页面访问量，访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc5297915cfb.html
📄
页面访问量，访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键不是看总页面访问量涨跌，而是先确认分流是否真的随机：如果两个版本的访客在来源、设备、登录状态或进入时间上明显不同，页面访问量差异就不能归给版本本身。下面按“能稳定分流”和“不能稳定分流”两种条件，分别说明判断依据、该做的动作，以及哪些例外不能照搬。
先判断分流是否稳定，再决定要不要比页面访问量
当分流由服务端或同一套前端逻辑控制，且同一访客每次进入都被分到同一版本时，样本污染的风险较低，可以直接比较两组的页面访问量。此时要核对的是分组标识是否在会话开始时写入、后续请求是否沿用同一标识。
当分流依赖客户端脚本、缓存或人工链接时，同一访客可能在不同时间进入不同版本。此时页面访问量的组间差异很可能来自人群构成，而不是版本效果。判断方法是：按来源、设备类型、是否登录、首次进入时间分别拆开，看两组在这些维度上的占比是否接近。如果某一维度差异明显，就先不要读版本对比结论。
一个实际动作是：在分流逻辑中固定分组标识，并让该标识随会话全程传递。结果会直接影响下一步——如果标识稳定后两组构成趋于一致，说明此前差异主要来自分配方式；如果仍然不一致，就要继续查缓存、跳转链路或外部入口。
用可核查的证据链判断污染来自哪里
不要只看页面访问量总数。可以按下面的顺序收集证据：
- 站内统计：按分组分别看来源、落地页、设备、新老访客占比。
- 分流记录：确认分组发生在哪一步，是否在跳转或缓存之后被覆盖。
- 第三方估算与搜索引擎报告：它们与站内口径不同，只能用来判断外部流量结构是否变化，不能单独用来还原分组是否正确。
如果站内统计显示两组来源占比差异很大，而第三方估算显示整体来源结构没有明显变化，那么更可能是站内分流或跳转把不同人群送进了不同版本。反过来，如果站内和外部都显示来源结构变化，就要先排除外部流量本身波动，再谈版本影响。
假设某次测试中，A 版本页面访问量高于 B 版本。按来源拆分后发现，A 版本多出的访问主要来自一个外部推荐入口，而该入口只指向 A 版本。这个例子说明：页面访问量差异可以完全由入口分配造成，不能直接当作版本效果。这里的数字只用于说明比较方法，不代表真实项目结果。
两种条件下的不同选择
条件一：分流稳定且分组标识全程一致。此时可以继续比较页面访问量，但要把来源、设备、登录状态作为分层变量，先看各层内部是否同向。如果各层方向一致，版本差异更可信；如果只有某一层出现差异，就只在该层内下结论，不推广到整体。
条件二：分流不稳定或存在缓存、跳转覆盖。此时不应直接比较页面访问量。应先把分组标识固定到会话入口，再重新收集一段数据。重新收集后，如果两组构成仍然不同，就需要检查是否存在只面向特定人群的入口、旧链接或客户端缓存。只有在构成接近后，页面访问量的组间比较才有意义。
这两种选择的分界不是样本量大小，而是分配是否可重复。可重复的分配允许你逐步缩小解释范围；不可重复的分配只会让页面访问量变成人群差异的投影。
哪些例外不能照搬
如果版本差异本身就会改变访客行为，例如一个版本会触发跳转、登录或弹窗，那么两组的页面访问量口径可能从一开始就不同。此时先统一统计口径，再谈污染识别。
如果外部渠道正在同时调整投放或推荐策略，页面访问量的变化可能来自渠道结构变化。第三方估算、搜索引擎报告和站内统计口径不同，不能互相替代。请求量、抓取量或某项统计归零，也不能单独证明分流处理正确，它还可能来自采集中断、过滤规则变化或入口暂时不可用。
因此，识别样本污染的可操作标准是：分组标识是否稳定、两组构成是否接近、页面访问量差异是否在分层后仍然同向。只有这三步都通过，才适合把页面访问量差异归给版本；否则应先修正分配或口径，再进入下一轮比较。
