التتبع من جهة الخادم (server-side): ما هو، وما الذي يتغير، ومتى تحتاجه

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

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

ما هو التتبع من جهة الخادم

في الوسم من جهة العميل (client-side)، يحمّل متصفح المستخدم وسم كل منصة ويرسل الأحداث مباشرة إلى Google أو Meta أو TikTok. ويتلقى كل مزوّد ما يجمعه نصه البرمجي.

أما في الوسم من جهة الخادم (server-side)، فيرسل الموقع الأحداث إلى وجهة واحدة: خادم وسم يعمل على نطاق فرعي تملكه. يتلقى ذلك الخادم الحدث، ويعالجه، ثم يعيد توجيهه إلى كل منصة عبر واجهات API الخاصة بها.

ما الذي يتغير مقارنة بالوسم في المتصفح

تذهب الطلبات إلى نطاقك الخاص

لم يعد المتصفح يتواصل مع عشرات النطاقات التابعة لأطراف ثالثة، بل مع نطاق فرعي تملكه. وبالنسبة إلى المتصفح، إنها حركة خاصة بالموقع (first-party).

الخادم يقرر ما يصل إلى كل منصة

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

كوكيز خاصة تدوم أطول

يحدّ Safari، بنظام Intelligent Tracking Prevention (ITP)، عمر الكوكيز المنشأة عبر JavaScript بسبعة أيام، ولا يقبل كوكيز الأطراف الثالثة أصلًا. أما الكوكيز التي يضبطها خادمك في استجابة HTTP من نطاقك فيمكن أن تدوم أطول، فيظل المستخدم الذي يعود بعد أسبوعين قابلًا للتعرف عليه. ملاحظة: يحدّ Safari أيضًا من كوكيز الخادم عندما يشير النطاق الفرعي للوسم إلى بنية تحتية مختلفة جدًا عن بنية موقعك، لذا فطريقة الإعداد مهمة.

شيفرة أقل من أطراف ثالثة في الصفحة

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

ما الذي لا يفعله التتبع من جهة الخادم

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

ما المكونات اللازمة

1. خادم وسم. الخيار الأكثر انتشارًا هو Google Tag Manager server-side، الذي يمكن نشره على Google Cloud Run أو لدى مزوّد مُدار يستضيفه نيابة عنك.
2. نطاق فرعي خاص. مثل tag.yourdomain.com، يشير إلى ذلك الخادم.
3. حاوية ويب. GTM المعتاد أو وسم Google في الصفحة، مهيآن لإرسال الأحداث إلى خادمك بدل كل منصة.
4. حاوية خادم. تتلقى الطلبات عبر «عملاء» (clients) يفسرونها، وتشغّل وسوم كل وجهة.
5. وسوم كل منصة. Conversions API من Meta، والتحويلات المحسّنة في Google Ads، وEvents API من TikTok، وMeasurement Protocol في GA4، وغيرها.

نشرح مكوّن Meta في دليل Conversions API.

إزالة التكرار: عندما يرسل المتصفح والخادم الحدث نفسه

تُبقي كثير من التثبيتات البكسل في المتصفح وتضيف الإرسال من الخادم. وهذا معقول، لكن عملية الشراء نفسها تصل مرتين. ولكي تحتسبها المنصة مرة واحدة، يجب أن يحمل الإرسالان المعرّف نفسه: في Meta وTikTok، اسم الحدث نفسه وevent_id نفسه؛ وفي Google Ads، معرّف المعاملة نفسه. ودون ذلك، تتضخم التحويلات وتتعلم المزايدات من بيانات مكررة.

إثراء الأحداث ببيانات عملك

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

التكاليف والصيانة

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

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

متى تحتاجه ومتى لا

يجدي إذا تحققت عدة من هذه الشروط:

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

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

أخطاء شائعة

• إعداده للالتفاف على الموافقة. إنه خطر قانوني، فضلًا عن أن هذا ليس الغرض منه.
• تكرار الأحداث. الإرسال من المتصفح ومن الخادم دون event_id مشترك.
• استخدام نطاق ليس نطاقك. دون نطاق فرعي خاص، تضيع نسبة كبيرة من ميزة كوكيز first-party.
• غياب المسؤول. لا أحد يراجع الخادم حتى تنهار التحويلات.

كيف يفعل ذلك Babuin

في MonkeyFlux، تمر أحداث موقعك وتطبيقك عبر خادم على نطاقك الخاص، مثل tag.yourdomain.com، مع كوكيز first-party. وهناك تُطبَّق الموافقة، ويُزال تكرار الأحداث بـ event_id، وتُثرى ببيانات من CRM الخاص بك وERP، مثل الهامش أو LTV أو جودة العميل المحتمل أو المرتجعات. ثم تُرسل إلى كل منصة عبر Conversions API أو Enhanced Conversions أو Events API أو Measurement Protocol. وهو متوافق مع حاوية GTM من جهة الخادم لديك.

وبتلك الإشارات، يقيس Babuin كل قناة مقابل نتائج عملك، ويزايد MonkeyBot نحو القيمة الحقيقية، ويوزّع DBA الميزانية كل يوم بين القنوات.

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