A/B testing是数据驱动和用户增长的核心方法论，绝大多数科学的增长方式都是建立在AB实验基础之上的，本文将对A/B testing做一个全面的介绍，涉及实验系统的构建技术和产品应用，适合用户增长领域的产品经理和技术工程师参阅。
A/B testing是一种随机实验方法，对于某个变量，给定A和B两个方案，通过随机抽样实验确定哪个方案更有效。图1展示了AB实验示例，对于一个网页，做了A和B的两个优化方案（橙色和绿色区域的变化），然后随机将50%的用户分配到A方案上，另外50%的用户分配到B方案上，通过对比实验结果确定出了方案A更优（A的转化率23%高于B的转化率11%）。
AB实验在日常生活中也经常会遇到，例如在临床医学上进行的双盲测试就是实际case。在双盲测试中病人被随机分成两组，分别给予安慰剂和测试用药，经过一段时间的实验之后根据这两个人群的临床表现差异，来判断测试用药是否有效。另一个经典case是A/B testing应用于奥巴马总统竞选时候的一个网站优化，如图2所示，这个活动的注册引导页面分为上半部分的媒体信息（图片or视频）和下半部分的注册按钮（4个文案JOIN US NOW，LEARN MORE……），一共是6*4个组合，最终通过实验得到了图2右侧效果最优的组合。这个最优的页面比起原始的基准页面，用户的转化率提升了40.6%，让他们多获取了约280万的注册用户。
图2 A/B实验用于优化奥巴马竞选网站优化
因为A/B testing如此重要，因此在整个互联网行业得到了广泛的推广应用。诸如Google、Facebook、腾讯、阿里、头条、百度等这些互联网巨头企业，都已经将AB实验平台作为了非常重要的基建设施，融入到了各个业务场景中。笔者见证了很多实际例子，例如百度收入在2010年-2012年收入大幅提升（70%以上），其中很重要的一个原因是将A/B testing引入到百度凤巢广告系统中，使得技术迭代速度有了很大的一个飞跃。另外，在行业内还涌现了一批专门提供实验能力服务的Saas公司，例如国外的optimizely、国内的Testin和吆喝科技等企业。
可以看到A/B testing已经成为互联网产品经理和开发工程师的一项重要能力，尤其是用户增长从业者的一种基本素养，为何它如此重要，主要有以下几方面原因：
1）AB实验已经逐渐成为了一种产品/系统的迭代方式。如图3所示，传统的产品迭代方式是产品经理制定了一系列升级点，然后开发上线发布一个新的版本，如果出现了问题（例如数据下跌），再发新的版本升级甚至回滚。在A/B实验的迭代模式下，产品经理针对所有的升级点（甚至一个升级点的多个不同方案），同时进行实验，最后选定最优的方案进行上线发版。通过实验数据，保证了迭代质量；并且可以多个方案同时实验，加快了迭代速度。
图3 基于A/B测试的系统迭代示意图
2）产品经理/开发工程师由于各种原因无法确定哪个方案更优（例如产品名称A还是B更好好，本身就是很难事先决策的模糊问题；再比如算法模型离线AUC更好并不意味着上线效果更优），因此需要通过实验数据来选择更好的方案。
3）团队内部意见不统一，针对不同意见对应的方案进行实验，用数据说话，统一大家沟通语言和标准。
技术实现篇
A/B实验也叫Bucket Test（分桶测试），这个名称反应了A/B testing的基本思想。如图4所示，通过hash算法，将用户随机分配到N个桶（bucket）中，实验方案A和B分别占用一个bucket。实验周期结束之后，分别统计A和B两个方案对应bucket中用户的实验实验指标（例如点击率、转化率）即可对比出A和B两方案哪个更优。常用的hash算法例如MD5、CRC32、SHA-1由于性能太低，不能满足AB实验系统的需求，因此常用MurMurHash算法。Google的论文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》可以算得上是工业化A/B实验系统的鼻祖资料，感兴趣的朋友可以参阅。按照图4的方式，一个最基础的实验系统可以运行起来了，但是在实际工作中很容易发现这样的设计远远不能满足产品经理和技术工程师的需求：我们有非常多的实验，需要更多的bucket，但是流量却怎么也不够分？一个实验周期结束，出来了实验结果，数据上看起来只有很小的提升，这个实验是否有效果？因此，在实际工作中，我们需要的是一个拥有更多实验桶；实验结果更准确；实验过程更快速的实验系统。
1. 更多：流量有限，但在众多的实验需求下，如何并行更多的实验桶？
1.1 客户端、前端、后台、算法每个环节都需要进行实验，并且每个测试有可能会有多个实验方案（例如某个按钮需同时实验10种背景颜色选一个最好的；算法工程师同时实验某个参数的5个不同取值，以便确定最优的参数）。在实验需求这么多的情况，我们还希望缩短实验周期（避免实验排队的情况），如果按照图4的方式，很快就会面临流量不够用。假设有1000万用户流量，我们同时需要并行做1000个实验，每个桶就只能分到10000个用户。在这10000个用户上累计出来可信的实验指标可能就需要2个星期，这样会导致我们的实验周期很长，并且由于样本太少，实验置信度降低。因此，我们需要一个在有限的流量情况下，仍能大规模并发的实验系统。
解决这个问题的常用做法是将流量分层分桶，构建多层实验框架。在业务系统中，有很多参数是互相相关的，也有很多参数是彼此正交且互相独立的，因此我们可以将相关的参数放在一个层中，将正交的参数放在不同的层中，这样就可以达到同层流量互斥，分层流量复用的目标。如图5展示了一个推荐场景中的分层AB实验系统示意图，展现层的各种UI调整、排序层排序算法优化、召回层的召回策略实验三者都是互相正交的，因此可以将整个流量分为3层，每层再分为N个桶，所有的流量先经过第1层，随机分配到N个桶中；然后所有的流量再经过第2层，此时需要保证第1层第1个桶中的所有流量需均匀分配到第2层的N个桶中，第1层第2个桶中的流量需均匀分布到第2层的N个桶中，以此类推……，同理，第2层各个桶中的流量也需均匀分布到第3层各个桶中。通过这样分层分桶架构，相比单层N个实验桶，扩展到了N*K（K层）个实验桶，并且理论上可以不断添加新的实验层，从而大大提升了实验并发规模。
图5 单层实验流量分桶示意图
1.2 正交性验证：在多层实验框架中，每一个请求只会落在某层的唯一一个实验桶中，但是可以落在多个层的不同实验桶中，因此某个请求有可能会带上多个实验ID。上一层的每个桶的流量需均匀分布下一层的每个桶中，也即满足多层正交性。正因为满足多层正交性，多层实验框架中的每个桶产出的实验效果才和单层多个桶的实验效果一致，是置信的。这个逻辑是有严格的数学证明的，在此不再赘述。在实际工作中，是如何保证每层之间是正交的呢？这一点很关键，如果不能验证每一层是否正交，实验平台则不能保证实验结果的置信度。因此，我们需要对每层进行正交性验证的。
如图6所示，则A,B是第1层中任意两个桶，用户占比例分别为N(A),N(B)，X是第2层中任意一个桶，如果满足以下条件：N(AnX)=N(A)*N(X)、N(BnX)=N(B)*N(X)，则说明第1层和第2层是正交的。同样，这个也是可以从数学上进行证明的，在此不赘述。
图6 多层正交验证示意图
1.3 既然多层正交如此的基础和重要，那么具体如何对流量进行分配以保证在多层的正交性呢？常用的方法与单层流量随机分配类似，设置多个hash函数，在每层采用不同的hash函数对流量进行切分。先确定第1层的hash算法，再用另外的hash算法（或者种子）对第2层进行流量切分，然后验证第1层和2层是否满足正交性，如果不满足，再尝试新的hash算法和验证正交性，如此反复。这样的方式是work的，业内很多AB实验系统都是采用的这样方式。目前行业内更领先的方式，是采用正交表算法，如图7所示，通过直接查正交表即可确定某个用户ID应该落在哪一层的具体哪一个bucket中，这样的方式非常高效，既省去了构造hash算法和正交性验证的成本，同时直接查正交表的方式计算性能也有了极大的提高。
图7 正交表示意图
2. 更准：在A/B实验系统中，准确性主要是指的实验结果是可信的，更具体的说是实验系统需要给出关于实验结果是否具有显著性这一点上准确的判断。
例如，在新起的一组实验中，发现产品的人均收入上涨了0.5%，实验结果是否是显著正向的，是否应该将这个实验推全到100%流量？这个环节主要涉及到统计学中的假设检验，本文将主要介绍一下背后的实现逻辑。假设检验通常采用反证法，例如上面的实验效果，我们需要确定人均收入上涨了0.5%是否具有显著性。如图8所示，以双侧Z检验为例，常见假设检验包括以下几个步骤：
1）提出原假设H0：新的实验方案是无效；备择假设H1：实验方案是有效的；
2）选取合适的统计变量（收入均值），并计算其分布；
3）计算p-value=P（拒接H0 | H0为真），p-value也即在原假设为真的条件下，样本数据拒绝原假设H0这样一个事件发生的概率；
4）根据事先确定的可以接受的显著性水平alpha，如果p-value<alpha时，判定原假设H0错误，接受备择假设H1，也即说明实验是具有显著性的。
图8 双侧检验示意图
假设检验中涉及到2种类型的错误：一类错误（无效实验被判定为有效）和二类错误（有效实验被判定为无效），不同的业务场景对于一类错误和二类错误的容忍度并不一样。作为一个高效的实验系统，需要尽可能降低这两类错误，常用方式是应用合适的检验方法。不同的指标适用于不同假设检验方法，常见的统计指标，例如人均PV、人均收入等均值统计类指标用T检验或者Z检验就可以（当样本量较大时T分布近似于标准正态分布）。Z检验用于检验正态样本均值是否等于某个假设值，不过需要事先知道总体方差，得到的统计量服从正态分布。T检验与Z检验相似，T检验不需要知道总体方差，它用样本方差替代总体方差，得到的统计量服从T分布。实际应用中，T检验用的更多，因为不容易知道总体的方差。然而对于CTR这类指标，T检验和Z检验就并不合适。例如在推荐、社交广告场景中，用户多次点击行为并不是互相独立的，因此使用正态分布模型会出现大量的假阳性，也即一类错误，此时需要采用bootstrap检验方法。bootstrap检验，如其名字一样，它是一种样本重抽样的统计方法，能解决总体分布未知的复杂情况置信区间估计问题。
3. 更快：AB实验系统中更快主要指的是可以快速的创建实验，直观的看到各个统计指标数据，方便的实验放量配置。这个环节主要涉及实验系统易用性和细节打磨，在这里不做赘述。
读到此处，如果已经对前文的内容有较深的理解，那么对于A/B testing绝大部分知识已经掌握了。然而在实际工作中，随着实验场景的复杂性可能还会遇到一些更深入的问题，这个部分的内容会让你成为一个更加资深专业的A/B testing玩家。
Q1：由于各种各样的原因，在实验开始之前，A和B两个实验桶的数据并不一定是平的（例如实验组B比实验组A CTR高3%），这种情况下虽然得出了很漂亮的实验数据（例如实验结论是B比A的CTR高2.5%），但实验结果并不一定是正向的。遇到这样的情况应该怎么办？
A1：常见的解决方案是，在开始A/B实验之前，先进行AA实验。所谓的AA实验，也即对于即将进行的实验的bucket A和 bucket B，我们不做任何实验修改，先保留一定时间的空跑期，以观察两个bucket数据的差异。针对上面的情况，在AA实验的时候我们就能发现bucket A比bucket B的CTR低了3%，那么在我们拿到最终的实验数据之后，可以先消除这部分A/A的差异，再来评估实验结论。
Q2：再看另外的实际场景，假设我们在推荐系统中针对深圳地区的用户进行了一轮特殊优化，由于这部分用户占整体用户中的比例较小（例如1%），我们预期对于这部分用户的推荐结果CTR有5%的提升，如果按照流量随机切分的方式，是很难评估出这次优化是否有效的（对于大盘CTR的提升只有0.05%），这种情况下怎么办？
A2：这个优化只影响了推荐系统大盘用户中的很小一部分，如果我们从大盘整体去看效果，很难评估出实验效果是否显著，因此我们需要针对这部分受影响的用户（深圳地区）进行单独评估，以便更准确判断实验是否正向有效。因此这就要求我们的实验平台不光具有随机流量切分（通过用户ID哈希分桶）的方式，还需要具备按照用户标签随机流量切分的功能和针对用户标签进行指标统计的功能。
Q3：如果我们想开展的某项实验的候选方案非常多（例如UI修改方案有128种），按照正常流程如果对所有的候选方案都给定固定的实验观测期，那么整个实验成本会非常高，这种情况下是否还有进一步优化空间？
A3：当然是可以进一步优化，通过借助机器学习上的E&E（Explore & Exploit）算法模型，优化每个候选实验方案的测试流量成本。简单来说，可以将这个问题建模成一个多臂老虎机（MAB：Multi-Armed Bandit）问题，站在这个视角上看，上面的问题可以抽象为，如何用尽可能小的实验流量成本，从候选方案中选出效果最好的那个。其核心思想为：针对所有的候选实验组先用很小的流量进行测试，得到每个候选方案的效果反馈数据之后（刚开始的时候这个效果数据是不准确的），然后以概率p进行Explore（随机选择一个实验候选方案），以1-p进行Exploit（选择历史平均效果最好的候选实验方案），不断迭代收敛，从而减少实验成本。历史经验表明，对于有10个候选方案的实验，采用MAB算法进行优化，测试流量可以减少80%以上。细节可参考关于MAB更详细的资料。
Q4：在互联网产品中有时会遇到这样的情况，在整个产品用户中，非常活跃的用户是少数的，但是这样的用户却对于某些统计指标有着很大的影响（例如视频的观看时长，游戏的收入贡献）。在A/B实验方案中，虽然整体用户是平均分配的，但是这样的重度用户却不一定是平均分配的，这种用户微小的差异有可能导致实验结果的较大偏差。遇到这种情况怎么办？
A4：针对这样的情况，Netflix提出了一种interleaving的测试评估方法。如图9所示，interleaving比较适合应用在搜索/推荐/广告的排序场景，这种方法不用将用户事先分为A/B两组,而是将AB两个方案的结果进行随机交替排名，生成一个混合结果，然后对所有的实验用户展示这个混合结果。最后通过统计混合结果中A/B两个方案中各自占比多少从而确定A和B方案的优劣。interleaving方法消除了A/B组测试用户自身属性分布不均的问题，通过给予每个人相同的权重，降低了重度消费者对结果的过多影响。但是这种方法也有自身的缺陷，只能对比出A/B两个方案相对最优，并不能得出具体好多少的度量结论。
图9 Interleaving测试评估方法示意图
写在最后：A/B-testing实验系统确实是非常重要且好用的一个快速迭代工具，已经被无数家公司证明过对产品的巨大帮助。对于产品经理来说，这项能力和传统的产品思维（例如产品逻辑、捕捉用户需求……）并不矛盾。AB实验它只是一个辅助工具，当我们有ABCDE5个方案不知道哪个更好的时候，A/B-testing能够帮助我们做更科学的决策，更重要的是这5个方案如何产生，仍然依赖于产品经理根据用户需求和逻辑推导而得出，仍然依赖于算法工程师根据数据分析找到新的优化方向，而对于此，A/B-testing实验系统却几乎无能为力。但，这并不影响A/B-testing用户增长最重要的系统工具！
本篇文章来源于微信公众号: 聊技术做增长
原创文章，作者：数字时代，如若转载，请注明出处：http://www.timedigital.cn/3332
