轉換 API

設定轉換 API 做為平台

如果您提供的標籤管理服務中包含 Meta 像素設定，您可能會想要考慮新增轉換 API 功能。與轉換 API 整合可讓您的顧客將網路事件直接傳送至 Meta，而不需要依賴瀏覽器像素事件。

伺服器事件與瀏覽器事件

開始之前，瞭解伺服器事件與 Meta 像素之間的關係非常重要。伺服器事件是透過轉換 API 來傳送，並且像瀏覽器像素事件一樣，可用於成效衡量、分析報告和最佳化。

如果說傳送瀏覽器像素事件就像是透過航空郵政來寄送郵件，則傳送伺服器事件就像是透過貨運來寄送郵件。兩者都是將包裹（事件的相關資料）運送至目的地地址（像素編號）的機制。因此，我們強烈建議您在自己的平台上建立轉換 API 整合，以做為目前 Meta 像素產品的擴充功能（而不是獨立的外掛程式或服務），原因如下：

  • 伺服器事件使用像素編號做為目的地
  • 伺服器事件的處理方式與瀏覽器像素事件傳送到 Facebook 的方式相同
  • 刪除重複項目將更容易實作
  • 方便客戶使用。例如，伺服器事件預設可以與瀏覽器事件一起傳送。

您的平台與轉換 API 整合後，建議透過瀏覽器和伺服器來傳送相同的網路事件。這種備援機制有助於確保訊號的可靠性。以前可能因為各種網路原因而在瀏覽器端遺失的事件，現在可以透過轉換 API 來擷取。

若要透過瀏覽器和伺服器來傳送事件，您必須為對應的事件正確設定相同的 event_id。這樣可以讓 Facebook 正確地為您的事件刪除重複項目。

必要條件

  1. 能夠將事件分享到 Facebook 的網路平台。例如，網站打造工具、代碼管理工具或 AdTech 平台。
  2. 依照《Facebook 商業工具使用條款》的要求，以適當的方式通知用戶將與 Facebook 分享事件資料，並取得用戶同意。
  3. Facebook 業務代表
  4. 標準轉換 API 整合先決條件：

若要開始提供轉換 API 做為平台，您的應用程式需要經過應用程式審查。應用程式審查期間，您必須要求下列存取層級、功能和權限：

開始使用

如果這是您第一次使用轉換 API，請按照以下步驟建立商家、Meta 應用程式、Meta 像素和系統用戶。然後，您就能夠使用系統用戶的存取權杖，透過 轉換 API 來傳送伺服器事件。

步驟 1：建立商家。

步驟 2：在您新建立的商家之下建立 Meta 應用程式。

步驟 3：在您新建立的商家之下建立 Meta 像素：

步驟 4：產生系統用戶存取權杖。

步驟 5：將伺服器事件傳送到您的 Meta 像素。

代表客戶傳送事件

成功將伺服器事件傳送到您自己的 Meta 像素後，您就可以選擇如何代表客戶傳送事件。

針對合作夥伴企業管理平台擁有或管理的 Meta 像素

  1. 在企業管理平台中，前往用戶區塊，並選擇系統用戶頁籤。點擊您用於轉換 API 的特定系統用戶。
  2. 前往指派資產對話方塊，並選擇像素。然後，選擇您要代表其傳送事件的像素。
  3. 針對每個像素，選擇管理像素權限，然後點擊儲存變更。
  4. 返回系統用戶的詳細資料頁面。確認所選擇的像素顯示在該頁面上。

針對非由合作夥伴管理的 Meta 像素

您必須先要求授權，才能代表客戶傳送事件。您有以下幾種驗證選項：

Facebook Business 擴充功能（建議）

使用此選項時，Facebook Business 擴充功能（FBE）會透過以下程序，傳回代表客戶傳送事件所需的所有必要資訊。FBE 會提供端點，以擷取在客戶企業管理平台中建立的系統用戶存取權杖。此程序包含傳送伺服器事件的權限，並且會自動以安全的方式完成。

端點需要用戶存取權杖做為輸入參數。針對新的 FBE 用戶，在完成 FBE 設定後，請呼叫此端點來擷取系統用戶存取權杖。現有用戶在呼叫新的 API 端點之前，需要先要求重新驗證。

客戶系統用戶存取權杖

使用此選項時，必須由您的客戶透過像素設定中的轉換 API，手動建立系統用戶存取權杖。然後您就可以使用該權杖，將事件傳送到廣告主的像素。

系統工作人員或管理系統工作人員必須安裝將用於產生存取權杖的應用程式。此設定可讓您的應用程式代表此系統用戶或管理員系統用戶呼叫 API。

請遵循我們的開始使用說明文件，向您的廣告主要求系統的用戶權杖。請記得使用您自己的 Meta 像素和存取權杖進行測試。

客戶將 Meta 像素分享給合作夥伴的企業管理平台

使用此選項時，客戶可以透過企業管理平台設定或透過 API，將其 Meta 像素分享給合作夥伴。然後，您可以將合作夥伴系統用戶指派給客戶像素，並產生存取權杖來傳送伺服器事件。

使用 partner_agent 欄位，將事件歸因於您的平台

若要將轉換 API 事件歸因於您的平台，請使用 partner_agent 欄位。這讓您能夠在代表客戶傳送事件時，設定自己的平台識別碼。請與您的 Facebook 業務代表協議平台的識別碼。然後，將識別碼隨著每個伺服器事件一起傳送。

事件承載範例

假設您的平台識別碼為 datapartner，則以下是代表您的客戶傳送的購買事件承載範例：

    
{
  "data": [
    {
      "user_data": {
        "em": "8159ea0e33c51a774b83104ee562784f9b1836c852102046e4bd8385706fe7ca"
      },
      "event_name": "PageView",
      "event_time": 1579645238
    },
    {
      "user_data": {
        "em": "8159ea0e33c51a774b83104ee562784f9b1836c852102046e4bd8385706fe7ca"
      },
      "custom_data": {
        "currency": "USD",
        "value": "50"
      },
      "event_name": "Purchase",
      "event_time": 1579645238
    }
  ],
  "partner_agent": "datapartner"
}

常見問題

Sending events sent via the Conversions API is just like sending events via the Meta Pixel. The only difference is that the event is sent via the server, instead of the browser. So, why make an effort to integrate with the Conversions API? Here are some important use cases:

Capture offline and down-funnel events

If someone uses an advertisers’ website to sign up for a credit card, they can send events such as ViewContent, Application Start, and Application Submit via the browser to the Meta Pixel. However, the end user still needs to be approved for this credit card. The Approval event happens offline and cannot be sent via browser. To register this final step, the advertiser can send the Approval via the Conversions API.

Signal resiliency

Browser side events can be lost for many reasons:

  • The user might navigate away before the page has finished loading.
  • Ad blockers could prevent the event from firing.
  • The changing internet landscape might change the way inter-domain messages are sent.

These examples can all be mitigated by sending events via the Conversions API.

Sensitive data

Many advertisers have expressed concerns about sharing data via the browser when that data could be seen or inspected. This can be mitigated by sending data via the Conversions API.

For example, advertisers may want to send data like profit margin or lifetime value (LTV) along with a purchase event. This way, ads can be optimized towards a specific type of customer.

固定連結

Since browser events are always vulnerable to obstacles, we recommend that you only send events collected from the Conversions API sources. For example, if:

  • One of the ways your customer ingests data into your platform is via a browser JavaScript tag, or
  • You send that data to Meta via the Conversions API

the data is open to the browser-side risks.

To take full advantage of the Conversions API, no part of the data flow should be reliant on the browser.

固定連結

We recommend that you provide advertisers with a way to test this connection on your own platform.

  1. Send a test event via the Conversions API to the advertiser’s pixel. Look for a 200 return code.
  2. Update the status of the connection appropriately.
固定連結

Meta tries to deduplicate identical events sent through the Meta Pixel and the Conversions API. We determine if events are identical based on their event_id and event_name. For more information, see Handling Duplicate Pixel and Conversions API Events.

固定連結

The external_id parameter is a string that represents a user on an advertiser's system. These IDs help improve ads attribution and create audiences.

You can send external_ids via browser or the Conversions API, but you must be consistent across channels. For example, if you send a browser pixel event with external_id set to 123, your server event for that same user should also have external_id set to 123.

固定連結