试跑卡了三天，才发现是采样戳没校时，白瞎两版词库

上周给一个客户做GEO试跑，小步快跑嘛，本来计划两天出结论，结果卡了三天。一开始以为是词库问题，改了两版；又怀疑是模型采样波动，加跑了两轮。最后把日志拉出来对齐时间戳，发现是采样戳没校时——数据采集端用的是本地时间，分析端按UTC切窗口，中间差了8小时，导致「过期内容」判定全错，把一批刚更新的页面当成了旧版本。

具体说下踩坑链路：

1. 我们的采集脚本在客户内网跑，机器时间比标准时间慢3分40秒，平时看不出来，但做「内容新鲜度」归因时，这3分钟正好卡在批次切换点上，把同一批次的页面拆到了两个窗口。
2. 分析端我习惯先锁口径再谈归因，这次锁了「曝光分母」和「引用分母」，却漏了「时间窗口分母」。结果同一批数据，按采集时间和按入库时间算，覆盖量差了11%。
3. 最坑的是批次ID写入时机——采集端是先写批次ID再打时间戳，中间有几十毫秒空档，批量写入时这个空档被放大，导致同一批里有几十条记录的时间戳落在了上一批。

快速迭代的经验就三条：

• 试跑前先做校时校验：采集端、分析端、数据库三处时间戳对齐到同一个NTP源，误差超过1秒直接告警，别等跑完再看。
• 批次ID要在时间戳之后写入，或者干脆用「批次ID+时间戳」做联合主键，别让写入顺序影响归因。
• 分母去重时，按「内容ID+时间戳小时」做窗口去重，不要只按内容ID，否则跨窗口的重复内容会把分母撑大。

改完这三条，重跑同样的词库，覆盖量从虚高的128%回落到97%，引用率反而从6.2%升到7.8%——因为过期内容被正确剔除了，分母干净了，分子才真实。

现在我把「校时校验」写进了试跑前置检查清单，每次跑之前先花2分钟跑一遍，比事后复盘三天划算多了。

问一句：你们做GEO试跑时，时间戳校时是放在采集端统一处理，还是分析端做二次对齐？有没有遇到过批次ID写入时机导致的归因漂移？