SEO问题诊断：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2243aef783ad.html
📄
SEO问题诊断：访客被分配到不同版本时怎样识别样本污染
当同一批入口流量被随机分到两个页面版本，而汇总数据却显示整体转化率变化时，最先要做的不是解释胜负，而是确认两个版本的样本是否真的可比。识别样本污染的核心动作是：把每个版本按来源、设备、登录状态、地域和进入路径拆开，检查各分组的构成比例是否接近；若某一版本多出了大量来自推荐位或广告的访客，那么汇总差异很可能来自样本结构，而不是页面本身。
先判断污染发生在分流前还是分流后
分流前污染指访客在进入实验前就已经带有不同特征，例如一个版本只出现在搜索结果页，另一个版本只出现在信息流推荐位。分流后污染指访客进入实验后，因跳转、缓存或二次请求被重新分配到另一版本。两者的证据不同：前者看来源构成，后者看同一访客的多次请求记录。
一个可执行的区分方法是，在分流逻辑中写入一个稳定的访客标识，并记录每次请求命中的版本。假设某访客首次命中 A 版，第二次请求却命中 B 版，且这种情况在日志中反复出现，就应优先排查重定向、CDN 缓存和客户端脚本的重复触发，而不是继续比较两版页面的转化率。
用分层核对替代总量比较
总量比较会把结构差异误读成版本差异。把数据按以下维度分层后，观察每个版本在各层内的表现是否仍然相反：
- 流量来源：自然搜索、平台推荐、广告、直接访问分别统计，不混在一起。
- 设备与浏览器：移动端和桌面端的分流比例是否一致。
- 登录状态：已登录与未登录访客的分布是否均衡。
- 进入路径：从首页进入与从活动页直接进入的比例是否接近。
- 时间分布：两个版本的流量是否集中在不同时段。
如果某个版本在自然搜索来源中的转化率更高，但在推荐来源中更低，而推荐来源又恰好大量涌入该版本，那么汇总结果就会被这一层的权重带偏。此时下一步不是宣布哪个版本更好，而是先检查分流规则是否对来源做了隐式区分。
识别那些让样本失真的技术动作
有些污染不是人为分组造成的，而是技术实现引入的。常见证据包括：
- 版本切换依赖客户端脚本，脚本加载失败时访客被默认分配到某一版本。
- 页面设置了缓存，同一 URL 在不同时间返回不同版本，导致同一访客前后看到不同内容。
- 实验工具在重定向时丢失了原始来源参数，使部分流量被归入直接访问。
- 爬虫或监控请求被计入实验样本，而它们的行为与真实访客不同。
这些情况的共同点是：样本在进入比较之前就已经被系统性改变。发现上述任一证据后，应先修复分流或记录机制，再重新收集数据；否则后续任何差异都缺少可解释的基础。
用一个小例子说明如何把异常转成处理方案
假设某页面改版实验显示 B 版转化率比 A 版低，但直觉认为 B 版更清晰。核对日志后发现，B 版有大量来自平台推荐的访客，而 A 版几乎没有。此时有两种成立条件不同的解释：
- 如果推荐来源的访客本身转化意愿更低，那么 B 版的低转化是样本结构造成的，不能归因于页面设计。
- 如果推荐来源在两个版本中的占比接近，但 B 版在该来源内仍然更低，那么页面设计或加载性能就值得进一步排查。
对应的动作是：先按来源分层重算，若差异消失，就调整分流规则，让两个版本在各来源上按相同比例分配，再重新观察；若差异仍在，就转向检查 B 版的加载时间、表单可用性和首屏内容是否与推荐访客的预期不符。这个动作的结果直接决定下一步是修分流还是修页面。
把核对结果写成可复查的记录
识别样本污染不依赖单次判断，而依赖可复查的证据链。建议在诊断记录中保留：分流规则版本、每个来源的样本量、各层转化率、异常请求的样本日志，以及你据此做出的处理决定。这样当后续数据再次出现反常时，可以快速判断是旧问题复发，还是新的样本结构变化。记录的目的不是证明某个版本一定更好，而是让每一次比较都建立在可核对的分组之上。
