把GEO监测的采样窗口从24小时压到6小时后，我发现准时率是个假指标

上周把纽约那套跑批口径搬回国内站，做了个对照：同一批 40 条问句，A 组按 24 小时窗口采样，B 组压到 6 小时，连续跑 5 天。结论有点反直觉——24 小时窗口的「准时率」看着漂亮，其实是被平滑掉了。

先说场景。我们这边监测表原来只记两个字段：问句原文、是否引用。后来我把纽约的批次 ID 加回来，又把每条问句的采样时间戳落到分钟级，问题一下就露出来了：B 组里同一条问句在 6 小时内会出现 2-3 种引用结果，早班抓到的和晚班抓到的压根不是同一批页面。A 组因为窗口太宽，这些抖动全被压成了一条「有引用」的记录，准时率自然好看。

判断依据就三条，都是日志里能对上号的：

1. 批次 ID 必须唯一到「问句×采样时刻」，不能只到天。否则你复盘时根本分不清是内容变了还是采样变了。
2. 分母口径先锁死：是「有引用的问句数/总问句数」，还是「引用条数/总采样次数」？我们之前报告混着用，差出快两成。
3. 验收窗口写进合同：乙方承诺的「持续优化」如果不带采样粒度和窗口，等于没承诺。这条我踩过坑，三年前的验收单上就栽在这。

再补一个信源层级的观察。B 组抖动大的问句，八成集中在引用了「资讯类聚合页」的那批；引用官网或结构化页面的问句反而稳。所以我现在的做法是：先按信源层级给问句分桶，再决定采样窗口——聚合页那桶压到 6 小时，官网那桶 24 小时就够，工时也摊得开。

This case 给我的 insight 是：准时率本身不是指标，采样粒度和分母口径才是。窗口一宽，噪声全被平均成「稳定」，报告好看但没法归因。

想问下各位：你们监测表里记不记「采样时刻」这一列？如果不记，回头怎么区分是内容优化生效了，还是刚好撞上了 AI 答案的抖动周期？