GEO采样戳校时没做，我拿三个月日志倒推才找到那半小时的偏差

先说结论：采样戳不校时，后面所有快速迭代都是白跑。

上周我把一个客户的GEO监测数据拉出来复盘，发现同一批问句在6小时采样间隔下，下午场的品牌出现率比上午场稳定低8个点左右。我第一反应是内容侧出问题了，差点让内容组改稿。

忍住，先查口径。

第一步：锁时源。 我问数据组三句话——采样戳用的是哪台机器的时间？有没有接NTP？和日志服务器差多少？结果查出来：采集端用的容器宿主机时间漂了，跟标准时间差了快半小时，而且只在某台节点上。那台节点正好承担了下午场的大部分采样。

也就是说，我看到的“下午品牌出现率低”，本质上是那半小时里的问句被归到了错误的时间桶里。

第二步：对批次ID写入时机。 我把同一批问句的批次ID和采样戳拉出来比对，发现有12%的记录里批次ID写入时间晚于采样戳十几秒。这意味着什么？意味着如果AI在这十几秒内返回了不同答案，落库的批次归属和实际采样时刻对不上。快速试错最怕这种——你以为在A版本上试，其实数据是B版本的。

第三步：分母去重。 我把去重逻辑按「问句哈希+采样戳整点小时」重算了一遍，把跨节点重复采集的剔掉，分母一下少了7%。之前那个虚高的转化率立刻回到正常水位。

这三步做完，我只花了半天，但省掉了内容组一周的无效改稿。

我的做法现在固化成检查清单，跑任何GEO实验前必须过：

1. 采样节点NTP校时状态截图存档；
2. 批次ID写入时间与采样戳差值分布，超过5秒的单独标记；
3. 分母按「问句哈希+时间桶」去重，不用默认口径；
4. 实验组和对照组必须同节点、同时间桶。

快速迭代的前提是数据能对得上账。口径没锁死就开跑，跑得越快错得越远。

问一句：你们跑GEO实验的时候，采样戳的时源是统一校过的，还是各节点各管各的？有没有人遇到过批次ID写入晚于采样戳的情况，最后怎么处理的？