AB测试

什么是AB测试？

AB测试的概念来源于生物医学的双盲测试，双盲测试中病人被随机分成两组，在不知情的情况下分别给予安慰剂和测试用药，经过一段时间的实验后再来比较这两组病人的表现是否具有显著的差异，从而决定测试用药是否有效。互联网公司的AB测试也采用了类似的概念：将Web或App界面或流程的两个或多个版本，在同一时间维度，分别让两个或多个属性或组成成分相同（相似）的访客群组访问，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。

AB测试的基本步骤

AB测试是一个反复迭代优化的过程，它的基本步骤如下图所示可以划分为：

1.设定项目目标即AB测试的目标

2.设计优化的迭代开发方案，完成新模块的开发

3.确定实施的版本以及每个线上测试版本的分流比例

4.按照分流比例开放线上流量进行测试

5.收集实验数据进行有效性和效果判断

6.根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验

从对AB测试的定义中可以看出AB测试强调的是同一时间维度对相似属性分组用户的测试，时间的统一性有效的规避了因为时间、季节等因素带来的影响，而属性的相似性则使得地域、性别、年龄等等其他因素对效果统计的影响降至最低。

AB测试流程

如何提供对用户的有效分组以及如何判断实验中不同分组用户属性的相似性是AB测试需要解决的第一个问题。而在试验过程中如何收集用户的体验和业务数据，如何对收集的数据进行分析并判断不同版本间的优劣是AB测试需要解决的第二个问题，也是AB测试的目的所在。下面我们对AB测试中这两个关键的问题进一步展开。

AB测试的设计

AB测试中分流的设计直接决定了测试结果是否有效。AB测试是对线上生产环境的测试，而之所以进行AB测试通常是对测试中的改进版本所产生效果的好坏不能十分确定，所以测试版本的流量通常不宜过大。尤其对于那些影响范围较大的改版（如主流程页面的重大调整），影响用户决策的新产品上线和其他具有风险性的功能上线通常采用先从小流量测试开始，然后逐步放大测试流量的方法。但是，测试版本的流量如果太小又可能造成随机结果的引入，试验结果失去统计意义。举个例子：某电商网站对我的历史订单这个页面进行改版的AB测试，测试的目标是提升用户的复购，衡量的指标是经过这个页面的单UV产生的GMV贡献（单日GMV总数／单日进入UV）。假设这个页面每天的UV在2000左右，而我们对新版本取的分流比例是2%，那么一天就会有差不多40个UV进入试验版本。如果试验进行1周然后考察试验结果，这是试验的结果就很容易受到某些异常样本的影响，譬如说某个土豪老王恰好分在了试验组然后购买了一个高价值的东西，那么老王的购买行为就可能带偏整个测试组的统计结果。

为了规避这种因为样本量不足造成的试验结果不可用，在AB测试设计时可以采用如下措施：

1.试验设计时预估进入试验的样本量，做分流规划时避免分配给测试集的样本量过少。

2.除了进行AB测试外增加关于数据有效性考量的AA测试，将原始版本的流量中分出两个和测试版本相同的流量也进入测试。例如：为测试一个新的功能，我们原本准备划分90%流量给老版本，10%流量给新版本；这时我们可以分配70%流量给老版本A，同时生成两个10%流量的老版本C和D进行AA测试，然后把剩余的10%流量给新版本B；在试验过程中通过考察分配给老版本C和D的两股流量是否存在显著性差异，从而认定试验分流是否有效。

AB测试和AA测试

3.如果参与测试新版本已经分配了很大的流量比例，但是仍然存在样本量不足的情况，这时就只能通过拉长试验时间的方式来累积足够的样本量进行比较了。

AB测试的设计过程中另一个重要的点就是AB测试延续的时长了，通常AB测试延续的时间不宜太长，因为AB测试是对线上的多个版本的测试，这也就意味着线上系统需要同时维护多个可用的版本，长时间的AB测试无疑加大了系统的复杂性。但是，另一方面如果试验进行的时间太短可能会造成试验样本量不足的问题。同时，如果进行的是UI改版一类影响用户体验的测试，新版本上线后用户通常需要有一个适应的过程，这时我们通常会在试验开始时给用户一个适应期让用户适应新的UI版本，然后再考察试验的结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。适应期过后的试验时间长短除了需要考察样本量的情况外，还需要参考用户的行为周期，譬如说电商用户的购买行为有较强的周次规律，周末流量和购买量与工作日会有显著差异，这时测试的周期应该能够覆盖一个完整的周期，也就是应该大于1周。

在试验版本的设计过程中还需要考虑线上进行多个试验相互间的影响，譬如在电商的购买流程中我们同时对搜索算法和商品详情页的UI进行优化，这两个变动贯穿在用户的购物流程中，相互之间可能是有影响的，我们需要区分试验中这两种改动带来的影响分别是怎样的。在这种情况下当然我们可以将用户流量分成：

A.老的搜索算法和老的详情页UI

B.新的搜索算法和老的详情页UI

C.老的搜索算法和新的详情页UI

D.新的搜索算法和新的详情页UI

这样四个版本，然后进行测试。但是这样分流的问题是对于流程中元素的改动，测试的版本是呈现指数上升的，在多个改动同时进行时就容易造成版本流量不足的情况。在这种情况下就需要引入试验分层的概念，将实验空间横向和纵向进行划分，纵向上流量可以进入独占实验区域或者是并行实验区域。在独占实验区域，只有一层，实验可以独享流量且不受其他实验的干扰。在分层区域，不同的应用属于不同layer，每个应用内部，又可以划分为多层，层与层之间相互不影响。流量可以横向经过多层，每一层可有多个实验。流量在每一层都会被重新打散。

独占流量实验区域

这样多层次正交的实验方式使多个并发实验都可以保证具备一定流量的并行进行。

最后，在对用户体验有明显影响的实验中通常采用对用户稳定的分流实现。即分到不同版本的用户在多次登录应用落入相同的实验版本，这样可以保证用户体验的一致性，保证用户能够在适应新版本的情况下有稳定的表现。通常会采用不同实验选用不同的hash种子，对用户的guid和上述分层实验的实验层次id的组合进行hash，然后根据hash值取余的方式进行分流。

AB测试效果分析   

关于AB实验效果的分析通常分为两个步骤：实验有效性的判断、实验结果的比较。实验有效性的判断即判断实验的分流是否已经到达所需要的最小样本量，从而能够以较大的概率拒绝两类统计错误的发生。最小样本量的判断可以采用假设实验目标指标符合正态分布下，两类错误发生概率的分位数的方式进行估算。或者更一般的可以采用AA测试，对两个老版本的实验结果计算P值，从而判断其是否存在显著差异。如果AA实验的结果不存在显著差异，那么可以认为实验结果是有效的，进而可以对新老版本的实验结果进行进一步的判断。

在确认实验有效后就可以对实验的结果进行判断了，通常通过比较新实验版本和老版本是否存在显著差异（前述的P值判断），以及计算实验结果指标的置信区间（通常选用指标的95%置信区间），从而判断新版本是否相对老版本存在显著提升或下降。

实验结果

关于AB测试的一些误区

最后，讲一下关于AB测试的一些误区，通过对这些误区的理解希望能够恰如其分的应用AB测试提升网站和产品的转化等指标。

误区1: AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况。

灰度发布是应用发布通常采用的方式，即对一个pool的部分服务器发布新版本的代码，而其余的服务器采用老版本代码，在确认应用正常的情况下逐步将新版本发布到pool的全部服务器。这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上。同时，灰度发布的分流单位通常是以服务器的流量为最小单位的，不能做到对测试流量的精确分配。

误区2: 用参加实验的部分用户的体验质疑AB实验结果的正确性。

经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果。AB实验是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性。

误区3: AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化。

AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代。对于那些明显的bug修复，或者对于那些能够明显改善用户体验的功能，应该采用尽快上线并监控关键数据指标的方式。此外，AB测试也不是silver bullet, 通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比。例如，某OTA对机票进行捆绑销售产生的收益进行了为期一年的多版本AB测试，测试的目标是在用户转化率没有显著下降的情况下提升用户客单价。在实验中，通过对价格非敏感用户的个性化展示、默认勾选等方式的确客单价有了很显著的提升，同时用户的线上转化率并没有显著变化甚至有了略微的提升。但是，这种捆绑销售的方式从长远来看可能对用户是有伤害的，这种情况在低频消费的场景下很难在实验的结果上有所体现。而且，这种捆绑销售的产品为媒体和公众所诟病，这些都不是AB测试能够体现的。