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

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

المسار بالترتيب:
- العميل يكمل الطلب، وصفحة الشكر تطلق حدث الشراء من البكسل ومعه معرّف الحدث.
- نظام المتجر يسجّل الطلب، ويرسل نفس حدث الشراء من الخادم إلى واجهة التحويلات بنفس المعرّف، ومعه بيانات المطابقة.
- المنصة تستقبل النسختين، تقارن المعرّف واسم الحدث، وتحسب الطلب مرة وحدة.
النتيجة إنك تكسب تغطية الخادم بدون ما تخسر إشارات المتصفح، وبدون ما تتضاعف أرقامك.
إلغاء التكرار: معرّف الحدث 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 Pixel | Conversions API | eventID = event_id + نفس اسم الحدث، خلال 48 ساعة | Test Events في Events Manager، وتقييم جودة مطابقة الأحداث |
| سناب شات | Snap Pixel | Conversions API | client_dedup_id = event_id خلال 48 ساعة، وللشراء transaction_id = order_id حتى 30 يوم | تشخيص إلغاء التكرار في Events Manager |
| تيك توك | TikTok Pixel | Events API | event_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 خاص فيك أو في بيئة ثانية، وتمرّر منه الأحداث للمنصات. يفيد إذا تبي تتحكم في البيانات من مكان واحد، لكنه يحتاج إعداد وصيانة.
الاختبار وقراءة جودة المطابقة
تختبر ربط البكسل مع الخادم بطلب تجريبي حقيقي، ثم تتأكد في أداة الأحداث في كل منصة إن الحدث وصل من المتصفح ومن الخادم وانحسب مرة وحدة. الخطوات:
- سوّ طلب تجريبي كامل من جوالك ومن متصفح على الكمبيوتر.
- في ميتا، افتح Test Events في Events Manager، وتأكد إن حدث الشراء وصل من المتصفح ومن الخادم، وإنه ظهر كحدث واحد بعد إلغاء التكرار.
- في سناب، راجع تشخيص إلغاء التكرار في Events Manager.
- في تيك توك، راجع الحدث في Events Manager وتأكد إن
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 خيار يجمع الأحداث في حاوية وحدة على خادمك، ويفيد إذا تبي تحكم أكبر وعندك من يديره.
كيف أعرف إن الربط شغال صح؟
سوّ طلب تجريبي، وتأكد في أداة الاختبار في كل منصة إن الحدث وصل من المتصفح ومن الخادم وانحسب مرة وحدة، وإن القيمة والعملة تطابق الطلب في متجرك.
الخلاصة
ربط البكسل مع الخادم مو بس تركيب واجهة. هو ثلاث أشياء مع بعض: معرّف حدث واحد يمنع التكرار، ومفاتيح مطابقة مرتبة ومشفّرة صح، واختبار في كل منصة قبل ما تعتمد على الأرقام. ابدأ بحدث الشراء، وبعدها وسّع للأحداث اللي قبله. وإذا تبي من يركّب القياس ويديره مع إعلاناتك، تعرّف على خدمة الإعلانات الرقمية.
المصادر
- Meta for Developers — Conversions API
- Meta for Developers — Handling Duplicate Pixel and Conversions API Events
- Meta for Developers — Customer Information Parameters
- Meta Business Help Center — About event match quality
- Snap for Developers — Conversions API: Deduplication
- Snap for Developers — Conversions API: Parameters
- TikTok Ads Help — Event deduplication
- TikTok Ads Help — Advanced matching for web
- Google Ads Help — Use a transaction ID to minimize duplicate conversions
- Google Ads Help — About enhanced conversions
- Google for Developers — Introduction to server-side tagging
- مركز مساعدة سلة — ربط Facebook Conversion API
- Salla Help Center — Connect Snapchat (Snap Business Extension)
- WordPress.org — Meta for WooCommerce