把GEO实验的采样戳和批次ID写进日志后，我砍掉了三成无效试错

先说结论：GEO快速试错的前提不是跑得多，是每次跑完能对得上账。我之前也是猛跑派，一周排十几版问句库，结果复盘时发现日志里一半实验根本没法归因——采样时间戳没打、批次ID写晚了，分母全是糊的。

具体踩坑：上个月做一个问句分层的AB，A组按「用户前置搜过价」拆，B组不拆，跑了一周。看后台数据B组效果好，差点全量切B。结果我手贱去翻原始日志，发现B组有一批请求的采样戳是服务器时间，A组是客户端时间，两边差了将近40分钟，正好跨过早高峰。分母根本没对齐，那个「效果」是时段错位造出来的。

后来我定了三条死规矩，快速迭代照跑，但账必须清：

1. 采样戳在请求入口就写，别等入库。入库再补，中间任何异步环节都能给你漂移。我现在是网关层直接打UTC+客户端时区双戳，宁可多存一列。

1. 批次ID在实验创建时就绑定，不是跑完再归。之前试过按天回捞打标，结果跨零点那批全乱了。批次ID写进请求头，日志、问句库、引用结果三张表用同一个，对不上直接报警。

1. 分母先去重再进看板。同义扩写算不算重复分母这个坑我踩过，现在扩写变体共用父问句ID，看板只认父ID，扩写只做归因下钻。

这三条落地后，同样的人力，有效实验占比从大概五成提到八成，无效试错砍掉三成。不是说跑得少了，是跑完能立刻判断该留该砍，这才是小步快跑的本意。慢一步校时源，快十步砍实验。

抛个具体问题：你们做GEO实验时，采样戳是打在哪一层的？网关、SDK还是入库补的？我特别想看看有没有人跟我一样被异步链路坑过的，以及批次ID你们是怎么保证三张表不串的。