GEO跑批43飘47，我把旧批重算了一遍，发现分母虚高8到21条

求大佬指点。

先说结论：同一个批次，我拿两套快照对完，43条飘成了47条，分母虚高了8到21条不等。这事我卡了三天，越查越慌，想请社区的大佬帮我看看我是不是想岔了方向。

背景

我负责的一个小项目，之前跑批一直用的是入库时间当批次标识。上周我手欠，把同一批数据按「跑批开始时间」和「数据落库时间」分别切了一次，结果对不上。

• 按跑批开始时间切：43条
• 按数据落库时间切：47条

我第一反应是重复计数，赶紧去重，去完还是差。

我做了什么

我把两套快照逐条拉出来对，发现差异集中在三类：

1. 跨天的那几条：有一批数据是晚上23:50开始跑，落库拖到了第二天00:10。按落库时间切，它就跑到下一天去了。这类有3条。
2. 回填的数据：有几条是前两天补进来的，落库时间是我补的那天，但业务上它属于原批次。这类最要命，我数出来是8到11条不等，看我怎么定义原批次口径。
3. 重跑覆盖的：同一个业务主键跑了两次，第二次把第一次的记录盖了，但两次落库时间不一样，按哪个算又不一样。

分母虚高8到21条是怎么来的

这个区间不是拍脑袋。我拿三种口径各算了一遍：

• 口径A（只认批次ID，不锁时间源）：虚高21条
• 口径B（锁批次ID + 锁落库时间）：虚高8条
• 口径C（锁批次ID + 锁跑批开始时间 + 回填单独标记）：虚高11条

差距全在回填和跨天这两块。

我最想不通的地方

现在团队里习惯的方案是「只锁批次ID」，也就是说，只要批次ID对得上就算同一个批次。但我的数据告诉我，光锁ID不锁时间源，回填的那批数据会两头都算，分母直接虚高。

我提了个方案：旧批必须重算，回填要单独打标记，责任划分上，回填是数据补录方的事，还是跑批调度方的事？这块我完全没经验。

我的判断（可能不对）

我觉得时间源不锁死，后面对ROI、对转化率全是错的。分母虚高8条，转化率就被稀释了将近两成，这个误差在给客户汇报的时候是致命的。

问题

求大佬指点：

1. 你们跑批的时候，批次ID和时间源是分开锁还是绑在一起锁的？
2. 回填数据算旧批还是算新批？这个口径谁来签字？
3. 旧批重算的话，已经报出去的数据要不要追回来改？

真心求教，我拿我自己的43飘47在这等各位大佬的答案。