搜索词分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /19ca6951e445.html
📄
搜索词分析：访客被分配到不同版本时怎样识别样本污染
先给结论：只有当分流规则、统计口径和搜索词归因三者都能按版本拆开时，版本对比才成立；只要其中一项无法拆分，样本污染就很可能已经发生。识别它的关键不是看总流量涨跌，而是检查同一搜索词是否被跨版本重复计入，以及进入某一版本的用户是否本身就更可能带有特定搜索意图。
先确认版本分流是否真的随机
很多团队默认“一半用户看A版、一半看B版”就等于随机。实际常见情况是：分流依据本身与搜索意图相关。例如按设备类型、登录状态、地域或首次访问时间分流，而这些变量又会影响用户搜什么词、点不点结果。此时两组样本在搜索意图上先天不同，后续任何搜索词分析都在比较两类人，而不是比较两个版本。
判断方法很直接：把分流变量和搜索词分布交叉看。假设按“是否登录”分流，那么登录用户可能更多搜品牌词，未登录用户更多搜泛需求词。如果A版恰好拿到更多登录用户，A版的品牌词占比就会偏高，这不是版本造成的，而是分流造成的。
- 分流变量是否出现在搜索词归因链路中；
- 两组用户的搜索词分布是否在实验开始前就已不同；
- 同一用户是否可能先后进入两个版本。
识别跨版本重复计入的痕迹
样本污染最典型的形态是同一访客在不同时间被分到不同版本，而统计系统仍按“访问”累计，于是同一个人的搜索词行为被算进两个版本。表现包括：某搜索词在A、B两版都出现，且两边的会话数之和明显高于去重访客数；或者同一设备标识在两版日志里交替出现。
这里要区分两种解释。其一确实是分流不稳定，比如缓存、跳转或客户端状态丢失导致用户重新分配；其二只是统计口径问题，比如站内统计按会话去重，而搜索平台报告按点击去重，两者本来就不等。请求量或抓取量归零也不能单独证明分流正确，它还可能来自采集延迟、过滤规则变更或日志采样。
可核查的证据链是：导出带设备标识或稳定用户标识的访问日志，按版本标记，检查同一标识是否跨版本出现；再对照搜索词报告的时间戳，看跨版本行为是否集中在某一时段。若跨版本标识占比很低，污染可能只影响小部分长尾词；若集中在高价值搜索词上，则结论必须重做。
看归因窗口是否被版本切换截断
搜索词分析通常依赖归因窗口：用户先搜索、后点击、再转化。当版本在窗口期内切换，转化可能被记到用户最后停留的版本，而不是最初触发搜索的版本。这会让两个版本都“抢”同一个搜索词的结果，形成看似双方都有效的假象。
一个注明假设的短例子：假设归因窗口为七天，用户在第一天通过搜索词“A”进入旧版，第三天被重新分配到新版并完成注册。若系统按最后触点归因，新版会拿到这次转化，旧版拿不到；若按首次触点归因，则相反。两种口径下同一搜索词的表现可以完全相反，但用户其实只经历了一次搜索意图。此时应固定一种归因口径并全程沿用，而不是在两个版本间各用一套。
分流变量与搜索意图相关时的反例
反例：如果分流完全随机，且同一用户在整个实验期内不被重新分配，那么即使总流量有波动，版本间的搜索词差异仍可解释为版本影响。此时把样本污染当成主因反而会误判。判断这一点需要确认分流稳定性和去重口径，而不是只看数字差异大小。
换句话说，样本污染不是“两组数据不一样”就成立，而是“两组数据的构成机制不同”才成立。构成机制不同，才需要先修复分流或归因，再谈搜索词层面的优化。
下一步动作：先冻结对比，再决定是否继续
如果检查发现跨版本标识占比不可忽略，或分流变量与搜索词意图明显相关，下一步不是继续扩大流量，而是先冻结版本对比，改为按稳定用户标识重算分组，并固定归因口径。重算后若差异消失，说明此前结论受污染；若差异仍在，才值得进入下一步的搜索词意图分析，比如按意图类别而非单个词比较。
这个动作的结果会直接改变后续决策：重算后差异消失，就应暂停基于该实验的优化判断，先修分流；重算后差异保留，才可以把搜索词分布差异作为版本效果的候选证据，并继续用同一口径验证。无论哪种结果，都不要用单次流量或收录变化替代这条证据链。
