灏天阁

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

· Yin灏

背景

为了验证一些想法是否真的有业务价值，往往需要做 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 缓存的文章juejin.cn/post/716307…

缺点：

  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 这样就配完了，解释一下为什么这样配置就可以解决
    2. 当用户初次访问时，肯定没有 cookie，那么自然 55 开分流到 AB
    3. 假设当前被分流到了 B，那么此时会种下 cookie：b=1，用户刷新后，会固定打到 B 集群，这样就可以保证实验结果的真实准确了！

总结

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

- Book Lists -