网站权重检测：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /76675b257f96.html
📄
网站权重检测：访客被分配到不同版本时怎样识别样本污染
先给结论：当访客被分到不同版本时，样本污染通常不是靠“权重掉了多少”识别，而是靠分组标签与统计口径是否对齐来识别。你要确认每个访客被分到哪一组、该组的指标由谁记录、两组是否在时间与来源上可比。只要这三件事有一件对不上，后续的权重对比就不能作为判断依据，应优先修正分组或退出这次对比。
先确认污染来自分组还是来自口径
访客被分配到不同版本，常见做法是按客户端或服务端分流。污染的第一种来源是分组本身泄漏：同一访客在会话中途切换版本，或爬虫、内部账号、回访用户被反复分配。第二种来源是口径错位：站内统计按会话计数，而外部估算按域名整体聚合，两者混在一张表里比较，看起来像某个版本变差，实际只是统计对象不同。
区分方法很直接：把分组标签单独拉出来，看同一访客标识是否在两组都出现过。如果出现，说明分流不稳定，属于分组污染；如果访客始终只在一组，但两组的数据来源不同，属于口径污染。前者要改分流逻辑，后者要统一数据来源，两者的处理动作完全不同。
保留、改写还是退出：三种取舍的适用前提
遇到污染时，不必强行把这次对比做完，可以按条件选择。
- 保留：仅当污染比例很小、且污染集中在与结论无关的维度时成立。例如只有内部账号跨组，而内部账号已被单独标记、可从两组同时剔除。此时保留数据的前提是剔除规则对称，不能只从表现差的一组删。
- 改写：当分流本身可用，但统计口径不一致时适用。做法是回到原始访问日志，用同一套会话定义重新聚合两组，再比较。改写的前提是原始日志里保留了分组标签和访客标识，否则无法重算。
- 退出：当分流在会话中途反复切换、且无法回溯每个访客的归属时，这次对比应放弃。继续分析只会把分流缺陷误读成版本差异，投入越多，误判越深。
判断顺序建议是先看能否改写，改写不了再看污染比例是否小到可保留，两者都不成立就退出。
用一条可核查的证据链替代直觉判断
不要只凭“某版本数据变差”下结论。可以按下面这条链走一遍，每一步都留下可复查的记录：
- 取一段固定时间窗，导出带分组标签的访问明细。
- 按访客标识统计跨组次数，得到分组泄漏的规模。
- 对两组分别用同一会话定义重算关键指标。
- 检查两组的来源构成、设备构成、时间分布是否接近。
- 若构成差异大，先做分层对比，而不是直接比总量。
这条链的作用是让“污染是否存在”变成一个可复核的问题。假设某站点把新访客分到 A 版、回访访客分到 B 版，那么两组天然在来源和频次上不同。此时总量差异更可能来自访客类型，而不是版本本身。动作上应改为在同一访客类型内部比较，或改用随机分流，结果才会影响下一步是否继续该实验。
哪些信号不能单独证明分流是干净的
有几个现象容易被误当成“没问题”的证据，需要谨慎：
- 总请求量或总访问量没有明显异常，不能证明分组干净，因为两组此消彼长时总量可能不变。
- 外部估算流量与站内统计接近，不能证明口径一致，两者本就可能因统计范围不同而巧合接近。
- 某版本转化率更高，不能直接归因于版本，若该组集中了更多老访客或特定渠道，差异可能来自样本构成。
这些信号只能作为辅助，不能替代分组标签核对。把分流标签和原始日志对齐，才是识别样本污染的核心依据。
把结论落到下一步动作
如果你确认存在分组泄漏，下一步是修分流逻辑并重新开一段干净的观察窗，而不是在旧数据上继续加权修补。如果确认是口径错位，下一步是统一统计来源后重算，再决定是否保留这次对比。如果两者都无法修正，就退出这次版本比较，改用随机分流重新开始。这样处理的好处是：无论最终保留还是退出，你依据的都是可复查的分组事实，而不是被污染数据带出的表面差异。
