# 網站訪客數是零，但 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/articles/analytics-sampling-trap/ - 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 的架構設計](/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 比對。如果差距超出合理誤差，你就知道接下來該怎麼做了。