实验设计

AB Test 实验一般有 2 个目的：

1. 判断哪个更好：例如，有 2 个 UI 设计，究竟是 A 更好一些，还是 B 更好一些，我们需要实验判定
2. 计算收益：例如，最近新上线了一个直播功能，那么直播功能究竟给平台带了来多少额外的 DAU，多少额外的使用时长，多少直播以外的视频观看时长等

我们一般比较熟知的是上述第 1 个目的，对于第 2 个目的，对于收益的量化，计算 ROI，往往对数据分析师和管理者非常重要。

对于一般的 ABTest 实验，其实本质上就是把平台的流量均匀分为几个组，每个组添加不同的策略，然后根据这几个组的用户数据指标，例如：留存、人均观看时长、基础互动率等等核心指标，最终选择一个最好的组上线。

实验的几个基本步骤一般如下：

流量分配

实验设计时有两个目标：

• 希望尽快得到实验结论，尽快决策
• 希望收益最大化，用户体验影响最小

因此经常需要在流量分配时有所权衡，一般有以下几个情况：

• 不影响用户体验：如 UI 实验、文案类实验等，一般可以均匀分配流量实验，可以快速得到实验结论
• 不确定性较强的实验：如产品新功能上线，一般需小流量实验，尽量减小用户体验影响，在允许的时间内得到结论
• 希望收益最大化的实验：如运营活动等，尽可能将效果最大化，一般需要大流量实验，留出小部分对照组用于评估 ROI

根据实验的预期结果，大盘用户量，确定实验所需最小流量，可以通过一个网站专门计算所需样本量：

• 以次日留存率为例，目前大盘次日留存率 80%，预期实验能够提升 0.2pp
  （这里的留存率可以转换为点击率、渗透率等等，只要是比例值就可以，如果估不准，为了保证实验能够得到结果，此处可低估，不可高估，也就是 0.2pp 是预期能够提升地最小值）
• 网站计算，最少样本量就是 63W
  （这里的最少样本量，指的是最少流量实验组的样本量）
• 如果我们每天只有 5W 的用户可用于实验（5W 的用户，指最少流量实验组是 5W 用户），63/ 5 = 13 天，我们需要至少 13 天才能够得到实验结论

如果我们预期提升的指标是人均时长、人均 VV 等，可能就比较复杂了，我们需要运用 t 检验反算，需要的样本量：

实验效果

我们以一个稍复杂点的运营活动实验为例，活动有方案 1、方案 2，同时为了量化 ROI，对照组没有运营活动。

需要回答几个问题

1. 方案 1 和方案 2，哪个效果更好？
2. 哪个 ROI 更高？
3. 长期来看哪个更好？
4. 不同群体有差异吗？

第 1 个问题，方案 1 和方案 2，哪个效果更好？

还是要运用假设检验，对于留存率、渗透率等漏斗类指标，采用卡方检验：

对于人均时长类等均值类指标，采用t 检验：

通过上假设检验，如果结论置信，我们就能够得到方案 1 和方案 2 在哪像指标更好（有显著性差异）， 对于不置信的结论，尽管方案 1 和方案 2 的指标可能略有差异，但可能是数据正常波动产生。

第 2 个问题，哪个 ROI 更高？

一般有活动相比无活动，留存、人均时长等各项指标均会显著，我们不再重复上述的假设检验过程。

对于 ROI 的计算，成本方面，每个实验组成本可以直接计算，对于收益方面，就要和对照组相比较，假定以总日活跃天（即 DAU 按日累计求和）作为收益指标，需要假设不做运营活动，DAU 会是多少，可以通过对照组计算，即：

• 实验组假设不做活动日活跃天 = 对照组日活跃天 * （实验组流量 / 对照组流量）
• 实验组收益 = 实验组日活跃天 – 实验组假设不做活动日活跃天

这样就可以量化出每个方案的 ROI。

第 3 个问题，长期来看哪个更好？

这里就要考虑新奇效应的问题了，一般在实验上线前期，用户因为新鲜感，效果可能都不错，因此在做评估的时候，需要观测指标到稳定态后，再做评估。

例如有的时候出现，刚刚上线前期，实验组效果更好，但是经过以端时间，用户的新鲜感过去了，实验组的效果可能更差，因此，从长远收益来看，我们应该选择对照组，是实验组的新奇效应欺骗了我们，在做实验分析时，应剔除新奇效应的部分，待平稳后，再做评估

第 4 个问题，不同用户群体有差异吗？

很多情况下，对新用户可能实验组更好，老用户对照组更好；对年轻人实验组更好，中年人对照组更好，

作为数据分析师，分析实验结论时，还要关注用户群体的差异。

实验结束

实验结束后需要：

• 反馈实验结论，包括直接效果（渗透、留存、人均时长等）、ROI
• 充分利用实验数据，进一步探索分析不同用户群体，不同场景下的差异，提出探索性分析
• 对于发现的现象，进一步提出假设，进一步实验论证

更高级的实验

对于长线业务，可能同时有数十个实验同时进行，不但对比每项小迭代的差异，同时对比专项对大盘的贡献量、部门整体对大盘的贡献量，这样就需要运用到了实验的层域管理模型。

• 对比每个产品细节迭代的结果
• 对比每个专项在一个阶段的贡献
• 对比整个项目在一个阶段的贡献

多个活动交集量化的实验设计

作为数据分析师，多团队合作中，经常遇到多业务交集的问题，以我近期主要负责的春节活动为例，老板会问：

• 春节活动-明星红包子活动贡献了多少 DAU？春节活动-家乡卡子活动贡献了多少 DAU？
• 春节活动总共贡献了多少 DAU？

严谨一点，我们采用了 AB 实验的方式核算，最终可能会发现一个问题：春节活动各个子活动的贡献之和，不等于春节活动的贡献，为什么呢？

• 有的时候，活动 A 和活动 B，有着相互放大的作用，这个时候就会 1+1 > 2
• 还有的时候，活动 A 和活动 B，本质上是在做相同的事情，这个时候就会 1+1 < 2

这个时候，我们准确量化春节活动的贡献，就需要一个【贯穿】所有活动的对照组，在 AB 实验系统中通俗称作贯穿层。

（说明：实验中，各层的流量是正交的，简单理解，例如，A 层的分流采用用户 ID 的倒数第 1 位，B 层的分流采用用户 ID 的倒数第 2 位，在用户 ID 随机的情况下，倒数第 1 位和倒数第 2 位是没有关系的，也称作相互独立，我们称作正交。当然，AB Test 实验系统真实的分流逻辑，是采用了复杂的 hash 函数、正交表，能够保证正交性。）

这样分层后，我们可以按照如下的方式量化贡献：

• 计算春节活动的整体贡献：实验填充层-填充层填充组 VS 贯穿层-贯穿层填充组
• 计算活动 A 的贡献：活动 A 实验层中，实验组 VS 对照组
• 计算活动 B 的贡献：活动 B 实验层中，实验组 VS 对照组

业务迭代的同时，如何与自身的过去比较

上面谈到了【贯穿层】的设计，贯穿层的设计其实不但可以应用在多个活动的场景，有些场景，我们的业务需要和去年或上个季度的自身对比，同时业务还不断在多个方面运用 AB Test 迭代。

类似与上面这种层次设计，在推荐系统中较为常见，在某一些产品或系统中，贯穿层不能够完全没有策略，那么采用去年或上个季度的策略，代表着基准值，从而量化新一个周期的增量贡献

我们可以量化：

• 每个小迭代对整个系统的贡献：实验层中的实验组 VS 对照组
• 周期内，系统全部迭代与上个周期的比较：实验填充层 VS 贯穿层 1（或贯穿层 2）
• 同时，可以量化去年策略的自然增长或下降，以衡量旧有系统是否具有长期的适用性（作为系统设计者，更应鼓励设计具有长期适应性的系统）：贯穿层 1（上个季度的策略）VS 贯穿层 2（去年的策略）

更为复杂的实验设计

我以我目前负责的业务，微视任务福利中心的实验设计为例，举例一个更复杂的实验系统设计，综合了上面提到的 2 个目的：

• 量化每一个实验迭代为系统带来的增量贡献
• 量化每一类迭代（如 UI 迭代、策略迭代），在一个阶段的增量贡献
• 量化系统整体在上一个周期（季度、年）的增量贡献
• 量化任务福利中心的整体 ROI（本质上，是给用户一些激励，促进用户活跃，获得更多商业化收益，所以和推荐系统不同的是，需要有完全没有任务福利中心的对照组，用户量化 ROI）

更多干货，尽在 腾讯技术。

感谢邀请。在过去的几年里，我们的智能优化&AB测试引擎服务了美图、Camera360、宜人贷、爱钱进、自如、中原地产、51信用卡、中国移动、咪咕视频等众多互联网公司，对A/B测试在国内的应用有一些粗浅的认识，在此分享给大家，希望对大家有帮助。

一、什么是A/B测试

随着移动互联网流量红利、人口红利的逐渐衰退，越来越多的产品运营开始关注数据驱动的精细化运营方法，期望通过精细化运营在一片红海中继续获得确定的用户增长，而A/B测试就是一种有效的精细化运营手段。简单来说，A/B测试是一种用于提升App/H5/小程序产品转化率、优化获客成本的数据决策方法。在对产品进行A/B测试时，我们可以为同一个优化目标（例如优化购买转化率）制定两个方案（比如两个页面），让一部分用户使用
A 方案，同时另一部分用户使用 B 方案，统计并对比不同方案的转化率、点击量、留存率等指标，以判断不同方案的优劣并进行决策，从而提升转化率。

---

以下内容太长 TL;DR

2008年奥巴马竞选美国总统的时候，有一个互联网团队专门负责竞选相关活动的线上产品，例如奥巴马的竞选募捐网站。这个网站最核心的目标是：让网站的访客完成注册并募捐竞选资金。这个团队当时做了一个非常成功的实验：通过对6个不同风格的主页进行AB测试，最优的版本将网站注册转化率提升了40.6%，而这40.6%的新增用户直接带来了额外的5700万美金募捐资金！

对于互联网产品来说，通过A/B测试提升点击转化率，优化获客成本已得到越来越多的关注。以获客环节为例：许多产品都会在百度、头条等渠道投放落地页广告，以完成新用户的注册转化，而落地页效果的好坏，会直接影响转化率和获客成本。以每月200万投放费用为例，如果通过A/B测试将落地页的注册转化率有效提升20%，相当于每月能多获得价值40万推广成本的新用户。

那么，产品什么时候需要做A/B测试呢？一个App在做版本迭代更新的时候，所有的功能都需要做A/B测试吗？根据Testin合作的大量A/B测试客户的实际经验，一个产品在遇到“影响大，选择难”问题的时候，是最适合做AB测试的。

以广告投放的落地页为例，随着流量红利的结束，落地页的投放成本越来越高，落地页转化率效果的优劣影响也变得越来越大；与此同时，不同设计风格、不同布局的落地页之中到底哪个转化率最高，往往是一个困难的选择题。在“影响大，选择难”这两个条件都符合的情况下，落地页的A/B测试也就成了一个必然选择：因为A/B测试带来的收益会远高于A/B测试的实施成本。就像之前提到的奥巴马竞选网站首页的A/B测试一样，5700万美金的收入收益远高于整个实验的成本。

那如果我们在落地页中不使用A/B测试，而是根据经验，直接上一个落地页呢？在回答这个问题之前，我们先来看看我们在做产品决策时，常面临的一些挑战：

• 产品优化依靠经验主义，不能保证新的产品版本一定会有业绩提升

• 重大产品功能很难决策，不确定哪个方案效果最优

• “后验”成本高，如果改版失败，业绩损失无法挽回

从这些挑战中我们可以看到，如果我们在产品上线时不做A/B测试的话，一方面不能保证上线的版本转化率等指标一定是最优的，其次还面临着因产品改版失败带来的用户流失、业绩损失的风险。实际上，随着业务的发展，产品迭代体系的逐渐成熟，新功能上线时必须做A/B测试的紧迫性会越来越高，因为改版失败的风险越来越大，而用户的习惯也越来越难以捕捉，所以A/B测试的必要性会越来越高。

让我们来看一个真实的例子。下面这幅图，反应的是微软Bing搜索引擎从2008年到2015年每周A/B测试频率的增长情况。在08年Bing上线的初期，每周整个搜索引擎大约做20-30个A/B测试实验，而到15年之后，整个搜索引擎每周的A/B测试实验个数已经多达400个。从14年到15年，Bing移动端产品的A/B测试频率也增长（图中绿色曲线）到了每周近100个实验。由此可以看到，随着产品业务和用户量的增长，对A/B测试的需求也会随之增长，由数据来做科学决策的必要性也随之提升。

二、A/B测试最佳实践

一个产品运营团队，在实际推进A/B测试的时候，会遇到多方面的挑战。从Testin实际合作的AB测试客户来看，我们发现这些挑战可以总结成三个方面的问题：人、业务和工具。

• 人：

任何一个组织，核心要素都是人。在这个要素中，最重要的就是让整个团队的成员统一思想，想明白诸如“什么是A/B测试？”，“是否有必要在我们的产品运营中做A/B测试？”，“怎么做A/B测试？”，“如何衡量A/B测试的价值和效果？”等等相关的问题。

• 业务：

在一个具体的业务场景中，我们最关注的问题往往是如何将A/B测试在业务中的价值最大化。这个时候，产品运营比较关心的问题是“在已有的产品迭代流程中，如何低成本高效率地引入A/B测试？”，“如何在有限的资源投入情况下，最大化提高A/B测试的收益？”，“如何推进A/B测试在团队中的应用？”，“A/B测试的最佳实践是什么？”

• 工具：

A/B测试的工具有两种选择：自建A/B测试工具，或者与Testin云测这样专业的第三方A/B测试服务提供商合作。自建的A/B测试工具最大的好处是与企业业务关联度高，这种方式比较适合有强大的数据分析技术研发实力的企业。而与Testin
AB测试这样的专业第三方服务企业合作，最大的好处是能高效率、低成本地开展A/B测试，把精力专注于自己的业务增长上。

当一个团队具备以上三个要素，开始真正推进A/B测试时，最佳的实践流程是怎么样的呢？如果是初次接触A/B测试的同学，可能会有一个误解：“A/B测试的效果好坏非常依赖灵光一闪的好想法好创意，如果创意好，A/B测试的效果就好，如果创意不行，那么A/B测试的效果就不行”。这种理解最大的问题就在于，忽略了A/B测试其实是有一套完整的方法论和实践流程的。在这套理论体系下，我们是可以稳定地通过A/B测试实现产品增长的。

1. 确立优化目标。在图5的A/B测试流程体系中，首先要做的，就是确立想要优化的“目标”。在这个过程中，我们建议大家一定要设立“可量化的、可以落实到某一个具体功能点的、可实施的小目标”。举例来说，如果一个目标不好直接量化，例如“将用户满意度提升15%”，那么就不好形成一个具体的A/B测试方案。同理，如果这个目标太大太宽泛，也不好落地。一个可行的目标可以是“通过优化注册流程，将注册转化率提升20%”，这个目标可以量化，而且足够具体，可以在后续流程中形成一系列相关的A/B测试实验方案。

2. 分析数据。通过数据分析，我们可以找到现有产品中可能存在的问题，只有先发现了某一个产品环节可能存在的问题，才好在后续流程中提出相应的优化方案，以优化这个环节的转化率。

3. 提出想法。在这一步，我们可以针对数据分析发现的问题，针对性的提出产品优化的方案，例如优化流程以提高转化率，优化设计和文案等等。一般来说，A/B测试的想法会以“假设”的方式提出。例如，“假设把注册流程中的图片校验码方式，改成短信校验码的方式，我们的注册转化率可能提升10%”。基于这个假设，我们会设计对应的A/B测试，并通过实验的数据验证这个假设是否成立。在后面的章节我们也会通过更多实际的A/B测试案例来跟大家分享一些相关经验。

4. 重要性排序。在开发资源、版本排期、优先级等因素的制约下，我们很可能不能对所有的想法进行实验。在这一步，最重要的目的就是根据重要性、潜在收益、开发成本等因素对所有想法进行优先级的排序，并选择最重要的几个想法进行A/B测试。

5. 实施A/B测试并分析实验结果。对于一个A/B测试来说，结果主要分成两种：有效和无效。无效的A/B测试实验对于团队来说，其实是非常宝贵的经验，这个时候我们可以把这些无效的实验转化成团队的经验，避免以后再犯同样的错误。而对于有效的A/B测试来说，我们成功通过实验提升了产品的转化率，这时我们可以把优胜的版本正式推送给全部用户，以实现产品用户的有效增长。

6. 迭代整个流程，进行下一轮A/B测试。

在这个流程中，最重要的就是迭代、迭代再迭代。尤其是在刚开始推行A/B测试的时候，很容易遇到“团队成员经验尚浅，不确定哪些产品功能点做A/B测试效果会比较明显”的问题，往往需要一些quick wins去建立团队对A/B测试的信心。这个时候，比较有效果的办法有两种：一种是针对一些转化率相对较低、很有可能通过改版获得提升的产品功能点，精心设计A/B测试实验，一般都会有比较明显的效果；另一种是快速地做一批简单的A/B测试实验（例如修改关键按钮的文案，颜色，图标等），只要其中有一部分实验取得了成功，就能很好的在团队内部推进A/B测试的实施。像Testin AB测试产品提供了业界首家针对App/H5的可视化编辑功能，可以对按钮、图标等控件进行“所见即所得”的可视化编辑，实现文案、图标的实时修改，而且无需应用市场审核，可以即时更新，非常适合快速地进行简单的A/B测试实验。

某国外大型互联网公司分享过一个有意思的数据，在他们进行过的数千个A/B测试实验中，只有大约1/3的实验取得了正面提升。这个数据说明了一个很有意思的现象：“产品经理的很多想法，其实不符合预期”，这也是为什么需要通过A/B测试的真实实验数据来进行产品决策的原因。

插播福利：感兴趣体验美图、宜人贷、相机360正在用的智能优化&AB测试产品 TestinData.AI 的同学，可以访问http://ab.testin.cn/?ch=zh1预约试用：）

三、A/B测试案例剖析

我们通过一些真实的案例，来分析下A/B测试的实际应用。

案例1：注册流程改版

让我们先来看一个注册流程的A/B测试。这个产品原始版本的注册流程使用了图片校验码的方式，但是注册转化率偏低。于是产品经理提出一个设想：如果把图片校验码方式改成短信校验码的方式，有可能因为降低了用户输入的难度导致注册转化率的提升。

带着这样的假设，他们设计了如下图所示两个版本的注册流程。通过使用Testin
A/B测试产品，分别为两个版本分配了20%的用户流量，通过一周左右的实验观察，数据显示新版本（短信校验码）的注册转化率提升了接近10%，并且95%置信区间是[8%,
12%]，说明这个实验版本推广到全量用户之后，95%的概率下至少会有8%到12%的提升。基于这个实验结果，产品经理选择将新版本注册流程推送给全部用户，显著提升了注册转化率。

案例2：App首页大改版

首页大改版对于一个产品来说，无疑满足“影响大，选择难”两个必要条件。在下面这个App首页改版的例子中，新版本的首页布局发生了多处改动：例如改动了4个子栏目、新增了一个banner，更改了类目展示方式。对于一个App来说，首页的改版属于非常重大的产品变动，稍有不慎就可能对现有用户体验造成很大的影响，如果改版失败，会直接导致成交额、用户点击转化率、留存率的下降。正因为影响重大，同时又不确定新版本是否能提升业绩，所以A/B测试在这种场景下是非常必要的。

产品经理进行这样的大改版，核心目的主要是为了提升首页向二级页面的点击转化率，并最终促成更高的成交转化。在这个实验中，因为有多个首页模块发生了变动，我们需要为不同的首页模块分别设置对应的指标，以对比两个版本首页向二级页面的转化率优劣。通过A/B测试平台将两个版本用户流量分别设置为10%，并运行2周实验之后，实验数据显示新版本首页向二级页面的整体点击量提升了12%以上。通过A/B测试，产品经理成功验证了新版本首页达到了预期的优化目标，之后就可以将新版本发布给全部用户了。

案例3：美图的A/B测试实验

美图正在用TestinData.AI对潮自拍APP的首页设计进行A/B测试优化实验，以提高社区化转型过程中用户对拍摄功能的使用率。

四、未来 – 智能优化&A/B测试

TestinData.AI A/B测试，已经为很多顶尖的产品经理、运营推广团队提供了从优秀到卓越的必杀密器，为产品、运营和经营管理人员，有效掌握、提升了以下这些经营核心指标：

• 点击通过率 Click-through Rate (CTR)
• 转化率 Conversion Rate (CR)
• 更新率 Renewal Rate
• 跳出率 Bounce Rate
• 平均保留率 Average Retention
• 平均使用量（应用，手机网站、网页，App屏幕或游戏场景上的时间），Mean Usage (Time on app, mobile web, mobile webpage, an app screen or game scene)
• 平均每用户事务数Average Transactions Per User
• 净推动者指数 Net Promoter Score (NPS)
• 客户满意率 Customer Satisfaction Rate
• 平均每用户收入 Average Revenue Per User (ARPU)
• 平均订单大小 Average Order Size

在跟美图、宜人贷、自如、51信用卡、相机360等众多合作伙伴做A/B测试的过程中，我们发现，未来的A/B测试引擎一定是越来越智能，越来越自动化：智能优化引擎应该能实时持续动态对不同产品版本进行数据分析，并进行智能流量调节，无需人工干预，自动提升转化率，降低产品试错风险。

于是，我们在18年推出了业界首家基于强化学习的智能优化引擎，可以7*24小时系统自动进行版本选优和比例调整，无人工干预，保持运营水准持续提升。感兴趣的同学可以访问: http://ab.testin.cn/?ch=zh2 了解更多详情。

受限于篇幅，本文未深入讨论A/B测试的一些相关知识，例如分流算法、统计算法、95%置信区间、统计显著性等等。如果对这些内容感兴趣的读者，欢迎加作者微信交流：threadingnow

参考资料

1. TestinData.AI官网：

TestinData.AI,转化率优化,AB测试,智能优化,数据分析-云测数据-国内领先的应用智能优化引擎​ab.testin.cn2. 知乎专栏 | A/B测试那些事：https://zhuanlan.zhihu.com/abtesting

2. TestinData.AI 智能优化&AB测试官方博客：http://ab.testin.cn/blog/

A/B 测试是什么呢？团队内部经常会有针对细节上的意见不一致的情况，你觉得你的想法好，我觉得我的想法好，那与其大家吵来吵去，还不如把每个人的想法拿出来快速验证一下，看看真实用户的反馈，那么反馈数据最好的自然就是最终我们的选择。

简单来说，A/B 测试能快速帮助我们做出正确决定。比如说我们要决定放一张图片，通过图片来吸引用户点击我们的页面，那这个时候，你觉得放一张仙人掌图的效果最好，我觉得放个慈祥老太太的照片效果最好，那我们谁也没法说服谁，不如就拿出 1000 个用户，然后给其中 500 人看仙人掌，计算他们会有多少人来点击这张图片。然后给另外 500 人看老太太人像的照片，同样计算他们的点击率。那么点击率高的那张图，就可以被认定是效果最好的，然后可以给所有的用户看。

那么现在国内外各大网站呢，都会使用这种测试方法。尤其是媒体类的，比如说新郎网易这样的大平台，他们在起标题的时候，都会起很多，然后挑选其中感觉最好的，拿来做 A/B 测试，比如在最初发布的 30 分钟，测试几个标题，然后选出选出效果最好的，最后就都用那一个。

同样呢，微信公众号也可以做类似的测试，但是会麻烦一些。首先你得有一个微信个人号，里面全是你的用户，然后把个人号的用户群体分成了两个或者多个分组。那么每次你拿不准标题和配图的时候，就可以用预览的方式，做出不同版本的微信图文，然后发到朋友圈，给不同的分组看，看看实际的点击效果怎么样。这个测试不是特别准确，但是能起到一些参考作用，然后在正式的推送之前呢，就可以根据参考的结果来进行调整。

那除了标题和图片之外的，A/B 测试的用途非常的广泛，比如说去哪儿，就会用这种方式来测试广告投放的效果。

做为一家提供以A/B测试方法论为基础的Saas创业公司，尽可能详细介绍一下这个事情，希望对大家有帮助：

—————-什么是A/B测试？———————-

这个摘自：Online Experimentation at Microsoft

Controlled experiments, also called randomized experiments and A/B tests, have had a profound influence on multiple fields, including
medicine, agriculture, manufacturing, and advertising. Through randomization and proper design, experiments allow establishing causality
scientifically, which is why they are the gold standard in drug tests. In software development, multiple techniques are used to define
product requirements; controlled experiments provide a valuable way to assess the impact of new features on customer behavior. At
Microsoft, we have built the capability for running controlled experiments on web sites and services, thus enabling a more scientific
approach to evaluating ideas at different stages of the planning process. In our previous papers, we did not have good examples of
controlled experiments at Microsoft; now we do! The humbling results we share bring to question whether a-priori prioritization is as good
as most people believe it is. The Experimentation Platform (ExP) was built to accelerate innovation through trustworthy experimentation.
Along the way, we had to tackle both technical and cultural challenges and we provided software developers, program managers, and
designers the benefit of an unbiased ear to listen to their customers and make data-driven decisions.

翻译过来的意思：（偷懒了，谷歌翻译，略作了修改）

对照实验，也叫随机实验和A /B测试，曾在多个领域产生深远的影响，其中包括医药，农业，制造业和广告。

通过随机化和适当的实验设计，实验构建了科学的因果关系，这就是为什么对照实验（A/B测试）是药物测试的最高标准。

在软件开发中，产品需求通过多种技术手段来实现; A/B测试实验提供了一个有价值的方式来评估新功能对客户行为的影响。

在微软，我们已经实现了运行网站和服务的A/B测试实验能力，从而可以用更科学方法来评估规划过程中不同阶段的想法价值。 在以前的文章中，我们并没有很好的A/B测试实验的例子; 现在我们有了！ 我们用震撼人心的效果，来说明先验优先级是否一样能获得大家的信任。

该实验平台（EXP）始建通过值得信赖的实验来加速创新。一路上，我们必须解决技术和文化的挑战，我们给软件开发人员、项目经理和设计师一副“公正的耳朵”，帮助他们听取客户真实的诉求以及用数据驱动的决策。

A/B测试其实是一种“先验”的实验体系，属于预测型结论，与“后验”的归纳性结论差别巨大。A/B测试的目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信。这里面又涉及到数据化驱动决策与确定性优化提升等等延伸概念，接下来我详细解释。

（说句题外话，大量的大数据公司都在尝试通过“后验”结论进行未来行为预测，个人觉得然并卵，主要是因为数据不全、脏数据、随机事件、建模人为因素等等影响，方向无比正确，现实无比残酷）

—————-A/B测试的应用场景———————-

A/B测试这种方法论的应用非常广泛，这里讨论在Web产品、移动产品、数字广告优化领域的应用。应用场景由小到大可以可以分为：

• 元素/控件层面
• 功能层面
• 产品层面
• 公司层面

——元素/控件层面——–

先用一个例子来说明什么是元素/控件层面A/B测试：

图做的很难看，用来说明问题：

当产品已经相对稳定，已经上线并且有一定量的用户在使用时，

产品经理会面临一个压力：任何的更新或者优化是否一定比原来更好？

比如上面这个界面的变化：背景图片变了、模特换了、CTA按钮的颜色、大小、文案都变了

这么多变化，怎么来衡量 任何的更新或者优化是否一定比原来更好？这个问题

首先，这个问题可以进一步分解为：

• “好”怎么定义

“好”的定义就很复杂，不同的元素/控件的目的不一样，就拿“购买”这个CAT按钮来说，它的目的应该是“点击”，也就是说“点击次数”是衡量它好与不好的一个指标，当然还有其它如“点击率”、“首次点击次数”等等。

不同的产品侧重不同，为了简单点说明白，这里假定“点击次数”是衡量这个优化的唯一指标

• “好”怎么衡量

接下来就到了难点了，怎么衡量？

再回过来看看微软的描述：

At Microsoft, we have built the capability for running controlled experiments on web sites and services, thus enabling a more scientific approach to evaluating ideas at different stages of the planning process.在微软，我们已经实现了运行网站和服务的A/B测试实验能力，从而可以用更科学方法来评估规划过程中不同阶段的想法价值。

这里涉及到“科学的方法”涉及到很多统计学的概念，我就不一一解释了，有兴趣可以看看，我用这个栗子来描述这几个词到底是个啥：

假定这是个电商的APP，产品有100万用户

• 样本空间、样本特征、实验流量

样本空间：100万用户

样本特征：这100万用户有各式各样的特点（性别、地域、手机品牌与型号、甚至是不是爱点按钮等行为。。）

实验流量：100万用户成为100%的流量；假定将这100万用户根据样本特征与相似性规则分为100组，那每组就是1万人，这1万人就是1%的流量

• 采样、代表性误差、聚类

相似性采样：在A/B测试的实验中，需要保证小流量的实验具备代表性，也就是说1%的流量做出来的实验结果，可以推广到100%的用户，为了保证这一点，需要保证1%的流量的样本特征与100%流量的样本特征具备相似性。（说个最简单的逻辑：假定把所有小米手机用户均匀的分到这100组中，那第一组的所有小米手机用户的特征与第2组-第100组的所有小米手机用户具备相似性）

代表性误差：代表性误差，又称抽样误差。主要是指在用样本数据向总体进行推断时所产生的随机误差。从理论上讲，这种误差是不可避免的，但是它是可以计算并且加以控制的。（继续小米。。尽管把小米用户均匀的分成了100组，但是不能完全保证每个组里的小米用户的数量、性别、地域等特征完全一样，这就带来了实验误差风险）

聚类：物理或抽象对象的集合分成由类似的对象组成的多个类的过程被称为聚类，也就是在分配小米用户的过程中，需要按照实验目的的不同把特征相似性高的用户认为是一类用户，比如定义100次点击为高频点击，可能在某些情况下也会认为99次点击的用户跟100次点击的用户是一类用户

• 置信度与置信区间

在统计学中，一个概率样本的置信区间（Confidence interval）是对这个样本的某个总体参数的区间估计。置信区间展现的是这个参数的真实值有一定概率落在测量结果的周围的程度。置信区间给出的是被测量参数的测量值的可信程度，即前面所要求的“一定概率”。这个概率被称为置信水平。

置信度：简单来将表示可信程度，一般来说95%的置信度就很好了，一些及其严苛的A/B测试实验才会到99%的置信度。差别在于，越高的置信度得出结论的实验时间越长、流量要求越高

置信区间：从前面的概念中也讲了，1%的流量尽管具备了代表性，但是跟100%的流量还是有差异的嘛，所以实验结果的评判要有一定的前提的，置信度就是这个前提，置信区间表示在这个置信度的前提下，实验结果很可能会落在一个区间内，比如下图，95%的置信度的前提下，置信区间为[-2.3%, +17.4%],可以解读为这个A/B测试的实验既有可能使“点击次数”降低2.3%，又有可能提升17.4%。说明这个实验结果还不稳定，可能是试验时间短或者是流量不够。

理解完这些，我们继续回来说“好”怎么衡量：

实际上，你需要一整套工具。。。。知道为啥我们创业做这个了吧，实在有点复杂。

基本的衡量逻辑如下图：（看起来很复杂，其实真正使用的时候比较简单）

别人那里借的图，罪过罪过~

是时候讲讲数据化驱动决策与确定性提升是什么意思了：

数据化驱动决策：A/B测试是典型的靠谱数据化驱动决策，拿这个栗子来说：无论是绿按钮还是橙色按钮只有用户真正使用了才能判断到底哪个更好，所以可以先用A/B测试的方式，让比如1%或者5%的用户进行实验，让用户用实际的行为来告诉你哪个好。假设结论是下图，那就很不幸，你原来绿色的版本更好。因为这1%或者5%的用户通过“点击次数”这个指标告诉你，他们不喜欢橙色的设计。这就是数据化驱动决策，不用一屋子人你拍桌子我瞪眼的争辩到底那个设计好，让真实的用户跟数据告诉你到底哪个更好。

确定性提升：这就更好解释了，有了这么个工具，每次只有效果好了才会上线，也就意味着每次优化都能比以前更好，无论是产品经理的自信心、用户的体验还是投资人那里，咱都可以理直气壮地说，我的每次更新，都比以前更好了。。。

到了我最喜欢的真实栗子的时间了：

Airbnb的产品方法论

知乎日报原文：都说在做某界的 Airbnb，Airbnb 到底做了什么

灰度发布 和 A/B测试：重要页面的修改和流程上的调优，通过灰度发布到1%或者5%的用户，看其实际对用户的数据影响（访问时间增加、留存提高、下单率提高等），决定此修改到底是100%发布还是被砍掉

Google：

每个月从上百个A/B测试中找到十几个有效方案，月营收提升2%左右，10亿美元的规模

广告位左移一个像素带来X%的增收，左移两个像素带来Y%的亏损

任何产品改动需要A/B测试才能上线

Facebook：

6个月内所有版本完全线上灰度发布，通过不断进行用户流量分割的方式进行实验，获得无Bug口碑

写了这么多，才第一条。。我真是话痨=。=b

——功能层面——–

A/B测试这么伟大的方法论只用来测界面（当然真有效啊！！！），有点太小瞧它了，无论是推荐算法还是定价策略，用这个方法论，轻松搞定啊！

为了简单理解，说个定价策略，如上图。

一个价格包含这个几个因素：

1.价格区间：

用我最朴素的理解，人类是喜欢折扣的不理性动物：人们明显更乐意花45折买一个价值900块钱的东西而不是花67折买一个价值600块的东西，尽管东西一样，最终价格一样都是400块。

所以你看电商广告都是打折配合几个垫背的低价来卖。。。

2.价格精度：

以前去超市经常能发现2.99元或者8.99，现在都变成2.32或者4.23，这是弄啥嘞？

这里面太多心理学与营销的东西就不说了，在某些情况下，即使几分钱的价格变化对用户转化的影响是巨大的，比如一个东西原来卖400元，那现在改成399还是401可能对总营收的影响并不巨大，但是配合用户转化率的变化，可能营收的差异就天差地别了。

3.价格周期：

伴随着产品迭代、促销等等因素影响，什么时候降价是对自己最有利的策略，完全可以A/B测试来解决

——产品层面——–

A/B测试在产品层面的应用主要是通过“灰度发布”来实现的。

就目前移动端的产品来说，iOS的应用商店审核期是个大大大坑，任何BUG打补丁还得再来一遍，也就意味着补丁的审核期内用户带着BUG使用，这个太致命了，用户的获取成本高的吓人，因为这个流失太不值得了，基于A/B测试的灰度发布更重要的不是优化，而是保护性发布，先通过小流量的实际用户测试，有BUG或者新版本体验不好，可以立即回滚到老版本，简单有效。

——公司层面——–

A/B测试其实也是谷歌管理方法论，具体文章请参考：

Google 的产品策略：两边下注

可以这么说，Google 的一整个产品线就是一系列可观的 A/B 测试。
大家应该都听说过 “不要把所有鸡蛋都放到一个篮子上。” 这句话的意思是说永远都要有 B 计划，它赞美的是多样化的优点。看看 Google 貌似混乱和令人困惑的产品线你会发现，其实这家公司正谨守着这一价值观。Google 往往喜欢针对同一客户群推出多项竞争产品。这样的话，如果一个产品失败了，也许另一个产品能够补上。
最极端的例子是 Google 的即时通信解决方案。Android 上一度曾出现过 4 款不同的产品：Google Talk、Google+ Messenger、Messaging （Android 的短信应用）以及 Google Voice。Google Hangouts 最终胜出，把其他的都合并进了一个平台。
Google 现在终于有了一个统一的即时通信平台了，这算是不幸中的万幸了吧。且慢，据印度经济时报报道，Google 已经在开发第 5 款产品了。据称这款即时通信产品将不需要 Google 账号，其目标针对的是 Whatsapp。Google 的 KitKat（Android 4.4）把原来的 SMS 应用撤掉，用 Hangout 来代替发短信，而到了 Lollipop 又添加回一个 SMS 客户端，所以很快我们又将回到有 3 个短信客户端的情况了。更新后一体版的 Hangout 由给 Android 增加了第二个拨号应用，这样现在除了 KitKat 引入的 Google Dialer 以外还有一个新的能拨打 VOIP 电话的 Hangout Dialer。现在用户要求统一拨号应用的呼声也开始高涨起来。
不过 Google 平时就是这样折腾的。其行动表明，自己并不相信一个问题只有一种解决方案，哪怕这样会让用户的日子好过得多。因为它需要应对外部各个领域的竞争对手，而且 Google 似乎也认为没理由竞争就不能出自内部—让自己的产品自相残杀。
Google Dialer 与 Hangouts Dialer
其效果就是 Google 几乎所有的产品目录似乎都要进行大型的 A/B 测试。正如 Google 的搜索引擎不断从 Web 上收集数据加以学习和改进一样，Google 公司本身也是这么运作的。它给单个问题提供了多个解决方案，希望能从中决出优胜者。
这种多产品策略对于 Google 的长期健康来说是好的，但它也浪费了许多资源。到处都是重复的工作，但 Google 的 Adsense 和 Adwords 带来了那么多的收入，至少现在 Google 挥霍得起。
这对于客户来说也不是最好的。它往往会给用户选择造成困惑，不知道在 Google 的生态体系里面应该如何二选一，尤其是在智能手机上面同一用途的 app 往往有好几个。虽如此，但 Google 更看重长期市场存在而不是短期的易用性。这一点也许是 Google 和苹果最大的不同。苹果提供了一个聚焦的用户体验，非常容易理解。Google 则对做任何事情都提供了多种手段，有的做得不错，有的则过于复杂，而有的则是 “僵尸产品”—未曾积极研发但一直都在好些年。
公司偶尔会通过 “春季大扫除” 的形式来整理多产品策略带来的混乱。2011年，Google 第一次开始产品批量清退时用了 “有的放矢” 的说法，但是现在 Google 推出新产品的速度似乎比清理老产品的速度要快得多。
有时候 Google 看起来纯属手贱无法控制自己。几波人同时做一件事的方式已经成为公司文化的 DNA。公司大部分的时间都是 “三头统治”，由 Larry Page、Sergey Brin 以及 Eric Schmidt 共同运营公司。Larry Page 最终成为 CEO，但 Sergey Brin 现在把持着 Google X，这基本就算是 Google 内部的迷你 Google—这家公司根本停不下来多样化的脚步。
所以下一次你看到 Google 的两款竞争产品希望它们合并时，你得知道这并不能解决问题。Google 最终还是会折腾出新的内部竞争者，然后再度冒出 2 款做同样事情的东西。Google 就是这么爱折腾。如果你是 Google 的用户，对此会感到沮丧，但没办法，Google 就是这样。
Google X 生命科学分部的负责人 Andy Conrad 在《财富》的一篇文章中曾提到：
对于一个问题 Larry 会尝试用 1、2 种办法去解决，并且在策略上会对两者都同时下注。

===============都说到这了，聊聊A/B测试需要注意的一些问题吧============

• 辛普森悖论与区群谬误

先说辛普森悖论，以偏盖全

辛普森悖论（Simpson’s Paradox）亦有人译为辛普森诡论，为英国统计学家E.H.辛普森（E.H.Simpson）于1951年提出的悖论，即在某个条件下的两组数据，分别讨论时都会满足某种性质，可是一旦合并考虑，却可能导致相反的结论。

转个果壳的文章，有兴趣可以看看

辛普森悖论：诡异的男女比例

大多数的产品或功能上线前都会进行测试，实际上很多的测试行为并不科学，特别是很多定向的用户测试经常会有这个弊端，简单来说，如果新上线的一个功能，所有的研发工程师都说好，那是不是意味着所有的用户都觉得好？很多情况下是否定的。当然这个例子比较简单，实际上很多A/B测试方法并没有考虑到这个问题，以至于最后得出的结论跟实际情况差异巨大。

要解决这个问题，对采样、聚类、流量分割等要求非常的高，这也是为什么A/B测试工具不能像很多统计工具一样，埋个点看数据，再根据数据反推业务逻辑，而是要充分与业务结合，从一开始就应该考虑业务策略，让用户去选择适合其口味的产品。

先说辛普森悖论，以全盖偏

区群谬误（Ecological fallacy），又称生态谬误，层次谬误，是一种在分析统计资料时常犯的错误。和以偏概全相反，区群谬误是一种以全概偏，如果仅基于群体的统计数据就对其下属的个体性质作出推论，就是犯上区群谬误。这谬误假设了群体中的所有个体都有群体的性质(因此塑型(Sterotypes)也可能犯上区群谬误)。区群谬误的相反情况为化约主义（Reductionism)。

==========写在最后========

大多数的产品或功能上线前都会进行测试，实际上很多的测试行为并不科学，特别是很多定向的用户测试经常会有这个弊端，简单来说，如果新上线的一个功能，所有的研发工程师都说好，那是不是意味着所有的用户都觉得好？很多情况下是否定的。当然这个例子比较简单，实际上很多A/B测试方法并没有考虑到这个问题，以至于最后得出的结论跟实际情况差异巨大。

要解决这个问题，对采样、聚类、流量分割等要求非常的高，这也是为什么A/B测试工具不能像很多统计工具一样，埋个点看数据，再根据数据反推业务逻辑，而是要充分与业务结合，从一开始就应该考虑业务策略，让用户去选择适合其口味的产品。

现在的创业者面临着前所未有的竞争压力，好的想法与用户接受的想法有着各种不可逾越的鸿沟。特别是伴随着激烈的竞争，谁能领先一步可能就变成了赢者通吃的局面。