一个 A/B test 实验审查工具

最近重看了一遍 Kohavi 讲在线实验的材料，顺手做了个小工具。这篇记一点我的想法。

如果你更关心这些检查如何落到完整系统里，可以接着看从零搭建一个广告实验平台，以及配套的 MDE / Sample Size Calculator 和 A/B Test Delta Calculator。

我自己的感觉是，很多团队看 A/B test 基本就看一个数：B 的 conversion rate 有没有显著高于 A。这个数当然要看，只是它排在最后。前面还有几件事，出问题的时候更麻烦。比如统计结果很漂亮，实验本身却不太靠得住。又比如 OEC 是赢了，速度、崩溃率、留存这些 guardrail 却在悄悄变差，报告里还不一定看得到。

所以我做的这个东西偏“审查”：

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

它把一个结果放进四道 gate：

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

最后给出的是 SHIP CANDIDATE、HOLD / REVIEW、FIX DATA、NO CLEAR WIN 这类结论。我特意用了 candidate 这个词，工具能做的就是把证据摆齐，真要不要发还得产品团队自己定。

先看数据靠不靠得住

Kohavi 有句话我印象很深：“Getting numbers is easy; getting numbers you can trust is hard!” 我把 SRM 放第一道，多少是因为这句。

2014 年 MIT CODE 的演讲材料里有个数字我记到现在。Kohavi 给了 Microsoft 真实的实验分布：大约三分之一的想法显著为正，三分之一没有显著差异，三分之一显著为负。差不多三分之二的想法，没能改善它们本来想改善的指标。

这说明“我们觉得它会有效”这句话，本身其实不算证据。Kohavi 说得更直接：“Stop debating, it’s easier to get the data.” 与其让资历更深的人赢下争论，不如早点把假设变成一个能测的实验。我觉得 A/B test 在组织里最大的用处也在这，它让判断的依据从资历挪到了真实用户身上。Microsoft 对 ExP 的早期总结里，也是把这套东西当成一个帮团队听见客户声音、加快迭代的技术加文化系统来讲的。

不过既然要靠数据裁决，数据本身得先站得住。

比如实验计划 50 / 50 分流，跑完却是个很奇怪的比例，这事我觉得不能当随机波动放过去。Microsoft 那篇 SRM 案例提到，缺失的那批用户往往不是随机缺的，他们可能恰好是被实验影响最大的一群。SRM 只是个症状，它不告诉你病因，但在解释 lift 之前总得先把它查清楚。

早期那份 controlled experiments 实践指南还讲到 A/A test，两组用户看到完全一样的东西，用来验分流系统和数据管道。健康的 95% A/A 检验不该老是跑出显著差异。要是 A/A 也经常“赢”，那 A/B 那边再漂亮的数我也不太敢信。

时间上还有个坑我自己踩过。实验期间是该早点看、常常看，好及时发现严重 bug，但不能每天瞄一眼 p-value，看到显著就停，然后当成普通的固定时长检验去解读。Microsoft 的 During-Experiment Patterns把这层拆得挺清楚：早点盯 OEC 和 guardrail，严重回归该设自动反应就设，但重复查看会带来 multiple testing 和 early peeking 的问题，分析方法或者停止规则得跟上。

那篇还建议按日期切片看，我觉得这条很实用。效果从第一天起就往下掉，可能是 novelty effect；只在某一天冒个尖，那说不定是节日、体育赛事、季节因素，也可能就是数据出岔子了。工具里的日期检查和 stopping rule 那两项都不做统计计算，纯粹是提醒一下，别把一个瞬时现象当成长期收益写进结论。

OEC 最好在看结果之前就定下来

OEC（Overall Evaluation Criterion）大概是这套方法里最重要、又最容易被轻看的概念。它指的是实验开始前就约好的、能代表客户或者业务长期价值的那个主要评价标准。看完报告再从十个指标里挑一个最好看的，那就有点自欺欺人了。

举个例子，新功能让点击率上去了，但用户完成任务变慢了，或者页面加载变慢了，那“赢没赢”光看点击率肯定不够。Kohavi 建议把 OEC 和诊断指标分开，OEC 拿来做决策，local / diagnostic metrics 拿来解释为什么会这样。我觉得这个分法挺清楚的。

所以工具里我没做“十个指标自动算个总分”那种设计。它只收一个二元结果当 OEC 示例，然后问你一句：你是不是在看到结果之前就把 OEC 定好了。这个限制是我故意留的。一个看着很精确的总分，很多时候只是把没想明白的产品取舍藏了起来。

OEC 赢了但 guardrail 坏了

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 近一点。理解也还浅，给同样在做实验的人一点参考。

资料

• Ron Kohavi — Talks
• Lessons from Running Thousands of A/B Tests — MIT CODE 2014 slides
• Practical Guide to Controlled Experiments on the Web
• Online Experimentation at Microsoft
• Trustworthy Online Controlled Experiments