Cloudflare Zaraz -suostumusintegraation opas: Palvelinpuolen tagienhallinta reunassa vuodelle 2026
Cloudflare Zaraz eroaa useimmista ennen sitä tulleista tagienhallinnan tuotteista. Lähtökohta on rakenteellinen eikä inkrementaalinen: sen sijaan että ladattaisiin Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight ja jokaisen muun toimittajan JavaScript vierailijan selaimeen, Zaraz suorittaa nämä integraatiot Cloudflare Workersissa reunassa, julkaisijan lähdepalvelimen edessä. Selain näkee yhden pienen Zaraz-suoritusympäristön; toimittajatyökalut toimivat palvelinpuolella. Tällä arkkitehtuurivalinnalla on kerrostuvia seurauksia suostumuksen kannalta. Evästepinta pienenee dramaattisesti, koska useimpia toimittajaevästeitä ei koskaan aseteta lainkaan. Sormenjälkiä ottava pinta pienenee, koska useimpia toimittajan JavaScript-koodeja ei koskaan suoriteta selainympäristössä. Ja suostumuksen täytäntöönpanopiste siirtyy JavaScript-bannerilta, joka portittaa joukon <script>-tageja, palvelinpuolen päätökseen, joka määrittää, mitkä Zaraz-integraatiot laukeavat ja minkä kuorman ne saavat. Julkaisija, joka kytkee Zarazin oikein CMP:hen, saa pienemmän vaatimustenmukaisuuspinnan, nopeammat sivut ja selkeämmän tilintarkistuspolun. Julkaisija, joka kohtelee Zarazia nopeampana Google Tag Managerina ja ohittaa suostumuksen kytkennän, altistuu sääntelyriskille, joka on vaikeampi havaita, koska suuri osa toiminnasta on näkymätöntä tavallisille selainpohjaisille tilintarkistuksille.
Mitä Zaraz todella tekee reunassa
Zaraz on palvelinpuolen tagihallinta, joka suoritetaan Cloudflare Workersissa. Kun vierailija lataa sivun, julkaisijan HTML sisältää pienen Zaraz-alustuskomentosarjan — yleensä muutamia kilotavuja — joka kerää jäsennetyn tapahtumakuorman selaimesta (sivunäkymä, napsautus, mukautettu tapahtuma) ja lähettää sen POST-viestillä Cloudflare-päätepisteeseen julkaisijan omalla verkkotunnuksella. Worker vastaanottaa tämän kuorman ja suorittaa konfiguroimansa Zaraz-työkalut sitä vasten: Google Analytics 4 -integraatio lähettää Measurement Protocol -osuman, Meta Pixel -integraatio lähettää Conversions API -tapahtuman, Mixpanel-integraatio lähettää HTTP API -kutsun. Toimittajan kolmannen osapuolen JavaScript ei koskaan lataudu selaimeen, toimittajan evästeitä joko ei aseteta lainkaan tai ne kirjoitetaan Cloudflare-verkkotunnuksen kautta Workerin avulla, ja toimittaja saa vain ne tiedot, jotka julkaisijan Zaraz-konfiguraatio nimenomaisesti välittää.
Tämä on arkkitehtuurinen arvolupaus. Siksi myös suostumuskuva eroaa mistään asiakaspuolen tagihallinnasta. Perinteisessä asetuksessa suostumuskysymys on, latautuuko toimittajan JavaScript vai ei. Zarazin kanssa JavaScript ei lataudu koskaan kummassakaan tapauksessa — kysymykseksi tulee, lähetetäänkö palvelinpuolen kuorma vai estetäänkö se, ja sisältääkö kuorma tunnisteet, joita toimittaja tarvitsee käyttäjän seuraamiseen. Molemmilla kysymyksillä on hyvin määritellyt vastaukset Zaraz Consent API:ssa; julkaisijan tehtävä on kartoittaa ne oikein.
Zaraz Consent API ja miten se eroaa asiakaspuolen CMP:istä
Zaraz toimitetaan sisäänrakennetulla suostumusalustalla — Zaraz Consent Tools — joka ylläpitää vierailijankohtaista suostumustilaa ja portittaa, mitkä konfiguroidut työkalut laukeavat. Tila on käytettävissä pienen JavaScript API:n kautta: zaraz.consent.set({ analytics: true, marketing: false }) käyttäjän valinnan tallentamiseen, zaraz.consent.get('analytics') sen lukemiseen, zaraz.consent.getAll() koko kartalle, zaraz.consent.modal() suostumusliittymän avaamiseen ja tapahtumakuuntelijat zaraz.consent.onModalShown:ssa ja siihen liittyvissä tapahtumissa mukautettua käyttöliittymäkäyttäytymistä varten. Jokainen Zaraz-työkalu kojelaudalla on konfiguroitu yhdellä tai useammalla tarkoitustunnuksella, ja Worker suorittaa työkalun vain, kun asiaankuuluvat tarkoitukset on myönnetty vierailijan suostumustilassa.
Integrointivaihtoehto on, käytetäänkö Zarazin sisäänrakennettua suostumusalaikkunaa vai sidotaanko Zaraz ulkoiseen CMP:hen. Sisäänrakennettu alaikkuna on yksinkertaisin tie: ota Consent Tools käyttöön, määritä tarkoitukset, konfiguroi jokainen työkalu oikealla tarkoituksella ja lähetä. Ulkoinen CMP-tie on oikea valinta organisaatioille, jotka jo standardoivat Cookiebotilla, OneTrustilla, Usercentrics-ratkaisulla tai mukautetulla CMP:llä — Zaraz toimii silloin CMP:n jälkeen, kun CMP kutsuu zaraz.consent.set():tä käyttäjän liikkuessa bannerin läpi. Molemmat tiet päätyvät samaan täytäntöönpanopisteeseen: Worker tarkistaa suostumustilan ennen jokaisen työkalun suorittamista, ja työkalut, joiden tarkoituksia ei ole myönnetty, yksinkertaisesti eivät suoriudu.
IAB TCF -tuki ja alueelliset järjestelmät
Zaraz lisäsi IAB TCF v2 -tuen vuonna 2023 ja on seurannut kehystä eteenpäin siitä lähtien. EEA:lla ja Isossa-Britanniassa TCF-pohjaisten mainoskumppanuuksien alaisille julkaisijoille integraatio kääntää TCF-suostumusaluksen automaattisesti Zaraz-tarkoitustilaksi, kun julkaisija valitsee sen. Muille kuin TCF-alueille julkaisija kartoittaa mukautetut tarkoitukset — yleensä analytics, marketing, personalization, functional — suoraan asiaankuuluville Zaraz-työkaluille. Sama Worker panee täytäntöön molemmat, mikä tarkoittaa, että yksi Zaraz-konfiguraatio voi palvella sekä EEA-vierailijaa TCF:n kautta että kalifornialaista vierailijaa mukautetun markkinointitarkoituksen portaalin kautta ilman kahta rinnakkaista putkistoa.
Miksi Zaraz muuttaa GDPR:n ja ePrivacyn kuvaa
Oikeudellinen asema GDPR:n, ePrivacyn ja CCPA:n alla ei ole vapautettu palvelinpuolen suorittamisesta — oikeudellinen perusta seuraa tietoja, ei kuljetusta — mutta käytännön vaatimustenmukaisuuspinta muuttuu. Kolme muutosta on tärkeää.
- Evästepinta pienenee. Useimpia toimittajaevästeitä ei koskaan kirjoiteta, koska toimittajan JavaScript ei koskaan suoriudu selaimessa. Jäljelle jäävät evästeet ovat tyypillisesti Zarazin oma istuntotunniste ja kaikki ensimmäisen osapuolen tunnisteet, joita julkaisija on tietoisesti levittänyt. Ei-välttämättömien evästeiden pinta, jota bannerin on portitettava, on siksi dramaattisesti pienempi — joskus vain yksi tai kaksi evästettä verrattuna tyypillisen asiakaspuolen pinon tuottamaan tusinaan tai enempään.
- Kolmannen osapuolen siirtoa koskeva ilmoitus muuttuu. Koska Worker lähettää tietoja toimittajille palvelinten välisillä kutsuilla, tietopolku vierailijan selaimesta kulkee Cloudflaren reunaan ja sieltä konfiguroituihin toimittajiin. Tietosuojailmoituksessa on tämä heijastettava — Cloudflare on käsittelijä ja jokainen Zaraz-työkalu on alavirran vastaanottaja — mutta ilmoitus on monessa mielessä puhtaampaa kuin vastaava asiakaspuolinen polku, koska julkaisijalla on täysi hallinta siitä, mitä välitetään.
- Tilintarkistuspolku on keskitetympi. Koska kaikki toimittajatapahtumat kulkevat Workerin kautta, julkaisijalla on yksi piste, jossa suostumustila, tapahtumakuorma ja alavirran vastaanottaja voidaan kirjata lokiin. Sääntelyviranomaisilla, jotka odottavat kyselykelpoista suostumustilauslogia, on selkeämpi vastaus Zarazin kanssa kuin asiakaspuolisten tagien leviämisellä.
Toimiva integrointimalli
Viiteympäristö koostuu neljästä liikkuvasta osasta. Ensimmäinen on Zaraz-alustus sivulla, ladattu julkaisijan verkkotunnukselta Cloudflare-välityspalvelimen kautta. Toinen on joko sisäänrakennettu Consent Tools -alaikkuna tai ulkoinen CMP, joka kutsuu zaraz.consent.set():tä käyttäjän tehdessä valintoja. Kolmas on Zaraz-kojelaudan konfiguraatio, joka kartoittaa jokaisen työkalun oikeisiin tarkoituksiin — analytiikkatyökalut analytiikkatarkoitukseen, mainostyökalut markkinointitarkoitukseen, istunnon toistamistyökalut tiukempaan toiminnalliseen tai tutkimustakoimukseen, ja kaikki kolmannen osapuolen siirtoriippuvaiset työkalut rajat ylittävän siirron tarkoitukseen, jos julkaisijan tietosuojailmoitus paljastaa sen erillisenä valintana. Neljäs on palvelinpuolen loki — joko Cloudflare Analytics, Logpush julkaisijan tietojärveen tai mukautettu Worker, joka kirjoittaa suostumuspäätökset kyselykelpoista tallennusta varten — jotta suostumustietue voidaan tuottaa sääntelyviranomaisen pyynnöstä.
Validointiaskel on sama neljän tarkistuksen sarja, joka koskee mitä tahansa suostumuksen integrointia, mutta Zaraz-kohtaisella lisäpiirteellä. Puhtaan selaimen istunnossa, jossa banneri näytetään mutta valintaa ei ole tehty, pitäisi olla nolla pyyntöä vierailijan selaimesta millekään toimittajatunnukselle ja nolla ei-välttämättömiä evästeitä — molemmat on helpompi vahvistaa Zarazin kanssa kuin asiakaspuolisen pinon kanssa, koska kolmansien osapuolten pyyntöjen puuttuminen on oletus, ei konfiguroitu poikkeus. Hylkäysvierailun pitäisi säilyttää tämä tila. Hyväksyntävierailun pitäisi tuottaa Zaraz-päätepisteessä POST-pyyntöjä, jotka sisältävät vain tapahtumat, joihin käyttäjä on antanut suostumuksensa, ja Worker-lokien pitäisi näyttää alavirran työkalun laukaisu. Peruuttamisen pitäisi välittömästi pysäyttää kaikki muut Workerin työkalusuoritukset, vanhentaa kaikki Zarazin asettamat evästeet ja laukaista asianmukaiset poistamis- tai kieltäytymissignaalit konfiguroituihin alavirran toimittajiin.
Missä Zaraz vaatii yhä huolellista käsittelyä
Zaraz ei ole arkkitehtuurin mukainen suostumusratkaisu, joka poistaa ajattelun tarpeen. Kolme aluetta vaatii tietoista käsittelyä. Klikkaa-ladataksesi-upotukset — YouTube, Twitter, Instagram, TikTok-video — tarvitsevat yhä samaa paikkamerkkimallia, jota mikä tahansa suostumus-ensin-käyttöönotto käyttää, koska Zaraz ei tällä hetkellä välitä upotettuja videoisyöttöjä. Asiakaspuolen tunnisteet, joita julkaisija valitsee asettaa selaimeen ensimmäisen osapuolen tarkoituksia varten — kirjautuneen käyttäjän tunniste, istuntopoletti, A/B-testikori — pysyvät julkaisijan puolella suostumuksen rajoissa ja tarvitsevat oman portointilogiikkansa. Ja tietosuojailmoituksen on tarkasti kuvattava palvelinpuolen siirtomalli, mukaan lukien Cloudflaren rooli käsittelijänä ja tietoja käsittelevien Workerien maantieteellinen sijainti, koska Cloudflare-reuna toimii useilla alueilla ja vierailijan liikennettä saatetaan käsitellä muulla kuin heidän omalla alueellaan. Kun nämä on hoidettu, Zaraz-käyttöönotto vuonna 2026 muuttuu tagienhallinnan tuotteesta yhdeksi puhtaimmista suostumuksen arkkitehtuureista, joita julkaisija voi käyttää: pienempi evästepinta, vähemmän kolmansien osapuolten pyyntöjä, keskitetty täytäntöönpano ja tilintarkistuspolku, jota sääntelyviranomainen voi todella lukea.