تحويلات الخادم: كيف تفعّلها دون احتساب مزدوج

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

باختصار

• المُعرّف الفريد (event_id) هو ما يمنع احتساب التحويلة مرتين، وليس عدد المصادر.
• البكسل وحده يتأثر بحاجب الإعلانات وتعطيل الكوكيز، أما الخادم فلا يعتمد على المتصفح.
• يجب أن يتطابق اسم الحدث (event_name) حرفيًا بين المصدرين، وإلا فشلت إزالة التكرار.
• المنصات تحتاج عادة من 24 إلى 72 ساعة لتطبيق إزالة التكرار على البيانات المستلمة.
• ارتفاع الأرقام بعد 72 ساعة يعني خللًا في الإعداد، لا تأخرًا في المعالجة.

ما المقصود بتحويلات الخادم ولماذا تحتاجها

تحويلات الخادم هي طريقة تتبع يرسل فيها سيرفرك بيانات التحويل إلى المنصة عبر واجهة برمجية (Conversions API)، بدل انتظار ما يرسله البكسل من متصفح الزائر. الفرق الجوهري أن الخادم لا يعتمد على ما يحدث في متصفح المستخدم، فلا يتأثر بحاجب الإعلانات ولا بحذف الكوكيز ولا ببطء تحميل الصفحة.

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

نقل التحويلات من الخادم يرفع نسبة مطابقة الأحداث غالبًا بنسبة تتراوح بين 15% و30% مقارنة بالبكسل وحده. الرقم ليس ثابتًا: يعتمد على نوع الحدث، ومدى اكتمال البيانات التي ترسلها، ودرجة تعطيل التتبع عند جمهورك، وتأثير حاجب الإعلانات في سوقك تحديدًا.

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

كيف تفعّل نقل التحويلات من الخادم خطوة بخطوة

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

1. حدّد الأحداث التي ستُرسل من الخادم. ابدأ بالأحداث ذات القيمة التجارية الواضحة مثل إتمام الشراء أو إرسال نموذج طلب، لا بكل حدث في الموقع.
2. اختر مُعرّفًا فريدًا لكل عملية. رقم الطلب أو معرّف المعاملة هو الخيار العملي، لأنه موجود أصلًا في نظامك ولا يتكرر عبر الجلسات.
3. جهّز حمولة الحدث (payload) وأدرج فيها الحقل event_id إلى جانب event_name والطابع الزمني وبيانات المستخدم المتاحة.
4. أرسل الحدث من السيرفر إلى نقطة النهاية الخاصة بـ Conversions API في المنصة.
5. أضف نفس قيمة event_id إلى البكسل على المتصفح عبر خاصية eventID، وتأكد أن event_name مطابق حرفيًا.
6. اختبر بحدث تجريبي واحد، ثم راقب التقارير خلال أول 72 ساعة قبل أن تحكم على النتيجة.

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

أين تضع المُعرّف بالضبط

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

ما الذي يفسد الربط حتى لو وضعت المُعرّف

ثلاثة أخطاء تظهر في الممارسة أكثر من غيرها. الأول اختلاف اسم الحدث بين المصدرين، مثل purchase في الخادم وPurchase في البكسل. الثاني إرسال الحدث من الخادم متأخرًا جدًا بعد انتهاء صلاحية الربط الزمني. الثالث توليد المُعرّف في لحظة الإرسال من الخادم فقط، بدل توليده عند إنشاء الطلب ومشاركته بين المصدرين.

جدول مقارنة: البكسل مقابل نقل التحويلات من الخادم

الجدول يوضح أن الخطر لا يأتي من مصدر واحد، بل من تشغيل المصدرين دون رابط. الجهة التي تمنع التكرار هي المُعرّف المشترك، لا اختيار مصدر على حساب الآخر.

لماذا يظهر الاحتساب المزدوج بعد التفعيل

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

هناك سبب ثانٍ أقل وضوحًا: إرسال الحدث نفسه أكثر من مرة من الخادم. يحدث هذا عند تكرار الطلب بسبب إعادة المحاولة (retry) بعد انقطاع الشبكة، أو عند تشغيل الحدث من أكثر من نقطة في الكود. هنا لا يساعد event_id وحده إن كان المُعرّف يتغير مع كل محاولة، لذلك يجب أن يُشتق المُعرّف من العملية نفسها لا من لحظة الإرسال.

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

كيف تفرّق بين التكرار الحقيقي والتأخر في المعالجة

راقب نمط الأرقام لا قيمتها. إذا ارتفعت الأرقام بعد التفعيل ثم عادت إلى مستوى منطقي خلال 24 إلى 72 ساعة، فما رأيته هو تأخر في المعالجة وليس تكرارًا. أما إذا بقي الارتفاع ثابتًا بعد 72 ساعة، أو تضاعفت الأرقام بنسبة قريبة من الضعف بشكل منتظم، فالسبب غالبًا إعدادي وليس زمنيًا.

كم من الوقت تستغرق إزالة التكرار

تحتاج المنصات عادة من 24 إلى 72 ساعة حتى تُطبّق إزالة التكرار بشكل كامل على البيانات المُستلمة. خلال هذه الفترة قد ترى أرقامًا مرتفعة مؤقتًا في التقارير. إذا استمر التضاعف بعد 72 ساعة، فغالبًا هناك خلل في إعداد event_id أو في توقيت الإرسال.

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

القاعدة العملية: لا تعدّل الإعداد خلال أول 24 ساعة لمجرد رؤية أرقام مرتفعة. التعديل المتكرر يضيف متغيرات جديدة ويجعل تحديد السبب أصعب.

أخطاء شائعة تسبب احتسابًا مزدوجًا

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

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

الخطأ الثالث هو الاعتقاد بأن إزالة التكرار تعمل تلقائيًا بمجرد تفعيل الخادم. إزالة التكرار تحتاج مُعرّفًا مشتركًا صحيحًا؛ بدون ذلك لا يوجد ما يربط الحدثين.

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

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

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

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

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

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

الخطوة التالية

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

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

كيف أفعّل نقل التحويلات من الخادم (Server-Side) دون احتساب مزدوج؟

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

ما الفرق بين نقل التحويلات من الخادم والبكسل العادي؟

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

لماذا يظهر الاحتساب المزدوج في تقارير التحويلات بعد تفعيل النقل من الخادم؟

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

كم من الوقت تستغرق إزالة التكرار بعد إرسال الحدث من الخادم؟

تحتاج المنصات عادة من 24 إلى 72 ساعة حتى تُطبّق إزالة التكرار بشكل كامل على البيانات المُستلمة. خلال هذه الفترة قد ترى أرقامًا مرتفعة مؤقتًا في التقارير. إذا استمر التضاعف بعد 72 ساعة، فغالبًا هناك خلل في إعداد event_id أو في توقيت الإرسال.

أين أضع مُعرّف الحدث لإزالة التكرار بشكل صحيح؟

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