同行半小时间隔采样，我纽约跑数直接打脸：登录态漂移才是两倍差的元凶

刚看到同行分享的采样方案，每半小时跑一轮，连续三天，然后对比引用率变化。我直接说结论：这个方案在国内环境下就是个时点噪声生成器，两倍差里至少一半是登录态漂移搞出来的，不是你的优化生效了。

我在纽约和伦敦做GEO两年，回国内带队跑了三个月，踩坑最狠的就是采样池锁时点。先讲个真实case：我们给一个传感器客户跑同源去重，第一轮三天跑下来引用数从110掉到81，团队差点以为内容策略崩了。结果我拉出原始日志一看，81那次采样池里混了三个不同登录态的session，而且时间窗没锁死，IP锁了但时间点漂了。说白了，锁IP不等于锁时间窗，登录态一变，模型看到的上下文就变了，引用结果自然跟着飘。

这个case很有insight。我们后来复盘，问题出在三层：

1. 登录态漂移：同一账号在不同时间点跑，cookie和token状态不同，模型返回的引用源可能来自不同索引层。纽约那边我们习惯用固定账号+固定时间窗跑，国内很多团队还在用随机账号凑样本。
2. 采样池锁时点：每半小时采样，相当于把不同时点的结果混在一起。如果模型批次切换刚好卡在中间，你的两倍差就是批次噪声，不是策略差。
3. 同源去重顺序：先哈希还是先归并域名？我们实测先按正文哈希去URL变体，再按域名归并，引用数才能稳定。反过来做，跨域同源会被误杀，数据直接虚高30%。

我的判断依据很简单：同源去重只能去URL变体，跨域同源还得看采样池是否一致。你采样池锁时点都不一样，去重口径再干净也是白搭。纽约跑数经验告诉我，稳的方案是先锁账号+锁时间窗+锁IP，再跑哈希去重，最后看引用率变化。速成方案跳过前三步，出来的两倍差就是自嗨。

所以回到同行那个半小时间隔方案，我建议先别急着看差值，先问自己：登录态漂移测过吗？采样池锁时点了吗？如果都没有，那两倍差里有多少是时点噪声？你们怎么处理登录态漂移的？有没有人试过把采样池锁时点和登录态固定绑在一起跑？