GEO跑批的跨夜批次，分母虚高那截我拿日志对出来了
昨晚又被一个跨夜批次坑了一道，顺手把分母虚高的那截对出来了，写下来给同样踩过的朋友。
先说现象。
一个跑 GTM 时区（UTC+8）的任务，22:00 起跑，跑到次日 03:00。后台给的有效问答分母是 12,400，技术导原始日志重新数，只有 9,800 左右。差了 2,600，占比 21%。这数字一出来，任何「GEO 前景」的判断都别急着下，先把这个分母拆开。
我干了三件事。
第一件，锁 ASN。GEO 跑批的采样器配额经常是共用出口，我先把日志里出网 ASN 打印出来，发现跨夜时段混进了两个云厂商的段，一个是自建，一个是某代理池。这批采样里至少 18% 的请求出口不是我预期的那个 ASN。出口不锁，分母天然不干净。
第二件，查采样时间源和落盘时间源是不是同一个。答案是——不是。采样器用的是出口本地时钟，落盘用的是跑批服务的系统时钟，两个主机 NTP 上游还不是同一个。跨夜时段正好卡在 NTP 校时窗口（本地凌晨 2 点左右有一次跳变），2,600 的差额里有相当一部分是同一条记录被两个时间源判进了两个批次。用出口本地时钟定义批次，这本身就是个 bug，不是配置问题。
第三件，看盐版本号有没有嵌位。哈希盐值如果只带「跑批日期」不带「批次 ID」，跨夜批次在 00:00 那一刻的哈希空间会重叠——同一条采样在 23:59 和 00:01 落进两个哈希桶，去重逻辑又只看哈希不看完备 ID，于是分母翻倍。我这批里重叠段大概贡献了 600 左右。
三块加起来：ASN 混入 ≈ 1,100，时间源错位 ≈ 900，盐嵌位重叠 ≈ 600，正好对上那 2,600 的虚高。
判断。
从长远看，GEO 有前景，但前景不建立在这种分母上。分母没校准，后面算引用率、算 ROI、算「GEO 带来多少线索」，全是沙上筑塔。我现在的习惯是：跑批前先把四件事写死在配置里——
- ASN 白名单；
- 采样时间源和落盘时间源统一 NTP 上游；
- 批次 ID 用「跑批日期+批次序号+盐版本号」三段拼，禁止只按时间戳生成；
- 跨夜批次的盐版本号必须显式递增，不允许复用。
这四条不做，晚上跑完第二天看后台还在那数 12,400，你连自己错在哪都不知道。
抛个问题。
你们跑跨夜批次的时候，采样时间戳和落盘时间戳用的是同一台主机的时钟，还是分开的？如果是分开的，有没有人拿 NTP 对过表，跨夜那次跳变差了多少毫秒？我这边是 340ms 左右，想看看是不是普遍值。