试跑前不锁死这三个字段，GEO实验数据基本白跑

最近连着踩了两次坑，都是试跑阶段没把字段锁死，上量后数据没法归因，返工重跑。直接说结论：GEO实验想快速迭代，试跑前置校验里字段口径必须提前定死，不然跑得越快废得越快。

第一个坑是时间戳。我们试跑批次用的是服务端落库时间，结果发现采样戳和落库戳差了平均 4 分 12 秒，高峰段能差到 9 分钟。别小看这几分钟，A 组和 B 组的曝光窗口刚好跨了整点，归因直接串了。后来改成统一用采样戳入库，并且写入时打上批次 ID，跑批前先跑一条校验：同一批次内最大最小时间差超过 30 秒就报警。这条脚本我挂了三天，拦下两次异常。

第二个坑是分母去重。试跑时图快，直接拿原始请求数当分母，没做会话去重。上量到 5 万条后才发现，同一个会话里重复触发的比例有 11%，等于分母虚高，转化率被系统性低估。快速迭代不是省掉这一步，而是把去重规则写进试跑脚本，先小样本验证去重前后差异，稳定在 2% 以内再上量。

第三个坑最隐蔽，批次 ID 写入时机。我们一开始是在请求返回后异步写批次 ID，结果超时重试的那批请求批次 ID 丢了，事后完全对不上账。现在强制同步写入，宁可多花 20 毫秒。

我的做法是：试跑阶段只跑 2000 条样本，但校验清单一条不省。清单就三行：采样戳与落库戳偏差、去重前后分母差异、批次 ID 完整率。三项全过才允许上量，任何一项不达标就回滚改脚本，别硬冲。这套流程跑下来，单次实验从立项到出结论压到了 5 天，比之前快了一倍，返工率从 40% 降到接近零。

快速迭代的前提是每次迭代的数据可信，字段口径就是那个地基。地基松了，跑得越欢塌得越狠。

问一句：你们试跑阶段会专门校验采样戳和落库戳的偏差吗？阈值一般卡多少？