CAPI للعقارات: إزاي ترجع نتيجة متابعة حقيقية لإعلانات Meta؟

إيه المشكلة اللي CAPI بيحلها؟

في رحلة الاستفسار، قد توجد نتيجة مؤكدة في الخادم أو CRM لا يظهر معناها كاملًا في قياس المتصفح. CAPI يوفر قناة لإرسال الحدث ضمن إعدادات المنصة؛ تصميم النتيجة وجودة البيانات يظلان مسؤولية الفريق.

هذا الدليل يشرح خريطة العمل والاختبار، وليس تكاملًا جاهزًا أو إثباتًا أن جميع أحداث CRM تُرسل حاليًا. الربط يتوقف على الأدوات والحقول المتاحة وما يسمح به استخدام البيانات.

اختار نتيجة فعلية قبل اسم الحدث

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

اختار الحدث المدعوم والمناسب لإعداد الحساب؛ لا تنسخ أسماء GA4 إلى Meta تلقائيًا. لا تسمّ إرسال نموذج Purchase أو تعرضه كبيع لمجرد أن هذه التسمية تبدو أقوى في التقرير.

هتطلب ربط CAPI بـCRM؟ اتفق على التسليم ده الأول

قبل ما تبدأ Integration، اطلب خريطة بتربط CRM Stages بالـEvents: إيه اللي يفعّل كل Event، ومين مسؤول عنه، وإزاي هتختبره بعيدًا عن تقارير الليدز الفعلية. Screenshot إن الـEvents وصلت مش كفاية تعرف منه إن المرحلة صح أو إن الـRetry ما كررش نفس النتيجة.

اتفق مين مسؤول عن البيانات في CRM، ومين يتابع الإرسال الفاشل، ومين يراجع معنى النتيجة. بيانات التواصل مكانها مسار الربط المعتمد؛ متبعتهاش لـGA4 عشان تسهّل المطابقة. تسليم CAPI معناه مسار إرسال واختبار واضح، مش وعد باستعادة كل الإشارات أو زيادة المبيعات.

على الموبايل، اسحب الجدول أفقيًا لقراءة بقية الأعمدة.

مثال تعليمي لهوية الحدث ومنع التكرار

Meta يوضح في مرجع SDK أن event_id مع event_name يساعدان في التعرف على الحدث نفسه المرسل من الخادم والمتصفح. المثال التالي لتوضيح الهوية فقط، وليس payload جاهزًا أو اسمًا مفروضًا لكل مرحلة.

على الموبايل، اسحب الجدول أفقيًا لقراءة بقية الأعمدة.

مرجع تقني أصلي: Meta Business SDK: server event fields and deduplication identity

راجع التوقيت والمصدر والحقول المطلوبة

سجّل وقت حدوث النتيجة الحقيقي؛ event_time في مرجع Meta هو Unix timestamp بالثواني. لا تستبدله بوقت كل محاولة إرسال. وaction_source يصف المكان الذي حدثت فيه النتيجة، فلا تفترض أن كل نتيجة مبيعات مصدرها website.

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

قائمة اختبار قبل وبعد التشغيل

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

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

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

إمتى نعتبر المراجعة مفيدة؟

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

CAPI لا يضمن تجاوز قيود المنصات أو استعادة 100% من الإشارات أو مضاعفة ROAS. لو محتاج تبدأ، جهّز خريطة المراحل وأرقامًا مجمعة؛ لا تبدأ بإرسال بيانات العملاء أو صلاحيات الحسابات في نموذج التواصل.