cpv：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /efbb1ccb827e.html
📄
cpv：访客被分配到不同版本时怎样识别样本污染
先看分配记录，而不是先看结果。cpv 场景下的样本污染，指的是本应只进入 A 版或只进入 B 版的访客，因为分流条件、跳转或缓存等原因，实际接触了另一个版本，导致两组数据不再代表各自的处理。识别它的关键动作是：在分析结果之前，先按访客维度核对“被分到哪组”和“实际看到哪版”是否一致；一致率明显偏离预期时，先修分流再谈结论，否则保留、改写或退出都建立在错误的比较上。
先区分三种看起来像污染的现象
结果反常不一定都是样本污染。至少有三类原因会产生相似表象，需要用不同证据区分。
- 分配不一致：访客被记录进 A 组，但页面实际渲染了 B 版。证据是分流日志与页面版本标识对不上。
- 重复进入：同一访客多次访问，前后落入不同组。证据是同一访客标识出现两条组别记录。
- 口径差异：站内统计与第三方估算对“访客”的定义不同，看起来像两组混在一起。证据是同一时间段的访客数、会话数在两个口径下差异方向一致且可解释。
只有第一类和第二类属于样本污染。第三类属于统计口径问题，处理方式完全不同：前者要修分流逻辑，后者要统一口径或明确以哪套数据为准。把三类混为一谈，最容易做出错误的保留或退出决定。
用一条可核对的证据链定位污染
不要只看汇总指标，要下沉到访客维度。假设某次对比中，A 版转化率明显低于 B 版，与改动前的预期相反。可以按下面的顺序核对：
- 取分流日志，确认每位访客被分配的组别，以及分配时间。
- 取页面侧记录，确认同一位访客实际渲染的版本标识。
- 把两份记录按访客标识对齐，统计“分配组别 = 实际版本”的比例。
- 对不一致的访客，检查其路径：是否经过跳转、是否命中缓存、是否在分配后重新进入。
如果一致率接近预期，污染的可能性低，应转向口径差异或真实效果差异。如果一致率明显偏低，且不一致集中在某类入口或某个时间段，那么污染是更合理的解释，下一步应修分流而不是继续扩大样本。
这里要提醒一点：某个指标归零或骤降，不能单独证明分流出了问题。缓存过期、埋点上线延迟、入口流量结构变化，都会造成类似现象。需要至少两条独立证据指向同一原因，才值得动手改分流。
保留、改写还是退出：三种取舍的适用前提
确认污染后，处理方式取决于污染的范围和方向，而不是取决于结果好不好看。
保留适用于污染比例很低、且不一致访客在两组间近似随机分布的情况。此时两组仍可比较，但要在结论中注明这一限制，并把一致率作为后续监控项。前提是你能持续拿到分配与实际版本的对照记录。
改写适用于污染集中在特定入口或特定设备的情况。比如只有从某个跳转链接进入的访客会看到错误版本，那么修好这条路径、重新分配这批访客，比推翻整个对比更合适。改写的前提是污染原因可定位、可修复，且修复后能重新建立干净的对照。
退出适用于污染方向与处理效果同向的情况。如果进入 B 版的访客本就更容易转化，而污染又把这类访客部分算进了 A 版，那么两组的差异已经被污染方向扭曲，继续分析只会放大误判。此时应停止基于这批数据的结论，重新设计分配与校验环节后再开始。
三种取舍不要求全部用上。多数情况下，先判断污染是否随机、是否集中，就能排除掉其中一两个选项。
把校验做进分配环节，而不是事后补救
事后识别成本高，是因为分配记录和页面记录往往不在同一处。更实际的做法是在分配环节就留下可核对的痕迹：给每位访客记录组别、分配时间和一个版本标识，页面渲染时把同一标识写回日志。这样一致率可以随时计算，污染一旦出现就能定位到具体入口或时间段。
需要接受的代价是：这会增加一点埋点和存储成本，也可能让分流逻辑变复杂。如果对比规模很小、结论只用于内部参考，可以不做完整校验，但要在结论里明确“未校验分配一致性”这一前提。反之，如果结论要影响投放或产品决策，校验就是必要成本，不能省。
无论选哪种，都要记住：一致率、抓取量或某个指标的异常，只是线索，不是结论。先确认污染是否存在、范围多大、方向如何，再决定保留、改写还是退出，这一步的顺序不能颠倒。
