واجهة API التحويلات من Meta للدفع عند الاستلام: كيف تُبلغ MyLeadDone منصة Meta بالطلبات المُسلَّمة فعلاً

أصبحت MyLeadDone تُرسل حدث الشراء (Purchase) إلى مجموعة بيانات Meta الخاصة بك عبر واجهة API التحويلات (Conversions API) عندما يُسلَّم طلب الدفع عند الاستلام — وليس عندما يملأ العميل نموذج الطلب. بهذا يعرف حسابك الإعلاني الطلبات التي وصلت فعلاً إلى العميل ودُفع ثمنها عند الباب، بدل أن تتوقف معلوماته عند العميل المحتمل (Lead).

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

باختصار: ماذا يفعل تكامل MyLeadDone مع Meta؟

• متى يُرسل الحدث: عندما تصبح حالة الطلب مُسلَّم — أي، في الدفع عند الاستلام، اللحظة التي يدفع فيها العميل لعامل التوصيل. لا يُرسل شيء عند إنشاء الطلب أو إلغائه أو رفضه أو إرجاعه.
• الحدث: حدث Purchase واحد من جهة الخادم لكل طلب مُسلَّم، بمبلغ الطلب بالدرهم المغربي (MAD)، يُرسل عبر واجهة API التحويلات من Meta إلى مجموعة البيانات الخاصة بك — المرتبطة ببيكسل Meta لديك.
• المطابقة: معلومات العميل بعد تجزئتها (رقم الهاتف والاسم والمدينة والبلد)، إضافة إلى معرّف النقر من فيسبوك ومعرّف المتصفح من Meta وعنوان IP ووكيل المستخدم (User Agent) متى توفّرت في الطلب.
• البيكسل: يواصل البيكسل قياس ما يحدث داخل المتصفح، وتضيف MyLeadDone البيع المُسلَّم الذي لا يستطيع المتصفح رؤيته أبداً. فهي لا تحلّ محلّ البيكسل.
• ضمانات: حدث Purchase واحد كحدٍّ أقصى لكل طلب، وإعادة محاولة تلقائية عند الأخطاء المؤقتة، وعلامة Meta ✓ على كل طلب أكّدت Meta استلام حدثه.

المشكلة الخفية في إعلانات الدفع عند الاستلام

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

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

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

والنتيجة تشويه صامت لكنه مكلف. فالحملة التي تجلب كثيراً من النماذج الرخيصة تبدو ناجحة، حتى لو تحوّل القليل منها إلى طرود مُسلَّمة. والحملة التي تجلب مشترين أقل عدداً لكن أكثر جدية تبدو أضعف مما هي عليه. وعندما يُوجَّه العرض الآلي للإعلانات نحو «الأشخاص الذين يملؤون النماذج»، فإنه يُوجَّه نحو الهدف الخطأ بالنسبة إلى تجارة قائمة على الدفع عند الاستلام.

لماذا لا يُعدّ العميل المحتمل بيعاً في الدفع عند الاستلام؟

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

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

ببساطة: عبارة «شخص ملأ نموذجاً» وعبارة «شخص ملأ نموذجاً واستلم المنتج ودفع ثمنه» تصفان واقعتين مختلفتين تماماً. الثانية وحدها هي البيع. والنظام الإعلاني لا يتعلّم إلا من الوقائع التي تصله، ولهذا فإن ما تُبلغ به Meta أمر مهم.

ما هي واجهة API التحويلات من Meta؟

واجهة API التحويلات من Meta (Meta Conversions API، وتُختصر إلى CAPI) هي اتصال مباشر بين الخوادم يتيح للشركة إرسال أحداث التحويل من أنظمتها الخاصة إلى Meta مباشرة، دون الاعتماد فقط على شيفرة تعمل داخل متصفح الزائر. وتصفها Meta بأنها صلة بين البيانات التسويقية للمعلن — مثل أحداث المواقع والتطبيقات والرسائل والتحويلات التي تتم خارج الإنترنت — وبين أنظمة Meta التي تحسّن استهداف الإعلانات وتخفّض تكلفة النتيجة وتقيس الأداء (Meta for Developers).

ثلاث أفكار تستحق المعرفة:

• الأحداث. يُرسل كل تحويل على شكل حدث له اسم. حدث Purchase القياسي يعني أن عملية شراء قد تمّت، ويتطلّب قيمة وعملة؛ أما Lead فيعني اكتمال تسجيل (الأحداث القياسية في Meta).
• معلومات العميل للمطابقة. لربط الحدث بشخص على فيسبوك أو إنستغرام، يحمل الحدث معلومات عن العميل. تُوحَّد صيغة البيانات الشخصية مثل رقم الهاتف والاسم والمدينة والبلد، ثم تُجزَّأ بخوارزمية SHA-256 قبل إرسالها، بينما تُرسل معرّفات المتصفح، مثل ملفات تعريف الارتباط الخاصة بمعرّف النقر ومعرّف المتصفح، كما هي (معلمات معلومات العميل).
• الأحداث خارج الإنترنت. ليست كل المبيعات تتم على موقع إلكتروني. وتقول Meta إن واجهة API التحويلات هي طريقة التكامل التي توصي بها لإرسال الأحداث التي تتم خارج الإنترنت وفي المتاجر الفعلية، لاستخدامها في قياس الإعلانات والإسناد والاستهداف (الأحداث خارج الإنترنت).

هذه النقطة الأخيرة هي الأهم في الدفع عند الاستلام. فالطلب المُسلَّم بيعٌ يكتمل وجهاً لوجه عند باب العميل، بعد أيام من النقرة. إنه بالضبط نوع التحويل الذي لا يستطيع المتصفح الإبلاغ عنه — ويستطيع ذلك خادمٌ يعرف نتيجة التوصيل.

بيكسل Meta وواجهة API التحويلات: كيف يعملان معاً؟

بيكسل Meta وواجهة API التحويلات أداتان متكاملتان، لا متنافستان. البيكسل شيفرة موضوعة في صفحات متجرك، تُبلغ عمّا يفعله الزوار في متصفحاتهم، مثل مشاهدة منتج أو بدء عملية الطلب. أما واجهة API التحويلات فتُبلغ عن الأحداث من خادم — وهنا خادم MyLeadDone — بما في ذلك أحداث تقع بعد مغادرة الزائر للموقع بوقت طويل.

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

هل تحلّ واجهة API التحويلات محلّ بيكسل Meta؟

لا. لا تُثبّت MyLeadDone أي بيكسل ولا تحذف البيكسل الخاص بك. احتفظ ببيكسل Meta لأحداث التصفح والطلب، وستضيف MyLeadDone حدث Purchase من جهة الخادم للحدث الوحيد الذي لا يستطيع المتصفح رؤيته: الطلب المُسلَّم.

تعديل واحد ضروري: متى يُطلق البيكسل حدث «Purchase»؟

كثير من متاجر الدفع عند الاستلام تُطلق حدث Purchase من البيكسل بمجرد إرسال نموذج الطلب، لأنها آخر لحظة يكون فيها المتصفح حاضراً. وبمجرد أن تُبلغ MyLeadDone عن Purchase عند التسليم، سيحتسب هذا الإعداد كل طلب مُسلَّم مرتين — مرة كنموذج ومرة كبيع — وسيستمر في احتساب كل نموذج لم يتحوّل إلى بيع. ولا تستطيع آلية إزالة التكرار في Meta دمج الحدثين، لأنهما حدثان منفصلان يفصل بينهما عدة أيام.

الحل بسيط: غيّر حدث البيكسل الذي يُطلق عند إرسال النموذج إلى Lead أو InitiateCheckout، واترك حدث Purchase الخاص بالطلب المُسلَّم يأتي من MyLeadDone. هكذا يعبّر اسم كل حدث بصدق عمّا حدث فعلاً.

كيف تُغلق MyLeadDone حلقة التحويل في الدفع عند الاستلام؟

معظم تكاملات واجهة API التحويلات تجيب عن سؤال واحد: كيف نُرسل حدثاً إلى Meta؟ وفي الدفع عند الاستلام، هذا هو الجزء السهل. أما الجزء الصعب فهو معرفة أيّ الطلبات تستحق أن يُبلَّغ عنها كمبيعات — وهذه المعرفة لا توجد إلا حيث تُؤكَّد الطلبات وتُتابَع وتُسلَّم.

وهذا بالضبط ما تقوم به MyLeadDone أصلاً: تستورد الطلب، ويؤكّده موظفوها عبر الهاتف، وتُطلع العميل على المستجدات عبر واتساب، وتتابع الطرد مع شركة التوصيل، وتسجّل التسليم. ويربط تكامل Meta الخطوة الأخيرة من هذا المسار التشغيلي بالخطوة الأولى من المسار الإعلاني.

القيمة لا تكمن في استدعاء الواجهة البرمجية، بل في كل ما يسبقه: فكل حدث Purchase تُرسله MyLeadDone مرّ بمكالمة تأكيد، ومتابعة مع شركة التوصيل، وتسليم مُسجَّل. تربط MyLeadDone الإعلان ← الاستقطاب ← التأكيد ← المتابعة ← التسليم ← إشارة التحويل في مسار عمل واحد.

المسار الكامل خطوة بخطوة

1. الاستقطاب: وصول الطلب إلى MyLeadDone

تصل الطلبات من قنوات البيع التي يستخدمها المتجر أصلاً:

• Shopify، عبر Webhook لإنشاء الطلبات.
• YouCan، عبر سكربت يُضاف إلى المتجر.
• Google Sheets، حيث يُرسل سكربت خاص بالجدول كل صف جديد.
• متجر مخصّص، عبر واجهة API الخاصة بالطلبات في MyLeadDone.

عند الاستيراد، تحتفظ MyLeadDone أيضاً بالمعرّفات الإعلانية التي تتيح لاحقاً لـMeta ربط البيع بالنقرة على الإعلان: معرّف النقر من فيسبوك (fbclid)، وقيم ملفات تعريف الارتباط ‎_fbc و‎_fbp، إضافة إلى عنوان IP ووكيل المستخدم الخاصين بالمشتري عند توفّرهما. في Shopify تُقرأ هذه القيم من رابط صفحة الوصول ومن خصائص الملاحظات (note attributes) في الطلب، حيث تحفظها كثير من تطبيقات نماذج الدفع عند الاستلام. وفي Google Sheets يمكنك ربط أعمدة اختيارية مخصّصة لها، كما تقبلها واجهة API الخاصة بالطلبات كحقول. وتُحفظ هذه القيم كما وصلت تماماً، لأن تغيير حرف واحد في معرّف النقر كفيل بإفشال الإسناد.

2. التأكيد: محادثة حقيقية قبل أي شحن

يُؤكَّد كل طلب عبر الهاتف. يتصل موظفو MyLeadDone بالعميل، ويؤكّدون المنتج والكمية وعنوان التوصيل، ثم يسجّلون النتيجة: مؤكَّد، أو لا يجيب، أو يتعذّر الوصول إليه، أو رقم خاطئ، أو مؤجَّل، أو ملغى. ويمكنهم أيضاً تأكيد عرض إضافي (Upsell) أثناء المكالمة. وإذا وصل طلب جديد من رقم الهاتف نفسه خلال 48 ساعة، يُوسَم الطلب لكي يكتشف الموظفون التكرار قبل شحن أي طرد مرتين. أما الطلب الذي يتعذّر تأكيده حتى نهاية مهلة التأكيد الممتدة ثلاثة أيام، فيُغلق بوصفه غير مؤكَّد، ولا يصل أبداً إلى شركة التوصيل.

واتساب يدعم المكالمة ولا يحلّ محلّها. فعندما لا يُجاب على مكالمة اليوم الأول، يتابع الموظف مع العميل برسالة واتساب مُعدّة مسبقاً. وبعد تأكيد الطلب، يتلقى العميل رسالة تأكيد تلقائية عبر واتساب (عند تفعيل إشعارات واتساب للمتجر)، ويُنشأ الطرد لدى شركة التوصيل التي يعتمدها المتجر.

3. المتابعة: إبقاء التوصيل على المسار الصحيح

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

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

اللحظة التي يتحوّل فيها الطلب إلى تحويل حقيقي

ترتبط MyLeadDone بشركات توصيل مغربية مثل Sendit وAmeex وOzon وOLivraison وDigylog. وتُبلغ شركات التوصيل عن حالات الطرود إما فوراً عبر Webhook، وإما عبر عمليات تحقّق من الحالة تُجريها MyLeadDone عدة مرات في اليوم. وتُطابَق كل حالة من شركة التوصيل مع حالة في MyLeadDone، ولا ينتقل الطلب إلى حالة «مُسلَّم» إلا عبر حالة تعني أن الطرد سُلِّم فعلاً — أي، في الدفع عند الاستلام، سُلِّم مقابل الدفع. وأي حالة لا تتعرّف عليها MyLeadDone لا تُعامل أبداً على أنها تسليم. كما يمكن للموظفين تسجيل التسليم يدوياً.

هذا التغيير في الحالة هو محور النظام بأكمله. إنه اللحظة التي يصبح فيها بيع الدفع عند الاستلام حقيقياً، وهو يُطلق أمرين في آنٍ واحد:

• احتساب تكلفة الطلب على المتجر وفق تسعير MyLeadDone لكل طلب مُسلَّم؛
• وإدراج حدث Purchase في قائمة الإرسال إلى Meta.

فوترتك وإشارتك الإعلانية تتقاسمان التعريف نفسه للنجاح: طلب مُسلَّم.

كيف تُرسل MyLeadDone حدث الشراء إلى Meta؟

عندما ينتقل الطلب إلى حالة «مُسلَّم» ويكون تكامل Meta مفعّلاً لدى المتجر، تُدرج MyLeadDone الحدث في قائمة الإرسال فوراً وتُرسله من خوادمها إلى مجموعة بيانات Meta الخاصة بالمتجر. وقبل الإرسال مباشرة، تتحقّق مجدداً من أن الطلب ما زال مُسلَّماً. كما أن إرسال الحدث لحظة وقوع البيع يتوافق مع أفضل ممارسات Meta، التي تشير إلى أن مشاركة الأحداث عند حدوثها تساعد الحملات على تحقيق أفضل النتائج (أفضل ممارسات واجهة API التحويلات).

ماذا يتضمّن حدث الشراء؟

ضمانات مدمجة

• الطلبات المُسلَّمة فقط. الطلبات المعلّقة أو الملغاة أو المرفوضة أو المُرجَعة أو غير المتوفرة في المخزون لا تُنتج أبداً حدث Purchase.
• مرة واحدة لكل طلب. يُبلَّغ عن كل طلب مُسلَّم مرة واحدة كحدٍّ أقصى، حتى لو حُفظت حالته مرتين أو أُعيدت محاولة الإرسال.
• إعادة محاولة تلقائية. تُعاد محاولة الأخطاء المؤقتة، مثل مشكلات الشبكة أو تجاوز حدود الطلبات، عدة مرات بفواصل زمنية متزايدة. وإذا رفضت Meta رمز الوصول، يتوقف الإرسال مؤقتاً ويطلب منك التكامل إعادة الربط.
• لا حدث دون وسيلة للمطابقة. الطلب الذي لا يحمل مبلغاً، أو لا يحمل أي معرّف صالح مثل رقم هاتف صحيح، يُتجاوَز مع توضيح السبب.
• تحقّق لا افتراض. لا تظهر علامة Meta ✓ على الطلب إلا بعد أن تؤكّد Meta استلام الحدث؛ أما الطلب المُسلَّم الذي لم يصل تأكيده فتظهر عليه علامة Meta —. وتعرض صفحة «سجل Meta» كل حدث بحالته: مُرسَل، أو قيد الانتظار، أو فاشل، أو مُتجاوَز.
• رمز وصول محميّ. يُشفَّر رمز الوصول، ولا يُرسل إلى Meta إلا داخل ترويسة طلب آمنة، ولا يُعرض مرة أخرى بعد حفظه.

طريقة الإعداد

1. في مدير الأحداث (Events Manager) من Meta، افتح مجموعة البيانات (البيكسل) التي تستخدمها إعلاناتك، وانسخ معرّف مجموعة البيانات.
2. من الإعدادات الخاصة بمجموعة البيانات، وضمن قسم Conversions API، أنشئ رمز وصول.
3. في MyLeadDone، افتح Intégrations → Marketing & Publicité → Meta Ads، والصق القيمتين ثم احفظ.
4. اختيارياً، أضف رمز حدث اختبار من تبويب اختبار الأحداث في مدير الأحداث، ليظهر الاختبار لدى Meta دون أن يُحتسب.
5. انقر على Tester & activer (اختبار وتفعيل). تُرسل MyLeadDone حدثاً انطلاقاً من طلب مُسلَّم حقيقي من متجرك، وتُفعّل الإرسال إذا نجح الاختبار — لذلك تحتاج إلى طلب واحد على الأقل سُلِّم خلال الشهرين الأخيرين. ودون رمز اختبار، يكون هذا الحدث الأول عملية Purchase حقيقية لآخر طلب مُسلَّم لديك.

لماذا تهمّ إشارات الطلبات المُسلَّمة في إعلانات Meta؟

يتعلّم النظام الإعلاني في Meta من التحويلات التي تصله ويستطيع ربطها بأشخاص. وعندما يكون التحويل الوحيد نموذجاً، تُكافأ الحملة على إنتاج النماذج. أما إضافة حدث Purchase للطلب المُسلَّم فتغيّر ما يمكن للحساب الإعلاني رؤيته على ثلاثة مستويات:

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

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

مثال عملي على الدفع عند الاستلام

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

ينفق متجر 30,000 درهم على إعلانات Meta خلال شهر. تُنتج حملاته 1,000 نموذج طلب. وبعد استبعاد الطلبات المكرّرة والأرقام الوهمية والطلبات غير الصالحة، يبقى 700 طلب صالح. يؤكّد الموظفون 500 منها، وتُسلّم شركات التوصيل 320 طلباً.

إذا أبلغ البيكسل عن كل نموذج على أنه Purchase، فستظن Meta أن المتجر حقّق 1,000 عملية بيع بتكلفة 30 درهماً للواحدة. أما في الواقع، فقد حقّق 320 عملية بيع بتكلفة تقارب 94 درهماً للواحدة: أي أن الإشارة تُضخّم المبيعات بأكثر من ثلاثة أضعاف. لنقسّم الآن الشهر نفسه على حملتين بميزانيتين متساويتين:

إذا حُكم على الحملتين بالنماذج، فالحملة A تتفوّق بوضوح: عملاؤها المحتملون أرخص بالثلث. أما إذا حُكم عليهما بالمبيعات المُسلَّمة، فالحملة B هي الرابحة: فقد جلبت عدداً أكبر من العملاء الذين دفعوا فعلاً بالميزانية نفسها. الإشارة المقتصرة على العملاء المحتملين تدفع الميزانية نحو A، بينما تمنح إشارة الشراء المُسلَّم Meta — وتمنحك أنت — المعلومات اللازمة لإدراك أن B هي الحملة الأفضل.

ما الذي يجب على التجار التحقق منه قبل البدء؟

• اربط مجموعة بياناتك الخاصة. استخدم مجموعة البيانات (البيكسل) التي يعمل بها حسابك الإعلاني فعلاً. لا تستخدم MyLeadDone أي بيكسل مشترك.
• غيّر حدث إرسال النموذج. إذا كان البيكسل يُطلق Purchase عند إرسال النموذج، فحوّله إلى Lead أو InitiateCheckout حتى لا تُحتسب المبيعات مرتين.
• أوصل معرّفات النقر إلى الطلب. يكون الإسناد أقوى عندما يتضمن الطلب قيم fbclid أو ‎_fbc أو ‎_fbp. طلبات Shopify القادمة من تطبيقات نماذج الدفع عند الاستلام التي تحفظ رابط صفحة الوصول أو هذه القيم في خصائص الملاحظات تُلتقط تلقائياً؛ وفي Google Sheets اربط الأعمدة الاختيارية؛ ومع واجهة API الخاصة بالطلبات أرسل الحقول. أما في YouCan، فلا يمكن حالياً إلا استرجاع معرّف النقر الموجود في رابط الصفحة. ودون معرّفات النقر، تعتمد المطابقة على رقم الهاتف المُجزّأ وبيانات العميل.
• تأكّد من أن مجموعة البيانات تقبل الأحداث خارج الإنترنت. لا تقبل Meta الأحداث خارج الإنترنت عبر واجهة API التحويلات إلا في مجموعة بيانات مؤهّلة (موحّدة). ويعرض تكامل MyLeadDone تنبيهاً إذا لم تكن كذلك.
• اختبر أولاً. يتيح لك رمز حدث الاختبار رؤية الحدث في مدير الأحداث قبل احتساب أي عمليات Purchase حقيقية.
• اعرف ما لا يُرسل. الطلبات الملغاة والمرفوضة والمُرجَعة لا تُرسل شيئاً، والطلبات التي سُلِّمت قبل تفعيل التكامل لا تُرسل بأثر رجعي.

أسئلة شائعة حول واجهة API التحويلات والدفع عند الاستلام

المصادر

يصف هذا المقال تكامل MyLeadDone مع Meta كما هو مُطبَّق في سبتمبر 2026. وتستند المعلومات الخاصة بـMeta إلى وثائقها الرسمية (باللغة الإنجليزية):

• Meta for Developers — نظرة عامة على واجهة API التحويلات
• Meta for Developers — الأحداث خارج الإنترنت عبر واجهة API التحويلات
• Meta for Developers — معلمات أحداث الخادم
• Meta for Developers — معلمات معلومات العميل
• Meta for Developers — إزالة تكرار أحداث البيكسل والخادم
• Meta for Developers — أفضل ممارسات واجهة API التحويلات
• Meta for Developers — الأحداث القياسية لبيكسل Meta
• مركز مساعدة الأعمال من Meta — حول واجهة API التحويلات