ربط بيكسل فيسبوك وConversions API بالمتجر 2026: أي إعلان جلب الطلب في الدفع عند الاستلام؟

ما الفرق بين بيكسل فيسبوك وConversions API في المتجر؟

بيكسل فيسبوك (Meta Pixel) شيفرة تعمل في متصفح الزائر وترسل إلى ميتا ما يفعله في متجرك. أما Conversions API فيرسل الأحداث نفسها من خادم المتجر مباشرة، فلا يوقفه مانع إعلانات ولا قيود المتصفح. والأفضل تشغيلهما معًا: البيكسل يلتقط تفاصيل التصفح، والخادم يضمن وصول الشراء.

أين يعمل كل منهما

البيكسلفي متصفح الزائر

Conversions APIعلى خادم المتجر

مانع الإعلاناتيحجب البيكسل وحده

شراء يُؤكَّد بعد ساعاتيبلّغ به الخادم وحده

الأفضل تشغيلهما معًا بمعرّف حدث مشترك

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

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

فالسؤال ليس «أيهما أختار؟» بل «كيف أشغّلهما معًا دون أن يُحسب الشراء مرتين؟» — وهذا عمل معرّف الحدث.

كيف يمنع event_id عدّ الشراء مرتين بين البيكسل وConversions API؟

حين يرسل المتصفح والخادم الشراء نفسه، يحمل الحدثان الاسم نفسه (Purchase) والمعرّف نفسه (event_id)، فتعدّهما ميتا شراءً واحدًا. وتنص ميتا على أن الدمج يتم إذا وصل الحدث الثاني خلال 48 ساعة من وصول أول حدث بالمعرّف نفسه، وداخل البيكسل نفسه.

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

• الاسم متطابق حرفيًا: Purchase في الطرفين، لا Purchase في أحدهما واسم مخصص في الآخر.
• المعرّف متطابق ومرسل من الطرفين: البيكسل يرسله في حقل eventID، والخادم في حقل event_id.
• البيكسل واحد: لا يُدمج حدث أُرسل إلى بيكسلين مختلفين، فكل بيكسل يعدّ ما وصله.

وتيك توك يطبّق القاعدة نفسها بين بيكسله وEvents API: نوع الحدث نفسه وevent_id نفسه، خلال 48 ساعة من الحدث الأول.

ما أحداث بيكسل فيسبوك التي يحتاجها المتجر الإلكتروني؟

أربعة أحداث قياسية تصف رحلة الشراء: ViewContent حين يشاهد الزائر منتجًا، وAddToCart حين يضيفه إلى السلة، وInitiateCheckout حين يبدأ إتمام الطلب، وPurchase حين يتم الشراء. الإعلان يتعلّم من كل مرحلة، لكن Purchase هو ما تُبنى عليه حملات المبيعات وحساب العائد.

ويحمل كل حدث مع اسمه بيانات: معرّف المنتج (content_ids)، والقيمة، والعملة. وشرطان يُغفلان كثيرًا: أن تكون العملة عملة المتجر الفعلية كالجنيه أو الريال لا الدولار، وأن يطابق معرّف المنتج في الحدث معرّفه في ملف المنتجات (الكتالوج) الذي رفعته إلى ميتا؛ فإن اختلفا لم تعرف إعلانات الكتالوج أي منتج شاهده الزائر.

متى يُبلَّغ الإعلان بالشراء في الدفع عند الاستلام: عند الطلب أم عند التأكيد؟

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

متجرك

طلبك #1043 جاهز للشحن. تؤكد الطلب؟

أيوه أكّد

الآن فقط يرسل الخادم Purchase إلى ميتا

الإبلاغ عند الطلب

• إشارة فورية وأحداث أكثر
• يعدّ الملغى والوهمي شراءً

الإبلاغ عند التأكيد

• يعدّ ما أكّده العميل فقط
• الإشارة تتأخر حتى التأكيد

ولكلا الخيارين ما يُحسنه، فالقرار بحسب طريقة الدفع في متجرك:

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

كيف تعرف أي إعلان جلب الطلب بروابط UTM ومعرّف النقرة fbclid؟

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

1. افتح الإعلان في مدير الإعلانات

   على مستوى الإعلان نفسه، في قسم التتبع، تجد حقل معاملات الرابط (URL parameters). المعاملات تُكتب لكل إعلان، ويمكن تعديل عدة إعلانات معًا.

2. الصق المعاملات الديناميكية

   utm_source=facebook&utm_medium=paid&utm_campaign={{campaign.name}}&utm_term={{adset.name}}&utm_content={{ad.name}}

   الأقواس المزدوجة تُستبدل عند العرض باسم الحملة والمجموعة والإعلان، فلا تكتب الأسماء بيدك في كل إعلان.

3. سمِّ الحملات بأسماء تفهمها بعد شهر

   المنتج والعرض والجمهور في اسم واحد قصير، فيُقرأ تقرير المصدر دون الرجوع إلى مدير الإعلانات.

4. راجع تقرير المصدر كل أسبوع

   قارن الطلبات المؤكَّدة لكل إعلان بما أنفقته عليه، لا عدد النقرات ولا عدد الطلبات قبل التأكيد.

أول زيارة أم آخر زيارة؟

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

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

ماذا عن بيكسل تيك توك وسناب شات وGA4 بجانب بيكسل فيسبوك؟

المنطق واحد في كل منصة: حدث من المتصفح، ونسخة من الخادم حيث تتوفر، بمعرّف مشترك يمنع التكرار. تيك توك يقابل ميتا ببيكسل وEvents API، وجوجل يقيس بـGA4 ووسم تحويل Google Ads. اربط المنصات التي تنفق فيها فعلًا، لا كل منصة موجودة؛ فكل بيكسل زائد وزن على الصفحة ومصدر محتمل للخطأ.

• تيك توك: بيكسل في المتصفح وEvents API من الخادم، والدمج بنوع الحدث وevent_id كما سبق.
• سناب شات: في متجر عربي بوت يعمل بالبيكسل في المتصفح فقط، فتتأثر أحداثه بموانع الإعلانات أكثر من ميتا وتيك توك.
• GA4: لا يبني لك جمهورًا إعلانيًا، لكنه يرى كل المصادر لا مصدر منصة واحدة. وإن أرسلت إليه الشراء فأرسل رقم الطلب في حقل transaction_id حتى لا يُحسب مرتين إن أُعيد تحميل صفحة الشكر.
• Google Tag Manager: مفيد لوسوم خاصة، لكنه أشيع مصادر التكرار: من يضع البيكسل في حقل المتجر ثم يضيفه مرة أخرى داخل GTM يرسل كل حدث مرتين.

كيف تختبر أحداث البيكسل وConversions API قبل إطلاق الإعلانات؟

افتح مدير الأحداث في ميتا، واختر البيكسل، ثم أداة «اختبار الأحداث» (Test Events)، وأدخل رابط متجرك وتصفّح كزبون: افتح منتجًا، وأضفه إلى السلة، وابدأ إتمام الطلب، ثم اطلب طلبًا تجريبيًا. يجب أن ترى كل حدث يصل بقيمته وعملته، وأن يظهر الشراء مرة واحدة.

اختبار الأحداث (Test Events)

ViewContentوصل بالقيمة والعملة

AddToCartوصل

InitiateCheckoutوصل

Purchaseمرة واحدة

جودة المطابقة 6 أو أعلى

أزل رمز الاختبار test_event_code بعد التجربة

1. افتح أداة اختبار الأحداث

   في مدير الأحداث، اختر مصدر البيانات (البيكسل) ثم تبويب اختبار الأحداث، وافتح متجرك من المتصفح الذي تحدده الأداة.

2. امشِ في رحلة الشراء

   صفحة منتج، ثم السلة، ثم صفحة الطلب. تأكد أن ViewContent وAddToCart وInitiateCheckout وصلت، وأن القيمة والعملة صحيحتان.

3. اطلب طلبًا تجريبيًا برقمك أنت

   إن كان متجرك يرسل تأكيد الطلب على واتساب، فالرسالة تصل فعلًا إلى الرقم المكتوب في الطلب؛ لا تكتب رقمًا مخترعًا فقد يكون رقم شخص حقيقي. ثم ألغِ الطلب بعد التجربة.

4. تحقق من الخادم ومن الدمج

   تقول ميتا إن أحداث الخادم تظهر في مدير الأحداث خلال نحو 20 دقيقة من إرسالها. بعدها افتح «تفاصيل الحدث» لحدث الشراء من صفحة «نظرة عامة»، ثم تبويب «إزالة التكرار» (Event Deduplication) وفيه نسبة الأحداث التي دُمجت، وراجع درجة «جودة مطابقة الأحداث» (Event Match Quality) التي توصي ميتا بأن تكون 6 أو أعلى.

5. في وضع الإبلاغ عند التأكيد

   أكّد الطلب التجريبي من اللوحة ثم انتظر وصول الشراء من الخادم. وتذكّر أن الأحداث المرسلة برمز اختبار (test_event_code) لا تحذفها ميتا بل تدخل القياس والاستهداف، فأزل رمز الاختبار حين تنتهي التجربة.

أخطاء شائعة تفسد قياس البيكسل

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

كيف يعمل ربط البيكسل ومصدر الطلب في متجر عربي بوت؟

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

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

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

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