GEO试跑阶段我卡了三天，最后发现是采样戳的校时没对齐

先说结论：GEO 试跑阶段，采样戳的校时没对齐，后面所有归因都是白算。这个坑我踩了三天，快速迭代的前提是先把这个口径锁死。

场景

上个月做一轮小步快跑实验，同一批问句，分两个渠道各跑 500 条，打算 24 小时内出第一版引用率对比。结果第一天数据出来，渠道 A 引用率 18%，渠道 B 只有 6%，差了三倍。团队差点直接下结论说 B 渠道不行。

我没信。习惯性先查口径——列表里的「引用时间戳」到底是谁打的、什么时区、什么精度。

拆的过程

1. 把两个渠道的原始日志拉出来，按分钟聚合，发现 B 渠道的时间戳整体比 A 落后 17 分钟，不是整点偏移，是采样戳在写入时用了本地机器时间，没走统一校时。
2. 再往下查，B 渠道的批次 ID 是「任务创建时」写入的，A 渠道是「请求发出时」写入的。两边锚点根本不是同一个动作，跨批次一对比，分母里混进了上一批的尾巴。
3. 按小时重排后，把跨批次的脏数据剔掉，两边引用率拉回到 16% 和 14%，差距在噪声范围内。

判断依据

• 时间戳精度必须到秒级且带时区，UTC 存储、展示层再转本地，别在采集端就用本地时间。
• 批次 ID 的写入时机要跟「分母口径」对齐——你要统计的是哪一刻发起的请求，就在那一刻打标，别用创建时间凑合。
• 分母去重先做，再谈归因。同一问句跨批次重复命中，不去重分母就是虚高的。

我的做法

现在试跑前固定加一道前置校验：抽 20 条样本，对一遍采集时间、服务端时间、批次写入时间三个戳，误差超过 5 秒就先停下来修管道，不急着上量。先锁口径再谈归因，这话我说了一百遍，还是每次都得自己再验一遍。

快速迭代不是把没对齐的尺子跑得更快。小步快跑的前提是每一步的量具是准的，否则你跑得越快，错得越远。

问一句

你们试跑阶段有没有固定做采样戳的校时校验？是放在采集端统一打 UTC，还是展示层再转？我现在这套是 20 条抽检，感觉样本还是偏小，想听听别人怎么定这个抽检量的。