标签： ABTest

通过前三篇文章，大家可以了解到一个基本的 ABTest 平台架构建设的要点，看起来构建起一个生产环境可用的 ABTest 平台难度不大。但如果想把这个平台做得更强大，还有很多细节地方要注意。下面举两个常见的细节问题。

跨层分桶不完全正交

理论上来讲，如果每层分桶都是采取的独立不相关的 hash 算法，那么层和层之间的流量应该是完全正交且服从均匀分布的。举个例子：如果每层分 10 个桶，那么第二层的 1 号桶内，应该有第一层每个桶里的 1/10 的用户。

但从实际上来讲，很多情况下我们使用的 hash 算法没有那么地“强”，会导致分桶没那么地随机和均匀。比如几年前非常流行的 MurmurHash，也被 SipHash 的作者找到了攻击的方法，他们更推荐使用更强的 SipHash / HighwayHash。

还有就是均匀分布仅仅是统计意义上的期望，而不是实际的效果。比如我们有 1-10 十个数，用 hash 算法一定能保证把它们分到 10 个桶里，每个桶里 1 个数吗？

只不过大多时候，在统计意义上能保证基本的均匀，对大部分产品来说也够用了。

对于一些强迫症公司，或者用户数还没有达到统计意义上可分又开始早早做 ABTest 的公司，或者从数据观察的确存在较大的实验间干涉的公司，可能会做这样的一个事，人工构造层间正交分桶。

具体做法是这样的：先用 hash 算法（或其它抽样算法）将用户分成桶数的平方个最小流量单元，然后再选取这些流量单元组成每个分层。比如要构造 2 层，每层 3 个分桶的用户分层，先将用户分为 3*3 个流量单元，那么两层就可以这样构造：

Layer 1: [1, 2, 3] [4, 5, 6] [7, 8, 9]
Layer 2: [1, 4, 7] [2, 5, 8] [3, 6, 9]

可以看到第二层的每一个桶，都包含第一层里所有桶的 1/3 用户。通过精巧地构造来实现层间的正交分桶，可以有效地降低层间实验互相干涉的情况。

发版造成指标波动

当实验本身受到 APP 版本一定影响的时候，AB 分组可能会由于升级节奏不同，导致 AB 指标波动完全不可比。

举一个例子：如果新版本使用时长会上升 10%，正常情况下实验分组 A 比分组 B 使用时长上升 3%。那么如果分组 A 用户升级新版本占比 30%，分组 B 用户升级新版本占比 70%，结果会是怎样呢？

分组 A：70*1.03 + 30*1.1*1.03 = 106.09
分组 B：30 + 70*1.1 =  107  

分组 A 反而比分组 B 的数据更差！当然，这里为了效果，举的例子比较极端。实际的情况可能是在发版收敛期间，ABTest 的指标波动较大。

而且升级动作本身对活跃用户和非活跃用户有一定的筛选作用，产生的行为和数据也是有偏的，很难有完美的解决办法。避开发版收敛时段，或者对数据进行多维的分析和组织，也许有一定帮助。

结语

按照我以前的风格，这本应是一篇文章。但在信息快消时代，我发现自己也没耐心读长文了，所以就拆成一个系列发布了。

这篇文章主要从平台建设的角度出发，讨论了一些平台设计中要考虑到的关键功能点，希望能对读者有所助益。至于如何科学地进行 ABTest 实验设计和效果分析，不是我擅长的部分，就不再后续展开了。

上篇《ABTest 平台设计 - 实验开关和分组信息传递》简单介绍了 ABTest 实验开关和数据收集的一些实现，从流量划分、到实验开关、到数据收集，基本实现了 ABTest 的主要功能。下面则扩展谈一下 ABTest 的衍生功能：

基于 ABTest 的灰度发布

与 ABTest 一样，灰度发布也是圈出来一部分流量进行新功能的线上验证，验证基本能力没有问题之后再逐渐扩大覆盖面，支持扩展到全流量。

灰度发布本身也有很多种机制，例如最常用的：上线时先上单副本，再扩展到多副本，再扩展到单机房，再扩展到其它机房。这种方式非常自然，逐步扩量观察保证了服务稳定性。

但这样在上线的中间过程中，总不可避免地会出现一些用户体验问题。比如用户相邻的多次刷新请求被路由到版本不同的副本上，导致请求结果的跳变。

既然 ABTest 同样具备划分流量的能力，而且这种划分对于单个用户来说是稳定的，其实在很多情况下可以利用 ABTest 能力来实现灰度发布。

但基于 ABTest 的灰度发布，要求在架构上提供一些支持。

比如要发布新版本的网站静态文件（css/js 等），可以全量发布多个版本，然后通过 ABTest 圈定部分用户路由到新版本的静态文件，其余则路由到原版本的静态文件。

比如要发布新版本的服务程序，可以用新的 Docker 部署新版本程序，通过 ABTest 圈定部分用户请求路由到新的 Docker 上，其余则路由到线上的 Docker 上。

基于 ABTest 的灰度发布，很多情况下可以简化服务的部署和回滚操作，也保证了用户在灰度上线期间的体验稳定性。

服务好早鸟用户

在很多时候，企业的内外部总存在着一些早鸟用户，他们对灰度 / AB 新功能有着非常迫切的需求。

最典型的早鸟用户，就是公司的老板。当你开发了一个新功能，向上汇报了一下这功能多好多好。老板会问：

“为什么我没有看到这个新功能？”

你可能不得不解释说：

“老板你的 ID 没有被随机分到实验组里。”，

或者：

“老板这个功能只上了广州机房，北京访问不了。”

还有一种早鸟用户，是产品经理、测试人员，甚至可能包括提交 BUG 的外部用户。他们需要去回归新功能的线上效果是否达到预期，而且甚至他们需要一直不停地在不同的 AB 分支上切来切去比较效果。

这时候就需要一种灵活的机制，让这些早鸟用户有办法切换 AB 功能。

很多人最直接想到的方法，是在随机分桶之外搞一个 ID 分桶，收集上来早鸟用户的 ID，手动配置实验分组。这能在一定程度上解决问题，但设想这样的场景：

“老板，把你 UserID 发来一下，我给你配一下小流量实验。”

老板心里肯定在嘀咕，我要给了你 UserID，岂不是我看过啥发过啥你都能查出来了？这以后还能有隐私么？

而且配置 ID 的方式会增加运维的工作量，尤其是用户需要切来切去的时候。所以这时候不如提供一些强制命中灰度 / AB 的后门功能，能够大幅度降低沟通和维护的复杂度。

这种给早鸟用户的后门可以有很多种做法：

写 Cookie 机制。提供一个特殊的 URL，访问该 URL 就会种下一个强制命中的实验分组 Cookie，此后带着这个分组 Cookie 的访问都会中这个实验。这种适用于 WEB 端产品。APP 端使用的话，需要做一些 Cookie 同步工作。

配置注入机制。提供一个二维码，二维码内容是一段特殊的代码，APP 扫描到该二维码，就会被注入实验分组配置。这种适用于 APP 端产品。

隐藏功能机制。在某些内容上连续点 N 下，就会弹出一个配置面板，可以用来查看和调整当前所中的实验分组。

ABTest 平台如果能够提供这样的后门机制，将会大大方便与早鸟用户的沟通和合作。

下篇，我们聊一下流量分布问题。

通过上文《ABTest 平台设计 - 如何进行流量分桶》可以知道如何把用户流量科学地分配到不同的实验分组中，下面就面临一个问题：如何根据分组信息控制产品功能？

一种直观做法

最显而易见的做法，是直接在系统中传递分组信息，同时使用分组信息作为实验功能的开关。

比如说在服务端系统的接入层，通常是 Nginx 或者其它入口模块，对流量进行分组，为每个请求添加一个抽样分组字段，字段内容类似于 “Exp1Group1,Exp3Group2,...”。然后所有对下游的请求，都带着这个分组字段。那么下游的各个模块，都可以根据这个分组字段来决定程序逻辑。用伪码表示就是：

if 抽样分组字段 包含 Exp1Group1:
  do 实验1 的 A逻辑
elif 抽样分组字段 包含 Exp1Group2:
  do 实验1 的 B逻辑
else
  do 全流量逻辑

上面的伪码有些缺点，就是抽样分组信息 Exp*Group* 写死在了代码里，这样灵活性太差。所以，即使直接使用分组字段，通常也是将分组字段作为配置项写到代码里，这样更方便测试和部署。

客户端带来的挑战

在服务端直接使用抽样分组信息作为实验功能开关尚且可以忍受，因为一旦有问题调整下重新上线并不困难，但是在客户端 APP 中这样做就行不通了。客户端版本一旦发布，再想改动就面临着诸多的问题，比如发布审核周期问题，用户拒绝升级问题等等。

还有一个问题就是冗余代码和数据控制的问题。服务端功能 ABTest 转全以后，可以同时删除实验分组和对应的实验功能代码。客户端的实验代码是很难删除的，而且无法预判哪个分支会转全，所以没法直接删除实验分组。这会导致线上的实验越来越多，无法控制。

功能配置和分组配置分离的设计

回过头来思考这个需求：用户中了实验分组 A ，就走实验 A 逻辑。 其实可以加一层抽象：用户中了实验分组 A，就下发 A 对应的功能配置，实现走实验 A 逻辑。

就拿客户端 ABTest 来说，大实验可能是换一下 APP 版式，增加或者减少一个新功能；小实验可能是调整一下字体和字号，调整一下背景颜色或者图片等。其实本质上是控制一些功能的配置项。ABTest 可能会下线，但这些配置项会一直在产品中存在。

功能配置和分组配置分离还能带来很大的灵活性，也就是说云端可以创建新的 ABTest 尝试不同的功能配置组合，而不需要硬编码固定的 ABTest。

假设你本来有两个实验，标题大小实验和内容大图实验。如果硬编码情况下，你只能做原始实验方案的对比。如果用功能配置的话，等这两个实验完了，你还可以实验不同标题和内容大小图的结合实验，这是不需要再开发和发版的。

当然，动态配置在工程上如何更合理地实现，也是一个值得探讨的话题，这个留待以后再说。

实验分组信息记录

做 ABTest 的目的，主要是为了收集用户对实验的反馈，方法则是查看不同分组下用户数据指标和用户行为的对比和变化。这些数据的记录，往往是靠各种系统日志。

一种比较原始的办法，是用系统日志跟用户中实验分组的时间信息去 join，来区分 AB 分组。比如用户 A 在 1 号到 10 号分到了 A 分组，那么可以认为该用户 1 号到 10 号的日志都属于 A 分组，用来统计 A 分组指标。

这种方式存在着明显的缺点：一是实验的开启和关闭点不会是整点，而进行精确到秒的日志时间 join 成本太高，很多时候不得不抛弃首尾两天不足整天的用户日志；二是用户中实验分组在产品上的生效往往不是实时的。尤其是在客户端上，用户正在用一个功能的时候，很难瞬间将该功能切换成另一种样式，往往是在用户在下一次重入初始化的时候才开启实验样式，否则很容易引起崩溃。

对统计更友好的分组信息记录，是在每条关键的系统/客户端日志中都添加分组信息字段。这样虽然增加了一些冗余信息，但会使所有的关键数据记录都有实验分组这一列，用它做筛选即可进行指标的对比和用户行为序列的分析。

小细节：分组编码

上面谈到每条日志中都要记录用户所属的实验分组信息，这种冗余程度要求分组信息有着非常集约的编码设计，才能尽量减少传输和存储的数据量。可能的选择有以下几种：

• 奔放派 ：直接使用实验名+分组名作为分组信息。比如一个用户中了两个实验的不同分组，那就是：“ExpTitle_GroupA|ExpImage_GroupC”。奔放派的好处是日志可读性很高。
• 婉约派：将实验名和/或分组名精简为两个 ID，形如：“10010_1|10080_3”。好处是虽然可读性低了些，但毕竟直观。
• 理工派：将实验名和分组名精简为一个ID，形如：“12345|14523”。对于理工科思维来说，只要 ID 不重复就行，为啥要分成俩字段？
• 极客派：将 ID 用 62 进制表示，形如：“3d7|3Mf”。这个世界上，只有麻瓜才用 10 进制。
• 抠门派：将 ID 数组用 protobuf （varint）表示，有时候需要 base64 一下，形如：“算了举例太费劲”。好处就是一般人看不懂。

当然，可能还有其它的组合，大家意会就好了。

下篇，我们聊一下灰度发布和早鸟用户。

在 2018 年，我相信 ABTest 这个名词已经不用过多地解释了。但我发现很多公司，尤其是初创企业，虽然能理解这件事是什么，却不知道这件事该怎么做，以及该怎么做好。

这一系列文章，就是想讲清楚在设计具体的 A/B 测试平台这种基础架构时，要考虑哪些问题，以及有哪些推荐的做法。

今天先谈一谈：

如何进行用户分桶

我们都知道互联网产品的 ABTest 主要是围绕用户进行的实验，从统计意义上观察用户对不同的产品设计、交互体验、业务流程的反馈，从而指导产品的改进方向。

那么很重要的一点就是，怎么圈定哪些用户进行 A 实验，哪些用户进行 B 实验。

一种错误做法

在我工作过的一家公司，他们是这样做的：

“使用用户的 UserID 对 1000 取模分成 1000 个桶，然后选择不同的桶分配给 A 或者 B。”

我问研发人员为什么这么做？他们给的理由是：

“UserID 是自增 ID，跟用户注册顺序有关，有一定的随机性。可以保证用户随机地分到 A 或者 B 中。”

A/B 的流量圈定的一个重要原则就是无偏，不然无法进行对比评估。上面的做法看起来倒也有一定的道理。（还常见的一种做法是，用手机尾号最后一位来进行分桶，优惠多少就看你手机尾号是否运气好了 ^_^ ）

单单考虑孤立实验，这样做也无可厚非。但如果考虑到长期交叉、连续的实验，这样做有很大的问题。

首先，这种设计只能进行单层实验，也就是说一份流量只能通过一个实验。

如果实验人员选择了在任意一个桶中同时进行 X, Y 两个实验的话，那两个实验的结果就会相互干涉，导致最终结果不可信。例如：在尾号为 001 的桶里进行了两个促销活动“降价10%”和“满100减10块”的实验，最终 001 桶的用户订单数比其它桶高，那到底是哪个促销更有效果呢？

其次，这种设计在长期会造成桶间用户行为有偏。

也许刚开始因为其随机性，桶间用户行为差异很小。但第一个实验过后，桶间就开始有了行为差异——这也是 ABTest 的目标。N 个实验过后，桶间行为的差异可能就变得非常大了。

比如你总是在 001 桶的用户上实验幅度较大的促销活动，那么 001 桶的用户留存就会显著高于其它桶。那实验人员为了让实验效果更好看，可能会偷偷地继续选择 001 桶进行实验。

最后，这种设计的实验效率太低。因为一份流量只能通过一个实验，无法对流量进行充分的利用。

那该如何设计用户分桶，才能满足 ABTest 的需求呢？

一种正确方法

目前业界应用最多的，是可重叠分层分桶方法。

具体来说，就是将流量分成可重叠的多个层。因为很多类实验从修改的系统参数到观察的产品指标都是不相关的，完全可以将实验分成互相独立的多个层。例如 UI 层、推荐算法层、广告算法层，或者开屏、首页、购物车、结算页等。

单单分层还不够，在每个层中需要使用不同的随机分桶算法，保证流量在不同层中是正交的。也就是说，一个用户在每个层中应该分到哪个桶里，是独立不相关的。具体来说，在上一层 001 桶的所有用户，理论上应该均匀地随机分布在下一层的 1000 个桶中。

通过可重叠的分层分桶方法，一份流量通过 N 个层可以同时中 N 个实验，而且实验之间相互不干扰，能显著提升流量利用率。

从实操上来说，我们通常采取下面的方法：

首先，确定 Layer，确定请求 Tag。例如从 UserID，DeviceID、CookieID、手机号 中选一个，支持匿名流量的，一般会选用 DeviceID 或者 IMSI 等作为请求 Tag。

然后，选一个你喜欢的 Hash 函数，尽量选个使用方便、随机性更强的；

最后，通过 Hash(Layer, Tag) % 1000 确定每层分桶。如果 Hash 函数支持 seed，那么使用 Layer 作为 seed，否则作为 SALT，即将 "Layer+Tag" 作为输入参数。

在完成分桶以后，还可以进行一定的流量筛选。例如来自北京和上海的用户，可以允许分别进行不同的实验。

可重叠分层分桶方法的系统性介绍，可以参见 Google 在 KDD 2010 发表的论文 《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》，感兴趣的同学可以延伸阅读一下。

更多样的选择

但分层方法并不能让所有人满意，尤其是对并行实验非常多的大公司来说。因为同一层可能有不同份额的其它小流量实验在线上，新实验能够拿到的流量非常有限，需要等待同层其它实验结束，会非常影响迭代效率。而新实验未必一定会修改其它实验的参数，或者影响其它实验的效果。

所以一些公司也逐渐开始探索无分层，也可以称为无限分层的方法。具体的做法是，每个实验都可以看成独立的层，只保证层间流量分桶的正交性，所有的实验都可能存在重叠情况。

这样做用户就有大概率同时中同一类实验，例如两个实验人员同时在实验 UI 布局，实际上用户只能看到一种布局（因为代码分支有先后逻辑），那么实验结果就不可信了。

由于系统上无法保证实验间不冲突，那么只能从组织上来避免冲突，或者从数据上尽早观察到冲突的存在来解决冲突。这对组织的管理能力和企业的数据能力提出了更高的要求。

下篇，我们聊一下实验的开关和分组信息传递。