第1章 A/B测试的价值与适用场景
A/B测试（分流实验）是产品需求验证的核心工具之一。本章明确其适用边界、前置条件与常见误解，帮助团队在正确场景下启动实验，避免资源浪费。
1.1 适用场景
A/B测试并非万能，以下场景可充分发挥其价值：
- 产品需求验证：新功能、UI改版、算法策略上线前，通过对比实验验证是否带来正向业务指标。
- 假设驱动：针对用户行为或业务瓶颈提出明确假设，通过实验证伪或证实。
- 灰度发布：逐步放量至100%，监控核心指标变化，降低全量发布风险。
- 决策依据：替代“拍脑袋”或“竞品分析”，用数据驱动优先级排序与方案选择。
关键判断标准：只有当实验对象可随机分组、干预可隔离、指标可测量时，A/B测试才优于其他验证方法。
1.2 前置条件
| 维度 | 条件说明 |
|---|---|
| 随机化 | 用户或样本可无偏分配到实验组/对照组，且组间独立。 |
| 样本量 | 预期效应量、显著性水平（α=0.05）与统计功效（80%）下，样本量满足最小要求。 |
| 测量指标 | 有明确的北极星指标或核心OEC，且收集链路完整无中断。 |
| 实验周期 | 能覆盖用户自然行为周期（如一周），避免新奇效应影响。 |
| 技术可行性 | 分流系统、埋点上报、实时或离线分析管道已就绪。 |
1.3 操作步骤：A/B测试适用性判断流程
- 明确业务目标：将抽象需求转换为可量化的指标变化（如DAU、转化率、留存）。
- 提出可验证假设：例如“将注册页面按钮由红变绿能使注册率提升2%”。
- 检查随机化条件：是否存在网络效应（如社交产品）导致组间污染？
- 估算所需样本量：使用公式或工具（如Evan Miller样本计算器）验证是否可在预期时间内积累。
- 确定核心指标与护栏指标：明确胜利标准，并置入负向指标（如加载时长）防止副作用。
- 评估技术投入成本：开发、运维、分析资源是否可支撑实验全流程。
- 决策：若所有条件满足 → 进入实验设计阶段；否则选择替代方法（如问卷、日志分析、仿真）。
1.4 输入输出物
| 类型 | 内容 |
|---|---|
| 输入 | 产品需求文档、业务数据、用户分层、技术架构说明、历史实验记录 |
| 输出 | A/B测试可行性检查清单、适用性决策表（含是否进入实验的结论及理由） |
1.5 责任边界
- 产品经理：把控需求价值，提出可验证假设，协调资源。
- 数据工程师/算法：评估分流可行性，准备埋点与指标计算。
- 分析师：完成样本量预估，设计最小实验单元与显著性阈值。
- 工程开发：实现版本切换逻辑，确保隔离性。
- 决策委员会（如VP/总监）：批准实验灰度范围与时间窗口。
1.6 记录材料
每次实验开始前填写以下检查清单（示例格式）：
| 检查项 | 状态 | 备注 |
|---|---|---|
| 业务目标已量化 | ☐ | 例如：提升详情页点击率2% |
| 假设可证伪 | ☐ | |
| 随机化无污染 | ☐ | 如存在强社交网络则不适用 |
| 样本量足够 | ☐ | 根据历史均值计算 |
| 指标埋点确认 | ☐ | 前端/后端埋点均已上线 |
| 技术人力到位 | ☐ | 开发与QA工期已排期 |
| 伦理合规 | ☐ | 不侵犯用户隐私，不涉及敏感群体 |
1.7 异常处理
常见异常与应对：
- 样本量不足 → 延长实验周期、降低效应量设定、改用MAB（多臂老虎机）或准实验设计。
- 指标波动剧烈 → 引入CUPED（方差缩减）、增加滚动样本段对比。
- 分流冲突 → 检查同一用户是否同时进入多个实验（分层分流），实施互斥域。
- 技术事故 → 设置暂停机制，降级为A/A测试或回滚逻辑。
- 伦理风险 → 禁止对涉及用户公平、隐私、安全的变体做实验。
1.8 验收标准
完成本章学习后，团队应能输出以下成果：
- 文档：一份填写完整的《A/B测试适用性检查清单》。
- 判断结论：针对给定的业务需求，明确写出“适合A/B测试”或“不适合A/B测试”，并列出至少3条支撑理由。
- 决策树：参照下文的SVG流程图，可复述每个决策节点的关键条件。