Mit csinál a „süti” valójában, és miért fontosak a consent‑jelek?

A „süti” (cookie) eredetileg egyszerű állapotmegőrző eszköz: kisméretű adatfájl, amely segít a webhelynek „emlékezni” a felhasználó egyes beállításaira vagy azonosítójára. A modern weben azonban a böngészőben tárolt adatok nem csak cookie-k lehetnek, hanem egyéb tárolók is (például localStorage), és a nyomkövetés nem kizárólag cookie-kkal történik. Emiatt a szabályozás, a technológia és a gyakorlat ma már elválaszthatatlanul összefonódik. A felhasználó hozzájárulása – azaz hogy engedélyezi‑e bizonyos tárolók használatát vagy adatai meghatározott célú továbbítását – nem esztétikai kérdés a bannerben, hanem mérési, hirdetési és kockázatkezelési döntéseink alapja. A Google Consent Mode v2 pontosan ezt a hidat képezi: a felhasználói döntést lefordítja a mérőkódok és hirdetési címkék nyelvére, úgynevezett consent‑jelek (jelzők) formájában. Ezek a jelek a következők: analytics_storage, ad_storage, ad_user_data, ad_personalization, personalization_storage, functionality_storage, security_storage. Mindegyik külön célterületet és külön jogi‑üzleti kockázati profilt takar. A cikk célja, hogy ezek jelentését praktikusan, jogilag védhető és üzletileg használható módon tisztázza, és megmutassa, mi történik, ha „denied” vagy „granted” állapotot adunk egy-egy jelzőnek – különös tekintettel a magyar piaci környezetre és a vállalkozások napi döntéseire.

GDPR és ePrivacy: a hozzájárulás helye a rendszerben

A sütik és más végberendezésen tárolt/olvasott adatok elsődlegesen az ePrivacy irányelv (és a tagállami végrehajtás) hatálya alá esnek: minden, ami nem feltétlenül szükséges a kért szolgáltatás nyújtásához, hozzájárulás-köteles. A GDPR itt kettős szerepben jelenik meg. Egyrészt meghatározza, mi minősül személyes adatnak és milyen jogalapok mellett kezelhetjük; másrészt előírja a hozzájárulás minőségét: önkéntes, egyértelmű, megfelelő tájékoztatáson alapuló, visszavonható legyen. A praxisban ez azt jelenti, hogy ami funkcionális, biztonsági működéshez kell (például bejelentkezés állapotának megőrzése, csalásmegelőzés), az jellemzően beállítható hozzájárulás nélkül is; ami analitika vagy hirdetés céljára szolgál, ott a „minden vagy semmi” megoldások helyett a pontos cél szerinti engedélykérés a jogilag tiszta és üzletileg értelmes út. Fontos különbség: a hozzájárulás a tárolás/olvasás aktusára vonatkozik (pl. reklám- és analitikai azonosítók), míg a GDPR‑os jogalap a további adatkezelésre. E kettő gyakran együtt jár, de nem felcserélhető. Ezért van jelentősége annak, hogy a Consent Mode v2 több, eltérő jelentésű jelzőt használ: egyesek a tárolást befolyásolják, mások a Google rendszereinek adatfelhasználását instruálják. A jó gyakorlat az, hogy a felhasználó előtt világossá tesszük, pontosan mihez kérünk hozzájárulást, és a technikai jelzőket ehhez igazítjuk, nem fordítva.

Consent Mode v2: mi változott, és miért számít?

A v1 két kulcsjelzője az ad_storage és az analytics_storage volt. A v2-ben ehhez jön két külön hirdetési utasítás: ad_user_data és ad_personalization. Az első azt közli a Google rendszereivel, hogy továbbítható‑e a hirdetésekhez kapcsolódó felhasználói adat (például a user_id vagy a felhasználó által megadott, hashelt adatok mérése), a második pedig a személyre szabott hirdetéseket engedélyezi vagy tiltja. E két jelző funkciója eltér az ad_storage-tól: míg az ad_storage közvetlenül a böngésző‑szintű tárolás/olvasás lehetőségét szabályozza (tehát hatására a címkék viselkedése is változik a webhelyen), az ad_user_data és ad_personalization inkább a feldolgozási oldalon, a Google rendszereiben érvényesíti a felhasználó döntését. Gyakorlati hatás: hiába granted az ad_storage, ha az ad_user_data denied, a fejlettebb mérési és hirdetési funkciók (például GA4‑>Google Ads konverziós export felhasználása ajánlattételben) korlátozottak lesznek. A Consent Mode két implementációs üzemmódot ismer: Basic (alap) és Advanced. Alap módban a címkék csak hozzájárulás után indulnak, míg fejlett módban a hozzájárulás megtagadása esetén is küldhetők „cookieless pingek” (azonosító nélküli mérési jelzések) bizonyos modellezési célokra. Magyar piacon – különösen KKV‑knál és erőforrás‑szűk környezetben – az alap üzemmód a biztonságos, jogilag komfortos kiindulópont; a fejlett mód alkalmazása tudatos kockázat‑ és etikai mérlegelést igényel.

A jelzők jelentése: denied vs. granted – mit csinál a rendszer?

Az alábbi táblázat tömören mutatja be a legfontosabb consent‑jelek célját és tipikus hatását. A részletes működés egyes termékekben (GA4, Google Ads, GTM) árnyaltabb, de a döntési logika így áttekinthető.

Mit jelent mindez a mérésben és a hirdetésben? (Basic vs. Advanced)

A Basic megközelítésben a címkék – így a GA4 és a Google Ads mérőkódok – csak akkor indulnak, ha a felhasználó engedélyt adott a vonatkozó jelző(k)re. Ez jogilag letisztult és kommunikációs szempontból is könnyen védhető, ugyanakkor csökken a mérési lefedettség (különösen mobilon és szigorúbb böngésző‑beállításoknál). Az Advanced megközelítésnél a rendszer a hozzájárulás hiányában is küldhet azonosító nélküli jelzéseket (cookieless pingeket) bizonyos alapvető modellezett mérési funkciókhoz. Ezzel javítható az összkép, de nem kerülhető meg a hozzájárulás: remarketing és személyre szabott hirdetés továbbra sem épülhet ad_personalization engedélye nélkül, és az ad_user_data tiltott állapota szintén korlátozza a fejlett ajánlattételi és konverzió‑összepárosítási forgatókönyveket. Stratégiai kérdés tehát, hogy mennyire támaszkodik a cég a modellezésre, és mit vállal jogi‑etikai kockázatban a cookieless jelzésekért cserébe. Magyar KKV‑k számára – különösen, ha nincs erős belső privacy kompetencia – reális kompromisszum a Basic indulás, és csak dokumentált döntéssel érdemes Advanced irányba lépni.

Implementáció GTM‑mel: milyen lépésekből áll a rendezett megoldás?

Az implementáció lényege, hogy nagyon korán (Consent Initialization) beállítjuk az alapállapotot, majd a felhasználói választás pillanatában frissítjük a jelzőket. A GTM‑ben a címkékhez hozzárendelhetők beépített és kiegészítő hozzájárulás‑ellenőrzések: például a GA4 eseménycímkék alapból figyelik az analytics_storage és ad_storage állapotát, míg a tűzési feltételeknél külön köthetjük egyes címkék működését ad_user_data és ad_personalization engedélyezettségéhez. Területi beállításokkal (regionális defaultok) elérhető, hogy az EGT‑ből érkező forgalom alapértelmezése szigorúbb legyen, más régióké eltérő. Az oldalon a hozzájárulási interakciót (elfogadás, elutasítás, részleges engedély) még az oldalváltás előtt rögzíteni kell, különben a frissítés nem mindig érvényesül a következő oldalbetöltéshez. Ajánlott haladó beállítás az úgynevezett click‑ID redakció (pl. gclid redakció) és a közönségépítés tiltása, ha a felhasználó nem engedélyezte a személyre szabást. A való életben a hibák jelentős része abból adódik, hogy a banner csak vizuálisan „működik”, de technikailag nem frissíti a consent‑állapotokat minden szükséges jelzőre. Ennek megelőzésére a Tag Assistant és a Consent Debugger rendszeres használata kötelező házi feladat.

Gyakorlati ellenőrzőlista (CMP‑től függetlenül)

• Adatleltár: azonosítsd minden címkéd és célodat (analitika, hirdetés, funkció, biztonság, személyre szabás). Ne csak a cookie‑kat, a localStorage‑ot is vizsgáld.
• Cél‑hozzájárulás illesztés: térképezd fel, mely célhoz mely jelző szükséges (ad_storage, analytics_storage, ad_user_data, ad_personalization, stb.).
• Alapállapotok: EGT‑forgalomra szigorú default (denied), más régiókra üzleti döntés szerint.
• Banner logika: egyértelmű opciók „Elfogadom / Elutasítom / Testreszabás”. Kerüld a félrevezető UI‑t.
• GTM beállítás: Consent Initialization, beleegyezés‑frissítés még az oldalváltás előtt; tag‑szintű consent‑ellenőrzések.
• Tesztelés: Tag Assistant, hálózati kérések (gcs/consent paraméterek), modellriportok összevetése.
• Dokumentáció: Privacy Policy frissítése célonként, megőrzési idők, partnerek, visszavonás módja.
• Jogos érdek vs. hozzájárulás: csak a valóban feltétlenül szükséges elemeket tartsd hozzájárulás nélkül.

Eszközhasználati minták különböző üzleti helyzetekben

E‑kereskedelmi B2C: tipikusan szükséges a teljes mérési lánc. Működő remarketinghez az ad_storage és ad_personalization „granted”, fejlett konverziókhoz az ad_user_data „granted” is kell. Ha az ügyfél elutasítja, a Basic üzemmód megállítja a címkéket; Advanced esetben is legfeljebb modellezett konverziókat kapunk, közönségépítés nélkül. B2B leadgenerálás: gyakran elegendő a pontos analitika (analytics_storage „granted”), míg a hirdetési személyre szabás kevésbé kritikus. Tartalomszolgáltató: a functionality_storage és personalization_storage biztosítja az olvasói élményt (pl. téma‑preferenciák), de analitikára egyértelmű hozzájárulást kérjünk. Bejelentkezős szolgáltatás: a security_storage és functionality_storage jellemzően hozzájárulás nélkül is indokolt, más célokhoz külön engedély szükséges. Minden esetben döntési pont, hogy mennyire támaszkodunk a modellezésre és megéri‑e ezért Advanced módot használni, vagy jogi‑ügyfélélmény szempontból a Basic a célszerűbb.

Tipikus tévhitek és elkerülendő hibák

„Az analitika feltétlenül szükséges.” Nem. Az üzlet szempontjából hasznos, de szabályozási értelemben nem mindig szükséges a szolgáltatás nyújtásához. „Ha nincs cookie, nincs adat.” Téves. A Consent Mode cookieless jelzéseket is használhat, de ez nem ad felmentést a hozzájárulás alól a személyre szabáshoz. „Elég egyetlen kapcsoló.” Nem. A célok eltérőek, és a v2 külön választja a tárolást (ad_storage, analytics_storage) és a hirdetési felhasználást (ad_user_data, ad_personalization). „A banner UI a lényeg.” A banner csak a belépő. A technikai jelzők frissítése, a tag‑szintű hozzájárulás‑ellenőrzés és a dokumentáció adja a megfelelést. „A CMP mindent megold.” A CMP integráció csak akkor jó, ha ténylegesen és hiánytalanul frissíti a szükséges jelzőket, és a GTM oldalon is ehhez vannak kötve a címkék. „A cookie‑fal és a rejtett kényszerítés rendben van.” Nem az. A hozzájárulásnak önkéntesnek kell lennie; etikailag és jogilag is visszaüt a kényszerítés. „A magyar piac megengedőbb.” A felügyeleti gyakorlat szigorodott; a transzparens, célonkénti hozzájárulás az ésszerű default.

Ajánlott alapbeállítás mintaként (EGT‑forgalomra)

Gyakorlati, ésszerű javaslat – Basic módban:

• Alapállapot EGT‑ben: analytics_storage = denied, ad_storage = denied, ad_user_data = denied, ad_personalization = denied, a funkcionális és biztonsági jelzők üzletileg indokolt minimumon.
• Elfogadás („Mindent elfogadok”): minden érintett jelző „granted”, a címkék elindulnak és teljes adat áll rendelkezésre.
• Részleges engedély: például csak analytics_storage „granted” – a GA4 rendben működik, de a remarketing letiltva marad, és a fejlett Ads‑használat az ad_user_data miatt blokkolt.
• Elutasítás: a címkék nem futnak fel; nincs tárolás és nincs személyre szabás; riportok hiányosabbak – ezt kommunikációban és mérési elvárásban előre tegyük világossá.

„Az adatvédelem nem a marketing ellen dolgozik. A tiszta, célszerű hozzájárulás jobb mérési fegyelmet és jobb ügyfélélményt eredményez. Ez hosszú távon több bevételt hoz, mint bármilyen rövid távú trükk.” — Dajka Gábor

Dajka Gábor marketingszakértő, business coach és befektető szerint

Ha a süti‑kérdést a helyén kezeljük, kiderül: ez nem „banner‑projekt”, hanem üzleti stratégiai döntés a bizalomról. Az a cég, amelyik célonként kér és tart be hozzájárulást, a mérésben fegyelmezettebb, a hirdetésben okosabb és a válságokban ellenállóbb lesz. Magyar piaci viszonyok között az alap Consent Mode megoldás bőven elég, ha világos cél‑hozzájárulás illesztéssel és technikai fegyelemmel párosul. Aki ebből versenyelőnyt akar, tegye rá a pontot az ad_user_data és ad_personalization tudatos kezelésére, és vállalja, hogy nem a kiskapukra, hanem a jobb adathigiéniára épít. A piac meghálálja.

Szakértő válaszol – GYIK

Mit jelent, ha az ad_personalization „denied”, de az ad_storage „granted”?

Az oldalon a hirdetési tárolás elvben működhet (konverzióméréshez), de személyre szabott hirdetés és remarketing nem épülhet. Gyakorlatban ez azt jelenti, hogy a konverziós riportjaid még használhatók, de közönségek, érdeklődés alapú ajánlattétel és dinamikus remarketing nem lesznek elérhetők.

Elég‑e a „cookieless” mérés, ha sok a megtagadás?

A cookieless jelzések modellezéshez hasznosak lehetnek, de nem pótolják a hozzájárulással támogatott, azonosító alapú mérést. KKV‑knál jellemzően a Basic mód + jól megtervezett hozzájárulás‑kérés adja a legjobb jogi‑üzleti kompromisszumot.

A functionality_storage és security_storage miért kezelhető eltérően?

Mert a szolgáltatás működése és biztonsága sokszor megköveteli a minimális tárolást. Ezek az elemek rendszerint a „feltétlenül szükséges” kategóriába esnek. De ami ezen túl megy (analitika, hirdetés, személyre szabás), ahhoz célonkénti hozzájárulás kell.

Mi a magyar piac realitása 2025‑ben?

A felügyeleti gyakorlat fókusza az átlátható és célonkénti hozzájárulás. A „mindent elfogad” gomb mellé elvárt a „mindent elutasít” és a „testreszabás” opció. A cookie‑falak, trükkös dizájnok és elrejtett visszavonás rossz irány – rövid távon sem hoznak valódi üzleti előnyt, hosszú távon pedig reputációs és hatósági kockázatot hordoznak.

Hogyan beszéljek erről az ügyfeleimmel/vezetőséggel?

Üzleti nyelven. Mutasd meg, milyen funkciók függnek az egyes jelzőktől, és hogy a hozzájárulás aránya hogyan fordul át pontosabb mérésbe, jobb ajánlattételbe és alacsonyabb beszerzési költségbe. A jogi megfelelés és a ROI itt nem egymás ellenfelei, hanem egymás feltételei.

Források

• Consent mode reference – Google Ads Help.
• Set up consent mode on websites – Google for Developers.
• NAIH: Cookie (süti) tájékoztató.

Ha tetszett a cikk, támogasd a blogomat és vedd meg a könyvem.