بكسل ميتا و Conversions API: الإعداد الصحيح لمتجرك

الإعداد الصحيح لبكسل ميتا في متجرك يعني تشغيل أداتين معًا: البكسل الذي يرسل الأحداث من متصفح العميل، وConversions API الذي يرسل نفس الأحداث من سيرفر المتجر. وحتى لا يُحسب الطلب مرتين، يجب أن يحمل كل حدث نفس الاسم ونفس رقم التعريف (event_id) من المصدرين.

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

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

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

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

الأحداث التي يحتاجها المتجر

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

أهم حدث هو Purchase، وحسب مرجع ميتا فإن قيمته (value) والعملة (currency) مطلوبتان فيه. لو القيمة لا تُرسل، أو تُرسل بعملة خاطئة، فالـ ROAS في مدير الإعلانات لا معنى له. ولو تستخدم إعلانات الكتالوج، فالأحداث تحتاج أيضًا أرقام المنتجات حتى تعرف ميتا أي منتج شاهده العميل أو اشتراه.

خطوات الإعداد بالترتيب

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

منع التكرار: أهم خطوة في الإعداد

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

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

الحدث الذي لا تستطيع ميتا ربطه بحساب شخص ما لا يُستخدم في الإسناد ولا في تحسين الحملات. لذلك أرسل ما تملكه من بيانات العميل مع أحداث السيرفر. حسب صفحة معاملات بيانات العميل في توثيق ميتا: البريد الإلكتروني ورقم الهاتف والاسم والمدينة تُشفّر بـ SHA-256 قبل الإرسال، أما fbp وfbc وعنوان IP والـ User Agent فتُرسل كما هي بدون تشفير.

وانتبه للتنسيق قبل التشفير: البريد بحروف صغيرة وبدون مسافات، ورقم الهاتف أرقامًا فقط مع مفتاح الدولة وبدون الصفر في البداية. رقم سعودي مثل 0501234567 يصبح 966501234567 قبل التشفير. وتعرض ميتا لكل حدث ويب درجة “جودة مطابقة الحدث” (Event Match Quality) من 10، وهي مؤشر جيد لترى هل البيانات التي ترسلها كافية.

كيف تتأكد أن الإعداد يعمل؟

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

عند اختبار السيرفر، تعطيك الأداة كود اختبار يُرسل مع الأحداث في معامل test_event_code. احذف هذا المعامل بعد الانتهاء من الاختبار. ثم بعد أيام من التشغيل الفعلي، قارن عدد أحداث Purchase في Events Manager بعدد الطلبات في لوحة المتجر لنفس الفترة. هذا الفحص البسيط يكشف أغلب المشاكل.

في شاشة Overview لمصدر البيانات، يظهر عمود Integration بجانب كل حدث. كلمة Multiple تعني أن الحدث يصل من أكثر من مصدر، أي من البكسل وConversions API معًا. وبجانبه رقم Event Match Quality من 10: كلما ارتفع، استطاعت ميتا ربط الحدث بالشخص الصحيح بدقة أكبر.

وعند فتح أي حدث، تعرض ميتا مقارنة مباشرة: كم حدثًا إضافيًا وصل عن طريق Conversions API ولم يكن البكسل وحده سيسجله. في المثال التالي من موقعي، أضاف Conversions API نسبة 33.3% إلى أحداث Initiate Checkout مقارنة بالبكسل وحده. هذه هي الأحداث التي كانت ستضيع لو اعتمدت على البكسل فقط.

مثال بالأرقام: ماذا يحدث للـ ROAS؟

الأرقام للتوضيح، والحساب نفسه يعمل بأي عملة.

متجر افتراضي صرف 10,000 ريال على إعلانات ميتا في أسبوع، وسجّل فعليًا 200 طلب، متوسط قيمة الطلب 250 ريال. الإيراد الحقيقي إذن 50,000 ريال، والـ ROAS الحقيقي 5. لنفترض للتبسيط أن كل الطلبات جاءت من الإعلانات. لاحظ كيف يتغير ما يراه صاحب المتجر حسب الإعداد:

في الحالة الأولى، يظن صاحب المتجر أن الحملة ضعيفة فيوقفها رغم أنها رابحة. في الحالة الثانية، يرى ROAS يساوي 8.25 فيضاعف الميزانية على أرقام غير موجودة. فقط الحالة الثالثة تقترب من الحقيقة: 196 حدثًا من 200 طلب، أي 98%.

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

أخطاء شائعة في إعداد البكسل وConversions API

تركيب البكسل مرتين. مرة من تكامل المنصة ومرة يدويًا في كود الثيم، أو عن طريق Google Tag Manager. النتيجة أن كل حدث في المتصفح يُرسل مرتين، ومنع التكرار لا ينقذك لو كان رقم التعريف مختلفًا.

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

إرسال Purchase من صفحة الشكر فقط. كل مرة يعيد العميل تحميل الصفحة يُسجل شراء جديد. اربط الحدث بإنشاء الطلب، لا بفتح الصفحة.

قيمة الطلب خاطئة. إرسال القيمة بدون عملة، أو بعملة غير عملة المتجر، أو إرسال قيمة ثابتة لكل الطلبات. راجع القيمة في Test Events مع طلب حقيقي.

أحداث سيرفر بلا بيانات عميل. حدث يصل من السيرفر بدون بريد أو هاتف أو fbp أو IP يصعب ربطه بأي شخص، فيكون عديم الفائدة تقريبًا في التحسين.

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

أسئلة شائعة

هل أكتفي بـ Conversions API وألغي البكسل؟

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

كم الفرق الطبيعي بين أحداث الشراء وطلبات المتجر؟

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

هل أرسل الشراء عند تسجيل الطلب أم عند التوصيل في الدفع عند الاستلام؟

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

اقرأ أيضًا: نقطة التعادل للـ ROAS: الرقم الذي يخبرك هل حملتك تربح أم تخسر وميزانية الإعلانات الشهرية لمتجرك وطريقة حسابها بالأرقام