يشرح هذا الدليل كيفية تسجيل أحداث التطبيق وأحداث صفحة فيسبوك لتحليل كيفية تفاعل المستخدمين مع تجربة 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:
الخاصية | الوصف | القيمة |
---|---|---|
| تمثل مصفوفة من الأحداث التي تريد تسجيلها. ويمكنك الرجوع إلى دليل واجهة API أحداث التطبيق للحصول على قائمة من الأحداث القياسية والمعلمات المعمول بها. كما يمكنك استخدام أحداث التطبيق الخاصة بك. ويمكنك تحديد عدة أحداث في المصفوفة. | استخدم مصفوفة مشفّرة بلغة JSON لتحديد تفاصيل الحدث المخصص لديك. |
| تحدد معرف الصفحة المرتبط بالحدث. | استخدم معرف صفحة فيسبوك الخاص بالصفحة المرتبطة بالبرنامج التلقائي. |
| يمكن تحديد معرف المستخدم على مستوى الصفحة المرتبط بالبرنامج التلقائي في messenger والذي يسجّل الحدث. | استخدم معرف المستخدم على مستوى الصفحة والمتوفر في حدث webhook لديك. |
| يمكن تحديد ما إذا تم تمكين تتبع الإعلانات أم لا. | استخدم القيمة |
| يمكن تحديد ما إذا تم تمكين تتبع الإعلانات أم لا على مستوى التطبيق. | استخدم القيمة |
| تحدد مصدر الحدث. | استخدم السلسلة |
| تحدد الكيانات المستهدفة التي سيتم تسجيل الحدث لها. | استخدم السلاسل |
بإمكان التطبيقات الآن بدء الإبلاغ عن عروض العملاء المحتملين المقدمة في سلاسل الرسائل. يسمح الحدث lead_submitted
للتطبيقات بأتمتة الإبلاغ عن السلاسل التي تعتبر بيانات عميل محتمل في المبيعات (مثل مشاركة المستخدم لمعلومات الاتصال وطلب التواصل معه بشأن عملية البيع).
يتمثل أفضل استخدام للحدث في تمييز مستخدمين محددين باعتبارهم عملاء محتملين، الأمر الذي من شأنه أن يساعد الأنشطة التجارية في إعطاء الأولوية لسلاسل الرسائل الواردة من جانبهم. على سبيل المثال، يمكن للنشاط التجاري إعداد دفق مؤتمت يؤهل المستخدم ليصبح عميل محتمل، ويقوم بتشغيل هذا الحدث عندما يكمل المستخدم هذا الدفق لإشارة بذلك إلى الوكيل المباشر باعتبار الحدث سلسلة رسائل عالية الإمكانات.
في الوقت الحالي، تتوفر هذه الميزة في الإصدار التجريبي المفتوح وتم دمج إعداد التقارير في مدير الإعلانات، حتى يتم عرض بيانات العملاء المحتلمين في واجهة مستخدم مدير الإعلانات.
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 هذه، يمكنك إنشاء لوحة معلومات تحليلات متقدمة للمساعدة في عرض بيانات العميل المحتمل المنسوبة لحملات 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
للحصول على تعريف مفصل حول أنواع الإجراءات أعلاه، راجع مرجع إحصاءات إجراءات الإعلانات.
ملاحظة: نوصي بعدم تمييز كل محادثة تلقائيًا برقم الهاتف أو عنوان البريد الإلكتروني كبيانات عميل محتمل، خاصةً في الأسواق حيث تتم فيها مشاركة أرقام الهواتف لأغراض عمليات الدفع/التجارة الإلكترونية.
إذا كنت مسؤول تطبيق أو صفحة، فيمكنك التحقق مما إذا كان الإعداد صحيحًا من خلال البحث عن الأحداث في مدير الإعلانات.
fb_messenger_bot_stopped
.عادةً ما تستخدم المنصات التي تتيح للأشخاص تطوير تجارب Messenger من خلال الواجهات المرئية تطبيقًا مركزيًا واحدًا لتشغيل كل صفحاتها المرتبطة. ولتمكين عملائك من عرض أحداثهم الخاصة، يجب تسجيلها في صفحات العملاء من خلال تعيين logging_target
إلى page أو app_and_page.
في سياق المحرر المرئي، يمكنك تقديم قالب قابل للسحب يسمح للأشخاص باختيار حدث وتحديد معلمات إضافية. وهذا يسمح لمسؤولي الصفحة بتعيين تدفق Messenger باستخدام الأحداث المناسبة. بشكل مثالي، يجب أن يتمكن المستخدمون من تحديد اسم حدث قياسي في القائمة المنسدلة، حيث يتم إعداد تقارير الأحداث القياسية فقط في مدير الإعلانات وتكون متوفرة لاستهداف الإعلانات وتحسينها (عند توفرها). إذا لم يكن هناك اسم حدث قياسي يتوافق مع إجراء المستخدم ولم تكن هناك حاجة إلى إعداد تقارير الإعلانات، فقد يتعين توفير حقل بنص حر للسماح للمستخدمين بإدخال المعلمات واسم الحدث المخصص.
يجب الحصول على الإذن page_events
المطلوب أثناء تدفق تسجيل دخول فيسبوك في تطبيقك. ويجب إضافته إلى نطاق إذن زر تسجيل الدخول المطلوب أو استدعاء مجموعة Facebook SDK للغة JavaScript أو تدفق تسجيل الدخول الذي تم تطويره يدويًا كما هو موضح في هذا الدليل.