我把GEO跑批的幂等键从毫秒戳换成哈希，重复批次从41条掉到0

上周跑一批GEO实验，同一份问句集我丢进去两次，后台出来41条重复线索。第一反应是采样戳没锁死，查了日志——采样戳是对的，两批一模一样。那问题在哪？

往下拆。

先锁时源，再谈归因。这是我改不掉的顺序。

我把两次跑批的 batch_id 打出来对比，格式是 {场景}_{毫秒戳}。毫秒戳在采样时赋，两批差了几百毫秒，理论上应该区分开。但落盘表里去重是按 batch_id 做的，结果发现——采样时赋的戳到了落盘阶段被重写过一次，用的是落盘时间。所以两批的采样戳虽然不同，落盘戳却因为队列积压被压平到同一秒，去重逻辑直接把一批当成了另一批的重复。

这就是典型的赋戳时机和去重口径对不上。

我的处理：幂等键不用时间，用内容哈希。

具体做法：把 场景 + 问句原文 + 采样戳（采样时锁死，落盘不允许重写） 拼成一个字符串，做一次 SHA1，取前16位当幂等键。落盘表按这个键做唯一约束。

改完重跑，重复批次直接掉到0。

踩过的细节：

• 采样戳一旦赋了就不准改，落盘阶段要单独存一个 write_ts，两个字段分开，别混用。
• 分母去重必须在幂等键这一层做，不能放到下游聚合里做，否则聚合时你根本不知道哪条是重复的。
• 哈希只覆盖内容不覆盖时间的话，同一问句不同批次会被误杀，所以采样戳必须进哈希。

为什么我坚持先量后归因？

因为分母没洗干净之前，任何ROI、任何引用率都是虚的。你拿41条重复线索去算转化，分子分母一起膨胀，最后得出的结论全是错的。我宁可现场把锁加上、把幂等键算对，也不信后台默认口径给的"已去重"三个字。

两天日志翻下来，最大的收获不是哈希本身，是赋戳时机必须跟去重口径一起设计，分开设计必出坑。

问一句：你们的GEO跑批里，幂等键是用时间戳还是内容哈希？采样戳和落盘戳是同一个字段还是分开的？