1 AB平台简介

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

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

2 1.0时代 从无到有

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

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

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

2.1 一个基本AB实验实例

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

1.实验目标和实验假设

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

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

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

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

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

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

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

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

2.2 算法的AB1.0主要功能

1.通过控制变量的方式进行AB分流实验，并通过离线的模拟分流规则提供用户实验分组信息，使得数据分析可以计算实验的指标报表。

2.打通基本的工程实验链路，可以让算法通过实验配置自主的控制实验流量和实验策略。

2.3 1.0 AB实验的策略生效流程

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

1.通过配置中心配置约定好的AB实验配置信息，线上的服务通过配置中心的变更信息，实时变更实验配置，从下次分流开始应用新的分流策略，同时记录实验日志。

2.报表计算方式，将实验配置信息同步到ODPS，第二天用前一天的实验配置对昨天的用户进行重新分流计算，获得昨天的用户实验分流信息（之所以这样是因为实验变更是以天为单位，离线计算可以比较方面的支撑后续的实验分析）。

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

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

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

3.1 新的业务需求

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

1.流量饥渴，更丰富的流量需求：在1.0版本的AB实验中已经解决了基本的实验分流和配置的问题，但是由于一个场景中总用户流量有限，可能会有多种业务实验同时进行，实际实验运行时需要在同时运行的实验数量和每个实验的流量大小之间做一个取舍，业务高速发展时期经常会有用户希望提高同时运行的实验数量，同时保证每个实验有充足的流量，于是我们扩展了原来的实验流量分流模型设计，采用分层分域的正交的业务实验划分方式来支撑上述的流量需求。

2.更实时更准确的实验报表：在早期的实验中通过第二天的配置重算的方式得到前一天的用户实验分组数据，这种方法可以支撑非常巨大的用户和实验数量，但是时效性上比较难以保证。随着业务快速迭代，算法的实时实验效果监控的需求也逐渐增加，离线的实验报表计算反馈需要等到至少1天后才能观测，实验反馈周期太长。于是我们调整了实验分流和报表的计算链路，采用实时实验日志埋点通过flink等实时计算平台实时计算实验效果，这种做法可以实时捕捉实验流量的变化情况，对于验证实验分流效果有较大的效率提升。

3.复杂实验形式：联合实，多集群实验， 指定用户实验需求：随着算法工程链路的规范化，业务链路中的一些业务层之间开始进行联合调优实验，催生出了多参数跨层联合实验的需求，需要在分层实验的基础上支持联合参数的生效机制，这在一般的分层实验设计中是很难支撑的。随着工程链路稳定性项目的进展，大部分业务同时都具有多个不同集群，此时又需要AB系统也可以针对不同集群提供同场景不同实验配置的功能支撑。还有随着精细化运营的展开，越来越多的实验只针对更精准的特定用户群才能生效，这给原来的实验分流和实验分析都带来了不小的需求和挑战。

3.2 更大更通用的分流模型

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

多层正交的实验流量模型

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

服务器托管网

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

1.分层分域，互相嵌套的流量设计，支持业务域分层的正交流量，每一层都是一个单独的业务，解决流量饥渴问题，同时支持自由的流量域划分，流量域和流量层可以互相嵌套，实现极其灵活的流量划分方式。

2.每一个流量层采用hash模板+流量槽，层内实验通过圈槽的形式决定实验在该层的流量比例，允许算法用户自定义实验分流的规则，支持根据用户的用户特征信息进行分流，同时支持灵活的跨层流量对齐机制。这种方式可以实现极为灵活的分流方式，支持各种对象和分流方式（比如用户分流，请求分流，设备分流，作者分流，按地区分流等）。

3.支持白名单，允许用户绕开分流机制，指定用户的固定实验链路，用于在线上进行特殊用户的实验验证。

4.支持条件层，允许符合某种条件的用户单独进行特定实验，比如只针对新用户进行的实验。

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

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

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

3.3标准实验的工程链路

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

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

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

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

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

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

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

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

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

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

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

ACM通用埋点标准

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

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

ACM埋点规范例子：

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

• 版本：标记本条ACM的遵循的规范版本，不同版本具有不同的解析规则，方便udf解析。

• 业务域：业务系统代称，尽量简短，比如 搜索srh。

• 内容资源类型：内容类型或资源，比如 user_10098, cspu_1020,spu_771等。

• 资源位：广告位，榜单位。

• 实验：资源本次采用的AB实验策略，多个实验用-隔开。

• 自定义值：

  • 允许应用方进行扩展的字段，比如 chan_latest-pos_3 代表channel为latest，pos为3。

  • 特殊要求：自定义字段中不能出现 “.”,”-“,”_”等字段，其他部分无此要求。

埋点示例：

acm: 1.srh.spu_1009.sh.kka3b.10089-1929-100.channel_hot-position_2
acm: 2.srh.spu:1009.sh.kka3b.10089;1929;100.channel:hot;position:2

埋点场景：

request维度，覆盖所有搜索和推荐场景

埋点动作：

request维度

下面是一个带有acm信息的后端返回示例：

{
    "code": 200,
    "data": {
        "total": 3730,
        "start": 0,
        "hits": 10,
        "searchId": "161113175619737242413163",
        "searchTime": 0.024447,
        "items":[
            {
                "spuId":"xxx",
                "acm": "1.ms.prd-10092.v1ss.exp-1.kka.12",
            }
        ],
        "facet":[],
        "cache": false
    },
    "requestId": "f2ca7c08693acd54",
    "cost": 0,
    "time": 1611131759
}

3.4 实时的实验指标监控

实时实验指标的计算流程

1.后台服务日志实验分流信息需要透传给客户端；

2.客户端用户行为及时上报；

3.行为日志被flink等实时计算平台及时处理；

4.制定明确且可计算的实时指标规范。

有了上面四个基础流程，就可以计算实时的实验反馈指标，但是要注意实时的指标计算往往只能反映一段时间的实验趋势变化，在部分复杂指标上很难实现精确的实验指标计算，所以一般用来观察实验指标变化趋势，不作为最终决策依据。

实时数据处理链路

打通了数据链路并且在用户的行为日志中包含了ACM埋点以后，算法就可以基于行为日志，通过flink等工具实时算计算用户的各种指标信息。

具体的监控链路流程如下图绿色链路所示：

具体实时实验监控效果

最终可以达到秒级的实验效果反馈，极大的加快了算法对实验策略的反馈效率，具体效果如下图，用户可以自己选择关注的实验信息对比不同实验在同一时间区间内的指标变化情况。可以非常迅速的得到线上的新实验的效果反馈信息，极大地缩短了算法对实验指标的策略调整反馈周期。

4 3.0 时代 从全到优，提升用户体验和实验效率

2.0 时代主要是从各种机制和功能方面尽量满足业务需要，业务功能满足以后，我们进行了业务与扩展，将算法的推荐业务场景也囊括进来，推荐业务接入以后，虽然在基本功能上也可以满足需求，但是推荐和搜索的业务特点还是有点不同，于是我们针对实验平台的实验操作用户体验和稳定性方面进行了较多的优化。

4.1 实验操作易用性的建设

业务场景铺开以后，使用的业务团队和人员也变得更为复杂，于是我们在针对特定场景的使用和业务人员使用习惯方面做了不少的功能改进和优化。根据我们收集的算法人员的参数配置，白名单配置，流量调整等功能使用痛点，我们进行了针对性的优化。

实验参数的易用性工具

实验参数配置是AB实验的最主要的功能，为了优化用户体验在实验参数使用方面的体验，我们收集了一些常见的用户在使用参数配置时候经常遇到的问题，并针对性做了功能和体验的优化。

场景1：随着业务发展，算法配置的业务层越来越多，由于约定的参数规范是同一层的可配置实验参数应该一致，同一个实验参数配置也应该出现在同一层，但是随着层数增多和部分参数使用不规范，估算某个实验参数的实际生效流量就变得很困难（参数有后覆盖前面的规则）。有可能出现你给a实验配置了 10%流量的 recallSize = 20 但是后续该参数被别人的同名参数覆盖导致实际参数生效流量不符合预期的情况。

参数流量着色分析

使用参数流量的着色分析可以清楚的知道某个实验参数都在哪些实验中有配置，这些实验如果同属于一个业务层则无流量覆盖，如果有些实验不属于同一个业务层，有可能出现参数覆盖的情况。流量着色就是通过程序，一键计算某个参数最终的流量结果分布情况，可以方便的看到某个参数最终的线上真实流量比例。

包含某参数配置的所有实验查询：

某参数的实际生效流量分布

场景2：实验参数越来越复杂，同一个参数往往有多个不同的版本需要同时观测实验的效果，这种时候可能由于时间久远或者实验变更频繁，或者参数过多，很多时候在进行实验观测和调整的时候需要确认实验中的参数配置信息，特地为这些需要对比参数的场景制作了便捷的实验参数对比的功能。

实验参数对比：可以比较清晰的对比同一个实验参数在同一层其他实验中分别是什么值，可以大幅度提高实验流量调整期间需要进行的实验信息核对工作效率。

实验布局的操作和展示优化

为了满足灵活的实验流量划分，我们设计了一套通用的实验流量模型，但是该流量模型的可视化方面一直是一个不小的难题，最基本的我们希望能直观的展示层与层，层与桶（用户域）之间的布局结构和用户流量的命中顺序关系。

我们进行了一些更能直观体现实验布局的探索，目前我们采用一个标准的树状结构来表示个实验分流模型。实验模型中的业务层和用户桶我们都会用图标进行区分，由于层桶结构可以嵌套多次，我们通过将结构关系进行拆分，将桶页面主视图和层页面主视图进行了分别设计。

• 层页面主视图：可以便捷的观察到当前层内的不同流量桶和子桶内的其他子业务层，主要是用于寻找自己的业务层位于某一个用户桶内，观察某些桶的流量比例和参数等。子业务层内的流量桶信息不予显示。

• 

• 桶页面主视图：桶页面的主视图可以同时观察到该桶内的各个子业务层和业务层内部的子实验桶信息，可以用来直观的对照具体的实验命中链路从上往下核对实验命中路径。

界面显示如下（测试数据）：

通过将层桶结构进行主要的功能拆分，可以在复杂场景的视图布局清晰度和易用性上达到一个比较好的平衡。

实验信息的完善

算法的实验在进行实验分析报表的时候往往需要对比多个指标综合观察实验效果，之前都是算法人员跟分析人工对齐某个实验什么时候开始什么时候结束，需要观察哪些指标等信息。为了方便后续自动化的进行实验效果分析，我们完善了实验的实验时长，核心指标，辅助指标等功能，方便用户进行实验的分析信息管理，后续通过自动化功能依赖这种信息可以实现实验报表指标流程的自动化计算。

4.2 服务稳定性的改进

1.动态白名单功能优化

白名单操作是一个使用频次较高的AB实验操作功能， 实验参数配置好以后往往需要通过白名单来小范围的验证策略效果。但是早期的白名单设计时候考虑到白名单会影响用户的分流，所以白名单信息和实验布局配置信息一起被用户感知，这也导致每一次的白名单变更都需要重新发布实验配置，给线上的配置稳定性造成了威胁。

解决方案：

基于白名单的设计和生效流程，我们尝试通过流程和配置格式改进优化，使得白名单的配置可以实时生效同时又不影响原来的实验配置，如下图所示：

动态白名单功能改动相当于将白名单的配置信息独立出来，在白名单有修改的时候独立加载，同时不触发配置信息本身的更新。但是考虑到兼容性问题，我们每次配置信息改动也会额外触发白名单的重新更新，描述配置更新相当于一次全量更新，配置和白名单都会更新。白名单更新相当于实时只更新新增的白名单信息。

2.并发操作Ark发布实验的优化

由于AB实验的配置下发方式是通过Ark配置中心提供的配置通知功能实现的，目前后台操作Ark进行配置发布的时候是通过http接口进行了，使用接口同时操作同一个Ark配置集的时候，大量操作容易产生并发，并发问题会导致Ark操作直接失败，这种情况极大地阻碍了实验配置发布过程的流畅性。

解决的办法有如下方案：

经过仔细评估和方案选择，我们决定方案2,3,4同步进行，最终完全解决了实验操作时候的并发问题。

4.3 实验效果分析的探索和优化

在过去2年的AB实验的实践和改进过程中，我们也十分注重实验效果方面的分析和问题归因，根据遇到的实际实验分析问题和情况，总结了一部分常见的实验分析相关经验文档，其中涉及实验流程标准化，实验指标选取，实验指标的统计功效分析，实验指标的p值和置信度分析，以及常见的实验中遇到的问题等。

常见的实验分析问题

我们总结了一些实验效果分析中常见的问题和可能的原因，可以帮助排查AB实验中遇到的常见问题。具体如下表：

实验中的辛普森悖论

辛普森悖论（英语：Simpson’s paradox），是概率和统计中的一种现象，其中趋势出现在几组数据中，但当这些组被合并后趋势消失或反转。这个结果在社会科学和医学科学统计中经常遇到，当频率数据被不恰当地给出因果解释时尤其成问题。当干扰变量和因果关系在统计建模中得到适当处理时，这个悖论就可以得到解决。辛普森悖论已被用来说明统计误用可能产生的误导性结果。 落实到我们的AB实验中就是 如果一个实验A在一个较长的实验周期内每天指标都高于实验B，实验A的整体周期指标未必高于实验B。

本图想说明一个问题，如果一个实验周期跨很多天，每天观测实验效果的情况下，如果某个实验组用户数量（或者某个指标）长期每天稳定高于另一个实验组，不能说明分流不均匀。

第一天 因为刚刚重新分流，所以所有用户对实验来说都是新用户，a组 505万，b组 495万 ，1%的正常误差。

第二天 因为老用户要保持分流一致，组内用户=新用户+次留老用户， 新用户会重新分组，老用户沿用之前的分组，此时有两种情况：

情况1 （合理） 老用户按原来的分流， 新用户分流误差 1%。

情况2 （不合理） 老用户按原来的分流，新用户必须要保证误差 2%，才能逆转第二天的分组误差情况，但是此种情况下第二天的新老用户比例会严重不均匀，同时没办法保持分流策略的一致性，理论上不可能实现。

5 未来改进的方向

未来我们会希望借助数仓部门的AB平台的指标计算和可视化通用能力，希望可以逐步增强AB平台的数据可视化能力，在实验分流情况的可视化分析，实验的用户特征的分布可视化分析，实验的指标变化原因排查等方面与分析同学一起合作，提升AB实验的指标报表问题分析效率。

在AB实验平台本身的实验信息操作和性能，稳定性方面我们也有一些新的想法，希望将来可以打通开发环境，测试环境，生产环境，实现一个界面可以跨环境操作，降低算法同学使用不同环境AB需要在不同系统切换的问题，同时在将来还希望借助sidecard的形式增强AB实验的分流能力和分流稳定性，兼顾分流性能和分流平台功能迭代效率。

*文 / 开阳

本文属得物技术原创，更多精彩文章请看：得物技术官网

未经得物技术许可严禁转载，否则依法追究法律责任！

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: 2023-06-13：统计高并发网站每个网页每天的 UV 数据，结合Redis你会如何实现？

2023-06-13：统计高并发网站每个网页每天的 UV 数据，结合Redis你会如何实现？ 答案2023-06-13： 选用方案：HyperLogLog 如果统计 PV （页面浏览量）那非常好办，可以考虑为每个网页创建一个独立的 Redis 计数器，并将日期…