样本比例失衡 SRM 卡方检测排查

样本比例失衡 (Sample Ratio Mismatch, SRM) 卡方拟合优度检验与全链路根因排查体系 (Sample Ratio Mismatch Detection, Chi-Square Goodness-of-Fit & Root-Cause Debugging) 是工业 A/B 实验平台最核心、最高优先级的“健康红线卫士”；定义：当实验实际分流进对照组与实验组的样本数量比例（观测频数 $O_T, O_C$），与预先配置的理论分流比例（期望频数 $E_T, E_C$，如 50%:50%）在统计学上发生极显著偏离时，即触发 SRM 报警；检测方法：采用皮尔逊卡方检验 (Pearson's $\chi^2$ Test): $\chi^2 = \sum \frac{(O_i - E_i)^2}{E_i}$（自由度 $df = 1$），若 $\chi^2 > 3.84$（$p < 0.001$ 工业严苛红线），则实验结论 100% 作废，严禁上线；SRM 绝大多数情况下意味着严重的工程 bug（如重定向丢失埋点、客户端崩溃过滤、机器人爬虫异常分流、或者特定网络延迟导致慢用户超时断开）。

A/B 测试平台自动化实验健康度巡检、实验数据有效性前置防御、复杂工程分流 Bug 排查。

很多团队看到实验指标暴涨 20%，却不知是因为实验组前端报错导致弱网低消费用户全部闪退漏斗只剩下高净值用户（假繁荣）；SRM 拦截了所有由于分流偏差导致的虚假结论。

写出计算 50/50 分流下 SRM 卡方统计量 $\chi^2 = \frac{(N_T - N/2)^2}{N/2} + \frac{(N_C - N/2)^2}{N/2} = \frac{(N_T - N_C)^2}{N_T + N_C}$ 的简化公式？

SRM 排查四大根因分类：1) 埋点丢失 (Tracking Loss)；2) 客户端崩溃过滤 (Crash Bias)；3) 延迟超时 (Performance Dropout)；4) 爬虫机器人过滤 (Bot Skew)，如何逐一排查？

为什么当实验组网页加载变慢导致 SRM 时，简单的均值比较会产生“幸存者偏差 (Survivorship Bias)”从而得出完全相反的错误结论？

触发事件后分流 (Trigger-based Analysis): 为什么必须在进入实验触发点 (Trigger Point) 时才进行样本分配记录，而不是在全量 App 启动时记录？

当排查发现 SRM 确实存在时，是否可以通过“倾向得分加权 (Propensity Weighting)”挽救数据？为什么工业界金标准坚持直接报废并重新修复上线？