Griffin Chow / A/B测试搭建

Created Sat, 05 Oct 2024 00:00:00 +0000 Modified Thu, 06 Nov 2025 04:24:59 +0000
3872 Words
数据分析 A/B测试

A/B测试完整业务流程

# AB Test业务流设计

## 发起实验 By 产品
### 做出假设
- 版本差异点
- 衡量指标

### 创建实验【后台】
- 实验名称
- 版本ABC
- 确定衡量指标
- 实验分层
- 特殊分流需求
- 实验端设置

## 配置实验 By 研发
- 实现版本差异
- 确认能收集到数据
- 确认分流
- 确认分层

## 开始实验 By 产品【后台】
- 确认开始实验
- 查看实时数据
- 调整流量比例
- 白名单设置及开关

## 结束实验 By 研发
- 结束实验【后台】
- 回收实验数据【后台】
- 输出实验结论
- 确定线上版本
  1. 发起实验，主要是产品或运营，设定好测试目标
  2. 配置实验，即通过选择合适的AB测试工具，实现AB版本的差异以及数据收集等
  3. 开始实验，即实验上线，包括了在实验过程中一些流量比例的管理，查看实时数据等
  4. 结束实验，即实验有结果以后，结束实验

A/B测试的五大核心模块

  1. 流量分组模块

    可以说流量分组模块是A/B测试最核心的模块，好的分组方案可以让流量分配得更加均匀随机，同时需要兼容用户、地域、时间、版本、系统、渠道、渠道、事件等各维度来对请求进行分组的能力，并且保证分组的均匀性和一致性

    在推荐系统中，有两种主要的推荐范式：

    • 完全个性化范式：就是需要为每个用户生成个性化推荐，这个时候我们可以选择对用户进行随机分组
    • 标的物关联标的物范式：如果对标的物进行随机分组，可能就会存在一个问题：因为不同的标的物是不一样的，有些是热门的，有些是冷门的，可能存在分配不均的现象；这个时候，可以采用基于时间的分配策略，某段时间标的物分配到A组，另一段时间分配到B组，只要保证分到AB两组的时间是公平的即可（比如第一天分到A组，第二天分到B组）【注：此算法已申请相关专利】

    在流量分组模块，可以创新的地方有很多，如果创新点在大量试验中使用并得到验证，是可以申请相关专利的

  2. 实验管理模块

    实验管理模块的目的是让产品经理、运营人员或者开发人员方便快速的创建A/B测试案例，包括：实验名称、实验周期、实验指标、增加分组、调整每组的流量比例等实验基本信息的设置；同时，也用于管理A/B测试平台用户创建、权限管理，让用户具备编辑、拷贝、使用A/B测试实验的能力，做到高效易用

  3. 业务接入模块

    A/B测试平台的业务接入模块主要是用来与其他业务系统进行对接，让业务系统能够方便地调用A/B测试平台的服务，实现A/B测试的实际应用；这个模块具有高效性、易用性和扩展性，是整个A/B测试平台的重要组成部分

    一般来说，通过提供一个A/B测试SDK或者Restful接口的形式供业务方使用：

    • SDK（Software Development Kit）接口是指为开发人员提供的一种编程工具包，通常包含了接口文档、示例代码、库文件等，使开发人员能够快速方便地开发某项功能；在A/B测试中，SDK接口通常指的是与A/B测试平台对接的API接口，用于实现其他业务系统与A/B测试平台之间的数据通信
    • RESTful接口是一种使用HTTP协议来实现Web Services的软件架构风格，它是一种设计Web API的标准，使得Web API易于理解、开发和使用，并且能够很好地支持分布式系统的开发
    • SDK接口与restful接口主要的区别在于：
      • SDK接口和RESTful接口是两种不同的接口类型，它们在功能、用途和实现上有很大的区别
      • SDK接口是一种软件开发工具包，通常用于简化开发者的工作流程，提供各种服务和功能，方便开发者快速完成项目开发；RESTful接口是一种面向资源的Web API，通过HTTP协议实现，它提供了一种统一的、标准的、简单的数据交互方式，便于多个系统之间的互相协作
      • 总的来说，SDK接口适用于客户端的开发，而RESTful接口适用于多个系统之间的数据交互

  4. 行为记录分析模块

    行为记录分析模块包含A/B测试行为数据埋点、数据收集、数据分析和数据可视化展示等子模块

    行为记录分析模块主要的目的是当某个产品功能的AB测试在线上运行时，记录用户在AB测试模块的行为，将用户的行为收集到数据中心，借助大数据分析平台来做各种效果评估指标的统计分析与评估，最终确定新的优化点是否是有效的

    注意：在业务实现上，需要前端在用户访问做A/B测试页面的过程中过记录做A/B测试的业务标识及对应的方法(策略)标识

    因为在一段时间或者在同一时间整个产品中会有各类AB测试在运行，只有记录了对应的业务和策略，我们在数据分析时才能更好的区分一条日志到底是哪个业务上的哪个策略产生的；最终方便我们将整个AB测试的效果评估、指标分析及可视化做到全自动化，提升整个AB测试迭代的速度

  5. 效果评估模块

    A/B测试效果评估模块主要用于跟踪A/B测试的效果，根据A/B测试效果来做出业务、运营、算法调整的决策

    在效果评估部分，衡量指标的确定是非常重要的一环，一般来说，A/B测试要评估出A方案和B方案的好坏，可以选择人均播放量、人均点击量、人均浏览次数、转化率、CTR等指标来评估

    具体效果评估指标的定义需要根据自身公司行业特性、产品形态、功能点等来定义，核心要点是指标能够量化，并且能够直接或者间接跟产品体验、用户增长、商业变现等公司整体目标联系起来

    衡量指标最好也可以直接嵌入到整个模块中，自动化地实现计算及评估

业界流行的AB测试架构实现方案

AB测试架构图

方案1：在客户端整合 A/B 测试能力

  • 该方案主要是通过定制的 AB test SDK 来处理 A/B 测试业务。在这个方案里，需要开发 A/B test SDK，并将 SDK 整合到前端，通过 AB Test SDK 与 A/B 测试服务（核心分组模块）交互来处理 A/B 测试相关功能。
  • 具体 A/B 测试服务与业务接口的交互实现方式可以是如下两种之一：
    1. A/B 测试服务下发两个不同的接口给 A/B 测试 SDK，当用户请求时，根据用户的分组，分别调用不同的接口。
    2. A/B 测试服务下发一个接口给 A/B 测试 SDK，但是不同的分组对应的参数不同，当用户请求时，根据用户所在的分组，选择不同的参数来访问该接口（该接口会根据不同的参数获取不同的数据）。
  • 采用该方案的公司主要有微博等，具体架构如下图： SDK处理AB-test逻辑架构：微博采用
  • 该方案的优劣势主要是：
    • 优点：可以通过统一的 SDK 来对接 A/B 分组服务，前端业务代码简单调用 SDK 的方式就可以，开发效率高、灵活性也比较高，可以根据自己的需求定制化开发，更符合业务需求
    • 缺点：SDK 可能需要额外的内存和 CPU 资源，这可能会影响业务系统的性能；此外，如果 A/B 测试业务有调整，需要升级 SDK，可能会带来额外的开发和维护成本；同时，如果公司有 iOS、Android、PC 等多个业务的话，需要开发多套 SDK，维护成本较大

方案2：在接口层整合 A/B 测试能力（统一 Router vs Web 接口层）

第一类：A/B 两组对比测试业务分别部署在不同的服务器，通过构建一层统一的 router 来分发流量（即通过后端统一 Router 模块来处理 A/B 测试相关请求）

统一 Router 指的是在分布式系统架构中的一种技术，它的作用是将请求路由到正确的服务器上，使用户能够在不知道具体服务器地址的情况下访问系统

统一 Router 通过预先配置路由规则，将请求从用户端转发到对应的服务器上

这种方案可以实现服务器的负载均衡和故障转移，提高系统的稳定性和可用性

  • 采用该方案的公司主要有 Google、百度等，具体架构如下图所示： 统一Router处理AB-test逻辑架构：Google、百度等采用

  • 该方案的优劣势主要是：

    • 优点：模块化，router 解决所有与 A/B 测试相关问题，对 A/B 测试业务做调整不需要前端版本升级，只需要升级后端服务即可
    • 缺点：Router 层成为整个 A/B 测试的核心，对 Router 层的要求就会比较高，需要高并发可用的能力，如果能力跟不上则会影响 A/B 测试能力的发挥

第二类：将 A/B 两组对比测试业务实现逻辑写在同一个业务接口，全部业务逻辑在业务服务器完成，即可通过构建 A/B lib（比如构建一个处理所有 A/B 测试业务逻辑的 jar 包）模块来处理 A/B 测试相关业务

  • 采用该方案的公司主要有大众点评等，具体架构如下图所示： 接口层处理AB-test逻辑架构：大众点评等采用

当用户使用产品触发做 A/B 测试的功能时，前端调用统一的接口，接口层通过 A/B lib 跟 A/B 测试服务交互获取该请求对应的分组，并从对应的数据存储中获取数据，组装成合适的格式返回给用户

  • 该方案的优势劣势主要是：
    • 优点：当 A/B 测试调整时也不需要前端做升级，只需要修改 A/B lib 包就可以了，比较方便快捷
    • 缺点：如果公司采用多种开发语言做业务接口服务，需要每种开发语言维护一套 A/B lib 库，维护成本较高；另外 A/B 测试逻辑调整需要升级 A/B lib 包时，需要对所有在线上接口做升级，明显增加了风险；同时，在接口服务中整合 A/B lib 与 A/B 测试服务交互，增加了接口服务的复杂度，如果 A/B 测试服务有问题，可能会影响接口功能或者性能

方案3：在后端业务层实现 A/B 测试能力

该方案通过在具体业务中整合 A/B 测试能力来做 A/B 测试，该方案比较适合算法类（推荐算法、搜索算法、精准投放、精准运营等）相关业务做 A/B 测试

具体架构如下图所示：

  • 采用该方案的公司主要有大众点评等，具体架构如下图所示： 业务层处理AB-test逻辑架构

需要做 A/B 测试的业务模块通过调用 A/B 测试服务来实现 A/B 测试能力，具体 A/B 测试的实现放在业务中实现（如在推荐场景中，推荐程序在为用户计算推荐结果过程中访问 A/B 测试服务，确定用户对应的分组）；在实际操作中，为了提升 A/B 测试落地效率，可以将这些处理 A/B 测试的操作或者模块封装成 Jar 包，方便各个业务方共用

  • 该方案的优势劣势主要是：
    • 优点：以推荐场景来说，前端和接口层不做任何处理，只需在业务中实现 A/B 测试能力，并且不需要根据 A/B 两组分别对全量用户计算推荐结果，也不需要为全量用户分别存储 A/B 两个算法的推荐结果，大大减少计算时间和存储开销
    • 缺点也是很明显的：
      1. 依赖性强：因为该方案要求算法业务层实现 A/B 测试功能，所以在算法业务层没有很好地实现 A/B 测试功能时，将影响 A/B 测试效果
      2. 维护复杂：该方案要求算法业务层和 A/B 测试服务双方交互，所以维护起来较为复杂
      3. 扩展性差：因为该方案依赖于算法业务层的实现，所以如果在未来需要增加其他的功能时，将需要对算法业务层进行修改