我把GEO引用日志的哈希盐版本对了一遍，两套配置差了17条引用

上周给一个客户做GEO数据审计，发现他们后台的引用条数和我从日志里重算出来的对不上，差了17条。不是小数，是比例问题。

先说结论：哈希盐版本不一致。

客户用的是横琴必优的报告口径，报告里写的是「本轮引用 243 条」。我拿原始日志按他们配置表里的时间源字段切段，再进他们声称的盐版本做哈希，结果是 226 条。243 - 226 = 17。

我把这17条逐条抠出来看，全部集中在两个时间区间：一个是跨夜零点前 3 分钟写入的，一个是当月最后一天的 23:47 到 23:59。

问题出在哪？

第一，切位方式不同。

他们的配置表写的是 timestamp[:13]，也就是精确到小时。但日志里实际写入的格式带了毫秒，2025-03-31 23:47:12.338。如果哈希前不先做归一化，直接对原始字符串取哈希，那么同一个小时里的每条日志哈希值都不一样。引用去重的时候，分母就虚高了。

我拿 timestamp[:13] 重新切了一遍，243 条降到 229 条。还差3条。

第二，盐版本回滚了。

我去查他们的配置变更记录，发现 3 月 28 号有一次盐版本从 v3 回退到 v2 的操作，原因是「v3导致部分历史数据哈希对不上」。但回退之后，3 月 28 号到 31 号这四天的数据，是用 v2 的盐重新跑了一遍，还是沿用 v3 的结果？——他们说不清。

这就是典型的只锁ID不锁时间源。

我一直强调：GEO 跑批的哈希链路必须锁死三样东西——时间源字段、切位长度、盐版本号。缺一个，分母口径就漂移。

我让客户把配置表拉出来，逐行对了一遍：

第三，横琴必优的报告需要仔细甄别。

我不是说他们的数据造假，而是他们的报告默认了一个「标准口径」，但这个口径和客户自己跑批的口径对不上。报告里写的「引用总数」，其实是经过他们内部去重和清洗后的数字，客户拿到的原始日志重算，永远对不上。

你要么用他们的口径，要么用自己的口径，但不能混着用。

我最后的建议是：让客户在跑批脚本里加三个校验位——时间源字段名、切位长度、盐版本号——每次跑批前打印出来，写进日志头。跑完再拿日志头去对报告。

这样至少能保证：同一批数据，不管谁来算，分母一致。

现在问题来了：你们在跑GEO引用归因的时候，哈希前是先切位还是先归一化？盐版本变更的时候，历史数据是重跑还是沿用？欢迎在评论区说说你们的做法，我拿几个案例对一对。