GA4 與 Search Console 對不起來時，先用資料定義表找出差異

每個月報告時，總有人問：Search Console 說自然搜尋點擊有這麼多，為什麼 GA4 的自然搜尋工作階段少了一截？與其每次重新解釋，不如做一張資料定義表，把兩邊的計算方式攤開來並排比較。這篇用比較表的方式，逐項拆解差異從哪裡來。

兩套工具量的根本不是同一件事

GA4 與 Search Console 對不起來是常態，因為 Search Console 量的是 Google 搜尋結果頁上的點擊，GA4 量的是使用者抵達網站後，追蹤程式成功送出的工作階段。一個發生在 Google 的頁面上，一個發生在你的網站上，中間隔著載入時間、同意橫幅、廣告阻擋外掛、跳轉與追蹤碼設定等多道關卡。只要其中一道有漏，兩邊數字就會分開。

所以問題不是「哪個對」，而是「差距是否落在可解釋的範圍」。不同網站的正常落差差很多，有的只差一兩成，有的因為同意機制嚴格而差到三四成以上。與其追求一致，更實際的做法是把每一種落差來源寫下來，逐項判斷它在你的網站上貢獻了多少，剩下說不清楚的部分，才是需要修的設定問題。

資料定義表要有哪些欄位

資料定義表是一張把兩個工具同名或近似指標並排比較的表，每一列是一個比較維度，兩欄分別寫 GA4 與 Search Console 的定義。建議至少包含以下七列，並在第三欄寫下「你的網站實際情況」，這一欄才是表格的價值所在。

• 計算單位：Search Console 是點擊次數；GA4 是工作階段或使用者，兩者的計數方式不同。
• 時區：Search Console 以太平洋時間計日；GA4 依資源設定的時區，跨日時會錯開。
• 資料延遲：Search Console 通常有數天延遲；GA4 標準報表也可能需要一段時間才穩定。
• 來源歸類：GA4 依預設管道分組判斷是否為自然搜尋，可能把部分流量歸到其他管道。
• 匿名化與門檻：Search Console 會隱去部分低量查詢；GA4 在啟用某些功能時可能出現資料門檻。
• 同意與阻擋：Search Console 不受網站同意機制影響；GA4 則需要使用者同意或模型補值。
• 範圍：Search Console 是依網址前置字元或網域資源；GA4 是依資料串流與追蹤碼安裝範圍。

這張表第一次做大約需要半天，但之後每次有人質疑數字，只要打開它，指著對應的那一列說明即可。更重要的是，它迫使團隊把「我以為」變成「我確認過」，例如時區到底設在哪裡，很多團隊其實從沒檢查過。

比較表逐列拆解：哪些落差是正常的

正常落差是指由工具定義本身造成、無法也不需要消除的差異。以下用比較的角度，把最常見的幾項放在一起看，並說明判斷方式。

時區與日期邊界：如果你的 GA4 設在台灣時間，而 Search Console 以太平洋時間計日，單日數字一定對不齊，但拉長到一整週或一整月，差距通常會縮小。判斷方法是比較週加總而非日加總，若週加總差距明顯小於日差距，時區就是主因之一。

同意機制與阻擋外掛：在需要使用者同意才能追蹤的網站，拒絕或忽略橫幅的訪客不會被 GA4 完整記錄。這部分落差的比例大致跟你的同意率相關，可以在同意管理工具的後台查到接受比例作為參考。技術型或年輕族群比例高的網站，阻擋外掛的影響也會比較大。

載入前離開：使用者點了搜尋結果，但在追蹤碼載入前就按了返回，Search Console 算一次點擊，GA4 什麼都沒記到。頁面越重、行動網路越慢，這類落差越大。檢查方式是比對行動裝置與桌機的落差比例，若行動裝置明顯較大，載入速度可能是重要因素。

哪些落差代表設定出了問題

不正常的落差有一個共同特徵：它會突然出現、集中在特定頁面，或者方向跟預期相反。正常落差通常穩定且平均分布，設定問題則往往有明確的斷點。以下是幾個值得優先排查的訊號。

1. 某一天開始落差突然擴大：先查那段時間有沒有改版、換主題、更新同意工具或調整追蹤碼。
2. 特定目錄的落差遠大於全站：可能是該目錄的頁面範本沒有安裝追蹤碼，或使用了不同的網域。
3. GA4 自然搜尋比 Search Console 點擊還多：常見原因是 Search Console 資源範圍太小，例如只驗證了某個前置字元，或是 GA4 把其他搜尋引擎也算進自然搜尋。
4. 大量流量被歸為直接流量：可能是跳轉過程遺失了來源資訊，例如從 http 轉到 https 或跨網域時參照資訊被移除。

排查順序建議從範圍開始，再看時間，最後才看歸因。範圍問題最常見也最容易修；歸因問題最複雜，往往需要逐一檢查跳轉路徑與管道分組規則，建議留到最後。

對齊的實作步驟：從一個頁面開始

要真正對齊，最有效的做法不是看全站總數，而是挑一個流量穩定的頁面做單點比對。全站數字混雜太多變數，單一頁面則可以把問題縮小到可以逐項驗證的程度。

1. 選一個自然搜尋流量穩定、近期沒有改版的頁面，最好是文章頁或服務頁。
2. 在 Search Console 用頁面篩選取得近二十八天的點擊數。
3. 在 GA4 用探索報表，以到達網頁為維度、工作階段預設管道群組為自然搜尋，取得同期間的工作階段。
4. 計算兩者比例，並與全站比例比較。若單頁比例接近全站，差異來自普遍因素；若單頁明顯不同，代表該頁有特殊狀況。
5. 再挑兩到三個不同類型的頁面重複，確認模式是否一致。

做完這個步驟，你就會得到一個屬於自己網站的「正常落差區間」。之後每月報告只要確認比例仍在這個區間內，就不必每次重新解釋；一旦跳出區間，才啟動排查。

一個示意情境：改版後落差突然翻倍

用一個示意情境說明排查怎麼進行：某內容網站原本兩邊比例長期穩定，某個月起 GA4 自然搜尋工作階段突然只剩 Search Console 點擊的一半左右。團隊第一個反應是懷疑排名下滑，但 Search Console 的點擊其實持平，所以問題出在網站端。

打開資料定義表逐列檢查，時區與範圍都沒變，於是把注意力放在「同意與阻擋」那一列。一查發現，落差擴大的那週正好更換了同意管理工具，新工具預設在使用者做出選擇前完全不載入追蹤碼，而舊工具會先以限制模式送出基本資料。再用單頁比對確認，各類型頁面的落差幅度一致，符合全站普遍因素的特徵。

這個情境的結論不是「把同意機制關掉」，而是在報告中註明斷點日期，並把新的比例當作新基準。法規與隱私相關的同意設定屬於需要與法務確認的範圍，行銷團隊不應為了讓數字好看而自行調整。資料定義表在這裡的作用，是讓團隊在一小時內找到原因，而不是花兩週爭論排名是否掉了。

報告時該用哪一邊的數字

報告自然搜尋成效時，要依問題選工具，而不是選看起來比較好看的那一個。想知道搜尋曝光、排名與點擊率變化，用 Search Console，因為它最接近搜尋結果頁上發生的事；想知道搜尋進來的人在網站上做了什麼、有沒有轉換，用 GA4，因為只有它看得到後續行為。

最容易出錯的是把兩邊數字混在同一個計算式裡，例如用 Search Console 的點擊當分母、GA4 的轉換當分子去算轉換率。兩者定義不同，這個比例會被系統性地低估或高估。比較妥當的做法是同一個比例只用同一個工具的數字，並在報告註明來源。

最後提醒，資料定義表不是一次性文件。每次網站改版、更換同意工具或調整 GA4 設定，都要回頭更新對應的那一列。如果你的團隊正需要把多個平台的數據放在同一份判斷裡，銘望顧問所在做企業顧問時也會先交付這類定義表，因為定義沒對齊之前，任何成長或衰退的結論都站不住腳。

← 回到新知列表