Cloudflare Zaraz sutikimo integracijos vadovas: serverio pusės žymų valdymas prie krašto 2026 metams
Cloudflare Zaraz skiriasi nuo daugelio anksčiau pasirodžiusių žymų valdymo produktų. Prielaida yra struktūrinė, o ne laipsniška: vietoj to, kad būtų įkelta Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight ir visų kitų tiekėjų JavaScript į lankytojo naršyklę, Zaraz vykdo šias integracijas Cloudflare Workers viduje, veikiančių prie krašto, prieš leidėjo kilmę. Naršyklė mato vieną mažą Zaraz vykdymo aplinką; tiekėjų įrankiai veikia serverio pusėje. Šis architektūrinis sprendimas turi kaupiamuosius padarinius sutikimui. Slapukų paviršius dramatiškai mažėja, nes daugelis tiekėjų slapukų apskritai niekada nesustatomi. Pirštų atspaudų paviršius mažėja, nes daugelis tiekėjų JavaScript niekada nevykdoma naršyklės kontekste. O sutikimo vykdymo taškas pereina iš JavaScript reklamjuostės, kuri kontroliuoja <script> žymų krūvą, į serverio pusės sprendimą, kuris nustato, kurios Zaraz integracijos bus paleistos ir kokį naudingąjį krovinį jos gaus. Leidėjas, tinkamai sujungęs Zaraz su CMP, gauna mažesnį atitikties paviršių, greitesnius puslapius ir aiškesnį audito pėdsaką. Leidėjas, kuris traktuoja Zaraz kaip greitesnį Google Tag Manager ir praleidžia sutikimo sujungimą, susiduria su reguliavimo poveikiu, kurį sunkiau pastebėti, nes didelė dalis veiklos yra nematoma standartinėms naršyklės pagrindu veikiančioms audito procedūroms.
Ką Zaraz iš tikrųjų daro prie krašto
Zaraz yra serverio pusės žymų tvarkyklė, vykdoma Cloudflare Workers viduje. Kai lankytojas įkelia puslapį, leidėjo HTML apima nedidelį Zaraz inicijavimo scenarijų — paprastai kelis kilobaitus — kuris renka struktūrizuotą įvykių naudingąjį krovinį iš naršyklės (puslapio peržiūra, paspaudimas, pasirinktinis įvykis) ir POST metodu siunčia jį į Cloudflare galutinį tašką leidėjo paties domene. Worker gauna tą naudingąjį krovinį ir paleidžia sukonfigūruotus Zaraz įrankius: Google Analytics 4 integracija siunčia Measurement Protocol smūgį, Meta Pixel integracija siunčia Conversions API įvykį, Mixpanel integracija siunčia HTTP API iškvietimą. Tiekėjo trečiųjų šalių JavaScript niekada neįkeliama naršyklėje, tiekėjų slapukai arba iš viso nesustatomi, arba rašomi per Cloudflare pirmosios šalies domeną per Worker, o tiekėjas gauna tik tuos duomenis, kuriuos leidėjo Zaraz konfigūracija aiškiai persiunčia.
Tai architektūrinis vertės pasiūlymas. Tai taip pat paaiškina, kodėl sutikimo vaizdas skiriasi nuo bet kurios klientinės žymų tvarkyklės. Naudojant tradicinę sąranką, sutikimo klausimas yra tai, ar tiekėjo JavaScript įkeliama, ar ne. Naudojant Zaraz, JavaScript neįkeliama jokiu atveju — klausimas tampa, ar serverio pusės naudingasis krovinys siunčiamas ar slopinamas, ir ar naudingajame krovinyje yra identifikatoriai, kurių tiekėjui reikia vartotojui stebėti. Į abu klausimus Zaraz Consent API turi gerai apibrėžtus atsakymus; leidėjo užduotis yra juos teisingai susieti.
Zaraz Consent API ir kaip ji skiriasi nuo klientinių CMP
Zaraz pateikiamas su integruotu sutikimo moduliu — Zaraz Consent Tools — kuris palaiko kiekvieno lankytojo sutikimo būseną ir kontroliuoja, kurie sukonfigūruoti įrankiai paleidžiami. Būsena atskleidžiama per nedidelę JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) vartotojo pasirinkimui įrašyti, zaraz.consent.get('analytics') ją perskaityti, zaraz.consent.getAll() visam žemėlapiui, zaraz.consent.modal() sutikimo vartotojo sąsajai atidaryti, ir įvykių klausytojai zaraz.consent.onModalShown bei susijusiuose įvykiuose pasirinktiniam vartotojo sąsajos elgesiui. Kiekvienas Zaraz įrankis prietaisų skydelyje konfigūruojamas su vienu ar daugiau tikslo ID, ir Worker vykdo įrankį tik tada, kai atitinkami tikslai suteikti lankytojo sutikimo būsenoje.
Integracijos pasirinkimas yra tai, ar naudoti Zaraz integruotą sutikimo modalą, ar susieti Zaraz su išoriniu CMP. Integruotas modalas yra paprasčiausias kelias: įjungti Consent Tools, apibrėžti tikslus, sukonfigūruoti kiekvieną įrankį su tinkamu tikslu ir diegti. Išorinio CMP kelias yra tinkamas pasirinkimas organizacijoms, kurios jau standartizuojasi su Cookiebot, OneTrust, Usercentrics ar pasirinktiniu CMP — Zaraz tada veikia žemiau CMP, o CMP iškviečia zaraz.consent.set() kai vartotojas pereina per reklamjuostę. Abu keliai veda į tą patį vykdymo tašką: Worker tikrina sutikimo būseną prieš kiekvieną įrankio vykdymą, o įrankiai, kurių tikslai nesuteikti, tiesiog nepaleidžiami.
IAB TCF palaikymas ir regioniniai režimai
Zaraz 2023 metais pridėjo IAB TCF v2 palaikymą ir nuo to laiko seka sistemos raidą. Leidėjams, veikiantiems EEA ir UK pagal TCF grindžiamas reklamos partnerystes, integracija automatiškai verčia TCF sutikimo eilutę į Zaraz tikslo būseną, kai leidėjas pasirenka dalyvauti. Ne TCF regionams leidėjas tiesiogiai susieja pasirinktus tikslus — paprastai analytics, marketing, personalization, functional — su atitinkamais Zaraz įrankiais. Tas pats Worker vykdo abu, o tai reiškia, kad viena Zaraz konfigūracija gali aptarnauti tiek EEA lankytoją per TCF, tiek Kalifornijos lankytoją per pasirinktinę rinkodaros tikslo jungtį be dviejų lygiagrečių vamzdynų.
Kodėl Zaraz keičia GDPR ir ePrivacy vaizdą
Teisinė padėtis pagal GDPR, ePrivacy ir CCPA nėra atleidžiama dėl serverio pusės vykdymo — teisinis pagrindas seka duomenis, o ne transportavimą — tačiau praktinis atitikties paviršius keičiasi. Trys poslinkiai svarbūs.
- Slapukų paviršius mažėja. Daugelis tiekėjų slapukų niekada nerašomi, nes tiekėjo JavaScript niekada nevykdoma naršyklėje. Likę slapukai paprastai yra Zaraz savasis seanso identifikatorius ir bet kokie pirmosios šalies identifikatoriai, kuriuos leidėjas sąmoningai išplatino. Nebūtinų slapukų paviršius, kurį turi kontroliuoti reklamjuostė, todėl yra dramatiškai mažesnis — kartais tik vienas ar du slapukai, palyginti su daugiau nei dešimčia, kuriuos gamina tipinė klientinė pakuotė.
- Atskleidimas apie perdavimą trečiosioms šalims keičiasi. Kadangi Worker siunčia duomenis tiekėjams per serveris-serveris iškvietimus, duomenų kelias iš lankytojo naršyklės eina į Cloudflare kraštą ir iš ten į sukonfigūruotus tiekėjus. Privatumo pranešimas turi tai atspindėti — Cloudflare yra tvarkytojas, o kiekvienas Zaraz įrankis yra žemutinio srauto gavėjas — tačiau atskleidimas daugeliu atžvilgių yra švaresnis nei lygiavertis klientinis kelias, nes leidėjas turi visišką kontrolę per tai, kas perduodama.
- Audito pėdsakas yra labiau centralizuotas. Kadangi kiekvienas tiekėjo įvykis pereina per Worker, leidėjas turi vieną tašką, kuriame galima registruoti sutikimo būseną, įvykio naudingąjį krovinį ir žemutinio srauto gavėją. Reguliuotojai, tikintys užklausomą sutikimo žurnalą, su Zaraz gauna aiškesnį atsakymą nei su klientinių žymų sklaida.
Integracijos modelis, kuris veikia
Etaloninis diegimas turi keturias judančias dalis. Pirmoji yra Zaraz inicijavimas puslapyje, įkeltas iš leidėjo domeno per Cloudflare tarpinį serverį. Antroji yra integruotas Consent Tools modalas arba išorinis CMP, kuris iškviečia zaraz.consent.set(), kai vartotojas daro pasirinkimus. Trečioji yra Zaraz prietaisų skydelio konfigūracija, kuri susieja kiekvieną įrankį su tinkamais tikslais — analizės įrankiai su analytics tikslu, reklamos įrankiai su marketing tikslu, seanso atkūrimo įrankiai su griežtesniu functional ar research tikslu, ir bet kuris nuo trečiosios šalies perdavimo priklausantis įrankis su cross-border-transfer tikslu, jei leidėjo privatumo pranešimas tai atskleidžia kaip atskirą pasirinkimą. Ketvirtoji yra serverio pusės žurnalas — Cloudflare Analytics, Logpush į leidėjo duomenų ežerą arba pasirinktinis Worker, rašantis sutikimo sprendimus į užklausomą saugyklą — kad sutikimo įrašas galėtų būti pateiktas reguliuotojo prašymu.
Patvirtinimo žingsnis yra ta pati keturių patikrinimų seka, taikoma bet kuriai sutikimo integracijai, tačiau su Zaraz būdingu aspektu. Švaraus naršyklės seanso su rodomu reklamjuoste, bet nepriimtu sprendimu, rezultatas turi būti nuliniai prašymai iš lankytojo naršyklės į bet kurį tiekėjo domeną ir nuliniai nebūtinų slapukų — abu lengviau patvirtinami su Zaraz nei su klientine pakuote, nes trečiųjų šalių prašymų nebuvimas yra numatytoji konfigūracija, o ne sukonfigūruota išimtis. Atmetimo apsilankymas turi išlaikyti tą būseną. Priėmimo apsilankymas turi gaminti Zaraz galutinio taško POST, nešančius tik tuos įvykius, su kuriais sutiko vartotojas, ir Worker žurnalai turi rodyti žemutinio srauto įrankio vykdymus. Atšaukimas turi nedelsiant sustabdyti tolesnius Worker įrankių vykdymus, baigti Zaraz nustatytų slapukų galiojimą ir suaktyvinti tinkamus trynimo ar atsisakymo signalus sukonfigūruotiems žemutinio srauto tiekėjams.
Kur Zaraz vis dar reikalauja atsargaus tvarkymo
Zaraz nėra architektūriniu sutikimu grindžiamas sprendimas, pašalinantis mąstymo poreikį. Tris sritis reikia sąmoningai tvarkyti. Spustelėjimo įkėlimo įterpimai — YouTube, Twitter, Instagram, TikTok vaizdo įrašai — vis dar reikalauja tos pačios vietos rezervavimo schemos, kurią naudoja bet kuris pirmiausia sutikimu pagrįstas diegimas, nes Zaraz šiuo metu nesuteikia tarpinio serverio funkcijų įterptoms vaizdo iframe. Klientiniai identifikatoriai, kuriuos leidėjas pasirenka nustatyti naršyklėje pirmosios šalies tikslais — prisijungusio vartotojo ID, seanso atpažinimo ženklas, A/B bandymo krepšys — lieka leidėjo pusėje sutikimo ribos ir reikalauja savo kontrolės logikos. Privatumo pranešimas turi tiksliai aprašyti serverio pusės perdavimo modelį, įskaitant Cloudflare vaidmenį kaip tvarkytojo ir duomenis tvarkančių Workers geografinę vietą, nes Cloudflare kraštas veikia keliuose regionuose ir lankytojo srautas gali būti apdorotas regione, kuris nėra jų pačių. Tai sutvarčius, 2026 metų Zaraz diegimas virsta iš žymų valdymo produkto į vieną švariausių sutikimo architektūrų, kurią gali naudoti leidėjas: mažesnis slapukų paviršius, mažiau trečiųjų šalių prašymų, centralizuotas vykdymas ir audito pėdsakas, kurį reguliuotojas tikrai gali perskaityti.