# 网站访客数是零，但 Dashboard 说有 130 人 > 从发现 Cloudflare Web Analytics API 回传 visits=0 开始，完整记录排查过程、两套分析系统的差异、adaptive sampling，自建 beacon 的架构决策。 - Author: Paul Kuo（郭曜郎） - Date: 2026-03-23 - Pillar: 智能与秩序 / Intelligence & Order - Tags: Cloudflare Analytics, 网站流量分析, adaptive sampling, 个人品牌网站, 超级个体 - Canonical: https://paulkuo.tw/zh-cn/articles/analytics-sampling-trap/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/analytics-sampling-trap.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- 晚上十一点半，我打开 paulkuo.tw 的首页，看了一眼流量分析区块。
▶ 听摘要
AI 合成语音・作者本人声线克隆
访客：0。 不对。今天有人看我的文章，翻译工具也有人在用。昨天的数据已有数百人来访，不可能今天直接归零。我打开 Cloudflare Dashboard 看，Page views 193，Visits 130。 零和 130 不是误差，是两个完全不同的世界。究竟是「没人来」，还是「一百多人来过了」。哪一个是对的，或者都错？ ## Cloudflare 的两个世界 如果你的网站放在 Cloudflare 上（全球超过 4,100 万个网站都是），你可能不知道 Cloudflare 其实有两套完全不同的分析系统。 **第一套：Zone Analytics（HTTP Traffic）。** 这是 CDN 层的数据。每一笔经过 Cloudflare 网络的 HTTP request 都会被记录。它能告诉你总请求数、带宽、国家分布、unique visitors（用 IP 去重）。精确，什么都算，包括 Google 的爬虫、ChatGPT 的 crawler、各种监控 bot。 **第二套：Web Analytics（RUM beacon）。** 这是浏览器层的数据。Cloudflare 在你的网页里注入一段 JS beacon，只有真人用浏览器载入页面时才会触发。Bot 不会跑 JavaScript，所以它天然过滤掉了非真人流量。 我在设计流量分析架构时，经过一次迭代，后来选了 Web Analytics 的 GraphQL API 作为主要数据源。理由联起来很合理，它只算真人，更精准。一开始使用 Zone Analytics 这条路，但含有 bot，数字偏高。才刚设定好网站，一天就上千 Visit。 逻辑没问题。但我犯了一个错误：我验证了「这支 API 能给我什么数据字段」，没有验证 Web Analytics（RUM beacon）「给我的数字是不是准的」。 ## Adaptive sampling：让 130 变成 0 追查之后，我找到了根因。Cloudflare 的 Web Analytics GraphQL API 用的是一种叫做 Adaptive Bit Rate（ABR）的取样技术。 原理不复杂：Cloudflare 每秒处理超过七亿笔事件。如果每一笔查询都要扫过全部原始数据，系统要支付更多成本。所以它把数据存成多种分辨率，100%、10%、1%。查询的时候，系统根据数据量和复杂度，自动选一个分辨率回传结果。 对高流量网站，这完全没问题。你的日访客如果有十万，10% 取样也是一万笔，统计上准确度很高。 但对低流量网站呢？我的 paulkuo.tw 一天大约 130 个真人访客。API 取样完之后，回传的 visits 都是 100 的整数倍，0、100、200。130 被四舍五入成了 0。 我去翻了过去 30 天的 API 数据，发现有几天 visits = 0，而且所有数值都是 100 的倍数。这不是「今天坏了」，这是从上线第一天就是这样的逻辑。只是我今天第一次拿 API 数据跟 Dashboard 比对。 后来查了 Cloudflare 的文件，他们承认，现在还没办法让使用者验证查询结果到底准不准。也就是说，你拿到一个数字，但没有人能告诉你这个数字的误差范围是多少。 ## 还有一个更大的数字 当我理清了 Web Analytics 的取样问题，转头去看 Zone Analytics。Unique Visitors 的数字是 1,100。 Web Analytics Dashboard 说 130。Zone Analytics 说 1,100。API 说 0。 三个数字，同一天，同一个网站。 1,100 和 130 的差距，那接近一千个「多出来的访客」就是 bot。我的网站从一开始的设计就是 AI 友善，有 llms.txt、JSON-LD、MCP 支持，都是为 AI 系统设计的。所以 GPTBot、ClaudeBot、Bingbot 这些爬虫很勤劳地来抓内容。Zone Analytics 忠实记录了每一个 IP，不管它是人还是机器。 根据 Imperva 的 2025 年报告，自动化流量在 2024 年首次超过了人类活动，占全球网络流量的 51%。其中恶意 bot 占 37%。Cloudflare 的 2025 年度回顾也显示，AI bot 对 HTML 页面的请求占了 4.2%，Googlebot 一家就占了 4.5%。 所以，我的网站 88% 的 unique IP 是 bot、12% 是真人。听起来很夸张，但在统计上完全合理。今年一月起，很明显有感觉到 "Make something Agent Want"，已经是技术圈内的共识。因此，这就让我重新检视网站只看真人 Visit 的执念。 ## 我走错的三条路 在找到目前的方案前，我犯了三个错。 **第一个错：规划时没做技术侦察。** 选 Web Analytics RUM 做主要数据源之前，我没有查 adaptive sampling 的行为限制，没有拿 API 回传值跟 Dashboard 交叉比对。如果当时花五分钟做这件事，整个问题会在规划阶段被发现。 **第二个错：发现问题后仓促修复。** 我直觉地判断「Zone-level API 的取样粒度应该比较好」，仍有「人类中心」的执念，写了修正版推到 GitHub。推完之后才在 Cloudflare 社群发现有人回报 zone-level API 也有同样的 visits=0 问题。于是 revert。一来一回浪费了时间，还污染了 git history。 **第三个错：把「不含 bot」跟「精确」画等号。** Web Analytics 确实只算真人，但「不含 bot」不代表「数字正确」。取样精度和 bot 过滤是两件完全独立的事。我把它们混在一起看了。 我与 AI Agent 的工程原则是先侦察再动手，但 AI 会疏漏（奇怪，已经写在 skill 了呢），我也会。但人在发现问题的时候，特别容易急着去修，跳过该做的功课。 ## 看见完整的观众轮廓 一开始我把 bot 流量当作噪音，想要排除它。但 paulkuo.tw 有 [AI-Ready 的架构设计](/zh-cn/articles/ai-ready-continuous-optimization/)。llms.txt 让 AI 系统读懂网站结构、JSON-LD 提供结构化知识、MCP 协议让 AI agent 可以直接操作。所以，让 AI bot 来读内容，不是噪音，也是影响力的一部分。 所以正确的问题变成：怎么看见完整的『阅读观众』？ 我需要两个独立的指标： - **真人访客**：多少人类读者看了我的文章和工具。这是旧世界衡量社群影响力的核心指标 - **AI/Bot 访客**：多少 AI 系统在读取我的内容。这是 AI-Ready 策略的成效指标 最终的架构也不复杂。真人访客用自建的 visit beacon，页面载入时发一个 POST 到我的 Cloudflare Worker，Worker 用 IP + User-Agent 的匿名 hash 做每日去重。全站访客继续用 Zone Analytics 的精确 IP 去重。两个相减就是 AI/Bot 的量。 ![paulkuo.tw 流量分析架构图：自建 beacon（真人）+ Zone Analytics（全量）→ 差值计算 AI/Bot](/images/articles/analytics-sampling-trap-architecture.svg) 三个数字都是自己算出来的，不靠 Cloudflare 的估算。做法跟 Google Analytics、Plausible、Umami 这类网站流量分析工具的原理一样。在网页里埋一段追踪码，自己数人头，每一个都算到。只是我不需要额外装第三方工具，直接跑在网站既有的服务器上就行。 ## 你的数据可能会误导你 2025 年，自动化流量首次超过人类活动，占全球网络流量的 51%。AI crawler 的爬取量在同一年增长了超过 15 倍。你的网站不只被人类读，也被机器读。 如果你的网站用的是 Cloudflare Web Analytics 的 free plan，而且日访客在几百以下，仪表板上的 visits 数字，很可能跟我一样，是取样后的估算值，不是精确值。 这不代表 Cloudflare 不好用。它的 CDN、DNS、安全防护在业界顶尖。Web Analytics 的 Dashboard UI 数字是准的。但如果你要用 API 把数据拉到自己的仪表板，在低流量场景下，你需要自己验证一次。拿 API 回传的数字跟 Dashboard 比对，五分钟就能知道答案。 当数据落差过大时，比较直接的办法就是自己数，自己建立精确的访问计数机制。Cloudflare 本身值得信任，问题在于取样在流量规模还小的时候，先天就容易失准。随着受众规模扩大，取样精度自然提升；但偏偏就在流量还在成长的阶段，每一个数字都攸关方向判断。 网站经营不能只靠感觉。五分钟：拿 API 数字跟 Dashboard 比对。如果差距超出合理误差，你就知道接下来该怎么做了。