A/B 测试出现样本比例不匹配时，如何诊断？

题干与适用场景

一个产品实验按用户稳定随机分流，配置比例为 50/50。累计 100,000 名合格用户后，分析数据中对照组有 51,000 人，实验组有 49,000 人；实验组转化率比对照组高 1.8%，常规效果检验的 p 值小于 0.01。 请判断结果是否可信，并设计 Sample Ratio Mismatch，简称 SRM，的检测、根因诊断、修复和预防流程。

本题面向数据科学、产品分析、商业智能和实验平台岗位。Amazon 当前的数据岗位面试指引明确要求统计基础、 处理模糊数据以及把数据转成可执行结论；Microsoft 的实验研究则把 SRM 定义为实验可信度的重要质量信号。 核心能力属于 data，因为重点是随机实验、统计检验和数据链路诊断，不是设计整个实验平台。

题目中的 100,000、51,000、49,000 和 1.8% 都是面试演算数据，不代表行业基准。答案采用用户作为随机化 单位，并假设每位用户只应进入一个组；若真实实验按设备、账号、工作区或地域集群分流，检验单位必须随之改变。

面试官考察点

第一个信号是候选人能否在看业务效果前检查实验完整性。普通回答会看到“提升 1.8%，p 值小于 0.01” 就建议上线。强回答会先验证实际样本是否符合配置分布，因为效果检验只能回答两组观测结果是否不同， 不能证明进入两组的人仍来自可比的随机样本。

第二个信号是能否把肉眼比例差异转成统计检验。同样是 51/49，1,000 名用户和 100,000 名用户的证据强度 完全不同。SRM 检验比较各组观测人数与配置比例推导出的期望人数；样本量越大，越能识别小而系统性的偏差。

第三个信号是诊断是否覆盖完整链路。SRM 可能来自分流配置、标识符不稳定、版本执行差异、埋点丢失、 反作弊过滤、数据连接或使用实验结果之后才成立的筛选条件。把所有问题归为“随机数不够随机”会漏掉大量 更常见的数据处理和分析错误。

最后看候选人是否敢于停止错误决策。SRM 是症状，不是可以用重新加权自动消除的噪声。公开案例中，实验版本 改变了用户参与行为，反而让更多高参与用户被机器人过滤器删除，修复后业务结论发生反转。根因未解释前， 正确动作是冻结发布判断，而不是挑一个仍然显著的指标继续推进。

回答前需要澄清的问题

• 50/50 指的是分配、曝光还是最终分析人群？ 分配日志可能正常，但曝光、触发或指标资格过滤后出现

SRM。必须逐阶段检查，不能只看最终表。

• 随机化单位是什么？ 按工作区分流时，成员人数天然不相等；应先检验工作区数量，再用与集群随机化

相匹配的方法分析成员结果。

• 用户标识是否稳定且互斥？ 跨设备登录、Cookie 清除、匿名转登录和 ID 合并可能让同一人重复分配或

在组间移动。

• 实验比例是否在运行中调整过？ 10/90、50/50 等分阶段放量需要按每个时间段的配置计算期望人数，

不能用最后一个比例解释全程。

• “合格用户”由什么条件定义？ 条件若受实验版本影响，例如只保留点击新按钮的人，就属于处理后的

筛选，会破坏组间可比性。

• 是否存在版本特有的重定向、性能或错误？ 一组更慢、崩溃更多或无法完成埋点，会在执行和采集阶段

丢失用户。

• 哪些数据链路参与最终人数统计？ 需要区分分流日志、曝光日志、事件日志、去重、机器人过滤、

维表连接和指标窗口。

• 决策是否允许重新运行实验？ 若根因无法从原始日志无偏重建，可靠选择是修复后重跑，而不是强行

挽救当前结果。

30 秒回答框架

“我不会发布。先按 50/50 计算期望人数各 50,000，卡方统计量是 (51,000 - 50,000)² / 50,000 + (49,000 - 50,000)² / 50,000 = 40，自由度为 1， p 值约 2.54 × 10^-10，说明最终样本与配置比例严重不符。业务效果的 p 值因此不能作为发布证据。 我会依次比较分配、曝光、触发、日志处理和最终分析人数，再按时间、平台、版本和标识符切片，定位偏差首次 出现的位置。根因修复并通过 SRM、埋点和 A/A 检查后重新分析；无法无偏重建就重跑实验。”

分步骤深入解答

先把决策门槛写清楚：实验结果必须同时通过随机化、数据完整性和业务效果检查。SRM 检测应先于效果检验， 而且最好在平台中自动运行并突出显示。Microsoft 的公开实践使用 p < 0.0005 作为保守告警阈值，目的是 减少大规模实验平台中的误报；这是一个实践示例，不是所有团队必须照抄的通用常数。团队应预先设定阈值， 不能看到结果后再调整。

第一步：正确计算 SRM。

对于两组 50/50 实验，总样本为 100,000，期望人数各 50,000。卡方拟合优度统计量为：

χ² = Σ (observed - expected)² / expected = 40

两组且没有估计额外参数时，自由度为 1，对应 p 值约为 2.54 × 10^-10。这远低于常见的保守质量阈值， 不能用随机波动解释。卡方检验依赖足够的期望频数；NIST 给出的常用规则是每组至少约 5 个期望观测。 极小样本、极低比例或很多稀疏实验组应改用精确二项或多项检验。

比例必须和样本量一起解释。若只有 1,000 人、观察到 510/490，期望各 500，则 χ² = 0.4， p 值约 0.527，不能拒绝 50/50 假设。肉眼看到同样的 51/49，并不代表证据相同。

第二步：找到偏差首次出现的阶段。

建立一张阶段漏斗，每一步都保留按实验组统计的唯一随机化单位数：

若分配阶段已经失衡，先检查实验配置、分桶代码和随机化 ID。若分配正常、曝光后失衡，检查某个版本是否 更容易加载失败、崩溃或被重定向。若未触发总体分析正常，只有“访问结账页的人”分析失衡，就检查触发条件 是否会被实验影响，或对照组是否缺少等价日志。若偏差只在最终事实表出现，重点排查过滤、去重和连接。

第三步：用切片和时间线缩小根因。

按小时画累计观测人数与累计期望人数，找出差异从何时开始。突然跳变通常指向配置、发布或数据任务变更； 从实验开始持续偏离更像分桶或触发条件问题。再按平台、浏览器、应用版本、地域、登录状态、ID 类型和流量 来源切片，但每个切片都要同时展示样本规模、方向和首次异常时间。

切片不是为了寻找一个“通过 SRM 的子群”继续发布。大量切片会自然产生少量小 p 值；它们的作用是形成 可验证的根因假设。例如 SRM 只集中在旧版 iOS，且该版本的实验组曝光日志明显缺失，就应核对客户端发布 和事件发送，而不是删除 iOS 后宣称总体实验可信。

第四步：验证随机化与身份语义。

分桶函数应由稳定随机化 ID、实验 ID 和固定盐值确定，同一个单位在实验周期内始终得到同一组。检查：

1. 同一随机化单位是否出现多个组。
2. 匿名 ID 合并到账号 ID 时是否重新分流。
3. Cookie 清除或跨设备是否制造重复“新用户”。
4. 排除名单、员工流量和机器人是否在分配前后使用一致规则。
5. 逐步放量时，每个配置版本是否有可审计的生效时间。

按工作区或家庭集群分流时，SRM 应先比较集群数。一个实验组恰好包含几个超大工作区，成员行数出现 51/49 并不一定说明分流错误；把成员当独立随机样本反而会制造错误告警。

第五步：审查处理后筛选和缺失机制。

有效触发条件应尽量由实验处理前的信息决定。例如“进入结账页”可通过两组都存在的页面曝光记录定义； “点击实验组新增优惠券按钮”无法在对照组等价观测，用它筛选会让实验组天然更多。类似地，实验组性能改善 可能增加事件上报，性能退化可能减少上报；反作弊、超时和错误过滤也可能删掉受到处理影响最强的人。

不要默认缺失用户是随机样本。应比较原始分配日志与每个下游表的差集，抽取缺失 ID，检查其平台、时间、 版本和行为。若实验结果影响进入分析表的概率，最终转化差异会混入选择偏差。

第六步：决定修复、重建还是重跑。

• 分流配置错误或用户跨组：停止实验，修复后重新随机化并重跑。
• 原始分配和曝光完整，确定是可逆的日志任务丢行：修复任务，从未受偏差的原始事件重建，再重新做 SRM。
• 触发条件受实验影响：改为处理前条件，或回到未触发的意向处理人群；不能直接给人数较少的一组加权。
• 某客户端版本没有必要日志且无法回补：当前实验无法支持该人群结论，通常应修复埋点后重跑。
• 比例只因预先计划的分阶段放量变化：按每个时间段累加期望人数重新检验，并保留配置审计记录。

重新加权只有在选择机制已知、可估计且独立验证时才可能成立；多数 SRM 恰恰表示缺失机制未知。把 49,000 名实验用户简单乘上权重，使总数看起来等于 50,000，不会补回缺失用户的行为，也不会恢复随机性。

第七步：把防复发能力放进实验平台。

每次实验保留不可变的分配记录、配置比例和生效时间，并在分配、曝光、触发和分析人群上分别计算 SRM。 业务效果在完整性检查通过前不应成为发布依据。定期运行 A/A 测试，验证分桶、埋点和分析链路在没有产品 差异时是否仍产生异常。

告警要包含总量、期望与观测人数、p 值、偏差方向、异常开始时间和主要切片。发布、身份系统、反作弊或 ETL 变更后应自动提高检查优先级。实验结束后仍保存足够的配置与血缘信息，使团队能够复算当时的期望人数， 而不是只保留一张最终指标截图。

高质量示范回答

“我不会因为转化率提升 1.8% 且效果检验显著就发布。这个结论假设两组仍是可比的随机样本，但 50/50 配置下观察到 51,000 和 49,000 人，期望各 50,000。卡方统计量是 40，自由度 1，p 值约 2.54 × 10^-10，说明样本比例不匹配，当前业务结果应冻结。

我会先确认用户是否真是随机化单位，以及 50/50 是否覆盖整个实验周期。然后把人数沿数据链拆开： 分配、实际曝光、符合触发条件、进入事件事实表、进入最终分析。偏差在哪一步首次出现，就从那一步查。 分配已失衡时查配置、稳定 ID、盐值和跨组；分配正常但曝光失衡时查发布、性能、崩溃和重定向；只有触发 分析失衡时查条件是否被实验影响；最终表才失衡时查埋点、机器人过滤、去重和连接。

我还会按时间、平台、应用版本、地域、登录状态和 ID 类型切片，寻找同一方向且能解释机制的证据，而不是 挑一个没有 SRM 的子群继续发布。原始事件能够无偏重建时，修复数据任务并重新跑完整性检查；若用户跨组、 触发条件受处理影响或关键日志无法回补，就修复后重跑实验。

预防上，平台应在展示业务结果前自动跑 SRM，保留不可变分配日志和比例变更历史，并分别监控分配、曝光、 触发和分析人数。再用 A/A 测试、稳定分桶和处理前触发条件验证链路。只有根因解释清楚、修复后 SRM 通过， 我才重新看 1.8% 的业务提升和护栏指标。”

常见错误

• 看到业务 p 值小就直接上线 → 效果检验建立在样本可比的前提上 → 先通过 SRM 和数据完整性检查。
• 只看 51/49 的百分比 → 相同比例在不同样本量下证据强度不同 → 用期望人数和统计检验。
• 把 SRM 当成随机数生成器问题 → 执行、日志和分析过滤同样会制造失衡 → 沿全链路定位首次偏差。
• 继续跑到人数变得更接近 → 更多受偏数据不会恢复随机性，还可能掩盖时间局部故障 → 立即冻结判断并查根因。
• 简单重加权到 50/50 → 权重补不回系统性缺失用户的行为 → 只有缺失机制可识别且验证后才讨论校正。
• 只检查最终分析表 → 无法判断问题来自分配还是下游 → 保存并比较每个阶段的唯一随机化单位。
• 用实验组新增行为定义触发 → 对照组没有等价机会进入样本 → 使用处理前、两组对称的条件。
• 按成员数检查集群实验 → 集群规模差异会制造假 SRM → 先按真实随机化单位检验。
• 切出一个正常平台就发布 → 事后挑选人群增加错误结论风险 → 切片用于诊断，并重建或重跑预定义人群。
• 根因修复后沿用旧效果报告 → 原报告仍基于错误样本 → 重新生成 SRM、效果和护栏的完整分析。

追问及应对

追问一：如果同样是 51/49，但总样本只有 1,000 人呢？

期望人数各 500，观察人数为 510 和 490，卡方统计量是 (510 - 500)² / 500 + (490 - 500)² / 500 = 0.4，自由度 1 的 p 值约 0.527。 这不足以判定 SRM。它说明不能用固定的“比例差超过 1%”规则替代统计检验，但仍应检查是否有明确的 工程异常。

追问二：总体分配没有 SRM，只有 iOS 用户出现 SRM，实验还能用吗？

先考虑切片数量、iOS 样本量和异常是否有一致机制。若 SRM 集中在一个预先关注且规模足够的 iOS 版本， 并能由曝光失败或埋点缺失解释，就说明该人群结果不可信。其他人群是否可用取决于分析计划和根因是否真正 隔离；不能在看到结果后随意删除 iOS。更稳妥的做法是修复客户端并重跑预定义目标人群。

追问三：未触发的全体用户没有 SRM，触发分析却有，最可能是什么问题？

优先检查触发条件。它可能只在一个版本记录，或由实验处理后的行为决定。把触发定义改为两组都能在处理前 满足的条件，例如进入页面而不是点击新增组件。还要比较触发事件的埋点覆盖率；未触发总体正常说明基础分桶 可能没有问题，但不能证明触发后的效果分析可信。

追问四：为什么不能按已观察到的组别人数重新加权？

因为 SRM 没有告诉你缺失的是谁。若实验组少掉的正好是最活跃、最容易转化或最容易崩溃的用户，人数权重 只能补总量，不能补行为分布。只有选择概率由处理前变量完整解释、模型可验证且分析方案允许时，才可能进行 校正；这需要额外假设，不能作为默认补救。

追问五：按工作区 50/50 分流，但用户人数是 55/45，算 SRM 吗？

先看工作区数量。如果工作区数符合 50/50，而实验组随机抽到更多大型工作区，用户人数失衡可能是集群规模 差异，不是分桶故障。效果分析也必须考虑工作区内相关性。若业务要求用户流量也平衡，应在实验设计阶段采用 按规模分层或配对随机化，不能事后把用户行当成独立分流单位。

追问六：实验从 10/90 逐步放量到 50/50，如何计算期望人数？

按每个配置生效区间分别计算期望人数，再累加到各组。例如第一阶段 20,000 人按 10/90，第二阶段 80,000 人按 50/50，则两组总期望人数是 42,000 和 58,000，不是各 50,000。需要使用分配时实际生效的 配置和时间，不能用实验结束时的比例回填历史。