网站访问量增加，访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /733dc9f01376.html
📄
网站访问量增加，访客被分配到不同版本时怎样识别样本污染
先给结论：当访问量增加伴随分流实验或灰度发布，样本污染通常表现为“组间差异在分流日志里对不上”，而不是流量数字本身异常。识别方法是把分流决策日志、站内事件日志和页面版本标识三者按同一访客标识对齐，先确认每个访客是否只落入一个版本，再判断指标差异是否来自版本本身。若对齐后仍有一批访客同时出现在两个版本，这批人就是污染源，后续分析必须先剔除或单独归因，否则任何版本对比都不可信。
假设情境：一次灰度发布后的指标反常
假设某站点在访问量上升期间上线新版页面，用分流规则把访客分成 A、B 两组。运营发现 B 组转化率明显低于 A 组，但两版页面内容差异很小，于是怀疑新版设计有问题。此时不要急着改设计，先检查样本是否被污染。可核查的证据链是：分流服务记录“某访客被分到哪一组”，前端埋点记录“该访客实际看到哪个版本”，站内行为记录“该访客完成了什么动作”。三者用同一个访客标识关联，如果出现一个访客在分流日志里属于 A，但埋点里上报了 B 版本标识，就说明分流生效与页面渲染之间出现了错位。
污染最常见的三个来源
分流标识在跳转或缓存中丢失
当访客先到落地页再跳转到目标页，或经过 CDN、反向代理、多域名跳转时，分流标识可能没有随请求传递。结果是同一访客在不同页面被重新分配，甚至在同一会话内切换版本。动作上，可以抽取一批被怀疑的访客，检查其请求链路中是否每个环节都携带了同一个分流标识。若某个环节缺失，后续版本判断就会失真，下一步应先修复标识透传，再重新积累样本。
客户端缓存与多标签页并行
访客可能在一个标签页打开 A 版本，在另一个标签页打开 B 版本，浏览器缓存又让旧版本继续生效。此时站内统计会把两个版本的行为混在同一访客身上。识别方法是查看同一访客标识下是否出现多个版本标识，且时间戳交错。若存在，说明该访客不能作为任一版本的干净样本。
埋点上报延迟或重复
埋点队列在网络波动时可能延迟上报，导致访客先看到 A，后切换到 B，但 A 的行为事件在切换后才到达。表面看是 B 组数据异常，实际是 A 组事件被记到了 B 组时间窗口。可对照事件时间戳与版本切换时间，若事件时间早于当前版本生效时间，就应归回原版本。
用一张对照清单定位污染范围
不要只看汇总指标，按访客粒度做一次交叉核对更可靠。可以按以下顺序检查：
- 分流日志中每个访客是否只有一个组别；若出现多个，标记为疑似污染。
- 前端埋点中每个访客是否只上报一个版本标识；若多个，记录切换时间点。
- 站内行为事件的时间戳是否落在该访客当前版本的有效区间内。
- 同一访客标识是否跨设备或跨浏览器出现；若是，确认是否共用登录态导致合并。
完成核对后，计算被标记访客占总样本的比例。这个比例不需要精确到小数，只需判断污染是集中在少数异常链路，还是已经扩散到主要分流路径。如果集中在少数链路，可以剔除后继续对比；如果扩散到主要路径，则应暂停版本对比，先修复分流与埋点的一致性。
剔除污染样本后，下一步怎么走
假设核对后发现 8% 的访客同时出现在两个版本中，且这些访客的转化行为明显偏向其中一组。此时直接比较全量数据会高估或低估版本差异。动作是：把这批访客单独归入“混合组”，不参与 A/B 对比，同时检查他们进入混合组的原因是否与某个入口、某类设备或某个跳转路径相关。如果原因集中，说明污染不是随机的，而是特定链路的结构性问题，修复该链路比调整版本设计更优先。修复后重新分流，并确认新样本中不再出现同一访客跨版本的情况，再开始下一轮对比。
哪些证据不能单独证明污染已排除
访问量增加本身、某组转化率回升、或某个统计口径下差异消失，都不能单独证明样本已经干净。第三方估算流量、搜索引擎报告和站内统计的口径本来就不同，把它们直接相减没有诊断意义。更合理的解释还包括：分流比例配置错误、统计时间窗口错位、或部分访客被重复计数。要排除这些可能，仍需回到访客级的分流日志与版本标识对齐结果。只有当同一访客在整条链路上只对应一个版本，且行为事件时间戳落在该版本有效区间内，才能认为这批样本可用于版本对比。
