🧩 一、event_id 是什麼？為什麼這麼重要#

在 Meta 的事件追蹤體系中，每一筆事件都由以下三個欄位唯一識別：

1
pixel_id + event_name + event_id

Meta 透過這三個欄位判斷事件是否重複。當前端（Browser Pixel）與後端（Server CAPI）都上報相同事件時，只要 event_id 一致，Meta 就會認為這是同一筆事件並進行去重。

⚙️ 二、GTM 中如何產生 event_id#

在 Google Tag Manager 中，我們可以透過自訂變數生成一個由 timestamp 與亂數組成的 event_id，例如：

1
return getBrowserId() + '_' + getPageLoadId() + getGtmUniqueEventId();

這段邏輯透過：

• getTimestampMillis() 取得時間戳
• generateRandom() 產生隨機數
• 組合出唯一識別碼

此 ID 會在同一頁載入期間保持一致，確保事件能夠跨前端與後端對應。

🧠 三、Server 端該怎麼產生相同的 event_id#

Server 端可從前端傳遞而來的 event_id 使用，例如：

1. 前端結帳完成時，將 event_id 寫入 GA4 dataLayer 或帶入 API payload。
2. 後端接收到 webhook 或付款完成通知後，從該資料中取出相同的 event_id，並隨 CAPI 事件一併上報。

這樣，Meta 就能識別兩者屬於同一事件，避免重複計算。

💰 四、那 event_id 要不要直接用訂單編號？#

理論上可以，但要注意：

• 若 order_id 永遠唯一且不會重覆使用（即一筆訂單不會修改或重送），那麼可以直接用。
• 但若後端存在 webhook retry、訂單更新或重送機制，Meta 可能會將同一筆訂單誤認為多次購買。

因此建議：

✅ 使用 order_id + 隨機碼 或 order_id + timestamp 組成 event_id。

🧨 五、為什麼同一筆 order_id 會造成混淆#

假設：

• 使用者付款 → 前端送出一次 Purchase
• 後端 webhook retry → 又送一次同樣的 order_id

從商務角度來看，這兩筆是同一筆交易；
但在 Meta 看起來，它只看到「兩筆不同事件」，除非 event_id 一樣。

因此：

Meta 只能透過 event_id 辨識「重送事件」，而不是依 order_id。

⚖️ 六、如果 event_id 相同但金額不同，Meta 會怎麼處理？#

這是實務上最常見的陷阱之一。
當兩筆事件的 event_id 相同，但 value（金額）不同時：

👉 Meta 不會合併或比對金額，只會單純丟棄重複事件。

🧩 七、前端／後端重送流程視覺化#

1
┌──────────────────────────────────────┐
2
│ 使用者完成付款 → GA4 觸發 purchase  │
3
└──────────────────────────────────────┘
4
              │
5
              ▼
6
   前端 (Browser Pixel)
7
   event_name: Purchase
8
   event_id: ORD98765_XYZ123
9
   value: 1999
10
              │
11
              ▼
12
     Meta 收到事件 #1 ✅
13

14
              ▲
15
              │
16
  Server 端 (CAPI webhook retry)
17
  event_name: Purchase
18
  event_id: ORD98765_XYZ123   ← 相同 ID
19
  value: 1999
20
              │
21
              ▼
22
   Meta 收到事件 #2 → ⚙️ Dedup
23
   → 只保留第一筆，第二筆捨棄

若第二筆 event_id 改成 ORD98765_XYZ124：
Meta 就會當成「第二筆新購買」➡️ 導致重複統計。

✅ 八、最佳實務建議#

✅ 一筆訂單 = 一個 event_id
重送、重發都要用同一個 ID。

🧭 九、實作建議流程#

1. 前端結帳 → 產生 event_id 並寫入 dataLayer
2. 將 event_id 帶入 GA4 purchase 事件
3. Server 端在 webhook 或 CAPI 事件中使用同一 event_id
4. 確認 Meta Events Manager Test Events 中，Browser 與 Server 事件的 event_id 完全一致
5. 驗證 dedup 成功（CAPI 事件會顯示 deduplicated 狀態）

🧩 十、總結#

• event_id 是 Meta 去重的唯一依據
• order_id 只是業務邏輯，不參與 dedup
• 若 event_id 不同，Meta 會當成新事件
• 若相同但內容不同，Meta 會只保留第一筆
• 最佳實務：前後端共用 event_id，一筆訂單一個 ID

這樣設計能確保：

• 廣告轉換不重複計算
• CAPI 與 Pixel 一致化
• 後續資料分析與 ROAS 更準確

參考資源

Meta Pixel Tracking using GTM & GA4 Data Layer

Meta Conversions API Official Docs