文章发布于公号【数智物语】 （ID：decision_engine），关注公号不错过每一篇干货。
来源 | 中国统计网
2000年Google的工程师第一次将AB测试用于测试搜索结果页展示多少搜索结果更合适，虽然那次的AB测试因为搜索结果加载速度的问题失败了，但是这次的AB测试可以认为是Google的第一次AB测试。
从那以后AB测试被广泛应用于互联网公司的优化迭代, 每年数万个AB实验被Google、Amazon、eBay、阿里等主流互联网公司应用于线上进行UI内容优化、算法优化、收益优化等方方面面。
01AB测试的基本概念
1. 什么是AB测试？
AB测试的概念来源于生物医学的双盲测试，双盲测试中病人被随机分成两组，在不知情的情况下分别给予安慰剂和测试用药，经过一段时间的实验后再来比较这两组病人的表现是否具有显著的差异，从而决定测试用药是否有效。
互联网公司的AB测试也采用了类似的概念：将Web或App界面或流程的两个或多个版本，在同一时间维度，分别让两个或多个属性或组成成分相同（相似）的访客群组访问，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
从对AB测试的定义中可以看出AB测试强调的是同一时间维度对相似属性分组用户的测试，时间的统一性有效的规避了因为时间、季节等因素带来的影响，而属性的相似性则使得地域、性别、年龄等等其他因素对效果统计的影响降至最低。
2. A/B测试的好处
1. 消除客户体验（UX）设计中不同意见的纷争，根据实际效果确定最佳方案；
2. 通过对比试验，找到问题的真正原因，提高产品设计和运营水平；
3. 建立数据驱动、持续不断优化的闭环过程；
4. 通过A/B测试，降低新产品或新特性的发布风险，为产品创新提供保障。
3. A/B测试的限制
1. 在App和Web开发阶段，程序中添加用于制作A/B版本和采集数据的代码由此引起的开发和QA的工作量很大，ROI（投资回报率）很低；
2. AB测试的场景受到限制，App和Web发布后，无法再增加和更改AB测试场景；
3. 额外的A/B测试代码，增加了App和Web后期维护成本。
02AB测试的基本步骤
AB测试是一个反复迭代优化的过程，它的基本步骤如下图所示可以划分为：
现状分析并建立假设：分析业务数据，确定当前最关键的改进点，作出优化改进的假设，提出优化建议；
设定目标，制定方案：设置主要目标，用来衡量各优化版本的优劣；设置辅助目标，用来评估优化版本对其他方面的影响。
设计与开发：制作2个或多个优化版本的设计原型并完成技术实现：
分配流量：确定每个线上测试版本的分流比例，初始阶段，优化方案的流量设置可以较小，根据情况逐渐增加流量。
采集并分析数据：收集实验数据，进行有效性和效果判断：统计显著性达到95%或以上并且维持一段时间，实验可以结束；如果在95%以下，则可能需要延长测试时间；如果很长时间统计显著性不能达到95%甚至90%，则需要决定是否中止试验。
根据试验结果确定发布新版本、调整分流比例继续测试或者在试验效果未达成的情况下继续优化迭代方案重新开发上线试验
03影响AB测试结果准确性的因素
1. 样本数量：流量样本的数量不能过少
测试版本的流量如果太小又可能造成随机结果的引入，试验结果失去统计意义。
举个例子：某电商网站对我的历史订单这个页面进行改版的AB测试，测试的目标是提升用户的复购，衡量的指标是经过这个页面的单UV产生的GMV贡献（单日GMV总数／单日进入UV）
假设这个页面每天的UV在2000左右，而我们对新版本取的分流比例是2%，那么一天就会有差不多40个UV进入试验版本。如果试验进行1周然后考察试验结果，这是试验的结果就很容易受到某些异常样本的影响，譬如说某个土豪老王恰好分在了试验组然后购买了一个高价值的东西，那么老王的购买行为就可能带偏整个测试组的统计结果。
但是需要强调的是，不能一昧追求大量的流量，流量过多，会增加试错成本。AB测试是对线上生产环境的测试，而之所以进行AB测试通常是对测试中的改进版本所产生效果的好坏不能十分确定，所以测试版本的流量通常不宜过大。尤其对于那些影响范围较大的改版（如主流程页面的重大调整），影响用户决策的新产品上线和其他具有风险性的功能上线通常采用先从小流量测试开始，然后逐步放大测试流量的方法。
所以，在试验设计时需要预估进入试验的样本量，并根据观察的数据及时进行调整。
2. 样本质量：分流出的样本是否有效
当测试结果显示两个版本没有区别时，我们不能完全确定这样的结果是因为方案本身的原因还是样本质量的原因。例如，依旧是购物车复购的案例，假设样本数量足够多，但很不巧的是恰好实验组里大部分都是老王这样的土豪，那么结果依旧会产生偏差。这个时候我们还需要更进一步确定，实验组里究竟有没有这样的意外因素。
解决这个问题有个很好的方式：AA测试
将原始版本的流量中分出两个和测试版本相同的流量也进入测试。
3. 测试的时间长短
测试的时间长短要根据进入的流量进行调整，不能太长或太短。
时间太短，没有足够的样本进入测试版本，会出现样本不足的情况，这时就需要通过拉长试验时间的方式来累积足够的样本量进行比较。时间太长，就意味着线上系统需要同时维护多个可用的版本，长时间的AB测试无疑加大了系统的复杂性。
同时，在设定测试时间时还要考虑到用户的行为周期和适应期。
①用户的行为周期
对部分行业的产品来说，用户的操作行为存在很大的周期性变化，例如电商用户的购买行为有较强的周次规律，周末流量和购买量与工作日会有显著差异，这时测试的周期应该能够覆盖一个完整的周期，也就是应该大于1周。
②用户适应期
如果进行的是UI改版一类影响用户体验的测试，新版本上线后用户通常需要有一个适应的过程，这时我们通常会在试验开始时给用户一个适应期让用户适应新的UI版本，然后再考察试验的结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。
4. 多个实验并行的相互影响
在试验版本的设计过程中还需要考虑线上进行多个试验相互间的影响，譬如在电商的购买流程中我们同时对搜索算法【1】和商品详情页的UI【2】进行优化，这两个变动贯穿在用户的购物流程中，相互之间可能是有影响的，我们需要区分试验中这两种改动带来的影响分别是怎样的。
在这种情况下当然我们可以将用户流量分成：
A：老的搜索算法【1A】和老的详情页UI【2A】
B：新的搜索算法【1B】和老的详情页UI【2A】
C：老的搜索算法【1A】和新的详情页UI【2B】
D：新的搜索算法【1B】和新的详情页UI【2B】
这样分流的问题是对于流程中元素的改动，测试的版本是呈现指数上升的，在多个改动同时进行时就容易造成版本流量不足的情况。在这种情况下就需要引入试验分层的概念，将实验空间横向和纵向进行划分，纵向上流量可以进入独占实验区域或者是并行实验区域。
在独占实验区域，只有一层，实验可以独享流量且不受其他实验的干扰。在分层区域，不同的应用属于不同layer，每个应用内部，又可以划分为多层，层与层之间相互不影响。流量可以横向经过多层，每一层可有多个实验。流量在每一层都会被重新打散。
这样多层次正交的实验方式使多个并发实验都可以保证具备一定流量的并行进行。
最后，在对用户体验有明显影响的实验中通常采用对用户稳定的分流实现。即分到不同版本的用户在多次登录应用落入相同的实验版本，这样可以保证用户体验的一致性，保证用户能够在适应新版本的情况下有稳定的表现。
04AB测试效果分析
关于AB实验效果的分析通常分为两个步骤：实验有效性的判断、实验结果的比较。
1. 实验有效性的判断
①判断实验的分流是否已经到达所需要的最小样本量，从而能够以较大的概率拒绝两类统计错误的发生。最小样本量的判断可以采用假设实验目标指标符合正态分布下，两类错误发生概率的分位数的方式进行估算；
②判断样本有效性。采用AA测试，如果AA实验的结果不存在显著差异，那么可以认为实验结果是有效的，进而可以对新老版本的实验结果进行进一步的判断；
③判断测试时间是否满足了样本需求，并考虑了适应期和行为周期；
④判断是否收到并行实验的影响。
2. 实验结果的比较
在确认实验有效后就可以对实验的结果进行判断了，通常通过比较新实验版本和老版本是否存在显著差异（前述的P值判断），以及计算实验结果指标的置信区间（通常选用指标的95%置信区间），从而判断新版本是否相对老版本存在显著提升或下降。
05关于AB测试的一些误区
最后，讲一下关于AB测试的一些误区，通过对这些误区的理解希望能够恰如其分的应用AB测试提升网站和产品的转化等指标。
误区1
AB测试运用成本过高，可以通过灰度发布的方式来进行AB测试，进而避免同时维护不同版本的情况。
灰度发布是应用发布通常采用的方式，是指在黑与白之间，能够平滑过渡的一种发布方式。这种发布方式让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
这样的方式的确可以起到分流的作用，但是这样的分流是不稳定的，用户的两次访问很有可能会被分到新老两个版本上。同时，灰度发布的分流单位通常是以服务器的流量为最小单位的，不能做到对测试流量的精确分配。
误区2
用参加实验的部分用户的体验质疑AB实验结果的正确性。
经常碰到产品经理或是业务人员提出某些用户在新版本的实验中没有转化，而实际实验数据体现新版本效果好于老版本的情况，从而质疑实验的结果。AB实验是基于统计的结果，是基于大样本量的有效统计结果，实验结果的好坏是针对参与实验的大多数样本而言的，个例不具备代表性。
误区3
AB测试是优化Web应用的利器，应该在所有场合都应用AB测试进行优化。
AB测试从实验的设计、实施和实验结果的收集通常需要一个不短的阶段，且进行AB实验需要在线上维护多个不同的版本，所以不应该所有场景下都采用AB测试对Web应用进行优化迭代。对于那些明显的bug修复，或者对于那些能够明显改善用户体验的功能，应该采用尽快上线并监控关键数据指标的方式。
误区4
AB测试总是非常有效的解决方法。
通常AB测试的时间不会延续很长时间，对于一些长期效果很难做到有效的监测和对比。例如，某OTA对机票进行捆绑销售产生的收益进行了为期一年的多版本AB测试，测试的目标是在用户转化率没有显著下降的情况下提升用户客单价。
在实验中，通过对价格非敏感用户的个性化展示、默认勾选等方式的确客单价有了很显著的提升，同时用户的线上转化率并没有显著变化甚至有了略微的提升。但是，这种捆绑销售的方式从长远来看可能对用户是有伤害的，这种情况在低频消费的场景下很难在实验的结果上有所体现。而且，这种捆绑销售的产品为媒体和公众所诟病，这些都不是AB测试能够体现的。
06总结
AB测试不能解决所有的问题，但是仍然不失为衡量线上优化迭代的最有效方式之一。可衡量的实验目标、有效的实验分流、实验结果的正确解读是AB测试成功的关键。
化AB测试需要公司付出一定的资源成本，因此在小型公司，产品还以生存为首要目的的阶段，并不是AB测试可以发挥的地方，但这并不代表我们不需要了解。作为一种知识储备，即便是不会真正使用，但是它内在的思维逻辑依旧会对我们有很大的帮助。
星标我，每天多一点智慧
