Ko Zaraz faktiski dara malā

Zaraz ir servera puses tagu pārvaldnieks, kas darbojas Cloudflare Workers vidē. Kad apmeklētājs ielādē lapu, izdevēja HTML ietver nelielu Zaraz inicializācijas skriptu — parasti dažus kilobaitus — kas apkopo strukturētu notikumu slodzi no pārlūkprogrammas (lapas skatījums, klikšķis, pielāgots notikums) un to POST metodē nosūta uz Cloudflare galapunktu izdevēja paša domēnā. Workers saņem šo slodzi un izpilda konfigurētos Zaraz rīkus pret to: Google Analytics 4 integrācija nosūta Measurement Protocol pieprasījumu, Meta Pixel integrācija nosūta Conversions API notikumu, Mixpanel integrācija nosūta HTTP API izsaukumu. Pārdevēja trešās puses JavaScript nekad netiek ielādēts pārlūkprogrammā, pārdevēja sīkdatnes vai nu vispār netiek iestatītas, vai arī tās tiek rakstītas caur Cloudflare pirmās puses domēnu, izmantojot Workers, un pārdevējs saņem tikai tos datus, ko izdevēja Zaraz konfigurācija skaidri pārsūta.

Tas ir arhitektūras vērtības piedāvājums. Tas arī izskaidro, kāpēc piekrišanas aina atšķiras no jebkura klienta puses tagu pārvaldnieka. Tradicionālā iestatījumā piekrišanas jautājums ir par to, vai pārdevēja JavaScript ielādējas vai ne. Ar Zaraz JavaScript nekad netiek ielādēts nevienā gadījumā — jautājums kļūst par to, vai servera puses slodze tiek nosūtīta vai apturēta, un vai slodze satur identifikatorus, ko pārdevējs nepieciešams, lai izsekotu lietotāju. Abiem jautājumiem ir labi definētas atbildes Zaraz Consent API; izdevēja uzdevums ir tos pareizi kartēt.

Zaraz Consent API un kā tas atšķiras no klienta puses CMP

Zaraz tiek piegādāts ar iebūvētu piekrišanas moduli — Zaraz Consent Tools — kas uztur katram apmeklētājam piekrišanas stāvokli un kontrolē, kuri konfigurētie rīki tiek aktivizēti. Stāvoklis ir pieejams caur nelielu JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }), lai reģistrētu lietotāja izvēli, zaraz.consent.get('analytics'), lai to nolasītu, zaraz.consent.getAll() pilnai kartei, zaraz.consent.modal(), lai atvērtu piekrišanas UI, un notikumu klausītājiem uz zaraz.consent.onModalShown un saistītajiem notikumiem pielāgotai UI uzvedībai. Katrs Zaraz rīks informācijas panelī ir konfigurēts ar vienu vai vairākiem mērķa ID, un Workers izpilda rīku tikai tad, kad attiecīgie mērķi ir piešķirti apmeklētāja piekrišanas stāvoklī.

Integrācijas izvēle ir tāda — vai izmantot Zaraz iebūvēto piekrišanas modālo logu, vai saistīt Zaraz ar ārēju CMP. Iebūvētais modālais logs ir vienkāršākais ceļš: iespējot Consent Tools, definēt mērķus, konfigurēt katru rīku ar pareizo mērķi un palaist. Ārējā CMP ceļš ir pareizā izvēle organizācijām, kas jau standartizē Cookiebot, OneTrust, Usercentrics vai pielāgotu CMP — Zaraz tad darbojas pakārtoti CMP, ar CMP izsaukumu zaraz.consent.set(), kad lietotājs pārvietojas cauri baneram. Abi ceļi beidzas vienā izpildes punktā: Workers pārbauda piekrišanas stāvokli pirms katra rīka izpildes, un rīki, kuru mērķi nav piešķirti, vienkārši netiek palaisti.

IAB TCF atbalsts un reģionālie režīmi

Zaraz pievienoja IAB TCF v2 atbalstu 2023. gadā un kopš tā laika ir sekojis ietvara attīstībai. Izdevējiem, kas darbojas EEA un UK, izmantojot TCF balstītas reklāmas partnerattiecības, integrācija automātiski pārvērš TCF piekrišanas virkni Zaraz mērķa stāvoklī, kad izdevējs ieslēdz šo opciju. Reģioniem, kas nav saistīti ar TCF, izdevējs tieši kartē pielāgotus mērķus — parasti analytics, marketing, personalization, functional — uz attiecīgajiem Zaraz rīkiem. Viens un tas pats Workers izpilda abus, kas nozīmē, ka viena Zaraz konfigurācija var apkalpot gan EEA apmeklētāju caur TCF, gan Kalifornijas apmeklētāju caur pielāgotu mārketinga mērķa vārteju bez divām paralēlām cauruļvadiem.

Kāpēc Zaraz maina GDPR un ePrivacy ainu

Juridiskā nostāja saskaņā ar GDPR, ePrivacy un CCPA nav atbrīvota ar servera puses izpildi — juridiskais pamats seko datiem, nevis transportam — bet praktiskā atbilstības virsma mainās. Trīs izmaiņas ir svarīgas.

• Sīkdatņu virsma samazinās. Lielākā daļa pārdevēja sīkdatņu nekad netiek rakstītas, jo pārdevēja JavaScript nekad nedarbojas pārlūkprogrammā. Atlikušās sīkdatnes parasti ir Zaraz paša sesijas identifikators un jebkuri pirmās puses identifikatori, ko izdevējs apzināti izplatījis. Nebūtisko sīkdatņu virsma, ko baneram jāaiztur, tādēļ ir dramatiski mazāka — dažreiz tikai viena vai divas sīkdatnes pret duci vai vairāk, ko parasti rada klienta puses steks.
• Trešās puses pārsūtīšanas atklāšana mainās. Tā kā Workers nosūta datus pārdevējiem, izmantojot servera-uz-serveri izsaukumus, datu ceļš no apmeklētāja pārlūkprogrammas ir uz Cloudflare malu un no turienes uz konfigurētajiem pārdevējiem. Privātuma paziņojumam tas jāatspoguļo — Cloudflare ir apstrādātājs un katrs Zaraz rīks ir pakārtots saņēmējs — bet atklāšana daudzos veidos ir tīrāka nekā ekvivalentais klienta puses ceļš, jo izdevējam ir pilnīga kontrole pār to, kas tiek pārsūtīts.
• Revīzijas pēda ir centralizētāka. Tā kā katrs pārdevēja notikums iziet caur Workers, izdevējam ir viens punkts, kurā var reģistrēt piekrišanas stāvokli, notikuma slodzi un pakārtoto saņēmēju. Regulatoriem, kas sagaida vaicājamu piekrišanas žurnālu, ar Zaraz ir skaidrāka atbilde nekā ar klienta puses tagu izkliedēšanu.

Integrācijas modelis, kas darbojas

Atsauces izvietošanai ir četras kustīgas daļas. Pirmā ir Zaraz inicializācija lapā, ielādēta no izdevēja domēna caur Cloudflare starpniekserveri. Otrā ir vai nu iebūvētais Consent Tools modālais logs, vai ārējs CMP, kas izsauc zaraz.consent.set(), kad lietotājs veic izvēles. Trešā ir Zaraz informācijas paneļa konfigurācija, kas kartē katru rīku uz pareizajiem mērķiem — analītikas rīkus uz analītikas mērķi, reklāmas rīkus uz mārketinga mērķi, sesiju atskaņošanas rīkus uz stingrāku funkcionālo vai pētījumu mērķi, un jebkuru no pārrobežu pārsūtīšanas atkarīgu rīku uz pārrobežu pārsūtīšanas mērķi, ja izdevēja privātuma paziņojums to atklāj kā atsevišķu izvēli. Ceturtā ir servera puses žurnāls — vai nu Cloudflare Analytics, Logpush uz izdevēja datu ezeru, vai pielāgots Workers, kas raksta piekrišanas lēmumus vaicājamā krātuvē — lai piekrišanas ierakstu varētu sniegt pēc regulatora pieprasījuma.

Validācijas solis ir tā pati četru pārbaužu secība, kas attiecas uz jebkuru piekrišanas integrāciju, bet ar Zaraz specifiku. Tīra pārlūkprogrammas sesija ar parādītu baneru, bet bez veiktas izvēles, vajadzētu radīt nulli pieprasījumu no apmeklētāja pārlūkprogrammas uz jebkuru pārdevēja domēnu un nulles nebūtiskās sīkdatnes — abus ir vieglāk apstiprināt ar Zaraz nekā ar klienta puses steku, jo trešās puses pieprasījumu neesamība ir noklusējums, nevis konfigurēts izņēmums. Noraidīšanas apmeklējumam jāsaglabā šis stāvoklis. Pieņemšanas apmeklējumam jārada Zaraz galapunkta POST pieprasījumi, kas satur tikai notikumus, kam lietotājs piekrita, un Workers žurnālos jābūt redzamam, kā pakārtotais rīks aktivizējas. Atsaukšanai nekavējoties jāaptur turpmākā Workers rīku izpilde, jāizdzēš Zaraz iestatītās sīkdatnes un jāaktivizē atbilstošie dzēšanas vai atteikšanās signāli konfigurētajiem pakārtotajiem pārdevējiem.

Kur Zaraz joprojām prasa rūpīgu apstrādi

Zaraz nav piekrišana pēc arhitektūras risinājums, kas novērš domāšanas nepieciešamību. Trīs jomas prasa apzinātu apstrādi. Klikšķa ielādes iegultie elementi — YouTube, Twitter, Instagram, TikTok video — joprojām ir nepieciešams tāds pats viettura modelis, ko izmanto jebkurā piekrišanas prioritātes izvietošanā, jo Zaraz pašlaik neaizstāj iegulto video iframes. Klienta puses identifikatori, ko izdevējs izvēlas iestatīt pārlūkprogrammā pirmās puses mērķiem — pieteikušā lietotāja ID, sesijas marķieris, A/B testa skurste — paliek izdevēja pusē piekrišanas robežas un vajadzīga sava norobežošanas loģika. Un privātuma paziņojumam precīzi jāapraksta servera puses pārsūtīšanas modelis, tostarp Cloudflare loma kā apstrādātājam un Workers, kas apstrādā datus, ģeogrāfiskā atrašanās vieta, jo Cloudflare mala darbojas vairākos reģionos un apmeklētāja trafiks var tikt apstrādāts reģionā, kas nav viņu pašu. Ar to visu apstrādātu, Zaraz izvietošana 2026. gadā pārvēršas no tagu pārvaldības produkta par vienu no tīrākajām piekrišanas arhitektūrām, ko izdevējs var palaist: mazāka sīkdatņu virsma, mazāk trešās puses pieprasījumu, centralizēta izpilde un revīzijas pēda, ko regulators var faktiski izlasīt.