链接质量分析：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4f00bd6a6774.html
📄
链接质量分析：访客被分配到不同版本时怎样识别样本污染
先给结论：当同一个链接质量分析任务里，访客被分配到不同版本，样本污染通常不是靠某个指标突然升高来确认，而是靠“分配记录”和“行为记录”能不能对上。如果分配日志里同一访客ID出现在两个版本，或者版本A的曝光里混进了只应进入版本B的入口，那么后续任何按版本比较的链接质量结论都不成立。此时优先动作不是继续看数据，而是先冻结分流、导出分配日志，确认污染范围，再决定是废弃本轮样本还是只保留干净子集。
假设情境：同一批外链入口，两个版本各拿一半流量
假设你正在做链接质量分析，想比较两种落地页呈现方式对后续点击深度的影响。做法是把来自同一批外链的访客随机分到版本A和版本B，各占一半。运行三天后，你发现版本A的跳出率明显更低。但这里有一个隐患：分流脚本写在页面加载之后，而部分外链入口会先经过一个中间跳转页。中间跳转页可能把同一访客先放进A，再因为缓存或重定向把它放进B。此时版本A的低跳出率，可能只是因为它多接了一批本来就会继续点击的访客，而不是版本本身更好。
这个情境的关键不是“哪个版本更好”，而是“样本还干不干净”。如果分配记录显示同一访客ID在A和B都出现过，那么按版本汇总的链接质量指标已经被污染，继续比较只会放大误判。
先查分配日志，而不是先看结果指标
识别样本污染的第一步，是把分流记录调出来，而不是盯着跳出率或停留时长。你需要确认三件事：同一访客ID是否只出现在一个版本；同一会话ID是否跨版本；同一外链来源是否被稳定地分到同一版本。只要其中一项出现交叉，污染就已经发生。
实际动作可以这样执行：导出最近一轮的分配日志，字段至少包含访客ID、会话ID、版本号、分配时间、来源链接。然后用访客ID和会话ID分别做去重计数。如果某个访客ID对应两个版本号，标记为交叉样本；如果某个会话ID在两个版本都有曝光，标记为会话污染。这个动作的结果会直接决定下一步：交叉比例低时，可以只剔除交叉样本后重算；交叉比例高时，本轮样本应整体废弃，不要试图用加权修补。
区分三种常见污染来源，别把它们混成一种
样本污染在链接质量分析里通常来自三个不同层面，处理代价也不同。
- 分流层污染：分配逻辑本身不稳定，比如先跳转再分流、缓存命中旧版本、同一访客刷新后重新随机。这类污染会直接破坏版本对照，通常需要改分流位置，而不是改分析口径。
- 入口层污染：不同外链来源被不均匀地分到两个版本。比如某个高意图来源全部进了A，另一个低意图来源全部进了B。此时即使分配逻辑没问题，版本比较也不公平。处理方式是按来源分层后再看，或者把来源作为固定变量重新分流。
- 记录层污染：分配日志和行为日志的访客标识对不上，比如一端用cookie ID，另一端用设备ID，导致同一访客被算成两个人。这类污染不会在单一日志里暴露，需要做跨日志关联才能发现。
三种污染的识别证据不同：分流层看版本交叉，入口层看来源分布，记录层看标识映射。把它们混在一起，就会得出“数据不可信”这种无法行动的结论。
用一条可核查的证据链决定：废弃、剔除还是重跑
假设分配日志显示，交叉访客占全部样本的8%，且交叉集中在移动端外链来源。这里不能直接说“8%很小所以没关系”，因为交叉样本可能恰好集中在高意图来源上。更稳妥的做法是分两步：先按来源分层，看交叉样本是否集中在某一类入口；再对干净子集和全量样本分别计算同一指标。如果两者方向一致，干净子集的结论仍可参考；如果方向相反，说明污染正在主导结论，应废弃本轮。
这个判断的代价是：剔除交叉样本会减少样本量，可能让原本勉强显著的差异变得不显著。但这不是坏事，它避免你把一个由分配错误造成的差异当成链接质量差异。下一步动作取决于剔除后的样本量是否还足以支撑分层比较；如果不足，就应该重跑一轮，并把分流脚本前移到入口之前。
重跑时优先固定入口，而不是增加样本量
很多人遇到污染后的第一反应是“加大流量再跑一次”。但如果分流位置没改，增加流量只会让交叉样本按比例增加，不会让结论更干净。更有效的动作是先把分流固定在入口层：同一外链来源的访客在进入落地页之前就确定版本，并把这个版本写入会话记录。然后检查缓存策略，确保同一访客不会因为缓存拿到另一个版本。
这样做的结果是，后续的链接质量分析才能按版本做有效比较。你仍然需要保留分配日志，因为入口固定不等于记录一定正确。只有当分配日志、会话记录和来源标记三者能互相印证时，样本才具备比较条件。否则，任何关于链接质量的结论都只是对污染数据的再描述。
