Шта 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 и kako се разликује од CMP-ова на страни клијента

Zaraz долази са уграђеним модулом за пристанак — Zaraz Consent Tools — koji одржава стање пристанка по посетиоцу и контролише које конфигурисане алате активира. Стање је изложено кроз мали 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-ом koji позива zaraz.consent.set() како корисник пролази кроз банер. Оба пута завршавају на истој тачки примене: Worker проверава стање пристанка пре него што сваки алат изврши, и алати чије сврхе нису одобрене једноставно не раде.

Подршка IAB TCF и регионалне уредбе

Zaraz је додао подршку IAB TCF v2 у 2023. години и прати оквир унапред од тада. За издаваче koji послују у EEA и UK под TCF-заснованим рекламним партнерствима, интеграција аутоматски преводи TCF ниску пристанка у стање сврхе Zaraz када издавач пристане. За не-TCF регионе издавач директно пресликава прилагођене сврхе — обично analytics, marketing, personalization, functional — на релевантне Zaraz алате. Исти Worker примењује оба, što значи да једна Zaraz конфигурација може да служи и EEA посетиоцу кроз TCF и калифорнијском посетиоцу кроз прилагођену маркетиншку сврхну капију без два паралелна цевовода.

Зашто Zaraz мења GDPR и ePrivacy слику

Правни став под GDPR, ePrivacy и CCPA није изузет извршавањем на страни сервера — правна основа прати податке, а не транспорт — али се практична површина усклађености мења. Три помака су битна.

• Површина колачића се смањује. Већина колачића добављача никада не добија упис јер JavaScript добављача никада не ради у прегледачу. Колачићи koji остају су обично Zaraz-ов властити идентификатор сесије и сви идентификатори прве стране које је издавач намерно проширио. Површина неесенцијалних колачића коју банер мора да контролише је стога драматично мања — понекад само један или два колачића наспрам десетак или више које производи типичан клијентски стек.
• Откривање преноса трећим странама се мења. Јер Worker шаље податке добављачима путем позива сервер-на-сервер, путања података из прегледача посетиоца иде до Cloudflare-овог руба и одатле до конфигурисаних добављача. Обавештење о приватности мора да то одражава — Cloudflare је обрађивач, а сваки Zaraz алат је даунстрим прималац — али је откривање у многим погледима чистије од еквивалентне клијентске путање јер издавач има потпуну контролу над тим шта се прослеђује.
• Ревизијски траг је централизованији. Јер сваки добављачки догађај пролази кроз Worker, издавач има јединствену тачку на kojoj се стање пристанка, корисна вредност догађаја и низводни прималац могу евидентирати. Регулатори koji очекују упитни евиденцију пристанка имају јаснији одговор са Zaraz-ом него са распршеношћу клијентских тагова.

Образац интеграције koji функционише

Референтно постављање има четири покретне делове. Прво је иницијализација Zaraz на страници, учитана са издавачевог домена преко Cloudflare-овог проксија. Друго је или уграђени Consent Tools модал или спољни CMP koji позива zaraz.consent.set() kako корисник прави изборе. Треће је конфигурација Zaraz контролне табле koja пресликава сваки алат на праве сврхе — аналитичке алате на аналитичку сврху, рекламне алате на маркетиншку сврху, алате за поновно приказивање сесија на строжију функционалну или истраживачку сврху, и сваки алат koji зависи од преноса трећим странама на сврху прекограничног преноса ако обавештење о приватности издавача то излаже као посебан избор. Четврто је евиденција на страни сервера — или Cloudflare Analytics, Logpush до издавачевог складишта података, или прилагођени Worker koji записује одлуке о пристанку у упитно складиште — тако да евиденција пристанка може бити произведена на захтев регулатора.

Корак валидације је исти редослед са четири провере koji се примењује на сваку интеграцију пристанка, али са Zaraz-специфичним обртом. Чиста сесија прегледача са приказаним банером али без уклоног избора треба да произведе нула захтева из прегледача посетиоца ка сваком добављачком домену и нула неесенцијалних колачића — оба је лакше потврдити са Zaraz-ом него са клијентским стеком јер је одсуство захтева трећих страна подразумевано, а не конфигурисани изузетак. Посета одбијањем треба да задржи то стање. Посета прихватањем треба да произведе POST-ове Zaraz крајње тачке koji носе само догађаје за које је корисник пристао, а Worker евиденције треба да покажу активирање низводног алата. Повлачење треба одмах да заустави даља извршавања Worker алата, истекне све Zaraz-постављене колачиће и покрене одговарајуће сигнале брисања или одјаве за конфигурисане низводне добављаче.

Где Zaraz и даље захтева пажљиво поступање

Zaraz није решење пристанка по архитектури koje уклања потребу за размишљањем. Три области захтевају намерно поступање. Уградње кликом за учитавање — YouTube, Twitter, Instagram, TikTok видео — и даље захтевају исти образац носача koji свако прво-пристанак постављање користи, јер Zaraz тренутно не проксира уграђене видео iframe-ове. Идентификатори на страни клијента koje издавач одлучи да постави у прегледачу за сврхе прве стране — ID пријављеног корисника, токен сесије, A/B тест група — остају на издавачевој страни границе пристанка и требају сопствену логику контроле. И обавештење о приватности мора тачно да опише модел преноса на страни сервера, укључујући Cloudflare-ову улогу као обрађивача и географску локацију Workers-а koji рукују подацима, јер Cloudflare-ов руб ради у више региона и саобраћај посетиоца може бити обрађен у региону koji није њихов властити. Са тим решено, Zaraz постављање у 2026. прелази из производа за управљање тагovima у једну од чистих архитектура пристанка коју издавач може да покрене: мања површина колачића, мање захтева трећих страна, централизована примена и ревизијски траг koji регулатор може заиста да прочита.