Meta Pixel 教學 2026：安裝、事件與 CAPI 去重

Meta Pixel（Meta 像素）是一段放在網站上的追蹤程式碼，用來衡量訪客在網站上的行為，並把轉換訊號回傳給 Meta，供廣告投放、歸因與成效分析使用。依 Meta Business Help，若你已用 Pixel 分享網站事件，官方也建議一併設定 Conversions API（CAPI），從伺服器補送可能被瀏覽器攔截或遺漏的事件。兩邊並行時，必須用相同的事件名稱與 event_id 去重，否則 Ads Manager 會重複計算，學習期也會被灌進噪音。

Meta Pixel：重點一覽

項目	可核對事實（2026-09-21）
Pixel 是什麼	放在網站上的程式碼，用來衡量廣告成效與網站行為（Set up and install the Meta Pixel）
建立位置	Meta Events Manager（事件管理工具）建立／選取資料集後安裝
安裝方式	合作夥伴整合、手動貼底碼，或經 Google Tag Manager 等（同上 Help；GTM 安裝說明）
為什麼還要 CAPI	官方建議 Pixel 與 Conversions API 並行，提升成效與測量完整性（同上 Pixel Help；Compare CAPI setup options）
同一 Pixel ID	瀏覽器事件與伺服器事件應送到同一個 Pixel／資料集 ID（CAPI Get Started）
去重關鍵	同一顧客動作：`event_name` 相同，且 Pixel 的 `eventID` 與 CAPI 的 `event_id` 相同（About deduplication）
去重時間窗	官方說明：約 48 小時內比對；若瀏覽器與伺服器事件約在 5 分鐘內同時到達，優先採用瀏覽器／App 事件（Server Event Parameters）
驗收工具	Events Manager → 你的 Pixel → Test Events（測試事件）

優化事件選錯、或學習期一直被重置時，先看 Meta 廣告學習中。Advantage+ 銷售活動開跑前設定見 Advantage+ 銷售活動。

Meta Pixel 是什麼？跟 Conversions API 差在哪？

	Meta Pixel（瀏覽器）	Conversions API（伺服器）
資料從哪裡送	訪客瀏覽器執行 `fbq`	你的伺服器呼叫 Graph API `/events`
優點	設定相對快；可搭配自動進階比對	較不受廣告攔截、網路中斷影響；可補瀏覽器漏掉的轉換
風險	被封鎖、隱私設定、頁面未載入完就離開	實作錯誤、去重失敗、漏送或重送
官方建議	保留 Pixel	與 Pixel 並行（冗餘設定）

官方在端到端實作指南把「冗餘設定（Redundant Setup）」列為建議：同一事件同時由 Pixel 與 CAPI 送出，並用持久的 event_id 去重。這樣測量較接近「只靠瀏覽器」時更完整，也能涵蓋部分瀏覽器追不到的轉換路徑。

本篇是網店／網站主的設定順序教學，不是開發者 SDK 全文。需要 Threads 版位素材規格時，另見 Threads 廣告 2026。

網店最常用的標準事件有哪些？

依 Meta Pixel API reference，標準事件以 fbq('track', '事件名稱', {參數}) 送出。網店優先順序通常如下（名稱必須用官方英文 event name，不可自創同義字去優化廣告）：

優先	標準事件	何時觸發（官方描述摘要）	參數重點
1	`Purchase`	完成結帳／感謝頁	必填 `currency`、`value`；目錄廣告另需 `contents` 或 `content_ids`
2	`AddToCart`	加入購物車	建議帶 `contents`／`content_ids`、`value`、`currency`
3	`InitiateCheckout`	進入結帳流程	可帶 `num_items`、`value`、`currency`
4	`ViewContent`	造訪你在意的頁（例如商品頁）	只代表「到了 URL」，不代表頁內行為；目錄廣告建議帶商品 ID
5	`Lead` / `CompleteRegistration`	完成潛在客戶或註冊表單	依商業目標擇一，不要兩個都拿去優化同一漏斗

其餘官方標準事件還包括 Search、AddPaymentInfo、Contact、Subscribe 等（完整表見 Pixel reference）。自訂事件可以記，但要用來優化廣告時，優先選官方標準事件，較容易對上 Ads Manager 的優化目標。

Purchase 範例（參數值請換成你的訂單資料；並行 CAPI 時加上第四參數 eventID）：

fbq('track', 'Purchase', {
  value: 320.00,
  currency: 'HKD',
  content_ids: ['SKU-001'],
  content_type: 'product'
}, {eventID: 'order_20260921_88421'});

相關閱讀：Advantage+ 銷售活動開跑前必查的設定

Meta Pixel 怎麼安裝？（逐步）

以下整理自 Set up and install the Meta Pixel 與 Add the Meta Pixel in Google Tag Manager。介面文案可能微調，以 Events Manager 當下指引為準。

A. 在 Events Manager 建立 Pixel／資料集

開啟 Events Manager。
連結到正確的 Meta Business Suite／業務資產（沒有的話先建立）。
新增資料來源／整合，選擇 Meta Pixel（或依當前介面選擇網站資料集）。
記下 Pixel ID——之後瀏覽器與 CAPI 都要用同一個 ID。

B. 三種常見安裝路徑（擇一為主）

路徑	適合誰	注意
合作夥伴整合	Shopify、WooCommerce 外掛、官方支援的電商平台	通常可同時引導 Pixel + CAPI；完成後仍要用 Test Events 驗
手動貼底碼	自架站、主題可編輯 `<head>`	底碼放全站頁首；標準事件放對應成功頁／按鈕
Google Tag Manager	已用 GTM 管標籤	用 Custom HTML 貼底碼，觸發條件設 All Pages；事件另建標籤

手動底碼的核心是：全站載入一次 Pixel base code，再在關鍵動作觸發 fbq('track', …)。不要在同一頁重複初始化多個不同 Pixel（除非你明確知道在做多帳戶，且已處理重複計算）。

C. 先驗證「底碼有沒有亮」

用無痕視窗打開網站首頁與一頁商品頁。
到 Events Manager → 該 Pixel → Test Events。
確認看到 PageView（底碼）與你手動觸發的標準事件。
沒出現時，先查：廣告攔截、錯誤網域、GTM 未發佈、事件寫在感謝頁但訂單導向外部金流未回來。

Conversions API 怎麼與 Pixel 並行？

依 Compare Conversions API setup options 與 Developers 端到端指南，常見選項：

選項	說明	誰適合
合作夥伴／平台整合	電商平台或中介幫你送伺服器事件	多數網店首選
Meta-enabled Conversions API	Meta 協助建立網站端的伺服器連線（網頁事件）	想少寫程式、接受官方引導流程
直接整合（寫程式）	伺服器 `POST` 到 `https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events`	有開發資源、要控資料欄位

直接整合最低門檻（概念，不是完整 SDK）：

在 Events Manager 的 Conversions API 設定產生 access token（官方建議由此產生系統使用者權杖）。
伺服器在訂單成立／表單成功後送事件，至少包含：event_name、event_time（Unix 秒）、action_source（網站事件用 website）、event_id、user_data、以及購買時的 custom_data.value／currency。
同一個顧客動作：瀏覽器 eventID = 伺服器 event_id，且 event_name 完全一致（例如都是 Purchase）。
用 Test Events 的測試事件碼（test_event_code）先打通，再關掉測試碼上正式環境。

去重失敗的典型症狀：Ads Manager 購買數幾乎是真實訂單的兩倍、或學習期「結果數」虛高。此時先停掉一邊重送，修好 event_id 對齊再開冗餘。

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

CAPI 能否把轉換對回廣告點擊，取決於你送的比對鍵。依官方客戶資訊參數說明，常見做法是：

可雜湊欄位（如 email、電話、姓名等）先正規化，再用 SHA-256 雜湊後放入 user_data
fbp、fbc、client_ip_address、client_user_agent 等依文件要求以未雜湊方式傳送（有取得時）
網站事件通常還需要正確的 action_source 與 event_source_url

不必一次追求滿分；先保證 Purchase／Lead 有穩定 event_id 去重，再逐步提高比對鍵覆蓋率。分數解讀以 Events Manager／Dataset Quality 介面為準。

開跑前檢查表（本篇 canonical）

步驟	通過標準	常見踩雷
1. Pixel ID 唯一	網站與 CAPI 指向同一 ID	測試 Pixel 與正式 Pixel 混用
2. 底碼全站	Test Events 看得到 PageView	只裝在首頁、或 GTM 未 Publish
3. 標準事件對齊漏斗	Purchase 在「付款成功」不是「按結帳」	用 PageView／淺層事件去優化購買
4. Purchase 必填欄位	有 `value` + `currency`	金額為 0、幣別缺漏
5. 去重	同一訂單兩邊同名＋同 `event_id`	只送 CAPI 不送 Pixel（或相反）卻以為已冗餘；或每次重新隨機 ID
6. 驗收	Test Events 與實際小額測試單一致	上線後從不對訂單抽查

事件穩定後，再回頭看學習期是否仍卡在 Learning limited：那通常是預算、事件定義或結構問題，不是再加一個 Pixel 能解決。

常見錯誤

只用瀏覽器 Pixel，遇到攔截就以為「廣告沒轉換」——先補 CAPI，再判斷素材與受眾。
Purchase 裝在「進入結帳」——會優化到未付款行為，浪費預算。
兩邊都送、但沒共用 event_id——重複計算，學習訊號失真。
為了「多一點事件」把 ViewContent 當購買優化——學習期可能較快滿，但買不到人。
外掛裝了三套追蹤——Shopify／GTM／主題各送一次，數字膨脹。

來源

第三方教學偶見「一定要 EMQ 8.0 才能跑 Advantage+」等門檻；公開 Meta Help／Developers 截至核對日並未把單一 EMQ 分數寫成 Advantage+ 硬性開關。以 Events Manager 實際提示與官方文件為準。

常見問題

Meta Pixel 跟 Facebook Pixel 是不是同一個東西？

是同一產品線的現行名稱。介面與文件多已改稱 Meta Pixel；舊文說的 Facebook Pixel 通常指同一套網站追蹤底碼與事件機制。

一定要同時裝 Pixel 和 Conversions API 嗎？

Meta 明確建議：若你用 Pixel 分享網站事件，也應使用 Conversions API。只裝一邊仍可能投放，但測量較容易受攔截或實作缺口影響。官方建議的冗餘設定是兩邊都送、再去重。

event_id 要用訂單編號嗎？

可以用能代表「這一次顧客動作」的穩定唯一值，例如訂單 ID。重點是：瀏覽器與伺服器對同一動作必須送出相同字串，且不要在頁面重新整理時又生成另一個新 ID 再送一次 Purchase。

去重失敗會怎樣？

同一筆購買可能被算兩次，Ads Manager 轉換與成本失真，學習期看起來「結果很多」卻對不到真實營收。先對齊 event_name + event_id，再用 Test Events 與真實訂單抽查。

Purchase 可以不填金額嗎？

標準事件參考寫明：Purchase 的 currency 與 value 為必填。缺漏會影響價值優化與報表金額。幣別請用訂單真實幣別（例如 HKD、TWD），不要為了「好看」硬填 USD。

裝好 Pixel 就能讓 Advantage+ 一定賺？

不能。Pixel／CAPI 提供的是可學習的轉換訊號；活動是否維持 Advantage+ On、預算與素材策略，仍要看銷售活動設定與學習期狀態。訊號正確是前提，不是成效保證。

Meta Pixel 教學 2026：安裝、標準事件與 Conversions API 去重

Meta Pixel：重點一覽

Meta Pixel 是什麼？跟 Conversions API 差在哪？

網店最常用的標準事件有哪些？