Посібник з інтеграції Cloudflare Zaraz Consent: Серверне управління тегами на edge для 2026 року
Cloudflare Zaraz відрізняється від більшості продуктів управління тегами, що з'явилися раніше. Передумова є структурною, а не поступовою: замість завантаження Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight та JavaScript кожного іншого постачальника в браузер відвідувача, Zaraz виконує ці інтеграції всередині Cloudflare Workers, що працюють на edge, перед джерелом видавця. Браузер бачить єдиний малий Zaraz runtime; інструменти постачальника працюють на стороні сервера. Цей архітектурний вибір має накопичувальні наслідки для згоди. Поверхня файлів cookie різко зменшується, оскільки більшість файлів cookie постачальників ніколи не встановлюється. Поверхня зняття відбитків пальців зменшується, оскільки більшість JavaScript постачальників ніколи не виконується в контексті браузера. І точка застосування згоди переходить від JavaScript-банера, що контролює купу тегів <script>, до рішення на стороні сервера, яке визначає, які інтеграції Zaraz спрацьовують і яке навантаження вони отримують. Видавець, який правильно підключає Zaraz до CMP, отримує меншу поверхню відповідності, швидші сторінки та чіткіший журнал аудиту. Видавець, який ставиться до Zaraz як до швидшого Google Tag Manager і пропускає підключення згоди, отримує регуляторний ризик, який важче виявити, оскільки значна частина активності невидима для стандартних аудитів на основі браузера.
Що Zaraz насправді робить на edge
Zaraz — це серверний менеджер тегів, що виконується всередині Cloudflare Workers. Коли відвідувач завантажує сторінку, HTML видавця містить невеликий скрипт ініціалізації Zaraz — зазвичай кілька кілобайтів — який збирає структуроване навантаження події з браузера (перегляд сторінки, клік, користувацька подія) та POST-надсилає його до кінцевої точки Cloudflare на власному домені видавця. Worker отримує це навантаження та запускає налаштовані інструменти Zaraz проти нього: інтеграція Google Analytics 4 надсилає Measurement Protocol-запит, інтеграція Meta Pixel надсилає подію Conversions API, інтеграція Mixpanel надсилає HTTP API-виклик. JavaScript третьої сторони постачальника ніколи не завантажується в браузер, файли cookie постачальника або взагалі не встановлюються, або записуються через першопартійний домен Cloudflare через Worker, і постачальник отримує лише ті дані, які конфігурація Zaraz видавця явно надсилає.
Це архітектурна ціннісна пропозиція. Саме тому картина згоди відрізняється від будь-якого клієнтського менеджера тегів. При традиційному налаштуванні питання згоди полягає в тому, чи завантажується JavaScript постачальника. З Zaraz JavaScript ніколи не завантажується в обох випадках — питання стає в тому, чи відправляється серверне навантаження або придушується, і чи містить навантаження ідентифікатори, які постачальнику потрібні для відстеження користувача. Обидва питання мають чітко визначені відповіді в Zaraz Consent API; завдання видавця — правильно їх відобразити.
Zaraz Consent API та чим він відрізняється від клієнтських CMP
Zaraz постачається з вбудованим модулем згоди — Zaraz Consent Tools — який підтримує стан згоди для кожного відвідувача та контролює, які налаштовані інструменти спрацьовують. Стан відкривається через невеликий JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) для запису вибору користувача, zaraz.consent.get('analytics') для читання, zaraz.consent.getAll() для повної карти, zaraz.consent.modal() для відкриття UI згоди та прослуховувачі подій на zaraz.consent.onModalShown та пов'язаних подіях для користувацької поведінки UI. Кожен інструмент Zaraz на інформаційній панелі налаштований з одним або кількома ID цілей, і 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 та UK у рамках рекламних партнерств на основі TCF, інтеграція автоматично перетворює рядок згоди TCF у стан цілей Zaraz, коли видавець підключається. Для регіонів без TCF видавець безпосередньо відображає користувацькі цілі — зазвичай analytics, marketing, personalization, functional — на відповідні інструменти Zaraz. Той самий Worker застосовує обидва, що означає, що єдина конфігурація Zaraz може обслуговувати як відвідувача EEA через TCF, так і каліфорнійського відвідувача через користувацький маркетинговий шлюз без двох паралельних пайплайнів.
Чому Zaraz змінює картину GDPR та ePrivacy
Правова позиція відповідно до GDPR, ePrivacy та CCPA не звільняється серверним виконанням — правова основа слідує за даними, а не за транспортом — але практична поверхня відповідності змінюється. Три зміни мають значення.
- Поверхня файлів cookie зменшується. Більшість файлів cookie постачальників ніколи не записується, оскільки JavaScript постачальника ніколи не запускається в браузері. Файли cookie, що залишаються, зазвичай є власним ідентифікатором сесії Zaraz та будь-якими першопартійними ідентифікаторами, які видавець навмисно поширив. Поверхня несуттєвих файлів cookie, яку банер повинен контролювати, тому різко менша — іноді лише один або два файли cookie проти дюжини або більше, які виробляє типовий клієнтський стек.
- Розкриття передачі третім сторонам змінюється. Оскільки Worker надсилає дані постачальникам через виклики сервер-до-сервера, шлях даних від браузера відвідувача проходить до edge Cloudflare і звідти до налаштованих постачальників. Повідомлення про конфіденційність має відображати це — Cloudflare є обробником, а кожен інструмент Zaraz є нижчим одержувачем — але розкриття в багатьох відношеннях чіткіше, ніж еквівалентний клієнтський шлях, оскільки видавець має повний контроль над тим, що пересилається.
- Журнал аудиту більш централізований. Оскільки кожна подія постачальника проходить через Worker, у видавця є єдина точка, де можна зафіксувати стан згоди, навантаження події та нижчого одержувача. Регулятори, які очікують запитного журналу згоди, отримують чіткішу відповідь від Zaraz, ніж від набору клієнтських тегів.
Шаблон інтеграції, який працює
Еталонне розгортання має чотири рухомі частини. Перша — ініціалізація Zaraz на сторінці, завантажена з домену видавця через проксі Cloudflare. Друга — вбудований модал Consent Tools або зовнішній CMP, який викликає zaraz.consent.set(), коли користувач робить вибір. Третя — конфігурація інформаційної панелі Zaraz, яка відображає кожен інструмент на правильні цілі — аналітичні інструменти на ціль аналітики, рекламні інструменти на ціль маркетингу, інструменти повторного відтворення сесій на суворішу функціональну або дослідницьку ціль, і будь-який інструмент, залежний від передачі третім сторонам, на ціль транскордонної передачі, якщо повідомлення про конфіденційність видавця відкриває це як окремий вибір. Четверта — серверний журнал — або Cloudflare Analytics, Logpush до озера даних видавця, або користувацький Worker, який записує рішення щодо згоди до запитного сховища — щоб запис згоди міг бути наданий на запит регулятора.
Крок перевірки — це та сама чотирикрокова послідовність, що застосовується до будь-якої інтеграції згоди, але з Zaraz-специфічним поворотом. Чиста сесія браузера з показаним банером, але без зробленого вибору, повинна видавати нуль запитів від браузера відвідувача до будь-якого домену постачальника та нуль несуттєвих файлів cookie — обидва легше підтвердити з Zaraz, ніж з клієнтським стеком, оскільки відсутність стороннього запитів є стандартним значенням, а не налаштованим винятком. Відмовний візит повинен зберігати цей стан. Візит з прийняттям повинен видавати POST-и кінцевої точки Zaraz, що несуть лише події, на які погодився користувач, а журнали Worker повинні показувати спрацювання нижчого інструменту. Відкликання повинно негайно зупинити подальші виконання інструментів Worker, завершити дію файлів cookie, встановлених Zaraz, та ініціювати відповідні сигнали видалення або відмови налаштованим нижчим постачальникам.
Де Zaraz все ще вимагає обережного поводження
Zaraz не є архітектурним рішенням для згоди, яке усуває необхідність думати. Три сфери вимагають навмисного поводження. Вбудовані елементи з натисканням для завантаження — YouTube, Twitter, Instagram, TikTok відео — все ще потребують того ж шаблону-заповнювача, що використовує будь-яке розгортання з пріоритетом згоди, оскільки Zaraz наразі не проксує вбудовані відеоiframe. Клієнтські ідентифікатори, які видавець вирішує встановити в браузері для першопартійних цілей — ID авторизованого користувача, токен сесії, A/B тест-кошик — залишаються на стороні видавця межі згоди та потребують власної логіки контролю. А повідомлення про конфіденційність повинно точно описувати модель серверної передачі, включаючи роль Cloudflare як обробника та географічне розташування Workers, що обробляють дані, оскільки edge Cloudflare працює в кількох регіонах і трафік відвідувача може оброблятися в регіоні, що не є їхнім власним. Після вирішення цих питань розгортання Zaraz у 2026 році перетворюється з продукту управління тегами на одну з найчистіших архітектур згоди, яку може запустити видавець: менша поверхня файлів cookie, менше запитів третіх сторін, централізоване застосування та журнал аудиту, який регулятор насправді може прочитати.