你是否也遇過「打開商店後台，今天有 100 筆訂單，但切到 GA4 卻只看到 90 筆 purchase。」這時你可能會思考，追蹤碼串接是否失效，還是系統出現了異常，但原因其實沒有想像中的複雜。
由於 GA4 本身非帳務系統，當顧客使用無痕模式、AdBlock、VPN 或在付款後沒有回到訂單完成頁面等情況時，都可能讓事件無法被記錄。有鑑於此，排查數據落差的第一步，不是要實現兩邊數字完全相同，而是先確認「比較基準」，再判斷落差是屬於正常範圍，還是已經大到需要檢查 Google Tag Manager（GTM）設定等。
重點摘要
- 訂單數量以 SHOPLINE 後台或 Shoplytics 為準；GA4 適合觀察流量與轉換趨勢，不是帳務依據。
- GA4 與後台出現約 5%～15% 的落差，通常仍在可預期範圍內。
- AdBlock、無痕模式、跨裝置、VPN、特定付款流程，以及多組 GA4／GTM，都可能造成事件遺漏或數據偏差。
- 若常見因素已排除，可暫時移除 GTM，並在 3 至 5 天內驗證 `add_to_cart`、`purchase` 與整體落差。
- 問題改善後，建立新的空白 GTM，依重要性逐項加回掛件；每加回一批，都要重新驗證事件。
先確認數據用途：GA4 與後台各自回答不同問題
排查之前，先問一個更基本的問題：現在看的數據指標，究竟要參考哪一個？提供以下建議：
- 【確認「實際訂單量」】：應以 SHOPLINE 後台的 Shoplytics 為準，因為系統記錄的是商店實際成立的訂單，也是營運與帳務判讀的主要依據。
- 【確認「網站流量變化」】：GA4 最適合用來觀察網站流量、使用者行為與轉換趨勢，它能幫助品牌看出變化方向，但同時也會受到瀏覽器、Cookie、裝置與追蹤機制影響，因此不應要求每一筆流量數字都與訂單後台完全相同，主要可拿來看流量成長與否。
- 【確認「廣告轉換率」】：看各廣告平台後台做準確，並以 GA4 輔助分析，由於不同系統採用的歸因模型、觀察期間與事件定義可能不同，直接把三套系統的數字並排，往往只會得到更多疑問。
簡單來說，SHOPLINE 後台看「實際有多少訂單」，GA4 看「流量與轉換如何變化」，廣告平台則看「廣告歸因成效」，先分清楚各系統適合看指標，能避免拿錯尺去衡量表現。
繼續閱讀文章
GA4 表現為什麼比商店後台少？先排除可預期的落差！
在接下來的排查基準中，你可能會好奇：「那多少的落差是正常範圍呢？」
目前商店後台與 GA4 數據落差可抓 5%～15% 屬正常。
原因不一定來自品牌追蹤碼等設定錯誤，更多時候是顧客端瀏覽環境讓追蹤事件沒有成功送出，這裡也盤點出常見的原因：
原因一、顧客端工具會阻擋追蹤
AdBlock、防毒軟體、防火牆或 VPN 可能直接阻擋追蹤碼與事件請求。訂單仍會在商店後台成立，但 GA4 有可能會收不到對應事件，而這類情況發生在顧客端，品牌通常無法完全避免。
原因二、無痕模式與 Cookie 清除會改變使用者辨識
如果顧客使用無痕模式，或頻繁清除 Cookie，可能被 GA4 視為新的使用者與工作階段，這會讓新使用者數、工作階段數偏高，也使跨次造訪的行為難以串接。
原因三、跨裝置 / 跨瀏覽器會被拆成不同使用者
同一位顧客先用手機瀏覽，再用電腦完成購買，若沒有可供辨識的共同訊號，GA4 可能把兩段行為當成不同使用者，此時單一顧客旅程就會被拆開。
原因四、特定付款流程不一定回到訂單完成頁
部分顧客在付款方式完成後不會自動跳回商店的訂單完成頁，因此無法觸發 「purchase」，像有些特定情境，如綠界 ATM 虛擬代碼、超商代碼／條碼，以及 MOLPay 網路 ATM 等，若流程提供「返回商店」按鈕，需要回到訂單完成頁，才有機會觸發購買事件。
原因五、App 內建瀏覽器與第三方服務有先天限制
顧客從社群 App 的內建瀏覽器開啟商店時，Cookie 與追蹤行為可能不同於一般瀏覽器，第三方服務的事件傳送也不完全由品牌或商店系統控制。
綜合以上，難免商店後台數據會與 GA4、廣告後台數據等有所落差，假如品牌還有使用多組 GA4 以及多組第三方 GTM，甚至可能會產生事件相斥，導致既有商店後台串接 GA4 事件無法傳送。
從全球與台灣 AI 零售應用概況開始，結合流量獲取與企業 AI 轉型的深度洞察，帶領讀者快速瞭解零售 AI 的發展趨勢！
數據落差持續明顯，可能是發生什麼情況？
看到這裡，如果目前數據落差在合理的區間範圍，且能由前述情境解釋，通常品牌不必急著大幅修改追蹤設定；但假如這些情境都已排除，仍然持續出現「明顯落差」，可能大致上是因「前台更新 GTM 失效」或是「GTM 掛件導致衝突」兩種情況所影響。
若為 GTM 掛件導致衝突，這裡分享一套相對單純的驗證方法：
「暫時移除既有 GTM，觀察 3 至 5 天，再逐步加回必要掛件，這能把複雜的追蹤環境拆開，找出真正的干擾來源。」
由於在近年 SHOPLINE 團隊統計 GA4 數據落差的事件當中，有發現一些共通點，而主要原因就是當品牌同時安裝多組 GA4、GTM 與第三方掛件導致衝突，事件可能重複觸發與彼此干擾（如「add to cart」、「purchase」等），此時繼續疊加設定，會讓問題更難定位。
因此先暫時拿掉外部變因，確認商店後台與 GA4 串接是否恢復正常，即可驗證問題是否源於 GTM 掛件等設定。因為 SHOPLINE 後台提供的原生 GA4 串接為獨立運作，不受品牌 GTM 影響。因此即使移除 GTM，原生的「add_to_cart」、「view_cart」與「purchase」事件仍應正常傳送。
然而，前台更新使 GTM 失效的情況，也是許多品牌可能會遇到的，因為品牌在 GTM 中自行設定觸發條件（例如綁定特定按鈕、文字或頁面元素等），假如當系統進行了前台版面或結帳流程更新時，頁面程式碼與元素結構亦可能改變，使原本的觸發條件若找不到對應元素，就會讓事件也會停止回傳。
而通常這類問題最需要留意「加入購物車」、「購物車頁」、「結帳頁」與「訂單完成頁」，因為「begin_checkout」、「purchase」等轉換事件一旦沒有正常觸發，不只 GA4 數據會出現落差，也會影響廣告歸因與 ROAS 判讀，進一步干擾預算決策，所以移除既有 GTM 也是建議的做法。
有鑑於此，如果品牌收到商店前台流程更新、或是不確定是否為 GTM 掛件導致衝突產生，建議可以依序做三件事：
- 確認目前是否有自訂 GTM 設定，尤其是綁定頁面元素的觸發條件。
- 親自走完加入購物車到訂單完成的流程，使用 Google Tag Assistant 或檢測工具確認事件。
- 依最新公告與頁面結構，修正 GTM 觸發條件。
需要特別注意的是，移除 GTM 後，所有透過其傳送的功能都會暫停，包括第三方夥伴串接、品牌自訂事件，以及其他安裝在容器內的追蹤。執行前應先盤點容器內容，確認暫停後的影響。
完整排查流程：移除、觀察、驗證，再逐步重建
步驟 1：從 SHOPLINE 後台暫時移除既有 GTM
進入 SHOPLINE 後台，依序前往「網店行銷及追蹤 → 追蹤設定」，在追蹤工具清單找到「Google 代碼管理工具」。
點選「刪除」的垃圾桶符號，並跟著步驟完成確認。
操作前，請先記錄或備份既有 GTM 容器與掛件設定。這一步的目的不是永久停用 GTM，而是建立一段沒有外部容器干擾的觀察期。
步驟 2：立即驗證兩個關鍵事件
移除 GTM 後，請品牌同時觀察以下兩個面向，用來判斷 GA4 事件是否正常傳送，以及數據落差降低比率：
面向一、確認 GA4 事件是否正常傳送
親自執行一次完整購物流程，使用 Google Tag Assistant 確認：
- 點擊加入購物車時，是否出現「add_to_cart」。
- 完成訂單並進入訂單完成頁時，是否出現「purchase」。
面向二、GA4 vs Shoplytics 數據落差比較
觀察 3–5 天彙整數據，比對 GA4 的「purchase」筆數與 SHOPLINE 後台訂單數，記錄落差比例是否有縮小。另外除了確認事件「有出現」，也要留意是否重複，理想狀態是一筆實際訂單對應一筆 「purchase」。
如果關鍵事件恢復正常，且落差明顯縮小，便可合理判斷原 GTM 容器或其中掛件是主要干擾源，若數據沒有改善，可能就不能認定 GTM 是主要原因，而要回頭檢查付款流程、Consent 設定、多組 GA4，以及顧客端限制。
步驟 3：建立全新的空白 GTM
確認移除舊 GTM 後數據改善，而且品牌仍有使用 GTM 的需求，再建立新的空白 GTM 容器，取得全新的「GTM-XXXXXXX」代碼，並填回 SHOPLINE 後台的 Google 代碼管理工具欄位。（路徑為「網店行銷及追蹤 → 追蹤設定 → 加入顧客活動追蹤」）
小提醒：不要直接沿用舊容器，否則原本的衝突與錯誤設定也會一起回來。新容器串接完成後，先不要一次裝回所有掛件，應再次確認原生 GA4 事件仍正常傳送。
步驟 5：依優先順序逐項加回掛件
從營運上最必要的掛件開始，一次加入少量設定。每完成一批，就重新測試「add_to_cart」與「purchase」，並觀察數據落差。
若加入某個掛件後，事件再次消失、重複或落差擴大，問題範圍就能縮小到該掛件或同批設定。第三方夥伴掛件則應對照夥伴提供的安裝方式與最新規格，避免直接複製舊容器中的設定。
最後，什麼時候需要進一步回報？
什麼時候適合整理證據並進一步回報呢？就是當品牌完成下列檢查後，問題若仍持續時：
- 已確認訂單數以 SHOPLINE 後台或 Shoplytics 為基準。
- 已排除 AdBlock、無痕模式、跨裝置、VPN 與特定付款流程等常見因素。
- 已確認 Consent 與多組 GA4／GTM 設定。
- 已用 Google Tag Assistant 實際測試「add_to_cart」與「purchase」。
- 已移除舊 GTM 並觀察至少 3 至 5 天，數據仍無改善。
- 檢測工具持續顯示異常，且能提供發生時間、操作路徑與事件畫面。
把上述資訊整理完整，能減少來回確認，也更容易分辨問題出在顧客環境、品牌自訂設定、第三方掛件，或原生事件傳送。
總結
GA4 與訂單後台有落差，不等於追蹤一定壞了，只有落差持續超出預期，才進入 GTM 的隔離測試，而排查的重點是一次只改變一個變因。移除舊 GTM、觀察 3 至 5 天、驗證事件，再用全新容器逐項加回必要掛件，流程看似多花幾天，卻比在複雜容器裡反覆猜測更容易找到原因，也能避免為了解決一個事件，意外影響其他追蹤。
常見問題回顧
Q1：GA4 訂單數比 SHOPLINE 後台少，多少落差算正常？
依本次排查基準，約 5%～15% 的落差通常仍在可預期範圍。實際判讀仍要搭配訂單量、付款方式、顧客使用環境與事件測試結果，不能只看單日比例。
Q2：移除 GTM 會讓 SHOPLINE 原生 GA4 追蹤停止嗎？
不會。SHOPLINE 原生 GA4 串接獨不受品牌 GTM 影響，原生的「add_to_cart」、「view_cart」、「purchase」等事件應持續傳送。但所有原本透過 GTM 安裝的第三方或自訂追蹤都會暫停，因此操作前必須先盤點影響。
Q3：為什麼要建立新的 GTM，不能直接裝回舊容器？
舊容器可能同時包含重複、過期或彼此衝突的掛件。建立空白容器，再依優先順序逐項加回，可以觀察是哪一項設定讓事件再次異常，也能避免一次把舊問題全部帶回來。
（文章封面圖片取自 Magnific）
本身對於數位行銷領域滿懷憧憬，喜歡閱讀消費者心理與電商相關書籍，非常愛巴哥狗但家裡卻無法養，期盼能透過各種品牌內容合作（採訪、Podcast、影音企劃）帶給品牌店家更多電商經營的協助。
聯絡信箱：kevin.wu@shopline.com
個人部落格：https://kevins-life.com/
行銷知識 IG：https://www.instagram.com/kevins_lifesnote/
