التقنية والتطوير

ربط البكسل مع الخادم: دليل عملي لإعداد Conversions API بدون تكرار

ربط البكسل مع الخادم: دليل عملي لإعداد Conversions API بدون تكرار

الخلاصة: ربط البكسل مع الخادم يعني إن كل حدث مهم مثل الشراء يوصل للمنصة من طريقين: البكسل في متصفح العميل، وواجهة التحويلات (Conversions API) من خادمك. عشان ما ينحسب الطلب مرتين، أرسل نفس معرّف الحدث event_id ونفس اسم الحدث من الطريقين. وعشان المنصة تعرف مين اشترى، أرسل مع حدث الخادم مفاتيح المطابقة: الإيميل والجوال مشفّرة بـ SHA-256، ومعرّفات النقرة والكوكيز وعنوان IP والمتصفح بدون تشفير. بعدها اختبر من أداة الأحداث في كل منصة قبل ما تعتمد على الأرقام.

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

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

كيف يشتغل الربط الهجين؟

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

مخطط ربط البكسل مع الخادم: المتصفح والخادم يرسلان نفس الحدث بنفس المعرّف إلى منصة الإعلان

المسار بالترتيب:

  1. العميل يكمل الطلب، وصفحة الشكر تطلق حدث الشراء من البكسل ومعه معرّف الحدث.
  2. نظام المتجر يسجّل الطلب، ويرسل نفس حدث الشراء من الخادم إلى واجهة التحويلات بنفس المعرّف، ومعه بيانات المطابقة.
  3. المنصة تستقبل النسختين، تقارن المعرّف واسم الحدث، وتحسب الطلب مرة وحدة.

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

إلغاء التكرار: معرّف الحدث event_id

إلغاء التكرار (Deduplication) هو إن المنصة تتعرّف على الحدث اللي وصلها من البكسل ومن الخادم على إنه حدث واحد. والمفتاح هنا هو معرّف حدث واحد يتولّد مرة وحدة ويُرسل من الطريقين.

القاعدة في ميتا

حسب توثيق ميتا، المنصة تعتبر الحدثين نفس الحدث إذا تطابق eventID في البكسل مع event_id في Conversions API، وتطابق اسم الحدث كمان، مثل Purchase في الطرفين. والمطابقة تتم إذا وصل الحدثان خلال 48 ساعة من بعض، وميتا في الغالب تفضّل الحدث اللي وصلها أول. وفيه طريقة بديلة تعتمد على fbp أو external_id، لكن معرّف الحدث هو الأوضح.

من وين تجيب المعرّف؟

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

مفاتيح المطابقة: وش ترسل ووش تشفّر

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

القاعدة العامة في ميتا وسناب: البيانات الشخصية تتشفّر، والمعرّفات التقنية تنرسل كما هي.

المفتاحتشفير SHA-256؟من وين يجي
الإيميلنعم، بعد تحويله لأحرف صغيرة وحذف المسافاتبيانات الطلب أو الحساب
رقم الجوالنعم، أرقام فقط ومعه مفتاح الدولة (966 للسعودية)بيانات الطلب
عنوان IPلاطلب العميل الواصل لخادمك
المتصفح (User Agent)لاطلب العميل الواصل لخادمك
fbp و fbc (ميتا)لاكوكيز _fbp و _fbc في المتصفح
sc_click_id (سناب)لاالمتغير ScCid في رابط الإعلان
sc_cookie1 (سناب)لاكوكي _scid في المتصفح

مثال على تجهيز الجوال قبل التشفير: الرقم 05xxxxxxxx يصير 9665xxxxxxxx، بدون علامة + وبدون مسافات أو شرطات. وأي حقل فاضي لا ترسله بقيمة وهمية، اتركه.

تيك توك تطلب كمان تشفير الإيميل والجوال بـ SHA-256 في المطابقة المتقدمة. وقوقل تشفّر بيانات العميل بنفس الخوارزمية في التحويلات المحسّنة.

ربط البكسل مع الخادم في المنصات الأربع

كل منصة لها اسم مختلف للأداة وحقل مختلف لمنع التكرار. هذا الجدول يجمعها في مكان واحد:

المنصةفي المتصفحمن الخادممنع التكرارالاختبار
ميتاMeta PixelConversions APIeventID = event_id + نفس اسم الحدث، خلال 48 ساعةTest Events في Events Manager، وتقييم جودة مطابقة الأحداث
سناب شاتSnap PixelConversions APIclient_dedup_id = event_id خلال 48 ساعة، وللشراء transaction_id = order_id حتى 30 يومتشخيص إلغاء التكرار في Events Manager
تيك توكTikTok PixelEvents APIevent_id في الطرفين + نفس الحدث، خلال 48 ساعةEvents Manager في تيك توك
قوقلGoogle tagالتحويلات المحسّنة، وخيار Server-side GTMمعرّف المعاملة (Transaction ID)تشخيص التحويلات في قوقل ادز

ميتا: البكسل مع Conversions API

  • أطلق حدث Purchase من البكسل ومعه eventID، وأرسل نفس الحدث من الخادم ومعه event_id بنفس القيمة.
  • أرسل مع حدث الخادم الإيميل والجوال مشفّرة، و client_ip_address و client_user_agent و fbp و fbc بدون تشفير.
  • أرسل value و currency بنفس القيم في الطرفين، مثل SAR.
  • إذا تشغّل حملات Advantage+، فجودة هذي الإشارات تأثر مباشرة على اللي تتعلمه الحملة.

سناب شات: Snap Pixel مع Conversions API

سناب عنده طريقتين لمنع التكرار، وهذا اللي يفوت على كثير:

  • الطريقة العامة: client_dedup_id في البكسل يطابق event_id في Conversions API، خلال 48 ساعة.
  • للشراء فقط: transaction_id في البكسل يطابق order_id داخل custom_data في Conversions API، ويشتغل لمدة تصل إلى 30 يوم.
  • القيم الوهمية الثابتة ما تنفع لمنع التكرار، فلا ترسل نص ثابت أو قيمة تجريبية بدل المعرّف الحقيقي.
  • لحدث PURCHASE القيمة value مطلوبة. ومرّر sc_click_id من المتغير ScCid في الرابط، و sc_cookie1 من كوكي _scid.

تيك توك: TikTok Pixel مع Events API

  • تيك توك تطلب event_id في البكسل وفي Events API، ونفس اسم الحدث في الطرفين.
  • إذا تكرر نفس الحدث من نفس القناة خلال 48 ساعة، تحتفظ تيك توك بالأول. وإذا جا من البكسل ومن Events API، تتعامل معهم كحدث واحد خلال نفس المدة، ويوضّح توثيقها كيف تختار بينهم حسب توقيت وصول كل واحد.
  • فعّل المطابقة المتقدمة، وأرسل الإيميل والجوال مشفّرة بـ SHA-256.

قوقل: Google tag مع التحويلات المحسّنة

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

  • معرّف المعاملة: إذا أرسلت رقم الطلب كـ Transaction ID مع تحويل الشراء، قوقل ادز ما تحسب تحويل ثاني بنفس المعرّف. لكن توثيقها يوضح إن هذا ما يحل التكرار في تحويلات المشاهدة (view-through).
  • التحويلات المحسّنة (Enhanced Conversions): ترسل بيانات العميل مثل الإيميل مشفّرة بـ SHA-256 مع التحويل، عشان تتحسن المطابقة. وتقدر تفعّلها من Google tag أو من قوقل تاق مانجر.
  • Server-side GTM: خيار إضافي، تشغّل فيه حاوية تاق مانجر على خادم في مشروع Google Cloud خاص فيك أو في بيئة ثانية، وتمرّر منه الأحداث للمنصات. يفيد إذا تبي تتحكم في البيانات من مكان واحد، لكنه يحتاج إعداد وصيانة.

الاختبار وقراءة جودة المطابقة

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

  1. سوّ طلب تجريبي كامل من جوالك ومن متصفح على الكمبيوتر.
  2. في ميتا، افتح Test Events في Events Manager، وتأكد إن حدث الشراء وصل من المتصفح ومن الخادم، وإنه ظهر كحدث واحد بعد إلغاء التكرار.
  3. في سناب، راجع تشخيص إلغاء التكرار في Events Manager.
  4. في تيك توك، راجع الحدث في Events Manager وتأكد إن event_id واصل من الطرفين.
  5. في قوقل ادز، راجع حالة التحويل وتشخيص التحويلات المحسّنة.
  6. قارن القيمة والعملة في كل منصة بقيمة الطلب في لوحة متجرك.
مخطط إلغاء التكرار: حدث البكسل وحدث الخادم بنفس event_id يُحسبان طلبًا واحدًا

في ميتا، تقييم جودة مطابقة الأحداث (Event Match Quality) يوضح لكل حدث كيف تقدر المنصة تطابقه مع أصحاب الحسابات. إذا كان التقييم منخفض، ابدأ بالتأكد إن الإيميل والجوال المشفّرة و fbc و fbp واصلة مع أحداث الخادم. وبعد ما تضبط القياس، تقدر تقرأ العائد على الإنفاق الإعلاني وأنت مطمئن إن الأرقام ما هي متضاعفة.

الموافقة والخصوصية

ربط البكسل مع الخادم ما يعطيك حق ترسل بيانات العميل بدون موافقته. نفس قواعد الموافقة اللي تطبقها على البكسل لازم تطبقها على أحداث الخادم: إذا العميل رفض ملفات التتبع الإعلانية، لا ترسل بياناته الشخصية من الخادم. وفي قوقل، اربط الإعداد بـ وضع الموافقة Consent Mode، ووضّح في سياسة الخصوصية وش ترسل ولمين.

سلة وزد وووكومرس: وش يجيك جاهز؟

قبل ما تبني أي شي من الصفر، شوف وش توفره منصة متجرك:

  • سلة: مركز مساعدة سلة يشرح ربط Facebook Conversion API عن طريق تطبيق، تدخل فيه معرّف البكسل (Pixel ID) ورمز الوصول (Access Token). ويشرح كمان إضافة Snap Business Extension اللي تربط سناب بكسل والكتالوج و Conversions API بخطوة وحدة.
  • زد: ما لقينا توثيق رسمي من زد عن ربط Conversions API. راجع متجر تطبيقات زد، واسأل مطوّر التطبيق اللي تستخدمه: هل يرسل أحداث الخادم؟ وهل يرسل نفس event_id اللي يرسله البكسل؟
  • ووكومرس: إضافة Meta for WooCommerce الرسمية تغطي البكسل ومزامنة الكتالوج. تأكد من إعداداتها هل تفعّل Conversions API، وإذا أضفت إضافة ثانية للتتبع، تأكد إنهم ما يرسلون نفس الحدث مرتين.

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

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

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

قائمة التحقق

  • البكسل شغال في كل الصفحات، وحدث الشراء في صفحة الشكر فقط.
  • حدث الشراء ينرسل من الخادم لكل منصة تعلن فيها.
  • نفس event_id ونفس اسم الحدث في الطرفين (و client_dedup_id أو transaction_id في سناب).
  • Transaction ID مع تحويل الشراء في قوقل ادز.
  • الإيميل والجوال مشفّرة بـ SHA-256 بعد التجهيز، والجوال بمفتاح 966.
  • IP والمتصفح و fbp و fbc و ScCid و _scid تنرسل بدون تشفير.
  • القيمة والعملة متطابقة مع لوحة المتجر.
  • أحداث الخادم تحترم اختيار العميل في الموافقة.
  • طلب تجريبي ظهر كحدث واحد في أداة الاختبار في كل منصة.

أسئلة شائعة

هل أشيل البكسل إذا ركّبت Conversions API؟

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

وش هو event_id وليش مهم؟

هو معرّف فريد لكل حدث، ترسله نفسه من البكسل ومن الخادم. المنصة تستخدمه مع اسم الحدث عشان تعرف إن النسختين حدث واحد. بدونه ممكن ينحسب الطلب مرتين.

هل لازم أشفّر كل البيانات قبل ما أرسلها؟

لا. البيانات الشخصية مثل الإيميل والجوال تتشفّر بـ SHA-256. أما عنوان IP والمتصفح ومعرّفات الكوكيز والنقرة مثل fbp و fbc فتنرسل بدون تشفير حسب توثيق ميتا وسناب.

هل أحتاج Server-side GTM عشان أربط البكسل مع الخادم؟

مو شرط. كثير من المتاجر تربط من تطبيق المنصة أو من نظام المتجر مباشرة. Server-side GTM خيار يجمع الأحداث في حاوية وحدة على خادمك، ويفيد إذا تبي تحكم أكبر وعندك من يديره.

كيف أعرف إن الربط شغال صح؟

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

الخلاصة

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

المصادر

  1. Meta for Developers — Conversions API
  2. Meta for Developers — Handling Duplicate Pixel and Conversions API Events
  3. Meta for Developers — Customer Information Parameters
  4. Meta Business Help Center — About event match quality
  5. Snap for Developers — Conversions API: Deduplication
  6. Snap for Developers — Conversions API: Parameters
  7. TikTok Ads Help — Event deduplication
  8. TikTok Ads Help — Advanced matching for web
  9. Google Ads Help — Use a transaction ID to minimize duplicate conversions
  10. Google Ads Help — About enhanced conversions
  11. Google for Developers — Introduction to server-side tagging
  12. مركز مساعدة سلة — ربط Facebook Conversion API
  13. Salla Help Center — Connect Snapchat (Snap Business Extension)
  14. WordPress.org — Meta for WooCommerce