Mit csinál valójában a Zaraz az edge-en

A Zaraz egy szerveroldali tagkezelő, amely a Cloudflare Workers-ben fut. Amikor egy látogató betölt egy oldalt, a kiadó HTML-je tartalmaz egy kis Zaraz inicializáló scriptet — jellemzően néhány kilobájtot —, amely strukturált esemény-adatcsomagot gyűjt a böngészőből (oldalmegtekintés, kattintás, egyéni esemény), és POST-tal küldi el egy Cloudflare végpontra a kiadó saját domainjén. A Worker megkapja az adatcsomagot, és futtatja ellene a konfigurált Zaraz eszközöket: a Google Analytics 4-integráció Measurement Protocol-találatot küld, a Meta Pixel-integráció Conversions API eseményt küld, a Mixpanel-integráció HTTP API-hívást küld. A szállító harmadik féltől származó JavaScript-je soha nem töltődik be a böngészőbe, a szállítói cookie-k vagy egyáltalán nem kerülnek beállításra, vagy a Cloudflare első féltől származó domainjén keresztül íródnak a Worker segítségével, és a szállító csak azokat az adatokat kapja meg, amelyeket a kiadó Zaraz-konfigurációja kifejezetten továbbít.

Ez az architektúrális értékajánlat. Ez az oka annak is, hogy a hozzájárulási kép eltér bármely kliens oldali tagkezelőtől. Hagyományos beállítás esetén a hozzájárulási kérdés az, hogy a szállítói JavaScript betöltődik-e vagy sem. A Zaraz esetében a JavaScript egyáltalán nem töltődik be egyik esetben sem — a kérdés az lesz, hogy a szerver oldali adatcsomag elküldésre kerül-e vagy sem, és hogy az adatcsomag tartalmazza-e azokat az azonosítókat, amelyekre a szállítónak szüksége van a felhasználó nyomon követéséhez. Mindkét kérdésre jól meghatározott válaszok léteznek a Zaraz Consent API-ban; a kiadó feladata, hogy ezeket helyesen leképezze.

A Zaraz Consent API és miben különbözik a kliens oldali CMP-ktől

A Zaraz beépített hozzájárulási modullal — Zaraz Consent Tools — rendelkezik, amely fenntartja a látogatónkénti hozzájárulási állapotot, és kapuzza a konfigurált eszközök tüzelését. Az állapot egy kis JavaScript API-n keresztül érhető el: zaraz.consent.set({ analytics: true, marketing: false }) a felhasználó választásának rögzítéséhez, zaraz.consent.get('analytics') az olvasáshoz, zaraz.consent.getAll() a teljes térképért, zaraz.consent.modal() a hozzájárulási felhasználói felület megnyitásához, és az zaraz.consent.onModalShown és kapcsolódó eseményeken lévő eseményfigyelők az egyéni felhasználói felület viselkedéséhez. Minden Zaraz eszköz az irányítópulton egy vagy több cél-azonosítóval van konfigurálva, és a Worker csak akkor hajt végre egy eszközt, ha a releváns célok engedélyezve vannak a látogató hozzájárulási állapotában.

Az integrációs választás az, hogy a Zaraz beépített hozzájárulási modálját vagy egy külső CMP-hez való kötést alkalmazzunk-e. A beépített modál a legegyszerűbb út: engedélyezze a Consent Tools-t, határozza meg a célokat, konfigurálja az egyes eszközöket a megfelelő céllal, és szállítsa ki. A külső CMP-útvonal a helyes választás olyan szervezetek számára, amelyek már szabványosítottak a Cookiebot, az OneTrust, a Usercentrics vagy egy egyéni CMP alapján — a Zaraz ekkor a CMP mögé kerül, a CMP hívja a zaraz.consent.set() funkciót, ahogy a felhasználó végigmegy a szalaghirdetésen. Mindkét útvonal ugyanabba az érvényesítési pontba torkollik: a Worker minden egyes eszköz végrehajtása előtt ellenőrzi a hozzájárulási állapotot, és azok az eszközök, amelyek céljai nincsenek megadva, egyszerűen nem futnak.

IAB TCF-támogatás és a regionális rendszerek

A Zaraz 2023-ban adta hozzá az IAB TCF v2-támogatást, és azóta is követte a keretrendszer fejlődését. Az EEA-ban és az Egyesült Királyságban TCF-alapú hirdetési partnerségekkel működő kiadók számára az integráció automatikusan lefordítja a TCF hozzájárulási karakterláncot Zaraz-cél állapottá, amikor a kiadó beleegyezik. A nem TCF-régiók esetében a kiadó közvetlenül leképezi az egyéni célokat — jellemzően analytics, marketing, personalization, functional — a releváns Zaraz eszközökre. Ugyanaz a Worker mindkettőt érvényesíti, ami azt jelenti, hogy egyetlen Zaraz-konfiguráció képes kiszolgálni mind egy EEA-beli látogatót TCF-en keresztül, mind egy kaliforniai látogatót egy egyéni marketing-cél kapun keresztül, két párhuzamos folyamat nélkül.

Miért változtatja meg a Zaraz a GDPR és az ePrivacy képét

A GDPR, az ePrivacy és a CCPA szerinti jogi helyzet nem mentesül a szerver oldali végrehajtástól — a jogalap az adatokat követi, nem a szállítást — de a gyakorlati megfelelőségi felület megváltozik. Három változás számít.

• A cookie-felület csökken. A legtöbb szállítói cookie soha nem kerül kiírásra, mert a szállítói JavaScript soha nem fut a böngészőben. A maradék cookie-k jellemzően a Zaraz saját munkamenet-azonosítója és azok az első féltől származó azonosítók, amelyeket a kiadó szándékosan terjesztett. A szalaghirdetésnek ezért drámaian kisebb nem alapvető cookie-felületet kell kapuznia — néha csak egy-két cookie-t az egy tipikus kliens oldali verem által előállított tíz-egynéhányhoz képest.
• A harmadik félnek történő adattovábbítás közzétételének módja megváltozik. Mivel a Worker szerver-szerver hívásokon keresztül küldi az adatokat a szállítóknak, az adatút a látogató böngészőjétől a Cloudflare edge-éhez, onnan pedig a konfigurált szállítókhoz vezet. Az adatvédelmi nyilatkozatnak ezt tükröznie kell — a Cloudflare adatfeldolgozó, és minden Zaraz eszköz downstream befogadó —, de a közzététel sok tekintetben tisztább, mint az ezzel egyenértékű kliens oldali út, mert a kiadónak teljes kontrollja van afelett, hogy mi kerül továbbításra.
• Az auditnaplózás centralizáltabb. Mivel minden szállítói esemény átmegy a Workeren, a kiadónak egyetlen pontja van, ahol a hozzájárulási állapot, az esemény-adatcsomag és a downstream befogadó naplózható. A lekérdezehető hozzájárulási naplót elvárók részéről az illetékes hatóságok részéről világosabb választ kapnak a Zaraz-zal, mint egy kliens oldali tagek szétszórt rendszerével.

A működő integrációs minta

A referencia-telepítésnek négy mozgó eleme van. Az első a Zaraz inicializálása az oldalon, a kiadó domainjéről betöltve a Cloudflare proxyján keresztül. A második vagy a beépített Consent Tools modál, vagy egy külső CMP, amely hívja a zaraz.consent.set() funkciót, ahogy a felhasználó választást tesz. A harmadik a Zaraz irányítópult konfigurációja, amely minden eszközt leképez a megfelelő célokra — az analitikai eszközöket az analytics célra, a reklámeszközöket a marketing célra, a munkamenet-visszajátszó eszközöket egy szigorúbb functional vagy research célra, és minden határon átnyúló adatátviteltől függő eszközt a cross-border-transfer célra, ha a kiadó adatvédelmi nyilatkozata ezt külön választási lehetőségként tünteti fel. A negyedik egy szerveroldali napló — akár a Cloudflare Analytics, a Logpush a kiadó adatállómedencéjébe, vagy egy egyéni Worker, amely a hozzájárulási döntéseket egy lekérdezehető tárolóba írja —, hogy a hozzájárulási nyilvántartás hatósági kérésre előállítható legyen.

Az ellenőrzési lépés ugyanolyan négy ellenőrzésből álló sorozat, mint amely bármely hozzájárulási integrációra vonatkozik, de egy Zaraz-specifikus csavarral. Egy tiszta böngésző munkamenetben, amelyet a megjelenített szalaghirdetéssel, de egyetlen választás megtétele nélkül hajtanak végre, nulla kérésnek kell érkeznie a látogató böngészőjéből bármely szállítói domainre, és nulla nem alapvető cookie-nak kell létrejönnie — mindkettő könnyebben megerősíthető a Zaraz esetében, mint egy kliens oldali verem esetén, mert a harmadik féltől származó kérések hiánya az alapértelmezett, nem egy konfigurált kivétel. Egy elutasítási látogatásnak fenn kell tartania ezt az állapotot. Egy elfogadási látogatásnak elő kell állítania a Zaraz végpont POST-jait, amelyek csak azokat az eseményeket hordozzák, amelyekhez a felhasználó hozzájárult, és a Worker-naplóknak meg kell mutatniuk a downstream eszköz aktiválását. A visszavonásnak azonnal le kell állítania a további Worker-eszköz végrehajtásokat, le kell jártnia a Zaraz által beállított cookie-kat, és ki kell váltania a megfelelő törlési vagy leiratkozási jeleket a konfigurált downstream szállítók felé.

Ahol a Zaraz még gondos kezelést igényel

A Zaraz nem egy architektúrális hozzájárulás-alapú megoldás, amely eltávolítja a gondolkodás szükségességét. Három terület igényel tudatos kezelést. A kattintásra betöltődő beágyazások — YouTube, Twitter, Instagram, TikTok videó — még mindig ugyanazt a helyőrző-mintát igénylik, amelyet bármely hozzájárulást előtérbe helyező telepítés alkalmaz, mert a Zaraz jelenleg nem proxyzza a beágyazott videó iframe-eket. Az első féltől származó célokra a böngészőben beállítani kívánt kliens oldali azonosítók — egy bejelentkezett felhasználói azonosító, egy munkamenet-token, egy A/B teszt-gyűjtővödör — a kiadó oldalán maradnak a hozzájárulási határon, és saját kapuzási logikát igényelnek. Az adatvédelmi nyilatkozatnak pontosan le kell írnia a szerver oldali átviteli modellt, beleértve a Cloudflare adatfeldolgozói szerepét és az adatokat kezelő Workerek földrajzi helyzetét, mert a Cloudflare edge több régióban működik, és a látogató forgalmát egy olyan régióban lehet feldolgozni, amely nem az övé. Ha ezekkel foglalkozunk, a 2026-os Zaraz-telepítés egy tagkezelő termékből az egyik legtisztább hozzájárulási architektúrává válik, amelyet egy kiadó futtathat: kisebb cookie-felület, kevesebb harmadik féltől származó kérés, centralizált érvényesítés, és egy auditnaplózás, amelyet egy hatóság valóban el tud olvasni.