流量来源分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e8acb415485.html
📄
流量来源分析：访客被分配到不同版本时怎样识别样本污染
先给一个可执行的判断：当你按来源渠道对比两个版本时，如果同一访客在一次会话内被分到不同版本，或统计口径把同一人的多次访问拆进两个组，样本污染就已经发生。识别方法是把“分桶依据”和“来源归因依据”放在同一条记录上核对，而不是只看汇总报表的组间差异。只要这两个依据的粒度不一致，后续任何按来源的对比都不可信。
先把两个分配动作分开记录
访客进入你的页面时，通常发生两个独立动作：一是被分到某个版本（分桶），二是被标记一个来源渠道（归因）。很多站内实验工具默认按浏览器标识或登录账号分桶，而来源分析可能按会话、按首次点击或按最后一次点击归因。这两套标识的生命周期不同，正是污染的常见来源。
具体动作：在你手上的那份原始日志或事件表中，为每条记录补两列——bucket_id（该访客被分到哪个版本）和source_key（该次访问被判为哪个来源）。不要用汇总后的版本维度表，必须回到最细粒度的事件行。
结果如何影响下一步：如果同一bucket_id对应多个source_key，说明分桶发生在归因之前且未锁定；如果同一source_key下的bucket_id频繁跳变，说明分桶不稳定。前者需要固定分桶键，后者需要检查分桶是否被缓存或跨设备重置。两者处理方向完全不同，所以必须先分类再动手。
用三种证据区分“真差异”与“样本污染”
组间差异大不等于实验有效，也不等于污染。需要一组可区分的证据来排除合理解释。
- 时间证据：如果两个版本的来源构成在改动前后同时发生跳变，可能是渠道投放或季节性变化，而非分桶问题。查看同一来源在未参与实验的页面上的走势，作为对照。
- 标识证据：检查是否存在同一设备标识在短时间内出现在两个版本中。若有，且来源不同，污染成立；若来源相同，则更可能是分桶抖动，影响的是版本对比而非来源对比。
- 口径证据：站内统计、搜索引擎报告和第三方估算对流量的定义不同。站内可能按会话计数，搜索引擎报告可能按点击计数，第三方估算可能是模型推算。三者数量对不上是常态，不能单独用其中任何一个证明污染存在或不存在。
这里要注意一个反常现象：某个来源的访问量突然归零，并不一定说明该来源被错误分配。它也可能是标签未触发、过滤规则误伤、归因窗口到期，或该渠道本身停止投放。把这些解释逐一排除后，再判断是否与分桶有关。
一个假设例子：按会话分桶但按用户归因
假设你的实验工具按会话随机分桶，而来源分析按用户首次访问来源归因。一个用户第一次从搜索进入被分到A版本，第二次从广告进入被分到B版本。在按来源对比时，这个用户会被同时计入“搜索-A”和“广告-B”，两个来源的版本对比都被污染。
验证动作：抽取这类跨会话用户，统计他们在两个版本中的分布比例。如果比例明显偏离随机预期，说明分桶键与归因键不匹配。修正方式是把分桶键改为与归因键一致的标识（例如统一用用户ID或统一用首次来源标识），并在分桶时写入一条不可变的分桶记录。
结果如何影响下一步：修正后，原本被拆散的用户会完整落入一个版本，来源对比的样本才具备可比性。如果修正后差异消失，说明之前的差异来自污染；如果差异仍在，才值得继续排查版本本身的影响。
处理顺序：先冻结分桶，再谈来源对比
已经尝试过常规做法仍未解决时，遗漏条件往往不是分析方法，而是分桶与归因的执行顺序。建议按以下顺序处理：
- 确认分桶键是否在访客首次进入时写入且不再改变。若会随会话或设备变化，先固定它。
- 确认来源归因键是否与分桶键使用同一标识。若不同，明确记录两者对应关系，不要强行合并。
- 在事件表中保留原始分桶记录和原始来源记录，不要只保留汇总结果。
- 重新计算时，先按分桶键去重到用户级，再按来源聚合。这样能避免同一用户被重复计入多个版本。
完成这四步后，你手上应该有一份可核查的证据链：每条记录都能说明谁被分到哪个版本、依据什么来源归因、这个判断在什么时间点成立。只有在这条链完整时，流量来源分析中的版本对比才值得继续解读。
