任何一份統計的第一個問題是它的母體。前三篇各自交代了自己那個欄位的限制——來源網址會空白、離開事件會丟失、只有執行 JavaScript 的訪客會被記錄——而那些限制分散在各篇時看起來都是可接受的小瑕疵。加總起來才會看到它們共同界定了什麼：這份資料的母體不是「所有讀者」，而是「會執行 JavaScript、沒有攔截 beacon、也沒有退出統計的那些瀏覽」。

這一篇把散落的限制收成一張總帳，理由是報表上的每個數字都會被拿去回答某個問題，而問題答得準不準取決於母體涵蓋了誰。不知道分母的比例沒有意義。

看不見的部分

七條的性質不同，處置方向也不同，值得分開看。

第一條是刻意的。 多數抓取工具不執行 JavaScript，因此不會出現在這份資料裡——這正是辨識自動化流量那一篇說明的結構限制。它讓這份統計比伺服器日誌乾淨，代價是兩者的爬蟲比例完全不可比較。看過日誌裡「七成流量是機器」那類數字的人，不要拿它與這裡的數字對照。

第二條是最容易被低估、也最沒有痕跡的一條。 接收端的網址對本站而言是外部網域，而 uBlock Origin 與 Brave 的預設規則會攔下大量指向分析類端點的請求。被攔下時什麼都不會留下——沒有失敗紀錄、沒有孤兒事件、沒有任何欄位是空的，那次瀏覽就是不存在。這條損失無法從資料內部觀測，只能從外部估（下一節談怎麼估）。讀者組成越偏技術，這一塊越大，而技術部落格的讀者組成正是最偏的那一端。

第三與第四條是小量但方向明確的。 停用 JavaScript 的訪客現在很少；退出統計的讀者則是自己設計出來的缺口，那個缺口存在本身比它的大小重要。

第五條與第六條影響的是行為欄位而非計數。 離開事件遺失讓停留時間與互動旗標偏向缺失，而缺失集中在行動裝置；配額撞頂只在流量尖峰發生，症狀是那個時段的數字偏低。兩者都不影響「哪一篇被打開幾次」這個基準線，只影響建立在行為欄位上的判讀。

第七條讓回訪率單向偏低。 Safari 的追蹤預防機制清除儲存資料之後，同一個人回來會拿到新的訪客識別碼，在資料上是新訪客。這個偏差不會反向發生——不會有人被誤判成回訪——所以回訪率永遠是低估，而低估幅度隨 Safari 讀者佔比變動。

怎麼估自己站的量級

表格裡的量級判斷是方向性的，實際比例要靠外部對照才估得出來。三個成本不高的作法：

用兩個瀏覽器環境自測攔截率。 一個乾淨、一個裝上常見的內容攔截器，各自走一遍相同的路徑，比對記錄有沒有進來。這量不出站上的實際比例，但能確認攔截會不會發生——如果連常見設定都擋得住，那條損失就是真的存在而非理論風險。

拿搜尋主控台的點擊數當外部對照。 Google Search Console 記錄的是搜尋結果的點擊次數，那個計數發生在讀者的瀏覽器之外、不受 JavaScript 與攔截器影響。用同一段時間、同一批頁面比對兩邊的數字，差額大致就是這份統計漏掉的搜尋流量比例。這是這個架構下最容易取得的一把外部尺。

看自己的裝置分佈與已知的偏差方向對不對得上。 若記錄裡行動裝置佔比明顯低於一般內容網站的水準，可能的解釋之一是行動端的離開事件與整段瀏覽更容易丟失，而不是讀者真的都用桌機。

三種作法都不會給出精確的修正係數，它們的用途是判斷「漏掉的量是百分之幾還是幾成」——而那個量級足以決定一個結論能不能下。

這份統計適合回答什麼

相對問題可以回答：哪幾篇比較多人讀、這個月比上個月如何、哪些路徑常被連著讀、哪一篇的停留時間明顯偏短。這些問題的答案建立在「各種損失通道在比較的兩邊大致相同」這個前提上，而在同一個站、相近的時間範圍內，這個前提通常成立。

絕對問題不適合回答：有多少人看過、真實的跳出率是多少、有多少比例的讀者會回訪。這些數字永遠是低估，而低估的幅度無法從資料本身估出來——這正是上一節要用外部對照的原因。

有一類問題落在中間，判斷起來要小心：跨時間的比較在損失通道本身改變時會失效。改版換了頁面結構、內容主題從技術轉向非技術（讀者的攔截器安裝率隨之改變）、加了新的 JavaScript 讓載入變慢，都會讓前後兩段時間的分母不同。看到某個指標長期趨勢反轉時，先確認是不是分母變了。

這張總帳怎麼影響最初的選擇

模組零的自建取捨當時給的判準是「想搞懂機制運作，或資料必須在自己手上」。走到這裡之後，那個取捨可以帶著具體內容重算一次。

值得注意的是，這些限制大部分不是自建造成的。JavaScript 觸發、攔截器、瀏覽器的儲存清除政策同樣適用於 Plausible、Umami、GoatCounter 或任何靠前端腳本收資料的服務——它們的網域出現在攔截清單上的機率甚至更高。自建額外承擔的是實作與維護：退出機制、欄位變更同步、判讀規則的更新。

所以重算的問題不是「自建的數字準不準」，而是「知道這些限制之後，還願不願意為了資料的控制權與理解的深度承擔那些維護工作」。答案是否定的話，換成現成服務不會損失準確度，只會換成另一組別人幫忙維護的限制。

下一步

母體界定清楚之後，剩下的是確認收集鏈本身健康——判定規則寫對了但公式算錯、程式改了但端點沒生效、錯誤訊息指向的位置不是問題的位置，見假故障與靜默失效的診斷。想回頭看某一條損失的機制細節：JavaScript 觸發前提與抓取工具見辨識自動化流量、離開事件遺失見事件模型與停留時間、退出機制與儲存清除見訪客識別與 opt-out、配額碰撞見模組五的配額、防濫用與隱私邊界。