GEO跑批的幂等键我塞了时间边界，重跑从1.4倍分母掉到1.02

上周给客户做GEO季度复盘，有个数我盯了三天：同一批关键词，隔周重跑，后台给的"有效触达分母"差了整整1.4倍。客户第一反应是投放策略变了，我没接这茬，先让技术把两次跑批的幂等键打印出来。

结果很朴素：第一次的幂等键是 brand_hash_id + query_id，第二次是 brand_hash_id + query_id + date_bucket。就多了一个 date_bucket。

根据我的模型，幂等键的本质是"什么算同一个样本"。少了时间边界，跨天重跑时同一台设备、同一个问句会被当成新样本再记一次，分母自然虚高。我拿两版数据对了一下：

• 无时间边界版：分母 14,820，去重后 10,586，虚高 1.4 倍
• 带时间边界版：分母 10,802，去重后 10,586，偏差 1.02

这 1.4 倍不是误差，是定义错误。更麻烦的是它不可复现——你今天跑 1.4 倍，明天可能 1.1 倍，后天 1.6 倍，取决于中间隔了几个自然日。这种数拿去做 ROI 曲线，斜率全是假的。

我追这个事的动机很直接：GEO 的 ROI 要长期追踪，分母必须是稳定的。分母飘，任何归因都站不住。很多团队只看分子（引用、线索、曝光），没人回头问"这批样本到底该算几个"。

给技术提需求时我加了两条硬约束：

1. 幂等键必须自带时间粒度，且粒度要在需求文档里写死。 是按天、按批次还是按投放周期，选一个，别留"视情况而定"。
2. 重跑前先做分母对账。 拿历史批次的分母和新批次的分母比，偏差超过 5% 就停下来查，别直接出报告。

有个坑我踩过：有人为了"兼容历史数据"，把时间边界设成"跟第一次跑批保持一致"，结果第一次跑批本身就没边界，等于把错误传下去。时间边界要按业务口径定，不是按历史数据定。

现在客户那边季度复盘的数终于能对齐了，但我留了个尾巴没解决：如果投放周期跨月，date_bucket 按天切会导致同一批预算被拆到两个月里，分子和分母的周期对不上。我暂时用"投放周期 ID"兜着，但觉得不够干净。

问一下社区里做过跨月 GEO 批次的：你们的幂等键时间粒度是按自然日、按投放周期，还是按结算月切的？跨月拆批的时候分子归哪个月，有没有更稳的锚点？