Što Zaraz zapravo radi na rubu

Zaraz je upravitelj oznaka na strani poslužitelja koji se izvodi unutar Cloudflare Workersa. Kada posjetitelj učita stranicu, HTML izdavača uključuje mali Zaraz inicijalizacijski skript — obično nekoliko kilobajta — koji prikuplja strukturirani sadržaj događaja iz preglednika (pregled stranice, klik, prilagođeni događaj) i šalje ga POST zahtjevom na Cloudflareovu krajnju točku na izdavačevoj vlastitoj domeni. Worker prima taj sadržaj i pokreće konfigurirane Zaraz alate na njemu: integracija Google Analytics 4 šalje Measurement Protocol pogodak, integracija Meta Pixela šalje Conversions API događaj, integracija Mixpanela šalje HTTP API poziv. JavaScript trećih strana dobavljača nikad se ne učitava u preglednik, kolačići dobavljača ili se nikad ne postavljaju ili se zapisuju putem Cloudflareove domene prve strane putem Workera, a dobavljač prima samo podatke koje Zarazova konfiguracija izdavača izričito prosljeđuje.

To je arhitektonska vrijednosna ponuda. Zato je i slika pristanka drugačija od bilo kojeg upravitelja oznaka na strani klijenta. Uz tradicionalnu postavku, pitanje pristanka je hoće li se JavaScript dobavljača učitati ili ne. Uz Zaraz, JavaScript se nikad ne učitava ni u jednom slučaju — pitanje postaje hoće li se sadržaj na strani poslužitelja poslati ili potisnuti, i sadrži li sadržaj identifikatore koje dobavljač treba za praćenje korisnika. Oba pitanja imaju dobro definirane odgovore u Zaraz Consent API-ju; posao izdavača je ispravno ih mapirati.

Zaraz Consent API i kako se razlikuje od CMP-ova na strani klijenta

Zaraz dolazi s ugrađenim modulom pristanka — Zaraz Consent Tools — koji održava stanje pristanka po posjetitelju i kontrolira koje se konfigurirani alati aktiviraju. Stanje je izloženo putem malog JavaScript API-ja: zaraz.consent.set({ analytics: true, marketing: false }) za bilježenje korisnikovog izbora, zaraz.consent.get('analytics') za čitanje, zaraz.consent.getAll() za cijelu mapu, zaraz.consent.modal() za otvaranje korisničkog sučelja pristanka, te slušatelji događaja na zaraz.consent.onModalShown i srodnim događajima za prilagođeno ponašanje korisničkog sučelja. Svaki Zaraz alat na nadzornoj ploči konfiguriran je s jednom ili više ID-ova svrhe, a Worker izvodi alat samo kada su relevantne svrhe odobrene u stanju pristanka posjetitelja.

Izbor integracije je koristiti li ugrađeni Zarazov modalni prozor pristanka ili vezati Zaraz uz vanjski CMP. Ugrađeni modalni prozor najjednostavniji je put: omogućiti Consent Tools, definirati svrhe, konfigurirati svaki alat s odgovarajućom svrhom i pustiti. Put vanjskog CMP-a pravi je izbor za organizacije koje već standardiziraju na Cookiebotu, OneTrustu, Usercentricsovim ili prilagođenim CMP-om — Zaraz tada radi nizvodno od CMP-a, pri čemu CMP poziva zaraz.consent.set() dok korisnik prolazi kroz banner. Oba puta završavaju na istoj točki primjene: Worker provjerava stanje pristanka prije nego što se svaki alat izvrši, a alati čije svrhe nisu odobrene jednostavno se ne pokreću.

Podrška IAB TCF i regionalni režimi

Zaraz je dodao podršku za IAB TCF v2 2023. i od tada prati okvir. Za izdavače koji rade u EEA-u i Ujedinjenom Kraljevstvu u sklopu reklamnih partnerstava temeljenih na TCF-u, integracija automatski prevodi TCF niz pristanka u Zarazovo stanje svrhe kada se izdavač odluči za to. Za regije koje nisu TCF, izdavač mapira prilagođene svrhe — obično analytics, marketing, personalization, functional — izravno na relevantne Zaraz alate. Isti Worker primjenjuje oboje, što znači da jedna Zarazova konfiguracija može opsluživati i EEA posjetitelja putem TCF-a i kalifornijskog posjetitelja putem prilagođene marketinške svrhe bez dvije paralelne cjevovode.

Zašto Zaraz mijenja sliku GDPR-a i ePrivacyja

Pravni položaj prema GDPR-u, ePrivacyju i CCPA-u nije izuzet izvođenjem na strani poslužitelja — pravna osnova prati podatke, a ne transport — ali praktična površina usklađenosti mijenja se. Tri promjene su važne.

• Površina kolačića smanjuje se. Većina kolačića dobavljača nikad se ne zapisuje jer JavaScript dobavljača nikad ne radi u pregledniku. Kolačići koji ostaju obično su Zarazov vlastiti identifikator sesije i svi identifikatori prve strane koje je izdavač namjerno proširio. Površina neesencijalnih kolačića koje banner mora kontrolirati stoga je dramatično manja — ponekad samo jedan ili dva kolačića nasuprot desetak ili više koje tipičan stog na strani klijenta proizvodi.
• Otkrivanje prijenosa trećih strana mijenja se. Budući da Worker šalje podatke dobavljačima putem poziva od poslužitelja do poslužitelja, put podataka od posjetiteljevog preglednika ide do Cloudflareovog ruba i odatle do konfiguriranih dobavljača. Obavijest o privatnosti mora to odražavati — Cloudflare je izvršitelj obrade, a svaki Zaraz alat nizvodnji je primatelj — ali otkrivanje je na mnoge načine jasnije nego ekvivalentni put na strani klijenta jer izdavač ima potpunu kontrolu nad onim što se prosljeđuje.
• Revizijski trag je centraliziraniji. Budući da svaki događaj dobavljača prolazi kroz Worker, izdavač ima jednu točku na kojoj se mogu bilježiti stanje pristanka, sadržaj događaja i nizvodni primatelj. Regulatori koji očekuju traživ zapisnik pristanka imaju jasniji odgovor uz Zaraz nego uz gomilanje oznaka na strani klijenta.

Integracijski uzorak koji funkcionira

Referentna implementacija ima četiri pokretna dijela. Prvo je Zarazova inicijalizacija na stranici, učitana s domene izdavača putem Cloudflareovog proxyja. Drugo je ili ugrađeni Consent Tools modalni prozor ili vanjski CMP koji poziva zaraz.consent.set() dok korisnik donosi izbore. Treće je konfiguracija Zarazove nadzorne ploče koja mapira svaki alat na odgovarajuće svrhe — alate za analitiku na svrhu analitike, alate za oglašavanje na svrhu marketinga, alate za snimanje sesija na stroži funkcionalni ili istraživački cilj, te svaki alat koji ovisi o prijenosu trećih strana na svrhu prekograničnog prijenosa ako obavijest o privatnosti izdavača to izlaže kao zasebni izbor. Četvrto je zapis na strani poslužitelja — ili Cloudflare Analytics, Logpush u izdavačevo jezero podataka, ili prilagođeni Worker koji zapisuje odluke o pristanku u traživo pohranjivanje — kako bi se zapis o pristanku mogao dostaviti na zahtjev regulatora.

Korak provjere valjanosti ista je sekvenca četiriju provjera koja se primjenjuje na bilo koju integraciju pristanka, ali sa Zarazovim specifičnim zaokretom. Čista preglednikova sesija s prikazanim bannerom ali bez napravljenog izbora trebala bi producirati nula zahtjeva od posjetiteljevog preglednika prema bilo kojoj domeni dobavljača i nula neesencijalnih kolačića — oboje se lakše potvrđuje uz Zaraz nego uz stog na strani klijenta jer je odsutnost zahtjeva trećih strana zadano, a ne konfigurirana iznimka. Posjet s odbijanjem trebao bi zadržati to stanje. Posjet s prihvaćanjem trebao bi producirati POST-ove na Zarazovu krajnju točku koji nose samo događaje na koje je korisnik pristao, a zapisnici Workera trebali bi pokazivati aktiviranja nizvodnih alata. Povlačenje bi trebalo odmah zaustaviti daljnje izvođenje Workerovih alata, isteći sve kolačiće koje je Zaraz postavio i pokrenuti odgovarajuće signale brisanja ili odjave prema konfiguriranim nizvodnim dobavljačima.

Gdje Zaraz još uvijek zahtijeva pažljivo rukovanje

Zaraz nije rješenje pristanka-po-arhitekturi koje uklanja potrebu za razmišljanjem. Tri područja zahtijevaju namjerno rukovanje. Ugradnje klik-za-učitavanje — YouTube, Twitter, Instagram, TikTok video — još uvijek trebaju isti uzorak rezerviranog mjesta koji koristi svaka implementacija s pristankom na prvom mjestu, jer Zaraz trenutno ne proksira ugrađene video iframeove. Identifikatori na strani klijenta koje izdavač odluči postaviti u preglednika za svrhe prve strane — ID prijavljenog korisnika, token sesije, segment A/B testa — ostaju na izdavačevoj strani granice pristanka i trebaju vlastitu logiku kontrole pristupa. I obavijest o privatnosti mora točno opisati model prijenosa na strani poslužitelja, uključujući Cloudflareovu ulogu kao izvršitelja obrade i geografsku lokaciju Workersa koji rukuju podacima, jer Cloudflareov rub radi u više regija i posjetiteljev promet može se obrađivati u regiji koja nije njihova. Uz to riješeno, Zarazova implementacija 2026. pretvara se iz proizvoda za upravljanje oznakama u jednu od najčišćih arhitektura pristanka koje izdavač može pokrenuti: manja površina kolačića, manje zahtjeva trećih strana, centralizirana primjena i revizijski trag koji regulatori zaista mogu pročitati.