تسجيل الأحداث من خلال API الأحداث لمراسلات الأعمال

إيقاف استخدام API أحداث المراسلة

  • سيتم إيقاف استخدام API أحداث المراسلة في سبتمبر 2025. استعدادًا لعملية إيقاف الاستخدام، لن يتم دعم API أحداث المراسلة في أي إصدارات مستقبلية لواجهة Graph API، بدءًا من الإصدار 21.0، اعتبارًا من 24 سبتمبر 2024.
  • سيظل الشركاء الذين اختاروا عدم التحديث إلى أحدث إصدار من Graph API قادرين على الوصول إلى API أحداث المراسلة عن طريق استدعاء الإصدار 20.0 أو أي إصدار أقدم من Graph API حتى يتم إيقاف استخدام المنتج رسميًا في سبتمبر 2025.
  • بالنسبة للشركاء الذين لن يحاولوا التحديث إلى أحدث إصدار من Graph API، فإننا نوصي باستخدام واجهة API التحويلات لعمليات الدمج الجديدة. تعرف على المزيد حول واجهة API التحويلات.

يشرح هذا الدليل كيفية تسجيل أحداث التطبيق وأحداث صفحة فيسبوك لتحليل كيفية تفاعل المستخدمين مع تجربة Messenger.

قبل البدء

ستحتاج إلى ما يلي:

  • الإذن page_events
    • سيتم منح إمكانية الوصول المتقدم تلقائيًا إلى هذا الإذن عند الإرسال لمراجعة التطبيقات، إذا كان تطبيقك قد حصل بالفعل على إمكانية الوصول المتقدم للإذن pages_messaging ولا يوجد في تطبيقك أي انتهاكات للسياسة خلال آخر 90 يومًا
  • رمز وصول الصفحة الذي طلبه شخص ما يمكنه تنفيذ المهمة ANALYZE على الصفحة التي يتم الاستعلام عنها

التقييدات

لا تتوفر API هذه حاليًا للأنشطة التجارية أو العملاء الموجودين داخل أوروبا واليابان.

السياسة والشروط

تسجيل الأحداث

يتم تسجيل الأحداث من خلال إرسال طلب POST إلى عنصر الربط page_activities للتطبيق:

https://graph.facebook.com/

مثال على الطلب:

curl -X POST -H "Content-Type: application/json" -d '{
  "custom_events": [
    {
      "_eventName": "fb_mobile_purchase",
      "_valueToSum": 57.23,
      "fb_currency": "USD"
    }
  ],
  "advertiser_tracking_enabled": 1,
  "application_tracking_enabled": 1,
  "page_id": <PAGE_ID>,
  "page_scoped_user_id": <PSID>,
  "logging_source": "messenger_bot",
  "logging_target": "page"
}' https://graph.facebook.com/v21.0/<APP_ID>/page_activities?access_token=<PAGE_ACCESS_TOKEN>

نوصي باستخدام الأحداث القياسية للحقل _eventName. يتم الإبلاغ عن الأحداث القياسية فقط في مدير الإعلانات وتكون متوفرة لاستهداف الإعلانات وتحسينها (عند توفرها).

على سبيل المثال: لتسجيل أحداث الشراء للسمة في مدير الإعلانات، استخدم اسم الحدث fb_mobile_purchase.

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

يتناول الجدول التالي بالتفصيل الخصائص والقيم التي يجب توفيرها في نقطة النهاية لتسجيل أحداث Messenger:

الخاصيةالوصفالقيمة

custom_events

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

استخدم مصفوفة مشفّرة بلغة JSON لتحديد تفاصيل الحدث المخصص لديك.

page_id

تحدد معرف الصفحة المرتبط بالحدث.

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

page_scoped_user_id

يمكن تحديد معرف المستخدم على مستوى الصفحة المرتبط بالبرنامج التلقائي في messenger والذي يسجّل الحدث.

استخدم معرف المستخدم على مستوى الصفحة والمتوفر في حدث webhook لديك.

advertiser_tracking_enabled

يمكن تحديد ما إذا تم تمكين تتبع الإعلانات أم لا.

استخدم القيمة 0 عند التعطيل، والقيمة 1 عند التمكين

application_tracking_enabled

يمكن تحديد ما إذا تم تمكين تتبع الإعلانات أم لا على مستوى التطبيق.

استخدم القيمة 0 عند التعطيل، والقيمة 1 عند التمكين

logging_source

تحدد مصدر الحدث.

استخدم السلسلة messenger_bot للإشارة إلى أن هذا الحدث ناتج من البرنامج التلقائي في Messenger.

logging_target

تحدد الكيانات المستهدفة التي سيتم تسجيل الحدث لها.

استخدم السلاسل app أو page أو app_and_page للتحكم في الكيانات التي ستتلقى هذا الحدث. لمزيد من التفاصيل، راجع الأسئلة المتكررة حول أحداث التطبيق

الإبلاغ عن بيانات العملاء المحتملين باستخدام API حدث المراسلة

بإمكان التطبيقات الآن بدء الإبلاغ عن عروض العملاء المحتملين المقدمة في سلاسل الرسائل. يسمح الحدث lead_submitted للتطبيقات بأتمتة الإبلاغ عن السلاسل التي تعتبر بيانات عميل محتمل في المبيعات (مثل مشاركة المستخدم لمعلومات الاتصال وطلب التواصل معه بشأن عملية البيع).

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

في الوقت الحالي، تتوفر هذه الميزة في الإصدار التجريبي المفتوح وتم دمج إعداد التقارير في مدير الإعلانات، حتى يتم عرض بيانات العملاء المحتلمين في واجهة مستخدم مدير الإعلانات.

مثال على استدعاء API للإبلاغ عن حدث بيانات عميل محتمل يحدث في سلسلة رسائل:

curl -X POST -H "Content-Type: application/json" -d '{
  "custom_events": [
    {
      "_eventName": "lead_submitted"
    }
  ],
  "advertiser_tracking_enabled": 1,
  "application_tracking_enabled": 1,
  "page_id": <PAGE_ID>,
  "page_scoped_user_id": <PSID>,
  "logging_source": "messenger_bot",
  "logging_target": "page"
}' https://graph.facebook.com/v21.0/<APP_ID>/page_activities?access_token=<PAGE_ACCESS_TOKEN>

الإبلاغ عن بيانات العملاء المحتملين باستخدام API رؤى الإعلانات

يمكن عرض حدث بيانات العميل المحتمل الذي تم الإبلاغ عنه باستخدام API رؤى الإعلانات. باستخدام API هذه، يمكنك إنشاء لوحة معلومات تحليلات متقدمة للمساعدة في عرض بيانات العميل المحتمل المنسوبة لحملات CTX.

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

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

التنفيذ

تبدو عينة استدعاء الرؤى على مستوى الحملة الإعلانية كما يلي:

curl -G \
-d "date_preset=last_7d" \
-d "access_token=<ACCESS_TOKEN>" \
"https://graph.facebook.com/<API_VERSION>/<AD_CAMPAIGN_ID>/insights"
    

يمكن استدعاء API الرؤى على مستوى الحساب الإعلاني أو الحملة الإعلانية أو المجموعة الإعلانية اعتمادًا على مستوى الدقة المطلوب.

فيما يلي الاستدعاء المطلوب للحصول على بيانات عميل محتمل:

  • بيانات العملاء المحتملين (المسندة)
    • /<OBJECT_ID>/insights?fields=actions
    • في النتيجة، action_type=onsite_converstion.lead_grouped

للحصول على تعريف مفصل حول أنواع الإجراءات أعلاه، راجع مرجع إحصاءات إجراءات الإعلانات.

أفضل ممارسات تصنيف بيانات العملاء المحتملين

  1. المعلن الموجود في أحد مجالات تجميع بيانات العملاء المحتملين العادية (تلقائي، خدمات احترافية، خدمات مالية، معاملات شركات، التعليم، الصحة).
  2. يطلب المعلن معلومات الاتصال مثل رقم الهاتف أو عنوان البريد الإلكتروني ويقدمها المستخدم.
  3. يسبق أسئلة رقم الهاتف أو عنوان البريد الإلكتروني نوع من أنواع اختبارات التأهيل (مثل، سؤال أو سؤالين إضافيين).
  4. إذا كنت توفر قوالب تجميع بيانات العملاء المحتملين في التطبيق، فأضف هذه الإشارة في نهاية تدفقات تجميع بيانات العملاء المحتملين بشكل افتراضي.

ملاحظة: نوصي بعدم تمييز كل محادثة تلقائيًا برقم الهاتف أو عنوان البريد الإلكتروني كبيانات عميل محتمل، خاصةً في الأسواق حيث تتم فيها مشاركة أرقام الهواتف لأغراض عمليات الدفع/التجارة الإلكترونية.

التحقق من تسجيل الحدث

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

اعتبارات خاصة للتحليلات في Messenger

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

الاستخدام من جانب موفري المنصة

تسجيل الهدف

عادةً ما تستخدم المنصات التي تتيح للأشخاص تطوير تجارب Messenger من خلال الواجهات المرئية تطبيقًا مركزيًا واحدًا لتشغيل كل صفحاتها المرتبطة. ولتمكين عملائك من عرض أحداثهم الخاصة، يجب تسجيلها في صفحات العملاء من خلال تعيين logging_target إلى page أو app_and_page.

واجهة المستخدم

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

الأذونات

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

الموارد الإضافية