Meta 像素安裝不是把一段程式碼貼上網站就結束：先建立資料來源，再放置 Pixel 基礎程式，接著定義註冊、送出表單或完成付款等事件。
有伺服器資料時，可規劃另一條事件傳送路徑。Pixel 放在瀏覽器端，伺服器端則由後端整理事件；兩邊若要比對同一筆轉換，先記下 Pixel ID（資料來源 ID），再約定 event_name 與 event_id。
Meta Pixel 與 Conversions API 是什麼
Meta Pixel 是放在網站上的瀏覽器端程式。使用者載入頁面或完成動作時，Pixel 可依網站的事件設計送出資料；安裝前先列出要量測的動作與使用目的。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →Conversions API 的串接則由後端整理事件，再依帳戶設定送出。瀏覽器與伺服器若都記錄同一筆轉換，工程上要先讓兩邊使用同一個 event_id，並在報表中檢查是否重複。
兩條路徑各自有維護工作：瀏覽器端要檢查載入與觸發，伺服器端要檢查事件時機、資料欄位與請求紀錄。先決定要維護哪一條，再安排另一條的補強範圍。
網站有可靠的後端訂單或表單紀錄時，可讓兩邊使用同一筆業務紀錄產生 event_id。這樣排錯時能回到訂單或表單，而不是只比較兩個孤立的請求。
安裝前先決定要量什麼
先把商業動作寫成事件，不要先從程式碼開始。電商可把商品頁瀏覽、加入購物車、開始結帳與完成付款分開；服務型網站可把查看服務頁、送出表單與預約完成分開。每一個事件都要回答三件事：發生在哪個頁面、由哪個動作觸發、完成後要拿來看什麼。
事件名稱可參考 Facebook Node.js Business SDK README 的 .setEventName('Purchase') 範例。README 也寫明 SDK 是「server-side client for the Conversions API」；這是程式庫用法示例，不是事件分類定義。
付款事件還要保留訂單金額、幣別與訂單識別資訊，讓後續報表能分辨「有買」與「買了多少」。這些欄位應從實際結帳資料產生，不要由前端輸入框直接決定。
若網站已使用 Google Tag Manager，可把 Pixel 基礎程式與事件觸發集中管理；若是電商平台或表單服務，先確認平台原生整合會送哪些事件，再決定是否補碼。重複安裝同一個 Pixel，會讓同一頁產生重複事件，排錯時也會把問題拆得更複雜。
Meta Pixel 設定步驟
第一步：建立資料來源。在 Meta 的事件管理工具建立或選取網站資料來源，記下 Pixel ID。名稱可以用網站或品牌識別，但不要在多個網站共用一個無法分辨的事件架構。
第二步：安裝基礎程式。把官方產生的 Pixel 基礎程式放到網站每一頁都會載入的位置。若使用 Tag Manager，讓標籤在所有需要量測的頁面觸發；若直接改網站範本，則交由能部署與回復程式的人員處理。
第三步：加入事件。先做一個最重要的轉換事件，例如 Lead 或 Purchase，再補瀏覽與漏斗事件。事件的觸發點要放在動作已完成的位置：表單送出成功頁，而不是點擊送出按鈕的瞬間。
付款事件的時點要配合網站的轉換定義：若轉換定義是訂單成立，就在訂單狀態成立後送出；若定義是付款授權或付款完成，就分別等待對應結果。
第四步：測試事件。用事件管理工具的測試功能，實際走一次頁面、表單或結帳流程，檢查事件名稱、來源、網址、金額與貨幣。測試完成後移除測試設定，再用一筆可控流程檢查正式環境。
第五步：檢查重複。若同一轉換有兩條傳送路徑，兩邊要由同一筆業務紀錄產生相同的 event_name 與 event_id。先在測試流程各記下一組值，再比對接收結果與數量。
event_id 若不一致，先回查訂單或表單的產生時機，再檢查是否重複載入標籤或重複觸發後端工作。
Conversions API 怎麼設定
Conversions API 的核心工作是：在後端偵測已完成的動作，整理事件資料，再向 Meta 的事件端點送出。你需要先決定事件由哪個系統產生，例如訂單系統、CRM 或表單後端；再讓該系統保存同一筆轉換的 event_id，瀏覽器事件也使用這個值。
Node.js SDK README 的事件範例依序設定 event_name、event_time、使用者資料與 action_source，交易範例另設定 value 與 currency。串接時依你的事件資料表逐欄對照。
README 示範以 FacebookAdsApi.init('<ACCESS_TOKEN>') 初始化，並稱 SDK 是 Conversions API 的伺服器端用戶端。Token 只放在伺服器端，不要寫進前端 JavaScript、公開範本或網址。
後端收到訂單或表單結果後，先寫入事件紀錄，再組成請求。紀錄至少保留事件名稱、事件時間、Pixel ID（資料來源 ID）與 event_id。
重送流程要把原事件的 event_id 留在事件紀錄中，並把暫時性失敗與資料或權限錯誤分開處理。前者可安排退避重試，後者先修正資料或設定，再由原業務紀錄重新組請求。
傳送後回到事件管理工具看接收結果與診斷訊息。先用一個事件完成串接，再擴充到其他漏斗事件。若採合作夥伴整合，仍要確認它實際送出的事件名稱、event_id、金額、幣別與 action_source；「已安裝」不等於「資料欄位正確」。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →iOS 隱私設定會影響什麼
Apple 說明：「In iOS 14.5, iPadOS 14.5, and tvOS 14.5 or later」，App 若要跨其他公司擁有的 App、網站或離線資產追蹤使用者，或存取廣告識別碼，必須透過 AppTrackingTransparency（ATT）取得許可。
這項規則針對 App 的跨資產追蹤，不是用來宣稱「裝了 CAPI 就能繞過使用者選擇」。
若你的廣告流程包含原生 App，先盤點 App 內的 SDK、資料用途與權限提示，再決定哪些事件能送出。Apple 要求在 App Store Connect 提供資料，包括整合的第三方夥伴程式碼的隱私做法。
若使用者拒絕 ATT，不得改用雜湊電子郵件、電話或指紋等識別方式繼續進行 Apple 所稱的跨資產追蹤。Apple 的說法是：「You will need to receive the user’s permission through the AppTrackingTransparency framework to track that user。」
若只有網站，仍要處理網站自己的隱私告知、同意管理與資料最小化。傳送技術不會自動完成這些工作，也不會讓敏感資料變成可任意分享的資料。
只傳送完成量測所需的欄位，並依適用法規與網站的資料治理流程，確認資料用途、傳送條件與接收對象。
安裝後的檢查順序
排錯依序記錄四個結果：動作是否完成、瀏覽器事件是否送出、伺服器事件是否送出、兩邊的 event_name 與 event_id 是否一致。每一格都留下時間、事件名稱與回應，方便對照失敗位置。
| 檢查位置 | 要確認的事 | 常見修正方向 |
|---|---|---|
| 網站流程 | 表單或付款是否真的成功 | 確認成功頁、訂單狀態與重新整理行為 |
| 瀏覽器 | 事件名稱、觸發頁面與參數 | 檢查標籤觸發條件與重複載入 |
| 伺服器 | 事件是否送達、時間與動作來源 | 查看後端記錄與 API 回應 |
| 去重 | 兩邊 event_name、event_id 是否一致 | 由同一筆訂單或表單紀錄產生 event_id |
| 報表 | 事件是否進入資料來源與診斷頁 | 用測試事件再走一次完整流程 |
若瀏覽器有事件、伺服器沒有，對照後端觸發記錄與 token；若伺服器有事件、瀏覽器沒有，查看 Pixel 載入與觸發條件；若兩邊都有但數量偏高，匯出兩邊的 event_name 與 event_id 比對，再處理重複來源。
小型網站的落地順序
沒有工程資源時，先完成一個核心轉換：建立資料來源、安裝 Pixel、測試 Purchase，再把實際訂單紀錄接到伺服器事件。當第一個事件的 event_name 與 event_id 能對上，再擴充其他漏斗事件。
想整理廣告帳戶、資產與權限，可延伸閱讀Meta 企業管理平台設定教學；要將事件資料接回網站分析，可閱讀GA4 安裝與報表教學。
最後更新：2026-09。重新設定時，請回到 Meta 與 Apple 官方文件核對目前欄位與權限。
常見問題
Meta Pixel 一定要和 Conversions API 一起使用嗎？
不一定，但網站有可用的後端轉換紀錄時，兩條路徑能分別處理瀏覽器與伺服器事件。一起使用前要先設計去重，不然同一個動作可能出現兩筆事件。
沒有工程師可以設定 Conversions API 嗎？
可以先使用平台或合作夥伴提供的整合，但仍要檢查實際事件欄位。至少要確認事件名稱、事件時間、動作來源與 event_id 是否符合你的流程；若是交易事件，再確認金額與幣別等交易資料。
為什麼事件管理工具看得到 PageView，卻看不到表單 Lead？
這代表基礎載入與表單轉換是兩個不同問題，先查表單成功條件與 Lead 觸發點。若表單用嵌入式元件或跳轉到第三方頁面，還要確認事件是否發生在你能控制的頁面。
iPhone 使用者拒絕追蹤後，還能不能傳送網站轉換？
先區分網站與 App 的資料流程。Apple 的 ATT 規範針對 App 跨其他公司資產的追蹤與廣告識別碼存取；網站仍要依自己的隱私告知、同意管理與適用法規處理資料，不應把 CAPI 當成繞過選擇的方式。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →