دليل تكامل موافقة Cloudflare Zaraz: إدارة العلامات من جانب الخادم على الحافة لعام 2026

تختلف Cloudflare Zaraz عن معظم منتجات إدارة العلامات التي سبقتها. الفكرة الأساسية بنيوية لا تدريجية: بدلاً من تحميل Google Analytics وMeta Pixel وHotjar وMixpanel وLinkedIn Insight وكل JavaScript لكل بائع آخر في متصفح الزائر، تُنفّذ Zaraz تلك التكاملات داخل Cloudflare Workers التي تعمل على الحافة، أمام أصل الناشر. يرى المتصفح وقت تشغيل Zaraz صغيراً واحداً فقط؛ وتعمل أدوات البائع من جانب الخادم. هذا الاختيار المعماري له عواقب متضاعفة على الموافقة. يتقلص سطح الكوكيز بشكل كبير لأن معظم كوكيز البائع لا تُعيَّن أصلاً. ويتقلص سطح بصمة الأصابع لأن معظم JavaScript للبائع لا يُنفَّذ أبداً في سياق المتصفح. وتنتقل نقطة تطبيق الموافقة من لافتة JavaScript تحجب مجموعة من علامات <script> إلى قرار من جانب الخادم يحدد أي تكاملات Zaraz تُطلَق وما الحمولة التي تتلقاها. الناشر الذي يربط Zaraz بـ CMP بشكل صحيح ينتهي بسطح امتثال أصغر وصفحات أسرع ومسار تدقيق أوضح. أما الناشر الذي يعامل Zaraz كـ Google Tag Manager أسرع ويتخطى ربط الموافقة، فينتهي بتعرض تنظيمي يصعب اكتشافه لأن كثيراً من النشاط غير مرئي لعمليات التدقيق القياسية القائمة على المتصفح.

ما الذي تفعله Zaraz فعلياً على الحافة

Zaraz هو مدير علامات من جانب الخادم يعمل داخل Cloudflare Workers. عندما يحمّل الزائر صفحة، يتضمن HTML للناشر نص تهيئة Zaraz صغيراً — عادةً بضعة كيلوبايتات — يجمع حمولة حدث منظمة من المتصفح (مشاهدة الصفحة، النقر، الحدث المخصص) ويرسلها عبر POST إلى نقطة نهاية Cloudflare على نطاق الناشر الخاص. يستقبل Worker تلك الحمولة ويشغّل أدوات Zaraz المهيأة عليها: يرسل تكامل Google Analytics 4 إشارة Measurement Protocol، ويرسل تكامل Meta Pixel حدث Conversions API، ويرسل تكامل Mixpanel استدعاء HTTP API. لا يُحمَّل JavaScript للبائع الطرف الثالث في المتصفح قط، وكوكيز البائع إما لا تُعيَّن أصلاً أو تُكتب عبر نطاق الطرف الأول لـ Cloudflare عبر Worker، ولا يتلقى البائع سوى البيانات التي تُحيلها إليه صراحةً إعدادات Zaraz للناشر.

هذا هو القيمة المعمارية المقترحة. وهو أيضاً سبب اختلاف صورة الموافقة عن أي مدير علامات من جانب العميل. مع الإعداد التقليدي، يكون سؤال الموافقة هو ما إذا كان JavaScript للبائع يُحمَّل أم لا. مع Zaraz، لا يُحمَّل JavaScript في أي حال — يصبح السؤال هو ما إذا كانت حمولة الخادم تُرسَل أو تُكبَّح، وما إذا كانت الحمولة تحتوي على المعرفات التي يحتاجها البائع لتتبع المستخدم. كلا السؤالين لهما إجابات محددة جيداً في Zaraz Consent API؛ مهمة الناشر هي ربطهما بشكل صحيح.

Zaraz Consent API وكيف يختلف عن CMPs من جانب العميل

يأتي Zaraz مع وحدة موافقة مدمجة — Zaraz Consent Tools — تحافظ على حالة موافقة لكل زائر وتتحكم في أي أدوات مهيأة تُطلَق. تُكشف الحالة من خلال JavaScript API صغير: zaraz.consent.set({ analytics: true, marketing: false }) لتسجيل اختيار المستخدم، وzaraz.consent.get('analytics') لقراءته، وzaraz.consent.getAll() للخريطة الكاملة، وzaraz.consent.modal() لفتح واجهة الموافقة، ومستمعو الأحداث على zaraz.consent.onModalShown والأحداث ذات الصلة لسلوك واجهة المستخدم المخصص. كل أداة Zaraz في لوحة التحكم مهيأة بمعرف غرض واحد أو أكثر، ولا يُنفّذ Worker الأداة إلا عندما تُمنح الأغراض ذات الصلة في حالة موافقة الزائر.

خيار التكامل هو ما إذا كنت ستستخدم نافذة الموافقة المدمجة في Zaraz أو تربط Zaraz بـ CMP خارجي. النافذة المدمجة هي أبسط مسار: تفعيل Consent Tools، تحديد الأغراض، تهيئة كل أداة بالغرض الصحيح، والنشر. مسار CMP الخارجي هو الاختيار الصحيح للمنظمات التي توحّد بالفعل على Cookiebot أو OneTrust أو Usercentrics أو CMP مخصص — تعمل Zaraz عندئذٍ في مرحلة ما بعد CMP، مع استدعاء CMP لـ zaraz.consent.set() بينما يتنقل المستخدم عبر اللافتة. كلا المسارين يصلان إلى نفس نقطة التطبيق: يتحقق Worker من حالة الموافقة قبل تنفيذ كل أداة، والأدوات التي لم تُمنح أغراضها ببساطة لا تعمل.

دعم IAB TCF والأنظمة الإقليمية

أضافت Zaraz دعم IAB TCF v2 في عام 2023 وتتبعت الإطار منذ ذلك الحين. للناشرين العاملين في EEA والمملكة المتحدة في ظل شراكات الإعلانات القائمة على TCF، يترجم التكامل سلسلة موافقة TCF إلى حالة غرض Zaraz تلقائياً عندما يختار الناشر ذلك. للمناطق غير TCF، يربط الناشر أغراضاً مخصصة — عادةً analytics وmarketing وpersonalization وfunctional — بأدوات Zaraz ذات الصلة مباشرةً. يطبّق نفس Worker كليهما، مما يعني أن إعدادات Zaraz الواحدة يمكن أن تخدم زائراً من EEA عبر TCF وزائراً كاليفورنياً عبر بوابة غرض تسويق مخصصة دون خطين متوازيين.

لماذا تغير Zaraz صورة GDPR وePrivacy

الموقف القانوني بموجب GDPR وePrivacy وCCPA لا يُعفى من التنفيذ من جانب الخادم — الأساس القانوني يتبع البيانات لا وسيلة النقل — لكن السطح العملي للامتثال يتغير. ثلاثة تحولات مهمة.

نمط التكامل الذي يعمل

يحتوي النشر المرجعي على أربعة أجزاء متحركة. الأول هو تهيئة Zaraz في الصفحة، المحملة من نطاق الناشر عبر وكيل Cloudflare. الثاني هو إما نافذة Consent Tools المدمجة أو CMP خارجي يستدعي zaraz.consent.set() بينما يتخذ المستخدم خياراته. الثالث هو تهيئة لوحة تحكم Zaraz التي تربط كل أداة بالأغراض الصحيحة — أدوات التحليلات بغرض التحليلات، وأدوات الإعلان بغرض التسويق، وأدوات إعادة تشغيل الجلسة بغرض وظيفي أو بحثي أكثر صرامة، وأي أداة تعتمد على نقل الطرف الثالث بغرض نقل عبر الحدود إذا كشف إشعار خصوصية الناشر عن ذلك كاختيار منفصل. الرابع هو سجل من جانب الخادم — إما Cloudflare Analytics أو Logpush إلى بحيرة بيانات الناشر أو Worker مخصص يكتب قرارات الموافقة في مخزن قابل للاستعلام — حتى يمكن تقديم سجل الموافقة عند طلب الجهة التنظيمية.

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

أين لا تزال Zaraz تتطلب معالجة دقيقة

Zaraz ليست حلاً للموافقة بالتصميم يُزيل الحاجة إلى التفكير. ثلاثة مجالات تتطلب معالجة متعمدة. تضمينات النقر للتحميل — YouTube وTwitter وInstagram وTikTok للفيديو — لا تزال بحاجة إلى نفس نمط العنصر النائب الذي يستخدمه أي نشر يُقدّم الموافقة أولاً، لأن Zaraz لا تُوكّل وكالة حالياً لإطارات iframes للفيديو المضمّنة. معرّفات جانب العميل التي يختار الناشر تعيينها في المتصفح لأغراض الطرف الأول — معرّف مستخدم مسجّل الدخول، رمز جلسة، دلو اختبار A/B — تظل على جانب الناشر من حد الموافقة وتحتاج إلى منطق تحجبها الخاص. ويجب أن يصف إشعار الخصوصية بدقة نموذج نقل جانب الخادم، بما في ذلك دور Cloudflare كمعالج والموقع الجغرافي لـ Workers التي تتولى البيانات، لأن حافة Cloudflare تعمل في مناطق متعددة وقد تُعالَج حركة مرور الزائر في منطقة ليست منطقته. مع معالجة هذه الجوانب، يتحول نشر Zaraz في عام 2026 من منتج إدارة علامات إلى واحدة من أنظف بنى الموافقة التي يمكن للناشر تشغيلها: سطح كوكيز أصغر، وطلبات طرف ثالث أقل، وتطبيق مركزي، ومسار تدقيق يستطيع الجهة التنظيمية قراءته فعلاً.

← المدونة قراءة الكل →