‏واجهة API التحويلات‏

إعداد واجهة API التحويلات كمنصة

إذا كنت تقدم إعداد بيكسل Meta كجزء من خدمات إدارة العلامات، فقد تحتاج إلى النظر في إضافة وظائف واجهة API التحويلات. يتيح الدمج مع واجهة API التحويلات لعملائك إرسال أحداث الويب إلى Meta مباشرة، من دون الحاجة إلى الاعتماد على أحداث بيكسل المتصفح.

أحداث الخادم مقابل أحداث المتصفح

قبل البدء، من المهم فهم العلاقة بين أحداث الخادم وبيكسل Meta. يتم إرسال أحداث الخادم عبر واجهة API التحويلات واستخدامها في القياس وإعداد التقارير والتحسين بطريقة أحداث بيكسل المتصفح نفسها.

إذا كان إرسال أحداث بيكسل المتصفح يشبه إرسال البريد عبر البريد الجوي، فإن إرسال أحداث الخادم يشبه إرسال البريد عبر الشحن. كلاهما آليتان لنقل الطرود (بيانات حول حدث ما) إلى عنوان الوجهة (معرف البيكسل). لذلك، نوصي بشدة بإنشاء دمج واجهة API التحويلات على منصتك كامتداد لبيكسل Meta الحالي الذي توفره (بدلاً من توفيره كمكون إضافي أو خدمة منفصلة) للأسباب التالية:

  • تستخدم أحداث الخادم معرف البيكسل كوجهة
  • تتم معالجة أحداث الخادم بالطريقة نفسها التي يتم بها إرسال أحداث بيكسل المتصفح مرة واحدة إلى فيسبوك
  • إلغاء التكرار سيكون أسهل في التنفيذ
  • سهولة الاستخدام بالنسبة للعملاء. على سبيل المثال، يمكن إرسال أحداث الخادم إلى جانب أحداث المتصفح، افتراضيًا.

بمجرد دمج منصتك مع واجهة API التحويلات، نوصي بإرسال أحداث الويب نفسها عبر المتصفح والخادم. يساعد هذا التكرار في ضمان موثوقية الإشارة. الأحداث التي كان من الممكن أن يتم فقدانها في السابق من جانب المتصفح، لأسباب متنوعة تتعلق بالشبكة، يتم الآن استقبالها عبر واجهة API التحويلات.

لإرسال الأحداث عبر المتصفح والخادم، يجب تعيين event_id نفسه بشكل صحيح للأحداث المقابلة. هذا يسمح لفيسبوك بإلغاء تكرار الأحداث بشكل صحيح.

المتطلبات الأساسية

  1. منصة ويب قادرة على مشاركة الأحداث على فيسبوك. على سبيل المثال، أداة إنشاء مواقع الويب أو مدير العلامات أو منصة AdTech.
  2. إشعار مناسب للمستخدمين لديك وموافقتهم على مشاركة بيانات الأحداث مع فيسبوك، وفقًا لما تقتضيه شروط أدوات الأعمال من فيسبوك.
  3. ممثل فيسبوك
  4. متطلبات دمج واجهة API التحويلات القياسية:

لبدء عرض واجهة API التحويلات كمنصة، يجب أن يخضع تطبيقك لعملية مراجعة التطبيق. أثناء العملية، يجب طلب مستوى الوصول التالي والميزة والأذونات التالية:

البدء

إذا كانت هذه هي المرة الأولى التي تستخدم فيها واجهة API التحويلات، فاتبع هذه الخطوات لإنشاء نشاط تجاري وتطبيق Meta وبيكسل Meta ومستخدم نظام. بعد ذلك، ستتمكن من استخدام رمز وصول مستخدم النظام لإرسال أحداث الخادم عبر واجهة API التحويلات.

الخطوة الأولى: إنشاء نشاط تجاري.

الخطوة الثانية: إنشاء تطبيق Meta ضمن النشاط التجاري الذي تم إنشاؤه حديثًا.

الخطوة الثالثة: إنشاء بيكسل Meta ضمن النشاط التجاري الذي تم إنشاؤه حديثًا:

الخطوة الرابعة: إنشاء رمز وصول مستخدم النظام.

الخطوة الخامسة: إرسال حدث خادم إلى بيكسل Meta.

إرسال الأحداث نيابةً عن العملاء

بمجرد إرسال حدث خادم بنجاح إلى بيكسل Meta، ستتوفر لديك خيارات حول كيفية إرسال الأحداث نيابةً عن عملائك.

بالنسبة إلى بيكسل Meta التي يملكها أو يديرها مدير أعمال الشريك

  1. في مدير الأعمال، انتقل إلى قسم المستخدمون وحدّد علامة التبويب مستخدم النظام. انقر على مستخدم النظام المحدد الذي تستخدمه في واجهة API التحويلات.
  2. انتقل إلى مربع حوار تعيين الأصل واختر أحداث البيكسل. بعد ذلك، حدّد أحداث البيكسل التي تريد إرسال الأحداث نيابةً عنها.
  3. لكل بيكسل، حدّد الإذن إدارة البيكسل وانقر على حفظ التغييرات.
  4. عد إلى صفحة تفاصيل مستخدم النظام. تأكد من أن أحداث البيكسل المحددة مرئية هناك.

بالنسبة إلى أحداث بيكسل Meta التي لا يديرها الشريك

يجب أولاً طلب التصريح لإرسال الأحداث نيابةً عن عملائك. تتوفر لديك خيارات المصادقة التالية:

ملحق فيسبوك للأعمال (موصى به)

من خلال هذا الخيار، يقوم ملحق فيسبوك للأعمال (FBE) بإرجاع جميع المعلومات الضرورية اللازمة لإرسال الأحداث نيابةً عن العميل عبر العملية التالية. يوفر ملحق FBE نقطة نهاية لاسترداد رموز وصول مستخدم النظام التي تم إنشاؤها في مدير الأعمال الخاص بالعميل. تتضمن هذه العملية أذونات لإرسال أحداث الخادم وتتم تلقائيًا وبطريقة آمنة.

تتطلب نقطة النهاية وجود رمز وصول للمستخدم كمعلمة إدخال. بالنسبة لمستخدمي ملحق FBE الجدد، يمكن استدعاء نقطة النهاية هذه للحصول على رمز وصول مستخدم النظام بعد الانتهاء من إعداد ملحق FBE. بينما يحتاج المستخدمون الحاليون إلى طلب إعادة المصادقة قبل استدعاء نقطة نهاية API الجديدة.

رمز وصول مستخدم نظام من جانب العميل

من خلال هذا الخيار، يجب أن تجعل عميلك يقوم بإنشاء رمز وصول مستخدم النظام يدويًا عبر واجهة API التحويلات داخل إعدادات البيكسل. يمكنك بعد ذلك إرسال الأحداث إلى بيكسل المعلن باستخدام هذا الرمز.

يجب على مستخدم النظام أو مستخدم النظام المسؤول تثبيت التطبيق الذي سيتم استخدامه لإنشاء رمز الوصول. باستخدام هذا الإعداد، يسمح للتطبيق باستدعاء واجهات API نيابةً عن مستخدم النظام أو مستخدم النظام المسؤول هذا.

اتبع وثائق بدء الاستخدام واطلب رمز مستخدم النظام من المعلن. تذكر استخدام بيكسل Meta ورمز الوصول للاختبار.

مشاركة العميل لبيكسل Meta مع مدير أعمال الشريك

من خلال هذا الخيار، يشارك العميل بيكسل Meta مع الشريك عبر إعدادات مدير الأعمال أو عبر API. بعد ذلك، يمكنك تعيين مستخدم نظام الشريك إلى بيكسل العميل وإنشاء رمز وصول لإرسال أحداث الخادم.

إسناد الأحداث إلى المنصة باستخدام الحقل partner_agent

لإسناد أحداث واجهة API التحويلات إلى منصتك، استخدم الحقل partner_agent. يسمح لك هذا بتعيين معرف المنصة عند إرسال الأحداث نيابةً عن العميل. تعاون مع ممثل فيسبوك للاتفاق على معرف لمنصتك. بعد ذلك، يجب عليك إرساله مع كل حدث خادم.

عينة من حمولة بيانات الحدث

إذا كان معرف المنصة هو 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.

الرابط الثابت