A/B测试是什么？怎么做？有什么作用呢？本篇文章为大家分享了几种应用场景及案例，告诉大家如何在团队中有效推进A/B测试。

在互联网下半场竞争中实现科学增长，切实让A/B测试发挥增长引擎的作用是应有之义。

本文分享了A/B测试对业务转化率提升带来的价值，以及如何在团队中有效推进A/B测试及A/B测试系统科学设计实践等内容。

一、今日头条增长秘籍：A/B测试驱动

抖音可以说是现在增长最火热的公司，流行于大街小巷行走的人们手机之中，它让腾讯感到深深的危机感，被迫应对，从2017年下半年开始，抖音就呈现出现象级爆发式增长。

其母公司字节跳动，估值750亿美元，本身就是一个非常讲究实验、以A/B测试驱动科学增长的公司。

A/B测试对头条系产品来讲是很自然的事情，整个公司从最高管理层张一鸣开始就非常注重。36Kr曾在一篇报道中写道，“头条发布一个新APP，其名字都必须打N个包放到各大应用市场进行多次A/B测试而决定，张一鸣告诉同事：哪怕你有99.9%的把握那是最好的一个名字，测一下又有神马关系呢？”

今日头条从起名字开始就运用了数据思维，创始团队没有头脑风暴，没有投票，没有老大拍板儿，而是采用科学实验的方式，通过数据观测确定了头条的名称。

他们将App Store上各类免费榜单的前10名整理出来，然后根据名字归类（朗朗上口白话类，内涵情怀类，模拟特殊声音类，公司名+用途类等），分析那各类数量占比。分析结论是朗朗上口的大白话效果最好。

其次，分渠道A/B测试，确定先验效果类似的发布渠道，分别投放，界面功能logo完全一样，统计各个渠道的用户下载和活跃等核心数据指标，最后测得《今日头条》效果最好。

二、什么是A/B测试？

A/B 测试是一种产品优化的方法，为同一个优化目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，同时另一部分用户使用 B 方案，统计并对比不同方案的转化率、点击量、留存率等指标，以判断不同方案的优劣并进行决策。

上面图示就是一个典型的A/B测试范例。

在A/B测试比较成熟的公司中，可能并不局限于只有A、B两个版本，可能会有ABC测试、ABCD测试，甚至是ABCDE测试。

有一些情况，可能会出现比较特殊的A/B测试，比如说AAB测试，因为需要验证整个AB测试系统的准确度，需要设置两个对照组，所以叫AAB测试。

不管同时运行几个实验，我们都可以将它们统称为A/B测试，英文为ABtest或ABtest。

结合公开数据和行业深度调查，我们整理了行业A/B测试频率概览图，其中可以看到，公司市值或体量与A/B测试频率呈正相关关系。

像谷歌等大体量公司，它本身具有较为成熟的A/B测试系统与数据分析平台，平均每周A/B测试就多达2000个A/B测试，其中包括一些相对复杂的实验，如推荐算法A/B测试，也有相对简单的A/B测试。至于国内BAT等一线互联网公司，它们每周也会进行上百个A/B测试。

在与我们合作的大部分公司当中，行业分布广泛，比如互联网金融、电商、O2O等厂商，它们自身没有能力和精力自研一套成熟的A/B测试平台，所以他们选择与Testin A/B测试合作，将A/B测试服务快速应用到业务中。

比如，某互联网金融用户，在使用Testin A/B测试前，每周只能做0.1个A/B测试，使用了云测A/B测试服务后，大大提升了A/B测试频率，每周跑大概30个A/B测试实验。

当然，在其每周30个实验中，约有1/3的实验会取得转化率指标提升5%-30%的效果，剩余2/3的实验效果并不理想，未取得较好的数据指标提升。

通过这个例子，我们可以看出，大概2/3的产品设想并不符合预期，就是说转化率其实没有原始版本好。这个也是为什么需要A/B测试的根本原因，凭借产品直觉去做产品决策，但2/3的改进并不是最优解。

上述图表展示的是微软必应搜索引擎A/B测试增长曲线，覆盖Bing从2008年到2015年的时间的A/B测试实验增长情况。

可以看到，在Bing产品初期，每周A/B测试频率维持在10~50个，到2012年之后，Bing A/B测试每周频率进入快速增长。

图表右下角绿色曲线，是Bing移动端的A/B测试频率增长曲线。通过该图表，我们可以看到，Bing非常看重并认真实施A/B测试实验，以驱动数据增长，促进业务发展。

三、A/B测试应用场景及案例

我们先看下A/B测试在移动应用中的四大应用场景，分别是App、落地页、后端算法和小程序。

APP端是目前移动互联网增长的主要载体，PC或H5(如常见的朋友圈刷屏活动)或者广告投放落地页面等则可以归为落地页，还有后端算法场景，如推荐算法、广告算法、千人千面等等。

目前增长最快的应用场景，则是小程序。

在不同的场景，A/B测试的侧重点也有不同，但最核心目标仍然都是围绕业务的增长展开，也就是大家所熟悉的「北极星指标」，或者是 DAU、MAU等在A/B测试中设定的具体目标。

案例一：相机拍照类应用

以Camera360为案例，它选用Testin A/B测试服务帮助其进行产品优化决策。

该案例是其产品商业化过程中的一个尝试，希望提升商店中表情包或道具的付费比例，但要完成付费指标，首先要提升商店入口点击率。

所以，他们设定了多个商店入口方案（更改图标样式、文案），通过A/B测试来验证哪个方案可以最大化提升商店入口点击率。

在验证过程中，他们也针对人群目标做了相关定向测试，如日本、中国、韩国等区域，最终他们针对这一入口同时上线7~8个测试版本，通过A/B测试，将整体点击率提升了80%左右。

案例二

本案例为互联网理财行业的App，他们期望通过更改签到按钮的文案提高签到人数，从而提高留存率，按钮文案由「签到」改为「签到赚钱」，并进行A/B测试，为A、B版本分配了各5%的流量。

在经过测试后发现新版本的签到次数比原始版本签到次数提高4.17%，其中95%置信区间结果显示小范围人群的试验结果推广到全量用户之后，有95%概率获得1.7% 至 6.6%的提升；p-value小于0.05，显示新老版本有显著统计差异，Power 为100%，说明统计功效显著。

通过这次简单的A/B测试，就极大提升了App留存率。

本次测试，也借助Testin A/B测试的可视化功能，直接修改相关元素属性就实现了对照功能，无需开发人员介入。

那产品什么时候需要A/B测试呢？

我们知道进行A/B测试需要成本，比如需要开发多套版本，需要搭建可用的A/B测试及数据分析平台等。

从投入产出比考虑，进行A/B测试平台有2个必要条件，一是产品决策影响大，二是产品方案选择困难。

如果某决策对产品影响很大，但选择不困难，则没有必要进行A/B测试，比方是否决定给App增加微信及第三方登录方式，这对产品影响很大但决策并不困难，因为业界已有常见的解决方案。

再比方说，添加某很细小的功能，且该功能入口极深、用户量不大，那么A/B测试优先级也并不高。只有当一个产品决策同时满足影响大和选择难这两个条件的时候，才最适合进行A/B测试。

拿我们自身进行的测试来说，我们会基于功能影响大小、选择困难程度，对要做测试的功能做好优先级排序，然后判断哪些功能要做A/B测试。

四、A/B测试落地三要素

通过与我们的合作伙伴，如自如、36氪、子弹短信或51信用卡等众多增长团队交流，我们发现A/B测试做到落地有三大关键要素：

• 第一，人的因素，或者说整个团队的思维习惯、思维方式。
• 第二，业务流程，就是增长工作流程。
• 第三，工具。

展开来说，在「人」的角度上，要求整个团队具备数据驱动增长、A/B测试驱动决策的思维习惯，这是最重要的事情。

同时，如果增长或产品团队负责人本身不具备这种意识，认为A/B测试无关紧要，比较依赖经验进行产品优化决策，那么A/B测试做起来也很困难。

对APP也好，包括现在的小程序也好，新型产品层出不穷，产品面对的竞争也异常激烈。加之目前互联网流量红利期逐渐结束，获客成本增加，如果想继续获得业务增长，目前最有效的办法就是落地A/B测试、以数据驱动增长这一路径。

行业发展趋势决定所有团队都会慢慢迁移到用科学的实验进行增长这条路上来，即使你现在的团队推进A/B测试困难，但是我相信不远的将来，A/B测试将是最重要的产品增长驱动力。

我曾与较多欧美增长同行进行过深入交流，有一个很深感受就是他们的互联网企业中 A/B测试氛围更强，主要因为美国人工成本相对较高，他们特别注重投入产出比，所以他们很早进入到精细化运营阶段。

在业务流程上：

• 第一，需要注意你的产品是什么形态，是依托APP、小程序、公众号还是Web网站。不同的业务场景，A/B测试落地方案也会不一样。
• 第二，要考虑A/B测试是否很好融入到了产品迭代或增长团队工作流程中去，最佳实践就是做到将整个产品优化迭代流程、发版节奏与A/B测试紧耦合，形成流水线作业，这也是BAT等公司能够把A/B测试每周频率做到那么高的原因。

在工具方面，一种是自研，另外一种是使用第三方服务。

自研的话，在可控性、业务耦合方面有一定的优越性，但对一般企业来讲，其研发成本、人力成本很高，开发A/B测试服务还涉及到较为严格的数据统计，需要配置专业的数据分析师。

如果使用目前市面上的第三方工具，比如Testin A/B测试服务，可以最大化降低成本、加速业务落地A/B测试服务。

比如，某小程序用户当天接入Testin A/B测试服务后，当天就运行起三个A/B测试实验。无论是自研还是使用第三方工具，关键在于适合自身团队。

五、A/B测试最佳流程实践

A/B测试最佳流程，可分成四个步骤：

• 分析数据：分析现有原始版本的各项数据指标，如注册转化率等，比如说注册转化率仅有10%，针对这一转化率提出想法；
• 提出想法：比方说要改进注册流程，之前用户需要输入短信校验码，计划改成图片校验码，形成改进备选方案。有了该基本假设后，预估大概率可以提升转化率；
• 重要性排序：限于团队资源有限，无法把所有需求想法全部都去验证，这就需要做重要性排序，选择最重要的这几个改进方案去做A/B测试，接着进入第四步；
• A/B测试：在这个过程中，我们要监测A/B测试数据，结果一般有两种，一是数据证明实验无效，一是证明实验有效。我们经过大量测试发现，大部分进行的A/B测试实验，1/3被证明有效， 2/3被证明无效（与原始版本效果差别不大，或者比原始版本效果还坏）。

这里需要大家注意，不是所有的实验都会被证明对指标增长有显著效果，如果是这样，我们就没有必要进行实验了。

如果遇到这种情况，需要告诉自己的团队成员不要灰心，正因为某些实验被证明无效，我们才会找到有效的增长方式。

实验失败是大概率事件，我们最好的办法就是增加测试频率、持续测试，而非浅尝辄止，又回到经验主义决策的老路上。

如果你的团队从来没有做过A/B测试，有三点建议给到大家：

1. 从最简单的文案A/B测试开始，比如说测试关键按钮中不同文案的转化率；
2. 多做团队间的经验分享，多分享你的成功经验，有效果的事情大家都愿意尝试；不要天天去分享失败的经验，如果过多分享失败经验，会让你包括你的团队对A/B测试产生质疑，影响团队士气；
3. 可以优先使用第三方免费的A/B测试工具，比如Testin A/B测试，目前支持App、Web/H5、小程序。

六、企业A/B测试成熟度模型

上面介绍了落地A/B测试的三大关键因素，以及A/B测试的最佳实践流程。在这部分，为大家分享企业A/B测试成熟度模型。

我们把企业A/B测试分成四个阶段，分别是起步阶段、成长阶段、成熟阶段和大规模应用阶段。该能力的成熟度最核心指标，就是每周能做多少个A/B测试。

处于起步阶段，平均每周能做0~1个A/B测试，整个组织架构处于开始尝试A/B测试阶段，但内部没有成型的A/B测试实验平台，仍使用最简单的分流方式和数据分析方法进行实验。

此时的A/B测试并不是一个标准的A/B测试，从实验评价体系角度来看，已经设定一个最基本的指标，比如说转化率，但仍没有体系化。

何为体系化指标？也就是从单一指标演进为多维度指标体系，系统跟踪实验对产品的多方面影响。

第三个阶段就是相对比较成熟的阶段，这个时候每周能做到3~10个测试，A/B测试已经成为产品迭代流程的一部分，并需要可视化A/B测试，后端A/B测试等高级功能，以便满足多样的A/B测试需求。

在成熟和大规模应用阶段，提到了一个名词OEC。OEC，可以理解成综合评价指标，可能是复合型指标，在很多单项指标通过加权平均后得到。 通过OEC的设定，指导整个组织的业绩发展。

七、A/B测试系统设计能力

上面分享了如何落地A/B测试。接下来，跟大家分享下设计一个典型的A/B测试系统，需要具备哪几点能力或特征：

1. 科学流量分割

包括唯一性、均匀性、灵活性、定向性及分层分流。

1. 唯一性是指通过精准且高效的Hash算法，确保单个用户每次登录应用时被分到的试验版本是唯一的；
2. 均匀性，则是确保分流人群，各维度分配比例均匀；
3. 灵活性，则需要支持用户随时在实验的进行过程中，调节实验版本之间的流量分配比例；
4. 定向性，则是可以根据用户标签来实现精准定向分流，如根据用户设备标签及其他自定义标签特定分流；
5. 分层分流，则可以满足并行进行大量A/B测试需求。

左：未开启分层分流机制；右：开启分层分流机制

这里重点介绍下为什么需要分层流量分割机制。如果没有分层流量机制，则存在如下限制：

• 每个用户最多只能参加一个A/B测试实验
• 多个实验不能同时使用全体用户进行测试，可能因为人群覆盖度不够高导致结果偏差每个实验的可用实验流量受限于其他正在进行的实验，缺乏灵活的流量分配机制

有了分层流量分割机制，就可以很好地满足并行进行不同业务或不同场景，或者不同产品模块之间的A/B测试需求。

2. 科学统计算法

• 科学统计，使用科学的统计分析方法来对实验数据进行分析，并给出可靠的试验结果；
• 区间估计，给出95%置信区间，避免点估计带来的决断风险；统计显著性判断，通过p-value来判断不同实验版本之间差异显著性；统计功效判断，通过Power来判断不同实验版本统计功效是否充足；精益分析，对实验数据进行去噪音处理，去除噪音数据，以提高统计结果的质量。

上面就是基本的分享内容，限于篇幅，更多A/B测试后面有机会再与大家分享。

作者：陈冠诚，Testin副总裁、Testin A/B测试业务负责人。师从欧洲科学院院士Per Stenstrom教授，发表过6篇大数据国际论文和8项国际专利，为美图、宜人财富等企业搭建了A/B测试驱动增长的数据体系。公众号：云测数据（testindata），数据驱动增长的坚定实行者

本文由 @陈冠诚 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议