网站数据统计，访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /00a91c0db590.html
📄
网站数据统计，访客被分配到不同版本时怎样识别样本污染
先看一个矛盾：小流量试验里，B版本转化率明显高于A，但把流量放大后差距消失，甚至反转。此时最该怀疑的不是“效果不稳定”，而是两组访客的构成从一开始就不对等——样本污染。识别它的关键，是找到分流之外的系统性差异，而不是反复重算总转化率。
先分清两种解释：真差异还是分组差异
当小样本显示优势、规模扩大后消失，通常有两种成立路径。第一种是版本本身确实有效，但效果只对某类访客明显，流量放大后这类访客占比下降，平均效果被稀释。第二种是分流环节把不同来源、设备或活跃度的访客系统性地塞进了某一组，早期的小样本恰好放大了这种偏差。
两者的区别在于：真差异会随样本结构变化而平滑衰减，分组差异则会在特定维度上留下稳定的偏斜。判断时不要先看总指标，而要先看两组的构成是否可比。
用分流前的基线指标做一次对照
分流之后、版本生效之前，两组本应在关键维度上接近。实际动作是：在试验开始后的前一段流量里，分别统计两组的来源渠道占比、新老访客比例、设备类型分布和进入页面。如果某一组在某个维度上持续偏离，比如自然搜索占比明显更高，就说明分配机制可能受来源或缓存影响。
这一步的结果会直接决定下一步：若基线可比，问题更可能出在版本效果本身，应转向分群分析；若基线已经偏斜，先修分流，再谈效果，否则后续任何统计都建立在错误分组上。
检查触发条件是否在分流之后才生效
一个常被忽略的污染来源是：分流按“访问”执行，但版本展示依赖某个条件，比如登录状态、地区或页面加载完成。结果是部分被分到B的访客实际没看到B，却被计入B组。这类偏差不会在总流量上显现，只会在“实际曝光”与“被分配”两个口径之间出现缺口。
可核查的证据链是：对比被分配人数与实际触发版本的人数，再按来源或设备拆开。如果缺口集中在某一类访客，就能区分“版本无效”和“根本没看到版本”这两种截然不同的结论。
假设例子：一次放大后反转的排查顺序
假设某页面试验，小流量时B组转化率高于A组约两成，扩量后差距归零。按下面顺序排查，可以避免把分组问题误判为效果问题：
- 先核对两组在分流时的来源与设备构成，确认是否可比。
- 再对比被分配人数与实际曝光人数，找出未触发版本的缺口。
- 若两者都正常，再按来源或新老访客分群，看效果是否只存在于某个子群。
如果第1步就发现B组自然搜索占比偏高，那么“扩量后反转”更可能是流量结构变化，而不是版本失效。此时应固定来源做分层比较，而不是继续扩大总流量。这个动作会改变下一步：从“加量验证”转为“分层验证”。
哪些情况下不能直接照搬这套判断
样本污染识别依赖分流机制可控、触发条件可记录。如果试验工具无法区分“被分配”和“实际曝光”，或者多个版本在同一页面叠加，那么上述对照会失真。此时更稳妥的做法是先统一口径、固定一个变量，再谈识别。另外，第三方估算流量与站内统计口径本就不同，二者对不上时，不能单凭一方归零或偏离就断定分流出了问题，还需排除统计脚本、缓存和时区等合理解释。
识别样本污染的本质，是确认两组除了版本之外是否真的只差一个变量。做不到这一点，任何放大后的结论都只能当作线索，而不是依据。
