网站诊断：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /64c017f64464.html
📄
网站诊断：访客被分配到不同版本时怎样识别样本污染
识别样本污染的关键不是看总流量涨跌，而是先确认同一批访客是否被稳定分到同一版本。若分流规则按会话、入口来源或设备随机切换，A/B两组的差异会混入版本体验差异，此时任何转化对比都不可信。正确动作是固定分流维度并回放原始日志，直到每组内版本一致率接近100%。
先判断污染来自分流机制还是数据口径
两种条件对应两种选择。条件一：分流由前端脚本或CDN边缘规则决定，同一访客可能因缓存、重定向或参数丢失而落到另一版本。此时优先查分流层，而不是分析层。条件二：分流本身稳定，但统计工具把两个版本的数据写进同一事件表，或把未参与实验的访客计入对照组。此时优先查数据管道。
区分依据是证据链，而非单一指标。可核查的证据包括：原始访问日志中同一设备ID或登录ID出现的版本标识序列、分流服务返回的分配记录、以及统计后台中事件携带的版本字段。如果日志显示同一ID在多次访问中版本标识交替出现，属于机制污染；如果日志中版本标识稳定，但报表里两组样本量之和大于实际实验暴露量，属于口径污染。
用固定分流维度回放，而不是重跑一次实验
很多团队在发现异常后直接重跑实验，但若分流维度未固定，重跑只会得到另一组被污染的数据。可执行的动作是：选定一个稳定标识（登录ID优先，未登录场景用设备ID加首次落地参数），在分流服务中把该标识作为唯一哈希输入，关闭按会话、按来源、按随机数的二次分配。
动作结果会直接影响下一步：若固定后同一标识的版本一致率明显上升，说明此前污染来自分流层，接下来应检查缓存与重定向是否在标识写入前发生；若一致率仍低，说明标识本身在跨端或跨浏览器时发生变化，需要改用服务端下发的持久标识，并重新评估样本是否还能按用户维度聚合。
样本污染的例外：跨设备与主动清缓存
固定标识并不能消除所有污染。同一用户在手机与桌面分别访问、或主动清除Cookie后重新进入，可能被合法地分到不同版本。这类情况不属于机制错误，但会稀释组间差异。处理方式是：在分析时把跨设备用户单独标记，或只保留首次分配版本作为该用户的归属版本。
另一个例外是搜索引擎爬虫与预览抓取。它们通常不携带稳定标识，若被计入实验样本，会同时污染两组。可在分流前按已知爬虫特征或行为模式过滤，并在诊断记录中注明过滤规则，避免后续把过滤后的样本量变化误读为实验效果。
假设例子：一致率与样本量的交叉验证
假设某站点分流后，A版本报表样本量为1200，B版本为800。若分流规则本应接近均分，这个差距提示污染。此时不要直接补量，而是从日志中抽取100个稳定标识，统计每个标识的版本序列。若其中30个标识出现版本交替，则一致率为70%，说明机制污染严重，应先修分流。若100个标识版本全部稳定，但两组样本量仍差400，则更可能是统计口径把未暴露访客计入了某一组，应检查事件触发条件与版本字段的写入时机。
这个例子的数字仅用于说明比较方法，不代表真实项目结果。核心是：一致率低指向分流层，一致率高但样本量异常指向数据层。两条路径的修复动作不同，先做哪一步取决于你手头能否拿到原始标识序列。拿不到序列时，先补日志字段，而不是先调报表。
把污染识别写进诊断记录
完成上述检查后，应在诊断记录中留下三项内容：分流维度与标识定义、版本一致率的计算方式、以及被排除的样本类型及原因。这样下一次网站诊断时，可以直接对比一致率是否变化，而不是重新争论两组差异是否可信。若一致率无法达到稳定水平，应暂停基于该实验的转化结论，改为先修复分流或统计管道。
