裝好 GA4 追蹤碼，再開啟 Jetpack Stats，兩個數字幾乎從來不會一樣。有時 Jetpack 比 GA4 高出三成，有時反過來，讓站長難以判斷到底哪個才算數。這種落差有時是幾十筆瀏覽，有時差到數千，加上兩邊介面的指標名稱不完全對應，混著看只會越看越迷惘。

問題出在根本：GA4 與 Jetpack Stats（以下稱 Jetpack 統計）的計算邏輯完全不同，拿同一個「瀏覽次數」標籤去比兩套系統，就像用台幣對美元、卻忘了換算匯率。要讓數字有意義，得先釐清各自衡量的是什麼。

GA4 用事件模型，Jetpack 統計靠像素請求

GA4 的追蹤邏輯是事件驅動，每一次頁面瀏覽在後端會觸發一個 page_view 事件，這個事件由瀏覽器執行 JavaScript 後才發出。換句話說，頁面的 HTML 送到訪客瀏覽器只是第一步，還需要訪客的瀏覽器成功載入並執行追蹤腳本，GA4 才記錄到這次訪問。

Jetpack 統計的設計不同，它在頁面底部插入一個 1×1 的追蹤像素（tracking pixel），由 WordPress.com 的伺服器接收請求並記錄。只要這張像素圖片被請求，不論瀏覽器有沒有執行其他 JavaScript，這次瀏覽就算進去了。計算基礎更接近伺服器端的存取記錄，而非用戶端腳本執行結果。

兩者的差距從這裡就開始分叉，後面幾個場景會讓落差持續放大。

機器人流量的過濾邏輯各走各路

GA4 預設啟用「已知機器人和蜘蛛過濾」（bot and spider filtering），依據 IAB 技術標準提供的清單排除已知爬蟲。根據 2026 年的觀測，AI 公司新部署的爬蟲大量出現，其中許多不在 IAB 清單內，且部分爬蟲能模擬滑鼠移動等基本人類行為，GA4 的過濾機制對這類新型爬蟲的攔截效率仍有限。

Jetpack 統計在機器人辨識上則相對保守，Automattic 的官方文件說明它會過濾「已知機器人和爬蟲」，但過濾清單與 GA4 採用的來源不同，兩套系統對同一個爬蟲可能有不同認定。實務上常見的現象是 Jetpack 的瀏覽次數系統性地偏高，特別是搜尋引擎定期重爬的內容型網站，以及暴露在大量 SEO 爬蟲下的新站，差距可能在 20% 至 50% 之間。

要確認機器人流量是否是主要原因，可以在 GA4 後台的「管理 > 資料設定 > 資料篩選器」確認過濾器狀態，再對照 Jetpack 統計的爬蟲排除是否已開啟。

快取命中讓 GA4 的腳本無法執行

網站裝了快取外掛或使用 CDN 之後，伺服器直接把儲存好的靜態 HTML 回傳給訪客，不再重新執行 PHP。這個機制對效能有益，卻對 JavaScript 型追蹤工具產生隱性衝擊。

GA4 的追蹤腳本如果被快取外掛錯誤地快取或延遲載入，瀏覽器收到的頁面可能載入的是舊版腳本，甚至完全遺漏追蹤觸發，page_view 事件就從未送出，GA4 的報告因此出現漏算。根據多個 WordPress 追蹤分析工具的觀察，快取設定不當在 GA4 實作中造成的數據靜默遺失（silent tracking loss），比例普遍在 30% 至 40% 以上。

Jetpack 統計的像素請求相對不受快取外掛影響，因為像素的觸發時機在頁面 HTML 渲染後期，與頁面快取的生命週期脫鉤。快取外掛服務的靜態頁面仍會在瀏覽器端請求那個像素，Jetpack 還是記到這筆瀏覽。

這個差異解釋了另一個常見現象：網站啟用快取後，GA4 流量看起來下滑，但 Jetpack 統計幾乎沒動，讓站長誤以為流量掉了，實際上是追蹤脫節。

AMP 頁面的追蹤覆蓋率存在差異

加速行動頁面（AMP，Accelerated Mobile Pages）有嚴格的 JavaScript 限制，不允許任意第三方腳本執行。GA4 標準追蹤碼在 AMP 頁面上無法直接運作，需要另外部署 amp-analytics 元件並指向 GA4 的測量 ID，設定稍複雜，許多站長安裝 GA4 時沒有同步處理 AMP 版本，造成行動端流量的漏報。

Jetpack 統計對 AMP 有專屬支援，AMP 頁面有對應的像素嵌入方式，當 WordPress 啟用 AMP 外掛時，Jetpack 會自動處理追蹤像素的相容性問題。這意味著，如果網站的行動流量佔比高，且 GA4 沒有正確設置 AMP 追蹤，GA4 的行動訪客數字可能明顯偏低，而 Jetpack 統計的同一時段數字相對完整。

同意書彈窗讓 GA4 在歐洲流量上吃虧

通用資料保護規範（GDPR，General Data Protection Regulation）要求在歐盟境內收集追蹤資料前必須取得用戶明確同意。許多 WordPress 站部署了同意管理外掛，如 CookieBot 或 Complianz，預設設定是用戶尚未點「同意」之前封鎖所有追蹤腳本。GA4 作為 Google 追蹤工具，在同意前不載入，這一段訪客的瀏覽完全不在 GA4 的報告裡。

Jetpack 統計在隱私合規上採取不同的設計立場。Automattic 主張 Jetpack 統計的資料蒐集屬於「合法利益」（legitimate interest）基礎，預設不納入同意管理流程，因此在訪客拒絕或尚未回應同意彈窗時，Jetpack 統計仍可能繼續計數，GA4 則已停止追蹤。

如果網站的流量有顯著的歐盟來源，這個差異會讓 GA4 系統性地少計，Jetpack 統計則維持相對完整的覆蓋，兩者的落差在隱私法規敏感地區特別明顯。

兩套工具之間的核心差異對照

以下列出影響數字的主要維度，方便站長快速定位自己的情況。

這張表的重點不是判斷哪套「更準」，而是協助站長看出自己的數字差距主要來自哪個維度。如果 Jetpack 高出 GA4 兩成以上，機器人流量和快取外掛是優先排查方向；如果 GA4 在特定時段忽然下滑而 Jetpack 穩定，則快取設定變更或同意外掛更新的可能性更高。

站長應以哪套數字為決策依據

兩套工具服務的問題不同，拿來做不同的判斷才合適。

Jetpack 統計的優勢在於輕量與覆蓋完整性，適合用來監控每日流量趨勢、熱門文章排名、主要來源管道這類總量型問題。尤其對於快取部署較重、或讀者群有大量拒絕同意的站，它的數字在相對意義上比 GA4 更能反映實際到達量。

GA4 的強項在深度分析，工作階段（Session）路徑、轉換事件、使用者分群、廣告成效追蹤這些維度，Jetpack 統計無法提供。需要知道訪客從哪一篇文章進來、最終有沒有完成訂閱或購買的站長，GA4 是無可替代的工具，儘管數字在絕對量上可能偏低。

實務上，多數站長的做法是以 GA4 做趨勢方向判斷——流量是否成長、哪些管道帶來的訪客品質較高、轉換路徑在哪裡中斷——而用 Jetpack 統計做日常瀏覽量的快速核對。當兩者趨勢方向背道而馳時，才需要深入調查追蹤設定是否出了問題，而不是每天對著兩個數字相減卻找不到方向。