Meta Conversions API (CAPI) 完全設定教學：從 Pixel 到伺服器端追蹤

TL;DR：Meta Conversions API（CAPI）是將轉換事件從伺服器端直接傳送到 Meta 伺服器的追蹤機制，繞過瀏覽器的所有限制。在 2026 年，僅靠 Pixel 的廣告主正在流失 20% 至 40% 的轉換數據。本文涵蓋 CAPI 的完整架構選擇、GTM↗ Server-Side 設定步驟、Stape 部署、標準事件映射、EMQ 分數優化、重複事件去重，以及 iGaming 產業特有的追蹤挑戰與實戰除錯方法。無論你是第一次接觸伺服器端追蹤，還是正在從純 Pixel 架構遷移，這份指南都能讓你從零建立生產級的 CAPI 追蹤系統。

Pixel 與 CAPI 的根本差異：瀏覽器端 vs 伺服器端

Quick Answer：Meta Pixel 透過瀏覽器 JavaScript 發送事件，受制於 cookie 限制、廣告攔截器和 iOS ATT 框架；CAPI 則從你的伺服器直接呼叫 Meta API，完全繞過這些瀏覽器端的障礙，確保轉換信號不會遺失。

Pixel 的運作原理與瓶頸

Meta Pixel 是一段嵌入在網頁中的 JavaScript 程式碼。當使用者觸發特定行為（如頁面瀏覽、點擊註冊按鈕、完成購買），Pixel 會在瀏覽器中觸發，將事件資料以 HTTP 請求傳送到 Meta 的 facebook.com/tr/ 端點。這個機制在 2018 年以前運作良好，但現在面臨系統性的衰退。

第一個問題是 cookie 限制。Safari 的 Intelligent Tracking Prevention（ITP）將第三方 cookie 壽命限制為 7 天，第一方 cookie（透過 JavaScript 設定的）也被壓縮到 7 天。這意味著使用者如果在點擊廣告 8 天後才完成轉換，Pixel 完全無法將這次轉換歸因到原始廣告點擊。Firefox 的 Enhanced Tracking Protection 和 Chrome 的 Privacy Sandbox 也在逐步實施類似限制。

第二個問題是廣告攔截器。根據 2026 年的數據，全球約有 32% 的桌面使用者安裝了廣告攔截器，其中大部分會直接阻擋對 facebook.com/tr/ 端點的請求。在某些技術受眾的網站上，這個比例甚至高達 50% 以上。被攔截的事件對 Meta 而言完全不存在。

第三個問題是 iOS 14+ 的 App Tracking Transparency（ATT）框架。自 iOS 14.5 起，App 必須徵得使用者明確同意才能追蹤跨應用行為。根據 Flurry Analytics 的數據，全球約 75% 的 iOS 使用者選擇「不要追蹤」。雖然 ATT 主要影響 App 內追蹤，但其引發的整體隱私趨勢也加速了瀏覽器端追蹤的衰退。

CAPI 如何解決這些問題

CAPI 的核心概念是將事件傳送的責任從使用者的瀏覽器轉移到你自己的伺服器。當使用者在你的網站上完成轉換行為時，你的後端伺服器直接透過 HTTPS POST 請求呼叫 Meta 的 Conversions API 端點（graph.facebook.com/v21.0/{pixel_id}/events），將事件資料傳送給 Meta。

這個架構從根本上繞過了上述所有瀏覽器端的限制。廣告攔截器無法阻擋你伺服器到 Meta 伺服器之間的通訊，因為這個請求根本不經過使用者的瀏覽器。Cookie 限制也不再是瓶頸，因為你可以在伺服器端保存使用者的識別資訊（如 email hash、電話 hash），這些資料不受瀏覽器 cookie 政策影響。

然而，CAPI 並不是要取代 Pixel，而是與 Pixel 互補。最佳實踐是同時運行 Pixel 和 CAPI（所謂的 dual-fire 架構），讓 Meta 透過 event_id 去重機制自動合併重複事件，同時確保無論哪一端失敗，至少有一條路徑能把轉換信號送到 Meta。

如果你想深入了解瀏覽器端與伺服器端追蹤的差異，可以參考我們的 Client vs Server Tracking 完整比較。

CAPI 架構選擇：四種實作路徑

Quick Answer：最常見的四種 CAPI 實作方式為 GTM Server-Side Container、Cloud Functions 自建、Stape 託管服務、手動 API 直接呼叫。對大多數廣告主而言，GTM Server-Side 搭配 Stape 託管是效能與維護成本的最佳平衡點。

方式一：GTM Server-Side Container

Google Tag Manager 的 Server-Side Container 是目前最主流的 CAPI 實作方式。它在你的伺服器上運行一個 GTM 容器，接收來自網頁端 GTM（Web Container）的事件，然後透過 Meta CAPI Tag 轉發到 Meta 伺服器。

優點在於不需要寫程式碼，事件映射和參數設定都可以在 GTM 的視覺化界面中完成。同時支援多個平台（Meta、Google Ads↗、TikTok 等）共用同一個 Server-Side Container，降低維護成本。

缺點是需要一台專門的伺服器來運行 Server Container，有基礎設施成本。Google Cloud Platform 提供免費的 App Engine 額度可以入門，但流量大時需要付費。

方式二：Cloud Functions 自建

使用 Google Cloud Functions、AWS Lambda 或 Azure Functions 直接撰寫程式碼呼叫 Meta Conversions API。這種方式提供最大的彈性，你可以完全控制事件處理邏輯、資料轉換和錯誤處理。

適合有工程團隊的公司，或是需要複雜事件處理邏輯的場景（例如將後端 CRM 事件發送到 Meta）。缺點是需要撰寫和維護程式碼，且每個平台需要獨立的整合邏輯。

方式三：Stape 託管服務

Stape 是一個 GTM Server-Side Container 的託管服務供應商。它不是一個獨立的追蹤系統，而是幫你管理 GTM Server-Side Container 的基礎設施。你在 Stape 上建立一個 Server Container，Stape 負責伺服器的部署、擴展、SSL 憑證和監控。

Stape 的核心價值在於免除了自行管理 GCP App Engine 或 Cloud Run 的複雜性。起價約每月 $20 美元（包含合理流量），對中小型廣告主而言是最具成本效益的選擇。設定流程與標準 GTM Server-Side 完全相同，只是底層基礎設施由 Stape 託管。

方式四：手動 API 直接呼叫

直接用 curl 或後端程式碼呼叫 Meta Conversions API 端點。這是最底層的方式，適合需要從非 Web 環境（如客服系統、線下 POS、後台 CRM）發送離線轉換事件的場景。

curl -X POST \
  "https://graph.facebook.com/v21.0/{PIXEL_ID}/events" \
  -H "Content-Type: application/json" \
  -d '{
    "data": [{
      "event_name": "Lead",
      "event_time": 1719273600,
      "event_id": "event_abc123",
      "action_source": "website",
      "event_source_url": "https://example.com/register",
      "user_data": {
        "em": ["a1b2c3d4e5f6..."],
        "fbc": "fb.1.1719273000.ABCxyz123",
        "fbp": "fb.1.1719200000.987654321"
      }
    }],
    "access_token": "YOUR_ACCESS_TOKEN"
  }'

無論選擇哪種架構，最終的目標都是將事件資料以 Meta 規定的格式送到 Conversions API 端點。差別僅在於「由誰負責組裝和傳送這個請求」。

GTM Server-Side Container 設定步驟

Quick Answer：設定 GTM Server-Side Container 需要五個核心步驟：建立 Server Container、部署到 Stape 或 GCP、設定 Web Container 的 transport_url、建立 Meta CAPI Tag、設定觸發條件與變數映射。以下逐步說明。

步驟一：建立 GTM Server-Side Container

在 Google Tag Manager 中建立新的容器，類型選擇「Server」。建立後你會取得一個 Container Config 字串，這是部署到伺服器時需要的金鑰。

記住：Web Container 和 Server Container 是兩個完全獨立的容器。Web Container 運行在使用者瀏覽器中，Server Container 運行在你的伺服器上。事件從 Web Container 發送到 Server Container，再由 Server Container 轉發到各個平台的 API。

步驟二：部署 Server Container

如果使用 Stape，在 Stape 後台建立新的 Server Container，貼上 Container Config 字串，選擇地區（建議選擇靠近目標受眾的地區以降低延遲），Stape 會自動完成部署。部署完成後你會取得一個自訂域名，例如 sgtm.yourdomain.com。

如果自行部署到 GCP，使用 App Engine 或 Cloud Run 部署 GTM 官方提供的 Docker 映像，將 Container Config 設為環境變數。建議設定自訂域名並配置 SSL 憑證，確保數據傳輸的安全性。

步驟三：設定 Web Container 的 transport_url

在 Web Container 的 Google Tag（GA4 Config Tag 或 Meta Pixel Tag）中，將 transport_url 或 server_container_url 設定為你的 Server Container 域名。這告訴 Web Container 將事件發送到你的 Server Container，而不是直接發到 Google 或 Meta。

這裡有一個關鍵的陷阱：如果你設定了 server_container_url，但 Server Container 中沒有建立對應的 forwarding tag，事件會死在 Server Container 裡。你的 GA4 數據會出現「有人數但沒有頁面瀏覽」的詭異現象。務必確認 Server Container 中至少有一個 GA4 Tag 負責將事件轉發到 Google Analytics↗。

步驟四：建立 Meta CAPI Tag

在 Server Container 中，從 Community Template Gallery 安裝「Facebook Conversions API」Tag。這個 Tag 需要以下設定：

API Access Token：從 Meta Events Manager 的「設定」頁面產生。這是長效 token，不需要頻繁更新。
Pixel ID：你的 Meta Pixel 識別碼。
Action Source：設定為 website（除非你在追蹤 App 或離線事件）。
Test Event Code（可選）：用於除錯階段，讓事件出現在 Events Manager 的 Test Events 面板。

步驟五：設定觸發條件與變數映射

為 CAPI Tag 設定觸發條件，決定哪些事件應該被轉發到 Meta。最基本的配置是為每一個你想追蹤的標準事件建立一個觸發條件。例如：當事件名稱為 generate_lead 時觸發，並在 Tag 中將 event_name 映射為 Meta 的標準事件 Lead。

變數映射是 CAPI 設定中最容易出錯的環節。你需要確保 Web Container 傳送過來的事件包含所有必要的 user_data 欄位（fbclid、fbc、fbp、email 等），並且在 Server Container 的 Tag 中正確映射到 Meta Conversions API 期望的欄位名稱。

更多關於跨平台追蹤設定的實作技巧，可以參考我們的跨平台追蹤整合指南。

事件設定：標準事件與自訂事件

Quick Answer：Meta 優先推薦使用標準事件（如 PageView、Lead、CompleteRegistration、Purchase），因為標準事件可以觸發 Meta 的自動最佳化演算法。自訂事件雖然彈性高，但無法作為廣告最佳化目標，應僅在標準事件不適用時使用。

Meta 標準事件清單

Meta 定義了數十個標準事件，以下是最常用的核心事件：

PageView：頁面瀏覽。每次頁面載入自動觸發，是最基礎的事件。
ViewContent：內容瀏覽。使用者查看特定產品或內容頁面時觸發。
Lead：潛在客戶。使用者提交表單、註冊帳號或表達興趣時觸發。
CompleteRegistration：完成註冊。使用者完成註冊流程時觸發。
AddToCart：加入購物車。電商場景中使用者將商品加入購物車。
Purchase：完成購買。包含 value 和 currency 參數，是衡量 ROAS 的核心事件。

event_name 映射的關鍵原則

在 GTM Server-Side 架構中，Web Container 發送的事件名稱通常遵循 GA4 的命名慣例（如 generate_lead、sign_up），而 Meta CAPI 期望的是 Meta 自己的標準事件名稱（如 Lead、CompleteRegistration）。Server Container 的 CAPI Tag 負責這個映射轉換。

一個極為常見的陷阱是 objective 與 pixel event 的不對應。如果你的 Meta 廣告↗ campaign 設定的目標是 OUTCOME_LEADS（潛在客戶轉換），那麼你的 CAPI 必須發送 Lead 事件，而不是 CompleteRegistration 或自訂事件。目標與事件不對應會導致 Meta 的演算法優化錯誤的行為，嚴重影響廣告成效。

自訂事件的使用時機

當你需要追蹤的行為不在標準事件清單中時，可以使用自訂事件。例如 click_cta、watch_video_50pct、scroll_to_bottom 等。自訂事件會出現在 Events Manager 中，可以用來建立自訂受眾，但無法作為廣告組的轉換最佳化目標。

實務建議：儘可能將業務行為對應到標準事件。例如「使用者點擊 CTA 按鈕跳轉到合作方網站」可以合理地映射為 Lead 事件，而不需要用自訂事件。

EMQ 分數提升方法

Quick Answer：Event Match Quality（EMQ）衡量你傳送到 Meta 的事件中包含多少可用於身份配對的使用者資訊。分數範圍 1-10，建議目標 7 以上。影響 EMQ 的因素按權重排序為：email > phone > fbc > fbp > external_id。提高 EMQ 的核心策略是在每個事件中傳送盡可能多的 user_data 欄位。

EMQ 是什麼，為什麼重要

EMQ（Event Match Quality）是 Meta 在 Events Manager 中顯示的評分指標，反映每個事件中包含的使用者識別資訊品質。Meta 需要這些資訊將伺服器端收到的事件匹配到正確的 Facebook/Instagram 使用者。

EMQ 分數直接影響廣告最佳化效率。高 EMQ 代表 Meta 能更準確地將轉換歸因到正確的廣告點擊，這讓機器學習模型能更快完成學習期，最終降低你的 CPA。

user_data 欄位與權重

以下是 Meta Conversions API 接受的 user_data 欄位，按對 EMQ 的影響權重排序：

高權重欄位：

em（email）：使用者的 email 地址，必須經過 SHA-256 hash。這是 EMQ 影響最大的欄位，因為 Meta 的使用者幾乎都綁定了 email。
ph（phone）：使用者的電話號碼，需含國碼，經過 SHA-256 hash。

中權重欄位：

fbc（Facebook Click ID Cookie）：記錄使用者點擊廣告時的 fbclid 參數。格式為 fb.1.{timestamp}.{fbclid}，其中 {timestamp} 是使用者首次到達網站的 Unix 時間戳，{fbclid} 是 URL 中的 fbclid 查詢參數值。fbc 是連結「廣告點擊」和「轉換事件」的關鍵橋梁。
fbp（Facebook Browser ID Cookie）：Meta Pixel 自動設定的第一方 cookie，格式為 fb.1.{timestamp}.{random}，其中 {timestamp} 是 cookie 建立時的 Unix 時間戳，{random} 是隨機產生的數字。fbp 用於識別同一瀏覽器上的同一使用者。

基礎權重欄位：

external_id：你系統中的使用者 ID（如 CRM ID、會員編號），經過 SHA-256 hash。
client_ip_address：使用者的 IP 位址（不需要 hash）。
client_user_agent：使用者的瀏覽器 User-Agent 字串。

fbc 和 fbp 的實作細節

fbc 的正確實作方式是：當使用者透過 Meta 廣告到達你的網站時，URL 中會帶有 fbclid 查詢參數。你需要在使用者首次到達時捕捉這個 fbclid，並組裝成 fb.1.{當前Unix時間戳}.{fbclid值} 的格式，存入名為 _fbc 的第一方 cookie 中。

這裡有一個關鍵的實作要點：fbc 的時間戳必須在第一次擷取時凍結，之後無論使用者何時回訪，都應該回傳同一個 fbc 值。如果每次都用當前時間戳重新產生 fbc，Meta 會視為不同的點擊，降低配對準確度。建議同時將 fbc 寫入 cookie 和 localStorage，防止 cookie 過期後遺失。

fbp 通常由 Meta Pixel 自動設定在 _fbp cookie 中。如果你的網站安裝了 Pixel，直接讀取這個 cookie 值傳入 CAPI 即可。如果沒有安裝 Pixel，你也可以自行產生 fbp，格式為 fb.1.{當前Unix時間戳}.{10位隨機數字}。

實戰 EMQ 優化清單

以下是提升 EMQ 分數的具體行動清單，按優先順序排列：

確保每個事件都帶有 fbc（從 _fbc cookie 讀取）和 fbp（從 _fbp cookie 讀取）。這兩個欄位不需要使用者主動提供任何資訊，應該在所有事件中都存在。
在 Lead 和 CompleteRegistration 事件中傳送 hash 過的 email 和 phone。使用者提交表單時已經提供了這些資訊，利用它們是合法的。
傳送 client_ip_address 和 client_user_agent。在 Server Container 中這些資訊通常自動可用。
如果使用者已登入，傳送 external_id（你的系統 User ID，hash 後）。
所有 hash 使用 SHA-256，並在 hash 前先做小寫轉換和去除首尾空白。

除錯工具：從測試到生產驗證

Quick Answer：Meta 提供三層除錯工具：Events Manager 的 Test Events 面板（即時查看測試事件）、Payload Helper（驗證 API 請求格式）、以及直接用 curl 發送測試事件。三者搭配使用可以快速定位 CAPI 問題。

Events Manager Test Events

在 Meta Events Manager 中，選擇你的 Pixel，進入「Test Events」分頁。這裡會顯示過去 24 小時內透過 CAPI 發送的帶有 test_event_code 的事件。

使用方式：在你的 CAPI Tag 或 API 請求中加入 test_event_code 參數（值為 Events Manager 顯示的測試碼，例如 TEST12345），然後在網站上觸發事件，即可在 Test Events 面板即時看到事件是否成功送達、參數是否正確、EMQ 分數如何。

Test Events 的關鍵價值在於它顯示的是「Meta 實際收到了什麼」，而不是「你以為你發了什麼」。常見的除錯發現包括：event_name 拼寫錯誤、user_data 欄位格式不正確、fbc/fbp 值為空等。

Payload Helper

Meta 提供了一個線上工具 Payload Helper↗，可以幫你建構和驗證 CAPI 請求的 JSON payload。你可以在視覺化界面中選擇事件類型、填入參數，它會自動產生格式正確的 JSON，你可以直接用於 API 請求或對照你自己的實作。

curl 驗證

在完全排除 GTM 和 Server Container 的變數之後，直接用 curl 發送測試事件是最快的驗證方式：

curl -X POST \
  "https://graph.facebook.com/v21.0/{PIXEL_ID}/events?access_token={TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "data": [{
      "event_name": "Lead",
      "event_time": 1719273600,
      "event_id": "test_curl_001",
      "action_source": "website",
      "event_source_url": "https://yourdomain.com/register",
      "user_data": {
        "client_ip_address": "1.2.3.4",
        "client_user_agent": "Mozilla/5.0",
        "fbc": "fb.1.1719273000.ABCxyz123",
        "fbp": "fb.1.1719200000.987654321"
      }
    }],
    "test_event_code": "TEST12345"
  }'

如果 curl 回傳 {"events_received": 1}，代表 Meta API 端點正常，問題出在你的 GTM/Server Container 配置。如果 curl 本身就失敗，檢查 access token 是否有效、Pixel ID 是否正確。

更完整的追蹤稽核流程，包含 Pixel、CAPI 和 GA4 的交叉驗證方法，請參考我們的廣告追蹤稽核清單。

重複事件去重：event_id 機制

Quick Answer：當 Pixel 和 CAPI 同時發送同一個轉換事件（dual-fire 架構），Meta 使用 event_id 去重。只要瀏覽器端 Pixel 事件和伺服器端 CAPI 事件帶有相同的 event_id 和 event_name，Meta 會自動將它們視為同一個事件，只計算一次。

為什麼去重至關重要

在 dual-fire 架構下，每個轉換行為會產生兩筆事件記錄：一筆來自瀏覽器端 Pixel，一筆來自伺服器端 CAPI。如果不做去重，Meta 會將它們視為兩次獨立的轉換，導致轉換數量虛增一倍，ROAS 數據嚴重失真，廣告組的最佳化方向也會被誤導。

event_id 的產生規則

event_id 必須是一個在合理時間範圍內唯一的字串。最簡單的方式是在瀏覽器端產生一個 UUID 或隨機字串，同時傳送給 Pixel 和 CAPI。

在 GTM 架構中，Web Container 在觸發事件時產生一個 event_id（例如使用 JavaScript 變數產生 Date.now() + '_' + Math.random().toString(36).substr(2, 9)），這個 event_id 會隨事件一起傳送到 Server Container。Web Container 的 Pixel Tag 使用這個 event_id 發送瀏覽器端事件，Server Container 的 CAPI Tag 也使用同一個 event_id 發送伺服器端事件。Meta 收到兩筆帶有相同 event_id + 相同 event_name 的事件後，自動去重，只計一次。

去重失敗的常見原因

去重失敗通常有三個原因。第一，Web Container 和 Server Container 使用了不同的 event_id 變數來源，導致兩邊的 event_id 不一致。第二，event_id 只在其中一端設定了，另一端遺漏。第三，event_name 不一致，例如 Pixel 端發送 Lead，CAPI 端發送 lead（大小寫不同），Meta 會視為兩個不同事件。

驗證去重是否正常運作，可以在 Events Manager 的 Overview 頁面查看事件的「Deduplication」狀態。如果出現「Potential duplicate events detected」警告，代表 Meta 偵測到重複事件但無法自動去重。

iGaming 的追蹤挑戰

Quick Answer：iGaming 產業面臨獨特的追蹤難題，包括 cookie 超短壽命（斗篷環境下的多次跳轉）、跨域導流（Landing Page 與遊戲平台不同域名）、iOS ATT 影響尤其嚴重（遊戲類 App 的 opt-in 率極低）、多帳號分散（帳號頻繁被封需要分散追蹤資產），CAPI 是解決這些問題的核心基礎設施。

斗篷環境與 cookie 損耗

iGaming 廣告通常使用斗篷（cloaking）架構，使用者的點擊路徑可能經過多個中間域名的跳轉才到達最終的 Landing Page。每一次跨域跳轉都可能導致 fbclid 遺失或 cookie 被清除。在某些激進的跳轉鏈中，使用者到達 Landing Page 時已經完全丟失了與原始廣告點擊的關聯。

CAPI 的解決方式是在第一個著陸點就捕捉 fbclid 並組裝成 fbc，透過 URL 參數或後端 session 在整個跳轉鏈中持續傳遞，最終在使用者完成轉換時由伺服器端發送包含正確 fbc 的事件給 Meta。這個流程完全不依賴 cookie 的存續。

跨域導流的追蹤斷裂

典型的 iGaming 漏斗是：使用者點擊廣告到達你的 Landing Page（例如 yourlp.com），然後點擊 CTA 跳轉到遊戲平台（例如 gamingsite.com）。這兩個域名完全獨立，Cookie 不互通，Pixel 追蹤在跨域時中斷。

CAPI 的解法有兩層。第一層，在 Landing Page 上透過 CAPI 發送 Lead 事件（使用者點擊 CTA 時觸發），這個事件包含完整的 fbc/fbp/user_data，可以被 Meta 歸因。第二層，如果需要追蹤到遊戲平台上的深層轉換（如首存、下注），則需要遊戲平台的後端配合，從後端直接呼叫 CAPI 發送 Purchase 或自訂事件。

iOS 14+ ATT 的放大效應

遊戲類應用的 ATT opt-in 率通常低於 15%，遠低於其他品類。這意味著透過 iOS 設備觸發的 Pixel 事件有極高的比例被限制或丟失。CAPI 雖然無法完全繞過 ATT（Meta 仍會根據使用者的隱私設定進行信號降級），但伺服器端發送的事件在歸因模型中的權重通常高於受限的瀏覽器端事件。

多帳號分散管理

iGaming 廣告帳號被封是常態，廣告主通常同時運營多個帳號，每個帳號可能綁定不同的 Pixel。這造成了追蹤資產的碎片化：同一批使用者的轉換數據分散在多個 Pixel 上，無法彙總分析。

在 CAPI 架構下，你可以透過統一的後端追蹤系統，根據 campaign 或 adset 的來源動態路由事件到正確的 Pixel。當某個帳號被封時，只需要更新路由規則，將新帳號的 Pixel ID 替換進去，不需要重新部署前端程式碼。

如果你想了解更多 iGaming 追蹤的具體實作案例，包括我們如何為客戶建立跨帳號的統一追蹤架構，可以閱讀我們英文版的 CAPI Setup Guide 中的進階章節。

常見問題 FAQ

CAPI 需要工程師才能設定嗎？

不一定。如果你選擇 GTM Server-Side + Stape 託管的路徑，整個設定流程可以在 GTM 的視覺化界面中完成，不需要撰寫任何程式碼。Stape 處理了底層伺服器的部署和維護。你需要的是理解事件映射邏輯和 user_data 欄位的意義，這更偏向追蹤策略而非程式開發。

然而，如果你需要將後端 CRM 事件（如客戶完成首次儲值）發送到 Meta，那就需要後端工程師配合，在對應的業務邏輯中插入 API 呼叫。

CAPI 可以完全取代 Pixel 嗎？

技術上可以，但不建議。Meta 官方建議同時使用 Pixel 和 CAPI（dual-fire 架構），透過 event_id 去重。原因有三：第一，Pixel 可以追蹤某些純前端行為（如頁面瀏覽、滾動深度）而無需後端介入。第二，Pixel 是某些 Meta 功能（如 Custom Audiences、Dynamic Ads）的先決條件。第三，dual-fire 提供冗餘，任何一端失敗另一端仍能保底。

EMQ 分數多少算合格？

Meta 官方建議 EMQ 至少達到 6.0 以上，但實務上 7.0 以上才能有效提升廣告最佳化效率。如果你的 EMQ 低於 5.0，代表你傳送的事件中嚴重缺乏使用者識別資訊，Meta 無法將大量轉換配對到正確的使用者，廣告的學習期會顯著延長。提升 EMQ 最有效的方式是確保每個事件都帶有 fbc、fbp，並在使用者提供 email 或電話的事件中加入 hash 後的 em 和 ph 欄位。

Stape 與自架 GCP Server Container 的差異？

功能上完全相同，差異在於基礎設施的管理方式。自架 GCP 需要你管理 App Engine/Cloud Run 實例、設定自動擴展、監控資源使用量、更新 SSL 憑證。Stape 將這些全部託管化，你只需要在 Stape 後台點幾下就完成部署。

成本方面，GCP 提供免費額度（每月約 28 個 App Engine 實例小時），低流量網站可能免費。但一旦流量超過免費額度，GCP 的計費模式較複雜，可能反而比 Stape 的固定月費更貴。Stape 起價約 $20/月，包含合理流量額度，計費可預測。

CAPI 事件延遲發送可以嗎？

可以，但有限制。Meta 接受 event_time 與實際 API 呼叫時間之間最多 7 天的延遲。這意味著你可以在使用者完成行為後的 7 天內補發事件。這對於需要等待後端確認的轉換行為（如儲值到帳、訂單確認）特別有用。

但請注意，延遲越長，事件在 Meta 歸因模型中的權重可能越低。最佳實踐是盡快發送事件，理想狀況下在使用者完成行為後的幾分鐘內。如果你使用 GTM Server-Side 架構，事件通常在使用者行為發生後的幾秒內就會送達 Meta。

關於 Meta Conversions API 的完整技術規格和 API 參考，請查閱 Meta 官方 CAPI 文件↗。如果你正在規劃從零建立追蹤系統或需要診斷現有追蹤的問題，也可以參考我們的追蹤服務頁面了解 RedClaw 能提供的技術支援。

🎯 需要專業團隊幫你建立 CAPI 追蹤系統？

從 Pixel 基礎設定、GTM Server-Side Container 部署、CAPI 事件映射到 EMQ 優化，RedClaw 的追蹤工程團隊已為多個產業的客戶完成生產級 CAPI 整合。我們熟悉 iGaming、Forex、Crypto 等灰色垂直產業的追蹤挑戰，能在帳號分散、斗篷環境、跨域導流等複雜場景下建立穩定的轉換追蹤管線。 → 了解我們的追蹤設定服務

Meta Conversions API (CAPI) 完全設定教學：從 Pixel 到伺服器端追蹤