登录态不锁，GEO采样飘30%我忍了，但报告里这数真不敢拍

最近帮一个客户做GEO效果复盘，踩了个坑，说出来给大伙提个醒。

事情很简单：同一批问句，同一台机器，脚本定时打，隔了两周跑了两轮。第一轮引用率18%，第二轮掉到12.6%。客户那边看到数直接炸了，说优化动作没停过，怎么还倒退了？

我没急着解释，先做了一件事——把两轮的采样日志拉出来对。

第一个问题：登录态没锁。

第一轮跑的时候，脚本用的是干净的出口，匿名态。第二轮我们为了测“个性化推荐”，挂了个测试账号的登录态。结果同一批问句，带登录态的那轮，模型给的引用源变了——多了几个垂类站，少了几个泛资讯站。引用总数看着差不多，但结构完全不一样。

简单说，登录态没锁，采样环境就不是同一个环境，前后两轮的数根本不能放一起比。

第二个问题：同源去重口径没对齐。

我们把两轮的引用域名去重后，发现第一轮有效引用141条，第二轮同源去重完只剩67条。客户一看又炸了，说怎么砍这么多。

我解释了半天：第一轮去重只按主域，第二轮我手贱把子域也拆了，还卡了正文simhash阈值0.9。口径一变，数就砍半。这不是效果波动，是我自己把尺子换了。

第三个问题：时区没校准。

两轮跑的时间，一个是北京时间上午10点，一个是UTC时间下午2点——实际对应的本地时间差了8小时。GEO采样对时段敏感，尤其是新闻类问句，早高峰和晚高峰的引用源能差40%以上。这个之前有帖子聊过，我就不展开了。

我的结论：

1. 监测口径不统一，就别硬比。想比，先把登录态、出口IP、时区、去重规则、simhash阈值全部锁死，写成配置文档。
2. 日志才是底账。脚本跑完必须存原始返回，不存日志只看汇总数，出了问题你连回滚的机会都没有。
3. 登录态这个变量，比出口IP还隐蔽。IP你能查，登录态你不主动控，它就在那悄悄影响采样。

最后说句实在的：GEO技术门槛真不高，难的是把监测口径做干净。口径脏了，内容做得再好，报告也是废纸。

问一句：你们跑GEO监测的时候，登录态是统一锁死的，还是干脆不带？带登录态和不带，引用结构差多少，有人系统测过吗？