ABTEST平台建设思路与方案

导读

ABTest的作用：

1. 用ABTEST的结果数据，论证是因为某个业务方案的调整，对产品能力的影响。
2. ABTEST是一个过程，只是为了证明改动的效果，其最终的阶段一定是对某个方案进行推全结束实验，避免稳定的业务流程还需要依赖ABTEST。

基础概念

AB实验的业务推进过程

1. 明确实验的目标
2. 分析实验目标中，包含的变量。确定哪些变量是和实验结果直接相关的，排除掉影响结果的的无关因素
3. 确定实验过程中，需要观测的指标。制定好对应日志埋点方案、数据分析方案
4. 确定分流维度，确保和实验目标一致、分流结果足够分散
5. 按实验目标中涉及的变量，设置实验分组类型、流量比例、实验参数等

实验状态变化

说明：

1. 创建流量入口id：按业务，创建对应的流量入口id（entranceId）
2. 创建中：
   • 新建AB实验，将实验和流量入口进行关联
   • 新增AB实验下的实验分组、分组参数、分组流量、组内指定的实验uid
   • 此时实验还不能被外界访问到
3. 调试中
   • 调整上一步中，分组内的参数和组内指定的实验uid
   • 此时实验可以被外界访问到
   • 此时不允许调整分组的流量，因为调试阶段调整分组流量没有意义
4. 运行中
   • 该状态只允许调整组内的流量，但只能调大流量，不能缩减某个分组的流量（因为缩减流量后，会出现某个uid从老方案 >> 新方案 >> 老方案的情况，造成用户体验）
5. 推全实验：
   • 选择实验中的某个分组，将其设置为该实验的返回值
   • 推全后流量将被释放到entranceId中的空闲流量

实验类型介绍

   可将实验分为 互斥流量实验 和 正交流量实验，分别对应下图中的实验1和实验2。

实验类型比较：

实验类型	一句话特点	介绍	优点	缺点
互斥流量实验（随机实验）	将流量随机的分配到某个组上进行实验	1.请求只会获得到一个组的结果 2. 可认为是只有一层的正交流量实验	1. 实验简单，在做数据分析时，只需要对比所有互斥实验即可	1.由于组之间流量互斥，100的流量所分的组是有限的。 2. 若所有运行中实验把流量占满后， 将无法在同一个流量入口下再新增实验，将影响业务的AB推进
正交流量实验	用更少的实验，测试更多的因素，并保证各个因素间的独立性	1. 流量会经过每个层级的实验。向下传递时，流量会被再次打散到实验内的组上	1. 可以不断的添加正交实验	1. 不同层级的实验，在统计最后的结果时，比较复杂

实验分组、流量划分关系图

以多个正交实验类型为列：

说明：

1. 推全的实验A，占用的流量会被释放出来，但不是删除实验，推全分组的值，会被作为该流量入口的必须返回值

AB时的常见问题

一、 分流维度：

   对业务做AB实验时，需要对分流的维度思考清楚。要避免因为分流维度的问题，导致对最后的数据分析产生影响。如以下一些AB场景：

1. 在统一支付场景下，需要在PC端验证不同钱包展示页面，对支付成功率的影响
2. 验证在h5场景下，不同的拉端方案（保拉端：尽量尝试将钱包APP拉起、保支付：提供给用户选择支付的方式）对支付成功率的影响

两个方案中，均使用前端生成的浏览器唯一标识来分流，让分流结果更分散

二、分流算法：
   最简单的分流算法，取模+概率对比完成分流，但这种场景下，需要被取模数一定要随机。

   另外一种随机算法，MurmurHash算法，计算出的hash值更加分散，取模后更加符合随机性。

实验数据分析

   需要对平台内部，建设通用的实验基础数据分析模型和流程。若需要借助其他应用的数据结合分析，需要建设对应的数据分析平台能力。

   数据分析需要Case By Case 的去看，这里不做过多的介绍和研究。

Q：

1. AB解决了什么问题？
   • 用ABTEST的结果数据，论证业务方案的调整，对产品能力的影响。
2. 能对业务带来什么样产值？
   • 用来自实际市场的实验数据，证明业务方案调整的意义，确保业务调整方向是符合市场、产品心智的。
3. 平台和业务的产出，有没有形成闭环？
   • 通过数据分析，得出实验结果，引导PD调整业务方案，助力业务发展。

MurmurHash3算法介绍