网站检测工具访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8c179434c65d.html
📄
网站检测工具访客被分配到不同版本时怎样识别样本污染
先给有条件的结论：如果分流是在服务端完成、且每个访客只看到一个版本，那么用网站检测工具按版本分别统计通常能识别样本污染；但如果分流靠客户端脚本、或同一访客在会话中多次切换版本，那么“按版本分组”本身就会把同一批人拆进两组，检测结果反而会掩盖污染。下面给出可核对的证据链，以及一个会使结论失效的反例。
先确认分流发生在哪一层，这决定样本是否可切分
样本污染的核心不是数据脏，而是“同一个访客的多次行为被记到了不同版本名下”。要判断是否发生这种情况，先确认分流位置：服务端分流通常在响应生成前决定版本，同一访客的后续请求大概率沿用同一版本；客户端分流则在页面加载后用脚本改写内容，同一访客刷新、返回或跨页时可能被重新分配。
用网站检测工具时，可以抓取同一访客标识在多个页面上的版本标记，看它是否稳定。若同一标识在不同页面归属不同版本，样本已经被污染，此时按版本汇总的转化差异不能直接归因于版本本身。
用三类可核对证据判断污染是否存在
- 访客标识与版本标记的对应关系：导出带有访客标识、版本标记、时间戳的原始日志，统计每个标识出现的版本数量。若大量标识对应两个以上版本，污染成立。
- 会话内版本切换次数：按会话聚合，观察同一会话中版本标记是否变化。会话内切换比跨会话切换更能说明分流不稳定。
- 版本组的人数与流量比例是否偏离设定：如果分流本应各占一半，但两组人数长期明显偏离，可能是部分访客被重复计入，也可能是分流规则本身有偏，需要结合前两项证据区分。
这三项要一起看。单看人数比例偏离，既可能是污染，也可能是分流规则写错，不能单独下结论。
一个会使结论失效的反例
假设分流脚本在页面加载后执行，访客首次进入被分到A版本，随后脚本因缓存或异步加载失败，第二次访问被分到B版本。此时网站检测工具按版本统计，会显示A、B两组都有该访客的行为，看起来像“两组表现接近”，实际是同一批人被拆开。若只看汇总指标，很容易误判为“版本无差异”。
反过来说，如果分流在服务端完成、访客标识稳定，那么即使两组指标接近，也更可能是版本本身差异小，而不是样本污染。判断的关键在于分流层和标识稳定性，而不是指标本身的高低。
下一步动作：先固定访客标识，再重跑分组
确认存在污染后，实际动作是：在分流逻辑中固定访客标识与版本的绑定关系，确保同一标识在整个观察期内只进入一个版本；然后用网站检测工具重新导出原始日志，按“标识—版本”一对一的关系重算分组指标。
这个动作的结果会直接影响下一步：如果重算后两组差异仍然存在，说明版本差异可能是真实的，可以继续做显著性判断；如果重算后差异消失，说明此前的差异来自样本污染，需要先修复分流再谈版本效果。无论哪种结果，都不要在污染未排除前用汇总指标做决策。
把“归零”当作线索而不是结论
如果某个版本组的请求量或转化数突然归零，不能直接判定该版本失败。合理解释还包括：分流规则把该版本排除、埋点未触发、日志采集延迟，或该版本只对特定人群开放。要区分这些解释，需要回到原始日志，检查该版本是否有访客标识进入、埋点是否上报、时间戳是否连续。只有排除了这些替代解释，才能把归零当作版本本身的问题。
样本污染的诊断依赖可核对的日志和稳定的访客标识，而不是单一指标的涨跌。先确认分流层，再固定标识重算，才能让后续的版本比较建立在可解释的样本上。
