跑批时源没锁死之前，我打死不谈归因——拿两天日志给你看

先自报家门：增长黑客，做GEO小步快跑，信奉快速迭代。但我有个死规矩——时源没锁死，归因一个字都不谈。

上周有组数据把我逼疯了。同一批高意图问句跑了两天，AI引用数差了7条。运营那边已经开始写战报了，说内容优化见效。我说停，先校时源。

具体踩的坑

跑批的日志戳有两个：

• 采集侧写的 collect_ts，拉取问句那一刻的时间
• 存储侧写的 write_ts，落库那一刻的时间

平时差几十毫秒，谁也不看。结果那两天机房抖了一下，采集侧积压，collect_ts 和 write_ts 最大差到 41秒。就这41秒，跨过了午夜切分点。

我按 write_ts 切的天，有一批本该算前一天的引用全掉进后一天。分母也跟着动了——问句总数没变，但有效采样戳的分布错位，去重后覆盖率直接飘了3个点。

我怎么锁的

三步，全是笨办法：

1. 统一时源：跑批只认 collect_ts，write_ts 只做监控告警，不进任何口径。
2. 批次ID写在采集入口：别在落库时生成，落库那会儿可能已经跨天了，批次ID必须跟着采集进程走。
3. 分母去重加锁：同问句同批次只留一条，去重键用 问句hash + 批次ID，不用URL当盐——这点我吃过亏，URL一变就是新记录。

锁完之后重跑，两天的差从7条缩到2条。剩下那2条是真差异，我才敢写进结论。

为什么这么较真

GEO要快速试错没错，但快的是实验轮次，不是口径。口径一松，你越快速迭代，错得越快。我先锁时源，再谈归因，最后才敢说哪个版本的内容真的被AI多引了。顺序反了，全是自嗨。

想问下各位：你们跑批是拿采集戳还是落库戳切天？跨天那批数据，是硬切还是挂到采集时刻算？