Meta Conversions API 怎麼查？Pixel 與伺服器事件去重、Test Events 故障排除
當同一轉換同時由 Meta Pixel（瀏覽器）與 Conversions API（伺服器）傳送時，必須做去重，系統才分得清重疊與獨立事件。官方建議同時傳送相同的 event_name 與可區分的 event_id；同一 Pixel ID 在約 48 小時內收到相同事件識別時，後到者會被丟棄。本文整理去重邏輯、Test Events 驗證與常見故障，不承諾任何 match rate 或 ROAS 數字。
CAPI 與 Pixel 去重：重點一覽
| 項目 | 可核對事實（核對至 2026-10-30） |
|---|---|
| 何時需要去重 | 採用「冗餘設定」（同一事件同時經 Pixel 與 CAPI 傳送）時必須設定去重（Deduplicate Pixel and server events） |
| 單邊來源 | 若沒有同時經兩邊送同一事件，就不需為該事件做兩邊去重 |
| 建議方法 | 兩邊都帶 event_id；Pixel 的 eventID＝CAPI 的 event_id；Pixel 的 event＝CAPI 的 event_name |
| 時間窗 | 同一 Pixel ID、約 48 小時內相同鍵組合時，後到事件會被丟棄 |
| 驗證收件 | Events Manager 通常可在送出後約 20 分鐘內確認；Overview 可見去重前數量與 Connection Method |
| Test Events | 事件管理工具 → 資料來源 → 測試事件；檢查伺服器 payload；測試資訊約保留 24 小時或直至清除（Test Events 說明） |
| 檢查清單 | 兩邊 event_name 一致 → 共用訂單號或 UUID 作 event_id → 盡量近即時傳送 → value／currency 格式正確且兩邊一致 |
| 禁止事項 | 不虛構 match rate／ROAS 提升％；不重寫 Pixel 安裝步驟（見〈Meta Pixel 教學〉） |
若瀏覽器層尚未穩定，請先完成〈Meta Pixel 教學〉的標準事件；網站購買參數可對照〈GA4 電商事件教學〉的訂單號思路（兩套系統仍分開）。事件穩定後再解讀〈Meta 廣告歸因〉。
什麼時候需要 CAPI？和只裝 Pixel 差在哪？
Meta Pixel 在瀏覽器執行，容易受攔截、同意橫幅或頁面未完整載入影響。Conversions API（CAPI）則由你的伺服器（或平台／外掛／伺服器端 GTM）把事件直接傳給 Meta。官方把「Pixel 與 CAPI 並用」稱為冗餘設定（redundant setup），目的是提高事件覆蓋與測量穩定度——但一旦同一轉換會從兩邊各送一次，就必須去重，否則優化與報表可能把一筆成交當成兩筆。
本篇假設你已有 Pixel 或已開始接 CAPI，聚焦去重與驗證；不重寫 Pixel 基底程式碼安裝。若只從單一通道傳送某事件（例如只有伺服器 Purchase、沒有對應瀏覽器 Purchase），官方說明不必為該事件做兩邊去重，但仍應維持命名一致，並用 Test Events 確認伺服器事件有收到。
官方建議的去重方式是什麼（event_id＋event_name）？
Developers 文件列出多種去重選項，並將 Event ID + event name 標為建議做法。判定兩筆事件「相同」的條件是：
- 瀏覽器 Pixel 的
eventID與 CAPI 的event_id相同。 - 瀏覽器 Pixel 的
event（例如Purchase）與 CAPI 的event_name相同。
event_id 應能唯一區分「這一次」轉換（常見是訂單編號，或結帳當下產生、並寫入感謝頁／伺服器的 UUID）。Pixel 端以 fbq('track', …) 的第四個參數傳入 eventID（亦可 trackSingle 或影像像素的 eid）。伺服器端則在 CAPI payload 帶同一字串的 event_id。
Best practices 亦提醒：兩邊使用相同的 event_name，並帶上 event_id（或 external_id 與 fbp 組合）。內容無明顯差異時，系統一般偏好先收到的那筆事件。介面文案與參數名稱以當下文件為準。
48 小時去重窗與「只送一邊就不需去重」如何理解？
文件說明：若同一 Pixel ID 在約 48 小時內收到相同的伺服器鍵（event_id＋event_name）與瀏覽器鍵（eventID＋event），後到的事件會被丟棄。去重只在「收到第一個該 event_id 之後約 48 小時內」有效——延遲過大的伺服器補傳，可能已落在窗外而無法與瀏覽器事件合併。
另一條清楚規則：只使用單一事件來源時不會做兩邊去重。連續兩筆只有瀏覽器、或連續兩筆只有伺服器、且內容相同，文件寫明不會因此丟棄其中一筆。因此「重複 Purchase」若出現在單邊通道，更可能是你的網站／外掛對同一動作觸發了多次，而不是 CAPI 去重失敗——診斷時先分清是單邊重複還是兩邊未共用同一 event_id。
文件另述可用 fbp／external_id 輔助去重，但註明通常偏向「先瀏覽器、後伺服器」的情境，限制較多。實務上優先把 event_id＋事件名稱對齊，比依賴次要參數更可檢查。
如何用 Test Events／Events Manager 確認伺服器事件有收到、有去重？
分兩層驗證：
1. Test Events（送測與除錯）
依 Business Help「使用測試事件工具測試伺服器事件」：前往事件管理工具 → 左側資料來源 → 選取資料集 → 開啟「測試事件」分頁 → 在伺服器事件區塊送測（可用終端機或 Graph API Explorer）。用途是檢查伺服器事件 payload 格式是否正確、Meta 是否收到，並除錯異常。測試資訊通常會在工具中保留約 24 小時，或直到你清除。按鈕文案可能隨介面改版，請以當下後台為準。
2. Events Manager Overview／去重檢視（正式流量）
- 收件：送出後通常約 20 分鐘內可在對應 Pixel／資料來源的 Overview 看到事件；可見去重、同意政策等處理前的數量，以及 Connection Method（瀏覽器／伺服器）。
- Event Deduplication：在事件的 Event Details 進入去重分頁，查看各來源去重率、去重鍵使用率與兩邊 Overlap。Overlap 偏低，可能代表鍵不唯一，或只從一邊送了去重鍵。
- Event Freshness：同一處可看事件延遲量表（近即時至以週計）。官方建議盡量縮短「事件發生（
event_time）」與「分享給 Meta」的時間差。
Events Manager 也可能顯示 Event Match Quality（約 1–10 分），用來評估顧客資訊參數對帳號比對的助益。本文只把它當診斷訊號，不承諾任何帳戶會達到特定分數，更不把它等同 ROAS。
常見故障：event_id 不一致、重複 Purchase、value／currency 缺失、延遲過大
| 症狀 | 優先檢查 | 參考 |
|---|---|---|
| 兩邊都有 Purchase，數字幾乎翻倍 | 瀏覽器 eventID 與伺服器 event_id 是否同一字串；事件名稱是否同為 Purchase（區分大小寫） | Deduplication 文件 |
| Test Events 收不到伺服器事件 | payload 結構、資料來源是否選對、是否打到正確 Pixel／資料集；必要時用 Payload Helper | Test Events Help |
| 去重率／Overlap 警告 | 是否只從一邊送 event_id；訂單號是否在重新整理感謝頁時變了；外掛是否各產各的 UUID | Verifying setup → Event Deduplication |
| value／currency 警告 | currency 須為 3 字母 ISO（例如 HKD）；有 value 宜同時有 currency；Pixel 與 CAPI 數值應一致 | Pixel 診斷說明 |
| 多餘購買事件 | 單一動作觸發多次、感謝頁重複發送；先分清是單邊重複還是兩邊未去重 | 同上診斷 Help |
| 延遲過大 | 批次補傳是否超出約 48 小時去重窗；Event Freshness 是否偏 Weekly | Verifying setup／Best practices |
診斷 Help 亦提醒：若 Pixel 與 CAPI 的貨幣或金額不一致，在事件被去重／保留時，可能留下「不是你預期那組金額」的版本，進而讓後台 ROAS 解讀失真——這是參數品質問題，不是「接了 CAPI 就保證 ROAS 上升」。
和 Pixel 教學、GA4 purchase、廣告歸因文如何分工？
- 〈Meta Pixel 教學〉：瀏覽器安裝、標準事件與 CAPI 入門概念。本篇不重複安裝步驟，只承接「兩邊都送了之後怎麼去重與驗證」。
- 〈GA4 電商事件教學〉：GA4 的
purchase／transaction_id。可與 Metaevent_id共用「同一訂單號」的實務思路，但 GA4 與 Meta 仍是兩套系統，數字不必強行相等。 - 〈Meta 廣告歸因教學〉：歸因窗與報表解讀。應在事件去重與參數穩定之後再談，否則優化目標可能建立在重複或缺失的轉換上。
來源
- Meta Developers：Deduplicate Pixel and server events
- Meta Developers：Verifying your setup
- Meta Business Help：Test Events tool（測試伺服器事件）
- Meta Developers：Conversions API best practices
- Meta Business Help：Troubleshoot Pixel diagnostics
常見問題
只送 CAPI、不送 Pixel，還要設 event_id 去重嗎？
官方說明若沒有同時經 Meta Pixel 與 Conversions API 送同一事件，就不需為該事件做兩邊去重。仍建議保留穩定事件命名與參數品質，並用 Test Events 驗證伺服器事件有正確送達。
event_id 可以用訂單編號嗎？
常用做法是使用可唯一區分該次轉換的識別（例如訂單號或瀏覽器與伺服器共用的 UUID），並確保兩邊送出同一個值。Pixel 的 eventID 須對應 CAPI 的 event_id；細節以 Developers 文件與你的平台／外掛為準。
Events Manager 數字和 GA4／訂單後台不一致正常嗎？
常見。事件定義、歸因、同意控制與去重都會造成差異。應固定時間範圍與事件定義交叉比對，不要用單一後台數字對外承諾 ROAS。
