Google Analytics 4 (GA4) 是許多行銷、產品、SEO 工作者日常會使用的分析工具，便於觀察網站或文章的成效。不過偶爾會出現 GA4 數據不準如：和其他平台的數字對不起來、冒出一些不合理的流量變動等情況，進而影響我們在做業務決策時的依據。
本篇文章紀錄了我自己在工作中遇到疑似 GA4 數據不準，進而排查出可能的 GA4 機器人流量、GA4 垃圾流量等問題的案例筆記，順便整理當下思考與回頭檢查的幾個面向，希望對遇到類似情況的大家也可以有所幫助。
GA4 數據不準？先理解 GA4 的預設 tracking 架構與其限制
在進入正題之前，我們需要先理解 GA4 運作的基本架構與邏輯：
Google Analytics 4（GA4）是一個以 event-based data model 為核心的分析工具，用來接收並分析來自不同來源的使用者行為事件。簡單來說，在 GA4 裡幾乎所有使用者的互動都會被轉成 event（如：page_view、click、purchase），再進一步被記錄與分析。
GA4 的資料來源主要則分成兩種：client-side tracking（客戶端部署） 以及 server-side tracking（伺服器端部署）。
一般網站最常見的安裝方式，仍然是以 client-side tracking 為主，也就是透過瀏覽器執行 JavaScript，再把使用者在網站上的行為事件送到 GA4；server-side tracking 則像是 Measurement Protocol 或 Server-side GTM，是由後端伺服器直接把事件整理後再送出。
因此，在大多數情況下，我們在 GA4 裡看到的數據，主要仍然來自 client-side tracking 的結果，也就是「瀏覽器有成功執行並送出事件」的行為，而不是完整的使用者行為全貌。
GA4 數據不準的 3 個外部因素與初步排查步驟
理解 GA4 的預設架構與邏輯後，我們可以得知一件事：只要在資料產生或傳遞過程中出現缺失，GA4 就沒有辦法紀錄到正確的數據，進而造成我們認為的「GA4 數據不準」的情形。以下我將會搭配實例，列出 3 個 GA4 流量落差的外部因素與初步排查步驟：
1. 真實使用者資料未被完整記錄
在追蹤公司的 Help Center 文章表現時，我曾發現 GA4 的文章瀏覽數與我們所使用的 CRM 工具後台數字有明顯落差，而且 CRM 顯示的流量反而比較高。
由於 client-side tracking 仰賴瀏覽器端 JavaScript 執行，因此在某些情況下，GA4 可能無法完整記錄使用者行為，例如：
- 使用廣告阻擋器（ad blockers）或隱私外掛
- 瀏覽器隱私政策限制 cookie 或 script（如 Safari ITP）
- 使用者在 tracking script 還沒載入完成前就離開頁面（bounce/early exit）
這些情況會導致「實際有發生，但沒有被 GA4 記錄」的流量出現，因此在不同平台之間產生落差。
這個問題有辦法排查嗎？
和後面兩個原因不同，這個問題造成的是 GA4 數字偏低（漏記真實使用者），而不是多記了不該算的東西。因此排查的目的不是「找出來修掉」，而是「確認影響有多大」。
幾個初步可以確認的方向如下：
- 和其他資料來源交叉比對：把 CRM、email 開信率、或後端 log 拿來和 GA4 比對，落差幅度可以大致反映漏記的規模。完全一致反而不正常（因為每個工具的計算邏輯、session 定義、bot 過濾機制都不同，數字相同通常代表其中一個有問題），但落差超過 20–30% 就值得深究。
- 確認有沒有取樣問題： GA4 探索報表右上角若出現紅色驚嘆號，代表由於超過資訊的數量處理上限，數字已被取樣，本來就不完整，這時和其他工具比對意義不大。
- 檢查基本安裝是否正確：有時落差來自 tracking code 重複安裝或某些頁面根本沒裝到，可以用 GA4 DebugView 或 Google Tag Assistant 確認事件有沒有正常送出。
換言之，這個問題目前沒有可以「完全修復」的解法，廣告阻擋器和瀏覽器隱私設定是使用者端的行為，很難從網站方介入。想更完整捕捉流量的話，可以考慮導入 server-side tracking，或是先理解這個先天限制的存在、在做決策時保留一定的誤差空間。
2. 混入 GA4 機器人流量、GA4 垃圾流量
除了數字對不起來之外，我後來也發現，有些國家 / 地區的流量會突然異常升高，但實際上那裡根本不是公司業務的主要市場。
進一步把這些 session 撈出來看後，會發現一些很明顯的共通點：
- 螢幕解析度幾乎都是 1920×1080
- 流量來源大量是
direct / (none)或(not set) - 平均參與時間接近 0 秒
- 瀏覽器版本出現像
142.0.7444.175這種完整 Chromium build 號
從這些特徵中我們可以發現，這些流量比較像是自動化工具或 headless browser 所產生的行為。
這類 GA4 機器人或垃圾流量來源包含搜尋引擎爬蟲、網站監測工具等，因為也可能觸發前端追蹤，因此仍會被記錄成一般 session，近年來網路上也有不少類似的案例：新加坡、波蘭流量。
雖說 GA4 會自動透過 Google 自身研究與 IAB（Interactive Advertising Bureau）維護的 Spiders and Bots List 名單，過濾部分已知 bot，但由於這套機制主要只能辨識「有公開表明自己是 bot」的流量，而且目前也無法查看到底過濾掉多少 bot，因此對於那些偽裝成正常 Chrome 瀏覽器、完整執行 JavaScript 的 headless browser，GA4 的辨識能力其實有限，便會一併記錄在報表上。
初步排查步驟
如果你也在自家的網站上發現 direct 流量異常偏高、特定國家流量突然暴增，這篇文章的 “How can you identify bot traffic in GA4?” 段落也提供了以下問題可以先讓我們初步排查：
- 是否曾突然出現某個來源的一次性流量高峰？
- 這個異常流量是否以固定頻率重複出現？（例如每 6 小時一次）
- 流量主要來自哪些國家／城市？這些使用者地區是否不符合你的實際市場？
- 流量主要進到哪些頁面？是否幾乎都集中在首頁？網址後面是否帶有異常的 query string（查詢參數）？
- 這些流量的瀏覽器、裝置類型與螢幕解析度是否幾乎完全相同？
如果這些條件有明顯符合的情況，再進一步到 GA4 的探索報表建立自訂區隔，排除螢幕解析度固定、參與時間極短、或異常地區等條件，會更容易把真正的使用者流量拆出來。
3. Broken URL 與 404 錯誤頁面
另一個常見但很容易被忽略的問題，是 404 頁面流量異常增加，同時伴隨 direct/none 流量偏高的情況。
在 GA4 的邏輯裡，當使用者造訪的網址不存在（404），或來源資訊無法被正確辨識（缺少 referrer 或 UTM），這些流量就有可能被歸類為 direct。因此當網站內部存在錯誤連結、隱藏路徑，或被爬蟲持續造訪的無效 URL 時，就可能同時看到 404 流量上升與 direct 流量異常的現象。
在分析公司的 Help Center 流量時，我也發現了大量的 404 網址。匯出網址清單後，發現大約有 1,500 多條流量都指向同一種結構：
/hc/zh-tw/articles/文章標題/subscription.html
這個 /subscription.html 是我們使用的 CRM 系統內建的訂閱功能路徑，但實際上該網站並沒有啟用訂閱功能，因此這些連結全部都回傳 404。
進一步檢查網站模板後，在文章頁的 HTML 結構中發現一段內建 helper：
<divclass="article-subscribe">{{subscribe}}</div>
雖然畫面上沒有顯示任何按鈕，但這段程式碼仍然會在 HTML 原始碼中產生指向訂閱頁的連結。對於爬蟲來說，它讀的是 HTML，而不是畫面 UI，因此會持續抓到這個不存在的路徑，並反覆造訪，造成大量 404 請求。移除掉網站模板中自動產生訂閱連結的這行程式碼後，404 網頁的流量大幅下降，GA4 的數據也確實乾淨許多。
初步排查步驟
進入 GA4 → 點選「報表」 → 在「瞭解網站和/或應用程式流量」選擇「網頁和畫面」 → 新增「網頁標題與畫面名稱」，並輸入 404 錯誤頁面的標題（如「找不到頁面」、「您尋找的頁面不存在」）。
如果這些錯誤標題出現在前幾名，表示問題可能存在。接著加入「網頁路徑與畫面類別」維度，匯出完整的失效網址清單，看看這些 404 網址有沒有共同的規律。如果大量網址都有相同的結構或結尾字串，通常代表是某個系統性的來源，而不是散落的單一連結失效。
準確的 GA4 數據不存在：理解誤差並專注在有效指標
完全「準確」的 GA4 數據幾乎不存在。所有網站分析工具都有盲點，追蹤碼有時候就是沒辦法捕捉到每一個用戶。接受這個前提，你的目標就從「讓 GA4 100% 準確」變成「把誤差控制在合理範圍內，並理解誤差的來源」。
GA4 數據不準本身不一定是問題，比較像是分析工具的正常狀態。在理解 GA4 的限制和數據誤差可能從哪裡來之後，我們可以去想的是：我現在需要用這些數據做什麼決策？再透過設定或其他工具去撈出真正有用的指標，把注意力放回實際要解決的問題上就好。