网站流量：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c566ec9f3f97.html
📄
网站流量：访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键，不是先看总流量涨跌，而是先确认同一分析口径下，各版本是否被稳定、可复现地划分到不同组。若分组依据来自客户端跳转、缓存、登录状态或地域规则，而分析工具只按页面路径统计，那么“版本差异”很可能只是访客构成差异造成的假象。此时应优先保留原始分组证据，再决定是继续比较、改写分组逻辑，还是暂停该实验。
先判断污染来自分配，还是来自统计口径
访客被分配到不同版本时，常见污染源有三类：分配不独立、统计不完整、访客跨组。分配不独立指同一访客因刷新、回退或二次进入被重新随机；统计不完整指部分版本未被分析脚本覆盖，或跳转后丢失来源参数；访客跨组则出现在登录后、切换设备或清缓存后重新命中另一版本。它们都会让两组样本的构成不同，而不是版本本身造成差异。
要区分原因，可以固定一个短观察窗，只记录能稳定复现的访客标识与版本标识。如果同一标识在多次访问中频繁切换版本，优先怀疑分配层；如果版本标识稳定但分析报表中的来源、设备或新老访客占比明显偏移，优先怀疑统计层。这个动作的结果会直接决定下一步：分配层问题应暂停实验，统计层问题则可先修正口径再继续观察。
保留、改写还是退出：三种取舍的适用前提
保留适用于分组逻辑可被独立验证，且污染比例低到不影响方向判断。这里的“低”不是拍脑袋，而是用可核查证据说明：例如抽样检查若干访客标识，确认版本切换只发生在清缓存等预期场景。保留不等于忽略污染，而是把污染当作已知噪声，在结论中限定适用范围。
改写适用于分配机制本身可控，但当前实现引入了额外变量。比如原本依赖客户端跳转，改为服务端按稳定标识分流，能减少刷新重分组。改写的代价是历史数据前后不可直接合并，需要重新开始观察窗。执行改写后，下一步应核对新分组是否仍然出现跨组，而不是立刻比较版本效果。
退出适用于污染与版本差异无法分离，或继续观察会持续影响真实访客体验。退出的判断依据不是“数据不好看”，而是证据链显示分组不可信。退出后应保留原始日志与分组记录，供后续复盘，而不是删除痕迹。
用可核查证据链代替单一指标结论
第三方估算流量、搜索引擎报告与站内统计口径不同，三者对同一时段的计数可能不一致，这种不一致本身不能证明样本污染存在，也不能证明不存在。更可靠的证据链是：先确认分析工具中版本标识的写入位置，再抽查访客标识的版本归属，最后核对同一访客在来源、设备、登录状态上的分布是否在两组间明显不同。
假设一个场景：某页面用客户端脚本随机跳转到A、B两个版本，分析工具按落地页路径统计。若发现B版本的直接访问占比异常高，而A版本的自然搜索占比异常高，这可能是跳转丢失来源参数，而非版本效果差异。此时应检查跳转是否保留原始来源参数。若未保留，改写跳转逻辑比继续比较更有意义；若已保留，则需进一步确认是否存在缓存导致旧版本被复用。
规模化后出现例外时，先限定结论边界
个别样本成立、规模化后出现例外，通常说明初始观察窗的访客构成过于单一。例如小流量时段访客多来自同一地区或同一设备类型，分组看似干净；流量上升后，新访客、跨设备访客和登录访客比例增加，污染才暴露。此时不应直接把小样本结论推广到全量，而应说明结论仅适用于与初始观察窗访客构成相近的条件。
要判断是否值得扩大观察，可以按来源、设备、登录状态分别查看版本分布。若某一维度下两组差异明显，而其他维度接近，说明污染可能集中在特定入口。下一步应针对该入口单独检查分配与统计逻辑，而不是全站暂停实验。若多个维度同时偏移，则优先退出并重做分组设计。
把判断写成可复现的记录
无论最终选择保留、改写还是退出，都应记录三项内容：分组依据、观察窗起止、以及判定污染所用的证据。记录的目的是让下一次遇到类似异常时，能快速判断是同一原因还是新原因。没有这份记录，后续很容易把统计口径变化误认为版本效果变化。
最后需要明确：访客被分配到不同版本时，样本污染无法仅靠总流量、转化率或某个第三方估算值来排除。只有当分组逻辑可验证、统计口径一致、且结论边界被写清时，版本比较才具备继续讨论的基础。
