AB实验设计-阿里云开发者社区

为什么要进行 A/B 实验？

决策无处不在，小到一个活动标题、一个 icon 的颜色，大到产品的交互形式、甚至是战略。每个决策都会影响一部分用户的使用体验。长远看，他们都将或大或小影响产品价值。我们该如何做决策、如何量化收益？这些问题，我们无法通过产品、UI设计、运营等同学的主观判断来得到答案。与此同时，任何一个功能从开发到上线，我们也无法保证整个过程中不出任何 BUG。如果直接对全量用户推全新功能，而新功能存在 BUG 的话，影响将非常大。为了避免此类情况发生，我们有必要先小流量测试一下。这就是我们进行 A/B 实验的原因。

什么是 A/B 实验？

A/B 实验中，将用户随机分为至少两组。如果样本足够大，那么我们可以认为不同组别的用户无差异。在某个时间节点，对他们施加不同的方案或策略（一般只设定一个唯一的变量，除此之外，不同组别的其他条件完全一样）。不施加其他影响的组为对照组（A 组），实施新方案（策略）的组为实验组（B 组）。A/B 实验就是通过对比 A 组和 B 组的差异，评估所施加的方案（策略）的收益，达到帮助业务决策的目的。

A/B 实验的基本原理为假设检验。假设的形式为：原假设 H0、备择假设 H1。一般在工作中用的场景是双尾检验，即 H0 为 A 组 B 组的数据指标无统计学意义上的差异（包括用户数、用户画像、用户活跃度分布等）。其原理基础为小概率事件。即事件 A（小概率事件）在一次试验中几乎不可能发生的，如果在一次实验中 A 就发生了，那么我们应当合理怀疑该假设的真实性，拒绝原假设。常用的方法有 F 检验法、T 检验法、χ2检验法(卡方检验)等。

A/B 实验适用场景

理论上，方案不唯一的场景，都可以通过 A/B 实验来解决。我们平时会接触到的 A/B 场景可以归为以下 3 类。

产品功能优化

产品功能优化细分可以有几大类：

一是功能的去留决策，新功能是否上线、旧功能是否下线，比如前段时间微信上线的视频号就是一个新功能；

二是功能策略优化，比如微信公账号里，打赏作者的几种默认打赏金额；

三是产品功能的 UI 优化，比如微信聊天里的默认表情包的优化、甚至 App LOGO 的优化；

四是产品文案的优化，比如微信红包的默认文案以及红包文案节假日时的变更。

运营策略优化

运营策略也有很多种。

一是运营策略设置，比如很多 app 都有打卡奖励活动，打卡的频次设置、奖励金额设置；电商 App 里给用户送优惠券，优惠券的额度、满减标准、发放人群等。

二是活动文案优化，标题的重要性不言而喻，会直接影响参与活动的用户数，标题的选择也可以通过小流量 A/B 决定。

三是 Push 促活等优化，Push 的发送时间段、发送频次、Push 内容等等，这些也可以通过 A/B 实验，选择用户转化率最高的方案。

A/B 实验优缺点

A/B 实验可以量化不同方案的影响程度，从而回答不同方案的优劣。但是 A/B 实验也是有局限的，它并不能告诉我们最优答案，只能对比不同方案的区别；它也不能告诉我们直接的因果关系。我们能通过 A/B 实验等到结果，但是结果产生的原因却不能通过数据得到。另外，A/B 实验也不能回答战略性选择的问题，比如一个实验会导致活跃用户数下降，但是也能提升用户使用 App 的时长和打开 App 的次数。这种偏战略的数据结果，我们很难通过数据来决策。

目前 A/B 实验的方法已经比较普及了，甚至一些公司出现过分依赖 A/B 实验，造成 A/B 实验滥用的现象。我们知道 A/B 实验有诸多优点，但是 A/B 实验也是有成本的。多种方案就意味着，对应的产品、UI 设计、开发、测试、数据分析等等，都需要相应的资源来支持，另外，A/B 实验是需要流量的，也会出现用户产品体验不一致的问题。所以，现实中我们要辅以对业务的专业判断，及历史累计的经验来综合决策，避免 A/B 实验造成的资源浪费。

尽管有以上问题，我们不能因此忽视 A/B 实验优势。那么如何设计和评估 A/B 实验呢？

如何完成一个 A/B 实验？

我们以产品功能优化为例来说，根据业务流程，产品方案 → 功能开发→功能上线→产品决策，来说说数据分析师在各环节应该准备的 A/B 流程有哪些

A/B 实验设计（产品方案阶段）

在产品方案预评审阶段，我们基本可以知道功能的优化点或是新上线的功能形式。基于对业务的判断，和产品共同决策是否需要实行 A/B 实验，如果需要的话，前期我们需要完成以下准备工作。

首先，数据分析师需要根据功能特征，制定功能上线后的评估指标。预先做好评估方案，一是可以与各方业务达成一致的数据预期，作为后续功能上线、扩量等决策的依据；二是根据评估指标Check 目前的日志或者埋点数据，判断是否满足我们的需求。如果缺少数据，需要一并提交开发需求，以保证 A/B 实验的可评估性。

其次，我们要确定 A/B 实验的流量选取方案。流量的选取最好满足以下条件：一是每组用户的数量相当，且可以确保 A/B 实验的结果是可读的（量级太大会扩大影响范围、量级太小得不到置信结果）；二是保证各组用户是随机分组产生的，即每组用户无显著差异，以此保证后续试验时，实验组（B 组）和对照组（A 组）只有唯一变量；最后，依照通常情况，每种方案最好选取 2 组用户，这样可以排除不同组别用户的随机波动影响。你可能会问，如果满足以上全部条件，一个方案至少需要 4 组用户（AABB 组）。那么在活跃用户数一定的情况下，如果同时有多个 A/B 实验需要并行，那如何保证有足够的流量使得不同实验之间相互不影响呢？这就涉及一个实验设计的概念：用户（流量）分层正交。

我们假设，根据目前 App 活跃用户数的量级来看，需要每组至少 10% 的流量才能得到统计学相对置信的结果。此时我们可以随机将用户分为 10 组，每组 10% 的流量，即 A1、B1、C1……这样的分组结果，可以支持我们同时进行 2 个 A/B 实验（每个 A/B 实验，有 AABB 共 4 组用户）。如果，此时想同时进行第三个、第四个实验怎么办呢？此时，我们把刚刚分为 A1、B1、C1 等的 10 组称为第一层，再将第一层的用户随机分到第二层的 10 个组里，即将 A1 组 10% 的流量随机分为 10 个 1% 的流量分到第二层的 A2、B2、C3 等组中。同理 B1、C1 等也各自随机分到第二层每个组中，以此可以得到第二层 10 个 10% 流量的实验组。以此内推，可以得到第三层、第四层等。通过上述的分层规则，我们可以看到，不同层之间的实验是相互不影响的，即不同层的用户是正交的。通过这种方式，我们可以实现多个 A/B 实验的同时进行。

埋点验证（功能开发阶段）

进入开发阶段，如果有新增埋点，我们需要检验上报埋点的准确性。如果等到功能上线再来介入，可能会因为埋点的缺失或者不准确，导致 A/B 实验的结果无法评估。所以埋点验证需要在前置到开发阶段进行，以此保证后续数据的可用性。

实验分析（功能上线阶段）

功能上线后，一般需要用户更新安装新版本后，才能体验到新功能。所以，为了保证一定量级的用户体验到新功能，必须保证新版本的用户渗透率达到一定水平。也因为这个原因，A/B 实验通常需要一段观察周期。观察周期的长短与产品形态有关，像微信、微博这种高频 App，通常一周时间就够了；像淘宝这种相对低频的 App，需要的时间周期更长一些。

在评估指标时，有一点我们需要注意：我们必须排除实验前 AB 组差异的影响，即排除 preAA 的差异。下图为每组日活用户数的曲线图，假如实验在第 9 天上线，如果只看上线后的趋势图，我们会得出，B2 组的活跃用户数明显低于 A1 和 A2 组。因此会得出，实验组 B2 的方案会造成 DAU 下降。但是，如果我们多观察实验上线前的数据会发现，B2 的 DAU 在实验上线前就低于 A1 和 A2 组，他们之间的 diff 并非实验造成。

实验决策（功能决策阶段）

通过上一步，我们可以得到实验组各项指标收益与对照组的对比情况。这就需要针对实验方案作出决策。我们知道 A/B 实验不适宜长期观察，因为对于一个产品，不宜同时存在多种方案，让用户之间存在明显差异。另外，A/B 实验的客户端代码也会增加 App 包的大小，新用户对此比较敏感，可能会影响用户的下载转化；再次，A/B 实验可用的流量是有限的，长期占据流量也是一种资源浪费。所以需要对实验结果尽快决策。如果实验组的关键指标显著负向，可能需要继续优化功能后再上线；如果观察到的关键指标变化不大，但是功能本身的改动很大，可以建议扩大流量观察；如果实验组指标有正向收益，也可以建议直接推全。