Honnan tudod, hogy a Consent Mode tényleg működik? Ellenőrzési módszer

Scheo · 2026-09-16 · Frissítve: 2026-10-04 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A hozzájárulási mód (Consent Mode) bevezetése technikailag egy délutános munka: bekerül egy alapértelmezett állapot, a bannerhez hozzákötöd a frissítést, és a felület látszólag rendben viselkedik. A gond az, hogy ez a látszat semmit nem bizonyít. A banner attól még megjelenhet és eltűnhet, hogy közben a mérőkódok egyetlen jelzést sem kapnak a döntésről, vagy rosszat kapnak. A bevezetés fél munka, a bizonyíték a másik fele, és ez a rész szokott kimaradni.

Ebben a cikkben végigmegyünk azon, hogyan igazolod saját szemmel, hogy a hozzájárulási jelek helyesen mennek ki. Ahol tudom, jelölöm, mi hivatalos információ, mi saját tapasztalat, és mi szakmai feltételezés.

Miért nem elég az, hogy a banner megjelenik?

Rövid válasz: a banner és a mérés két külön rendszer, és attól, hogy az egyik működik, a másik még bármit csinálhat. A banner feladata összegyűjteni a döntést, a hozzájárulási mód feladata ezt a döntést továbbadni a Google mérőkódjainak. A kettő között egy hívás van, és ha az a hívás nem fut le, a felhasználó élménye teljesen szabályosnak tűnik, miközben a jelzés nem megy ki.

Hivatalosan igazolt: a Google dokumentációja szerint a hozzájárulási mód hét állapotot kezel, ebből négy érinti közvetlenül a hirdetési és mérési működést: ad_storage, analytics_storage, ad_user_data és ad_personalization. Ezek mellett létezik functionality_storage, personalization_storage és security_storage. Minden állapot értéke granted vagy denied.

Saját tapasztalat: a hibás beállítások többsége nem abból fakad, hogy valaki rosszul írta meg a kódot, hanem abból, hogy két megoldás van egyszerre az oldalon. Egy régi süti-plugin és egy új CMP, vagy egy sablonba égetett mérőkód a fejlécben és egy külön kezelt konténer. Ilyenkor az egyik felülírja a másikat, és csak a hálózati kérés mutatja meg, melyik nyert.

Mit nézz meg a böngésző konzoljában elfogadás előtt?

Az ellenőrzést mindig friss, inkognitó ablakban kezdd, mert a korábbi látogatásaidból megmaradt döntés eltakarja a valódi alapállapotot. Nyisd meg a fejlesztői eszközöket (Chrome-ban F12 vagy jobb gomb, majd Vizsgálat), és még a bannerre kattintás előtt nézd meg ezt a hármat.

• Sütik. Az Application (Alkalmazás) fülön a Cookies alatt a saját domainednél elfogadás előtt nem lehet ott a _ga, a _ga_ kezdetű mérési süti és a _gcl_au. Ha ott vannak, a tárolás megtörtént a döntés előtt.
• A dataLayer tartalma. A Console fülön futtasd le: Array.from(dataLayer).filter(x => x[0] === 'consent'). Legalább egy elemet látnod kell, aminek a második tagja default, és a harmadik tagja egy objektum a fenti állapotokkal. Ha ez üres, nincs alapértelmezett állapot.
• A tényleges belső állapot. A google_tag_data.ics.entries objektum kulcsonként megmutatja az egyes állapotokat, és azt is, hogy jött-e rájuk frissítés. A google_tag_data.ics.getConsentState('ad_storage') hívás 1 értéket ad, ha engedélyezett, és 2 értéket, ha tiltott.

Szakmai feltételezés: az utóbbi objektum a Google mérőkódjának belső szerkezete, nem dokumentált nyilvános felület. A gyakorlatban évek óta stabil, de nem érdemes automatizált monitorozást építeni rá, mert bármikor megváltozhat. Kézi ellenőrzésre viszont gyors és őszinte.

Hogyan olvasod ki a hálózati kérésekből a hozzájárulási jelet?

Rövid válasz: a mérési kérés URL-jében keresd a gcs paramétert, mert ez egyetlen karakterláncban elárulja, milyen állapottal ment ki az adott találat.

A Network (Hálózat) fülön szűrj a collect kifejezésre. A GA4 találatai a google-analytics.com/g/collect vagy a saját szervermegoldásod végpontjára mennek, a Google Ads konverziók pedig a googleads.g.doubleclick.net/pagead/ útvonalra. Kattints rá egy kérésre, és a Headers vagy a Payload fülön nézd meg a lekérdezési paramétereket.

Hivatalosan igazolt: a gcs érték felépítése egy G1 előtagból és két jelzőszámból áll, ahol az első a ad_storage, a második az analytics_storage állapota.

• G100: mindkettő tiltott, ez a helyes érték elfogadás előtt.
• G111: mindkettő engedélyezett, ez a helyes érték teljes elfogadás után.
• G101: hirdetési tárolás tiltott, mérési engedélyezett, tipikusan akkor, ha a látogató csak a statisztikát fogadta el.
• G110: fordított eset, hirdetési engedélyezett, mérési tiltott.
• Ha a paraméter teljesen hiányzik, az általában azt jelenti, hogy az oldalon nincs élő hozzájárulási mód.

Az EGT területén további paraméterek is megjelennek: a dma=1 jelzi, hogy a kérés a digitális piacokról szóló szabályozás hatálya alá tartozó módon megy ki, a npa=1 pedig azt, hogy a hirdetési jelzés nem személyre szabott. Van egy gcd nevű, hosszabb paraméter is, ami az alapértelmezett és a frissített állapotokat együtt kódolja mind a négy hirdetési és mérési típusra.

Szakmai feltételezés: a gcd pontos betűkódjait a Google nem dokumentálja nyilvánosan, a szakmában keringő megfejtések visszafejtésen alapulnak. Ellenőrzésre ezért a gcs a megbízható kapaszkodó, a gcd pedig másodlagos jel: ha változik az elfogadás hatására, az jó hír, de az egyes karakterekre ne építs érvelést az ügyfél felé.

Mire jó a Tag Assistant, és mire nem?

Rövid válasz: a Tag Assistant azt mutatja meg, hogy az egyes tagek milyen hozzájárulási állapot mellett tüzeltek vagy maradtak blokkolva, de nem bizonyítja, hogy a CMP a valódi felhasználói döntést fordítja-e le helyesen.

Indítsd el a Google Tag Manager előnézeti módját, vagy nyisd meg közvetlenül a Tag Assistant felületét, és csatlakozz az oldaladhoz. A bal oldali sávban végigfut az események sora: Consent Initialization, Container Loaded, DOM Ready, Window Loaded, majd a saját eseményeid. Válassz ki egy eseményt, és felül kapcsolj át a Consent fülre.

• Az On-page Consent State blokk két oszlopot mutat: mi volt az alapértelmezett, és mi lett a frissítés után. Elfogadás előtt a frissítés oszlop üres vagy azonos az alapértelmezettel.
• Tagenként látszik, hogy a hozzájárulás beállított-e (Consent Configured), és hogy az ellenőrzés sikeres volt-e (Consent Checks Passed). Ha egy tag fut, miközben az általa igényelt állapot tiltott, ott konfigurációs hiba van.
• A sorrend is látszik. A Consent Initialization eseménynek minden más előtt kell lefutnia.

Saját tapasztalat: a Tag Assistant a saját gépedről, a saját IP-címeddel dolgozik, ezért a régiófüggő beállítást csak korlátozottan mutatja meg. Amit ott látsz, az a te régiódra igaz, nem a világ többi részére.

Milyen értékeket kell látnod a banner előtt és után?

Az ellenőrzés lényege a különbség. Ha a két állapot között nincs eltérés, valami elromlott, akármit is mutat a felület.

Elfogadás előtt: a mérési kérésekben gcs=G100, a saját domainen nincs _ga és _gcl_au süti, a ad_user_data és az ad_personalization értéke tiltott, EGT-ből érkező látogatónál a dma=1 és a npa=1 megjelenik. Az, hogy egyáltalán kimegy kérés, önmagában nem hiba: az alapmodellben a mérőkód azonosító nélküli, süti nélküli jelzést küld.

Teljes elfogadás után: a következő találatban gcs=G111, létrejön a _ga süti, és a hirdetési kérésekben megjelennek a kattintásazonosítók, ha van ilyen a beérkező forgalomban.

Saját tapasztalat: sokan ott akadnak el, hogy az elfogadás után nem lát új kérést a hálózati fülön, és azt hiszik, nem működik. A GA4 nem küld automatikusan új oldalmegtekintést csak azért, mert megváltozott a hozzájárulás. Kattints át egy másik oldalra, vagy váltsd ki valamelyik eseményedet, és azt a találatot nézd meg. Ha az is G100 értékkel megy ki, akkor viszont tényleg elmaradt a frissítés.

Melyek a leggyakoribb hibák, és miről ismered fel őket?

Hiányzik az alapértelmezett állapot

Ilyenkor a gcs paraméter egyáltalán nem jelenik meg a kérésekben, a konzolban a consent, default bejegyzés nem található, a Tag Assistant Consent fülén pedig üres az alapértelmezett oszlop. A következmény kettős: egyrészt a tárolás a döntés előtt megtörténhet, másrészt a modellezett konverziók sem tudnak beindulni, mert a rendszer nem kapott értelmezhető jelet a kiindulási állapotról.

A banner utáni frissítés elmarad

A tünet jellegzetes: az elfogadás előtti és utáni kérés is G100 értékű, és az ics.entries objektumban az állapotoknál nincs frissítés. A leggyakoribb ok, hogy a CMP csak a saját sütijét írja meg, és a hozzájárulási mód hívását nem futtatja le, mert nem kapcsolták be a megfelelő integrációt. Egy másik gyakori változat, hogy a frissítés lefut, de egy másik szkript utána visszaállítja az alapértelmezettet.

Van tag, ami a bannernél korábban tüzel

Ez akkor látszik, ha a hálózati fülön már a banner megjelenése előtt kimegy egy kérés süti beállítással, vagy ha az Application fülön ott a _ga anélkül, hogy bármire kattintottál volna. Tipikus forrás a sablonba vagy pluginbe égetett mérőkód, ami a CMP betöltése előtt fut, illetve az olyan konténer, amiben a hozzájárulási inicializálás nem a legelső esemény.

A régiónkénti beállítás nem fedi le a valós forgalmat

A hozzájárulási mód alapértelmezése régiónként eltérhet, például szigorúbb az EGT-ben és megengedőbb azon kívül. Két hiba fordul elő rendszeresen. Az egyik, hogy csak régiós alapértelmezés létezik, globális nincs, így a listán kívülről érkező látogatónál nem definiált az állapot. A másik, hogy a régiólista hiányos: csak néhány országkód szerepel benne, miközben a forgalom máshonnan is jön.

Saját tapasztalat: a régiós beállítást a legőszintébben úgy nézed meg, ha a konzolban kiolvasod a teljes alapértelmezett konfigurációt, és összeveted a Google Analytics országonkénti forgalmi jelentésével. Ha a legnagyobb forgalmat hozó országok közül bármelyik hiányzik a listáról, és nincs globális alapértelmezés, ott hiány van. A VPN-es tesztelés is működhet, de lassabb és megbízhatatlanabb.

A döntés nem éli túl az oldalváltást

Egyoldalas alkalmazásoknál és néhány gyorsítótárazó megoldásnál előfordul, hogy az elfogadás az adott oldalbetöltésre működik, de a következő oldalon újra alapértelmezett állapotból indul minden. A tünet: a második oldalon megint G100 értéket látsz, pedig már elfogadtál. Ilyenkor a CMP nem olvassa vissza a korábbi döntést, vagy visszaolvassa, de a mérőkód betöltése után teszi.

Milyen 8 pontos ellenőrzőlistát futtass le minden oldalindítás után?

Ezt a kört érdemes minden éles indítás, sablonfrissítés vagy nagyobb plugintelepítés után végigvinni. Nagyjából negyed óra, és a legtöbb csendes hibát kiszűri.

1. Friss munkamenet. Inkognitó ablak, törölt sütik, fejlesztői eszközök nyitva már az első kérés előtt.
2. Alapértelmezett állapot megléte. A konzolban megjelenik a consent és default bejegyzés, mind a négy hirdetési és mérési állapottal.
3. Sorrend. A hozzájárulási inicializálás minden más mérőkód előtt fut le, és a banner előtt nem keletkezik mérési vagy hirdetési süti.
4. Kiindulási jel. Az elfogadás előtti találatokban gcs=G100, EGT-s látogatónál dma=1.
5. Frissítés elfogadás után. A következő találatban gcs=G111, és létrejönnek a várt sütik.
6. Részleges elfogadás. Ha a banner külön kezeli a statisztikát és a hirdetést, teszteld a köztes esetet is, és nézd meg, hogy G101 vagy G110 érték jön-e ki.
7. Elutasítás és visszavonás. Utasítsd el a hozzájárulást, majd egy másik körben előbb fogadd el, aztán vond vissza. Mindkét esetben a következő találatnak vissza kell állnia a tiltott állapotra, és a korábbi sütiknek törlődniük kell.
8. Oldalváltás és régió. Navigálj tovább legalább két aloldalra, és ellenőrizd, hogy a döntés megmarad. Vesd össze a régiós beállítást a tényleges forgalmi megoszlással, és győződj meg róla, hogy van globális alapértelmezés is.

Ha mind a nyolc pont tiszta, akkor van bizonyítékod arra, hogy a jelzések úgy mennek ki, ahogy kell. Ez nem garancia arra, hogy a konverziómodellezés minden esetben pontos számot ad, és nem helyettesíti a jogi átvilágítást sem: azt, hogy a te bannered szövege és működése megfelel-e az adatvédelmi elvárásoknak, adatvédelmi szakember tudja megítélni. Amit ez a kör ad, az a technikai bizonyosság, és ez jó eséllyel megelőzi azt a fajta hibát, ami hónapokig észrevétlen marad, aztán a hirdetési adatok hiányában jelentkezik.

Egy utolsó gyakorlati megjegyzés. Érdemes az ellenőrzés eredményét képernyőképpel együtt eltenni, dátummal. Amikor fél év múlva valaki átír egy sablont, és a mérés megbicsaklik, a régi kép alapján perceken belül látszik, mi változott. A dokumentált kiindulópont nélkül ugyanez fél napos nyomozás.

Mit ad vissza a google_tag_data.ics.getConsentState hívás, és hogyan olvasd az eredményt?

Rövid válasz: a google_tag_data.ics.getConsentState('ad_storage') egy számot ad vissza, ami azt mutatja, milyen hozzájárulási állapottal dolgozik éppen a Google címke az adott típusra. Az 1 engedélyezett, a 2 tiltott, a 0 pedig azt jelzi, hogy erre a típusra nincs beállított érték.

Szakmai feltételezés: a számok jelentését a Google nem dokumentálja, a mérőkód viselkedésének megfigyeléséből ismerjük. A 0 értéket a gyakorlatban akkor látod, ha az adott típusra se alapértelmezés, se frissítés nem érkezett, vagy elgépelted a típus nevét. A hívás nem ad hibát rossz névre, egyszerűen 0-t ad vissza, ezért egy elírt kulcs könnyen hamis riasztást okoz.

Egyesével hívogatni lassú, ezért egyetlen sorral kérd le mind a négy hirdetési és mérési típust, és táblázatban kapod vissza az eredményt.

console.table(Object.fromEntries(['ad_storage','analytics_storage','ad_user_data','ad_personalization'].map(k => [k, google_tag_data.ics.getConsentState(k)])))

Az eredményt így értelmezd.

1. Banner előtt. EGT-re szabott beállításnál mind a négy sorban 2 a helyes érték. Ha bármelyik 1, akkor vagy engedélyező az alapértelmezés, vagy egy korábbi döntés maradt meg a böngészőben. Ezért fontos az inkognitó ablak.
2. Teljes elfogadás után. Futtasd le újra ugyanazt a sort. Mind a négy típusnak 1-re kell váltania, oldalújratöltés nélkül is.
3. Részleges elfogadás után. Ha csak a statisztikát engedted, az analytics_storage legyen 1, a három hirdetési típus maradjon 2. Ha a statisztika elfogadására a hirdetési típusok is átváltanak, a CMP rosszul képezi le a kategóriákat.
4. Bármelyik sorban 0. Hiányzik a típus az alapértelmezésből. A leggyakrabban az ad_user_data és az ad_personalization marad ki a 2024 előtt beállított, a hozzájárulási mód második verziójára nem frissített oldalakon.

Az ics.entries objektum ennél részletesebb képet ad, mert típusonként külön mutatja az alapértelmezett és a frissített értéket. Ebből derül ki, hogy egy 1-es érték a látogató döntéséből jött, vagy már az alapértelmezés is engedélyező volt. A getConsentState mindkét esetben ugyanazt a számot adja, adatvédelmi szempontból viszont a kettő egészen más helyzet. Szakmai feltételezés: a mezők neve verziónként eltérhet, ezért nyisd ki az objektumot a konzolban, és a ténylegesen látott szerkezetből indulj ki.

Saját tapasztalat: a konzolos kiolvasás és a gcs paraméter együtt ad teljes képet. A getConsentState azt mondja meg, mit tud a címke az adott pillanatban, a gcs pedig azt, milyen állapottal ment ki egy konkrét kérés. Ha a konzol már 1-et mutat, de a legutóbbi kérés még G100, az többnyire csak időzítés, mert a kérés a frissítés előtt indult. Ilyenkor a következő találatot nézd meg, ne a korábbit.

Miért undefined a google_tag_data, vagy miért kapsz hibát a getConsentState hívásra?

Rövid válasz: a google_tag_data objektumot a Google címke (a gtag.js vagy a Tag Manager konténer) hozza létre betöltéskor, így ha a konzol szerint nem létezik, akkor az ellenőrzés pillanatában nem fut Google címke az oldalon.

Ez nem mindig hiba. Ha az oldal a hozzájárulási mód alapváltozatát használja, a Google címkék a döntésig egyáltalán nem töltődnek be, ezért elfogadás előtt a google_tag_data hiánya várt viselkedés. Hivatalosan igazolt: a Google dokumentációja megkülönbözteti az alapváltozatot, ahol a címke a döntés előtt nem tölt be, és a haladó változatot, ahol betölt, és süti nélküli jelzéseket küld. Ha elfogadás után sem jelenik meg az objektum, ott már valódi probléma van.

A leggyakoribb okok, amelyeket sorban érdemes kizárni.

• Túl korán futtattad. A konzol már akkor elérhető, amikor a címke még tölt. Várd meg a teljes betöltést, és futtasd újra a hívást.
• Rossz keretben vagy. A Console fül felső legördülő menüjében a top keretnek kell kiválasztva lennie. Ha egy beágyazott keretre váltottál, ott nincs Google címke.
• A CMP a teljes címkét blokkolja. Ez az alapváltozat, vagy egy olyan beállítás, ahol a banner a szkript betöltését is visszatartja. Elfogadás után nézd meg újra.
• Nem Google kliensoldali kód méri az oldalt. Más címkekezelőnél vagy tisztán szerveroldali mérésnél a böngészőben nem jön létre ez az objektum.
• Létezik az objektum, de a hívás hibát ad. Ha is not a function típusú hibaüzenetet kapsz, a belső szerkezet eltér attól, amire a hívás épít. Ilyenkor a dataLayer consent bejegyzéseire és a gcs paraméterre támaszkodj.

Saját tapasztalat: ha bizonytalan vagy, fut-e egyáltalán Google címke, a typeof gtag és a google_tag_manager objektum kulcsai gyorsan eligazítanak. Utóbbiban a betöltött konténerek és címkék azonosítói látszanak, így az is kiderül, ha két konténer vagy egy elfelejtett, sablonba égetett címke fut párhuzamosan.

Források és további olvasnivalók

• Google Tag Manager Súgó: Hozzájárulási mód (Consent mode) beállítása
• Google Tag Platform fejlesztői dokumentáció: Consent mode API és alapértelmezett állapotok
• Google Analytics 4 Súgó: Hozzájárulási mód és konverziómodellezés
• Google Ads Súgó: Hozzájárulási mód az EGT területén
• Google Tag Assistant dokumentáció
• Chrome DevTools dokumentáció: Network és Application panel
• IAB Europe: Transparency and Consent Framework specifikáció
• Európai Adatvédelmi Testület (EDPB) iránymutatásai a hozzájárulásról
• Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói a sütikezelésről