a5诊断：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da259a12a59d.html
📄
a5诊断：访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键，不是先看哪个版本数据更好，而是先确认分流记录和事件数据是否来自同一套身份口径。如果分流日志按设备ID记录、分析工具按登录账号去重，那么同一批访客会被重复计入不同版本，后续比较就失去意义。此时应暂停版本效果比较，先做一次身份口径对齐。
先判断污染来自分流层还是分析层
分流层污染指访客被重复分配或分配结果未持久化。典型证据是同一设备在短时间内多次触发分流请求，且返回不同版本。分析层污染指分流正确，但事件上报时身份标识丢失或替换，导致同一访客的行为被拆到两个版本。两者的处理动作不同：前者要检查分配逻辑和缓存，后者要检查埋点参数和去重规则。
一个可操作的区分方法是：取一小段访问日志，按设备ID和账号ID分别聚合，观察同一访客是否出现在两个版本的记录中。如果只有按账号聚合时出现交叉，问题更可能在分析层；如果按设备聚合也交叉，问题更可能在分流层。这个动作的结果决定下一步是改分配代码还是改上报参数，而不是继续调报表筛选。
两种条件下的选择：先冻结比较还是先清洗数据
条件一：污染比例低且分流记录完整。此时可以保留实验继续运行，但把分析口径从“按账号去重”改为“按分流时写入的稳定标识去重”。代价是需要重新处理已上报事件，且部分无法回溯身份的事件只能丢弃。选择这一路径的前提是分流记录里保存了当时使用的标识，否则清洗无从下手。
条件二：污染比例高或分流记录缺失。此时继续比较版本差异没有意义，应冻结该实验的结论输出，重新分配流量并确保分配结果写入持久化存储。代价是损失已积累的观察期，但避免了基于污染样本做出错误决策。判断“比例高”不依赖某个固定阈值，而是看随机抽取的访客记录中，交叉出现的比例是否足以改变版本间主要指标的排序方向。
用证据链确认污染，而不是靠单一指标波动
转化率突然下降或某版本访问量异常升高，都不能单独证明样本污染。合理的替代解释包括：投放渠道变化、页面加载失败、统计口径调整、机器人流量。要确认污染，需要形成一条可核查的证据链：分流日志显示同一标识被分配两次，分析事件中该标识同时携带两个版本参数，且该现象在时间上早于指标异常。
实际操作中，可以先在分流服务中增加一条临时校验记录，把每次分配的设备标识、账号标识、版本号和时间戳写入独立日志。运行一个短周期后，按标识分组统计版本数量。如果某个标识对应多个版本，再回到分析工具中查该标识的事件序列，确认是否被重复归因。这个动作的结果会告诉你污染是持续存在还是仅发生在特定时段，从而决定是修复后继续还是重新开始。
例外情况：身份合并本身就会制造交叉
当访客先以匿名状态进入A版本，之后登录账号并被合并到B版本时，记录中会出现同一账号关联两个版本。这不一定是分流错误，而是身份合并的正常结果。此时应检查合并规则是否把匿名阶段的行为错误地归给了登录后分配的版本。处理方式是明确以分流时刻的版本为准，还是以登录后的版本为准，并在分析层统一该规则。如果不统一，任何版本比较都会混入身份合并带来的噪声。
识别样本污染的目标不是追求零交叉，而是确保交叉不影响版本间比较的方向。先对齐身份口径，再决定冻结还是清洗，最后用证据链排除其他解释，才能让后续的版本判断站得住脚。
