Meta 轉換 API（CAPI）是什麼？像素數據變少怎麼辦、怎麼設定

Meta 轉換 API（Conversions API，簡稱 CAPI）是一種從「伺服器端」把網站上的轉換事件（例如購買、填表單）直接傳給 Meta 的追蹤方式，用來補強只靠瀏覽器端像素時漏掉的數據。當你發現廣告管理員裡的轉換數比後台實際訂單少很多，通常就是像素受到瀏覽器隱私限制、iOS 追蹤限制或廣告阻擋影響，這時搭配 CAPI 可以讓數據更完整，但它不是萬靈丹，也無法找回所有轉換。

重點摘要

像素在使用者的瀏覽器上執行，CAPI 則由你的伺服器或平台把事件傳給 Meta，兩者建議一起使用。
像素數據變少的常見原因包括瀏覽器隱私限制、iOS App Tracking Transparency 與廣告阻擋工具。
像素與 CAPI 同時傳送同一個事件時，需要用 event_id 做「去重複」，否則轉換會被重複計算。
事件比對品質（Event Match Quality）反映 Meta 能多準確地把事件對應到使用者，影響廣告最佳化效果。
導入方式可依技術資源選擇：電商平台內建整合、合作夥伴整合、GTM 伺服器端或自行開發。

像素和轉換 API 差在哪？

Meta 像素（Pixel）是一段安裝在網站上的程式碼，當訪客在瀏覽器裡瀏覽頁面、加入購物車、完成購買時，像素會從瀏覽器把這些行為傳回 Meta。轉換 API 則是換一條路：由你的網站伺服器、電商平台或追蹤伺服器，把同樣的事件資料直接傳給 Meta，不依賴訪客的瀏覽器。

比較項目	Meta 像素（瀏覽器端）	轉換 API（伺服器端）
資料從哪裡送出	訪客的瀏覽器	你的伺服器、電商平台或追蹤伺服器
受瀏覽器隱私限制影響	較大	較小
受廣告阻擋工具影響	可能被擋	通常不受影響
可傳送的資料	以瀏覽器行為為主	可加上後端資料，例如訂單狀態、雜湊後的顧客資訊
安裝難度	較低，貼碼或用 GTM 即可	較高，需要平台支援或技術資源
兩者並用時	需帶 event_id 供去重複	需帶相同的 event_id 供去重複

Meta 官方建議的做法是像素和轉換 API 一起使用，而不是二選一。像素可以掌握瀏覽器上的即時行為，CAPI 則補上被擋掉或漏掉的部分，兩邊互相備援。

為什麼 FB 像素數據不準、越來越少？

瀏覽器的隱私限制

近年各大瀏覽器陸續加強隱私保護，例如限制第三方 Cookie（網站用來記住訪客的小型檔案）、縮短 Cookie 的保存時間、阻擋跨網站追蹤。像素依賴這些機制辨識使用者，限制越多，能成功回傳並對應到使用者的事件就越少。

iOS App Tracking Transparency

Apple 從 iOS 14.5 開始推出 App Tracking Transparency（ATT，應用程式追蹤透明度），App 要追蹤使用者跨 App 和網站的行為前，必須先跳出視窗徵求同意。很多使用者選擇不允許追蹤，導致從 Facebook、Instagram App 點廣告進站的 iOS 使用者，其轉換數據回傳受到限制。這是「iOS 追蹤」議題最常被提到的來源。

廣告阻擋工具與其他因素

部分使用者安裝了廣告阻擋外掛或使用內建阻擋追蹤的瀏覽器，像素程式碼可能根本沒有載入。另外，網頁載入太慢、使用者在像素觸發前就關掉頁面、網站改版時把像素碼弄掉，也都會造成數據漏失。

CAPI 的好處與限制

導入 CAPI 的好處

補回部分被瀏覽器或阻擋工具擋掉的事件，讓報表更接近實際狀況。
系統拿到比較完整的轉換資料，廣告最佳化有更多依據。轉換數據不足也會影響學習階段，可以參考Meta 廣告學習階段是什麼。
可以傳送瀏覽器拿不到的後端資料，例如實際完成付款的訂單，而不只是「進到感謝頁」。

CAPI 不是萬靈丹

使用者拒絕追蹤或資料不足時，Meta 仍可能無法把事件對應到看過廣告的人，所以數據不會百分之百完整。
CAPI 改善的是「追蹤與歸因」，不會直接讓產品更好賣；如果素材、價格或落地頁有問題，成效一樣不會好。
導入需要技術資源與後續維護，設定錯誤（例如沒有去重複）反而會讓數據灌水。
傳送顧客資料前需要依規定處理，例如雜湊（把 email、電話轉成無法還原的亂碼再傳送），並注意個資與隱私相關規範。

事件重複是什麼？用 event_id 去重複

當像素和 CAPI 同時運作，同一筆購買可能會被瀏覽器送一次、伺服器再送一次。如果 Meta 無法判斷這兩筆其實是同一件事，報表上就會變成兩筆購買，轉換數和 ROAS（廣告投資報酬率）都會虛高。

「去重複」就是告訴 Meta：這兩筆是同一件事，只算一次。做法是讓兩邊在送出同一個事件時，帶上相同的事件名稱（例如都是 Purchase）和相同的 event_id（事件編號，例如訂單編號）。Meta 收到兩筆名稱與編號都相同的事件，就會合併成一筆。

可以想像成寄兩封內容一樣的掛號信，信封上寫著同一個單號，收件方看到單號一樣，就知道是同一份文件，不會重複登記。實務上最常見的錯誤，是像素和 CAPI 的 event_id 格式不一致，例如一邊用訂單編號、一邊用系統產生的亂數，結果去重複失效。

事件比對品質（Event Match Quality）是什麼？

事件比對品質（Event Match Quality，常簡稱 EMQ）是 Meta 在事件管理工具中提供的評分，用來表示你傳送的事件資料，能讓 Meta 多準確地對應到它平台上的使用者。分數越高，代表比對成功的機會越大，廣告歸因與最佳化通常也越準。

影響比對品質的關鍵，是事件附帶的「顧客資訊參數」，例如雜湊後的 email、電話、姓名，以及 Meta 自己的瀏覽器識別碼（fbp）與點擊識別碼（fbc）。在合乎隱私規範、使用者有提供資料的前提下，傳送越多且正確的參數，比對品質通常越好。分數只是參考指標，重點在於確認主要轉換事件有帶到足夠的識別資訊。

轉換 API 設定方式有哪些？

CAPI 不一定要自己寫程式。依照網站類型與技術資源，常見的導入方式如下：

導入方式	適合對象	優點	需要注意
電商平台內建整合	使用開店平台的品牌	設定最簡單，通常只要授權連結	可傳送的事件與參數受平台功能限制，是否支援以平台說明為準
合作夥伴整合	使用 WordPress 等常見架站系統	透過官方或第三方外掛完成，不需寫程式	外掛更新與相容性要定期確認
GTM 伺服器端	已經用 GTM 管理追蹤、想集中管理的團隊	彈性高，可同時處理 Meta、GA4 等多個平台	需要架設追蹤伺服器，有主機費用與設定門檻
自行開發	有工程團隊、自建網站或系統	完全客製，可傳送最完整的後端資料	開發與維護成本最高，要自行處理去重複與雜湊

各平台的設定畫面與步驟經常更新，實際操作建議以 Meta 與各平台的最新官方說明為準。如果網站已經有用 GTM（Google 代碼管理工具）管理追蹤，可以先參考GA4 關鍵事件怎麼設定，把事件規劃整理清楚，之後導入伺服器端追蹤也會比較順。

導入 CAPI 後怎麼檢查？

到 Meta 事件管理工具的「測試事件」功能，用測試代碼實際走一次網站流程（瀏覽、加入購物車、結帳），確認瀏覽器與伺服器兩邊的事件都有收到。
檢查同一事件是否標示為已去重複，確認像素與 CAPI 的事件名稱和 event_id 有對上。
查看主要轉換事件的事件比對品質，確認有帶到 email、電話或 fbp、fbc 等識別參數。
上線後觀察一段時間，把廣告管理員的轉換數與後台實際訂單比對，確認沒有明顯短少或重複灌水。
網站改版、更換外掛或平台時，重新做一次以上檢查，避免追蹤無聲無息地失效。

提醒：廣告管理員的轉換數本來就不會和後台訂單完全一致，因為歸因方式與時間範圍不同。檢查的重點是差距是否合理、是否穩定，而不是要求兩邊數字一模一樣。

常見問題

CAPI 是什麼？一定要裝嗎？

CAPI 是 Meta 的轉換 API，從伺服器端把轉換事件傳給 Meta。不是強制安裝，但如果你很依賴 Meta 廣告帶來轉換，搭配像素一起使用通常能讓數據更完整。

有了轉換 API 還需要像素嗎？

需要。Meta 官方建議像素與轉換 API 一起使用，兩者互相補位，再透過 event_id 去重複避免重複計算。

裝了 CAPI 之後，轉換數為什麼突然變兩倍？

很可能是去重複沒有設定成功，同一筆轉換被像素和 CAPI 各算一次。請檢查兩邊的事件名稱與 event_id 是否一致。

CAPI 能解決 iOS 追蹤限制嗎？

可以改善部分數據漏失，但無法完全解決。使用者拒絕追蹤時，Meta 仍可能無法把事件對應到看過廣告的人，所以數據不會百分之百完整。

事件比對品質分數低怎麼辦？

先確認主要轉換事件是否有傳送雜湊後的 email、電話，以及 fbp、fbc 等識別參數。在符合隱私規範的前提下補齊這些資訊，通常能提升比對品質。

結論

像素數據變少是瀏覽器隱私限制、iOS 追蹤限制與廣告阻擋共同造成的結果，Meta 轉換 API 是目前補強追蹤數據的主要做法之一。導入時記得像素與 CAPI 並用、用 event_id 去重複、留意事件比對品質，並在上線後實際比對數據。直白數位行銷提供 GTM 與追蹤設定服務，帳號數據對業主完全公開透明；如果你不確定網站適合哪種導入方式，或想檢查目前的追蹤是否正常，歡迎預約免費諮詢。