【数据分析】如何做一次系统的A/B Test?

1,771 阅读6分钟

互联网产品中,决策无处不在,小到一个活动标题、一个 icon 的颜色,大到产品的交互形式、甚至是战略。

每个决策都会影响一部分用户的使用体验。长远看,他们都将或大或小影响产品价值。

为了避免决策失误,我们有必要先小流量测试一下。这种测试一般就是 A/B 实验。

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

以产品功能优化为例,根据业务流程,一般分为产品方案 → 功能开发→功能上线→产品决策几个环节,每个环节数据分析师都有相应的工作。

image.png

A/B 实验设计(产品方案阶段)

在产品方案预评审阶段,我们基本可以知道功能的优化点,或是新上线的功能形式。

基于对业务的判断,和产品共同决策是否需要实行 A/B 实验,如果需要的话,前期我们需要完成以下准备工作。

首先,数据分析师需要根据功能特征,制定功能上线后的评估指标。

预先做好评估方案:

一是可以与各方业务达成一致的数据预期,作为后续功能上线、扩量等决策的依据; 二是根据评估指标Check 目前的日志或者埋点数据,判断是否满足我们的需求。如果缺少数据,需要一并提交开发需求,以保证 A/B 实验的可评估性。 其次,我们要确定 A/B 实验的流量选取方案。流量的选取最好满足以下条件:

一是每组用户的数量相当,且可以确保 A/B 实验的结果是可读的(量级太大会扩大影响范围、量级太小得不到置信结果); 二是保证各组用户是随机分组产生的,即每组用户无显著差异,以此保证后续试验时,实验组(B 组)和对照组(A 组)只有唯一变量; 最后,依照通常情况,每种方案最好选取 2 组用户,这样可以排除不同组别用户的随机波动影响。

你可能会问,如果满足以上全部条件,一个方案至少需要 4 组用户(AABB 组)。

那么在活跃用户数一定的情况下,如果同时有多个 A/B 实验需要并行,那如何保证有足够的流量使得不同实验之间相互不影响呢?

这就涉及一个实验设计的概念:用户(流量)分层正交。

image.png

我们假设,根据目前 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 并非实验造成。

image.png

实验决策(功能决策阶段)

通过上一步,我们可以得到实验组各项指标收益与对照组的对比情况。这就需要针对实验方案作出决策。

我们知道 A/B 实验不适宜长期观察,因为对于一个产品,不宜同时存在多种方案,让用户之间存在明显差异。

另外,A/B 实验的客户端代码也会增加 App 包的大小,新用户对此比较敏感,可能会影响用户的下载转化; 再者,A/B 实验可用的流量是有限的,长期占据流量也是一种资源浪费。 所以需要对实验结果尽快决策。如果实验组的关键指标显著负向,可能需要继续优化功能后再上线;

如果观察到的关键指标变化不大,但是功能本身的改动很大,可以建议扩大流量观察;如果实验组指标有正向收益,也可以建议直接推全。