网站检测：访客被分配到不同版本时怎样识别样本污染

📍 WDQWDWQD987AAAAA:216.73.217.108
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /08ae27621645.html
📄

网站检测：访客被分配到不同版本时怎样识别样本污染

先看结论：如果同一批访客在进入页面后被分成不同版本，而你的分析把两批人混在一起统计，那么问题往往不在版本本身，而在样本被污染。识别污染的关键不是看总转化率高低，而是确认分流是否随机、分组是否稳定、以及各组在进入实验前是否已经存在差异。最实用的动作是先冻结实验、导出分组日志，再按访客维度核对分组归属，而不是按会话或页面浏览去重。

矛盾现象：总量没变，但每个版本都变差了

一个常见场景是：旧活动页准备下线，但其中一部分模块仍有价值，于是你把它改造成新版本，用分流工具让访客随机看到 A 版或 B 版。上线几天后，总转化量与改版前接近，但后台显示 A、B 两版各自的表现都不如预期。这个矛盾通常有两种解释。

第一种解释是版本本身确实没有优势，两个版本都只是把旧页面的问题换了位置。第二种解释是分流过程产生了样本污染：某些访客被重复计入、某些渠道被系统性分配到同一版本，或者分组信息在跳转、缓存、登录后丢失。两种解释都会让数据看起来“都不好”，但处理方式完全不同。

区分两种解释的证据：先看分组是否独立于访客特征

要区分“版本无效”和“样本污染”，需要检查三组可复核证据。

这三组证据里，第一组最能直接证明污染是否存在。假设一个匿名 ID 在周一分到 A 版，周三清除了 Cookie 后被重新分到 B 版，那么同一个人就同时贡献了两组数据。此时即使 B 版转化率更高，也不能说明 B 版更好，因为两组样本已经不再独立。

实际动作：按访客维度重建分组表，再决定是否继续

发现疑似污染后，不要急着下结论说“实验失败”。更稳妥的动作是：暂停新的分流，保留现有日志，按访客维度重建一张分组表。具体做法是，把分流记录、站内行为日志和订单或表单提交记录按同一个匿名 ID 关联，检查每个 ID 的分组是否唯一、首次分组时间是否早于行为时间。

这个动作的结果会直接影响下一步。如果重建后发现大量 ID 跨组，说明当前分流机制不适合继续用于比较；应先修复分组稳定性，再重新开始。如果重建后分组基本唯一，但两组来源结构仍明显不同，说明问题可能出在分流触发条件上，例如只在某个落地页触发、只在登录后触发，导致部分渠道被排除在外。此时需要调整触发范围，而不是直接否定版本。

旧内容退出时，怎样避免把残留流量当成新样本

旧内容、旧系统或旧合作关系退出时，常见做法是保留一部分入口继续导流。这本身没有问题，但要注意：旧入口带来的访客可能带有不同的意图和路径。如果这些访客被随机分到新版本中，他们和新入口访客混在一起，就会让分组失去可比性。

一个可操作的判断方法是，单独标记来自旧入口的访客，观察他们在各组中的占比。如果旧入口访客在某一组中占比明显偏高，而他们的行为又与新入口访客不同，那么这组数据就不能代表新版本的真实表现。此时可以选择把旧入口访客排除在版本比较之外，或者先让旧入口完成下线，再重新开始分流。

需要强调的是，第三方估算流量、搜索引擎报告和站内统计的口径本来就不同。站内分流日志反映的是实际到达页面的访客，第三方估算可能包含未执行脚本的访问。两者对不上时，不能单凭某一项指标断定污染存在，而应回到访客标识和分组记录这条可复核的证据链上。

把识别动作固定成检查顺序

为了在下次遇到类似情况时快速判断，可以按以下顺序检查：

  1. 确认分流是否在访客首次到达时完成，而不是在页面滚动或点击后才触发。
  2. 导出分组日志，按稳定访客标识去重，统计跨组 ID 的比例。
  3. 比较各组的渠道、设备、新老访客结构，找出系统性偏差。
  4. 回看实验前行为基线，确认两组在进入实验前是否已经不同。
  5. 如果污染比例高，先修复分组机制再重跑；如果污染比例低但来源结构不同，先调整触发条件或排除旧入口流量。

这套顺序的核心是：先证明样本是否独立，再讨论版本优劣。只要分组不稳定，后续任何转化率比较都缺少可靠前提，继续优化页面也只是在污染的数据上做决定。

图1 图2
nginx