网站流量查询：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b94bf779efc7.html
📄
网站流量查询：访客被分配到不同版本时怎样识别样本污染
结论先说：当访客被分流到不同版本，而你在流量查询里把两个版本的数据合并看，样本污染几乎必然发生，此时任何“整体上涨或下跌”的判断都不可靠。可用的做法是先把分流标识拆出来，再比较各版本自身的口径；如果分流本身不随机，比如按设备、地域或登录状态切分，那么拆开也救不回来，这是最常见的反例。
先确认污染来自分流，而不是流量本身变化
分流实验或灰度发布期间，流量查询工具看到的往往是合并后的总量。假设你把一半新访客送进改版页，另一半留在旧页，两边跳出率天然不同，合并后的平均值就会向样本量大的那一侧偏移。此时总量上升并不代表改版有效，只代表权重变了。
区分这两种解释需要可核对的证据，而不是看曲线形状。可以查三类记录：分流规则写在哪一层（前端脚本、边缘节点还是服务端）、分流比例是否按会话稳定、以及流量查询工具能否按版本维度拆开。如果只能看到合并总量，第一步不是下结论，而是先补上版本维度。
用可核对的证据链判断污染程度
把证据按“谁被分到哪一组”排列，比直接看指标更有用。下面这组检查项能帮你判断污染是轻微还是致命：
- 分流键：是按用户 ID、Cookie 还是随机数？按随机数意味着同一访客刷新后可能换组，样本会互相渗透。
- 分组稳定性：同一访客多次访问是否始终落在同一版本。不稳定就说明两组数据在互相污染。
- 口径一致性：流量查询工具、站内统计和分流日志是否用同一时间窗和同一去重规则。
- 触发时机：分流发生在页面加载前还是加载后。加载后分流会让旧版本先被记录一次。
如果分流键不稳定，或分流发生在统计脚本之后，那么即使你把版本拆开，两组样本也已经串味。这种情况下正确动作是修复分流实现，而不是继续调分析报表。
一个注明假设的短例子
假设某页面把 70% 访客分到 A 版、30% 分到 B 版，A 版跳出率 40%，B 版 60%。合并后整体跳出率约为 46%。如果某天分流比例因故障变成 30% / 70%，即使两个版本各自表现完全没变，合并跳出率也会升到约 54%。
这个例子里数字只用于说明比较方法：合并值的变化可以由权重变化单独解释，不需要任何真实效果变化。要排除这种解释，就得拿到分组后的分母，而不是只看合并分子。
分流不随机时，拆开也无效
反例出现在按非随机维度分流的情况。比如新版本只对移动端开放，或只对已登录用户开放。这时版本差异和设备差异、登录状态差异绑在一起，拆开比较仍然是把两种原因混在一起。你无法判断变化来自版本还是来自人群本身。
识别这种绑定的方法是看分组前的分布：两个版本在设备、来源、地域、新老访客比例上是否接近。如果明显不接近，那么任何版本间对比都只能当作描述，不能当作因果。此时下一步动作应是改回随机分流，或至少在分析时把这些维度作为分层条件分别看。
下一步动作：先修分流，再谈结论
发现污染后，优先做一件能改变后续判断的事：把分流标识写进统计请求，让流量查询能按版本出数。动作的结果是，你能看到每组自己的分母和转化，而不是一个被权重拉扯的合并值；如果拆分后两组样本量都太小，说明当前分流比例或观察窗口不足以支撑结论，下一步应延长观察或调整比例，而不是急着宣布胜负。
如果修复分流后发现两组在核心维度上仍然不可比，那就回到分层分析，或者暂停基于该实验的决策。样本污染不是靠更多报表能消除的，它只能靠更干净的分流和更明确的口径来避免。
