网站统计：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /83cde75d098c.html
📄
网站统计：访客被分配到不同版本时怎样识别样本污染
样本污染不是指某个版本的数据变差，而是指进入对比的访客本身在分组前就存在系统性差异，导致版本差异无法归因于版本本身。识别它的关键动作是：在分析结果前，先按分流机制、进入时点和访客来源重建分组过程，看两组在实验变量之外是否已经不同。若分流由稳定的随机机制完成，重点查进入时点与重复计数；若分流依赖跳转、地域或客户端条件，重点查条件本身是否与版本效果相关。两种前提对应不同的排查顺序和不同的处置决策。
先判断分流机制是否与访客特征相关
随机分流与条件分流是两种不同前提。随机分流下，两组访客的总体构成应当接近，样本污染更可能来自实现层面的偏差，例如同一访客被重复计入、分流脚本加载失败后回退到默认版本、或统计口径把未进入实验的访客也计入某一组。条件分流下，分组依据本身就可能携带差异，例如按地域、登录状态或客户端版本分配，这些条件往往同时影响转化行为。
区分方法不是看结果差异大小，而是看分组变量与访客属性是否独立。可以抽取分流日志，检查同一访客标识在同一时段是否只出现一个版本；再按来源、设备、新老访客交叉统计两组的构成比例。如果某组在新访客占比、来源结构或进入时段上明显偏离，就应先怀疑分组机制，而不是急着解读版本效果。
这里有一个可操作的判断：若关闭版本对比、只观察分流本身，两组的访客构成仍然不同，则污染发生在分组阶段；若只有纳入统计后才出现差异，则问题更可能在统计口径或进入时点。
检查进入时点与统计窗口是否对齐
访客被分配到版本的时刻，和访客被统计进指标的时刻，往往不是同一时刻。常见偏差包括：分流在页面加载后才执行，首屏行为已经记入旧版本；访客在实验中途被重新分配；统计窗口把实验开始前的历史行为一并计入。这些都会让两组包含不同阶段的行为。
排查时按访客标识对齐三段时间：分流生效时间、首次进入时间、指标归属时间。若大量访客的指标归属时间早于分流生效时间，说明统计窗口没有与分流对齐。处置动作是给指标加上以分流生效为起点的观察窗口，或把分流前行为单独标记。这个动作会直接改变样本集合，因此下一步应重新核对两组人数是否仍满足分析所需的最小规模，而不是沿用旧结果继续比较。
用来源结构交叉验证污染方向
样本污染常表现为来源结构失衡。搜索引擎自然流量、平台推荐流量和广告流量在进入路径、跳转链路和客户端环境上不同，若某一版本更容易在特定来源下被触发或加载成功，两组来源构成就会分化。此时即使总体指标有差异，也不能直接归因于版本。
可核查的证据链是：先按来源分层，分别比较两组在同一来源内的表现；若层内差异消失、总体差异仍在，说明差异主要由来源构成造成；若层内仍有差异，再继续检查设备和进入时点。假设某次对比中，A 组自然搜索占比明显高于 B 组，而自然搜索访客本身转化率更高，那么总体差异可能只是来源结构差异。这个例子用于说明比较方法，不代表任何真实项目结果。
需要说明的是，来源结构变化还有别的解释：投放节奏调整、页面被不同渠道引用、统计口径变更都可能造成类似现象。因此来源失衡只能作为污染线索，不能单独作为结论。
两种前提下的不同决策
当分流为稳定随机且实现无重复计数时，样本污染通常是个别技术问题。处置顺序是修复分流实现、剔除受影响的访客记录、重跑对比。此时可以保留原有实验设计，只需重新确认样本量是否仍然够用。
当分流依赖访客条件时，污染可能与条件本身共存，无法通过简单剔除解决。此时应改为在同一条件层内比较，或把条件作为分层变量纳入分析。若条件与版本效果存在交互，则不应给出单一的总体结论，而应分别报告各层结果。
例外情况是：若条件层内样本过少，分层后不足以支撑决策，正确动作是暂停结论并延长观察或调整分流方式，而不是把分层结果合并成一个看起来稳定的数字。
把识别动作固化为可复查的记录
为避免下次重复排查，可在每次对比前记录三项内容：分流机制类型、分流生效与统计归属的时间关系、两组在来源与设备上的构成。记录的目的不是增加流程，而是让“样本是否可比”成为可复查的证据。若某项统计归零或骤降，先检查分流与统计链路是否中断，再判断业务变化，因为归零本身不能单独证明处理正确，链路故障、埋点缺失和口径调整都是合理解释。
最终判断标准是：两组在实验变量之外是否可比。可比则继续解读版本差异；不可比则先修复分组或统计口径，再决定是否重新开始观察。
