流量来源统计方法：访客被分配到不同版本时怎样识别样本污染
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /3b60d6d9426f.html
📄
流量来源统计方法：访客被分配到不同版本时怎样识别样本污染
先给结论：识别样本污染的关键，不是看总流量有没有变化，而是看同一访客是否在多个版本之间被重复计入。具体做法是建立一个以访客标识为主键的核对表，把每个访客命中的版本、首次命中时间和后续命中次数列出来。如果同一标识在A、B两个版本下都出现，且时间间隔超过会话窗口，那这部分流量就是被污染过的样本，需要从对比中剔除或单独归因。这一步做完，才能决定下一步是修分流逻辑，还是改统计口径。
先看一个常见的矛盾现象
假设你同时上线了两个落地页版本，A版和B版，分流规则是五五开。一周后，A版统计到的独立访客是1200，B版是800，合计2000。但站内总访客统计只有1600。两边对不上，团队里就会出现分歧：做投放的人认为B版实际拿到的流量本来就少，做前端的人认为统计脚本没问题，做数据的人怀疑是分流没生效。
这种矛盾通常来自两个完全不同的原因，需要分开验证。
解释一：分流确实不均，但样本本身干净
分流不均指的是访客被分配到了不同版本，但每个访客只归属一个版本，没有重复计数。这种情况下，A版1200、B版800的差异是真实的，只是分配比例偏离了预期。可能的原因包括：分流规则里带了设备类型或地域条件，导致某一类访客集中进入A版；或者某个版本的入口链接被外部渠道单独引用，带来了额外流量。
判断这种情况是否成立，证据是：同一访客标识在A、B两版中只出现一次，且各版本的访客之和等于去重后的总访客数。如果1600个总访客里，有1200个只命中A版、400个只命中B版，剩下0个跨版本，那分流不均成立，样本干净，问题出在分配规则上。
解释二：访客被重复计入，样本已经污染
样本污染指的是同一个访客在统计周期内先后或同时命中了两个版本，被两边各计一次。这种情况下，A版1200加B版800等于2000，但去重后只有1600，多出来的400就是重复计数。常见触发条件包括：访客清除了分流用的cookie或本地存储，被重新分配；页面跳转或重定向过程中，版本参数丢失后又重新生成；同一访客在不同设备或浏览器上访问，被识别为不同标识。
判断这种情况是否成立，证据是：同一访客标识在A、B两版下都有命中记录，且两次命中之间的时间间隔大于你设定的会话窗口。如果这400个跨版本访客中，大部分是在同一天内先看到A版、后看到B版，那基本可以确认是污染，而不是真实的分流差异。
用一张核对表区分两种解释
要区分上面两种解释，不需要复杂的归因模型，只需要一张以访客标识为主键的核对表。表里至少包含四列：访客标识、命中版本、首次命中时间、该标识下的总命中次数。建表时注意三点：
- 访客标识要统一，不能A版用cookie、B版用设备ID，否则跨版本匹配不上。
- 首次命中时间要精确到分钟，用来判断两次命中是否落在同一个会话窗口内。
- 总命中次数要按版本分别统计，而不是只记一个总数。
拿到这张表后，先筛出命中版本数大于1的标识，这些就是疑似污染样本。再按首次命中时间的间隔分组：间隔小于会话窗口的，可能是正常的页面跳转或重定向，不一定是污染；间隔大于会话窗口的，才是需要剔除的重复样本。这个动作的结果直接决定下一步：如果疑似污染样本占比很低，可以先在分析时排除它们，继续观察；如果占比很高，说明分流逻辑本身有问题，必须先修分流，再谈对比。
一个注明假设的短例子
假设会话窗口设为30分钟，你从核对表里筛出50个跨版本访客。其中30个是在5分钟内先命中A版、再命中B版，另外20个是隔了一天以上才命中另一个版本。前30个更可能是页面跳转或参数丢失导致的重复记录，后20个更可能是访客清除了标识后被重新分配。这个判断只是假设，需要结合分流脚本的日志去验证：如果脚本日志显示这20个访客在第二次访问时确实没有携带原有标识，那污染结论成立；如果日志显示标识一直存在但版本参数被覆盖，那问题出在参数传递上，而不是访客标识本身。
把分歧转成可核对的项目
当多个角色对同一事实有不同理解时，不要停留在“我觉得是分流问题”或“我觉得是统计问题”的争论上。把核对表作为共同的事实基础，让每个人指出自己认为可疑的行，然后逐行核对访客标识、命中时间和版本参数。核对完一轮后，通常会得到两个明确结论之一：要么污染样本可以量化并剔除，对比继续；要么分流逻辑需要先修复，对比暂停。无论哪种结论，都比继续争论总流量为什么对不上更有用。
最后提醒一点：第三方估算流量、搜索引擎报告和站内统计的口径本来就不同，跨版本对比时不要混用这三类数据。样本污染是站内分流层面的问题，用站内核对表就能定位，不需要引入外部估算来佐证。
