网站性能检测：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7a91e143497b.html
📄
网站性能检测：访客被分配到不同版本时怎样识别样本污染
先看一个矛盾现象：新旧版本并行期间，整体指标没有明显恶化，但分版本看，新版本表现明显更好，旧版本却比切换前更差。这通常不是新版本真的更优，而是样本被污染了——同一类访客被系统性地分到了不同版本，两个版本的用户构成不再可比。识别污染的关键，不是看总量，而是检查分流是否随机，以及污染是否与某个可观测维度相关。
先区分两种解释：真实差异还是分配偏差
当新旧版本指标出现差距时，有两种成立条件不同的解释。
解释一：版本本身造成差异。成立条件是分流近似随机，两组访客在来源、设备、地域、登录状态等维度上的分布基本一致。此时差距可以归因于版本差异。
解释二：分配机制造成差异。成立条件是分流并非随机，例如按缓存命中、按入口路径、按登录状态或按灰度名单分配。此时两组访客从一开始就不是同一类人，指标差距反映的是人群差异，而不是版本效果。
这两种解释在总量指标上可能表现相同，必须靠分组维度的分布对比来区分。
能区分两种解释的证据：分组分布对照
最直接的动作是：不要只看两组的汇总指标，而是把每个关键维度单独拆开，逐项对比两组占比。可检查的维度包括：
- 流量来源（自然搜索、直接访问、外链、广告）
- 设备类型与浏览器
- 新访客与回访客比例
- 登录状态与用户分层
- 入口页面与落地路径
- 地域与网络环境
如果某个维度在两组间占比差异明显，而这个维度本身又影响目标指标，那么样本污染基本可以确认。反过来，如果所有关键维度的分布都接近，版本差异的解释才站得住。
这一步的结果直接决定下一步：分布接近，可以继续比较版本效果；分布明显偏移，应先修正分流逻辑，再重新采集数据，否则后续任何对比都不可信。
按分配机制排查：污染通常来自哪里
分流不随机往往有具体来源，可以按机制逐项排查：
- 缓存与CDN分配。不同节点缓存了不同版本，访客实际看到哪个版本取决于命中的节点，而不是随机数。此时版本与网络环境、地域强相关。
- 入口路径分配。例如旧版只保留给某个旧入口，新版只从新入口进入，两组访客的来源结构天然不同。
- 登录状态或名单分配。灰度名单、内部账号、老用户优先等规则，会让两组在用户成熟度上产生系统差异。
- 跳转与重定向残留。旧链接仍指向旧版，新链接指向新版，导致版本与内容来源绑定。
每一种机制都对应一个可验证的假设。例如怀疑缓存导致污染，就对比不同节点的版本命中情况；怀疑入口导致污染，就对比两组的入口页面分布。
一个假设例子：如何用分布对照定位污染
假设某站点把旧版保留给回访客，新版开放给新访客，目的是观察新用户反应。此时若直接比较两版转化率，结论必然失真，因为新访客与回访客的行为基线本就不同。
可核查的证据链是：先按访客类型分组，分别在新版和旧版内部比较同类访客的转化，再对比两组的新访客占比。如果新版的新访客占比远高于旧版，说明版本与访客类型绑定，整体对比无效；只有在同类访客内部比较，才接近真实版本差异。这个例子的数字不必真实，重点是验证方法：先固定人群，再比较版本。
修正后的判断顺序
识别样本污染不是一次性动作，而是一个顺序：先确认分流是否随机，再确认两组人群是否可比，最后才比较版本效果。若中途发现污染，应记录污染维度、修正分配逻辑，并重新采集一段干净数据，而不是在污染数据上做加权修补。加权只能缓解已知偏差，无法处理未观测到的分配规则。
把分布对照作为常规检查项，能让版本对比从“看起来有差异”变成“差异可以归因”，这也是退出旧版本、保留有效部分时最需要的判断依据。
