评审会开到第 26 分钟，产品经理把最后一页 PPT 翻了出来。
“实验组转化率提升 3.8%，p 值 0.03。”他说，“这周能不能全量？”
投影幕上的数字很绿，会议室里的气氛也跟着轻松起来。开发已经开始问发布时间，运营在算活动能多带来多少订单。坐在角落的数据分析师却发现，实验只跑了四天，周末没有覆盖；实验组的入组人数还比对照组少了一截。
这时候说“不能上”，很像故意给大家添堵。说“可以上”，又等于拿自己的名字给一份还没复核的结果签字。
我见过不少类似的实验评审。麻烦往往不在于团队不会算显著性，而在于一张结果页把太多前提折叠掉了：用户怎么分组，谁真正看到了新功能，哪些数据没回来，同期还有什么实验，以及这个“转化率”到底用了哪个分母。
显著性只是结果的一行注释，不是上线许可证。
复核不是重做实验，而是检查证据有没有断
一份 A/B 测试报告通常很完整：实验组、对照组、样本量、指标变化、置信区间、p 值。它看上去像一道已经写出答案的数学题。
可产品实验不是在真空里做的。用户会换设备，会重复登录，会同时命中别的策略；埋点会延迟，版本会分批发布，活动会在实验中途开始。统计计算即使完全正确，也可能只是在精确描述一批已经偏掉的数据。
所以我更愿意把复核分成四道门：
- 实验问题是否清楚：究竟要支持什么决定；
- 样本是否可信：分流、入组和数据回收有没有偏差；
- 过程是否干净：实验之间、版本之间有没有互相污染；
- 结论是否够用：指标、周期和风险是否支持这次上线决定。
前一道门没过，不要急着讨论后一道。连实验组里是谁都说不清，争论小数点后两位没有多大意义。
问题一：这个实验到底要支持哪个决定？
先别看结果，先把实验假设完整读一遍。
“优化下单页体验”不算假设。“把地址表单从 8 个字段缩到 5 个，预计能提高进入支付页的用户比例，同时不增加地址错误率”，才接近一个能复核的假设。
前者出了任何数字都能解释，后者则写清了四件事：
- 改了什么；
- 影响谁；
- 期望哪个主指标变化；
- 哪个副作用不能恶化。
复核时可以直接问：“如果主指标上涨、护栏指标也恶化，我们原来约定怎么决定？”如果实验开始前没有答案，结果出来后就很容易临时挑一个有利说法。
把决定写具体也很重要。这次要决定的是“全量上线”“扩大到 50% 流量”“再跑一周”，还是“只在某类用户中发布”？同一份结果，对这四个决定的证据要求并不相同。
问题二：随机分流的单位，和分析的单位一致吗？
很多实验写着“随机分流”，却没写按什么随机。
按用户账号分流，适合观察账号层面的长期行为；按设备分流，未登录用户也能覆盖，但同一个人换设备后可能进入两组；按会话分流实现简单，却可能让用户今天看见 A、明天又看见 B。企业产品还有按租户、门店或团队分流的情况，此时一个租户里的用户往往会彼此影响。
复核表里至少要留下三项：
| 项目 | 需要写清的内容 |
|---|---|
| 随机单位 | 用户、设备、会话、租户或门店 |
| 稳定键 | 用哪个 ID 保证同一单位持续留在同一组 |
| 分析单位 | 指标按用户、订单、会话还是曝光计算 |
如果按用户分流，却把每一笔订单当成相互独立的样本，高频购买者就会在计算里拥有更多“投票权”。这不一定绝对错误，但必须与实验设计和方差估计方法一致。
再问一句：“用户什么时候算真正进入实验？”被分到实验组，不等于看到了实验功能。只分析实际曝光用户看起来更贴近功能效果，却也可能把“是否曝光”这个受实验影响的条件带进筛选，形成新的偏差。
这部分最怕一句“平台默认就是这么算的”。平台默认可以提高效率，不能替你回答实验单位是否适合当前业务。
问题三：实际样本比例和预设比例对得上吗？
预设 50:50，最后却得到 52:48，不能只说“样本量大，差一点没关系”。
样本比例失配通常被称为 SRM（Sample Ratio Mismatch）。它不是在证明哪段代码一定有错，而是在提醒你：观察到的分组人数，与实验设计预期不一致。原因可能出现在分流、功能执行、日志处理和分析筛选的任何一段。
微软实验平台把 SRM 比作发烧：检查很简单，病因却可能很多。其研究给出的案例包括分桶错误、用户 ID 问题、某个版本跳转流量、数据连接丢失，以及分析阶段用了受实验影响的筛选条件。发现 SRM 后若不定位原因，实验效果就不适合直接拿来做产品决定。
