复盘：从 0 到 1 设计 A/B测试系统

ManyHong 2023-07-22 19:09:14

不知不觉拖更了好久，后台被催更了好几次，前阵子比较忙，在给某四大银做一个私有化的系统，再次实践后又对相关系统有了新的认知，趁着热乎这期就先来讲讲 A/B测试系统吧。

虽然目前已顺利上线投产，但回想当初实在找了很多资料，包括书籍论文、相关产品使用资料，以及产品和开发者社区。资料虽然不少，但还是存在2 大问题，要么过于理论化以至于难以实操落地，要么就是过于靠近产品功能的介绍以至于对于产品背后的逻辑理解得不够深刻，整体都不够体系化（毕竟要深入和体系化讲解篇幅是很长的，这事就交给我吧）。

因此笔者希望本文能对此有个补充，写本文的主要目的在于希望能将理论和实际产品设计结合得更加紧密，帮助大家抓住设计的重点，对于比较深入的统计学原理不会过多涉及，仅用于辅助理解系统，如有深入学习兴趣的读者可自行研究。

当然，因为笔者现在做的是saas产品，所以在产品形态上是一个 saas系统模块，读完如觉得笔者理解不到位或偏颇之处，欢迎指教。

01 全文内容概要

说实在的，写这么一篇文肯定篇幅会比较长，所以对全文内容做个基本介绍还是比较有必要的。

对于互联网人而言，A/B 测试应该耳熟能详，即使没用过绝大部分也听过，但正常来说如果没接触过，很多人的理解可能仍停留在初中生物时学到的“对比实验”。因此先介绍系统背后的基础原理还是十分必要的，也能帮助大家更好地理解系统设计背后的目的所在，全文展开的节奏如下：

介绍 A/B 测试背后的统计学原理和试验流程，抛出系统的定位，帮助大家理解系统设计的目标；
结合对 3 大类涉及 A/B测试功能产品的调研，对背后不变的产品逻辑和系统架构进行抽象总结，帮助大家明确各个关键模块及作用；
在设计系统各个关键模块时，需要重点考虑的地方，属于落地实操部分，帮助大家看完后能知道应该具体该怎么开始设计。

02 A/B测试背后的统计学原理

1. 基础统计学概念

某度对于统计学的定义是：

统计学是通过搜索、整理、分析、描述数据等手段，以达到推断所测对象的本质，甚至预测对象未来的一门综合性科学。

联系到A/B测试，其实它就是通过先对部分用户设置不同的方案，并进一步对不同方案的数据进行分析，从而去推测哪个方案在全量发布后效果是更优的，在这个过程中有必要介绍下几个基础的统计学概念。下面以一个 case 为例来说明，假设现在希望看下改变按钮颜色能否提高落地页中的按钮点击率，在这个试验中涉及：

总体：落地页的全部访客，不仅包括试验时访问的那些，也包括后续访问网页的，绿色按钮、红色按钮分别对应 2 个总体；
样本：在访问时随机分配了不同颜色按钮的访客，对应颜色的按钮分别对应着一个样本，这些样本是总体经过抽样产生的，通常在统计中只有样本量足够大，才能更好地确保实验结论的有效性，所以 A/B测试系统会提供样本量计算器，告诉用户试验应该达多少样本量或运行多行时间才能得出相对有效的结论；
抽样：有多种抽样方法，包括简单随机抽样（有放回抽样、无放回抽样）、分群抽样、分层抽样，核心是要在随机原则下从总体取出样本，并且具有代表性（样本能够代表总体）；
总体参数：描述总体特征的参数，在示例中是按钮点击率
统计量：样本统计计算后得到的统计数值，在示例中是样本的点击率；
参数评估：指用样本统计量来估计总体参数，这里我们通过对比试验的2 个样本间的数据，从而评估方案调整后针对全部用户的效果。常有包括点估计和区间估计 2 种方式，一般我们使用的是后者。这也很好理解，当我们统计出样本的点击率是 20%，如果这时候说确定采用点击率更高的按钮颜色后，点击率大概是20%，这便是点估计，显然它的误差是非常大的，所以我们在估计是会给出总体参数的一个概率范围，即有多大的可能落在某个范围，比如说有 90%的可能提升 10%~20%，显然这样的估计就会更加准确科学，通常我们称之为“置信区间”，这个区间的计算有一定的方法，大部分 A/B测试系统都会给用户提供这个参数以供参考。

2. 假设检验试验

结合上文提到的落地页按钮点击率试验，假如现在通过一周的试验，我们发现绿色按钮比红色按钮的点击率更高，但事实真的是这样吗？

不，其实我们提出的只是一个基于试验样本的“假设”，但我们其实更想知道的是“总体参数”，当所有按钮都改为绿色后，最终针对所有用户所统计到的结果也不一定就是我们在试验中得出的结论。

所以，为了提升结论的可靠性，我们会基于对这个“假设”进行“检验”，看看这个“假设”在应用到“总体”时是否靠谱。

怎样检验呢？

统计学提出了它的解决方案：小概率反证法，即统计学中认为小概率的事件很难发生，我们只需证明某个假设发生的概率小于某个值（通常取 0.05），这个值在统计学中称为显著性水平，如果概率小于这个显著性水平，我们可判断为这个试验在统计上是显著的，就可以有一定的把握认为这个假设不会发生，大部分 A/B测试系统都会给用户提供这个参数以供参考。

通常情况下，在进行试验时我们往往并不知道新提出的方案对于原方案而言是好是坏，所以我们常常假设“原方案（对照组）”和“新方案（控制组）”是没有差异的，当我们证明这个假设小于显著性水平时，就可以有一定把握可以说原方案与新方案是有差异的，结合样本数据结果我们就可以获得一个相对可行的试验结论。

PS：上面介绍到的原理部分，为降低理解成本，没有对统计学背后的一些更底层的数学原理进行说明，也没有对假设检验中的基础概念做解释，比如原假设与备择假设、弃真与取伪错误、单侧与双侧检验等，有兴趣的读者可自行了解

小结

AB测试系统只是站在上述理论的基础上进行了产品化，有了理论基础，我们才能够在系统中通过各个功能去确保试验的有效性，简单的对应关系：

抽样：系统需提供科学的分流算法来确保试验有效性；
统计量：系统需要建设好基础的数据埋点和数据统计能力，才能完成统计量的计算；
假设：系统需提供试验方案的编辑管理能力，让用户能够创建不同的试验方案，从而形成试验假设；
置信区间、统计显著：系统在提供试验样本统计量数据外，还需基于试验统计量类型，基于不同的检验计算方法去计算出统计指标，通常为置信区间以及试验是否统计显著。

03 系统核心业务流程

AB测试系统核心的业务流程当然是围绕试验的设计和分析进行的，同时笔者调研了业界多个 AB测试产品，各家产品在使用流程上也相差无几。但不同的产品也提供了一定的方法来提升流程的效率，在设计时需要多考虑系统应该通过提供什么样的能力来支撑这个业务流程，以及怎样才能够帮助提升流程效率，帮助运营者更快更准确地得出结果。

复盘：从 0 到 1 设计A/B 测试系统

业务流程图

结合一个具体 case来说上述业务流程，还是采用上文的例子，现在是希望提升落地页的按钮点击率。

确定改进点：按钮样式；
设计不同方案：设计了绿色和红色两套方案；
确定衡量指标：按钮点击率；
配置试验：配置按钮颜色为绿色、红色共两套落地页；
分析试验数据：对比哪个方案的按钮点击率更高，是否统计上是显著的；
如果发现红色按钮比原来绿色按钮的点击率还差，则可决定中止试验不继续优化，或更改为其他颜色继续试验；
如果发现红色按钮和设想一样比原来绿色按钮的点击率更好，则可考虑将按钮颜色彻底改为红色。

04 系统目标

在设计系统时，我们通常会先定义系统目标并拆分阶段重点，读过 google 相关论文的读者也会发现 google也结合自己的情况给出了系统的目标：

更多：google数据驱动的文化使其对试验运行数量的要求比较高，要求系统能够支持同时运行更多的实验；
更快：简单便捷地创建试验；
更好：能够去规避无效实验的运行、、发现有效但不好的试验、能够提供标准的衡量维度确保对比是有效的。

笔者在设计自家系统时则定义如下：

（1）要能确保试验有效性

确保试验有效运行：确保分流规则、统计指标计算规则是科学的；
让用户确保试验有效：引导用户确保样本量符合要求或提供样本量计算工具、提供置信区间和统计显著性指标辅助用户进行判断。

（2）能支撑到更多有需要的试验场景

让试验进行得更快速；
能够帮助用户更快地得出结论（意味着不用耗费更多流量）：部分系统提供 MAB算法自动分配各个版本的流量，帮助用户简化分析的过程，并在得出优胜版本能够自动全量应用。

（3）更便捷快速地完成配置

指使用者能够有较低的使用和学习成本，A/B测试本身需要比较专业的背景知识，在互联网企业内部往往是增长团队和产品经理等角色负责。但笔者所设计的系统面向传统企业以及一些有IT部门的企业，企业内是否有配置专业的人员来实施，是否有对A/B测试比较了解的人都是问题。所以产品设计上一方面需要考虑易用性，另一方面也需要考虑让交付同事能更好地理解以便引导客户使用。

05 系统架构

结合笔者调研的结果，目前会涉及到AB测试系统的公司主要有以下几类：

（1）AB测试服务saas软件供应商

以saas 化形式提供AB测试能力，客户基于简单对接后即可基于平台能力进行 AB测试，能够有效降低企业自己的开发投入，企业体量没达到一定规模时或相应的团队建设没到位的情况下往往可采取这种方案，这些供应商可能同时也会提供其他数据分析平台等其他数据服务，针对的目前客户以有互联网相关业务、有 IT研发能力的企业为主。

（2）提供 AB测试能力的其他saas 平台

比如营销 saas 产品主要针对的营销场景下的 ab 测试能力提供、用户运营 saas产品主要针对消息推送场景下的 ab 测试能力提供。

（3）需自建 AB测试系统的企业

这类企业的公司体量基本都到了一定的规模，并且有专业的增长团队。

在产品形态上，目前在不同类型产品上看到的总共有 3 种形态：

AB测试saas产品一般均以试验管理的形式，在试验报表中查看 AB测试相关数据；
营销 saas 产品则会与营销流程编辑器结合，以流程组件的形式提供AB测试能力，在流程数据中查看 AB测试相关数据；
垂直场景的用户运营工具则是在以高级配置的方式提供AB测试能力，比如可在业务功能配置中通过额外的AB测试配置项完成配置，并在业务数据中可查看 AB测试的相关数据。

但抛开具体的产品形态，由于系统背后的原理、业务流程和目标都相同的，所以经过抽象后的系统架构其实是差不多的，仅在一些细节方案上有差异。

复盘：从 0 到 1 设计A/B 测试系统

系统架构图

1. 业务层

这一层是AB测试的核心功能模块，用于支持用户创建 A/B 测试试验。

1.1 样本设置

用于设置进入试验的客户，主要涉及 2 点：

（1）样本筛选

可筛选特定类型的客户参与试验，可与CRM、用户画像系统相结合，可针对某一特定人群进行试验。

（2）样本量设置

可设置客户进入试验的占比或数量，样本量对于试验有效性有着重要影响，大部分系统都会提供一个样本量计算公式，结合用户设置的预期提升效果，告知用户较合适的样本量是多少、试验应该进行多久，让用户确保试验有足够的流量（也看到一些产品会提供一些经验值给到用户，比如让用户确保样本数量应该大于 1000）。

1.2 流量分配

主要作用是决定客户命中哪个试验、命中的是试验的哪个版本，这块跟试验的管理结构有关系，分流模块需要满足以下要求：

（1）随机均匀分流

分流规则是系统中比较核心的模块，有几个核心的点：

必须确保样本一致性：确保分配到不同试验方案的用户样本特征是一致的，在统计上控制单一变量原则，即所谓“随机均匀”；
确保分流一致性：在分配到不同版本时应确保随机均匀分布，并且确保分流一致性（即同一客户多次进入同一个试验，访问的试验版本相同）。

（2）分层分流

当需要同时进行多个试验，且避免试验间会互相干扰时，需要通过分域的形式把一些会互相干扰的试验区隔开，用户只能命中其中某个试验，通过分层的形式把不会互相干扰的试验区隔开，用户可以同时命中不同层的试验，通用的 A/B 测试工具都会支持用户自定义层级规则和试验所处层级。但也并非必需，需要结合自身系统场景看是否有并发多个试验的场景，可查看下方分流模型示意：

复盘：从 0 到 1 设计A/B 测试系统

分流模型图（来源网络，如有侵权请联系删除）

分流指定版本：在试验结束后，用户可直接指定进入试验的客户进入哪个试验版本，为了提升流程效率，大部分产品提供了自动帮助客户选择最优版本的能力，但大部分只能从单个指标维度进行评判；
自动分流：基于MBA算法，可自动结合不同版本方案的试验指标，自动调整流量分配规则，帮助快速选择出可信赖的优化版本，可有效提升试验的效率，目前有提供该能力的主要是一些比较专业的 ab 测试工具。

1.3 试验配置

（1）版本设置

可添加不同的试验版本，与对照组版本进行对比，不同类型试验版本设置会有所不同，同时设置方式也与具体的 A/B测试场景有关，比如：

大部分系统针对 UI层面的优化会提供可视化编辑模式，可让运营人员直接在可视化界面完成不同方案的配置；
针对广告着陆页场景，则会提供的是链接合并跳转的模式，针对不同版本的广告着陆页提供不同的URL，用户访问时会随机跳转到某个版本的链接中；
针对算法优化等后端优化场景，则提供接口给后端服务调用。

这一块也是需要具体考虑，需结合业务场景和自身平台的情况考虑用户配置版本的方式。

（2）流量设置

即设置分配给各个版本的流量，总和需为100%，需要支持在试验中进行调整，方便使用者结合试验情况灵活调整流量分配（一般会先给试验版小流量试跑，然后再进一步加大流量）。

（3）指标设置

设置指标后可在数据统计中看到不同版本对应的指标数据，用于评估不同版本的效果：

主要目标与附加目标：评估方案好坏有时候显然不可能只从一个维度去评估，并且即使新版本方案在核心指标上表现更好，也不排除在其他比较重要的指标维度上表现更弱，所以主要目标是指本次试验重点要关注优化的指标，附加指标则是其他关联的效果指标，可帮助我们进一步全面地评估方案；
复合指标与自定义指标：可支持更多的业务场景；
自定义指标：指用户可以自定设定指标，可指定更多事件指标以及复合型指标，本期暂不考虑。

（4）分层分域

本质上是为了解决流量在多个试验的分配问题，考虑的是如何尽可能地分配流量确保每个试验都有足够的样本，以及如何避免试验之间互相干扰，这些层和域需要结合自身情况去做划分，常见的可划分为启动层、UI层、算法层等。比如对于页面中同一个区域进行试验，如果现在在进行 2 个试验，分别对文字颜色、文字背景做测试，假设不把这 2 个试验分配在不同域，那可能出现文字颜色和文字背景都是同一颜色，会导致在前端完全不可见，进而影响试验。

2. 数据统计层

这一层会展示试验数据，包括试验设定的各个指标数据以及统计数据，使命是帮助用户更准确和快速地进行决策，选择最优的方案，其中统计类指标主要提供 2 个指标：

一个是置信区间，通常采用的是置信度为 95%的区间，用于帮助用户科学评估方案效果；
另外一个是统计显著性指标，用于告诉用户当前统计得到的结论在统计学上是否是显著有效的，提升决策科学性。

当然，有时候会需要去细分到不同人群去看效果，可以进一步评估方案在不同人群中的效果是如何的，在产品上只需增加一个客户筛选即可。

3. 数据接入层

这一层主要解决试验指标统计的问题，与 AB测试系统的应用场景相关，要拓展系统使用场景，肯定是得垂直地从数据埋点、试验设置都进行拓展，通过同步外部数据，可以大大拓宽使用场景，比如笔者设计的是营销 saas 系统，如果能对接交易数据，场景可以进一步拓展为“验证通过更低的优惠券折扣是否可促进交易转化率”。

4. 服务接入层

当企业内部有多个客户端、多个系统、多个场景需要对接 AB测试能力时，通过标准接口可快速完能力的部署，有助于可以提升系统的扩展开放性。

06 业务场景

当我们对系统要做的事情以及系统的整体逻辑有所理解后，就需要因地制宜结合自己负责系统的业务场景、客户特点等因素设计产品的能力分布和形态。

当然，场景肯定是没法遍历完的，但可以记下一句话：“当你无法衡量它时，你就无法优化它”，结合上文对系统架构的介绍，我们知道A/B测试系统底层需依赖数据埋点这一基础设施，当我们能埋的点，能统计到的数据越多，能调控的变量更多，系统能支撑的场景也就越丰富。

但笔者还是对常见的AB测试场景做个简单总结，方便大家参考：

产品优化
UI层面优化：比如调整页面布局，调整文案等
功能体验优化
算法层面：比如推荐规则优化、列表展示规制，提高内容点击率
营销优化
广告落地页：营销文案优化，提升按钮点击率
营销活动流程、策略优化等等

其中 AB测试saas 产品无可置疑肯定基本都可满足上述场景，营销saas产品中则会围绕活动内容、消息触达、权益策略、活动流程等营销相关的场景做优化，垂直类场景仅支持自身产品场景的优化，比如“某策”能进行触达与否是否影响最终转化的 ab 测试。

07 落地细节注意

1. 分流模块

分流算法的实现方法网络上大把，推荐大家可以参考一下 google 的论文，具体实现上就是通过一致性哈希算法计算用户 id 、层 id 后进行取模即可，这样既可实现上文我们提到对于分流需要注意的关键点。但这里需要注意的是要结合我们设计出的产品形态，与上文的产品架构进行对应，考虑需要加什么因子加入哈希算法因子中。

当然，一些平台为了确保样本的一致性也提出了一种验证性的方法，比如微博广告系统提到的一个解决方案：

在广告系统中，用户是通过多维的画像向量（a,b,c,…,n）来进行刻画的，如果流量划分是均匀的，意味着用户的每一个画像向量分量在该流量划分条件下是均匀，更进一步，多个画像向量分量的组合在该流量划分条件下也是均匀的。通过进行用户画像向量单个分量和若干个画像向量分量的组合的均匀性验证，即可来反映该流量的划分的均匀性。