AB 实验治理完整手册

本文基于理想汽车中台运营部实习期间的实验治理经验，结合电商场景的 UK Retail II 数据实现。核心价值：将 AB 实验从"随意跑"变成"有纪律地跑"，让每一个实验结论经得起统计学检验。

为什么实验治理如此重要

没有治理的 AB 实验，比没有 AB 实验更危险。

在理想汽车实习期间，我亲眼见过两个真实案例：

这两个案例让我深刻理解：AB 实验不只是"跑个 t 检验"，而是一个需要多层质量关卡的治理体系。

实验治理三层架构

第一层：实验前 — 设计审查

| 检查项 | 标准 | 本项目的实现 | |--------|------|------------| | 样本量预估 | 双比例 z 检验，α=0.05, power=0.8 | lib/sample-size.ts — calcSampleSize() | | MDE 设定 | 相对提升 ≥ 当前波动水平的 2 倍 | 实验页可调 MDE 参数 | | 分流机制 | 哈希分流 + 分层抽样（按关键维度分层） | 需在实验系统中配置 | | 主指标定义 | 唯一、可量化、与业务目标对齐 | lib/tools.ts — getMetricDefinition() |

理想汽车实操：每次实验申请必须在「实验申请表」中填写以上四项，否则不批准上线。这个表格模板在 workflow/ab-experiment-application.md。

第二层：实验中 — 实时监控

| 检查项 | 检测方法 | 本项目实现 | |--------|---------|-----------| | SRM 检测 | 卡方检验，p<0.001 报警 | lib/significance.ts — srmCheck() | | 护栏指标 | 监控实验组是否有异常（如 GMV 暴跌） | app/diagnose/page.tsx 异常检测 | | 数据质量 | 每日检查分流比例 + 样本量增速 | 监控看板 Dashboard |

SRM 为什么阈值设 p<0.001 而不是 p<0.05？ 因为 SRM 是「一票否决」——一旦报警就表示实验结论不可靠，需要立即排查。降低误判概率（更严格的阈值）可以避免因随机波动而错误中止实验。

第三层：实验后 — 多维复盘

| 检查项 | 检测方法 | 本项目实现 | |--------|---------|-----------| | 显著性检验 | 双比例 z 检验，p 值 + 95% CI | lib/significance.ts — zTest() | | 辛普森悖论 | 关键维度分层检验 | app/review/page.tsx 多维下钻 | | 实际收益 | 相对提升 + 绝对提升 + 置信区间 | 复盘页实验结果卡片 | | 状态流转 | 实验前后用户状态分布对比 | lib/state-flow.ts — 状态机 |

理想汽车实操：每次实验结束后，必须生成一份包含以上四项的复盘报告，我设计了这个报告的模板格式（后来成为部门标准）。

常见错误与避坑指南

错误 1：不看 SRM 就下结论

后果：实验结论可能完全错误（分流偏差导致） 检测：实验上线 24 小时内跑一次 SRM

错误 2：只看总体不看分层

后果：辛普森悖论——总体好不代表各层都好 检测：复盘时按省份/渠道/用户分群逐层下钻

错误 3：p<0.05 就庆祝

后果：p 值只告诉你"不太可能是随机"，不告诉你"效果到底多大" 正确姿势：看相对提升 + 95% 置信区间 + 实际业务收益（不是统计显著就算赢）

错误 4：样本量不够硬跑

后果：实验跑出来不显著，但其实是样本量不够，不是策略无效 正确姿势：上线前用样本量计算器跑一遍，不够就不上线

面试时怎么讲

在理想汽车实习期间，我发现业务团队做 AB 实验存在两个系统性问题：第一，不检查 SRM（样本量比例失调），导致多次实验结论后来发现不可靠；第二，只看总体效果不看分层，容易掉进辛普森悖论的坑。

我推动了三个改进：引入 SRM 检测作为实验上线的必须关卡（p<0.001 报警）、建立多维下钻的复盘模板、设计了标准化的实验申请→审批→监控→复盘流程。

这个经历让我建立了「实验治理」的完整框架，在 GrowthDeck 项目中，我把 SRM 检测、样本量计算、显著性检验、多维下钻、辛普森悖论检测全部做成了可交互的工具。

延伸阅读