ABTest流量分发和业界的一些做法经验
大家好，我是宝器！
流量为王的时代，如何精准的利用用户的流量进行分析和产品的迭代？ABTest就是其中不可缺少的一环，那么ABTest是什么呢？下面来一层一层揭开它神秘的面纱。
0.流量分发
在互联网流量的分发模式中，主要的两种分发模式为：
中心化：平台负责流量的分配，节点的流量来自平台分配，平台拥有流量的控制权，比如像淘宝、京东、美团等互联网产品都是一个中心化的流量分发模式 去中心化：相对于中心化而言，去中心化模式并不负责流量的分配，节点的流量需要自己获取，节点本身拥有流量的控制权，其中典型的产品是微信，张小龙在阐述微信公众平台的八大观点时，就提到说“微信要打造的是一个真正的去去中心化系统，不会提供一个中心化的流量入口来给所有的第三方平台”
因为本文主要介绍的是ABTest，所以针对去中心化的模式就不展开叙述，主要聊一下中心化模式。
基于不同的流量分发模式，流量分发的方式包括：搜索分发、算法分发、社交分发、人工分发、付费分发，其对应的产品如下所示，其中除了社交分发是属于去中心化的模式，其他的均属于中心化的流量分发方式，可见中心化分发方式的广泛性。
其中搜索分发和算法分发应该是做算法同学接触最多的了，因为搜广推的场景下流量的珍贵性和严谨性，是我们算法策略迭代的基石。
在互联网行业，无路是构建搜索、广告、推荐系统，还是智能营销等场景，其实都是围绕着用户流量进行不同的实验，这其中流量的分发显得就格外的重要，因为我们要基于不同的流量，进行各项指标的监控和对比，继而决策算法策略改进的方法。
而流量分发中一个很重要的概念就是ABTest（AB实验），那么什么是ABTest呢？我们往下看。
1.ABTest介绍
1.1 ABTest来源
ABTest的前身是随机对照试验-双盲测试，是「医疗/生物试验将研究对象随机分组，对不同组实施不同的干预，对照起效果」。
双盲测试中病人被随机分成两组，在不知情的情况下分别给予安慰剂和测试用药，经过一段时间的实验后再来比较这两组病人的表现是否具有显著的差异，从而决定测试用药是否真的有效。
2000年谷歌工程师进行了第一次AB Test，试图确定在搜索引擎结果页面上显示的最佳结果数量。后来AB测试不断发展，但基础和基本原则通常保持不变，2011年，谷歌首次测试后11年，谷歌进行了7000多次不同的AB测试。
12年奥巴马竞选网站的样式，通过AB Test 找到了更能吸引募捐，帮助奥巴马赢得了更高的募捐金额。
1.2 ABTest描述
关于ABTest并没有一个官方的定义或者怎么样，因为从名字上我们就可以知道其大概的表述含义，每个人理解的都相差无几。维基百科上给ABTest下了一个定义为：
A/B testing is a way to compare two versions of a single variable, typically by testing a subject's response to variant A against variant B, and determining which of the two variants is more effective.
其实通俗来讲，ABTest就是比较两个事物好坏的一套方法论。比如某个平台将不同的用户分成不同的组，同时测试不同的方案，通过用户反馈的真实数据来找出哪一个方案更好。这解决的是“多种方案需要拍脑袋确认哪一种更好的问题”。
1.3 ABTest特性
对于ABTest，有哪些特性呢？如下描述
先验性：ABTest 是一种“先验体系”，属于预测型结论（与其相对的是后验型的经验归纳）。同样是一个方案是否好坏：ABTest 通过小流量测试获得具有代表性的实验结论，来验证方案好坏后再决定是否推广到全量；后验型则是通过发布版本后的版本数据对比总结得到 并行性：是指支持两个或以上的实验同时在线，并需要保证其每个实验所处环境一致。并行性极大的降低了多实验的时间成本 科学性：ABTest是用科学的方式来验证方案，科学性体现在流量分配的科学性、统计的科学性。记得在开篇提到的“AB测试的前身是随机对照实验，医疗/生物实验将研究对象随机分组，对不同组实施不同的干预，对照起效果”，这要求ABTest将相似特征的用户均匀的分派到实验组别中，确保每个组别的用户特征相同
1.4 ABTest目的
一些通用目的为：
减少发布新功能或者改版的风险，比如某个产品需要进行界面的改版，在没有进行ABTest的情况贸然切换到新版，如果引发用户流失、相关指标的下降，带来的后果是非常严重的。 收集用户的数据，基于数据了解平台用户的偏好，现在很多功能的改动，都是抄袭竞品的变化，看对手动了，没有去思考对方为什么这么改动，是否适合我们的用户，经过多次AB测试后，能让我们更加了解自己的用户偏好，用户群的画像特征，也更利于下一次改版 真正的用数据帮助决策，通过AB实验的效果数据，决定策略的迭代和更新
在做推荐算法的过程中，我们也离不开ABTest，这样的背景下，ABTest的目的主要是评估优化后策略算法的效果，如果我们优化的一个策略相对于基准组是正向且显著的，那么就可以将该策略进行推全。
1.5 ABTest局限
ABTest虽然强大，但却不是万能的，因为ABTest是验证方案、想法、策略的有效性，而不是凭空去创造一个方案、想法、策略。
知乎上有一个关于ABTest的描述极其的准确，分享给大家：
你可以用A/B测试让你在已经到达的山上越来越高，但你不能用它来发现一座新的山脉。如果你的产品真正需要的是一个完整的改造，那么A/B测试可能做不到
同时字节跳动创始人张一鸣在清华经管学院，对问题“PM是否可以产品设计上是否更多的依赖ABtest而非直觉?”的解答，也准确的描述ABTest的意义：
我们认为这和ABtest同样重要。我们反对从逻辑到逻辑，从逻辑到逻辑，很容易失之毫厘谬以千里。有一手的体验能帮我们远离偏差，我们愿意把用户的感受、体会带到公司。我们全球化的第一件事情是海外用户反馈，提供联系方式，让用户可以直接联系到我们。PM是需要sense的，AB的science可以用来的降低在细节层面的精力付出。
ABTest是有开发成本的，一个公司想要打磨出一个优秀的ABTest平台必定要投入大量的精力、人力。
ABTest的数据只有现象，没有详情。它可以给出实验组比对照组的效果好现象，但无法给出过程数据。测试相对复杂的方案，ABTest无法表述出具体是哪个方面呈现出了优势。
所以说ABTest并不是万能的，但是在做产品的过程中离开ABTest也是万万不能的。
2.产品发展到哪个阶段需要ABTest
上面针对ABTest做了详细的介绍，那么在针对一个产品做到什么程度需要ABTest呢？当然有精力、能力的团队可以在产品的一开始就进行ABTest平台的建设和利用，但是大多数团队和产品在产品的出去阶段并没有能力去建设自己的ABTest平台。
所以这个答案并不是一概而论的，一个比较通常的理解是当产品在初期阶段、或者是月活只有几十万的级别并不需要搭建复杂的ABTest平台，但是这并不说明不需要进行ABTest，可以利用一些简单的做法进行ABTest，比如利用用户的唯一ID做简单的Hash进行测试，或者一开始设计用户ID时进行自增设计，这种情况下可以利用ID的尾数进行简单的分桶测试。
当产品的月活达到百万级别时，这时候就需要开始搭建自己的ABTest平台了，这时候月活已经到达了一定的规模，需要对流量进行控制和有效的利用，基于此来进行产品的迭代和策略的更替。
当产品的月活达到千万、亿级别时，这时候自己公司的ABTest平台应该是达到了一个比较完善和精准的状态了，因为国内用户的流量价值比较高，这时候需要进行可靠的、精准的分发和测试。
当然上述只是笔者自己的观点，不过大多数互联网公司的产品是符合这个发展规律的。针对一些大平台孵化的一些小产品，可能在产品的初期阶段就会进行精准的ABTest，因为已经有成熟的内部平台可以使用了。
3.ABTest流量切分方式
这里结合推荐系统来介绍ABTest流量的切分方式，将推荐系统简化为召回和精排两个过程。
ABTest流量切分主要有两种方式：
水平的切分方式 树形的切分方式
水平的切分方式比较容易理解：比如我们有100%的流量，将其中的50%流量分给召回，把剩下的50%流量分给精排。在这种情况下进行试验，当某个试验的指标为正向时，进行推全，然后在该部分流量上继续进行别的试验，这种流量切分方式比较直观，可以看到定向组合流量下得到的试验效果，但是不够灵活，流量的利用程度不高。
树形的切分方式则是将推荐系统中的不同模块进行分层，比如召回是一个层，精排是一个层，因为召回出来的结果需要汇聚之后送到精排层做排序。这种情况下每层都是100%的流量，可以进行流量的充分利用。
一般情况下，采用的流量切分方式为：树形的切分+水平的切分。
比如召回100%的流量，召回中又分为多路召回，在召回层中我们可以采样水平的切分方式，将流量切分为若干个桶，比如1-10，然后选定基准桶（假设编号为1），然后在剩下的2-10个桶里进行不同的召回试验。同样可以将精排层的流量划分为若干个桶，每个桶进行不同的模型试验、不同的特征试验、不同的参数试验等。
4.ABTest平台应该包含哪些功能
一个标配的ABtest平台应该包含哪些功能呢？这里主要借鉴的OPPO的ABTest平台知识，详细原文可以阅读：OPPO在A/B实验分析平台的建设与实践
4.1 ABTest的核心能力
从A/B实验的形态上来看，可以分为算法类、产品功能类、页面展示类等实验。从集成端看，可以分为服务端、客户端、网关等。
站在实验生命周期的角度考虑，一个完整的实验流程一般是创建实验 —> 做实验 —> 实验效果分析 —> 调整实验的闭环，流程的示意图如下。
整个核心流程主要涉及三个阶段，创建实验和调整实验可归结为同一阶段，不同的阶段各自可以相互独立又相关，每个阶段需要提供的能力如下:
创建/编辑实验需要提供实验相关的管理，如参数、变量、版本控制、回滚，流量占比配置等一系列能力，可以抽取出一个实验管理模块 做实验阶段主要涉及分流和埋点数据上报，分流主要通过SDK来实现，同时还需要一些服务化的能力提供些外部接口以及SDK的数据交互，埋点数据主要是实验数据的回收 实验效果分析主要涉及指标体系的构建和实时表报的开发等一整套olap的能力
4.2 实验管理
试验管理可以理解为一个易操作的web系统，除了管理试验外，需要包含一些相关的配置功能：业务线管理、账号管理、权限管理等。而实验管理主要涉及：
应用：是管理所有实验的单元体，一个应用可以创建多个AB实验，应用也可以理解为一个个的实验场景，比如首页推荐、猜你喜欢 层：是应用内流量的横向划分，可以创建多层，每层是相同的流量，通过算法实现层与层的流量正交，层中包含实验，创建实验需要指定实验层，一个层同时只能做一个实验，因为要控制变量 指标：在每一个AB测试实验中，用于对比不同实验组优劣的数据就是指标（这里需要注意的是分析相关指标需要有相应的数据上报） 实验组：实验组和对照组是一组相对的概念，AB实验通常是为了验证一个新策略的效果，对照组一般又称base组
4.3 分流服务
分流服务主要解决流量控制和切分，主要参考2010年Google论文《Overlapping Experiment Infrastructure:More, Better, Faster Experimentation》确定了流量模型，划分了放量域、非重叠域、重叠域，重叠域支持分层，具体的了流量模型如下图：
确定流量模型后，还需要解决如何分流，即一个用户发起一个请求，如何命中实验？这涉及分流算法、用户标识、标签、流量比例等一系列因素，这里为了突出分流的过程，结合分流算法和用户标识，抽象出了分流树。如下图，图示的灰绿色箭头为一次请求的完整分流过程，即一次分流，可能命中多个实验或者一个实验，也可能没有任何命中，图中的hash属于一种分流算法，目前除了支持Hash算法，还支持随机算法，也可让业务方自定义分流算法
服务主要以SDK的方式提供服务，接入方只需要集成相应语言的SDK即可，这样可以避免不必要的网络请求，保障分流的稳定性和响应延迟。
4.4 实验效果
实验效果主要是在进行实验后，针对AB实验差别的可视化能力，为了方便业务团队快速的分析，需要构建一些基础的指标体系，比如：
基础指标：PV、UV、人均次数、渗透率、分位数、去重 自定义组合指标
数据回收与分析
实验数据的回收，主要使用公司的统一埋点SDK实现，有客户端将实验ID映射带埋点事件，随埋点上报到数据中心，然后使用flink从kafka消费入库到分析引擎ClickHouse，为了达到数据延迟在1分钟以内，数据在flink完成hash分片，然后直接写到ClickHouse本地表。
5.ABTest指标选择与有效性检验
当设计好ABTest实验时，最重要的两点就是实验评判指标的选择和实验结果的有效性检验。
5.1 评判指标选择
做AB实验之前，需要明确测试的目的，根据目标去制定合理的指标。
比如针对产品的首页改版，我们更加关注的是老用户的留存率，因为不同的页面对于老用户的心智影响比较大，老用户的行为习惯已经被养成了，当改动页面时老用户可能会因为不习惯新页面的变化而流失。所以在做这类实验时，要尽量避免大的改版，而且改版后给予的流量不要太大，否则影响会比较大。
比如电商产品的详情页改版，其目的是提高商品详情页的转化率，因此确定指标就需要考虑过程性指标，也要考虑结果指标，当然结果指标是最重要的。
过程性指标：商品详情页的跳出率、平均停留时长，页面功能的点击率
结果指标：加购或者立即购买的转化率，支付金额、支付人数
比如：社区类产品增加了一个模块，目的是增加用户的粘性
过程性指标：新模块的曝光点击情况，旧模块的曝光人数、旧模块的点击人数来判断新增模块对旧模块的负面影响
结果指标：用户总时长、用户人均时长
最终根据这些指标进行评价功能的好与坏，来决定新功能是否要保留上线
当对于一些策略的AB实验时，我们更关注的则是相关的业务KPI指标，比较策略算法都是为了业务服务的。经常关注的一些指标比如：CTR、CVR、CXR、交易额、RPM等。
5.2 有效性检验
当产出ABTest的结果时，如何去判断我们的结果是否有效呢？
首先需要保证的是我们流量比例，即样本的量级。假设AB两组实验的用户具有相同的标准差
，根据公式，带入n1，同时根据假设p值和a值，推导出需要的最低用户数。
其次是假设检验，在适当的条件下，中心极限定理告诉我们，大量相互独立随机变量的均值适当标准化后依分布收敛于正态分布，AB测试采用双样本对照的z检验公式，显著性上，根据z检验算出p值，通常我们会用p值和0.05比较，如果p<0.05，我们认为AB没有显著差异，置信问题上，对一个概率样本的总体参数进行区间估计的样本均值范围，他展现了这个均值范围包含总体参数的概率，这个概率称为置信水平。
从另一个角度来说，AB两个实验组之间即使有差异，也不一定能被观测出来，必须保证一定的条件才能使你能观测出统计量之间的差异；否则，结果也是不置信的。而这个条件就是开头提到的问题，样本数量问题。
关于假设检验，这里就不展开表述了，具体可以参考知乎文章：假设检验——这一篇文章就够了
6.业界的一些ABTest经验
6.1 ABTest的两种形式
据笔者了解到，业界ABTest的实现基本有两种做法：
提前划分好流量进行实验 动态配置流量进行实验
第一种就是提前分配好流量，对应的是「流量切分方式」中的水平切分方式，比如将所有的流量划分为20个桶，然后选定基准的试验桶，在剩余的各个桶内进行AB实验，当实验效果是显著正向时，将该实验进行推全（即在每个实验桶都进行配置，或者做一个前置的控制）。
第二种则是根据需要动态的划分流量，这里可以区分层（比如推荐系统中的召回、粗排、精排等），也可以不进行层的区分。当进行层的区分时就是树形的流量切分方式+水平的切分方式，如果不进行分层，就是根据需要划分5%或者10%或者其他占比的流量进行实验。
针对第二种分层控制时，我们的召回有若干路，分别使用大些字母ABCD等表示，当只有ABC三组召回时，可以进行配置的方式为：A:0-33,B:34-67,C:68-99，当新增召回源D时，可以将陪配置修改为：A:0-24,B:25-49,C:50-74,D:75-99。依次类推。
这里还有一种特殊的ABTest形式，就是字节跳动的赛马机制，不过这里是针对item的。其基本原理介绍如下：
冷启动推荐：通过审核后，抖音会对实时在线用户进行流量分桶，每桶按照总用户量10%分配进行实验推送，第一步叫冷启动流量池曝光，比如你今天上传一个视频，通过双重审核的作品，系统将会分配给你一个初始流量池：200-300在线用户。不论你是不是大号，只要你有能力产出优质内容，就有机会跟大号竞争 标签积累：分配的视频流量再进行分配实验组，每个实验组按照5%比例分配，并为用户贴上相近标签 加权推荐：把作品送量测试给首个实验组用户，根据用户反馈的转、评、赞、完播率等计算作品基数，决定是否进行第二轮推荐及推荐力度。即播放量=A完播率+B 点赞率+C* 评论率+D* 转发率。 加大流量推荐：达到通过推荐基数，继续把作品推送下一个分配实验组进行测试 顶流推荐：进入精品推荐池，大规模曝光，一旦进入精品推荐后，人群标签就被弱化了，几乎每个抖音用户都会刷到
6.2 其他公司的ABTest做法
技术揭秘大众点评大规模并行AB测试框架Gemini
教你如何对产品做AB测试
7.参考
7.1 文章
流量的概述系列：流量的分发 从数据产品经理视角，聊聊科学的AB Test OPPO在A/B实验分析平台的建设与实践 流量为王：ABTest流量分层分桶机制 假设检验——这一篇文章就够了
7.2 论文
Overlapping Experiment Infrastructure: More, Better, Faster Experimentation
·················END················· 推荐阅读
欢迎长按扫码关注「数据管道」
