别急着看 p-value：我做了一个 A/B test 实验审查器

很多团队把 A/B test 简化成一个问题：B 的 conversion rate 有没有显著高于 A？

这个问题当然重要，但它只覆盖了实验的最后一小段。更麻烦的情况是：统计结果很漂亮，实验本身却不可信；或者 OEC 上赢了，速度、崩溃率、留存等 guardrail 却变差了。

我最近重新看了 Ron Kohavi 关于在线受控实验的演讲、论文和 Microsoft Experimentation Platform 的文章，做了一个更偏“实验审查”的工具：

A/B Experiment Review：Can you ship this experiment?

它不会只告诉你 p-value，而是把一个结果放进四道 gate 里：

Data quality：实际 A/B 人数是否符合计划中的流量比例，先检查 SRM（Sample Ratio Mismatch）。
OEC evidence：Treatment − Control 的 delta、95% delta CI 和 p-value 是否支持一个清晰方向。
Guardrails：核心指标变好时，延迟、崩溃、放弃率等不该牺牲的指标有没有回归。
Readiness：实验是否跑完预先约定的时长，OEC、曝光、日期趋势和提前偷看是否都被明确检查。

最后它给出的是 SHIP CANDIDATE、HOLD / REVIEW、FIX DATA、NO CLEAR WIN 之类的建议。这里的关键词是 candidate：工具帮助你整理证据，不替产品团队做最终决定。

Kohavi 反复强调的几件事

1. 先承认直觉很差，再让数据来裁决

在 2014 年 MIT CODE 的演讲材料里，Kohavi 展示了 Microsoft 的真实实验：大约三分之一的想法显著为正，三分之一没有显著差异，三分之一显著为负。也就是说，约三分之二的想法没有改善它们原本想改善的指标。

这不是在说产品经理、设计师或工程师没有价值，而是在说“我们觉得它会有效”不是结果。Kohavi 在另一套演讲材料里把这个原则说得很直接：“Stop debating, it’s easier to get the data.” 与其让更资深的人赢得争论，不如尽早把假设变成一个可测量的实验。

这也是 A/B test 最有价值的组织作用：它把“谁的意见更有分量”改成“哪个假设能经受住真实用户的检验”。Microsoft 对 ExP 的早期总结也把这种能力描述成一个帮助团队倾听客户、加速创新的技术和文化系统。

2. OEC 要在看结果之前约定

OEC（Overall Evaluation Criterion）是这套方法里最重要、也最容易被低估的概念。它不是“报告里表现最好看的那个指标”，而是实验开始前就应该约定的、代表客户或业务长期价值的主要评价标准。

如果一个新功能让点击率上升，但让用户完成任务更慢，或者让页面加载更慢，那么“赢没赢”就不能只看点击率。Kohavi 的演讲材料建议把 OEC 和其他诊断指标区分开：OEC 用来做决策，local / diagnostic metrics 用来解释为什么会这样。

因此工具里没有设计一个“从十个指标里自动挑冠军”的总分。它只接受一个二元结果作为 OEC 示例，并要求你明确是否在看到结果前就约定了 OEC。这个限制是故意的：一个看起来精确的总分，可能只是把没有解决的产品取舍藏起来。

3. 先问结果能不能信，再问效果多大

Kohavi 有一句很适合做实验平台的标语：“Getting numbers is easy; getting numbers you can trust is hard!” 这正是我把 SRM 放到工具第一道 gate 的原因。

如果实验计划 50 / 50 分流，最后却出现了很不寻常的比例，不能只把它当作随机波动。Microsoft 的 SRM 案例说明，缺失的用户往往不是随机缺失的；它们可能正是被实验影响最大的一群用户。SRM 是症状，不是诊断结果，但在解释 lift 之前必须先调查它。

早期的 controlled experiments 实践指南还介绍了 A/A test：两组用户看到完全一样的体验，用来检查分流系统和数据管道。一个健康的 95% A/A 检验不应该频繁地产生显著差异。如果 A/A 也经常“赢”，就没有理由相信 A/B 的漂亮结果。

4. 看得早，但不要因为早期波动就随便停

这里有一个看似矛盾的建议：实验期间要尽早、频繁地测量，以便发现严重 bug；但不能每天看一次 p-value，看到显著就停止，然后把它当成普通的固定时长检验。

Microsoft 的 During-Experiment Patterns把这件事拆得很清楚：应该尽早关注 OEC 和 guardrail，必要时对严重回归设置自动反应；但重复查看会带来 multiple testing 和 early peeking 问题，分析方法或停止规则必须与之匹配。

这篇文章还建议按日期切片。如果效果从第一天开始快速下降，可能是 novelty effect；如果只在某一天突然尖峰，也可能是节日、体育赛事、季节因素或数据质量问题。工具里的日期检查和“stopping rule accounts for early peeking”不是统计计算，而是提醒团队不要把一个瞬时现象包装成长期收益。

5. Ship decision 是一个权衡，而不是一个显著性徽章

在 Post-Experiment Patterns里，Microsoft 给出的实际问题是：OEC 变好，但某个 guardrail 变坏，应该怎么办？没有通用的自动答案。团队可以预先定义指标权重和决策规则，但不能在看到结果后临时改规则，让结果刚好支持想做的决定。

所以工具把 guardrail 做成一个明确的人工输入：pass、warn 或 fail。它并不知道你的页面加载时间阈值，也不能替你看 crash log；它只负责让“这个权衡有没有被看见”成为发布讨论中的一个必答题。

为什么做这个，而不是再做一个 sample-size calculator？

sample size calculator 解决的是“实验开始前需要多少用户”。这个审查器解决的是“实验结束后，我有没有足够理由相信这个结果，并把它带进发布流程”。

我更喜欢后者有三个原因：

它更贴近真实工作里的失败模式：分流错、日志漏、指标选错、提前停止、只看局部指标。
它把统计数字放回产品决策上下文，而不是鼓励大家围绕 0.05 玩游戏。
它适合做成一个短链接或截图，放进 ship email、实验复盘或 code review 里，形成可复用的审查习惯。

这个版本仍然是一个轻量的浏览器工具，而不是完整的实验平台：数据需要手工输入；OEC 示例是二元 conversion；delta 用两比例 z-test 和 95% 区间；guardrail 也是人工汇总。对于 revenue、ratio、retention、clustered assignment 或 sequential testing，应该换用匹配指标和设计的统计方法。

但作为一个小工具，它至少把讨论顺序改成了：

结果先可信吗？核心目标真的变好了吗？有没有安全代价？现在是发布时机吗？

这比单独问“B 赢了吗？”更接近 Kohavi 所说的 trustworthy online controlled experiments。