文：冬冬

本文原创，转载请注明作者及出处

随着移动互联网流量的“增长红利”逐渐褪去，新的流量入口“小程序”也在很长时间内都会保持“克制”的状态，“野蛮生长”主导的互联网时代已经悄然离去。

但业务增长是每个企业亘古不变的刚需。在硅谷，“增长黑客”理论帮助谷歌等公司实现了持续的高速业务增长。这些科技公司的成功案例让“增长黑客”在国内也成为了一个非常热门的话题，越来越多的人开始关注“增长黑客”，希望能利用它落地到实际业务场景中。

增长离不开 A/B 测试

在硅谷，增长黑客已经发展出各种各样的理论。其中，千亿美元规模的科技公司都会将 A/B 测试作为一种必备的增长工具去使用。

这些公司将 A/B 测试做到什么程度呢？

亚马逊每年都要做超过 1 万个 A/B 测试；谷歌则有 10 万个之多；

当你访问 facebook 的页面时，你已经同时身处 10 个 A/B 测试之中了。

从这些数据看，巨头们已经将 A/B 测试当作了家常便饭。似乎做 A/B 测试是一件非常容易的事情，真的如此吗？

A/B 测试的本质

在了解如何科学进行一项 A/B 测试之前，我们需要对“A/B 测试是什么”有一个定性的认识。

相信绝大部分人对 A/B 测试的认知是这样的：

两套产品方案，分别让 50% 的用户各自访问不同的两个方案，观察谁的数据效果更好。

这样的描述并不是不正确，但没有说到 A/B 测试的本质。

那 A/B 测试的本质到底是什么？自然界中达尔文雀演化的例子已经告诉了我们答案:

达尔文雀族群是生活在加拉帕古斯群岛的多种近缘雀鸟物种的统称。他们之所以被称作为达尔文雀，是因为达尔文发现，它们在体型上几乎完全相同，仅仅只有鸟喙形态不同，并且种类多达十几种，分布在群岛不同的位置。研究结果证明，这些雀鸟族群源属同一种鸟类，因为群岛上不同地方的环境差异，让它们进化出了最适合当前环境的鸟喙。

达尔文雀的选择进化是自然界中活生生的 A/B 测试例子，而这个例子也揭示了 A/B 测试的本质：A/B 测试是一个特定条件下去择优的过程。

在这个案例中，我们还能发现 A/B 测试 3 个最主要的特征：

1）A/B 测试是多方案并行的，并不是传统认知上的 A、B 两种方案：就像达尔文雀同时进化出了多达 18 种鸟喙。

2）一个 A/B 测试只有一个变量：达尔文雀的演化只影响了鸟喙这一个部位，而其他部位并没有变化。

3)一定遵循了某些规则或特定环境：只有在群岛自然环境的影响下，才能让它们进化出适合当前环境的鸟喙。

正如达尔文雀通过进化出更优的新形态来适应当前的自然环境那样，A/B 测试也是在当前环境下找到最适合用户的产品方案的过程。

在 A/B 测试时，我们犯了什么错？

我们理解了 A/B 测试之后，回顾我们之前做的所谓“A/B 测试”，以及验证产品假设的过程，能找到很多不够严谨的地方，我们在这里一一列举：

做测试时只测两种方案。

我们已经知道，A/B 测试其实是多方案并行的。在很多场合下，我们对一个产品假设其实会有各种各样的争议，但我们通常会被惯性思维所驱使，认为这个假设“非对即错”，正确的方法“不是 A 就是 B”。我们应当对自己的业务有更多的思考，列出足够多的合理假设，并尝试。

新功能发布先上一个新版本，和上一个时间段的老版本对比数据。

这种验证假设的方法不能称做 “A/B 测试”，并且缺乏严谨性。犯这种错误，是因为惯性思维使得我们脑中通常会有这样一个认知：产品两个不同版本的用户一直都是同一批人，会有相同的需求场景以及行为倾向。

这种认知最大的漏洞就是时间。显然，不同时间周期中的用户行为是不同的，那用户行为反应出的数据自然就会不同：双十一前和双十一后，用户的消费倾向会不同；入夏前和入夏后，用户的生活作息会不同；产品上个版本有强运营的活动，而这个版本没有，用户在产品上的注意力会发生变化...

即使我们控制产品本身的运营节奏，时间周期性造成的用户行为变化通常也是很难预测并量化的，这对产品数据的严谨程度造成了很大的挑战。由于 A/B 测试不受这些因素带来的影响，所以它能够在业界得到越来越多的应用。

修改产品的两处或更多地方并 A/B 测试，只观察整体指标

我们在达尔文雀的案例中已经提到，A/B 测试的特点是一个测试只有一个变量。因为在这个特定条件下，我们能够容易的推断：A/B 测试中引起产品数据的变化，一定是这单个模块的策略调整引起的。一旦一个产品页面/流程修改了两处以上，如果只看整体数据，那这个页面／流程数据变化的原因将无从追究，因为你根本不知道数据变化到底是哪个模块引起的，每个模块到底发挥了积极的作用，还是消极的作用。

但这并不是说我们不能同时修改一个业务流程的多处地方。相反，在实际的产品与业务迭代中，因为业务本身的需要，这种情况不可避免地发生，需要有一个解决办法。

既然一个 A/B 测试实验只能有一个变量，我们就可以认为：一个业务流程上的有多少各地方进行了调整，那这个业务流程上就同时进行着对应数量的 A/B 测试实验。将这些产品流程上的每处策略调整都抽离成一个个独立的 A/B 测试实验，分别观察同一个整体指标的变化，能取出每个实验的最优方案。每个实验最优方案的组合，就是整个产品模块的最优解。

使用用户标识“奇偶”去划分样本

为了追求“随机性”，不少产品经理／业务会告诉开发，通过设备号 or 用户 ID 的奇偶或类似的简单数学规则去划分参加 A/B 测试的用户。

简单的奇偶等数学规则存在很多限制，无法灵活 & 精确调整用户流量划分策略。设备号、Cookie 等用户标识的生成算法往往也是不可知的，是否真的能按找“奇偶”去划分出 50% 的流量，存在着未知风险。

A/B 测试有一套正确划分样本的方法。简单来说，是将用户的唯一标识通过加密算法计算出一串数字，并基于某种数学规则进行计算，比如取余。基于我们的流量划分需求，将取余结果划入对应的流量。这种办法能在数学上保证样本划分是尽量符合要求且随机的。并且，对于某个用户标识来说，被取余的同一个用户，他在实验周期内只会看到一种方案，不会命中另外一个。

无论你是产品经理还是开发，当你再次听到“用设备号奇偶进行流量划分”的建议时，请郑重告诉他是错误的。

如何设计一个 A/B 测试

当我们不再犯错后，我们还要知道如何真正地去设计一个 A/B 测试，来帮助我们进行产品假设。

1.分析现有流程 使用你现有的数据分析工具，在你的产品与业务流程中找到有问题的环节所在。例如：在用户整个浏览-购物车-下单-支付的环节中，用户在整个商品详情页流量的跳出率非常高。

2.观察分析用户行为 通过分析用户的详细行为、问卷调研等方法，找到阻止用户转化的原因。例如：购买按钮在整个页面上不够突出。

3.构建假设 那基于找到的阻止用户转化的原因，建立一个或若干增加用户转化的产品假设。例如：增加购买按钮的大小将使其更加突出，并增加转化。

4.验证假设 根据您的假设创建对应个数的 A／B 测试变量，通过 A/B 测试将这些假设与原始产品版本做对比。例如：将你的原来的商品详情页与购买按钮更大的商品详情页进行 A/B 测试。基于你的用户量级，预期效果等因素评估样本量与实验持续时间。

5.分析数据,得出结论 分析A/B测试结果，看看哪些方案的转化率最高。如果在数据上有明显更优的方案，那么就采用那个方案；如果没有，回到第三步，重新开始构建假设。

A/B 测试不只如此

在互联网时代，A/B 测试作为增长黑客的一种常用方法论被人们所逐渐熟知。殊不知，A/B 测试作为数理统计学科中的一种“先验”实验体系，在很多传统行业都有极其深远的影响。比如，在药物临床实验中，A/B 测试就是最高规格的实验标准。

对于 A/B 测试数据结果以及决策，传统学科也已经有一套完善的数据分析理论与方法，但它和人们对数据的普遍认知有很大的不同。这些认知不同到底在哪里？我们对数据的看法存在哪些偏见？在下篇中，我们会帮助大家“打破”对数据的固化认识，敬请期待！

参考

达尔文雀相关介绍 https://zh.wikipedia.org/wiki/%E9%81%94%E7%88%BE%E6%96%87%E9%9B%80

A/B 测试流程 https://vwo.com/ab-testing/

样本分流算法参考 https://www.lucidchart.com/techblog/2016/06/22/ab-testing-pt-2/

推荐阅读

DAPP开发实战之投票系统（上）

纠正你对区块链的认知偏见

从Nest到Nesk -- 模块化Node框架的实践

从 SQL Server 到 MySQL （一）：异构数据库迁移

自动生成测试脚本方案浅析

沪江全链路跟踪系统设计与实践