Conversions API من Meta: ما هي ولماذا لم يعد البكسل كافيًا

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

وُجدت Conversions API من Meta (أو CAPI) لسد تلك الفجوة. نشرح ما هي، وكيف تُهيأ دون احتساب كل عملية بيع مرتين، وما الذي تراجعه عندما لا تظهر عمليات الشراء.

ما هي Conversions API من Meta

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

لماذا يفقد البكسل أحداثًا

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

• أدوات حظر الإعلانات والتتبع. كثير من الإضافات وبعض المتصفحات تحظر النص البرمجي لـ Meta.
• قيود الكوكيز. يقصّر Safari، بحمايته ITP، وFirefox عمر الكوكيز المنشأة عبر JavaScript. فإذا اشترى المستخدم بعد أيام من النقرة، فقد يكون المتصفح قد نسي من أين جاء.
• App Tracking Transparency في iOS. مستخدمو iPhone الذين يرفضون التتبع بين التطبيقات يقلّصون المعلومات التي تستطيع Meta استخدامها لربط الإعلان بالشراء.
• رفض الموافقة. إذا رفض المستخدم كوكيز الإعلانات، فلا ينبغي أن يعمل البكسل. وهذا هو الصواب، ولا ينبغي أن تصل تلك الأحداث عبر أي مسار.
• صفحات تُغلق قبل الأوان. إذا دفع المستخدم عبر بوابة دفع خارجية ولم يعد إلى صفحة التأكيد، فلن تُرسل عملية الشراء أبدًا.

تحل الـ API الأعطال التقنية، لأن الحدث يخرج من خادمك عند تسجيل الطلب. أما الموافقة فلا تحلها، ولا ينبغي لها ذلك.

البكسل والـ API معًا: كيف تزيل التكرار

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

ولتجنب ذلك، يجب أن يحمل كل حدث القيمة نفسها لـ event_name (مثل Purchase) وevent_id في المسارين. وأنت من يولّد event_id، مثل رقم الطلب. فإذا تلقت Meta حدثين بالاسم والمعرّف نفسيهما خلال وقت قصير، فإنها تحتفظ بواحد.

فضلًا عن ذلك، يُستحسن أن ترسل عبر الـ API كوكيز البكسل، _fbp (معرّف المتصفح) و_fbc (معرّف النقرة، المشتق من fbclid في عنوان URL). وهما لا يحلان محل event_id، لكنهما يساعدان على ربط الحدث بالزيارة والنقرة.

بيانات العملاء وجودة المطابقة

لا يحمل حدث الخادم جلسة المتصفح، لذا تحتاج Meta إلى معرفة من اشترى بطريقة أخرى: معلمات معلومات العميل، أي البريد الإلكتروني والهاتف والاسم واسم العائلة والمدينة والرمز البريدي والبلد، أو معرّف خارجي مثل معرّف العميل لديك. وتُوحَّد صيغتها (أحرف صغيرة، دون مسافات، الهاتف مع رمز البلد) وتُشفَّر بـ SHA-256. أما عنوان IP ووكيل المستخدم فيُرسلان دون تشفير.

في مدير الأحداث، لكل حدث درجة جودة مطابقة (Event Match Quality)، من 0 إلى 10، تشير إلى مدى نجاح Meta في ربط أحداثك بمستخدميها. وإذا كانت منخفضة، فغالبًا ما تنقص معلمة ما أو تكون صيغتها غير موحدة. والبريد الإلكتروني والهاتف هما الأكثر وزنًا.

أربع طرق لتطبيقها

1. تكامل عبر شريك

تفعّل Shopify وWooCommerce وكثير من أنظمة CRM الـ API دون برمجة. وهي الطريقة الأسرع، وإن كانت سيطرتك على ما يُرسل محدودة.

2. Conversions API Gateway

حل من Meta يُنشر في سحابتك ويكرر من الخادم أحداث البكسل. عمل تقني قليل، لكنه لا يرسل إلا ما يراه البكسل أصلًا.

3. Google Tag Manager من جهة الخادم

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

4. تكامل مباشر مع الـ API

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

الأحداث غير المتصلة وأحداث CRM عبر الـ API نفسها

تتلقى الـ API أيضًا نتائج تحدث خارج الموقع: عميل محتمل أهّله فريق المبيعات، أو بيع عبر الهاتف، أو شراء في المتجر. وتُرسل إلى مجموعة البيانات نفسها مع الإشارة إلى مصدرها، وتنسبها Meta تمامًا كعملية شراء عبر الإنترنت. نشرح ذلك في كيف ترفع التحويلات غير المتصلة إلى Google Ads وMeta.

الموافقة

الإرسال من الخادم لا يغيّر القواعد: إذا رفض المستخدم الإعلانات المخصصة، فلا ينبغي أن يصل حدثه عبر الـ API أيضًا. يجب أن يعرف خادمك القرار المسجل في CMP الخاص بك وأن يطبقه قبل كل إرسال.

البكسل لا يسجل عمليات الشراء: كيف تشخّص المشكلة

1. استخدم أداة اختبار الأحداث. أجرِ عملية شراء تجريبية وتحقق في مدير الأحداث من أن Purchase يصل من المتصفح أو من الخادم أو من كليهما.
2. راجع تبويب التشخيص. تنبّه Meta إلى المعلمات الناقصة والأحداث غير المزال تكرارها والانخفاضات الحادة في الحجم.
3. تحقق من صفحة التأكيد. إذا انتهى الدفع في بوابة خارجية ولم يعد المستخدم، فلن يعمل البكسل. وهذا هو السبب الأكثر شيوعًا لفقدان عمليات الشراء.
4. قارن بطلباتك. قارن أسبوعًا من عمليات الشراء في Meta بطلبات متجرك الإلكتروني أو ERP. إذا سجلت Meta أقل، فهناك أحداث ناقصة؛ وإذا سجلت أكثر، فالأرجح أنك لا تزيل التكرار.

أخطاء شائعة

• عدم إزالة التكرار. يرسل البكسل والـ API عملية الشراء نفسها دون event_id مشترك فتحتسبها Meta مرتين.
• إرسال بيانات عملاء قليلة. عنوان IP ووكيل المستخدم وحدهما يعطيان مطابقة منخفضة.
• تجاهل الموافقة. إرسال ما رفضه المستخدم عبر الخادم خطر قانوني.
• نسيان القيمة والعملة. دون value وcurrency، لا تستطيع Meta التحسين وفق الإيرادات ولا حساب ROAS.

لدى Google وTikTok ما يعادلها: التحويلات المحسّنة (Enhanced Conversions) في Google Ads وEvents API في TikTok. والمنطق نفسه.

كيف يفعل ذلك Babuin

مع القياس من جهة الخادم في MonkeyFlux، تمر أحداث موقعك وتطبيقك عبر خادم على نطاقك الخاص. وهناك تُطبَّق الموافقة، ويُستبعد تدفق الروبوتات، ويُزال تكرارها بـ event_id، وتُثرى بالهامش أو LTV أو جودة العميل المحتمل من CRM الخاص بك وERP. ثم تصل إلى Meta عبر Conversions API، وإلى Google وTikTok وGA4 عبر Enhanced Conversions أو Events API أو Measurement Protocol. متوافق مع حاوية GTM من جهة الخادم لديك.

وبتلك التحويلات، يمنح Babuin لـ MonkeyBot الإشارة للمزايدة وفق القيمة الحقيقية، ولـ DBA البيانات لتوزيع الميزانية بين القنوات. تحسّن Meta بما تتلقاه؛ والـ API هي التي تحدد كم من عملك يصل إليها.

الأسئلة الشائعة