网站访问量查询在访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /05cde2c5a9b8.html
📄
网站访问量查询在访客被分配到不同版本时怎样识别样本污染
先给结论：当你用网站访问量查询来对比两个版本时，样本污染指的是同一批访客因为分流、缓存或统计口径原因，被同时算进两个版本，或者两组的访客构成根本不可比。识别它的关键不是看总量差异，而是先确认分流是否稳定、统计是否按同一口径记录。如果分流在会话中途改变，或者两个版本记录的是不同层级的事件，那么任何对比结论都不成立。
先判断你面对的是分流污染还是口径污染
这两种污染的表现相似，处理方式却完全不同，所以第一步是区分它们。
分流污染的特征是同一个访客或同一会话在短时间内同时出现在两个版本里。常见原因是：分流逻辑基于随机数但未做持久化，访客刷新后重新被分配；或者前端先渲染默认版本、再异步切换到另一版本，导致两个版本都被触发一次。此时你在网站访问量查询中会看到两组的会话数之和大于实际独立访客数，或者同一设备标识在两个分组里都有记录。
口径污染的特征是分流本身稳定，但两组统计的触发条件不同。例如A版本在页面加载时上报，B版本在某个按钮出现时上报；或者一组按会话计数、另一组按事件计数。这时两组的访客数看起来合理，但分母含义不同，比较的是两个不同的东西。
区分依据很简单：如果同一标识跨组出现，是分流污染；如果标识不跨组但计数层级不同，是口径污染。前者要修分流，后者要统一统计定义。
用可核查的证据链确认污染，而不是靠总量差异
总量差异本身不能证明污染，因为两个版本的真实表现本来就可能不同。你需要一条能独立验证的证据链。
- 取一小段固定时间窗口，导出两组各自的原始记录，至少包含设备或用户标识、时间戳、版本标识。
- 按标识做交集。如果交集非空且占比明显，说明存在跨组分配。
- 对交集内的标识，按时间排序看它们的版本标识是否在会话中途切换。中途切换是分流未持久化的直接证据。
- 如果交集为空，再检查两组记录的事件名称和触发时机是否一致。不一致就是口径问题。
这个动作的结果会直接决定下一步：交集非空且中途切换，就去修分流持久化；交集为空但事件定义不同，就去统一上报口径。不要跳过这一步直接去调分流比例，那是在没有确认原因的情况下改动系统。
假设例子：一个可复现的判别方法
假设某页面用前端脚本做50/50分流，脚本在每次页面加载时重新随机。你查网站访问量查询时发现A组会话数比B组高出一截，但两组的转化事件数量接近。
此时不要急着下结论说A版本更好。按上面的方法导出原始记录，如果发现相当一部分标识在几分钟内既有A又有B的记录，那就是分流未持久化造成的污染。真实的独立访客被拆成了两组，会话数被重复计算，而转化事件因为只在某个版本触发，反而没有翻倍。这种情况下，两组的会话数都不可信，转化率的分子分母来自不同的访客集合。
修正动作是把分流结果写入持久存储，让同一访客在实验期内始终落在同一组。修正后重新取一段数据，再检查交集是否为空。只有交集为空时，两组的对比才有意义。这个例子的数字仅用于说明判别逻辑，不代表任何实际项目的表现。
例外：什么时候污染无法完全消除，以及该怎么处理
有些情况下你无法做到完全干净的分流。例如访客清除存储、使用隐私模式、或跨设备访问，都会让持久化失效。这时污染不会归零，但可以控制。
- 如果污染比例很低且两组对称，可以接受，但要在结论里注明存在少量跨组样本。
- 如果污染只集中在一个版本，比如只有B版本会先加载再跳转，那就要单独处理这个版本的加载逻辑，而不是调整整体分流比例。
- 如果两个版本必须共用同一批访客且无法持久化，那就放弃组间对比，改用组内前后对比，并明确前后对比会混入时间因素。
判断能否接受的依据是污染是否对称。对称的低比例污染对结论方向影响有限，单侧污染则会系统性地扭曲一组的数据。在网站访问量查询里看到两组数据时，先确认污染是否对称，再决定是继续分析还是先修分流。
把识别动作固定成检查顺序
每次做版本对比前，按固定顺序检查：先确认分流是否持久化，再确认两组统计口径是否一致，最后才看数据差异。这个顺序能避免你把口径问题误判为分流问题，也能避免在污染存在时得出关于版本优劣的结论。识别样本污染不是一次性的工作，而是每次对比前都要过的前置检查。
