Meta Ads / / 13 min

Facebook 轉換 API 設定:Cookie 失效時代的追蹤方案

從原理到實作,教你設定 Facebook 轉換 API(CAPI),在第三方 Cookie 失效的時代維持精準的廣告追蹤。

目錄

你的追蹤數據正在消失

如果你最近有在看 Facebook 廣告的成效報表,你可能發現了一件奇怪的事:轉換數字越來越不準了。

明明後台有 50 筆訂單,但 Facebook 廣告管理員只回報了 30 筆。漏掉的 20 筆去哪了?

這不是 Facebook 的 bug,這是整個數位廣告產業正在經歷的結構性變化。第三方 Cookie 正在死掉,而 Facebook Pixel 大量依賴 Cookie 來追蹤使用者行為。

Apple 的 iOS 14.5 開始要求 App 必須取得用戶同意才能追蹤(ATT 政策),大部分人選了「不要追蹤」。各大瀏覽器也陸續封鎖第三方 Cookie——Safari 早就封了,Firefox 也封了,Chrome 也在收緊。

結果就是 Facebook Pixel 能追蹤到的事件越來越少。追蹤不到就代表數據不準,數據不準就代表演算法沒辦法有效優化,最終你的廣告成本就會上升。

這時候就需要轉換 API(Conversions API,簡稱 CAPI)。

轉換 API 是什麼:用大白話解釋

傳統的 Facebook Pixel 是這樣運作的:使用者在你的網站上做了某個動作(比如完成購買),Pixel 的 JavaScript 程式碼會在使用者的瀏覽器裡觸發,然後從瀏覽器把這個事件資料傳送給 Facebook。

問題出在哪?中間的通道被堵住了。

瀏覽器封鎖第三方 Cookie、廣告阻擋器攔截追蹤腳本、iOS 的 ATT 政策限制追蹤——這些都是堵在瀏覽器端的障礙。Pixel 的資料從瀏覽器出發,但走不到 Facebook。

轉換 API 的做法不同。它不從瀏覽器發送資料,而是從你的伺服器直接發送。

使用者完成購買 → 你的伺服器處理訂單 → 你的伺服器把轉換資料直接傳給 Facebook 的伺服器。

整個過程不經過瀏覽器,所以瀏覽器端的限制完全影響不了它。不管使用者裝了什麼廣告阻擋器、用什麼瀏覽器、有沒有同意追蹤,你的伺服器都能把資料送出去。

簡單來說:Pixel 走前門(瀏覽器),CAPI 走後門(伺服器)。前門被堵了,後門還通。

最理想的做法是兩個都用——Pixel 和 CAPI 同時運作,能追蹤到的事件數量最多。Facebook 會自動做除重處理,不會重複計算同一個事件。

Facebook Pixel 與轉換 API 的資料傳輸路徑對比圖

設定前的準備工作

在開始設定 CAPI 之前,有幾件事要先確認:

1. 確認 Facebook Pixel 已正確安裝

CAPI 不是要取代 Pixel,而是要跟 Pixel 搭配使用。如果你還沒裝 Pixel,先去設定 Facebook Pixel

2. 確認你有 Business Manager 的管理員權限

CAPI 的設定需要在 Meta Business Suite 裡操作,你需要有 Pixel 所屬的 Business Manager 的管理員權限。

3. 決定要追蹤哪些事件

CAPI 可以傳送的事件種類跟 Pixel 一樣:PageView、ViewContent、AddToCart、Purchase、Lead、CompleteRegistration 等等。

你不需要把所有事件都透過 CAPI 傳送。優先處理對你最重要的轉換事件——通常是 Purchase(購買)和 Lead(留下聯絡資訊)。這些是你用來衡量廣告 ROI 的關鍵事件,也是演算法優化的依據。

4. 了解你的技術環境

CAPI 的設定方式取決於你的網站是怎麼建的:

  • Shopify / WooCommerce / 其他電商平台:大部分都有內建的 CAPI 整合,設定最簡單
  • WordPress:可以用外掛(像是 PixelYourSite)來設定
  • 自建網站:需要寫程式碼呼叫 Facebook 的 API
  • Google Tag Manager:可以用 GTM 的 Server-Side Tagging 來實作

最簡單的設定方式:合作夥伴整合

如果你用的是 Shopify、WooCommerce、Magento 等主流電商平台,設定 CAPI 可以不用寫任何程式碼。

Shopify 的設定步驟:

  1. 進入 Shopify 後台 → 設定 → 應用程式和銷售管道
  2. 找到 Facebook & Instagram 這個銷售管道(沒有的話先安裝)
  3. 連接你的 Facebook Business Manager 和 Pixel
  4. Shopify 會自動啟用 CAPI,把購買、加入購物車等事件透過伺服器端傳送

就這樣。Shopify 的整合已經處理了事件對應、參數傳遞和除重邏輯,你不需要做額外的設定。

WooCommerce 的設定步驟:

  1. 安裝 Facebook for WooCommerce 官方外掛
  2. 在外掛設定裡連接你的 Facebook Business Manager
  3. 外掛會自動處理 Pixel 和 CAPI 的設定

如果你想要更多的控制權,可以用 PixelYourSite Pro 這類第三方外掛,它可以讓你自訂要透過 CAPI 傳送哪些事件、傳送哪些參數。

用 Meta 的事件管理工具檢查設定是否成功:

設定完之後,進入 Meta Business Suite → 事件管理工具 → 選擇你的 Pixel。在事件列表裡,每個事件旁邊會顯示它的來源:

  • 「瀏覽器」= 從 Pixel 來的
  • 「伺服器」= 從 CAPI 來的

如果你看到某個事件同時有瀏覽器和伺服器兩個來源,代表 Pixel 和 CAPI 都在正常運作。

進階設定:自己呼叫 API

如果你的網站是自建的,或者你需要更精細的控制,就需要自己寫程式碼來呼叫 Facebook 的 Conversions API。

基本流程:

  1. 在 Meta Business Suite 裡產生一個 Access Token
  2. 當轉換事件發生時(例如使用者完成購買),從你的伺服器端發送一個 HTTP POST 請求到 Facebook 的 Graph API
  3. 請求裡包含事件名稱、事件時間、使用者資料(經過雜湊處理)和其他參數

API 端點:

POST https://graph.facebook.com/v21.0/{pixel_id}/events

請求內容的關鍵欄位:

  • event_name:事件名稱,例如 Purchase、Lead
  • event_time:事件發生的 Unix 時間戳記
  • action_source:資料來源,設定為 website
  • event_source_url:事件發生的頁面網址
  • user_data:使用者資料(Email、電話、IP 等),用於比對 Facebook 用戶
  • custom_data:自訂資料(訂單金額、商品 ID 等)

使用者資料的雜湊(Hashing):

傳送使用者資料給 Facebook 之前,Email 和電話號碼必須先用 SHA-256 雜湊處理。你不是把使用者的原始 Email 傳給 Facebook,而是傳一個雜湊值。Facebook 用同樣的方式雜湊他們的用戶資料,然後比對雜湊值來找到對應的用戶。

這麼做的原因是隱私保護——Facebook 不會拿到你用戶的原始個人資料。

注意:IP 位址和 User Agent 不需要雜湊,直接傳送。

事件比對品質:決定追蹤準確度的關鍵

CAPI 傳送的事件能不能被 Facebook 正確歸因到對應的廣告,取決於「事件比對品質」(Event Match Quality,簡稱 EMQ)。

在事件管理工具裡,每個透過 CAPI 傳送的事件都有一個 EMQ 分數,從 1 到 10 分。分數越高,代表 Facebook 越容易把這個事件比對到正確的 Facebook 用戶。

影響 EMQ 的因素:

  • Email:最重要的比對參數。如果你能傳送使用者的 Email(雜湊後),EMQ 會大幅提升
  • 電話號碼:第二重要的比對參數
  • fbclid / fbc:Facebook Click ID,使用者從 Facebook 廣告點進來時 URL 裡會帶的參數。如果你能擷取這個參數並透過 CAPI 傳回去,比對率非常高
  • fbp:Facebook Browser ID,Pixel 存在 Cookie 裡的識別碼。如果你能從 Cookie 裡讀取並傳送,也能提高比對率
  • IP 位址和 User Agent:輔助比對參數,單獨使用效果有限,但跟其他參數搭配可以提高準確度

提升 EMQ 的實用建議:

  1. 一定要傳 Email——大部分的轉換事件(購買、填表單)都能拿到使用者的 Email
  2. 從 URL 擷取 fbclid 參數,儲存在你的伺服器端(例如存在 Session 裡),在觸發事件時傳回去
  3. 從 Cookie 讀取 _fbp 值並傳送
  4. 傳送使用者的 IP 位址和 User Agent(從 HTTP Request Header 取得)

理想的 EMQ 分數是 7 分以上。如果低於 5 分,代表你傳送的參數不夠,Facebook 很難把事件比對到正確的用戶,追蹤的效果會打折扣。

轉換 API 事件比對品質的影響因素與提升方法

除重機制:避免重複計算

如果你同時使用 Pixel 和 CAPI,同一個轉換事件會被傳送兩次——一次從瀏覽器(Pixel),一次從伺服器(CAPI)。Facebook 需要知道這兩筆是同一個事件,才不會重複計算。

除重的關鍵是 event_id

在 Pixel 端觸發事件的時候,給這個事件一個唯一的 ID。在 CAPI 端傳送同一個事件的時候,使用同一個 ID。Facebook 收到兩筆有相同 event_id 的事件時,會知道這是同一個事件,只計算一次。

如果你不設定 event_id,Facebook 還是會嘗試用時間和使用者資料來做除重,但準確度會差很多。可能出現漏算(把兩個不同的事件當成同一個)或多算(把同一個事件當成兩個)。

event_id 的生成方式:

最簡單的做法是用訂單編號。每一筆訂單有一個唯一的編號,在 Pixel 和 CAPI 都傳送這個編號作為 event_id,Facebook 就能正確除重。

如果是非交易類的事件(例如 Lead),可以用時間戳記 + 使用者 Email 的組合來產生唯一 ID。

實作上的注意事項:

  • Pixel 端用 fbq('track', 'Purchase', {value: 100, currency: 'TWD'}, {eventID: 'order_12345'}) 來傳送 event_id
  • CAPI 端在 API 請求的 event_id 欄位填入同樣的 order_12345
  • 兩邊的 event_name 也必須一致(都是 Purchase

設定完之後的驗證

CAPI 設定完之後,你需要驗證它是否正常運作。不要設定完就放著不管,追蹤出了問題你可能要幾週之後才會從廣告成效的數字裡發現。

驗證步驟:

1. 用事件管理工具的測試事件功能

在 Meta Business Suite → 事件管理工具 → 你的 Pixel → 測試事件。這個功能可以即時顯示接收到的事件,包括來源(瀏覽器或伺服器)、參數和比對狀態。

打開測試事件頁面,然後去你的網站上觸發一個轉換事件(例如完成一筆測試訂單)。在測試事件頁面裡應該要看到兩筆事件——一筆來自瀏覽器、一筆來自伺服器,而且兩筆的 event_id 相同。

2. 檢查 EMQ 分數

在事件管理工具的事件列表裡,點擊某個透過 CAPI 傳送的事件,可以看到它的 EMQ 分數。如果低於 5 分,回去檢查你傳送的使用者資料參數是否足夠。

3. 檢查除重是否正常

在事件管理工具裡看事件的總數量。如果 Pixel 和 CAPI 同時運作,但事件數量是你預期的兩倍,代表除重沒有成功。回去檢查 event_id 的設定。

4. 比對後台數據

把 Facebook 回報的轉換數字跟你自己後台的數字做比對。差距在 10-15% 以內是正常的(因為不是所有事件都能成功比對)。如果差距超過 30%,就需要調查原因。

常見問題和解決方法

事件管理工具裡看不到伺服器端的事件

檢查你的 Access Token 是否正確、API 版本是否正確、Pixel ID 是否正確。用 Postman 或 curl 手動發送一個測試請求,看看 API 的回應。

EMQ 分數很低

最常見的原因是沒有傳 Email 或沒有傳 fbclid。確保你在伺服器端能拿到這些參數,並正確地傳送給 Facebook。

事件數量異常(太多或太少)

太多:除重沒有正確設定,同一個事件被計算了兩次。檢查 event_id。 太少:CAPI 的請求沒有成功送出。檢查伺服器的 Log,看有沒有 API 錯誤。

轉換歸因視窗的問題

CAPI 傳送的事件時間以 event_time 為準,不是 API 請求的時間。如果你延遲了幾天才傳送事件,要確保 event_time 填的是事件實際發生的時間,不是你傳送的時間。Facebook 最多接受 7 天前的事件。

不設定的代價

如果你到現在還沒有設定轉換 API,你正在承受的代價可能比你想像的大。

沒有 CAPI 代表你的追蹤只靠 Pixel,而 Pixel 能追蹤到的事件大約只有實際發生的 60-70%(在 iOS 用戶為主的市場裡可能更低)。這意味著:

  • Facebook 的演算法只看到 60-70% 的轉換數據,優化的依據不完整,廣告成本會更高
  • 你的受眾名單不完整,再行銷的觸及會少掉一大塊
  • 你看到的 ROAS 數字比實際低,可能因此做出錯誤的投放決策(砍掉其實在賺錢的廣告組合)

設定 CAPI 不是什麼可選的進階功能,在 2026 年,它是Facebook 廣告投放的基本配備。

如果你需要專業的網站架設與技術支援來處理 CAPI 的技術設定,從伺服器端的 API 串接到事件除重邏輯,專業的技術團隊可以確保你的追蹤設定正確無誤,讓每一筆轉換都被精準記錄。

轉換 API 設定驗證清單:從測試事件到數據比對