网站分析访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7f05df32bff4.html
📄
网站分析访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键，是先把“分流本身是否干净”当成独立问题，而不是直接比较两个版本的成绩。打开你手里的实验配置和一份原始访问日志，按用户标识、进入时间、版本标记三个字段做交叉核对：如果同一用户在短时间内同时出现在两个版本，或者分流比例与配置明显偏离，那么后续的转化差异就不能直接归因于版本，需要先清理或重新分流再谈结论。
先确认分流单元，别用页面浏览量当样本
样本污染最容易被忽略的来源，是统计单元和分流单元不一致。分流通常按用户、设备或会话进行，但报表里看到的往往是访问次数或页面浏览量。同一个用户刷新页面、跨设备登录、清空 Cookie 后再进入，都可能被重复计入不同版本。
实际动作是：从实验工具导出带用户标识的原始记录，而不是只看汇总报表。检查同一标识是否只对应一个版本。如果同一标识出现两个版本，说明分流没有粘住，这部分样本应当单独隔离，而不是混进总转化率里一起算。隔离之后你会得到两个数字：被污染样本的占比，以及干净样本的版本差异。前者决定这次实验还能不能用，后者才接近真实效应。
用进入时间找重叠窗口
分流规则变更、缓存未刷新、灰度发布未收尾，都会造成时间上的重叠。判断方法是把每个版本的首次进入时间画成一条时间线，看两个版本的活跃区间是否本应错开却发生了交叠。
- 假设某次调整在上午十点切换分流比例，那么十点前后各有用户进入。若十点后仍有用户被分到旧版本，且这些用户是首次进入，说明旧版本的入口没有完全关闭。
- 如果同一用户先进入 A 版本，之后又进入 B 版本，且两次进入之间没有重新触发分流条件，这属于典型的跨版本污染。
这一步的产出是一份时间重叠清单。如果重叠只发生在切换瞬间的少数用户，可以按时间窗口截断样本；如果重叠持续数小时，说明分流链路本身有问题，此时继续分析版本差异意义不大，应先修复分流再重新收集。
检查版本标记是否被缓存或代理改写
有时分流配置是对的，但用户实际看到的版本和记录里的标记不一致。常见原因是页面缓存、CDN 缓存或前端脚本在版本标记写入之前就已经返回了旧内容。
可执行的做法是：在实验页面加一个只用于核对的标记，例如在 <body> 上输出当前版本号，然后抽取一部分访问记录，比对“服务端记录的版本”和“页面实际渲染的版本”。如果两者不一致的比例不可忽略，那么报表里的版本分组就不可信。
这个动作的结果直接影响下一步：不一致比例低，可以按记录版本继续分析但注明误差；不一致比例高，必须先把缓存策略和标记写入顺序修正，否则任何版本比较都是在比较缓存命中情况，而不是版本效果。
区分污染与真实差异，看污染是否随机分布
样本污染不一定均匀。如果被污染的用户集中在某个来源、某个设备或某个时间段，那么它可能同时影响两个版本，也可能只影响其中一个。判断依据是：把污染样本单独拿出来，看它的来源、设备和时间分布是否与干净样本相似。
假设污染样本大量来自某一类外部跳转链接，而这类链接恰好更倾向于进入 B 版本，那么 B 版本的转化差异里就混入了来源差异。此时可以按来源分层，在每一层内部比较两个版本。如果分层后差异消失，说明原差异主要由污染样本的来源结构造成，而不是版本本身。
这一步的产出是分层后的对比结果。它能帮你决定是丢弃全部污染样本，还是保留其中来源均衡的部分。无论哪种选择，都要在结论里写明样本经过了怎样的清理，避免把清理后的结果当成原始全量结果。
决定继续、截断还是重跑的判断条件
识别出污染之后，处理方式取决于污染比例和污染是否与版本相关。
- 污染比例很低，且污染样本在两个版本之间分布均衡：可以保留全量数据，但把污染样本单独标注，并在结论中说明其影响方向。
- 污染比例中等，且污染与来源或设备相关：按来源或设备分层，只在层内比较版本，放弃跨层汇总的结论。
- 污染比例高，或同一用户频繁跨版本：停止当前实验的数据分析，修复分流和标记链路后重新收集。此时继续分析只会得到无法解释的差异。
需要提醒的是，第三方估算流量、搜索引擎报告和站内统计的口径本来就不同，样本污染的判断应以你能够核对的原始分流日志为准，而不是拿外部估算去反推版本分配。外部数据可以用来发现异常，但不能单独证明分流是否干净。
把上述核对做成一份固定记录：每次实验开始前记录分流单元、版本标记写入位置和缓存策略，实验结束后记录污染比例与处理方式。这样下一次遇到版本差异时，你能更快判断它是真实效应还是样本污染留下的痕迹。
