Boloop 阅读示意图（AI 生成）：不同统计来源有不同单位、日期边界与覆盖范围。
Boloop 接入统计以后，后台里同时出现了几组看起来应该相关、实际却对不齐的数字：本站有下载记录，GA4 只有很少的会话，Search Console 的搜索点击又更少。报表已经能取到数据，判断反而变难了。
如果把这些数当成同一批人的不同动作，很容易得出一个漂亮的转化率。但我们没有证据证明它们来自同一群访客，甚至连一天从什么时候开始都不相同。我后来先做了一件很朴素的事：给每个数字写清楚“它在数什么”。
同一个网站，三种观察位置
本站数据库记录的是在本站发生、符合接口规则的事件。例如托管文件下载、原创文章阅读、推荐内容的来源链接点击。这些事件接近具体功能，适合回答“这个入口有没有被使用”。一次下载并不自动对应一个独立读者，也不代表文件随后被安装。
GA4 提供用户、会话、页面浏览、来源与互动等指标。在 Boloop，浏览器端 GA4 需要访客同意可选分析后才启用。因此，它观察到的人群与本站某些功能事件天然存在差别。把两者要求成完全一致，等于先忽略了自己的采集设计。
Search Console 则从 Google 搜索这一侧观察展示和点击。有人直接输入网址、从 X 打开链接，或者在浏览器书签里访问，都不必产生 Google 搜索点击。搜索点击也不能直接代替一次完成的站内阅读。
这三套数字可以互相帮助解释，但不能随意合并为一个漏斗。
日期看起来一样，也可能不是同一天
Boloop 的本站事件按 UTC 日聚合；GA4 属性使用 Asia/Shanghai；Search Console 的报表按其 Pacific 日期口径处理。在我们的运营记录里，后者以 America/Los_Angeles 表示。
例如上海时间凌晨的一次访问，可能已经进入 GA4 的新一天，在 UTC 聚合中仍属于前一天。若只按报表中的 2026-10-21 对齐，就会把边界不同的两个集合拿来比较。
我现在会保留两项信息：界面选了什么日期，以及来源实际使用什么时区。日报取完整 UTC 日，后台临时查询却包含当天时，两者也分别保留，不能因为标题都写“最近 30 天”就直接相减。
实际操作时，先从一个来源内部做趋势比较：同一指标、同一时区、相同长度的完整窗口。只有要回答的问题确实需要跨来源时，才继续讨论边界能否对齐。
数据齐了，不代表已经处理完了
另一个容易误判的地方是新鲜度。接口返回了日期和数值，只说明这次拿到了这些行，不能证明它们以后不会变化。
Boloop 的运营流程把 GA4 最近两日标为暂定，趋势比较保守地使用属性日结束至少 48 小时的数据。较早的数据仍可能回补。Search Console 也保留自己的延迟窗口，缺少某天时标为未知，不用零补齐一条看似完整的趋势线。
这让日报多了一点等待，却少了许多无依据的“昨天突然掉量”。新站本来就样本少，如果再把未完成处理的昨天与较成熟的前天比较，一个小变化就很容易被放大。
显示数字、真实事件和自然增长要分开
Boloop 有管理员设置的初始计数，也有实际请求形成的事件。这两类字段分别保存为 initial_* 与 real_*。初始值不能放进增长报表，不能用它证明某篇文章已经有真实读者。
但把初始值排除以后，也还没有直接得到自然增长。上线检查、浏览器验收、正常的运营操作，仍可能贡献真实请求。它们确实发生了，却不是搜索获客的成果。
同样，不能把每天的活跃用户数相加后声称得到期间去重用户；一个人可能在多天出现。也不能拿本站下载次数除以 GA4 会话，声称这是下载转化率。没有一致的人群、时间范围和事件关联，分子与分母只是刚好放在一起。
我的报表现在先回答四个问题
每次读数据，我先确认：
- 指标是什么，统计的是事件、会话、用户，还是搜索展示与点击？
- 范围是什么，来源时区、截止日期和实际覆盖从何时开始？
- 状态是什么，是有数据、无数据、尚未接入，还是读取失败？
- 这次变化能解释到哪一步，是否混有验收、是否缺少可比基线？
读取失败会显示 unavailable；尚未接入是 not-integrated；正常查询但没有记录是 no-data。这些状态不共享一个零。否则一个外部接口故障，就能在图上制造一次“流量归零”。
2026 年 10 月 22 日复盘时，我们的搜索证据仍很少，主要是品牌词和英文首页，尚不足以判断某项页面改动是否带来增长。这并不妨碍继续修页面、写文章，只是效果结论要再等等。
如果你也在给自己的 AI 项目加统计，可以先做一张指标字典，把来源、单位、时区、覆盖和限制列出来。它比把所有数字排进一张漂亮仪表盘，更早帮助你发现哪些问题已经能回答，哪些还不能。