GA4 營收比後台多出一截：purchase 事件重複計算的稽核步驟與修正方式
GA4 的營收或購買次數比電商後台還多，幾乎可以肯定是 purchase 事件被重複送出。最快的確認方法是在探索報表中以交易 ID 為維度、購買次數為指標，只要同一個交易 ID 出現兩次以上，就是重複計算。修正的核心是確保每一筆訂單只觸發一次 purchase，並且每次都帶上正確且唯一的 transaction_id。
追蹤數字比實際少，大家通常會緊張；但數字比實際多，反而常被忽略，因為看起來成效很好。問題是，虛增的營收會讓廣告投資報酬率被高估，出價策略依據錯誤的轉換價值運作，預算可能被分配到其實沒那麼有效的活動上。
這篇文章提供一套稽核流程。你不需要懂程式，但需要能進入 GA4 的探索報表、GTM 預覽模式，以及電商後台的訂單清單。
先確認：差距是不是重複造成的
GA4 與後台數字有落差是常態，不一定是重複。在開始稽核前，先用以下方式判斷方向：
| 現象 | 可能原因 | 優先檢查 |
|---|---|---|
| GA4 營收低於後台 | 同意拒絕、廣告攔截、付款後未返回感謝頁 | 追蹤遺漏 |
| GA4 營收高於後台 | purchase 重複觸發、測試訂單未排除、取消訂單未扣除 | 重複計算 |
| GA4 購買次數高於後台訂單數 | 同一交易被計算多次 | 交易 ID 重複 |
| 購買次數相近但營收差很多 | 金額參數含運費、稅金或幣別不一致 | 參數定義 |
如果 GA4 的購買次數或營收明顯高於後台，就往下進行重複稽核。如果是低於後台，問題方向不同，可以參考廣告平台回報與 GA4 差三成的拆解中的遺漏原因。
稽核第一步：用交易 ID 找出重複
在 GA4 中建立一份自由形式探索報表：
- 維度加入「交易 ID」與「日期」。
- 指標加入「購買次數」與「購買收益」。
- 把交易 ID 放入列，指標放入值。
- 依購買次數由大到小排序。
正常情況下，每一個交易 ID 的購買次數都應該是一。如果看到二、三甚至更多，這些就是重複計算的訂單。另外也要注意交易 ID 顯示為空值或「(not set)」的列，代表 purchase 事件沒有帶上交易 ID，這種情況 GA4 無法去除重複。
官方文件使用交易 ID 減少重複的關鍵事件說明了 GA4 會利用交易 ID 去除同一使用者的重複購買事件。但這個機制有其限制，不能完全取代正確的觸發設計，所以即使有交易 ID，仍應從源頭避免重複送出。
稽核第二步：找出重複的來源
找到重複的訂單後，要判斷是哪一種原因造成的。最常見的有四種：
來源一：感謝頁重新整理或返回
最典型的狀況是 purchase 事件綁定在感謝頁瀏覽上。使用者完成付款後到了感謝頁，事件送出一次；如果他重新整理頁面，或之後從瀏覽器歷史紀錄回到這頁，事件又送出一次。
判斷方式：重複的訂單，兩次 purchase 的時間間隔不固定，有時是幾秒，有時是幾天後。
來源二：多個代碼同時送出
網站可能同時存在電商平台內建的 GA4 整合，以及 GTM 中另外設定的 purchase 代碼。兩者都會送出 purchase，於是每筆訂單都被計算兩次。
判斷方式：幾乎所有訂單都剛好重複兩次，且兩次時間幾乎相同。
來源三：資料層事件被推送多次
工程師在感謝頁推送 purchase 資料層事件，但因為頁面上的某些程式邏輯，推送執行了兩次。GTM 監聽到兩次，就觸發兩次代碼。
判斷方式：用 GTM 預覽模式開啟感謝頁，事件清單中出現兩個 purchase 資料層事件。
來源四：金流返回造成的二次載入
部分金流流程在付款完成後，會先返回一次網站確認狀態，再導到最終感謝頁。如果兩個頁面都被設定為會觸發 purchase，就會重複。
判斷方式：重複的兩次事件，頁面網址不同，但交易 ID 相同。
修正方式：依來源對症處理
- 感謝頁重新整理：在觸發代碼時寫入一個標記，例如用 Cookie 或瀏覽器儲存空間記錄已送出的交易 ID，同一個 ID 再次出現時不再觸發。更理想的是請工程師在伺服器端控制，只在訂單首次完成時推送資料層事件。
- 多個代碼同時送出：決定保留一套，關閉另一套。通常建議保留在 GTM 中管理的版本，方便統一維護；但若電商平台內建整合較完整，也可以反過來。重點是只能留一套。
- 資料層多次推送：交給工程師修正頁面程式，確保推送只執行一次。
- 金流返回二次載入：只在最終感謝頁觸發 purchase，中間的狀態確認頁不觸發。
不管哪一種修正，都要確保每一個 purchase 事件都帶有交易 ID，而且交易 ID 就是電商後台的訂單編號，這樣才能和後台逐筆對帳。電商事件的參數規格可以參考 Google 的電子商務評估開發者指南。
修正上線前，記得依照版本紀律在獨立工作區完成並完整預覽，做法可參考GTM 容器版本管理實務。
稽核第三步：金額參數也要一起檢查
重複計算解決之後，還要確認金額本身的定義。purchase 事件的 value 參數應該包含哪些項目，是一個需要團隊明確決定的問題：
- 是否包含運費？
- 是否包含稅金？
- 折扣碼折抵的金額是否已扣除？
- 幣別參數是否一律為新台幣？
這些定義沒有對錯，但必須與後台報表的口徑一致，否則即使沒有重複，數字也對不上。建議把決定寫成文件，放進行銷數據交接資料中，做法可參考行銷數據交接的六份文件。
上線後的持續監控
修正完成後，建議連續四週每週做一次交易 ID 稽核，確認重複的情況消失。之後可以改為每月一次。監控清單如下：
- 探索報表中是否仍有購買次數大於一的交易 ID。
- 是否有交易 ID 為空值的 purchase 事件。
- GA4 購買次數與後台訂單數的差距是否穩定在合理範圍。
- 網站改版、更換金流或新增付款方式後，立刻重新檢查一次。
第四點最重要。重複計算常常不是一開始就存在，而是某一次改版或更換金流後才出現。把稽核列入上線檢查清單，比事後發現好得多。如果你曾經遇過轉換追蹤全面失效，需要從頭重建，可以參考轉換追蹤重建的那一週。
常見錯誤
- 看到營收比後台高，以為是成效好，沒有懷疑追蹤。
- 只修正其中一個重複來源，其他來源仍在。
- 交易 ID 使用隨機產生的值，而不是真實訂單編號，無法與後台對帳。
- 測試訂單沒有排除，也被計入營收。
- 修正後沒有標記日期，前後數據比較時產生誤判。
如果需要協助稽核電商追蹤設定、確認營收數字的可信度，歡迎參考我們的服務說明。
常見問題
GA4 會自動用交易 ID 去除重複嗎？
GA4 會利用交易 ID 減少同一使用者的重複購買事件，但仍建議從觸發邏輯上避免重複送出，不要完全依賴這個機制。沒有帶交易 ID 的事件則無法去除重複。
已經重複計算的歷史資料可以修正嗎？
GA4 已處理的資料無法刪除或修改。分析時可以在探索報表中以交易 ID 去重後自行計算，並在報告中註明修正前的期間數字偏高。
退款與取消訂單要怎麼在 GA4 中處理？
GA4 提供退款事件，可以送出包含交易 ID 的 refund 事件來扣除收益。是否實作取決於退款比例與報表需求，退款少的網站可以先在後台對帳時處理。
GA4 與後台數字差多少算合理？
沒有標準答案，受同意設定、廣告攔截與付款流程影響。重點是差距要穩定，若突然擴大或反轉，就代表追蹤或流程有變化，需要立刻檢查。