AB 测试平台的设计与实现

AB 测试(以下称为「试验」)，本质是把选择权交给用户，让用户决定什么是最好的。我们给参与试验的不同用户，分配不同的方案，收集用户数据并加以分析，最终确定最优方案。

试验方案的分配可抽象为一个哈希函数，它将一个用户映射为一个试验方案。用户数据一般通过用户行为隐式收集，比如点击、购买、停留时长等。数据的分析则需要依据统计学的假设检验，确保结论的合理性。

需求，从简到繁

这里涉及的概念有「试验」(experiment)和「用户」(user)，而逻辑则有「分配方案」、「收集数据」和「分析并得出结论」等。我们从最简单的系统开始，以各种问题挑战这个设计及其背后的假设，以此逐步完善它。

第一个问题是关于用户的，如何支持未登录情况下的试验？一般来说用户是通过 uid 标识的，但未登录时无法得知 uid。如果要支持未登录情况，势必不能以 uid 为用户标识。未登录情况，常规做法是以设备标识 device_id 来做区分，而现实情况是，公司范围内 Web/Android/iOS 三端还未统一 device_id。看来无解了？
换个角度，既然无法控制，就不要控制。平台大可以只定义用户标识(名为 client_id)，但其取值完全交由业务方决定。

第二个问题，在开发/测试/验收过程中，PM/QA 可能想通过「白名单」，直接把用户分配到特定试验方案中，绕开「分配方案」逻辑。这是很实用的需求。在分配方案之前，先行检查用户标识是否在某个方案的白名单之中，即可做到。

第三个问题，试验方案是否支持设置权重？从科学的角度，试验期间不支持权重是最为合理的。用户在试验方案之间均匀分配，对于数据分析来说最简单。而且试验未得出结论之前，随意设置权重等于瞎撞，是没有意义的。但是，如果把确定最优方案之后的步骤也考虑进来，权重就有意义了。比如，现确定方案 B 是最优方案，那么自然希望尽快将 B 方案全量部署到线上。如果可以设置权重，直接把方案 B 的权重设置为 100% 就行了。否则的话，就得改代码并且上线，慢很多。这里，权重的意义在于试验之后的行为，达到灰度放量的效果。

第四个问题，试验状态及起止时间。这同样是出于实用的考虑，但这导致有新状况需要处理。比如试验状态被置为禁用，或