前端做AB实验的三种分流方式


theme: vue-pro

背景

为了验证一些想法是否真的有业务价值,往往需要做AB实验。

做AB实验,绕不过去的问题就是分流

什么是分流?

  • 比如100个用户访问你的站点的某个path,假如分流是五五开,那么结果就是50个用户看的是A页面,另外的50看的是B页面

常见的三种分流方式

  1. 接口分流
  2. 投放侧分流
  3. nginx层分流

1. 接口分流

原理:

  • 展示AB内容前,先调接口,根据响应的结果渲染A或B

好处:

  • 可以让运营参与配置,无需RD参与,就可以改实验条件

适用场景:

  • 同一个集群内的需求

不适用的场景

  • 不同集群的需求,比如:

    性能优化、内容/流程重构等对代码进行破坏性修改的,这种要做AB实验的话,是需要重新部署到新集群去的。这种接口分流就不再适用,因为2个集群,已经是2套代码了,只能在接口的更上层做分流

缺点:

  1. 对于CSR项目来说,性能伤害比较大,因为要通过http接口,来获得AB信息

  2. 对于SSR项目来说,要做成服务发现去调用,而不是前端去调用,否则也会伤害性能

2. 投放侧分流

原理:

  • 给运营提供AB两个url,让运营去投放平台投放。这个分流其实跟技术方面就没啥太大关系了,但也是一种思路

好处:

  1. 可以做接口分流做不了的AB实验
  2. 还能做nginx层的更上层的CDN缓存的AB实验

适用场景:

  • 可以做接口分流和nginx层分流做不了的场景

不适用的场景

缺点:

  1. 投放平台可能会带来buff加成,导致影响实验真实性

    buff加成的意思是:为了让你更愿意在投放平台投放,在初期可能会有冷启动,给你分配更优质的用户,提升你的转化率

3. nginx层分流

原理:

  • 流量打到对应服务器之前,会先经过nginx层,可以由nginx层把流量分到对应的服务器(集群)上

如何实现?

  • 公司应该有这方面的基建,可以oncall问。否则只能让运维帮忙配置一下

好处:

  1. 可以做接口分流做不了的场景

  2. 可以解决投放侧分流带来的副作用

适用场景:

  • 可以做接口分流做不了的场景

不适用的场景:

  • nginx层更上层的实验,比如CDN缓存的AB实验就做不了

    CDN缓存的AB实验是什么意思?

    • 就是想验证CDN缓存的性能提升到底能为业务带来多少价值。
    • CDN缓存本身还是有不少副作用的,感兴趣的可以翻我之前关于CDN缓存的文章https://juejin.cn/post/7163071012928487431

缺点:

  1. 需要考虑用户刷新的问题(比如:原本展示的是A,刷新后可能会展示B,这样会给实验结果造成点误差)

如何解决这个缺点?

  • 用组合分流

    • cookie分流 + 50%随机分流 (假设我们要55开分流)

    举例:

    1. 假设实验A在A集群,实验B在B集群,我们总的需要配3条nginx配置
      1. 配置1:当cookie:a=1存在时,100%命中A集群

      2. 配置2:当cookie:b=1存在时,100%命中B集群

      3. 配置3:50%命中A集群,50%命中B集群

      4. 再加上前端的代码改造,A集群的代码会写入cookie:a=1,B集群的代码会写入cookie:b=1

    这样就配完了,解释一下为什么这样配置就可以解决

    1. 当用户初次访问时,肯定没有cookie,那么自然55开分流到AB

    2. 假设当前被分流到了B,那么此时会种下cookie:b=1,用户刷新后,会固定打到B集群,这样就可以保证实验结果的真实准确了!

总结

总的来说,各有优缺点和适用场景,大家可以根据自己业务需求,考虑对应的方案


码字不易,点赞鼓励!!

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容