跑批前先做三件事：校时、锁分母、写批次ID，少一件实验就白跑

上周差点翻车。一个跑了五天的问句批次，引用率从32%冲到47%，我正准备往周报里写，顺手拉了下日志时间戳，发现采集端服务器比标准时间慢了11分钟。就这11分钟，把两天的数据切错了窗口，47%直接掉回29%。从那以后我给自己定了规矩：跑批前必须先做前置校验，少一件都不上量。

具体三件事，十分钟能做完，但能救你一整轮实验。

第一，校时前置。
采集端、跑批端、报表端，三处时钟对不对得上，跑之前先对一遍。我现在的做法是：每轮跑批开始前，往日志里打一个校时戳，跟NTP源比一次，偏差超过30秒就停下来查。别嫌麻烦，时间戳一偏，归因全是假的。我那次就是吃了这个亏，表面上数据在涨，实际是把前一天的存量算进了增量。

第二，分母先锁死。
问句集里哪些算品牌词、哪些算品类词，跑之前定好，跑完不许改。我们团队上周有人中途往分母里塞了八条长尾问句，引用率立马从41%掉到19%，他还以为策略失效了，其实是分母被稀释了。分母口径一变，前面所有对比全作废。我现在要求跑批前把问句表拆成两列，品牌词和品类词各自打批次ID，跑完分开算，谁也不许混着看。

第三，批次ID写入时机要对。
这个最容易踩。批次ID必须在下发问句那一刻就写进日志，不能等结果回来再补。补写就会出现同一批数据挂两个ID，或者跨批次的记录串到一起。我见过最离谱的一次，售后那层的问句被补写进了售前的批次里，引用率虚高了一倍，查了两天才发现是写入时机错了。

三件事做完，再谈归因。先锁口径，再谈效果，顺序反了，数据越好看越危险。

我现在每轮跑批前会填一张十行的前置校验表：校时偏差、分母版本号、批次ID写入位置、去重规则、采样比例，五项打勾才放行。快速迭代不是瞎跑，是把校验做在前面，小步快跑才跑得稳。

问一句：你们跑批前会单独做校时校验吗，还是默认服务器时间就是对的？我很好奇有没有人在这上面栽过跟头。