提升网站转化率：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f489adcedb00.html
📄
提升网站转化率：访客被分配到不同版本时怎样识别样本污染
先给结论：识别样本污染的关键不是看整体转化率谁高谁低，而是先确认分流是否真的随机、两组的访客来源与进入时间是否可比。如果分流本身被污染，任何版本对比都不可信，此时正确动作是暂停结论、回到分流层排查，而不是急着关掉表现差的版本。
先判断是分流污染还是结果波动
访客被分配到不同版本时，样本污染指的是两组访客在进入实验之前就已经系统性地不同。它和正常的随机波动有本质区别：波动会让差异忽大忽小，污染会让差异稳定地偏向某一侧。
一个可区分的证据是看分流日志。如果 A 组和 B 组的访客在来源渠道、设备类型、登录状态或首次访问时间上分布明显不一致，那更像是污染；如果这些维度分布接近，只是转化率有差距，那更可能是波动或版本本身的效果差异。这里要注意，站内统计与第三方估算流量的口径往往不同，不能用一个渠道的报表直接否定另一个渠道的分流记录。
两种条件下的不同选择
条件一：分流由前端脚本或客户端随机决定。这种情况下污染最常见的原因是脚本加载失败或缓存。部分访客在脚本执行前就被重定向，或者浏览器缓存了旧版本，导致某一组实际收到的是混合版本。此时应抽查分流日志中“分配版本”与“实际渲染版本”是否一致，若不一致比例偏高，先修分流再谈转化。
条件二：分流由服务端或边缘层决定。这种情况下污染更可能来自规则叠加，比如地域规则、登录态规则与实验规则同时生效，使某些用户被强制分到固定组。此时应检查是否存在优先级冲突，确认实验分组是否覆盖了全部目标流量，而不是只覆盖了一部分。
两种条件的选择依据是：污染发生在分配环节还是渲染环节。分不清这一点，后续所有优化动作都会打偏。
用可核对的证据链锁定污染
建议按下面的顺序收集证据，每一步的结论决定下一步动作：
- 导出分流日志，按访客 ID 统计每人实际看到的版本数量。如果同一访客在不同时间看到不同版本，说明分配不稳定。
- 对比两组的进入时间分布。如果 B 组集中在某个时段，而 A 组分散在全天，差异可能来自时段而非版本。
- 核对来源渠道构成。若某组大量来自站内推荐位或广告落地页，而另一组主要来自自然访问，两组本就不可比。
- 检查是否有爬虫或预加载请求被计入。这类流量通常不产生真实转化，却会稀释某一组的分母。
这里要提醒：请求量或抓取量突然归零，不能单独证明分流处理正确，它也可能是采集故障、日志延迟或规则误删造成的。必须结合访客 ID 的去重结果一起看。
一个注明假设的短例子
假设某次实验发现 B 版本转化率明显低于 A 版本，直觉上应该下线 B。但抽查分流日志后发现，B 组有相当比例的访客来自一个刚上线的广告落地页，而 A 组没有。此时两组的分母构成不同，转化率差异可能来自流量质量而非版本设计。正确动作是先按来源分层再看组间差异，而不是直接下结论。这个例子中的数字仅为说明比较方法，不代表任何真实项目结果。
什么时候可以停止排查
当分流日志显示同一访客版本稳定、两组在来源与时间维度分布接近、且去重后的访客数与实际进入数能对上时，可以认为样本污染已排除，此时再比较转化率才有意义。若上述任一条件不满足，应继续停留在诊断阶段，不要进入版本取舍。
需要强调的是，即使排除了污染，一次对比也只能说明当前条件下的差异，不能推断长期效果，更不能承诺任何固定的提升幅度。把诊断做扎实，比急着上线或下线一个版本更重要。
