Meta 像素和轉換 API 要兩個都裝，裝第二個不必寫程式

Meta 開發者文件講去重複的那一頁，開頭第一段就是答案：「為獲得最佳廣告成效，建議廣告主同時實作轉換 API 與 Meta 像素。我們將這種作法稱為「備援設定」。」

所以「要不要兩個都裝」，官方的答案是要。中小企業會卡住的是後面兩件事：第二個要花多少力氣裝，以及兩邊都送同一筆購買時，報表會不會把一筆算成兩筆。這篇依序回答。

像素從訪客的瀏覽器送，轉換 API 從伺服器送

Meta 開發者文件對像素的定義是：「Meta 像素是一段 JavaScript 程式碼片段，可載入一小個函式庫，供您用來追蹤網站上由 Facebook 廣告帶來的訪客活動。」這段程式碼貼在你的網頁裡，訪客打開網頁時由訪客的瀏覽器執行；訪客做了某個動作（看商品、加入購物車、完成結帳），程式碼就從那個瀏覽器把一筆「事件」送給 Meta。

像素什麼時候送出事件，取決於訪客的瀏覽器有沒有跑到那一步。以 Shopify 的說明頁為例，像素的購買事件（Purchase）觸發條件寫的是：「When a visitor completes a purchase and views the thank you page in the checkout.」訪客要完成購買、而且看到結帳的感謝頁，這一筆才會從瀏覽器送出。

轉換 API（Conversions API，常簡稱 CAPI）走另一條路。Meta 說明頁的描述是：「轉換 API 的設計目的是在行銷資料(您的伺服器、網站平台、應用程式或 CRM)和 Meta 之間建立一個直接且更可靠的連結。」事件由你的伺服器（用開店平台的話，是平台的伺服器）送到 Meta。Shopify 的說明頁講得更具體：「The Conversions API sends the purchase event between Shopify and Facebook servers.」

像素可能漏掉事件，伺服器送的轉換 API 補得回來

Meta 自己在說明頁寫了像素的弱點：「相較於 Meta 像素資料，轉換 API 資料較不易受到瀏覽器載入錯誤、連線問題及廣告封鎖程式的影響。」

這三種情況的共同點，是事件要靠訪客的瀏覽器把程式碼跑完、把資料送出去。瀏覽器裝了廣告封鎖程式、網路在那一刻斷線、頁面沒有載入完成，像素那一筆就可能到不了 Meta。由伺服器產生、從伺服器送出的事件，不依賴訪客的瀏覽器把頁面跑完。Shopify 的說明頁是這樣寫的：「Data sent from server to server can't be blocked by browser-based ad blockers.」

這就是 Meta 要你兩邊送「同一批」事件的原因。Meta 最佳作法頁舉的例子是：「若您透過像素分享購買、開始結帳與聯絡事件，請使用轉換 API 從您的伺服器分享那些相同的事件。」接著說明理由：「多餘事件設定很有用，因為轉換 API 可擷取到像素因網路連線問題或頁面載入錯誤而錯失的網站事件。」

至於成效，Meta 的說法是：「搭配像素使用轉換 API 可創造更為可靠的連結管道，有助於投遞廣告系統降低您的每次成果成本。」用詞是「有助於」，說明頁沒有承諾降多少。

第二個怎麼裝：看你的網站蓋在哪裡

Meta 的〈比較轉換 API 設定選項〉比較了三種方法：Meta 支援的轉換 API、直接整合、透過 Meta 合作夥伴整合；〈關於轉換 API 閘道〉另外介紹了第四種，轉換 API 閘道。照中小企業要花的力氣由少到多排，順序如下：

排序的理由是錢與人力。前兩種 Meta 不另外收費、不需要工程師（Wix 的說明頁另外寫明，要先升級網站方案並連接網域才能用這個功能）；閘道同樣免寫程式，但每個月有雲端費用，Meta 列的理想適用條件之一是「您每月在針對網站事件進行最佳化的行銷活動上花費超過 $300 美元」，而且同一頁寫明，已經用電商合作夥伴管理像素、而且對方支援轉換 API 簡易整合的，建議利用現有的合作夥伴。直接整合要工程師與數週時間，只有要送 App 或實體店（離線）事件時才非走不可。

第二列那個選項，Meta 開發者文件的首頁寫得最白：「如果您的網站上有 Meta 像素，您也可以從 Meta 事件管理工具點擊一下，為網站事件設定 Meta 的轉換 API，而無需程式碼、配置或設定費用。」比較頁對它的說明是「網頁專屬設定，會自動建立伺服器端連線」。

選它之前要知道一個限制。比較頁的英文版表格寫明，它送的事件與參數都跟著像素走：「The events shared through the Meta pixel are also shared through the Meta-enabled Conversions API」，參數那一列也是同樣寫法。中文版的「事件選擇」那一格把名稱寫成「轉換 API 閘道」，但同一欄的表頭與下一列「參數選擇與轉換」寫的都是「Meta 支援的轉換 API」，本文照英文版引用。事件的來源還是像素；像素這端沒送出的事件，這張表沒有說它補得回來。對照之下，Shopify 的說明頁寫明購買事件是在 Shopify 與 Facebook 的伺服器之間傳送。

所以 Meta 不另外收費的兩種裡，網站蓋在開店平台上的，平台整合排前面。自架網站、沒有工程師的，Meta 支援的轉換 API 是 Meta 自己提供、標示免費的一鍵選項，事件會自動去重；但它的事件範圍跟像素相同，比較頁沒有寫它比單裝像素多帶回多少事件。要讓自架網站後端的訂單資料直接送給 Meta，比較頁列的是直接整合，得排工程師；網站如果用了 Adobe、Google 代碼管理工具、Tealium 這類 Meta 合作夥伴平台，比較頁另外寫了「可能可以透過合作夥伴整合工具設定轉換 API」。

台灣常見開店平台的開法

下表只收平台官方說明頁或官方教學有寫明轉換 API 設定方法的平台。各家的介面名稱照原文：

兩邊都送同一筆購買，靠事件編號合併成一筆

備援設定等於同一個事件送兩次：像素從瀏覽器送一次，轉換 API 從伺服器送一次。Meta 收到兩筆，要認得出它們是同一件事，報表才不會多算。Meta 最佳作法頁的寫法是：「刪除重複的多餘事件以避免重複回報。」

Meta 建議的去重方法是比對事件編號與事件名稱，開發者文件列的條件是：

• 像素送的 eventID，要與轉換 API 送的 event_id 相同。這個編號由你的網站或平台替每一筆事件產生，例如同一張訂單的購買事件，兩邊帶同一個編號。
• 像素送的事件名稱（event），要與轉換 API 的 event_name 相同，例如兩邊都叫 Purchase。
• 兩筆要在 48 小時內送達：「這些事件必須在系統收到含有指定 event_id 的第一個事件後的 48 小時內送達，重複項目才會遭到刪除。」
• 兩筆合併時留哪一筆：「如果伺服器事件和瀏覽器事件無明顯的內容差異，系統通常會偏好先接收到的事件。」

另一種方法是比對事件名稱加上 fbp 或 external_id（外部編號，廣告主自己提供的不重複編號，例如會員編號），但它有一個限制：瀏覽器那筆要先到。文件原文是：「如果系統在過去 48 小時內沒有收到瀏覽器事件，就不會刪除伺服器事件，即使相同的瀏覽器事件緊跟在伺服器事件之後送達也一樣。」同一個來源連續送兩次也不會被合併：「如果您連續傳送兩個具有相同資訊的瀏覽器事件，系統會保留兩者。」

誰來產生這個編號，要看你用哪種裝法。WooCommerce 的說明頁寫明由外掛處理，「deduplicated based on a unique event ID」；轉換 API 閘道的說明頁寫「可自動刪除瀏覽器和伺服器事件間的重複事件」；Meta 支援的轉換 API，比較頁英文版寫的是「The events shared through the Meta pixel are also shared through the Meta-enabled Conversions API and are automatically deduplicated」。自己寫程式直接整合的，event_id 就是你的工程師要做的事。

轉換 API 送的是顧客資料，送之前要先雜湊

伺服器送來的事件，Meta 要把它對到某一個 Meta 帳號，靠的是你一起附上的「顧客資訊參數」。Meta 說明頁列了這些參數的優先順序：電子郵件地址與點擊編號是「高」，手機號碼、外部編號、瀏覽器編號等是「中」，名字、城市、郵遞區號是「低」。

配對得好不好，Meta 用「事件配對品質」（Event Match Quality，EMQ）打分數。Meta 開發者文件說：「我們通常建議您盡可能將「事件配對品質」分數目標設定為 6.0 或更高分。」

email、電話這類聯絡資料不能直接送原文。Meta 開發者文件寫：「我們的系統設計為不接受未將聯絡資料雜湊處理的顧客資訊，除非下文另有指示。」雜湊是用固定演算法把一串文字轉成另一串固定長度的字元，文件在電子郵件、電話等欄位的範例裡列的是「預期的 SHA256 輸出」。送之前要先把 email 的前後空格修掉、全部轉成小寫，大小寫或空格不同，雜湊出來的結果就不同。

Meta 在〈關於轉換 API〉說明頁寫明了轉換 API 不是拿來做什麼的：「和像素一樣，轉換 API 的設計用意並非用來繞過 iOS App Tracking Transparency 架構等資料分享政策或《電子通訊隱私指令》等歐洲地區的隱私規定。」

只裝轉換 API、不裝像素呢

Meta 沒有禁止。開發者文件〈轉換 API 端對端實作〉把這種用法直接寫進去：「透過僅限伺服器的實作方式（例如，沒有 Meta 像素）使用時，轉換 API 可讓您控制所分享的資料。」不過說明頁的建議仍是兩個一起用：「如果您使用轉換 API 傳送網站事件，可考慮也使用像素來協助讓您的網站事件發揮最大效用。」

對沒有工程團隊的中小企業，這條路也不省事。上面最省力的裝法裡，Meta 支援的轉換 API 列的所需資源就是「Meta 像素」。開店平台以 Shopify 為例，三個分享層級裡用到轉換 API 的兩級都同時用像素：Enhanced 寫的是轉換 API「as well as the Meta pixel」，Maximum 寫的是「Facebook's Conversions API, Meta pixel」，沒有只用轉換 API 的選項。拿掉像素，Meta 支援的轉換 API 少了它列的所需資源，轉換 API 閘道也不符合 Meta 列的第一個理想條件「您已經在使用 Meta 像素」。

現在可以做的三件事