轉換 API

CRM 適用的轉換 API：整合為單一平台

合作夥伴可考慮提供 CRM 適用的轉換 API 作為服務，這樣可讓您的客戶從各自的 CRM 系統上傳透過 Facebook／Instagram 潛在顧客廣告（即時表單）產生的「成為潛在顧客」事件，並在廣告中使用「採取轉換動作的潛在顧客」最佳化目標，以開發較可能轉換的高品質潛在顧客。

先決條件

規劃專案時，您可以使用預估時間表作為指引。請注意：

  1. 整合階段，或合作夥伴端的實際開發，可能需要大約 3 到 7 週的時間。整合完成後，廣告主可能需要 1.5 到 2 個月的時間，才能開始啟用完全最佳化的轉換名單型廣告行銷活動。
  2. 以下時間表是根據歷史資料，實際時間表可能因可用資源、解決問題的速度等因素而異。
階段步驟預估時間（時間長度）







整合

步驟 1. 設定資產的先決條件

步驟 2. 驗證


步驟 3. API 整合



總計

先決條件

1 天到 3 週，視驗證選項而定

3 到 4 週。
如果合作夥伴已經與網頁、離線、應用程式或訊息事件的轉換 API 整合，則所需時間較短

大約 3 到 7 週










整合完成後


步驟 1. 設定資料集

步驟 2. 連結合作夥伴系統

步驟 3. 等待 CRM 事件 7 天

步驟 4. 配置銷售漏斗

步驟 5. 漏斗分析與學習階段

步驟 6. 展開完全最佳化的轉換名單型廣告行銷活動*

總計


0.25 小時

1 到 2 小時

1 週

0.5 小時

1 到 2 個月





大約 1 到 2 個月

*廣告主可以在學習期間執行轉換名單型廣告行銷活動，但在學習期結束之前，廣告主無法受益於完全的成效提升。

整合指南

步驟 1：先決條件

如果您尚未提供轉換 API 作為網頁、應用程式、離線或商務式訊息事件的服務，請確認您已設定下列資產：

權限商家目的提交內容



ads_read

這項權限允許的用途在於提供廣告成效資料的 API 存取權，以用於自訂主控板和資料分析，或是將網站事件從您的伺服器直接傳送至 Meta。

書面：說明您將使用此權限，代表您的廣告主透過轉換 API 將事件從您的伺服器直接傳送至 Meta。

影片：示範您的平台如何透過轉換 API 傳送事件。






ads_management

這項功能的許可用途在於啟用不限數量的廣告帳號和降低限速。使用廣告管理一般存取權限至少需要 ads_read 或 ads_management 權限。

書面：說明您將使用此權限，代表您的廣告主透過轉換 API 將事件從您的伺服器直接傳送至 Facebook；或代表您的商家，以程式化方式建立和管理行銷活動作為您平台的加值功能。

影片：示範您的平台如何透過轉換 API 傳送事件，或展示測試用戶登入您的平台以建立或編輯廣告行銷活動。





廣告管理一般存取權限

這項功能的許可用途在於啟用不限數量的廣告帳號和降低限速。使用廣告管理一般存取權限至少需要 ads_read 或 ads_management 權限。

若要符合進階存取權限資格，您的應用程式在 15 天內必須成功發出至少 1,500 次行銷 API 呼叫，且錯誤率低於 10%。

達到限速後，請務必避免重複呼叫 API 的常見錯誤。請在收到錯誤回應時，改為立即暫停呼叫。

系統授予的權限，不需要提交。





pages_read_engagement

此權限允許您的應用程式讀取粉絲專頁發佈的內容（貼文、相片、影片、活動）、讀取粉絲資料（包括姓名、PSID）和大頭貼照，以及讀取關於粉絲專頁的中繼資料和其他洞察報告。

書面：說明您需要此權限作為 ads_management 權限的先決條件，您將使用此權限，代表您的廣告主透過轉換 API 將事件從您的伺服器直接傳送至 Meta。

影片：示範您的平台如何透過轉換 API 傳送事件。




pages_show_list（pages_read_engagement 的先決條件）

此權限允許的使用方式在於向用戶顯示他們所管理的粉絲專頁清單，或驗證用戶是否管理某粉絲專頁。

書面：說明您需要此權限作為 pages_read_engagement 和 ads_management 權限的先決條件，您將使用此權限，代表您的廣告主透過轉換 API 將事件從您的伺服器直接傳送至 Meta。

影片：示範您的平台如何透過轉換 API 傳送事件。




business_management（所有粉絲專頁權限的先決條件）

此權限的用途在於代表您應用程式用戶擁有的粉絲專頁，傳送業務相關的活動（例如購買、加到購物車、潛在顧客）。

書面：說明您需要此權限作為 pages_show_list、pages_read_engagement 和 ads_management 權限的先決條件，您將使用此權限，代表您的廣告主透過轉換 API 將事件從您的伺服器直接傳送至 Facebook。

影片：示範您的平台如何透過轉換 API 傳送事件。


步驟 2：驗證

合作夥伴對於非由您管理的資料集有以下兩種驗證選項：

選項 1 - Meta Business 擴充功能（MBE，偏好選項）

MBE 會提供端點，以擷取在廣告主企業管理平台中建立的系統用戶存取權杖。完成實作 MBE 的所有必備條件。

請確認您：

  • 獲得應用程式的 manage_business_extension - 這是非公開權限，必須由您的 Meta 業務代表將您的應用程式新增到許可清單中
  • 已將設定配置物件中的管道參數值設為 CONVERSIONS_API
  • 能夠在啟用完成時收到 Webhook 回應
  • 使用透過 MBE 傳回的存取權杖，再另外進行一次 API 呼叫，將此權杖轉換成系統用戶存取權杖
  • 在系統中儲存一份 external_business_id、pixel_id（即資料集編號）、business_id 和系統用戶存取權杖的副本
  • 讓您的 MBE 整合獲得核准

選項 2 - 用戶端系統用戶存取權杖

透過此選項，合作夥伴可以請廣告主：

  • 在 Meta 事件管理工具（EM）的設定中，透過轉換 API 手動建立系統用戶存取權杖
  • 與合作夥伴分享 pixel_id（即資料集編號）、business_id 和系統用戶存取權杖，並儲存一份副本

步驟 3：API 整合

合作夥伴接著呼叫轉換 API 端點來傳送事件裝載。需要注意的關鍵步驟：

尋找潛在顧客編號

lead_id 是預先定義的編號，與在 Facebook 或 Instagram 上執行的名單型廣告行銷活動所開發的潛在顧客相關聯。有多種方法可從 Meta 找到潛在顧客編號。建議合作夥伴使用 Webhook 或圖形 API 批量讀取來尋找潛在顧客編號。

注意，lead_id 是 CRM 適用的轉換 API 整合中使用的必要欄位，可將事件上傳回 Meta，以幫助開發更高品質的潛在顧客


新增 partner_agent 字串以進行歸因

將不重複的 partner_agent 字串與裝載一起傳送。如果可以，請與您專屬的 Meta 業務代表一起決定合適的代理商字串。如果您已經為網頁、離線、應用程式或商務式訊息事件透過轉換 API 傳送代理商字串，請使用同一個代理商字串。

範例

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

{
    "event_name": "my lead stage",
    "event_time": 1617693833,
    "user_data": {
        "lead_id": 1234567890123456
    },
    "action_source": "system_generated",
    "custom_data": {
        "lead_event_source": "Salesforce",
        "event_source": "crm"
    },
   "partner_agent": "datapartner"
}

使用正確的事件裝載

對於 CRM 適用的轉換 API 整合，合作夥伴應使用上述事件裝載結構，以確保能成功接收事件。請注意，這與網頁、離線、應用程式或商務式訊息事件的轉換 API 不同。

請務必為 CRM 適用的轉換 API 事件的 action_source 使用正確的值，即 action_source = system_generated

傳送所有潛在顧客階段，包括初始潛在顧客階段

請務必在更新階段時傳送潛在顧客的所有階段。這表示，隨著潛在顧客在潛在顧客漏斗階段的移動，同一個 lead_id 會有多個事件。

請務必傳送第一潛在顧客階段（即初始「成為潛在顧客」事件），因為這會讓系統知道已收到潛在顧客並加以處理。

您應該至少傳送兩個階段的銷售漏斗事件，包括初始「成為潛在顧客」事件。如果可以，建議傳送三個或更多階段。

對應 CRM 潛在顧客階段

如果您的廣告主使用不同的 CRM 系統，請確認您能夠將不同資料來源的參數分別對應到 lead_id、event_name 和 event_time。

一個可行的解決方案是在與廣告主互動的入口網站中加入 UI／UX 功能，讓廣告主可以將不同 CRM 參數對應到 lead_id、event_name 和 event_time 本身。

其他最佳作法包括以下幾項：

  1. 請每天至少上傳一次資料。理想的情況是即時上傳資料，但如果無法即時整合，可以採用每小時或每天批次上傳的方法。
  2. 每個批次最多可包含 1,000 個事件。如果批次中存在錯誤，系統將會捨棄整個批次，因此強烈建議採用小批次，並加入嘗試重試的邏輯。
  3. 最多可回填過去 7 天內的資料。系統會計算 event_time 和 upload_time 之間的時間差。透過回填部分資料，可能會加快訓練速度。
  4. 請確保 event_time 值位於潛在顧客產生時間戳記之後，否則系統可能會捨棄事件。
  5. 記錄來自 CAPI 呼叫的錯誤訊息，並在出現問題時建立警告。您也可以將這些錯誤視為例外情況處理。
  6. 在您的系統中儲存 lead_id 及其他資訊，例如潛在顧客的詳細資料、潛在顧客階段等。

整合完成後

成功完成 API 整合後，建議您先選擇一些合適的廣告主進行測試，然後再向所有廣告主公開您的解決方案。

選擇合適的廣告主

請務必選擇合適的廣告主來使用 CRM 適用的轉換 API。以下是針對此類廣告主的一些守則：

  • 使用 Facebook 或 Instagram 的名單型廣告（即時表單）
  • 每月最少開發 200 名潛在顧客
  • 廣告主想要最佳化的潛在顧客階段
    • 在開發潛在顧客的 28 天內發生
    • 轉換率在 1% 到 40% 之間
  • 關心潛在顧客品質

廣告主守則

若要將您的廣告主成功加入 CRM 適用的轉換 API，並在加入後為他們提供良好的服務，強烈建議您熟知廣告主用戶歷程，以便引導他們完成以下內容：

步驟 1. 建立 CRM 資料集：若要驗證 CRM 資料集的設定是否正確，請前往事件管理工具 > 資料來源 > 設定，如果是 CRM 資料集，您會看到「採取轉換動作的潛在顧客區塊」。

步驟 2. 傳送 CRM 事件：允許您的廣告主連結您的系統，並開始傳送 CRM 事件。如果整合卡在「傳送 CRM 事件」，表示廣告主或您的系統尚未成功傳送任何事件。

步驟 3. 等待 CRM 事件 7 天：若要通過資料驗證檢查，資料集必須符合所有必備條件，才能進入後續步驟。若要確認此階段是否成功，請在事件管理工具中檢查狀態是否下移至「配置銷售漏斗」。

如果廣告主無法繼續此步驟：

  • 檢查 CRM 資料集的「事件管理工具診斷」頁籤中的錯誤。

  • 持續傳送至少七天的資料，但不一定要連續七天，因為廣告主在某些日子（例如週末）可能不會開發潛在顧客。

  • 上傳的事件足以與 Facebook 上開發的潛在顧客配對。例如，如果廣告主在一天內開發 100 位潛在顧客，我們預期所有 100 位潛在顧客都有上傳的事件與之配對。

  • 廣告主銷售漏斗的事件至少有兩個階段，包括第一潛在顧客階段（即初始「成為潛在顧客」事件）。不過，如果可以，建議至少要有三個階段。例如，僅傳送「銷售」事件是不夠的，必須確保廣告主也傳送之前的階段。

  • 資料必須具備所有必要的參數，並採用本指南中標示的正確格式。使用其他格式傳送資料會導致錯誤。


步驟 4. 配置銷售漏斗

步驟 5. 漏斗分析與學習階段：若要脫離「漏斗分析」狀態，整合需要符合下列條件：

  • 轉換率在 1% 到 40% 之間的最佳化階段

  • 最佳化天數的轉換期間為 28 天或更短時間

整合完成後，需要 1 到 2 個月的學習階段，在此階段中，模式需要使用回傳的資料來進行最佳化。若要確認整合是否已完成學習階段，請檢查事件管理工具中的狀態是否顯示「學習階段完成」

步驟 6. 使用上述 CRM 資料集，透過廣告管理員執行完全最佳化的轉換名單型廣告行銷活動。

注意：請提醒廣告主不要在完成整合後變更資料集。變更資料集將開始新的整合並重新開啟訓練程序。