GEO试跑卡在采样戳校时上，批次ID到底该写在哪一步

上周跑了个小批量试跑，20个查询词，三个AI入口，目标就是看两天内能不能拿到可用的提及数据。结果第一天就发现时间戳对不上——采集器打的戳、日志里的戳、还有后续归因用的戳，三个差了将近40秒。

40秒听着不多，但试跑阶段批量小、请求密，这40秒足够让同一批次的样本串到上一批去。我拉了两天的原始日志逐条对，发现有大约12%的记录批次ID落在了错误的时间窗口里。不是丢数据，是串批次，这比丢数据恶心多了。

我的判断：批次ID必须在请求发出前就写死，不能等响应回来再补。

试过三个位置，直接说结论：

1. 响应回来后写入——最省事，也最容易串。响应延迟波动大，高峰期能差到几十秒，批次边界全糊。
2. 采集器入口写入——好一些，但采集器和实际发请求的服务如果不同步时钟，还是会偏。
3. 请求构造阶段写入，批次ID随请求体一起发出去——目前最稳。相当于给每个请求盖了个章，后面不管走哪条链路，批次归属是确定的。

但第3个也有坑：前置校验必须做。我现在上量前固定跑三件事——

• NTP校时，误差超过1秒直接停，不商量；
• 用20条小样本试跑，人工抽检批次ID和时间戳的对应关系；
• 在日志里加一个字段，记录「批次ID生成时刻」和「请求发出时刻」的差值，超过阈值就打标。

这套下来，试跑从原来两天出不了结论，压缩到半天就能判断方向对不对。快速迭代的前提是数据别骗自己，口径和批次先锁死，后面才谈得上归因。

现在卡在一个具体点上：异步回调的入口，响应回来的时间天然就晚，批次ID虽然请求前写了，但回调落库那一刻要不要再盖一个「回调戳」？盖了怕口径多一层，不盖又怕延迟大的记录对不上。你们异步链路这块是怎么处理的？

#GEO试跑 #批次ID #小步快跑