重點摘要
為何 GA4、Meta、Google Ads 的轉換數字不同？從購買事件、廣告歸因、時區、退款、重複回傳到訂單主檔，說明跨平台對帳流程。
GA4、Meta 與 Google Ads 的轉換數字不同，常是因為事件定義、歸因視窗、時區、跨裝置與回補時間不同，而非三個系統都測到獨立訂單。同一位顧客可能同時接觸多個廣告，因此品牌應先用電商後台已付款及退款資料建立交易基準，再分析媒體貢獻。
重點先看
- 先分清楚「訂單」「購買事件」「歸因轉換」：電商後台的已付款訂單通常有唯一訂單編號，可與退款、取消和金流核對。
- 歸因視窗不同，答案本來就不會完全一致：例如商店實際收到一百筆付款，Meta 報六十筆廣告歸因、Google Ads 報五十五筆，不能直接加成一百一十五筆新訂單。
- 時區、退款和延遲回補會造成短期差異：比較時要先確認日期是不是同一時區、報表使用事件發生日或廣告互動日，以及商店退款是否已回扣。
先分清楚「訂單」「購買事件」「歸因轉換」
電商後台的已付款訂單通常有唯一訂單編號，可與退款、取消和金流核對。GA4 收到的是網站或 App 傳送的 purchase 事件；若事件重複送出或 transaction_id 設定不正確，報表可能被影響。Meta 和 Google Ads 則依各自歸因規則，把部分轉換歸給廣告接觸。這三種報表應各自標示，不能被迫相加成一個銷售總數。
歸因視窗不同，答案本來就不會完全一致
例如商店實際收到一百筆付款，Meta 報六十筆廣告歸因、Google Ads 報五十五筆，不能直接加成一百一十五筆新訂單。先抽查 transaction_id、purchase 事件去重、支付狀態與報表時間，再理解歸因方法，才能找出是真的追蹤錯誤還是統計口徑差異。
時區、退款和延遲回補會造成短期差異
比較時要先確認日期是不是同一時區、報表使用事件發生日或廣告互動日，以及商店退款是否已回扣。GA4 某些歸因資料可能因處理與模型估算而延後更新；當日快照不必然是最終值。若品牌今天看昨天的 ROAS 就決定停廣告，可能因為資料仍在回補而做出過度反應。
正確的核對順序從訂單系統開始
第一層先核對已付款、取消與退款後的淨訂單及營收。第二層檢查 GA4 的 purchase 事件是否帶入正確的 transaction_id、value、currency，並排除測試訂單。第三層分別檢查 Meta Pixel／Conversions API 和 Google Ads 轉換事件的去重、回傳與對應轉換動作。最後再用各平台歸因報表討論預算配置，而不是把後台轉換量拿來當會計帳。
報告應採三欄並列，避免混淆
管理報表可分成「交易真值：後台淨實收」「行為觀察：GA4 來源與事件」「媒體成效：各平台歸因結果」。每一欄註明更新時間、使用的日期區間、幣別、含稅與退款口徑。當兩個平台都對同筆交易有貢獻時，應討論各自的可能角色，而不是自行任意拆分為兩筆收入。
實務示範
示範：某店單日確實收到一百筆付款，GA4 觀測到九十六筆 purchase 事件，Meta 報告六十個廣告歸因轉換、Google Ads 顯示五十五個。這四個數字沒有直接加減關係。行銷人應先處理 GA4 少掉的事件是否由拒絕追蹤、技術錯誤或定義差異造成，再比較各渠道有沒有帶來有價值的新顧客。數字純屬教學情境。
跨平台對帳的檢查順序與常見落差
第一步先打開電商訂單後台，確認實際收款與退款後的總額，再排除內部測試訂單與尚未完成付款的交易。若品牌有線上與實體雙通路，應標示哪些交易會送回網站追蹤，不要把門市訂單直接拿來和網站 purchase 事件相比。
第二步檢查 GA4 是否每次付款成功才送出 purchase 事件，且 transaction_id 唯一、金額和幣別正確。若同一個交易頁面重新整理就又觸發一次，系統可能看起來有更多購買。這類問題應先由技術窗口檢查資料層與事件送出邏輯，而不是靠修改報表數字處理。
第三步對照 Meta 的 Pixel 與 Conversions API。若瀏覽器與伺服器各送一次相同事件，需要依平台規範設置適當的事件識別與去重，否則廣告後台可能受到重複回傳影響。若事件數突然變高，應先排查技術設定，再解釋為廣告成效變好。
第四步檢查 Google Ads 的轉換動作，確認目前列入主要目標的是購買、加入購物車還是詢問。若多種事件都列為優化目標，報表中的轉換數可能比實際訂單多；此時不應直接說平台錯誤，而是把轉換事件的目的重新整理。
同一份週報應明確標示採用哪個時區、資料更新日、歸因模型及事件範圍。若每月都更換計算口徑，就算營收沒變，圖表也可能產生大幅波動。管理層需要的是可以重現的趨勢，而不是每個平台都宣稱自己帶來最多訂單。
最後可用少量真實訂單編號進行逐筆追蹤，在合法與適當權限下核對付款、GA4 與廣告事件是否一致。這種核查只能用來找出設定問題，不能據此還原消費者所有跨裝置的接觸路徑；涉及個資和追蹤同意的資料，必須限制存取。
經營者可以建立固定的每週對帳例會，讓電商、廣告與分析窗口各自提供同期間的資料。商店端帶來已付款訂單與退款，廣告端提供花費和平台轉換定義，技術端說明 GA4 事件及標記是否近期有變更。會議不要急著讓三個平台數字完全一致，而應把差異拆為可解釋的設定差異和需要修復的技術異常。若 Google Ads 以互動日計算、商店以付款日計算，即使數值接近也不是同一統計口徑。只有先定義清楚，後續調整預算才有可信的基礎。
若團隊在會議中比較不同平台的轉換，最實用的做法是先把所有指標旁標上「資料來源」「歸因口徑」「是否含退款」三個註記。主管若只看到未註明的數字，容易把廣告平台自行歸因的成果誤認為可直接對帳的淨銷售額。
常見問題
Q：哪一個平台的 ROAS 才是真的？
A：各平台的 ROAS 都依自身歸因與成本定義計算，應與商店淨營收及整體獲客成本一起判讀。
Q：用 GA4 就能完全解決重複歸因嗎？
A：不能。GA4 有自己的追蹤限制和歸因模型，仍無法觀察每個跨裝置或離線接觸。
Q：數據落差很大該先停廣告嗎？
A：先檢查是否有技術性事件重複、缺漏、時區或歸因設定變更，再判斷實際業績是否惡化。
實務比較｜三個面向與執行判準
| 比較面向 | 核心判斷 | 執行前核對 |
|---|---|---|
| 先分清楚「訂單」「購買事件」「歸因轉換」 | 電商後台的已付款訂單通常有唯一訂單編號，可與退款、取消和金流核對。 | GA4 收到的是網站或 App 傳送的 purchase 事件；若事件重複送出或 transaction_id 設定不正確，報表可能被影響。 |
| 歸因視窗不同，答案本來就不會完全一致 | 例如商店實際收到一百筆付款，Meta 報六十筆廣告歸因、Google Ads 報五十五筆，不能直接加成一百一十五筆新訂單。 | 先抽查 transaction_id、purchase 事件去重、支付狀態與報表時間，再理解歸因方法，才能找出是真的追蹤錯誤還是統計口徑差異。 |
| 時區、退款和延遲回補會造成短期差異 | 比較時要先確認日期是不是同一時區、報表使用事件發生日或廣告互動日，以及商店退款是否已回扣。 | GA4 某些歸因資料可能因處理與模型估算而延後更新；當日快照不必然是最終值。 |
總結
廣告平台的轉換數是媒體決策資料，不是結帳系統的替身。先用實際付款與退款建立一致的交易基準，再閱讀不同歸因模型，才能避免重複計入同一個客戶。
參考資料
Google Analytics：報表歸因模型 https://support.google.com/analytics/answer/16291112
Google Analytics：模型化重要事件 https://support.google.com/analytics/answer/10710245
好友力編輯部內容策略與編輯
好友力 GOOD FRIEND 的內容團隊，負責整理品牌策略、搜尋內容、社群口碑與數位行銷的實務觀點。所有文章均經人工查證與審稿後發布。