微软约有 6% 的实验显示样本比例不匹配,对于每年运行 10,000 次实验的产品而言,这相当于每天大约检测到一次(Fabijan等人,KDD 2019测试次数少得多的团队很少会遇到这种情况,因为他们的平台运行的检查在他们当前的流量下无法达到显著性水平。测试结果看起来很正常,报告提升了 4%,但实际上却是错误的。
本指南面向负责解读实验结果并决定是否发布数据的人员。阅读完本指南后,您将能够判断测试样本量是否足够大,从而使不匹配检查具有意义;按最快找到原因的顺序运行五种诊断分支;并将导致结果无效的不平衡情况与可以分割并保留的不平衡情况区分开来。
SRM 报警实际上告诉了你什么
样本比例不匹配是指您配置的分割比例与您观察到的分割比例之间存在差距:您设置的是 50/50,但实际得到的是 50.8/49.2。标准检查方法是对暴露计数进行皮尔逊卡方拟合优度检验,双臂检验的自由度为 1。
这一点很重要,因为导致用户流失的机制几乎从来都与你的指标无关。如果重定向导致连接速度慢的用户无法访问某个版本,那么幸存下来的用户往往是连接速度更快的用户,他们的转化率也更高。这种提升在数据中是真实存在的,但在现实中却并不存在。
大多数团队首先犯的错误是:不存在所谓的行业门槛。不同平台之间的差异可能超过一个数量级。
| 平台 | 《测试》(Test) | 旗帜 | 注意: |
|---|---|---|---|
| AB美味 | 序列频率学派(S-SRM) | p <0.01 | 专为持续监控而设计,因此重复查看也会被考虑在内。 |
| 统计 | 卡方 | p <0.01 | “如果SRM p值低于0.01,则我们认为暴露是不平衡的。” |
| GrowthBook | 卡方 | p <0.001 | 上述警告已被抑制 |
| 微软(插图作品) | 卡方 | 约 500,000 分之一 | 在大样本量 n 下,50.2/49.8 的比例已经可以解决这个问题。 |
两个后果。在一个平台上被标记的测试,在另一个使用相同数据平台上却通过了,因此“我们的工具没有发出警告”并不能证明数据分离干净。而且,0.01 的阈值会将百分之一的健康测试标记为异常。如果你在为期三周的测试中每天目测 p 值,那么误报率的简单独立峰值上限是 19%;实际值会更低,因为连续几天的数据高度相关,但绝对不是 1%。这就是 AB Tasty 运行顺序程序的原因。如果你的平台运行的是固定周期的卡方检验,那么只需在最后查看一次累计计数即可。
检查一下你的测试是否能够检测到任何不平衡。
对于 50/50 的分配,卡方统计量简化为 4n(p̂−0.5)²,其中 n 为总暴露量。取倒数即可得到检查能够检测到的最小不平衡值:
| 总暴露量 | p < 0.01 时标记的最小分裂 | p < 0.001 |
|---|---|---|
| 5,000 | 51.8 / 48.2 | 52.3 / 47.7 |
| 10,000 | 51.3 / 48.7 | 51.6 / 48.4 |
| 30,000 | 50.7 / 49.3 | 51.0 / 49.0 |
| 100,000 | 50.4 / 49.6 | 50.5 / 49.5 |
| 1,000,000 | 50.13 / 49.87 | 50.16 / 49.84 |
将其视为限制,而非许可。在 10,000 次曝光的情况下,任何小于 1.3 个百分点的失衡都无法被检测出来,而 1.3 个百分点的选择效应足以人为地提升转化率。这就是该地区大部分地区普遍存在的结构性问题。土耳其在 2025 年记录了约 6 亿笔电子商务交易,涉及约 634,000 家企业(贸易部,2026年5月12日平均每个平台每年约有 9,500 次测试,而这个平均值很大程度上被少数几个电商平台拉高了。一家中型商店测试结账流程时,曝光量只有几万次,而不是几百万次,因此其 SRM 检查只能发现一些明显的错误,而无法发现更细微的问题。
在这种数据量下,不要依赖警报。自行按天和按细分市场提取原始曝光量,即使 p 值并不显著,也要将持续的同向漂移视为可疑情况。如果您不确定您的平台在哪里公开这些计数, SRM 检查器文档 它们按工具进行映射。
五个分支,按找到原因最快的顺序排列。
KDD分类法按生命周期阶段对SRM故障原因进行分类:分配、执行、日志处理、分析、干扰。诊断顺序则有所不同,应先从成本最低、最常见的故障入手。
- 分析与触发。 症状:原始暴露日志中的拆分清晰,但在评分卡中拆分不清晰。检查:移除触发条件、日期筛选器和指标级连接,重新计算比率。如果比率恢复到预期值,则确认问题。修复:在任何特定变体行为影响资格之前,对两个组中的触发条件进行相同的评估。最常见的误报,十分钟即可排除。
- 日志处理。 症状:两条管道的暴露计数不同,或者差异出现在 ETL 步骤之后。检查:比较同一时间段内 SDK 端计数、仓库计数和报告计数,然后比较每个分支的机器人过滤器排除率。如果上游分支相等而下游分支不相等,则确认存在此问题。修复:确定性地进行过滤,并确保过滤方式相同。2026 年,自动化流量将占网络流量的 53%,高于 2024 年的 51%(Imperva恶意机器人报告,2026年4月29日因此,基于加载时间或用户代理行为的启发式过滤器可以针对不同的变体以不同的速率排除数据。用户同意驱动的损失也存在于此:当
ad_storage如果被拒绝,谷歌的标签平台将停止设置广告 cookie(Google 标签平台同意文档因此,如果一次测试中不同地区的拒绝率不同,那么任何依赖这些标识符的分配都会造成用户流失不均。 - 执行。 症状:页面加载速度越快,不平衡现象越严重,在移动设备上表现更差,或者从部署开始就出现。检查:按设备、浏览器、连接类型和日期细分比例;比较不同访问周期下的曝光时间。如果不足集中在加载速度慢的页面或某个浏览器中,则可确认问题所在。修复:重定向测试在这里失效。重定向只会给其中一个访问周期增加完整的导航,因此所有在重定向过程中放弃访问的用户都会造成选择性损失。要么在服务器端将两个访问周期都渲染到同一个 URL,要么接受两个访问周期不具有可比性的事实。
- 转让。 症状:比例从第一小时开始就出现偏差,并且偏差值固定不变。检查:对同一分配的资源运行 A/A 测试,并验证哈希盐是否重复使用了之前针对该种群进行的实验的盐值。如果 A/A 测试也显示不平衡,则确认问题所在。解决方法:使用新的盐值重新分配资源并重新启动。从之前的测试中继承盐值是此问题的隐蔽版本,只有 A/A 测试才会暴露出来。
- 干涉。 症状:不平衡集中在少数高活跃度标识符或内部 IP 地址段。检查:每个用户的曝光次数分布,以及事件量排名前 1% 的标识符。如果移除这些标识符后比例恢复正常,则确认问题所在。解决方法:使用已记录的规则排除内部流量和脚本流量,而不是手动排除,以确保下次排除规则完全相同。
一份完整的操作指南
以下数据仅为示例,并非客户数据。结账测试报告显示,对照组暴露次数为 61,480 次,变异体暴露次数为 58,520 次:在 12 万用户中,变异体暴露率为 51.2%,对照组为 48.8%,卡方检验 p 值小于 0.001。分支 1:移除触发条件后,变异体暴露次数变为 60,020 次,对照组为 59,980 次,因此分配正确,损失发生在暴露之后。分支 2:管道计数一致,两个分支中机器人排除率均为 0.9%。分支 3:桌面端为 50.1%,移动端为 52.4%,移动端为 47.6%,且变异体在移动端的暴露时间中位数比桌面端高 900 毫秒。诊断:变异体发送了一个额外的渲染阻塞请求,移动用户在请求期间放弃访问,而成功访问的用户网络连接更好。因此,该结果无效。修复方案是性能优化,测试已重新运行,但未重新解读。
哪些可以挽救,哪些不能。
- 取消读数 当损失机制可能与指标存在合理关联时,每次执行和赋值操作默认都符合条件。
- 按段打捞 只有当不平衡仅限于一个可以明确排除的细分市场,且该细分市场是在你查看指标之前定义的,并且剩余部分通过了自身的SRM检查时,才算合格。三者中满足两项是不够的。
- 保留测试 当问题完全出在分析上,并且修正后的评分表通过时,你就成功了。你是在用固定的筛选条件重新解读相同的数据,而不是在进行数据挖掘。
- 无论如何都要记录下来。 记录实验的原因类别。分类法的效果会逐步显现:如果最近十次测试中有三次失败于分支 3,那么问题不在于实验本身,而在于前端交付。[需要内部数据:过去 24 个月中 Switas 运行的实验中,未能通过 SRM 检查的比例,按分类分支划分,以用本市场数据替换微软 6% 的基准值]
问题出在哪里?
这棵树假设进行的是双臂试验,分配方案固定且已知,并采用用户级随机化。它不适用于多臂试验,因为多臂试验需要计算所有臂的完整卡方值,并进一步确定哪一对臂存在偏差;也不适用于渐进式分配试验,因为在试验过程中预期比例会发生变化,累积卡方检验本身就不适用。它不适用于整群或地理随机化设计,因为在这些设计中,单元不是用户,而是集群特征中的不平衡。它无法判断你的指标定义是否正确。而且,当暴露数据未被记录,而你仅凭指标事件推断分配情况时,它也无法提供帮助,因为这并非分组检验,而只是猜测。
常见问题解答
51/49 的比例总是有问题吗? 这完全取决于n值。5,000次曝光时,这只是普通噪声;500,000万次曝光时,这几乎可以肯定是一个缺陷。判断这个比率应该参考可检测性表格,而不是参考固定的百分比经验法则。
我可以直接通过统计方法重新调整手臂的权重,而不是重新运行程序吗? 不。重新加权会修正计数,但不会改变选择结果。丢失的用户已经消失了,而且他们并非随机样本。
我应该多久查看一次 SRM p 值? 除非您的平台运行的是顺序程序,否则只需在最后进行一次累计计数即可。每天查看固定周期的卡方检验会大幅增加误报率。
SRM是否也会使防护指标失效? 是的,原因相同。如果两侧的人群不同,那么固定的护栏与动态的主要衡量标准相比,可靠性并无高下之分。
如果A/A测试也显示不匹配呢? 那么问题就出在赋值语句或日志记录管道中,而不是你的处理语句上。在运行任何其他代码之前,务必先修复这个问题,因为它会污染该平台上的所有测试。
重定向测试总是会导致SRM吗? 并非总是如此,但它们存在其他设计所没有的结构风险,因为额外的导航功能仅存在于一个臂中。如果必须使用,请在读取任何指标之前,先根据连接速度和设备检查比率。
我的流量太低,这个检查结果没有任何意义。那该怎么办? 监测每日原始曝光量是否存在持续漂移,定期对分配层进行A/A分析,并预先注册更详细的健全性检查列表。您是在用流程代替统计功效。
机器人过滤应该在分配任务之前还是之后进行? 在记录暴露情况之后、分析之前,使用对两组数据均相同的确定性规则。SDK 内部的启发式过滤正是导致过滤器本身出现不匹配的原因。
对您自己的实验程序进行检查
如果您希望有人帮您检查当前运行的测试用例的运行状况,或者审查它们所依赖的分配和日志记录层,那么这就是我们所提供的服务。 CRO和实验服务 一样。
来源
- Fabijan、Gupchup、Gupta、Omhover、Vermeer、Dmitriev,“在线控制实验中样本比例不匹配的诊断:实践者的分类和经验法则”,KDD 2019
- AB Tasty 文档,样品比例不匹配(连续 S-SRM,阈值 0.01)
- Statsig,“样本比例不匹配快速指南”,2023 年 8 月 31 日(卡方检验,阈值 0.01)
- GrowthBook 文档,实验(卡方检验,低于 0.001 时需注意)
- Imperva,《2026年不良机器人报告:智能体时代的机器人》,2026年4月29日
- 土耳其共和国贸易部,《2025年电子商务数据》,2026年5月12日
- Google 标签平台、同意模式和存储行为
- SRM Checker 文档和常见问题解答,Lukas Vermeer







