免费工具 SRM 检查：A/B 测试样本比例不匹配
看 A/B 测试结果之前，先看分流对不对。设置的是 50/50，十万用户最后分成了 50.6/49.4，说明有什么东西不均匀地吞掉或塞进了用户，这个实验的结论就不可信了。把各组用户数贴进来检查一下。
- 卡方拟合优度检验
- 阈值 p < 0.0005
- 本地计算
每组拿到的比例对不对
每行一组：组名可省略，后面是用户数（或会话数，按你分流的单位）。可以带千分位、写「1.2万」；数字中间不要有空格。
2–6 行，比如「对照组 50,123」。
50/50、1:1:1、40/30/30……留空表示平均分。
p 值低于它时判定为 SRM。
结论
- SRM样本比例不匹配：p = 2.72 × 10⁻⁴，低于阈值 0.0005。找到原因之前不要解读这个实验的结果。
- 注意「实验组」比预期少了 1.16% 的用户，最可能是这一组丢了人。
p 值
2.72 × 10⁻⁴
如果分流完全按设置进行，出现至少这么不均匀的分组的概率。
卡方值（χ²）
13.252
自由度
1
组数 − 1。
总用户数
99,100
各组明细
偏差 = （实际 − 预期）÷ 预期。
| 分组 | 实际 | 预期 | 实际占比 | 预期占比 | 偏差 | χ² 贡献 |
|---|---|---|---|---|---|---|
| 对照组 | 50,123 | 49,550 | 50.58% | 50.00% | +1.16% | 6.63 |
| 实验组 | 48,977 | 49,550 | 49.42% | 50.00% | −1.16% | 6.63 |
逐项排查这些常见原因
参考 Microsoft 的 SRM 原因分类（Fabijan 等）：分组、执行、日志处理和分析环节。
- 可能原因机器人：爬虫或脚本更多地落进某一组，或者机器人过滤在分组之后才做，从某一组里剔掉了更多「用户」。
- 可能原因跳转：跳转式实验里，在多出来的那次跳转中离开、或埋点在跳转前触发的访客，只会从跳转组里丢失。
- 可能原因缓存：CDN 或页面缓存把同一个版本发给了很多访客，或者分组 cookie 没有进缓存键。
- 可能原因分组 bug：哈希或随机数有问题、用户登录或换设备后被重新分组、各系统之间的用户 ID 对不上。
- 可能原因放量：实验中途改过分流比例（比如 10% → 50%），分析时把不同阶段混在了一起。
- 可能原因埋点与分析：实验版改变了曝光事件是否上报（页面变慢、报错）、数据关联时丢了行，或者分组之后加的筛选条件不均匀地剔掉了用户。
分享这组输入：数值写在链接的 # 后面，不会发到服务器。
https://tapcub.com/zh/tools/srm-checker
版本 v1.0更新于 更新记录
检查器告诉你什么
SRM 检查不回答「实验版好不好」，只回答「这个比较公不公平」。
p 值
如果用户完全按设置分组，出现这么不均匀的分组有多大可能。50,123 比 48,977 看着很接近，但在 99,100 名用户上 p = 0.00027，大约 3,700 次里才有 1 次。
结论
p 低于阈值就判定为 SRM。默认的 0.0005 是 Microsoft 实验平台（ExP）用的保守阈值，目的是让误报很少；真正的 SRM 算出的 p 值通常远比它小。
各组偏差
哪一组少了、哪一组多了，按预期人数的比例表示。少人的组常常是因为跳转、报错或筛选丢了用户；多人的组常常混进了机器人或重复计数。
χ² 贡献
每组对卡方值的贡献。三组以上时，贡献最大的那一组最值得先查。
SRM 检查通过不代表实验没有 bug，只是排除了一类常见又严重的问题。
三步检查分流
在看任何转化数据之前做这个检查；实验进行中建议每天查一次。
-
1
按分流单位计数
按用户分流就数用户，按会话分流就数会话。数所有被分组的人，不要只数转化了的人。
-
2
填设置的比例
实验平台上设置的分流比例：50/50、34/33/33 等。平均分可以留空。
-
3
看结论
出现 SRM：先停下来，按列出的原因排查，再做任何分析。没有 SRM：接着比较转化率。
卡方拟合优度检验
预期人数由总人数和设置的比例算出。卡方统计量把各组的差异平方后加总，p 值取自由度为「组数 − 1」的卡方分布右尾（用正则化不完全 Gamma 函数计算，精度约 1e-12）。
- 预期人数 Eᵢ = 总用户数 × 第 i 组设置的比例
- 假设用户相互独立地分组；同一个用户多次访问只能算一次
- 每组预期人数至少 5 时近似才成立，不到 5 时检查器会提醒
- 阈值没有统一标准：Microsoft ExP 用 p < 0.0005，也有工具用 0.001 或 0.01。每天都查的话，阈值越低误报越少
预期人数
Eᵢ = N × wᵢ
99,100 × 50% = 49,550
统计量
χ² = Σ (Oᵢ − Eᵢ)² ÷ Eᵢ
573² ÷ 49,550 + 573² ÷ 49,550 = 13.25
p 值
p = P(χ²ₖ₋₁ ≥ χ²) = Q((k − 1)/2, χ²/2)
自由度 1：p = 2.72 × 10⁻⁴ < 0.0005 → SRM
大样本上的小偏差
同样比例的偏差，小实验上无所谓，大实验上就是警报。设置比例 50/50。
| A 组 | B 组 | A 组占比 | p 值 | 阈值 0.0005 下的结论 |
|---|---|---|---|---|
| 1,000 | 1,100 | 47.6% | 0.029 | 不是 SRM |
| 10,000 | 10,100 | 49.75% | 0.48 | 不是 SRM |
| 100,000 | 101,000 | 49.75% | 0.026 | 不是 SRM |
| 50,123 | 48,977 | 50.58% | 0.00027 | SRM |
2,100 人里 A 组占 47.6% 不算 SRM；99,100 人里占 50.58% 就是。数字用本工具算出。
SRM 常被漏掉的原因
SRM 是 A/B 测试结论出错最常见的原因之一，也是最容易检查的。
凭眼睛看比例
50.6/49.4 看着没问题，有没有问题取决于样本量，所以要用统计检验。
筛选之后再检查
对所有被分组的人做检查。只数走到后面某一步的用户，会把实验效果混进分流比例里。
数错了单位
按用户分流却数页面浏览量，某组里有几个重度用户就会看起来像 SRM。按分流单位计数。
加权代替修复
把各组按比例拉回 50/50 只是掩盖了症状：丢掉的那些用户多半不是随机的。
TapCub 能帮你看清的两类 SRM 原因
TapCub 不负责分组，也不运行实验。它能帮你查两类常见的 SRM 原因：机器人流量，以及各组之间不均匀的流失。
什么是样本比例不匹配（SRM）？
实际分流比例和设置的比例差得太多，已经不能用随机波动解释。说明有东西不均匀地增加或减少了某些组的用户，各组不再可比。
怎么检查 SRM？
用卡方拟合优度检验，把各组用户数和设置的比例对比。50/50 分流下 50,123 比 48,977，χ² = 13.25，自由度 1，p = 0.00027。
SRM 的 p 值阈值用多少？
Microsoft 实验平台（ExP）用 p < 0.0005，特意定得保守，让每天检查时很少误报。也有工具用 0.001 或 0.01。真正的 SRM 算出的 p 值通常比这几个都小得多。
SRM 一般是什么原因造成的？
Microsoft 按环节分类：分组（哈希有问题、用户被重新分组）、执行（跳转、实验版崩溃或加载更慢）、日志处理（数据关联丢行、机器人过滤）、分析（分组后加的筛选），以及实验人员的操作，比如放量不均匀。
出现 SRM 还能用实验结果吗？
一般不能。丢掉的用户很少是随机的，算出的提升可能来自「谁被丢掉了」，而不是改动本身。找到原因、修好后重跑。
检查用户数还是会话数？
按分流的单位。网站实验大多按用户分流（cookie 或用户 ID），就数各组的去重用户数。
和卡方检验是一回事吗？
这是卡方检验的拟合优度形式：实际人数对比已知的预期比例。卡方检验计算器还能做列联表，比如各组的转化情况。