搜索词分析工具，访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bf8903e3d4f8.html
📄
搜索词分析工具，访客被分配到不同版本时怎样识别样本污染
先给一个有条件的结论：只有当分流规则、日志时区和归因窗口三者都对齐后，分组对比才可能成立；否则你看到的组间差异，很可能来自样本污染，而不是版本本身。判断污染的第一步不是看转化率，而是先确认每个访客是否真的只进过一个版本。
样本污染通常不是分流失败，而是记录口径被混在一起
访客被分配到不同版本时，最容易出问题的地方是“访客身份”的定义。假设某个测试以设备ID分流，但站内统计以登录账号去重，那么同一台设备上换账号登录，就会被记成两个访客，分别落入两个版本。此时转化数据看起来是两组，实际却来自同一个人。
可区分的原因有几类：
- 身份键不一致：分流用cookie，统计用账号，跨设备或清缓存后身份断裂。
- 归因窗口过长：访客先看A版本，几天后从B版本进入并转化，转化被记到B。
- 时区错位：分流系统用UTC，报表用本地时区，跨零点实验被切成两段。
- 重定向或缓存层：CDN缓存把A版本页面返回给本该进B版本的访客。
这些原因的共性，是“分配”和“记录”发生在两个系统里，而两个系统对同一个人的判断不同。
先做一次身份对账，而不是先比较转化率
实际动作是：从分流系统导出最近一段时间的访客分配日志，字段至少包含访客标识、分配版本、分配时间；再从站内统计导出同一时段的访问与转化记录，字段包含同一访客标识、命中版本、事件时间。用访客标识做左连接，而不是用汇总数字做对比。
对账后重点看三类记录：
- 一个访客命中多个版本：说明分流没有锁定，或身份键在过程中变了。
- 分流日志里有、站内记录里没有：可能是埋点未触发、页面未加载，或访客在记录前就离开了。
- 站内记录里有、分流日志里没有：可能是直接访问落地页、爬虫流量，或旧缓存页面仍在生效。
如果第二类和第三类同时很多，先别急着判定实验失败，它更可能说明两个系统的采样范围不同。这个动作的结果会直接决定下一步：若多版本命中比例高，先修分流锁定；若单边缺失集中，先修埋点或缓存，而不是调整版本内容。
一个反例：把“请求量归零”当成污染已清除
假设你修好分流后，某个版本的请求日志突然归零。这不能单独证明污染已经消失。合理解释至少有三种：该版本被错误下线；缓存层开始直接返回另一版本；或者日志采集本身中断。三种情况的后续动作完全不同，而表面现象一样。
因此，识别污染不能只看某一项指标是否归零，而要看证据链是否闭合：分流日志、站内访问、转化事件三者的访客标识能否一一对应，且时间顺序符合预期。缺少其中任何一环，结论都应视为待验证。
用短窗口加对照，确认污染是否影响结论
在身份对账通过后，再做一个短窗口对照：选一段没有版本变更、没有大促、没有投放变化的时间，分别统计各版本的访客数、转化事件数和跨版本命中数。这里不追求大样本，而是看跨版本命中是否接近零。
假设某个访客在周一进入A版本，周三从B版本链接进入并完成转化。如果归因窗口设为7天，这次转化会被算给B。缩短归因窗口或按首次命中归因后，同一批数据可能给出不同结论。数字只用于说明比较方法，不代表真实收益。
下一步动作取决于对照结果：跨版本命中接近零，才适合继续比较版本效果；若仍偏高，应先统一身份键和归因规则，再重新取样。第三方估算流量、搜索引擎报告与站内统计口径本就不同，不能互相替代来证明分流是否干净。
把结论落到一个可复查的条件上
最终判断标准可以写成一句话：同一访客标识在实验期内只应出现一个版本，且转化事件的时间晚于分配时间。满足这个条件，样本污染才不构成主要威胁；不满足时，任何组间差异都只能当作待解释现象。先修记录口径，再谈版本优劣，这一步顺序不能颠倒。
