A/B 测试基本概念详解

统计基础 · 分层 · 分流 · 术语 | 阅读约 12 分钟
本文从零开始,系统讲解 A/B 测试的核心概念:是什么、怎么分层、怎么分流、以及所有你需要知道的基础术语。适合作为实验平台新人的第一份阅读材料。

一、什么是 A/B 测试

一句话定义
A/B 测试是一种通过随机对照实验来量化因果效应的方法。将用户随机分为两组(或多组),一组保持原样(对照组),一组应用新策略(实验组),通过对比两组的行为指标差异,来判断策略是否有效。

1.1 为什么需要 A/B 测试

不用 A/B 测试的常见误区:

误区问题
"上线后看指标涨没涨"无法排除时间趋势(如节假日、季节性波动)
"和去年同期对比"市场环境、用户构成已完全不同
"问用户喜不喜欢"用户说的和做的不一致(表态偏差)
"产品经理拍板"主观判断无量化依据
核心价值
在保持所有其他条件不变的情况下,只改变一个变量,从而建立因果关系。

1.2 A/B 测试 vs 其他实验方法

方法做法适用场景
A/B 测试用户随机分为 A/B 两组在线产品优化,用户独立
A/A 测试两组都是对照组(验证系统)测试分流系统是否有偏差
A/B/N 测试多于两个实验组同时对比多个策略变体
多变量测试(MVT)同时测试多个变量组合页面布局:标题按钮图片
Interleaving同一用户交替看到两组结果搜索/推荐排序对比
Switchback 实验同一群体按时间段切换策略有时序效应的场景(如定价)

1.3 完整生命周期

一个 A/B 实验从提出到上线,完整的流程如下:

flowchart TD A[提出假设] --> B[设计实验] B --> C[确定样本量] C --> D[配置分流] D --> E[上线运行] E --> F{SRM 检验通过?} F -->|否| G[排查分流系统] G --> D F -->|是| H[收集数据] H --> I{达到所需样本量?} I -->|否| J{序贯检验边界?} J -->|否| H J -->|是| K[统计分析] I -->|是| K K --> L{显著且效应量足够?} L -->|是| M[灰度全量上线] L -->|否| N[存档结论, 迭代假设]

二、A/B 测试的核心要素

每个实验都可以拆解为四个基本维度:

实验 = 人群 × 策略 × 指标 × 时间

  人群(Who)      哪些用户参与实验?
  策略(What)     改变了什么?(UI、算法、定价...)
  指标(How)      用什么衡量效果?
  时间(When)     实验运行多久?

2.1 实验单元(Experimentation Unit)

定义
实验中独立随机分配的最小单元。
实验单元类型示例适用场景
用户 IDuser_id绝大多数产品实验
设备 IDdevice_id未登录用户、客户端策略
会话 IDsession_id单次体验优化(如新用户引导)
集群城市、店铺、社区有网络效应的场景
选型建议
用户 ID vs 设备 ID:用户 ID 用于跨端一致体验和长期策略;设备 ID 用于未登录态策略,但换设备可能进不同组。登录后优先用 user_id 分流。

2.2 实验组设计

组别英文说明
对照组Control保持原策略不变,是效果对比的基准
实验组Treatment应用新策略

当有多个候选策略时,可以设置多个实验组(A/B/N):

Control:      基准策略
Treatment A:  策略变体 A
Treatment B:  策略变体 B
Treatment C:  策略变体 C

三、分流机制详解

什么是分流
分流(Traffic Splitting)是将进入系统的用户按照预定规则分配到不同实验组的过程。它要求三个核心性质:随机性(每组概率均等)、一致性(同一用户始终同组)、均匀性(各组特征均衡)。

3.1 哈希分流算法

业界最通用的做法是基于哈希函数的分流,核心公式:

$$bucket = Hash(salt + user\_id + layer\_id) \ \% \ N$$

参数说明:

  • salt — 固定随机种子,防止被逆向
  • user_id — 用户唯一标识
  • layer_id — 实验所在的层 ID
  • N — 总分桶数(如 10000,每桶代表 0.01% 流量)

3.2 哈希 vs 随机数

方法一致性性能可复现
随机数每次调用可能不同需要存储映射不可复现
哈希同一用户永远同一桶O(1) 计算完全可复现
为什么用哈希?
同一用户每次调用哈希得到相同结果 → 用户体验一致;不需要存储"用户属于哪个组"的映射表 → 系统无状态。推荐使用 MurmurHash3FarmHash 等分布均匀的非加密哈希。

3.3 分桶与分配

                 用户请求
                     |
                  哈希计算
                  bucket ∈ [0, N)
                     |
               查分桶映射表
                   │
          ┌────────┴────────┐
      桶 0-999          桶 1000-1999
      对照组             实验组
      50%                50%

实际配置示例:

{
  "experiment_id": "exp_001",
  "layer_id": "layer_homepage",
  "buckets": [0, 9999],
  "groups": [
    {"name": "control",   "range": [0, 4999],    "ratio": 0.50},
    {"name": "treatment", "range": [5000, 9999], "ratio": 0.50}
  ]
}

3.4 分流一致性

注意
用户可能通过多端(App、Web、小程序)进入系统:登录态用统一 user_id 保证跨端一致;未登录态用设备 ID,但换设备可能进入不同组(可接受的局限性);登录后优先用 user_id 回溯。

3.5 灰度分流

新策略不应一次全量上线:

实验期(1-2 周)  │  灰度期(1-2 周)  │  全量期
                  │                    │
    5% 流量       │  10%→30%→50%      │  100%
                  │                    │
   · 验证策略有效  │  · 验证系统稳定性   │  全量上线
                  │  · 验证网络效应     │
                  │  · 业务指标确认     │

四、分层机制详解

什么是分层
分层(Layering)是让同一批用户同时参与多个独立实验的机制。每层拥有独立的哈希空间,用户在不同层被分配到不同的桶,层与层之间正交(独立)。

4.1 为什么需要分层

产品团队同时需要多个实验(首页改版 + 推荐算法 + 定价策略),分层将流量空间切成多层,每层给一个实验使用:

用户流量(100%,10000 个桶)

  Layer 1:首页实验 → 100% 流量,control: 0-4999 / treatment: 5000-9999
  Layer 2:推荐实验 → 100% 流量,control: 0-4999 / treatment: 5000-9999
  Layer 3:定价实验 → 100% 流量,control: 0-4999 / treatment: 5000-9999
  Layer 4:空闲保留
正交性
用户在 Layer 1 被分到实验组,与在 Layer 2 被分到实验组,是完全独立的事件。因为各层使用不同的 layer_id 参与哈希计算。

4.2 独占层 vs 正交层

类型英文说明适用场景
独占层Exclusive Layer同一时段只能运行一个实验可能与其他实验强交互的策略(如定价)
正交层Orthogonal Layer多个实验共享,各自取一部分流量互不干扰的 UI/算法实验

4.3 层间干扰

典型场景
层 1(首页改版)改变了流量分发结构 → 层 2(推荐算法)的效果提升可能来自首页流量变化而非算法本身。对于这种情况,上游放独占层,下游正交层交叉分析时加入上游实验组作为协变量。

4.4 典型分层架构

Layer 1:独占层 — 核心策略(定价、会员)
  流量 100%  |  实验数 1  |  隔离:独占

Layer 2:正交层 — UI/交互(按钮、布局、文案)
  流量 100%  |  实验数多个  |  隔离:正交

Layer 3:正交层 — 算法策略(推荐、搜索、Feed)
  流量 100%  |  实验数多个  |  隔离:正交

Layer 4:正交层 — 运营策略(优惠券、推送、弹窗)
  流量 100%  |  实验数多个  |  隔离:正交

Layer N:保留层 — 临时实验、紧急测试

五、流量分配模型

5.1 三种分配模式

模式做法优缺点
独享流量为实验预留专用流量干净、易分析;流量利用率低
共享流量(正交)多个实验正交共享利用率高;需注意层间交互
混合模式核心实验独占层 + UI/算法共享正交层平衡隔离性与利用率

5.2 决策框架

该实验和其他运行中的实验有交互风险吗?
  ├─ 是 → 独占层,排队运行
  └─ 否 → 需要多少流量?
          → 根据 Power Analysis 计算最小样本量
          → 加 20-30% 缓冲(考虑数据质量问题)
          → 在正交层中分配相应比例流量

5.3 并行容量

$$并行实验数 = \frac{正交层数 \times 每层平均实验数}{1} + 独占层数$$

一个拥有 3 个正交层(每层 100% 流量,每个实验平均占 10% 流量)的系统,理论上可以同时运行 $3 \times 10 = 30$ 个小流量实验。

碎片化风险
过多小流量实验 → 每个样本不足 → 统计学意义降低;流量被切太碎 → 无"净流量"可用。需要建立流量预算实验优先级审批机制。

六、核心术语表

6.1 实验设计术语

术语英文定义
实验单元Experimentation Unit随机分配的最小粒度(用户/设备/会话)
对照组Control Group保持原策略不变的组
实验组Treatment Group应用新策略的组
分流Traffic Splitting将用户分配到不同实验组的过程
哈希分流Hash-based Splitting基于哈希函数的一致性分流方法
分层Layering将流量空间切割为多层以支持并行实验
正交层Orthogonal Layer多实验共享、互相独立的层
独占层Exclusive Layer同一时段只能运行一个实验的层
灰度发布Gradual Rollout从低流量逐步增加到全量的发布策略
分桶Bucketing将流量按哈希值分成 N 个等分桶

6.2 统计分析术语

术语英文定义
原假设Null Hypothesis ($H_0$)"实验组与对照组无差异"的假设
备择假设Alternative Hypothesis ($H_1$)"实验组与对照组有差异"的假设
p 值p-value在 $H_0$ 为真时,观察到当前或更极端结果的概率
显著性水平Significance Level ($\alpha$)拒绝 $H_0$ 的阈值(通常 0.05)
统计功效Statistical Power ($1-\beta$)真有效应被检测出的概率
第一类错误Type I Error无效应但误判为显著(假阳性)
第二类错误Type II Error有效应但未能检测出来(假阴性)
MDEMinimum Detectable Effect在给定样本量和功效下能检测到的最小效应
效应量Effect Size策略带来的实际变化幅度的标准化度量
置信区间Confidence Interval参数真值的区间估计
多重比较Multiple Comparison同时检验多个假设导致的假阳性膨胀

6.3 实验质量术语

术语英文定义
AA 测试AA Test两组都是对照组的假实验,用于验证系统无偏
SRMSample Ratio Mismatch实际分流比例与设计比例不一致
新奇效应Novelty Effect用户因新鲜感产生的短期行为变化
爬行效应Creep Effect小流量验证的策略在大流量下效果衰减
幸存者偏差Survivorship Bias留在实验中的用户不代表全体用户
辛普森悖论Simpson's Paradox分组看和整体看结论相反的统计现象
护栏指标Guardrail Metrics不能显著恶化的底线指标
OECOverall Evaluation Criterion复合决策的核心评估指标
实验饥饿Experiment Starvation实验数量超过系统承载能力

6.4 分流量化指标

指标含义计算方式
分流均匀性各组用户量是否一致$|N_T - N_C| / (N_T + N_C) \leq 1\%$
哈希分布均匀性哈希值的分布是否均匀卡方检验各桶的均匀性
实验纯净度真正进入实验的用户比例$N_{实际进入} / N_{分配到组}$
污染率对照组接触到了实验策略的比例通过技术埋点检验

七、Feature Flag 与 A/B 测试的关系

什么是 Feature Flag
Feature Flag(功能开关)是一种允许你在不重新部署代码的情况下,通过配置来远程控制功能"开"或"关"的技术手段。代码层面本质上就是一层 if 判断。
# 传统方式:代码部署即生效,风险不可控
def homepage():
    return render_new_homepage()

# Feature Flag 方式:开关控制,随时可关,秒级生效
def homepage():
    if feature_flag.is_enabled("new_homepage", user_id):
        return render_new_homepage()
    else:
        return render_old_homepage()
传统上线:
  写代码 → 部署 → 所有人立刻看到新功能
                    → 出问题只能回滚(慢,影响范围大)

Feature Flag 上线:
  写代码(包在 if 里)→ 部署 → 通过配置逐步打开
                              → 随时可关,秒级生效

7.1 Feature Flag vs A/B 测试

维度Feature FlagA/B 测试
目的控制功能的发布风险量化功能的因果效果
核心问题"功能上线安全吗?""功能有效吗?"
分组逻辑按比例逐步放量(0%→10%→50%→100%)随机分为对照组和实验组,对比差异
决策依据系统稳定性、报错率、性能用户行为指标的统计显著差异
关停策略全量稳定后移除开关代码实验结束后产出明确结论
典型时长全量后开关存活数天到数周实验运行 1-4 周

7.2 职责边界

Feature Flag 分流:
  user_id → Flag 配置 → ON / OFF
  目的:控制谁能看到某个功能
  结果:用户看到的是"新功能"还是"老功能"
  场景:灰度发布、紧急关停、运营开关

A/B 实验分流:
  user_id → 分层哈希 → 对照组 / 实验组
  目的:将用户随机分配到无偏的对比组
  结果:分析"新功能"相比"老功能"的因果效应
  场景:策略效果验证

7.3 协同工作流

1. 开发新功能 → 用 Feature Flag 包裹代码
2. 先开 1% 流量 → 确认无技术问题(纯 Flag 阶段)
3. 开 10% 流量 → 启动 A/B 测试(Flag + 实验阶段)
     5% 对照组(Flag = OFF)→ 老体验
     5% 实验组(Flag = ON) → 新体验
4. 实验显著 + 护栏指标正常 → 逐步放量 50% → 100%
5. 全量稳定运行 2 周 → 移除 Flag 代码(清理 if 判断)
                                     ↑
                           这一步常被遗忘,导致代码腐烂
Flag 必须清理
长期存活的 Flag 让代码逻辑组合爆炸(2 个 Flag = 4 种路径,3 个 = 8 种…),增加测试和维护负担。已全量的 Flag 就是"死代码"。

7.4 典型使用场景

场景说明
灰度发布(Canary Release)新功能先给 1% 用户,观察无异常后逐步扩大
Kill Switch(紧急关停)线上出问题时,秒级关闭功能,不需要回滚部署
A/B 测试基础设施Flag 作为分组机制,提供"谁进入新功能"的能力
运营开关大促活动到达指定时间自动开启/关闭
租户/白名单仅对特定用户(内部员工、VIP)开启
权限控制按套餐等级控制功能可见性

7.5 业界实现模式

模式做法典型工具
配置中心驱动Flag 存配置中心(Etcd/Consul),应用定期拉取自研配置中心
SaaS 服务商业 Feature Flag 服务,SDK 实时获取状态LaunchDarkly, Statsig
开源自建自建 Flag 评估服务 + 管理后台GrowthBook, Unleash
统一平台Feature Flag + A/B 实验在同一平台管理Statsig, Eppo, GrowthBook
最佳实践
统一平台的优势:Flag 的 ON/OFF 状态可以直接映射为实验的对照组/实验组,无需两套系统手动对齐分流比例。现代实验平台(Statsig、GrowthBook)都将 Feature Flag 和 A/B 测试整合在一起。

附录:典型 A/B 实验配置

{
  "experiment_id": "exp_homepage_redesign_2026",
  "name": "首页改版实验",
  "hypothesis": "简化首页布局可以提高核心区域的点击率",
  "owner": "growth_team",
  "layer_id": "layer_homepage",
  "layer_type": "exclusive",
  "traffic_percentage": 10,
  "buckets_total": 10000,
  "groups": [
    {
      "name": "control",
      "description": "当前首页",
      "bucket_range": [0, 4999],
      "ratio": 0.50
    },
    {
      "name": "treatment",
      "description": "简化版首页",
      "bucket_range": [5000, 9999],
      "ratio": 0.50
    }
  ],
  "metrics": {
    "primary": "ctr_core_module",
    "secondary": ["avg_session_duration", "bounce_rate"],
    "guardrail": ["page_load_time", "crash_rate", "complaint_rate"]
  },
  "parameters": {
    "mde": 0.02,
    "alpha": 0.05,
    "power": 0.80,
    "min_sample_size_per_group": 50000,
    "estimated_duration_days": 14
  }
}

关键要点总结

核心思想
A/B 测试的本质是通过随机化消除混淆,建立因果推断。它不是简单的"看看哪个更好",而是一套完整的统计推断方法论。
#1 随机分流
哈希分流保证一致性:同一用户永远同一组,系统无状态。
#2 正交分层
多层并行实验互不干扰,每层用不同 layer_id 哈希。
#3 统计严谨
先算样本量再跑实验,SRM 检验、p 值、置信区间一个不能少。
#4 灰度发布
5%→10%→50%→100%,用 Feature Flag 做开关,随时可回滚。