重複轉換怎麼查?GA4/Google Ads 交易編號與訂單對帳

MeetROAS 編輯團隊 · 發布

先按訂單列出每次傳送的來源、目的地動作與交易編號。同動作重送要查穩定身分及去重規則;同筆訂單出現在兩個重疊動作,則要查設定與報表範圍。Count 的一次/每次不能取代這種排查。

商店只有兩筆付款訂單,廣告報表卻出現三次購買,先查哪筆訂單,被送進哪個轉換動作,不要先改預算。「重複轉換」是同一個完成結果,在你計算的範圍內被表示不只一次;同一位客戶真的再買一筆,則是另一個結果,不能一起刪掉。

交易編號用來識別訂單;事件是描述結果的訊息,重試則是把訊息再送一次。Google Ads 的「轉換動作」是設定好的結果類別,例如某一個購買動作。「去重」是辨認特定範圍內重複表示的結果,不代表只填一個編號,所有平台與動作就會自動合併。

先分清楚:重複傳送,還是不同報表?

GA4 顯示一次購買,Google Ads 也顯示一次,本身不能證明追蹤重複;它們是不同報表視角,加總不會變成兩筆不重複訂單。同一位買家完成兩張不同訂單,也不是兩則重複訊息。

先對齊完成結果、幣別、時區、日期基準與轉換動作,並使用已經歷轉換延遲的成熟期間。事件次數、重要事件次數、歸因信用與不重複買家,回答的問題不同。若問題是一次有效點擊後,真的買了好幾筆,請看另一篇一次與每次計數說明;Count 設定不能修好重複設定的傳送路徑。

訂單總數與廣告報表有落差,是調查線索,不代表兩者必須完全相等。歸因資格、視窗及缺少訊號,都可能帶來合理差異。

具體對帳:四次傳送、兩筆訂單、兩個目的地

以下是假設案例,並非客戶實績。商店完成 A 訂單 USD 100、B 訂單 USD 60;沒有退款、稅或運費。假設兩筆都符合歸因資格、獲得完整信用,報表已成熟,購買動作都選每次。這些條件刻意排除了時間與歸因複雜度。

訂單傳送來源動作編號
A標籤Buy-AA
A重試Buy-AA
A匯入Buy-BA
B標籤Buy-AB

請按訂單看,不要只數列數。重試是把 A 再送到 Buy-A;若該動作的交易編號去重正確,Buy-A 會記兩筆、USD 160。但另一個設定好的 Buy-B 也表示 A。若報表同時納入兩個動作,加總就可能變成三次購買、USD 260,商店實際仍只有兩筆、USD 160。

同一訂單 A 傳送兩次到同動作可在規範內去重;A 傳到 Buy-A 和 Buy-B 則是兩個目的地,不能假設跨動作合併。
教學假設,非實測。編號相同仍要查目的地;一筆訂單不會因多個動作而多賺一次。

多出來的 USD 100 不是新營收,而是 A 出現在兩個目的地。這是示意設定,不代表每種匯入方式都會如此。真正要查的是:兩個動作是否描述同一筆完成購買,又是否同時納入報表或出價目標。

同動作重送,與跨動作重複,要分別修正

Google Ads 交易編號文件說明,同一轉換動作收到相同交易編號,可辨認重複。因此重送 A 應保留 A,另一張訂單則使用 B。若確認頁每次重整都產生新編號,便破壞這個關係;若不同訂單全用固定編號,真實購買反而可能被漏算。

接著查目的地。Google 在多來源轉換 beta 文件明列,去重限於連結的同一動作,不會對帳戶其他動作去重。這項 beta 有可用性與來源限制,本文不是要求你啟用,也不能假設所有串接都使用它;它說明了為何目的地不同時,「兩邊都有同一訂單編號」仍不足夠。

發現兩個重疊購買動作,先記錄各自用途、來源及活動目標選用情形,再決定哪個動作應代表這個報表與優化問題的完成結果。不要為了讓總數變小,就刪掉全部次要量測;診斷用動作仍可能有價值,重點是分開看它的範圍。

GA4 也要查購買身分,避免把真訂單藏起來

在 GA4 查實際送出的 purchase 與 transaction_id。Google 的 GA4 說明描述同一位使用者、相同交易編號的購買去重,並未保證任意 event_id 都能對所有事件類型或收集路徑去重。

同筆購買重送時編號保持穩定,另一筆訂單則不同,也不能把同一編號用在不同使用者。Google 特別提醒,空字串可能把購買事件合併,固定編號也會漏算。因此修完後總數下降,不足以證明修正成功。

編號不可帶入個資。請核對真正送出的值,不能只看標籤變數名稱的截圖。若商店套件與手動標籤都送同一結果,這是待驗證的線索,不能據此認定所有雙來源設定都會重複。

可以照做的修正與驗收清單

  • 挑一小組已知結果。使用獲授權的測試訂單或受適當限制的紀錄,列完成狀態、訂單編號、金額及幣別;不要把客戶個資匯出到共用排查表。
  • 列出每條傳送路徑。記來源、目的地資源或動作、結果名稱、發生時間與編號,查重整、重複標籤、匯入和重試,並保留原始紀錄。
  • 先分類落差。同筆訂單重複送到同動作,查觸發或身分處理;同筆訂單出現在兩個重疊動作,查目的地及目標設定;兩筆真訂單則需要不同身分。
  • 修已證實的原因。調整觸發條件、穩定訂單編號或重疊設定。重試要遵循該串接的文件,保留原事件欄位,不能只保留編號,卻改了時間或金額。
  • 同時驗收重複與真新增。在獲授權測試中,把一個結果送兩次,再送另一筆真實結果;確認文件規範範圍內能辨認重送,第二筆仍保留。查看標籤/事件明細、目的地診斷及稍後成熟報表;HTTP 成功本身不證明計帳正確。

記下生效時間,前後比較要維持相同口徑。歷史資料若要更正,須另外使用平台支援的調整方式;修正未來傳送,不表示舊報表已修復。去掉重複可能讓報表轉換或 ROAS 下降,實際銷售卻沒減少;驗收目標是能追溯真實結果,不是把指標做高。

對已串接的目的地事件,MeetROAS 的事件契約規範穩定的重試身分,重複發生的交易則使用不同編號,協助團隊先對齊目的地回報了什麼,再解讀成效。目的地入金不自動等於商店購買;這也不代表提供訂單帳本對帳,或自動跨 Google Ads 動作去重。

資料來源