目标群体分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e5f0cd955951.html
📄
目标群体分析：访客被分配到不同版本时怎样识别样本污染
先给结论：只有当分流规则、曝光时机和指标口径三者都能按访客逐一还原时，版本对比才算干净；只要其中一项无法还原，样本污染就已经存在，此时任何版本间的差异都不该直接归因于版本本身。识别污染的关键动作不是加数据，而是先锁定“谁在什么条件下看到了哪个版本”，再检查这条链路有没有被外部因素打断。
先确认分流是否真的随机：三个可核查的证据
常规做法是看两个版本的总量是否接近，但总量接近并不等于分配随机。真正能区分的原因通常藏在三处证据里。
- 分配时点：访客是在首次进入时被固定分组，还是每次请求重新随机？前者会产生“同一人反复进入同一版本”，后者会产生“同一人在会话内跨版本”。两种机制下的污染形态完全不同。
- 分组标识的存活范围：标识存在 Cookie、本地存储还是仅存在当前会话？如果标识在跳转或跨子域时丢失，访客会被重新分配，样本里就混入了同一人的两段行为。
- 进入路径：自然进入、站内跳转、外部广告落地是否走同一套分流？如果只有一个入口做了分流，其余入口的访客会全部落进默认版本，这不是随机差异，而是覆盖缺口。
把这三项对齐后，你会得到一张“访客—版本—进入条件”的对照表。能画出这张表，才谈得上判断污染；画不出，说明记录链路本身缺失，先补记录再谈结论。
一个会让结论失效的反例：分流正确但曝光被截断
假设分流规则完全随机，分组标识也稳定存活，但某个版本的首屏加载依赖一个较慢的资源。结果是：被分到慢版本的访客中，有一部分在内容渲染前就离开，行为数据里只留下“进入即跳出”的记录；快版本则留下了完整的浏览路径。
这时你会看到慢版本的跳出率明显更高，很容易读成“版本体验差”。但真正的差异可能来自曝光时机，而不是版本内容。这个反例说明：分流随机只保证分配公平，不保证曝光公平。只要版本间的加载或渲染条件不同，行为指标就同时承载了版本效应和曝光效应，两者无法靠总量对比拆开。
要区分这两种解释，需要看同一版本内“完整曝光”和“未完整曝光”访客的指标是否分裂。如果慢版本内部这两组人的表现差距很大，而快版本内部差距很小，那么差异更可能来自曝光截断，而不是版本设计。
指标口径不一致会伪装成样本污染
站内统计、第三方估算和平台报告对“一次访问”的切分方式不同。站内可能按会话切分，第三方可能按设备或估算模型切分，平台推荐则可能按曝光事件切分。当两个版本的流量来源结构不同，同一指标在不同口径下的数值会自然拉开，看起来像样本被污染，实际只是口径差异。
判断方法很直接：把两个版本按来源渠道拆开，分别用同一口径重算。如果差异在拆分后消失，问题出在来源结构而非分流；如果差异在拆分后依然存在，才回到分流和曝光链路继续查。这里不需要引入更多指标，只需要固定口径后做一次分层对照。
下一步动作：先冻结对比，再补一条可追溯记录
在污染未被排除前，不要基于当前数据调整版本或扩大流量。具体动作是：暂停对版本差异的解读，先为每个访客补一条可追溯记录，至少包含分组标识、进入路径、曝光是否完整、指标口径来源四项。
这条记录的作用不是立刻给出答案，而是让下一次对比有可还原的链路。如果补完记录后发现分组标识在某个入口丢失，那么修复入口分流就是下一步；如果发现曝光条件在两个版本间不同，那么统一曝光时机才是下一步。动作的结果决定了后续该修分流、修曝光还是修口径——在没有这条记录之前，任何调整都只是在猜测上叠加改动。
需要说明的是，请求量或抓取量突然归零、某项统计明显偏低，都不能单独证明分流处理正确，它们也可能是采集延迟、日志截断或口径切换造成的。把现象和原因分开记录，才能避免把一次口径变动误读成样本污染。
