一、AB平台简介

AB实验平台这几年在互联网公司得到了越来越广泛的应用，采用AB实验来评估产品和技术迭代效果也成为主流的业务新功能效果评估方式，数据驱动的文化在这几年得到了不少公司的广泛的认同，通过数据和指标来说明产品效果也得到了越来越多的公司的认可和应用。

AB实验在其中就是一种很常见的产品效果数据评估工具，在各大公司的产品迭代过程中也得到了越来越广泛的应用。

二1.0 时代 从无到有

在AB实验刚开始的时候，需要解决的问题很简单：

通过某种用户流量分组方式，将不同的用户划分到不同的流量组，在不同的流量组通过控制变量的方式应用不同的产品策略，随后观察两个组的产品效果差别。

这种非常朴素的实验思路就是最基本的AB实验的分流，需要注意的是在过程中需要保证控制变量和稳定的流量比例。

一个基本AB实验实例

图片

一个基本的AB实验需要有以下要素：

1. 实验目标和实验假设

实验目标决定到达到什么样的效果实验才算成功，举个例子，我希望付款率提升5%，这就是目标，其中的实验指标是付款率，做实验之前一定要有实验目标，没有实验目标没办法确定实验是否成功，实验目标包含指标和变化幅度两个要素。

实验假设是猜想通过控制哪些因素来达到实验目标，比如我们假设付款按钮的颜色会影响用户的付款意愿进而影响付款率，那这里的实验假设就是付款按钮颜色会影响用户付款意愿。

2. 实验对象（实验对象是可以用来应用策略的用户或者请求或者其他对象）

3. 实验对象并不是仅仅指用户，用户的每一次请求也可以单独做实验，甚至每一次用户请求的每一个曝光位置都可以看做一个实验流量，这个对象取决于具体的业务。

4. 对照组和实验组（AB实验的核心要求是控制变量做效果对照，所以至少有一个或多个对照组策略和实验组策略）

5. 对照组：一般是没有任何策略的组，代表了现在的实验效果。

6. 实验组：一般是应用了新策略的组，代表了新策略的实验效果。

7. 统计功效：在进行实验组和对照组的流量分配的时候要注意，因为我们的AB实验是从整体用户中取一部分进行实验，然后采用统计学方式进行效果评估，所以无论是实验组还是对照组样本量要满足最基本的统计功效，后续的实验才有意义，而统计功效无法在实验之后计算，需要我们在实验进行之前就做充足的调研。

算法的AB 1.0主要功能

1. 通过控制变量的方式进行AB分流实验，并通过离线的模拟分流规则提供用户实验分组信息，使得数据分析可以计算实验的指标报表。
2. 打通基本的工程实验链路，可以让算法通过实验配置自主的控制实验流量和实验策略。

1.0 AB实验的策略生效流程

在早期的实验过程有以下链路：

• 通过配置中心配置约定好的AB实验配置信息，线上的服务通过配置中心的变更信息，实时变更实验配置，从下次分流开始应用新的分流策略，同时记录实验日志。
• 报表计算方式，将实验配置信息同步到ODPS，第二天用前一天的实验配置对昨天的用户进行重新分流计算，获得昨天的用户实验分流信息（之所以这样是因为实验变更是以天为单位，离线计算可以比较方面的支撑后续的实验分析）。

算法和普通业务的AB分流由于业务特性原因有较多的需求不同的地方，针对两者区别我们也进行了一些特殊的算法实验优化设计。具体如下：

图片

早期的AB实验设计解决了基本的实验分流问题也提供了一套配套的实验指标和实验置信度计算方案，支撑了早期的简单业务可以通过AB实验的方式比较科学的观测算法模型效果。

三、2.0 时代 从有到全，支持复杂业务功能

新的业务需求

随着公司业务发展和各个系统迭代优化，用户对于基础的AB实验系统开始衍生出了一些新的，更细化更复杂的业务需求，用户也希望AB系统可以帮助支撑更高效的实验迭代。

• 流量饥渴，更丰富的流量需求：在1.0版本的AB实验中已经解决了基本的实验分流和配置的问题，但是由于一个场景中总用户流量有限，可能会有多种业务实验同时进行，实际实验运行时需要在同时运行的实验数量和每个实验的流量大小之间做一个取舍，业务高速发展时期经常会有用户希望提高同时运行的实验数量，同时保证每个实验有充足的流量，于是我们扩展了原来的实验流量分流模型设计，采用分层分域的正交的业务实验划分方式来支撑上述的流量需求。
• 更实时更准确的实验报表：在早期的实验中通过第二天的配置重算的方式得到前一天的用户实验分组数据，这种方法可以支撑非常巨大的用户和实验数量，但是时效性上比较难以保证。随着业务快速迭代，算法的实时实验效果监控的需求也逐渐增加，离线的实验报表计算反馈需要等到至少1天后才能观测，实验反馈周期太长。于是我们调整了实验分流和报表的计算链路，采用实时实验日志埋点通过flink等实时计算平台实时计算实验效果，这种做法可以实时捕捉实验流量的变化情况，对于验证实验分流效果有较大的效率提升。
• 复杂实验形式：联合实，多集群实验， 指定用户实验需求：随着算法工程链路的规范化，业务链路中的一些业务层之间开始进行联合调优实验，催生出了多参数跨层联合实验的需求，需要在分层实验的基础上支持联合参数的生效机制，这在一般的分层实验设计中是很难支撑的。随着工程链路稳定性项目的进展，大部分业务同时都具有多个不同集群，此时又需要AB系统也可以针对不同集群提供同场景不同实验配置的功能支撑。还有随着精细化运营的展开，越来越多的实验只针对更精准的特定用户群才能生效，这给原来的实验分流和实验分析都带来了不小的需求和挑战。

更强大更通用的分流模型

为了满足更丰富的流量分配需求，我们设计了一套比较灵活通用的实验分流模型， 这套模型经过多个公司的业务验证，可以确保在未来较长的一段时间内，充分支撑我们所有业务的个各种AB实验分流需求。同时根据我们自己的业务发展需求，也支持了条件层，自定义分流机制等为更复杂业务设计的一些分流机制。

多层正交的实验流量模型

上述的分流模型将一个场景流量分为层和域两种嵌套结构，通过层来隔离不同业务配置，通过域来隔离不同用户群。用户在该模型进行分流的过程采用从外到内，从上到下的逐步命中，每一次进入一个业务层都会触发一次选桶逻辑，命中桶以后，读取桶上的配置，如果桶内还有层配置继续依次命中层，触发内部的选桶逻辑。

该模型可以支持如下主要特点：

1. 分层分域，互相嵌套的流量设计，支持业务域分层的正交流量，每一层都是一个单独的业务，解决流量饥渴问题，同时支持自由的流量域划分，流量域和流量层可以互相嵌套，实现极其灵活的流量划分方式。
2. 每一个流量层采用hash模板+流量槽，层内实验通过圈槽的形式决定实验在该层的流量比例，允许算法用户自定义实验分流的规则，支持根据用户的用户特征信息进行分流，同时支持灵活的跨层流量对齐机制。这种方式可以实现极为灵活的分流方式，支持各种对象和分流方式（比如用户分流，请求分流，设备分流，作者分流，按地区分流等）。
3. 支持白名单，允许用户绕开分流机制，指定用户的固定实验链路，用于在线上进行特殊用户的实验验证。
4. 支持条件层，允许符合某种条件的用户单独进行特定实验，比如只针对新用户进行的实验。

从该模型上线以来，2年多的时间内已经完美支撑了算法300多个场景的AB流量分配需求，经过了充分的业务验证，从分流层面解决了许多有特殊需求的分流业务遇到的问题。

具体层中的分流规则如下：

图片

每一个流量层根据层中的分流配置信息和用户信息计算命中的流量槽，然后根据流量槽命中圈选了流量槽的实验，实验通过拥有的流量槽数量决定实验流量比例。

标准的实验工程链路

通过AB实验的后台改造，我们重新思考并调整了整个实验链路的工程设计，在新的工程设计中，相对于上一个版本主要有以下几个方面需要改进：

1. 采用实验分流日志而不是离线的实验配置来计算用户的实验分组信息。

实验日志可以捕获每一个时刻的用户的实验分流情况，可以较为敏感的捕捉到实验变更的情况。

实验日志可观测性强，用户配置完实验以后可以立刻通过日志观测实验的命中情况。

可以在日志中附加更多的实验环境相关信息，做更丰富的实验分析，可以简化离线的实验分组计算逻辑。

2. 线上应用增加实验信息的具体埋点信息， 埋点分为两部分:

3. 一部分透传给客户端，其中包含用户命中的实验信息，称之为ACM埋点，客户端在用户进行点击曝光等操作时上报信息中回传服务端下发的ACM字段，这样我们可以通过神策上报的行为日志，清楚的知道每个实验曝光几次，被点击几次,可以及时得到实验的线上表现，这部分行为日志还可以帮助我们实时的计算实验策略效果报表。

4. 另一部分作为应用的后台日志记录，记录了每一次请求中用户命中的实验相关信息，用于计算实验分组信息。

5. 设计了AB实验的后台操作管理界面，不用再通过手动修改配置中心的配置来进行实验配置。并将实验发布，实验修改，实验配置回滚等功能做成具体的按钮功能，极大地提高了用户的实验操作使用体验。

6. 拆分了实验参数和代码执行链路，抽象出了AB参数和代码链路运行方案两种概念，将AB变成一个弱依赖，降低实验参数配置错误对线上业务的影响。

Ps: 为什么要同时采用两种实验信息反馈链路，原因是第一种ACM上报的用户实验信息依赖于用户上报,如果用户遇到应用crash或者延迟上报，或者网络情况突然不好，我们没办法获得未上报的这部分信息，第二种很明显，没办法知道发放下来的带有实验信息的内容的后续反馈情况。两种链路都没办法完全的覆盖全部用户，只有互相配合才能完整的覆盖全量用户，至于为什么采用离线日志来做实验报表，ACM来做实时报表纯粹是工程效率方面的考虑。

ACM通用埋点标准

为了解决实验的实时效果观测问题， 我们需要想办法将后台的实验命中标识信息传递给客户端。考虑到其他业务场景也会有类似的埋点需求，为了埋点通用性考虑，我们规划了一个算法的埋点标准，主要想简化算法埋点流程和对算法的埋点信息进行统一的治理。

ACM埋点主要是通过算法与客户端约定一个固定的埋点内容字段ACM，后端算法在开发时候，通过提供的SDK工具，将需要埋点的信息和内容通过SDK采用特定的规范形成一串可识别的字符串内容，客户端同学对ACM这个约定好的字段进行事件（曝光，点击等）上报，后端就可以根据上报的用户行为日志通过实时计算工具快速的获得某个实验的后续用户反馈信息。

ACM埋点规范例子：

版本.业务域.内容资源类型.资源位.实验.自定义值