راهنمای یکپارچهسازی رضایت Cloudflare Zaraz: مدیریت تگ سمت سرور در لبه برای سال ۲۰۲۶
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 است — معمولاً چند کیلوبایت — که یک بار رویداد ساختاریافته از مرورگر (مشاهده صفحه، کلیک، رویداد سفارشی) جمعآوری میکند و آن را به یک نقطه پایانی Cloudflare در دامنه خود ناشر POST میکند. 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 و نحوه تفاوت آن با CMPهای سمت کلاینت
Zaraz با یک ماژول رضایت داخلی همراه است — Zaraz Consent Tools — که یک وضعیت رضایت به ازای هر بازدیدکننده را حفظ میکند و تعیین میکند کدام ابزارهای پیکربندیشده فعال میشوند. وضعیت از طریق یک API JavaScript کوچک در معرض دید قرار میگیرد: 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 را در سال ۲۰۲۳ اضافه کرد و از آن زمان چارچوب را دنبال کرده است. برای ناشرانی که در EEA و بریتانیا تحت مشارکتهای تبلیغاتی مبتنی بر TCF فعالیت میکنند، یکپارچهسازی رشته رضایت TCF را به طور خودکار به وضعیت هدف Zaraz ترجمه میکند وقتی ناشر انتخاب میکند. برای مناطق غیر TCF، ناشر اهداف سفارشی را — معمولاً analytics، marketing، personalization، functional — مستقیماً به ابزارهای Zaraz مربوطه نگاشت میکند. همان Worker هر دو را اعمال میکند، به این معنا که یک پیکربندی تکی Zaraz میتواند هم یک بازدیدکننده EEA را از طریق TCF و هم یک بازدیدکننده کالیفرنیایی را از طریق یک دروازه هدف بازاریابی سفارشی بدون دو خط لوله موازی خدمت کند.
چرا Zaraz تصویر GDPR و ePrivacy را تغییر میدهد
موضع قانونی تحت GDPR، ePrivacy و CCPA از اجرای سمت سرور معاف نیست — مبنای قانونی دادهها را دنبال میکند، نه حملونقل — اما سطح انطباق عملی تغییر میکند. سه تغییر مهم هستند.
- سطح کوکی کاهش مییابد. اکثر کوکیهای فروشنده هرگز نوشته نمیشوند زیرا JavaScript فروشنده هرگز در مرورگر اجرا نمیشود. کوکیهایی که باقی میمانند معمولاً شناسه نشست خود Zaraz و هر شناسه شخص اولی هستند که ناشر عمداً منتشر کرده است. سطح کوکی غیرضروری که بنر باید دروازهبانی کند بنابراین به طور چشمگیری کوچکتر است — گاهی اوقات فقط یک یا دو کوکی در برابر دهها کوکی که یک پشته معمولی سمت کلاینت تولید میکند.
- افشای انتقال شخص ثالث تغییر میکند. از آنجایی که Worker دادهها را از طریق فراخوانیهای سرور به سرور به فروشندگان ارسال میکند، مسیر داده از مرورگر بازدیدکننده به لبه Cloudflare و از آنجا به فروشندگان پیکربندیشده است. اطلاعیه حریم خصوصی باید این را منعکس کند — Cloudflare یک پردازشگر است و هر ابزار Zaraz یک دریافتکننده پاییندست است — اما افشا از بسیاری جهات تمیزتر از مسیر معادل سمت کلاینت است زیرا ناشر کنترل کامل بر آنچه ارسال میشود دارد.
- مسیر حسابرسی متمرکزتر است. از آنجایی که هر رویداد فروشنده از طریق Worker عبور میکند، ناشر یک نقطه واحد دارد که در آن وضعیت رضایت، بار رویداد و دریافتکننده پاییندست میتوانند ثبت شوند. قانونگذارانی که انتظار یک لاگ رضایت قابل جستجو دارند پاسخ واضحتری با Zaraz نسبت به گسترش تگهای سمت کلاینت دارند.
الگوی یکپارچهسازی که کار میکند
استقرار مرجع چهار بخش متحرک دارد. اول مقداردهی اولیه 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 در حال حاضر iframeهای ویدیوی جاسازیشده را پروکسی نمیکند. شناسههای سمت کلاینت که ناشر انتخاب میکند در مرورگر برای اهداف شخص اول تنظیم کند — یک شناسه کاربر وارد شده، یک توکن نشست، یک سطل آزمایش A/B — در سمت ناشر مرز رضایت باقی میمانند و به منطق دروازهبانی خود نیاز دارند. و اطلاعیه حریم خصوصی باید مدل انتقال سمت سرور را به دقت توصیف کند، از جمله نقش Cloudflare به عنوان یک پردازشگر و مکان جغرافیایی Workerهایی که دادهها را مدیریت میکنند، زیرا لبه Cloudflare در مناطق متعددی اجرا میشود و ترافیک بازدیدکننده ممکن است در منطقهای که منطقه خود آنها نیست پردازش شود. با مدیریت این موارد، یک استقرار Zaraz در سال ۲۰۲۶ از یک محصول مدیریت تگ به یکی از تمیزترین معماریهای رضایتی که یک ناشر میتواند اجرا کند تبدیل میشود: سطح کوکی کوچکتر، درخواستهای شخص ثالث کمتر، اعمال متمرکز، و یک مسیر حسابرسی که یک قانونگذار واقعاً میتواند بخواند.