热力图分析：访客被分配到不同版本时怎样识别样本污染

📍 WDQWDWQD987AAAAA:34.122.173.216
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ShapBot/0.1.0
🔗 /cff2ca8eb8c5.html
📄

热力图分析：访客被分配到不同版本时怎样识别样本污染

先给结论：热力图分析里出现“同一页面、两拨角色吵得不可开交”的情况，通常不是谁看错了，而是两拨人看的根本不是同一批访客。识别样本污染的第一步，不是去争论哪个版本的点击更多，而是先确认热力图的数据是否按版本被切成了互不重叠的集合。如果两个版本共用一条采集通道，或者分流规则在采集之后才生效，那么这份热力图对任何一个版本都不成立，保留它只会让分歧继续扩大。

先判断污染是否存在，而不是先比较版本优劣

样本污染指的是本应属于A版本的访客行为，被记进了B版本的热力图，或者两个版本的行为被合并成一张图。它和“样本量不够”是两回事：样本量不够是数据太少，污染是数据混了。判断方法不依赖任何平台界面，只看一条证据链是否闭合。

这三条里只要有一条不成立，就应默认存在污染，而不是先去解释“为什么A版本点击率更高”。

把分歧转成可核对的证据，而不是继续争论

多个角色对同一事实有不同理解时，有效的做法是把“我觉得”换成“哪条记录能证明”。可以按下面的顺序做一次核对，每一步都留下可复查的痕迹：

  1. 取同一时间窗内两个版本的会话数，看两者之和是否明显超过该页面同期的总会话数。如果超出，说明存在重复计入。
  2. 抽查若干条原始事件记录，确认每条是否带有明确的版本字段，且字段值只有两种，没有空值或默认值。
  3. 让每个角色各自写下“我看到的结论”和“支撑这个结论的具体字段”，把两份清单并排比对。分歧往往落在字段定义上，而不是数据本身。

这里要说明一个常见误判：某版本的会话数突然归零，不能单独证明分流已经修好。它也可能是采集脚本报错、版本字段被清空、或者统计口径临时变更造成的。归零只是线索，必须配合原始事件记录才能定性。

保留、改写还是退出：三种取舍的适用前提

确认污染之后，处理方式取决于污染发生在链路的哪一段，而不是取决于哪个版本“看起来更好”。

保留：只在版本字段完整且分流先于采集时成立

如果每条事件都带版本字段，且分流在页面渲染前完成，那么这份热力图可以保留，按版本拆开分别看。此时要做的动作是重新导出两份独立数据集，而不是在合并视图里手动筛选——手动筛选容易把边界事件重复计入。拆开之后，下一步才是比较两个版本的点击分布，而且比较对象必须限定在同一入口来源和同一设备类型内。

改写：分流规则可修，但历史数据已混

如果分流逻辑本身有问题，但采集通道可用，可以选择改写分流并重新采集。前提是你能接受历史数据作废。动作是把版本标识提前到分流决策的那一步，并确认它在首次事件上报前就已确定。改写后不要立刻下结论，先跑一轮小流量验证版本字段的分布是否符合预期，确认无误再扩大。这一步的结果直接决定后续分析是否可信：字段分布不对，后面所有对比都白做。

退出：采集层无法区分版本时，继续分析没有意义

如果热力图工具本身只按URL聚合，而两个版本共用URL，且无法在上报层追加版本字段，那么这份热力图无法支撑任何版本级结论。此时合理的动作是暂停基于它的决策，改用能区分版本的采集方式，或者干脆放弃版本对比、回到单版本观察。硬用一份混在一起的数据去支撑取舍，只会把分歧从“数据问题”变成“立场问题”。

一个假设例子：怎样用一条证据链定性

假设某页面同时跑两个版本，团队A认为新版本留不住人，团队B认为旧版本滚动更深。假设两边看的是同一张热力图，且该图按页面URL聚合。核对时发现：该页面的总会话数低于两个版本会话数之和，且原始事件里没有版本字段。这条证据链指向的结论是数据被合并，而不是某个版本表现更差。下一步动作应是先恢复版本字段的上报，再重新采集；在字段恢复之前，任何关于“哪个版本更好”的讨论都不具备可核对的基础。

需要强调的是，第三方估算流量、平台侧报告和站内热力图的口径本来就不同，三者对不上是常态，不能据此直接推断采集出错。判断污染要靠原始事件记录，而不是靠不同报表之间的数字差异。

把结论落到一个可执行的检查点

实际操作中，最省事的检查点是：在分流生效的那一行代码附近，确认版本标识是否已经写入，并且这个标识会随每一次点击、滚动和停留事件一起上报。如果这一步成立，样本污染基本可以排除；如果不成立，先修这一行，再谈分析。这个动作的结果决定了后续所有对比是否有效——修好之前，保留数据只是保留噪音，改写分流才是让分析重新成立的那一步。

图1 图2
nginx