关键字分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1dcccab45279.html
📄
关键字分析：访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键，不是先争论哪个版本更好，而是先确认每个访客看到的页面版本是否被正确记录。若分组日志、页面版本和后续行为三者对不上，任何按版本汇总的指标都可能混入另一版本的用户，比较结果自然失真。
先定义“污染”发生在哪一层
假设有一个站内试验：部分访客看到旧版注册引导，另一部分看到新版。团队发现新版转化率略高，但两个角色对同一批数据给出不同解释：一方认为新版更有效，另一方认为新版样本里混入了老用户。
这时要区分三种污染。第一种是分配污染：访客被分到A组，却看到B组页面。第二种是记录污染：页面版本正确，但日志把版本字段写错或漏写。第三种是分析污染：原始日志没错，但汇总时把未分组访客并入某一组。三者对应的排查动作不同，不能只用“转化率差异”来反推。
用一条可核对的证据链定位问题
最实用的做法，是从单个访客的会话开始，而不是从总报表开始。取同一时间段的若干会话，逐条核对以下字段是否一致：
- 分组服务返回的版本标识；
- 实际渲染的页面模板或关键元素；
- 行为日志中记录的版本字段；
- 该访客是否在试验开始前已有历史行为。
如果分组标识是B，页面元素却是A，说明分配或缓存层出了问题。如果页面元素是B，日志却记成A，说明埋点或字段映射有问题。如果前三者一致，但汇总表里B组人数大于实际分配人数，说明分析口径把未分组流量并入了B组。
这一步的实际动作是：先冻结版本变更，再抽样核对。结果会直接决定下一步——若是分配问题，先查分流规则和缓存；若是记录问题，先查日志字段和上报时机；若是分析问题，先查汇总查询里的默认值或空值处理。
哪些现象不能单独证明污染
两组样本量不等、某天流量突然下降、某个版本转化率波动，都不足以单独证明样本污染。样本量不等可能来自分流比例本身；流量下降可能来自渠道变化、节假日或统计口径调整；转化率波动可能只是小样本的正常抖动。
反过来，如果出现以下组合，污染嫌疑会明显上升：同一访客在不同页面看到不同版本；版本字段缺失率异常升高；某组的行为数据里出现了不可能属于该组的入口来源。此时应先核对原始日志，而不是直接删除异常数据。
把分歧转成可核对的项目
当多个角色对同一事实理解不同时，不要继续争论结论，而是把分歧拆成待核对项。例如：
- “新版转化更高”这一结论依赖哪个时间窗口？
- 该窗口内版本字段的缺失比例是多少？
- 未分组访客在汇总时被归入哪一组？
- 是否存在同一访客跨版本的行为记录？
每个问题都应指向一份可查的记录：分流日志、页面快照、行为日志或汇总查询。能核对的项目越多，越容易判断污染是局部的还是系统性的。如果只有汇总报表能核对，而原始日志无法追溯，那么最稳妥的动作是暂停基于该数据的决策，先补齐日志字段。
一个注明假设的短例子
假设某次试验中，A组分配了1000人，B组分配了1000人，但汇总表显示B组有1200人。此时不能直接得出“B组更好”或“B组更差”。先查那多出的200人来自哪里：如果来自未分组流量，且这些人的行为模式与B组差异很大，那么B组指标就被稀释或拉高了。下一步应把未分组流量单独列出，再重新比较A、B两组。若未分组流量与B组行为接近，污染影响可能较小；若差异明显，则原有结论需要推翻。
这个例子的重点不是数字本身，而是动作顺序：先定位多出的人，再判断他们是否改变了版本间的可比性。只有完成这一步，后续的优化决策才有可靠依据。
