隐藏链接检测访客被分配到不同版本时怎样识别样本污染
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /b92712b2cac2.html
📄
隐藏链接检测访客被分配到不同版本时怎样识别样本污染
先给结论：只有当访客分组发生在隐藏链接检测逻辑生效之前，且两组的入口来源、设备类型和页面路径分布接近时，组间差异才值得当作真实信号继续追查。反例是：分组由页面加载后的脚本决定，而检测动作同时受该脚本控制，这时两组差异可能只是脚本执行顺序造成的，不能直接归因于隐藏链接本身。
先确认分组时点，再谈样本是否被污染
样本污染的核心不是数据量大小，而是同一批访客被不同版本的检测逻辑重复影响。你需要先回答一个动作问题：分组标识是在服务器返回HTML前写入，还是在浏览器执行脚本后写入？
- 若在服务器端分组，每个访客只会拿到一个版本的HTML，检测逻辑与分组结果彼此独立，样本污染风险较低。
- 若在客户端分组，页面可能先加载通用脚本，再根据分组结果决定是否执行隐藏链接检测，此时同一访客可能短暂暴露在两个版本的逻辑下。
实际动作：在测试环境固定一个访客ID，分别记录其请求头、返回的HTML片段、最终执行的检测函数名。若同一访客ID出现两次不同的检测函数名，说明分组时点晚于检测动作，样本已被污染。这个结果会直接影响下一步：要么把分组前移到服务端，要么把检测动作改为只读取分组结果、不再自行判断。
用可核查的证据链区分污染与真实差异
第三方估算流量、搜索引擎报告与站内统计口径不同，不能互相替代。判断样本污染时，优先看能直接对应到单个访客的日志，而不是汇总报表。
- 取同一时间窗口内的访问日志，按访客ID聚合，标出每个ID命中的版本。
- 检查是否存在同一ID在短时间内命中两个版本，且两个版本都触发了隐藏链接检测。
- 对比这些ID的入口来源和落地页路径，看是否集中在某一类跳转或某一类外部引荐。
如果重复命中的ID明显集中在某个来源，更合理的解释是该来源的跳转链路绕过了分组写入点，而不是隐藏链接检测本身出了问题。反过来，如果重复命中分散在所有来源，才需要怀疑分组逻辑的写入位置。
一个假设例子：分组后置如何制造假差异
假设某页面用客户端脚本分组：A组执行完整检测，B组跳过检测。脚本在页面底部加载，而检测函数在页面头部已注册。此时A组和B组的访客都会先执行一次默认检测，再根据分组结果覆盖。结果是A组多了一次覆盖，B组也多了一次覆盖，但两组覆盖顺序不同。
如果你只统计“检测触发次数”，会看到A组和B组都偏高，容易误判为隐藏链接增多。正确做法是统计“每个访客ID的最终检测结果”，而不是统计触发次数。动作调整后，若两组最终结果分布接近，说明之前的差异来自执行顺序，而不是链接本身。这个判断会决定你是否需要回滚分组方案。
什么条件下可以暂时不处理样本污染
如果业务只关心最终转化，且分组只影响展示样式、不影响检测逻辑，那么同一访客短暂命中两个版本通常不会改变结论。适用条件是：检测动作不依赖分组变量，且转化路径在分组前已经确定。
一旦检测动作本身依赖分组变量，或者转化路径会因分组结果而改变，就必须先处理污染。否则后续任何组间对比都缺少共同基线，继续分析只会放大误差。
下一步动作：把分组标识写进检测日志
最小改动是在隐藏链接检测的日志里增加一个字段，记录该次检测读取到的分组标识和读取时间。然后按访客ID检查该字段是否唯一。若唯一，说明分组在检测前已稳定；若不唯一，说明检测读到了变化中的分组值。
这个动作的结果会直接决定你下一步是扩大样本量，还是先修分组写入位置。在分组标识稳定之前，扩大样本量不会降低污染，只会让错误结论看起来更可信。
