GEO跑批旧批重算，43飘47到底该谁背锅？求大佬指点
大佬们好，我又来求指点了。这次真的被旧批重算搞到头大。
先说背景：我们做GEO内容引用监测，跑批是每天凌晨定时拉数据。之前一直有个毛病，就是分母虚高，大概在8到21条之间飘。后来听了社区大佬的建议，把采样戳写死进配置，分母确实稳了一阵。
但这周出了个新问题。
周一凌晨的批次，我早上看引用率是43/100，也就是43%。结果周二我把周一的旧批重新跑了一遍，变成47/100。对，就是标题里说的43飘47。分母没变，分子多了4条。
我就去查，发现周一跑批的时候，时间源用的是UTC，但内容发布时间戳有些是本地时间。这就导致有4条内容在周一那会儿还没“到点”，被判定为不可引用，重算的时候时间源对齐了，它们又进来了。
说白了就是时间源没锁。我之前只锁了批次ID，没锁时间源，现在看这是个坑。
然后我就想，那旧批重算之后，以哪个为准？
我去问我们组长，他说以最新重算为准，旧批数据要回填。但问题来了：回填是覆盖还是追加？如果覆盖，那周一那份报表已经发给客户了，客户看到的43%，现在要改成47%，怎么解释？如果追加，那两份数据并存，后面做趋势分析的时候分母又对不上了。
还有个更细的，就是挪位的问题。我重算的时候发现，有些内容在旧批里被标记为“无引用”，重算后变成“有引用”，但这些内容其实没变，只是时间源对齐了。那这种挪位，算不算数据修正？还是算脏数据？
我现在能想到的解法是：在配置里同时锁批次ID和时间源版本号，每次重算必须带版本号，旧批数据不覆盖，但打上版本标签，分析的时候按最新版本去重。
但我不确定这么搞对不对，因为这样分母还是会变。比如周一那批，按UTC算分母是100，按本地时间算分母可能就变成104了。那分母虚高的问题不是又回来了吗？
所以想请教各位大佬：
- 你们跑GEO批任务的时候，时间源是怎么锁的？是统一UTC还是统一本地？
- 旧批重算后，数据是覆盖、追加还是打版本标签？客户报表怎么处理？
- 像这种43飘47的情况，你们会归因为时间源问题还是分母问题？
我现在是觉得，光锁批次ID不够，时间源才是真凶。但怎么锁才不引入新的分母虚高，我还没想明白。求大佬指点，感激不尽。
