增长实验室-ab分流的流量保护功能介绍 | 京东云技术团队

介绍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组)

这样经过多次调整后,每个实验都尽可能的减少了自己区间的变动,保证自己用户的留存性,减少对实验指标的影响

流量保护动画推演

大家可以直接欣赏:四个版本比例调整的推演(可以关注每个版本色块的变化



从上面的例子可以看出,经过多次的流量调整后,各个实验的区间分布会变得比较复杂,但是从使用者的角度看,他只需要关心每个实验所占的流量配比,不需要关心底层实验流量的区间分布情况(这块对他是黑匣子),因此不会增加使用者操作的难度

流量保护分配规则

  • 对版本比例调整进行分组:比对版本修改前、后的数据。按序识别比例新增、减少、不变的三个变化组
  • 将版本减少组的桶位拆分:对减少组版本桶位区间从最右侧拆分、匹配直到满足减少的浮动比例的桶位区间段
  • 对拆分的桶位区间排序、移动:对减少组被拆分的桶位区间按从左到右的排序,依次次分配给新增版本
  • 对版本变化后的桶位排序、合并: 分配后的所有版本进行桶位区间排序,相邻的桶位区间进行合并操作

作者:京东科技 付浩军

来源:京东云开发者社区 转载请注明来源

微软推出全新“Windows App” .NET 8 正式 GA,最新 LTS 版本 小米官宣 Xiaomi Vela 全面开源,底层内核为 NuttX 阿里云 11.12 故障原因曝光:访问密钥服务 (Access Key) 异常 Vite 5 正式发布 GitHub 报告:TypeScript 取代 Java 成为第三受欢迎语言 悬赏十几万元以用 Rust 重写 Prettier 向开源作者提问“项目还活着吗”非常粗鲁且无礼 字节跳动:利用 AI 自动调优 Linux 内核参数 运营商神操作:后台断网、停用宽带账号,强迫用户更换光猫
{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/4090830/blog/10149304