a*算法流程图_如何从0开始，搭建A/B test平台产品？

一、什么是A/B test

A/B-test，本质就是对照实验。为同一个目标和假设，设计A、B两个方案。从一波用户中，随机分为A、B两组，A组用A方案，B组用B方案。上线后，验收两组实验的数据情况，从而判断哪一组的效果更优。

A/B-test在国内互联网中的应用越来越普及，成为互联网进入精细化迭代和运营的核心方法论。

二、没有平台化的A/B-test 如何进行实践？

个人所在创业公司，在业务早期，没有平台化的时候，就开始粗暴地进行A/B-test。以一个简单case为例，阐述一个实验过程。

Step1. 确定实验内容

基于同一个目标，策划了①、②、③、④组实验内容。

Step2.放量策略

4组实验，分为9个实验组和1个实验组，针对某日注册的新用户，进行尾号0-9的分割，进行分流，由服务器控制版本下发。

Step3.上线收集数据

建立一张用户-实验组别的维度表，根据埋点日志 join 维度表，手动跑sql查询关于用户行为、次日留存、7日留存的数据。

Step4.根据结果判断next step

根据实验结果，判断相关的实验线下或者开放全量。比较难的问题是，如果测试的产品功能差异较大，如何进行版本兼容是个比较大的问题。

此外，客户端版本直接的管理，是根据各个独立版本进行服务器控制。没有进行用户版本记录和版本回滚，后续版本变多，可能会存在管理混乱的风险。

三、暴露的问题和平台产品解法

2.1 放量策略

现在使用的策略是这样的

对当日新增注册的用户，进行尾号0-9的分割，直接分配给10个实验组

当问到为什么这样的时候

UserID 是自增 ID，跟用户注册顺序有关，可以保证测试的随机性。

A/B-test的放量策略，一个重要原则就是随机无偏，不然会存在误差。

这样的实验做法，确实可以满足单个实验中的随机性。但如果考虑到长期繁杂的、交叉的、连续的实验，会出现问题：

第一，这种策略只能进行单层实验，对实验的流量分配的灵活变动非常不友好。

中途想要对某些实验扩容，对某些实验缩容都不可实现

其次，这种策略在长期会造成实验组间用户行为有偏。

刚开始因为其随机性，实验组间的用户行为差异很小。但第一次实验过后，某个尾号（某个实验组）就会产生行为差异，这种差异如果直接和某个尾号关联，可能直接会对后续的实验产生影响

那该如何设计用户分桶，才能满足A/B-test 的需求呢？

目前业内，对于A/B-test的流量策略，基本是基于google的论文Overlapping Experiment Infrastructure: More, Better, Faster Experimentation

总结来说，就是存在一个域和层的概念。不同域之间互斥，同一个域的不同层正交

具体来说，根据实验类型，从修改的系统参数到观察的产品指标上的相关性，将流量分成可重叠的多个Layer。例如 UI 层、推荐算法层、广告算法层。各个层之间的实验结果和观测指标独立，不存在相互影响的可能。

流量分层后，针对每个层中的流量，选用不同的随机算法，保证流量在不同层是重新打乱随机分发的。

用户分流，一般以用户维度分流，这样可以保证单一用户每次进来看到的是相同实验，不会造成体验上的不一致：

实验的 Hash 因子有用户唯一标示（通常是cookie，UID，手机号等）、策略ID、Layer ID，根据具体需求，可以选择多个因子组合后 Hash。

HashID=Hash(用户标示，策略 ID，Layer ID)%100+1

每个用户会分配唯一的 HashID，同时会落在[1，100]的范围内，让用户随机均匀散落在这个范围内。配置实验时，根据实际需求，为各个版本均匀切分流量。譬如A版本划分20%的流量，则 HashID 从 1-20 的用户被划分到 A 版本。

2.2 数据收集

现在在数据收集上，使用的方法是

用户和实验分组建立一张维度表，针对核心指标，基于系统日志跟用户-实验分组的维度表去 join

这种方式存在着明显的缺点：，一方面需要手动写sql取数，join的复杂程度比较高，对于业务方（通常是产品或运营）的要求太高。

另一方面，扩展性比较差，目前只针对新注册用户做实验，一个用户在生命周期内，只有一个实验分组。当后续实验拓展，用户和实验分组间按精确到秒的时间来分配，join的复杂程度更高。

再有一方面，用户中实验分组在产品上的生效往往不是实时的。尤其是在客户端上，用户正在用一个功能的时候，很难瞬间将该功能切换成另一种样式，往往是在用户在下一次重入初始化的时候才开启实验样式，否则很容易引起崩溃。

针对该问题，更友好的解法，是在日志上报时，都带上分组信息参数。这样虽然增加了一些冗余信息，但会使所有的关键数据记录都带上分组信息，作为筛选的参数更加便捷。

2.3 数据分析

在某个案例的实践中，业务方获得数据如下

一般的测试owner拿到数据后，直接算出各个实验组之间的转化率差距，然后就做决策。

但这样的做法，忽略了A/B-test的本质，是一个抽样实验，在统计学角度上，样本代表全体始终存在着统计显著性的问题。在一定程度内的数据差别是正常波动，并不能说明某个版本更优。通常A/B-test会进行显著性检验，计算P-value。

关于显著性检验的原理和方法，在之前的文章中介绍过了。

可以查看“一文解析：A/B-test里「显著性检验」的原理方法和实操案例”

2.4 版本回滚

客户端版本直接的管理，是根据各个独立版本进行服务器控制。没有进行用户版本记录和版本回滚，一般的参数配置回滚都是单值的回滚，但是存在多个表的情况下没有办法这么简单地去回滚，后续版本变多，可能会存在管理混乱的风险。

针对此问题，以美团为例，设计一套回滚模型如下：

首先在配置发布时，会将所有修改的表名、列名、列类型、列新旧值、修改类型存入表中。
回滚时获取上次发布的所有修改的表名、列名、列类型、列新旧值、修改类型，反向操作数据库，达到回滚的目的。

回滚模型

四、总结

从A/B-test的功能模块来看，大概有以下三个：用户分流服务、A/B test 配置、数据统计、（版本回滚非必要）。实现流程图如下：

针对此，平台产品重点需要策划的核心在于：

实验创建和人群分组管理
流量分配管理
实验绑定指标和指标上报逻辑
统计指标和显著性指标

参考资料：

Overlapping Experiment Infrastructure: More, Better, Faster Experimentation

ABTest 平台设计 - 如何进行流量分桶

ABTest 平台设计 - 实验开关和分组信息传递

ABTest 平台设计 - 灰度发布和早鸟用户

ABTest 平台设计 - 流量分布问题

沪江ABTest测试平台实践