A5网站诊断，访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /de85f72a366b.html
📄
A5网站诊断，访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键，不是先看总转化率差了多少，而是先确认同一访客在同一分析周期内是否只进入了一个版本。若分流标识、落地页或缓存把同一访客反复分配到 A、B 两组，后续按访客汇总的数据就混入了重复计数和跨组行为，此时继续比较版本差异没有意义。更稳妥的动作是：先按访客 ID 与首次进入版本做一次交叉核对，若同一 ID 命中两个版本的比例明显异常，应暂停结论、修复分流后再重跑，而不是保留数据硬做解释。
先区分三种看起来像样本污染的情况
访客被分到不同版本，未必都是分流代码出错。需要把三种原因分开：
- 同一访客重复进入：用户清缓存、换设备或从收藏夹再次访问，被重新随机分配。表现为同一用户 ID 或同一登录账号下出现多个版本记录。
- 分流标识未贯穿：入口页分配了版本，但跳转到下一层页面时参数丢失，日志里同一会话出现两个版本。
- 归因口径不同：站内统计按会话计，第三方按用户计，两者对“同一访客”的定义不一致，看起来像跨组，实际是口径差异。
只有第一种和第二种属于真正的样本污染，第三种需要先统一口径再判断。把三者混在一起，容易把口径问题误判成代码故障。
用可核对的证据链确认是否真的跨组
不要只依赖一个汇总比例。可以按下面的顺序取证据：
- 导出同一时间窗内每个访客 ID 对应的版本列表，统计命中两个及以上版本的 ID 数量与占比。
- 对照分流层日志，确认分配发生在哪一层、标识写入了什么位置（Cookie、localStorage 或服务端会话）。
- 抽查若干跨组 ID 的完整路径，看是首次分配就冲突，还是中途参数丢失后重新分配。
- 若使用第三方估算流量，把它与站内按访客统计的版本分布并排看，但不要用两者差值直接推断污染规模，口径不同会放大或缩小差异。
如果跨组 ID 占比接近随机重分的理论水平，通常说明标识没有稳定留存；如果跨组集中在某几个入口或某类设备，更可能是跳转丢参或缓存策略问题。这两种证据指向的修复动作不同。
保留、改写还是退出：三种取舍的适用前提
保留适用于跨组比例很低、且跨组行为集中在极少数边缘路径的情况。前提是你能在分析时按首次分配版本重新归集，并接受这部分噪声。若无法按首次分配归集，保留就只是把污染藏进平均值。
改写适用于分流逻辑本身可修、且仍有足够时间窗重跑的情况。改写包括把版本标识写入更稳定的位置、在跳转链路中显式透传、对已分配访客不再二次随机。改写后需要重新验证跨组比例，确认降到可接受范围再开始积累数据。
退出适用于污染已经贯穿大部分样本、且修复成本高于重新设计实验的情况。此时继续分析只会产出无法解释的结论，不如终止本轮、明确退出条件后重新设计分流与记录方式。
三种取舍没有默认优先级。判断依据是：污染是否可归集、修复后是否还有足够样本、以及当前结论是否已经影响到下一步决策。
一个假设例子：先修分流，再决定是否重跑
假设某次版本测试中，站内统计显示两个版本的访客数接近，但按访客 ID 交叉核对后发现约两成 ID 同时出现在两个版本里，且这些 ID 多来自同一类跳转入口。此时合理的下一步不是比较转化率，而是先修该入口的参数透传，再观察跨组比例是否下降。若修复后跨组比例回到很低水平，可以保留旧数据中未跨组的部分并重跑；若修复后仍大量跨组，说明标识存储本身不稳定，应退出本轮、重新设计分配与记录方式。这个例子的数字仅用于说明比较方法，不代表任何真实项目结果。
把识别动作固定成可复查的记录
为了下次能快速判断，建议在诊断记录中固定三项：分流发生的层级与标识位置、按访客 ID 统计的跨组比例、以及跨组 ID 的路径分布。这样当结果与直觉相反时，你能先回答“是样本被污染，还是口径不同”，再决定保留、改写还是退出。缺少这三项记录时，任何版本对比都只是未经核对的汇总数字，不足以支撑下一步动作。
