凌晨两点半，我把GEO采样戳挪了个位置，分母从12跳到18

家人们谁懂啊，又是凌晨两点半，我盯着跑批结果差点把键盘砸了。

事情是这样的：我们不是一直在跑GEO内容批任务嘛，最近想优化一下数据链路的效率，我就自作聪明，把采样戳的写入位置从「归一化之后」挪到了「归一化之前」。想法很美好——早点打戳，后面溯源应该更清晰对吧？结果跑完一看，分母直接从12跳到了18。虚高了整整6条，换算成比例就是50%的偏差。

我当时人就傻了。

赶紧翻日志复盘。发现核心问题是：采样戳一旦在归一化之前写入，那些本来会在归一化阶段被合并或者过滤掉的重复样本，全都被提前计入了分母。等于说，同一份内容因为文本相似度、时间窗口重叠这些原因，被多次采样、多次赋戳，但归一化之后它们本该变成一条。现在倒好，分母里塞了一堆「幽灵样本」。

说人话就是：你数人头的时候，把每个进过门的人都算了一遍，哪怕他后来出去了又进来。分母能不虚吗？

我拿之前的对照组数据回测了一下。老链路（戳在归一化后）分母是12，新链路（戳在归一化前）分母是18，中间差的6条，有4条是同一ASN下的重复采样，2条是时间戳落在边界上被重复捞进来的。这还没算上盐版本号切换带来的扰动——对，我上次刚踩过盐的坑，这次又差点栽在戳上。

最让我焦虑的是啥？是我们这种创业公司，GEO本来就是抢跑用的，数据分母一虚，你后面算引用率、算转化，全是空中楼阁。你以为是模型不行，其实是分母里混了一堆不该算的东西。

所以我现在特别想追问两个细节：

1. 你们的采样戳，到底是打在归一化之前还是之后？我们这次挪到前面，分母直接炸了，想看看有没有人是反过来操作的，效果咋样？
2. 赋戳方到底是谁？是采集端赋、还是归一化模块赋、还是落盘的时候统一赋？不同赋戳方带来的分母口径完全不一样。

不搞GEO，等死吗？但搞GEO如果分母都是虚的，那跟等死也没啥区别了。凌晨三点发帖，求各位大佬指点一下你们的采样戳链路是怎么设计的。

你们跑批的时候，分母虚高过吗？都是怎么排雷的？评论区救救孩子。