第二次世界大战期间，亚伯拉罕·瓦尔德是哥伦比亚大学的统计学家，他得出了一个非常违反直觉的解决方案。军方让他决定在飞机上放置装甲的位置，以增加飞机在任务中幸存的几率。军事研究小组和亚伯拉罕的统计小组都分析了从战场返回的飞机的受损部分，特别注意了发现弹孔的位置。军队建议在飞机袭击最严重的地方部署装甲部队。亚伯拉罕不同意。他建议加强飞机受损最少的部分。这听起来可能有点令人困惑，但他的建议是正确的。因为回来的飞机上的弹孔没有坠毁的飞机上的弹孔那么重要。换句话说，那些没有返回的飞机需要被纳入分析，这样分析结果才可信。
这个故事与A/B测试什么关系呢？
就像亚伯拉罕不能在不考虑那些没有返回的飞机的情况下进行完整的飞机生存分析一样，A/B测试者也需要在他们的实验中意识到 丢失的用户 。A/B测试经常遭受亚伯拉罕在他的分析中认识到的同样的问题—— 生存偏差 [2]。 它表现为变量A和变量B的用户比例与实验开始前配置的用户比例之间的显著差异(例如一个期望50/50实验) 。正如我们稍后将看到的，对这种不成比例的数据进行分析可能对它所支持的产品有害。为了防止这种危害， 在微软，每个A/B测试在分析其影响之前必须首先通过这个样本比例不匹配(Sample Ratio Mismatch，SRM)测试 。
MSN的一个团队曾经测试过他们的图像旋转木马[4]的变化。当旋转卡片的数量从12 (A)增加到16 (B)时，他们希望看到用户粘性增加。这种A/B测试具有足够的统计power来检测非常小的变化，用户交互遥测技术被正确记录和收集。 尽管基于相关A/B测试的期望，但结果却显示用户粘性下降了 ! 但是这种下降伴随着一个警告，即 变体A和B的用户数量在统计上与配置的比例不同 ， A/B测试未能通过SRM检查，并进行了进一步检查。深入调查发现了一个有趣的发现。版本B不仅更吸引人，而且接触到B的用户的吸引程度触发了机器人异常剔除命令，然后将他们从分析中过滤出来。
问题解决了，结果反过来了。新版本实际上是积极的，增加的内容显著提高了用户对产品的参与度。同时，这个例子说明了一个重要的教训: 丢失的用户很少，只是一小部分用户。他们往往是受测试内容影响最大的人。在MSN的例子中，这些人是最活跃的用户。在另一个使用SRM的A/B测试中，来自最不活跃用户的数据可能会丢失。简而言之， 当比较两个数据集时，导致不正确结论的最大原因之一是比较不成比例的数据集 。在诊断出根本原因之前，不要相信SRM的A/B测试结果。
领英（LinkedIn）[3]和雅虎（Yahoo）等公司最近的研究成果，以及我们自己的研究[4]都证实，SRM发生的频率相对较高的频率? 在LinkedIn，大约有10%的A/B zoom测试(如果用户满足某些条件，就会触发用户进行分析的A/B测试)曾遇到过这种偏见。在微软，最近的一项分析显示，大约6%的A/B测试有SRM[4]。显然，这是一个值得理解的重要问题，因此我们研究了SRM发生的各种方式。
就像发烧是多种疾病的症状一样， SRM是各种质量问题的症状 。这使得诊断SRM对于任何A/B测试人员来说都是一项极具挑战性的任务。在诊断样本比例不匹配KDD的19论文[4]中，我们导出了不同类型SRM的分类。在A/B测试的每个阶段中，这些知识将解析SRM的常见根源。我们发现了SRM的几个原因：
- 1).发生在作业阶段(如不正确的用户分桶,错误的用户id,延续效应,等等)
- 2).发生在执行阶段(如实验版本上报错误等)
- 3).在日志处理阶段(例如,错误的数据连接),
- 4).最后在分析阶段(例如，使用有过滤的条件来分割分析)。
与各个阶段不同的是，SRM也可能是由A/B测试者在任何时候通过不均衡地增加实验变量或让用户很容易地分配到一个变量而产生的。要了解全面的分类，请参阅下面的图或阅读我们的报告[4]。
我们通过分类的方式创建了对问题的理解，但它没有回答如何知道给定A/B测试的偏差的关键问题。下面让我们来研究一下。
诊断SRM需要两个步骤：
- 第一步是检测：AB两个数据集是否有SRM。
- 第二步是鉴别诊断：综合症状，并根据证据排除似乎不太可能的根本原因。
3.1.我的A/B测试有SRM吗?
每个成熟的A/B测试平台的一个基本组件是一个集成的SRM测试，它会显著地通知A/B测试人员他们的数据集不匹配[5]，[6]。如果A/B测试平台缺少此特性，则可以使用浏览器扩展或其他方法来计算SRM测试，参见[7]。
在发布决策分析开始之前，SRM测试是在底层数据上执行的，即使用A和B报告的用户数量。我们喜欢将其视为一种端到端方法，用于检测存在严重质量问题且需要关注的A/B测试。与直觉相反，只看A和B中用户的比例是不够的，这个比例缺乏关于样本规模的信息。我们 需要使用统计检验，如卡方统计量检验SRM问题 ，以确定在实验变量中观察到的用户分布是否在统计上与配置的用户分布不同。
正如我们在上面所提到的，在使用ExP进行A/B测试之前，每个分析都需要通过这个测试，然后我们才能揭示实验的实际结果。 我们使用的阈值是保守的，以减少假阳性的可能性: p值 < 0.0005 。在实践中，使用SRM进行的A/B测试将产生远低于阈值的p值。现在让我们讨论一下如何对SRM进行分类。
3.2.查找SRM根本原因
在医学上，鉴别诊断是将某一特定疾病或状况与其他具有相似临床特征的疾病或状况区别开来。我们遵循类似的实践来诊断SRM。在大多数SRM根本原因调查中，我们共享两个常见步骤。我们将在下一节中描述为简化研究而开发的工具。
- a)局部分析。 一个常见的出发点是分析局部(即队列)。通常，SRM的根本原因会局限于特定的段。在这种情况下， 受影响的部分将具有非常低的p值 ，这将促使A/B测试所有者更深入地进行测试。
- 例如，考虑一个场景，在A/B测试中的一个实验显著地改善了用户使用特定浏览器打开网站的加载时间。 更快的加载时间会影响记录和收集遥测数据的速率，因此，这个A/B测试可能会有一个本地化到该浏览器类型的SRM 。然而，其他部分对于分析可能是干净和有用的。现在，当局部分析证据是不确定的，例如，所有局部分析似乎都受到SRM的类似影响时，情况又如何呢？
- b)触发。 对于在分配的填充的子集(触发A/B分析[9])上进行分析的A/B测试，我们建议检查用于决定保留哪些日志的布尔条件。通常情况下，A/B测试人员会 创建触发分析来增加他们指标的敏感性 。
- 例如，如果结账页面上出现了更改，比如引入了新的优惠券代码字段，那么只分析实际访问该页面的用户可能是有价值的。但是，为了放大，需要使用有效的条件，即在测试更改之前捕获用户的体验。通常情况下，所提供条件的必要日志记录并不是在每个实验中都存在。考虑上面结帐网站示例中的更改是否为一个新的优惠券代码字段，并且条件放大到向这个新字段暴露的用户。分析中会发生什么? 除非将反事实的日志记录添加到没有这个新字段的控制实验中，否则会有一个支持实验的严重SRM[10]。
- 确认这种糟糕情况的一个简单诊断测试是检查A/B测试中未触发的群体是否没有SRM 。对于给定的A/B测试，如果未触发的分析是可信的，并且触发的分析具有SRM，那么错误配置的触发条件或配置条件缺少日志记录是最可能的根本原因。 解决方案通常很简单:更新触发条件 ，使其包含可能影响用户的所有方面(例如，为访问子站点的用户触发条件，而不是与子站点上的组件交互的用户)。
当然，还有其他几个诊断步骤可以用来收集更多的证据。帮助A/B测试人员诊断他们的SRM的其他数据点是，SRM的重要性(一个非常低的p值表明一个非常严重的根本原因)，SRM的方向性(与预期基线相比，新实验中更多的用户通常表明增加了参与度或更好的性能)，当然还有SRM的数量(一个产品中许多不同的SRM同时可能指向一个数据治理问题)。
在ExP，开发了一种工具，可以帮助诊断上述常见的根本原因。工具显示了它可以为给定的A/B分析收集和计算的最相关的信息。该工具的用户将获得循序渐进的经验，从解释SRM是什么开始，然后是一系列自动和手动的检查。自动检查帮助A/B测试人员回答以下三个问题，以进行任何A/B分析SRM:
- SRM是局限于某些局部还是广泛存在?
- 是配置的条件导致的SRM?
4.1.SRM是局限于某些局部还是广泛存在?
首先，为了让A/B测试者了解他们的srm是局部的还是广泛的，我们提供给他们一种直观的可视化，即所有可用的部分都以细胞形式呈现出来。红细胞表示SRM，而灰色细胞表示该段未检测到SRM。细胞的大小与局部的大小成正比，大的细胞指向大的局部范围，反之亦然。这种可视化的用户还可以基于SRM p值(从非常小的p值到边缘的SRM p值到所有的p值)和局部大小(关于所有数据)筛选视图。如上所述，目标是发现SRM是否只在某些段中被检测到，以及它们是否大到足以扭曲整个分析。
4.2.是配置的条件导致的SRM?
对于放大到一个子群体的A/B分析，我们提供关于放大条件是否是根本原因的诊断信息。如上所述，我们通过显示匹配分析来做到这一点，该分析对给定的A/B测试不使用这个条件。当这个标准分析没有SRM时，我们要求诊断专家调试用于产生这个分析的条件。
除了上面描述的检查之外，我们还开发了一个检查，它使用实验中的历史数据来帮助确定SRM的根本原因是在什么时候发生的。后面有机会分享关于这个工具的更多细节。然而，自动检查可能并不总是足够的。
我们的工具还为诊断人员提供了一个问答分析功能，其中询问有关A/B测试实验的策略问题(例如，“是否只有一些实验重定向流量”)和简单的是/否/待定回答问题。根据对这些问题的回答，诊断学家将被指导从分类法中进行解释和案例研究，以便在他们的某个实验按照问题所要求的行为时了解通向SRM的路径。
我们在ExP的任务是提供值得信赖的在线控制实验。在A/B测试的结果可信之前，SRMs是一个需要被检测、诊断和解决的重要陷阱。希望你能对这个主题有深刻的介绍，并且希望能够经常检查和诊断srm。下次分析A/B测试时，想想亚伯拉罕•沃尔德(Abraham Wald)和失踪的飞机。
如果这对你的工作学习有帮助，欢迎点赞关注一键三连，支持我的工作。
[1] A. Wald, “A method of estimating plane vulnerability based on damage of survivors, CRC 432, July 1980,” Cent. Nav. Anal., 1980.
[2] “Survivorship bias.” [Online]. Available: https://en.wikipedia.org/wiki/Survivorship\_bias.
[3] N. Chen and M. Liu, “Automatic Detection and Diagnosis of Biased Online Experiments.”
[4] A. Fabijan et al., “Diagnosing Sample Ratio Mismatch in Online Controlled Experiments,” in Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining – KDD ’19, 2019, pp. 2156–2164.
[5] S. Gupta, L. Ulanova, S. Bhardwaj, P. Dmitriev, P. Raff, and A. Fabijan, “The Anatomy of a Large-Scale Experimentation Platform,” in 2018 IEEE International Conference on Software Architecture (ICSA), 2018, no. May, pp. 1–109.
[6] A. Fabijan, P. Dmitriev, H. H. Olsson, and J. Bosch, “Effective Online Experiment Analysis at Large Scale,” in Proceedings of the 2018 44rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2018.
[7] L. Vermeer, “Sample Ratio Mismatch (SRM) Checker.” [Online]. Available: https://github.com/lukasvermeer/srm.
[8] “Differential Diagnosis.” [Online]. Available: https://en.wikipedia.org/wiki/Differential\_diagnosis.
[9] R. Kohavi, D. Tang, and Y. Xu, Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.
[10] W. Machmouchi, “Patterns of Trustworthy Experimentation: Pre-Experiment Stage,” 2020. [Online]. Available: https://www.microsoft.com/en-us/research/group/experimentation-platform-exp/articles/patterns-of-trustworthy-experimentation-pre-experiment-stage/.
[11] T. Xia, S. Bhardwaj, P. Dmitriev, and A. Fabijan, “Safe Velocity: A Practical Guide to Software Deployment at Scale using Controlled Rollout,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2019, pp. 11–20.
扫码加我好友进微信群｜QQ群