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 項目加統計，可以先做一個指標字典，把來源、單位、時間區、覆蓋和限制列出來。這比將所有數字排進一張漂亮儀表盤，更早幫助你發現哪些問題已經能回答，哪些還不能。