Ang talagang ginagawa ng Zaraz sa edge

Ang Zaraz ay isang server-side na tag manager na nagpapatakbo sa loob ng Cloudflare Workers. Kapag nag-load ang isang bisita ng pahina, ang HTML ng publisher ay naglalaman ng isang maliit na initialization script ng Zaraz — karaniwang ilang kilobytes — na nangongolekta ng structured na event payload mula sa browser (pageview, click, custom event) at nag-POST nito sa isang Cloudflare endpoint sa sariling domain ng publisher. Tinatanggap ng Worker ang payload na iyon at pinapatakbo ang mga naka-configure na tool ng Zaraz laban dito: ang integrasyon ng Google Analytics 4 ay nagpapadala ng Measurement Protocol hit, ang integrasyon ng Meta Pixel ay nagpapadala ng Conversions API event, ang integrasyon ng Mixpanel ay nagpapadala ng HTTP API call. Ang third-party na JavaScript ng vendor ay hindi kailanman naglo-load sa browser, ang mga cookie ng vendor ay hindi kailanman naitakda o isinusulat sa pamamagitan ng first-party na domain ng Cloudflare sa pamamagitan ng Worker, at ang vendor ay nakatanggap lamang ng data na tahasang ipinasa ng configuration ng Zaraz ng publisher.

Iyan ang arkitetyektural na value proposition. Ito rin ang dahilan kung bakit ang larawan ng pahintulot ay naiiba sa anumang client-side na tag manager. Sa tradisyonal na setup, ang tanong sa pahintulot ay kung ang JavaScript ng vendor ay nag-load o hindi. Sa Zaraz, ang JavaScript ay hindi kailanman naglo-load sa alinmang kaso — ang tanong ay nagiging kung ang server-side na payload ay ipinapadala o pinipigilan, at kung ang payload ay naglalaman ng mga identifier na kailangan ng vendor para subaybayan ang user. Ang parehong tanong ay may malinaw na tinukoy na mga sagot sa Zaraz Consent API; ang trabaho ng publisher ay ang tamang pag-map sa kanila.

Ang Zaraz Consent API at kung paano ito naiiba sa mga client-side na CMP

Ang Zaraz ay may kasamang built-in na consent module — Zaraz Consent Tools — na nagpapanatili ng per-visitor na estado ng pahintulot at nagpoporta kung aling mga naka-configure na tool ang mag-fire. Ang estado ay inilalantad sa pamamagitan ng isang maliit na JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) para i-record ang pagpili ng user, zaraz.consent.get('analytics') para basahin ito, zaraz.consent.getAll() para sa buong mapa, zaraz.consent.modal() para buksan ang consent UI, at mga event listener sa zaraz.consent.onModalShown at mga kaugnay na event para sa custom na gawi ng UI. Ang bawat tool ng Zaraz sa dashboard ay naka-configure ng isa o higit pang purpose ID, at ang Worker ay nagpapatakbo ng tool lamang kapag ang mga kaugnay na layunin ay ipinagkaloob sa estado ng pahintulot ng bisita.

Ang pagpipilian ng integrasyon ay kung gagamitin ang built-in na consent modal ng Zaraz o ikonekta ang Zaraz sa isang external na CMP. Ang built-in na modal ay ang pinakasimpleng landas: paganahin ang Consent Tools, tukuyin ang mga layunin, i-configure ang bawat tool sa tamang layunin, at i-ship. Ang landas ng external-CMP ay ang tamang pagpipilian para sa mga organisasyon na nag-standardize na sa Cookiebot, OneTrust, Usercentrics, o custom na CMP — ang Zaraz ay nagpapatakbo pagkatapos ng CMP, na may CMP na tumatawag ng zaraz.consent.set() habang gumagalaw ang user sa banner. Ang alinmang landas ay dumarating sa parehong punto ng pagpapatupad: sinusuri ng Worker ang estado ng pahintulot bago ang bawat tool na nagpapatakbo, at ang mga tool na ang mga layunin ay hindi ipinagkaloob ay simpleng hindi nagpapatakbo.

Suporta ng IAB TCF at ang mga rehiyonal na rehimen

Idinagdag ng Zaraz ang suporta ng IAB TCF v2 noong 2023 at sinundan ang framework mula noon. Para sa mga publisher na nag-ooperate sa EEA at UK sa ilalim ng mga TCF-based na pakikipagsosyo sa advertising, ang integrasyon ay awtomatikong isinasalin ang TCF consent string sa estado ng layunin ng Zaraz kapag nag-opt in ang publisher. Para sa mga rehiyon na hindi TCF, ang publisher ay nag-map ng custom na mga layunin — karaniwang analytics, marketing, personalization, functional — nang direkta sa mga kaugnay na tool ng Zaraz. Ang parehong Worker ay nagpapatupad ng dalawa, na nangangahulugang ang isang solong configuration ng Zaraz ay maaaring maglingkod sa isang bisita ng EEA sa pamamagitan ng TCF at isang bisita ng California sa pamamagitan ng custom na marketing-purpose na gate nang walang dalawang parallel na pipeline.

Bakit binabago ng Zaraz ang larawan ng GDPR at ePrivacy

Ang legal na postura sa ilalim ng GDPR, ePrivacy, at CCPA ay hindi exempt ng server-side na pagpapatupad — ang legal na batayan ay sumusunod sa data, hindi sa transportasyon — ngunit nagbabago ang praktikal na ibabaw ng pagsunod. Tatlong pagbabago ang mahalaga.

• Lumiliit ang ibabaw ng cookie. Ang karamihan ng mga cookie ng vendor ay hindi kailanman isinusulat dahil ang JavaScript ng vendor ay hindi kailanman nagpapatakbo sa browser. Ang mga cookie na nananatili ay karaniwang ang sariling session identifier ng Zaraz at anumang mga first-party identifier na sadyang ipinalaganap ng publisher. Ang ibabaw ng hindi-mahalagang cookie na dapat portahan ng banner ay kaya dramatikong mas maliit — minsan isang o dalawang cookie lamang kumpara sa dose-dosena na karaniwang nagagawa ng karaniwang client-side na stack.
• Nagbabago ang pagsisiwalat ng paglilipat ng third-party. Dahil ang Worker ay nagpapadala ng data sa mga vendor sa pamamagitan ng server-to-server na mga tawag, ang landas ng data mula sa browser ng bisita ay patungo sa edge ng Cloudflare at mula doon patungo sa mga naka-configure na vendor. Ang privacy notice ay dapat na ipakita ito — ang Cloudflare ay isang processor at ang bawat tool ng Zaraz ay isang downstream na tatanggap — ngunit ang pagsisiwalat ay sa maraming paraan ay mas malinis kaysa sa katumbas na client-side na landas dahil ang publisher ay may buong kontrol sa kung ano ang ipinasa.
• Ang audit trail ay mas sentralisado. Dahil ang bawat event ng vendor ay dumadaan sa Worker, ang publisher ay may isang punto kung saan maaaring i-log ang estado ng pahintulot, event payload, at downstream na tatanggap. Ang mga regulator na umaasang may query na consent log ay may mas malinaw na sagot sa Zaraz kaysa sa pagkalat ng mga client-side na tag.

Ang pattern ng integrasyon na gumagana

Ang reference deployment ay may apat na gumagalaw na bahagi. Ang una ay ang initialization ng Zaraz sa pahina, na na-load mula sa domain ng publisher sa pamamagitan ng proxy ng Cloudflare. Ang ikalawa ay ang built-in na Consent Tools modal o isang external na CMP na tumatawag ng zaraz.consent.set() habang gumagawa ng mga pagpipilian ang user. Ang ikatlo ay ang configuration ng Zaraz dashboard na nag-ma-map ng bawat tool sa tamang mga layunin — mga tool ng analytics sa layunin ng analytics, mga tool ng advertising sa layunin ng marketing, mga tool ng session-replay sa mas mahigpit na functional o research na layunin, at anumang tool na umaasa sa third-party-transfer sa layunin ng cross-border-transfer kung ang privacy notice ng publisher ay inilalantad iyon bilang isang hiwalay na pagpipilian. Ang ikaapat ay isang server-side na log — ang Cloudflare Analytics, Logpush sa data lake ng publisher, o isang custom na Worker na nagsusulat ng mga desisyon sa pahintulot sa isang queryable na store — para ang tala ng pahintulot ay maaaring maibigay sa kahilingan ng regulator.

Ang hakbang ng validation ay ang parehong apat na check sequence na naaangkop sa anumang integrasyon ng pahintulot ngunit may Zaraz-specific na baluktot. Ang isang malinis na session ng browser na may ipinakitang banner ngunit walang ginawang pagpipilian ay dapat makagawa ng zero na kahilingan mula sa browser ng bisita sa anumang domain ng vendor at zero na hindi-mahahalagang cookie — pareho na mas madaling kumpirmahin sa Zaraz kaysa sa isang client-side na stack dahil ang kawalan ng mga third-party na kahilingan ay ang default kaysa sa isang naka-configure na exception. Ang isang reject na bisita ay dapat panatilihin ang estadong iyon. Ang isang accept na bisita ay dapat makagawa ng mga POST ng Zaraz endpoint na nagdadala lamang ng mga event na pinayagan ng user, at ang mga Worker log ay dapat ipakita ang pag-fire ng downstream tool. Ang isang pag-atras ay dapat agad na itigil ang karagdagang mga pagpapatupad ng Worker tool, mag-expire ng anumang cookie na itinakda ng Zaraz, at mag-trigger ng naaangkop na mga signal ng pagtanggal o pag-opt-out sa mga naka-configure na downstream vendor.

Kung saan pa nangangailangan ng maingat na pangangasiwa ang Zaraz

Ang Zaraz ay hindi isang solusyon sa pahintulot-sa-arkitektura na nag-aalis ng pangangailangang mag-isip. Tatlong lugar ang nangangailangan ng sadyang pangangasiwa. Ang mga click-to-load embed — YouTube, Twitter, Instagram, TikTok video — ay nangangailangan pa rin ng parehong pattern ng placeholder na ginagamit ng anumang consent-first na deployment, dahil ang Zaraz ay kasalukuyang hindi nag-proxy ng mga naka-embed na video iframe. Ang mga client-side identifier na pinili ng publisher na itakda sa browser para sa mga first-party na layunin — isang naka-log in na user ID, isang session token, isang A/B test bucket — ay nananatili sa gilid ng publisher ng hangganan ng pahintulot at nangangailangan ng sariling gating logic. At ang privacy notice ay dapat tumpak na ilarawan ang server-side na modelo ng paglilipat, kasama ang papel ng Cloudflare bilang isang processor at ang heograpikong lokasyon ng mga Worker na humahawak ng data, dahil ang Cloudflare edge ay tumatakbo sa maraming rehiyon at ang trapiko ng bisita ay maaaring maproseso sa isang rehiyon na hindi sila. Sa mga iyon na nahawakan, ang isang Zaraz deployment sa 2026 ay nagbabago mula sa isang produkto ng pamamahala ng tag patungo sa isa sa mga pinakamalinis na arkitektura ng pahintulot na maaaring patakbuhin ng isang publisher: mas maliit na ibabaw ng cookie, mas kaunting mga third-party na kahilingan, sentralisadong pagpapatupad, at isang audit trail na talagang mababasa ng isang regulator.