Platform
Resources
样本比例不匹配（SRM）快速指南
注：本文是一篇英文博客的中文翻译，原文请见：https://statsig.com/blog/sample-ratio-mismatch
"让我们抛硬币决定——谁先到50次谁赢。"
想象一下，我们抛一枚公平的硬币几次，得到8次正面和2次反面。（公平的硬币是平衡的，从未在魔术表演中使用过。）
虽然我们期望得到一半正面一半反面，但我们可能只是得到了奇怪的结果。如果我们继续抛硬币100次，得到80次正面和20次反面，我们会对这枚硬币的"公平性"产生更多怀疑。
如果我们使用这种抛硬币的方式来随机将用户分配到实验的测试组或对照组，这种缺乏"公平性"的情况被称为样本比例不匹配或SRM。
我们使用卡方检验来评估这种不公平性，将我们看到的80/20结果与我们期望从公平硬币得到的50/50结果进行比较。这个卡方检验的p值是在使用真正公平的硬币进行重复试验时，我们期望看到的与我们观察到的结果一样极端或更极端的结果的比率。
直觉映射到SRM p值
我们从抛硬币实验中获得的直觉反映在这些实例的卡方检验的p值中。在10次抛硬币实验中看到80%正面的结果，p值为0.058，而在100次抛硬币实验中得到80%正面，p值基本为0。
为什么SRM不好？
样本比例不匹配是选择偏差的证据
随机实验的基本假设之一是个体被随机分配到对照组或测试组。否则，可能存在其他与分配不独立的变量，这些变量可能是我们观察到的处理组和对照组之间任何差异的真正原因。
指向实施问题
存在SRM的事实可能意味着实验实施中存在某些问题，但它可能发生在用户被分配到其处理组的方式中，或者发生在事后测量或处理数据的方式中。如果您使用的是Statsig，我们可能可以排除许多这些潜在原因！
需要调查的几个原因：
某些用户不符合某些变体的条件：也许您超酷新功能的代码也无意中强制某些用户群体进入特定的处理组。
如果您使用Statsig，这不会发生，因为我们的SDK会在所有实验组中均匀地过滤掉不符合条件的用户
注册与曝光分离：也许用户在某个网页上注册了实验，但只有在他们到达相关体验时才会暴露于其处理组。然而，如果对照组的曝光发生在页面顶部，但测试组需要滚动，这是一种可能导致SRM的机制。
Statsig SDK通过默认自动记录曝光来自动耦合分配和曝光，但在需要时也可以解耦。
随机化程序没有真正随机：您用来"随机"将用户分配到处理组的函数实际上不是随机的，可能会引入偏差。
如果您使用Statsig，这不会发生 - 我们使用SHA256哈希算法根据单位ID和实验ID确定性地分配处理组
测试组和对照组之间的崩溃率差异：如果新代码引入或解决了崩溃，这可能导致SRM。如果测试组有更多崩溃，这将导致测试组中更多用户无法发送曝光，从而导致SRM。
数据处理问题：可能存在某些过程，通过这些过程，仅对对照组或测试变体删除或复制此数据。
如果您通过Statsig发送所有数据，我们会进行数据处理，不应该出现来自数据处理的SRM
你只是运气特别差吗？
可能不是。
这就是p值所量化的：在以相同方式进行的重复试验中，我们期望看到的组划分至少与我们观察到的一样极端的结果的比率。这真的不太可能，但可能就是正在发生的事情。
Statsig控制台中的SRM
在Statsig中，我们会自动检查每个实验的SRM。在诊断中的实验健康检查下，如果您看到曝光平衡为绿色，这意味着我们没有检测到任何SRM。
如果SRM p值低于0.01，我们认为曝光是不平衡的。
如果您没有使用Statsig，并且想要检查您的实验是否有SRM，您可能不想手动进行卡方检验。我以前使用过这个SRM计算器，并用它来计算我们上面(8, 2)和(80, 20)示例的p值。
Statsig会自动跟踪您的SRM p值随时间的变化，这使您能够识别是否/何时看到SRM的证据。任何低于0.01的SRM p值都意味着实验未通过曝光平衡健康检查。
这意味着也有一个调试可能导致SRM的问题的起点。
如果检测到SRM并找到根本原因，您可以轻松放弃实验并重新分配。这个具有相同设计的新实验也将使用不同的"盐"来随机化用户的组，这意味着用户被随机分配到一个组，独立于他们在该实验的前一次迭代中的组。这很重要，因为它确保新结果不受前一次运行中的负面或正面体验的影响。
因为有SRM，我必须丢弃我的结果吗？
我们不想轻视实验中存在SRM。它表明您的实验在方法论上很可能存在问题。然而，我们可能不想完全忽视我们刚刚进行的实验。
重要的是，在做出这些判断时，我需要知道SRM的根本原因。没有这个关键知识，就不可能考虑实验偏差的潜在来源以及我们在哪些方面可以放心使用结果。
当我查看有SRM的实验时，我会考虑几个因素来确定是否可以从实验中获得任何方向性见解：
导致SRM的用户组与其他用户有多大不同？
例如，在我们的实验中，新用户都在测试组中，新用户的行为与老用户非常不同，所以我完全忽略实验结果并重新开始实验。
导致SRM的用户之间的差异是否也会影响处理？
例如，在我们的实验中，我为所有Internet Explorer用户创建了重复条目，我的新功能对这些用户造成了更高的延迟。这似乎推动了我看到的整体负面结果，而使用其他浏览器的用户似乎从新功能中获得了小的积极影响。这可能会让我迭代我的产品，以减少所有网络浏览器的延迟，然后再进行另一个实验。
归根结底，这是一个判断问题。
虽然重新开始实验并且不从存在SRM的先前版本中获取任何学习可能有缺点（延迟决策，向用户提供劣质体验），但最科学严谨的方法是在找到导致SRM的问题后，始终按照设计重新运行这些实验。
如果您想考虑实验结果，尽管存在SRM，使用CUPED控制实验前偏差可能有助于解决偏差。