介绍ab分流的流量保护功能之前,先普及一下ab分流的一些概念和术语
名词解释:
- 实验:用来验证某个决定请求处理方式的功能或策略的一部分流量,通常用来验证某个功能或策略对系统指标(如PV/UV,CRT,下单转化率等)的影响。
- 流量 :指所有访问用户的请求
- Hash因子:可以理解为访问实验用户的uuid,即一个可以识别某个流量用户的唯一标识。
- Hash算法:是把任意长度的输入通过散列算法变换成固定长度的输出,是一种从任意文件中创造小的数字「指纹」的方法。与指纹一样,散列算法就是一种以较短的信息来保证文件唯一性的标志
- 桶位:ab测试又称为分桶测试。当用户的请求打到某个实验进行分流时,分流引擎会根据请求的uuid + 强一致性hash算法(保证分每个桶分到的越随机越平均越好)生成一个全局固定不变的值 ,然后 值取模100 得到一个0-100区间的具体桶位编号,一个百分点对应一个桶位编号。
- 实验版本:实验版本即实验分组,A/B实验通常是为了验证一个新策略的效果。在实验进行中,所抽取的用户被随机地分配到A组和B组中,A组用户体验到新策略,B组用户体验的仍旧是旧策略。在这一实验过程中,A组便为实验组,B组则为对照组。也有多个实验组和一个对照组构成的实验,他们共同承载了100%的流量请求。
用户桶位编号如何生成
如上图说明,现在大家知道一个用户访问某个实验时都会有一个唯一固定的编号。
为了更好阐述其意,假设我们有这样26位流量用户,分别是A-Z的这样26位用户:
{**A , B , C , D , E , F , G , H , I , J , K , L , M , N , O , P , Q , R , S , T , U , V , W , X , Y , Z** }
他们访问实验X时,通过 Hash(uid+实验X种子) 生成了如下的实验编号(命名规则为:用户x_桶位编号):
A_11,B_9,C_12,D_10,E_7,F_9,G_24,H_22,I_18,J_8,K_21,L_15,M_1,N_4,O_76,P_33,Q_40,
R_5,S_12,T_80,U_67,V_25,W_33,X_49,Y_87,Z_100
他们访问实验Y时,通过 Hash(uid+实验X种子) 生成了如下的实验编号(命名规则为:用户x_桶位编号):
A_25,B_17,C_19,D_2,E_1,F_18,G_19,H_22,I_12,J_2,K_22,L_14,M_4,N_16,O_28,P_30,
Q_92,R_93,S_8,T_55,U_18,V_100,W_1,X_100,Y_50,Z_36
通过上面的案例说明,随机的流量用户访问实验时,某些用户生成的桶位编号会一样,那他们就会进入实验的同一个分组里。
实验版本与桶位的关系
一个桶位编号代表全部流量(100%)的一个百分点的流量(1%)
实验分流演示
假设我们一个实验有三个版本即三个分组,分别是 实验组1=VA,实验组2=VB,对照组=VC
初始分组比例为:VA=10%,VB=10%,VC=80%
下一步,我们要将实验组流量扩量,流量分别为:VA=20%,VB=20%,VC=60%
这种扩量后的分流,从分流角度看是ok的,But细心的同学可能会发现之前进入实验组2的用户11-20桶位编号的在进行实验组扩量后,居然...居然...被分配到实验组1。这样就发生了用户跳组的情况,如果接下来继续扩量,一直会存在此类问题:就是进入过实验组2的用户扩量后又被分配到实验组1。
每次都有实验组用户污染的问题,但是运营同事每次调整比例时并不知道后端分配逻辑,他们会想当然认为流量分配是ok的,这种分配方式会造成数据分析问题和用户体验问题,可能比例调整后对其他组的用户进行了污染,这样的结果在业务上是不可接受的
那么... 针对这种情况实际怎么分配会最佳呢,继续往下看。
正确的分流效果图
如上效果图:
VA 版本由原来的10%扩量到20%,正确的分流是:
新增的10%流量来自对照组VC的流量用户即桶位区间是21-30。
扩量后VA的20%流量是由:1-10,21-30的两个桶位区间。
VB版本由原来的10%扩量到20%,正确的分流是:
新增的10%流量来自对照组VC的流量用户即桶位区间是31-40。
扩量后VB的20%流量是由:11-20,31-40的两个桶位区间。
这样的扩量之后不会出现之前那样的流量用户发生跳组,即保证原来的用户进入的哪个版本扩量之后还是之前的版本。
这种的分流优化我们称之为:流量保护,就是我们本篇文章重点介绍的功能。
为什么做流量保护:
答:实验迭代时,增减版本、调整比例是最高频的操作,此时平台采用了【流量保护】功能,即每次修改先识别减少比例的版本,从减少比例的版本的流量拆分给增加比例的版本。最大限度隔离流量,减少实验组之间相互污染;
引入流量保护功能
ab分流亟需解决这种不科学的流量调整问题,升级【流量保护】功能后,再看一组如下实验的版本流量迭代的推演过程(红色代表A组、蓝色代表B组、绿色代表C组)
这样经过多次调整后,每个实验都尽可能的减少了自己区间的变动,保证自己用户的留存性,减少对实验指标的影响
流量保护动画推演
大家可以直接欣赏:四个版本比例调整的推演(可以关注每个版本色块的变化)
从上面的例子可以看出,经过多次的流量调整后,各个实验的区间分布会变得比较复杂,但是从使用者的角度看,他只需要关心每个实验所占的流量配比,不需要关心底层实验流量的区间分布情况(这块对他是黑匣子),因此不会增加使用者操作的难度。
流量保护分配规则
- 对版本比例调整进行分组:比对版本修改前、后的数据。按序识别比例新增、减少、不变的三个变化组
- 将版本减少组的桶位拆分:对减少组版本桶位区间从最右侧拆分、匹配直到满足减少的浮动比例的桶位区间段
- 对拆分的桶位区间排序、移动:对减少组被拆分的桶位区间按从左到右的排序,依次次分配给新增版本
- 对版本变化后的桶位排序、合并: 分配后的所有版本进行桶位区间排序,相邻的桶位区间进行合并操作
作者:京东科技 付浩军
来源:京东云开发者社区 转载请注明来源