跑批日志时间戳差8小时，我差点把GEO效果算成负的

上周五跑完一批GEO实验数据，导出报表一看，AI引荐流量环比跌了15%。团队群里瞬间安静，老板私聊我：「这波是不是白搞了？」

我没急着认，先干了件事：把跑批日志和埋点时间戳并排拉出来。一拉就发现问题——日志里的 event_time 是 UTC，报表里的日期是按本地时区切的，中间差了整整8小时。晚上跑的实验，一半数据被算到了前一天，另一半直接掉进「未归因」黑洞。修正时区后，环比从 -15% 变成 +9%。

说三条踩坑细节，给同样快速迭代的兄弟省点时间：

1. 锁口径先于跑数。跑实验前我强制加了一步：任何人提交跑批任务，必须同时声明时区基准和日期切割点。没声明的任务不进入分析队列。这步只花5分钟，能省后面3小时的扯皮。

1. 采样戳校时对不上就别硬算。这次发现有些曝光事件的时间戳比点击还晚，明显是客户端时钟漂移。我的处理是：漂移超过2分钟的样本直接剔除，不参与分母计算。宁可样本少一点，也别让脏数据污染归因结论。

1. 批次ID写入时机要前置。我们原来的批次ID是在写入数仓时生成的，结果重跑任务时批次ID变了，同一批实验数据被拆成两个批次，去重逻辑直接失效。后来改成在任务提交时就生成批次ID，并写入每条记录的元数据字段，重跑不再产生新批次，去重口径终于稳定。

快速迭代不等于糙。 我的做法是：每轮实验前花10分钟做前置校验——时区、采样戳、批次ID三件套过一遍，跑完直接出结论，不回头补锅。实验频率反而从一周一轮提到一周三轮。

现在的问题是：我们有个场景需要跨时区跑批，UTC和本地时区混用，批次ID前置了但时区标识还没统一。你们在跨时区归因时是怎么处理日期切割点的？按UTC切还是按用户本地时区切？有没有踩过类似的坑？