营销案例分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dbbecd1ccdef.html
📄
营销案例分析：访客被分配到不同版本时怎样识别样本污染
先给有条件的结论：当分流实验出现反直觉结果时，样本污染最可靠的识别方式，是找到“进入分析的数据行里混进了不属于该版本的访客”这一可核对证据，而不是先怀疑指标口径。如果分流标识在会话中途被改写、或分析口径按事后行为回填版本，那么原先看似成立的结论就会失效——这是最常见的反例。下一步动作不是重跑实验，而是先对分流日志与分析表做一次逐行对齐。
先分清“分流错误”和“样本污染”是两件事
分流错误指访客被分到了非预期的版本，但每个访客仍只属于一个版本；样本污染指同一个访客的多次行为被拆进两个版本，或分析时把不属于该版本的记录算进来。前者影响的是组间可比性，后者直接让版本标签失去意义。判断顺序应是：先确认每个访客是否只有一个版本标签，再确认这个标签是否在行为发生前就已确定。
一个可操作的动作是：从分流服务导出“访客标识—版本—分配时间”的映射，再从分析表导出“访客标识—版本—事件时间”，按访客标识做连接。如果出现同一访客对应两个版本，或事件时间早于分配时间，就说明存在污染，而不是单纯的随机波动。
用三条证据链定位污染来源
反直觉结果本身不能证明污染，需要能相互印证的具体证据。可以按下面三条链分别核对，任何一条断裂都足以让结论暂时不可用。
- 分配链：分流标识是否在会话中被客户端脚本、缓存或重定向改写。核对方式是抽样若干访客，看其首次分配与后续请求携带的版本是否一致。
- 记录链：分析表里的版本字段是“分配时写入”还是“分析时回填”。回填字段容易把转化后的行为错误归到另一版本。
- 时间链：事件时间与分配时间的先后关系。若大量事件时间早于分配时间，通常意味着标识复用了旧值或拼接了历史数据。
假设一个示例：某次实验的B版本转化率反而低于A版本。检查分配链后发现，部分访客在切换网络后重新请求页面，分流脚本因标识丢失而重新分配，于是同一人的前半段行为留在A、后半段留在B。此时“B更差”并不是版本差异，而是样本被拆开的结果。这个例子只是说明核对方法，不代表任何真实项目数据。
哪些现象会让人误判为污染
反过来也要警惕把正常现象当成污染。以下情况单独出现时，不能直接下结论：
- 某版本访客数明显偏少——可能只是分流比例设置或流量时段分布，需结合分配日志判断。
- 某版本转化事件突然归零——可能是埋点未触发、上报失败或过滤条件过严，未必是样本被污染。
- 两版本指标接近——可能说明差异确实小，而不是污染抵消了效果。
因此，请求量、抓取量或某项统计归零，不能单独证明处理正确或错误；它还有埋点故障、上报延迟、过滤规则变化等合理解释。要区分这些解释，需要回到分配时间与事件时间的对齐结果，而不是只看总量。
确认污染后，下一步先修口径再谈重跑
如果对齐后发现确实存在同一访客跨版本，优先动作是修正分析口径：按访客首次分配时间锁定其唯一版本，剔除分配前产生的事件，再重新计算。只有当修正后仍有足够样本、且分流标识在行为前已稳定写入，重跑实验才有意义。否则重跑只会重复同一类污染。
具体判断标准可以设为：若同一访客跨版本的比例高到足以改变组间对比方向，就先修口径；若比例很低且集中在边缘时段，可先记录并继续观察，但仍需在结论中标注这一不确定性。这样处理的好处是，下一步无论是继续分析还是重新分流，都建立在可核对的证据上，而不是对反直觉结果的猜测。
