A süti-sáv és a mérés vagy együtt működik, vagy sehogy. Ha a hozzájárulás-kezelő szépen felugrik, de a mérőkód már előtte elindult, akkor jogi oldalon sem állsz jól, mérési oldalon pedig rosszabbul jársz, mintha semmit nem raktál volna ki: a látogató elutasítja a sütiket, a Google mégis kap adatot, a Google Ads viszont nem kap semmilyen hozzájárulási jelzést, amivel dolgozni tudna. Ez a cikk azt szedi szét, mit csinál a Consent Mode v2 a gyakorlatban egy WordPress-oldalon, milyen sorrendben kell összerakni, és hogyan ellenőrzöd, hogy tényleg célba ér a jelzés.
Mit csinál pontosan a Consent Mode v2 egy WordPress-oldalon?
Rövid válasz: a Consent Mode v2 nem kapcsolja ki és nem kapcsolja be a mérést, hanem egy állapotjelzést továbbít a Google-címkéknek arról, hogy a látogató mihez járult hozzá, és a címkék ehhez az állapothoz igazítják a viselkedésüket.
Hivatalosan igazolt. A v2 négy jelzést használ. Az ad_storage arról szól, tárolhat-e a böngészőben hirdetési célú azonosítót (jellemzően sütit). Az analytics_storage ugyanez analitikai célra, ez dönti el, létrejöhet-e a GA4 _ga sütije. Az ad_user_data arra vonatkozik, továbbíthatunk-e felhasználóhoz köthető adatot a Google-nek hirdetési céllal. Az ad_personalization pedig azt szabályozza, felhasználható-e az adat személyre szabott hirdetéshez, tehát remarketinghez. Az utolsó kettő a v2 újdonsága, ezek 2024 márciusa óta kellenek ahhoz, hogy az EGT-területről érkező forgalomból a Google Ads személyre szabott hirdetési funkciói (remarketinglisták, Customer Match) egyáltalán töltődjenek.
Emellett létezik három további, régebbi paraméter is: functionality_storage, personalization_storage és security_storage. Ezeket a legtöbb magyar KKV-oldalon a süti-kezelő automatikusan kezeli, külön foglalkozni velük ritkán kell.
Fontos, hogy ez nem váltja ki a süti-kezelőt. A Consent Mode egy protokoll a süti-kezelő és a Google-címkék között. A hozzájárulás beszedése, tárolása és visszavonhatósága továbbra is a süti-kezelő dolga.
Mi a különbség az alapszintű és a haladó mód között?
Rövid válasz: alapszintű módban a Google-címke el sem indul, amíg nincs hozzájárulás; haladó módban elindul, de hozzájárulás hiányában süti és azonosító nélküli, névtelen jelzést küld.
Hivatalosan igazolt. Az alapszintű (basic) beállításnál a címkét maga a süti-kezelő blokkolja, tehát a Google szervere felé egyetlen kérés sem indul, amíg a látogató nem kattint az elfogadásra. Ilyenkor az elutasító látogatókról nulla információ marad. A haladó (advanced) módban a címke minden esetben betöltődik, és ha az állapot denied, akkor sütimentes, azonosító nélküli jelzést küld, amiből a Google modellezni tud.
Szakmai feltételezés, a hivatalos leírásból következtetve. Az adatvesztés különbsége a gyakorlatban itt látszik meg. Alapszintű módban az elutasító sáv teljes egészében eltűnik a riportokból, tehát ha a látogatók fele nem fogad el semmit, a GA4-ben nagyjából feleannyi munkamenetet fogsz látni. Haladó módban a Google konverziómodellezéssel próbálja pótolni a hiányzó részt. A modellezés viszont küszöbökhöz kötött: kell hozzá elegendő forgalom és elegendő konverzió, és a Google nem közöl garantált pontosságot. Egy heti pár konverziót hozó helyi vállalkozásnál jó eséllyel nem indul be, egy nagyobb webshopnál viszont érdemben javíthatja a képet.
Saját tapasztalat. Kis és közepes magyar oldalaknál a haladó mód általában jobb választás, mert az elutasított látogatókról is marad legalább aggregált nyom, és a Google Ads jelentéseiben megjelenik a hozzájárulási állapot. Az alapszintű mód akkor indokolt, ha a jogi tanácsadó ragaszkodik hozzá, hogy hozzájárulás előtt semmilyen kérés ne induljon harmadik fél felé.
Mi történik akkor, ha nincs Consent Mode v2 az oldalon?
Rövid válasz: az EGT-területről érkező forgalom nagy része kiesik a hirdetési funkciókból, és a mérés is torzul, de a hiány sokáig nem feltűnő, mert a felület nem dob hibaüzenetet.
Hivatalosan igazolt. Consent Mode v2 nélkül az EGT-s látogatókból nem épülnek a remarketinglisták, a Customer Match-feltöltések korlátozottan használhatók, és a konverziómodellezés sem indul el. A Google Ads felületén ez rendszerint figyelmeztetésként jelenik meg a hirdetéskezelőben.
Saját tapasztalat. A leggyakoribb tünet nem a figyelmeztetés, hanem az, hogy egy jól futó remarketingkampány közönsége lassan elfogy, a hirdetés megjelenései visszaesnek, és senki nem érti, miért. A másik tipikus jel, hogy a GA4-ben a forgalom egy nap alatt beesik, mert valaki felrakott egy süti-kezelőt, ami blokkolja a mérőkódot, viszont hozzájárulási jelzést nem küld. Ilyenkor a helyzet nem az, hogy "nem működik a mérés", hanem az, hogy a mérés pontosan azt csinálja, amit mondtak neki, csak hiányzik a második fele.
Milyen süti-kezelőt válassz magyar KKV-oldalra?
Rövid válasz: olyat, amelyik a Google által tanúsított CMP-k listáján szerepel, és amelyik kifejezetten támogatja a Consent Mode v2 négy jelzését, lehetőleg Google Tag Manager-sablonnal együtt.
Hivatalosan igazolt. A Google fenntart egy listát a tanúsított hozzájárulás-kezelő platformokról. WordPress-környezetben a bevett, hivatalosan is Consent Mode v2-t támogató megoldások közé tartozik a Complianz, a Cookiebot, a CookieYes, a Real Cookie Banner és a Borlabs Cookie. Ezek mindegyike tudja a négy jelzést, a különbség inkább a beállítás kényelmében és a GTM-integráció mélységében van.
Amit érdemes végignézni választás előtt:
- Küldi-e a bővítmény a
gtag('consent', 'default', ...)parancsot, vagy csak blokkol? - Van-e hozzá hivatalos GTM-sablon, vagy neked kell egyedi HTML-címkével megoldani?
- Kezeli-e a hozzájárulás visszavonását, tehát van-e visszahívható beállítás-panel?
- Naplózza-e a hozzájárulásokat, van-e időbélyeges bizonyíték?
- Támogatja-e a magyar nyelvet a sávon és a részletes beállításokban?
- Kezeli-e a nem Google-mérőkódokat is (Meta pixel, Hotjar, chat-widget)?
Szakmai feltételezés. Az IAB TCF-keretrendszer bekapcsolása a legtöbb magyar KKV-nál felesleges bonyolítás. Az akkor lesz igazán indokolt, ha programmatic hirdetési ökoszisztémában is szerepelsz, nem pedig akkor, ha Google Ads és Meta hirdetéseket futtatsz a saját szolgáltatásodra.
Milyen sorrendben állítsd be a Consent Mode v2-t?
Rövid válasz: előbb leltár, aztán süti-kezelő, aztán a default consent parancs a legelső helyre, csak ezután a Google Tag Manager beállításai, és legvégül az ellenőrzés.
- Leltározd a mérőkódokat. Írd össze, mi fut az oldalon: GA4, Google Ads konverzió, Meta pixel, Hotjar, chat, hőtérkép. Nézd meg azt is, hol vannak beillesztve: témabeállításban, bővítményben, GTM-ben, vagy a functions.php-ben. Egy magyar KKV-oldalon nem ritka, hogy ugyanaz a GA4-azonosító két helyről is betöltődik.
- Telepítsd a süti-kezelőt, és állítsd be a kategóriákat. A négy Google-jelzést hozzá kell rendelni a saját kategóriáidhoz: a statisztikai kategóriához az
analytics_storage, a marketing kategóriához azad_storage, azad_user_dataés azad_personalization. - Tedd a default consent parancsot a legelső helyre. Ennek a HTML
headszakaszának az elején, minden más script előtt kell lefutnia. A legtöbb bővítmény ezt magától elvégzi, de érdemes ellenőrizni a forráskódban. Kézi beállításnál így néz ki:
window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('consent', 'default', { ad_storage: 'denied', analytics_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', wait_for_update: 500 });
A wait_for_update azt mondja meg, hány ezredmásodpercet várjon a címke a hozzájárulási válaszra, mielőtt a default állapottal dolgozna. Ha a süti-kezelő lassabban tölt be, ez az érték túl alacsony lehet.
- Kapcsold be a hozzájárulás-kezelést a GTM-ben. A tárolóbeállításokban engedélyezd a hozzájárulási felületet, majd minden Google-címkénél add meg a szükséges hozzájárulási típusokat. A süti-kezelő sablonját a Consent Initialization eseményre kösd, ne az All Pages triggerre, mert az később fut.
- Nézd át a Google-oldali beállításokat. A GA4 adminfelületén a Google-jelekhez és a hirdetés-személyre szabáshoz kapcsolódó kapcsolók, a Google Ads oldalán pedig a fiók és a GA4 összekapcsolása, valamint a bővített konverziók állapota tartozik ide.
- Ellenőrizd, mielőtt bárminek örülnél. Erről szól a következő két szakasz.
Hogyan ellenőrzöd Tag Assistanttel, hogy a jelzés célba ért?
Rövid válasz: a Tag Assistant Consent fülén meg kell jelennie az oldalon beállított alapállapotnak, és a kattintás után az állapotváltásnak, címkénként.
A menete: nyisd meg a Tag Assistantet, csatlakozz az oldalhoz, és nézd meg a bal oldali eseménysort. A legelső esemény környékén kell megjelennie a hozzájárulási alapállapotnak. A Consent fülön három állapotot láthatsz: On-page default, On-page update és Not configured. Ha a Google-címkéidnél a hozzájárulás "not configured", akkor a jelzés nem érkezett meg, hiába van kint a sáv.
Utána kattints el a sávon az elutasítást, és nézd meg, marad-e denied minden érintett jelzés. Aztán frissíts, és fogadj el mindent: minden jelzésnek granted értékre kell váltania. Végül kattints rá egy konkrét címkére (például a GA4 konfigurációra), és a részleteknél nézd meg, milyen hozzájárulási állapottal futott le.
Saját tapasztalat. Ha a Tag Assistantben minden rendben van, de a valós forgalomban nem, akkor érdemes a beépülő modulok nélküli, inkognitó ablakos tesztet is elvégezni, és megnézni a böngésző Hálózat fülét. A Tag Assistant ugyanis bizonyos esetekben módosítja a betöltési sorrendet, és emiatt szebb képet mutat a valóságosnál.
Miről ismered fel, hogy a hozzájárulás-kezelő a mérőkód UTÁN fut?
Rövid válasz: ha a mérési kérés vagy a süti már azelőtt megjelenik, hogy hozzáértél volna a sávhoz, akkor a sorrend rossz, függetlenül attól, mit ír a bővítmény beállítási oldala.
Ellenőrzőlista, végigmehetsz rajta tíz perc alatt:
- Nyiss inkognitó ablakot, indítsd el a fejlesztői eszközök Hálózat fülét, és szűrj a
collectszóra. Ha a sáv megjelenése előtt már fut kérés a Google felé, a sorrend rossz. - Utasíts el mindent, majd nézd meg az Alkalmazás fülön a sütiket. Ha ott van a
_ga, akkor az analytics_storage jelzés nem ért célba. - Írd be a konzolba, hogy
dataLayer, és nézd meg az első elemeket. A legelső bejegyzések között kell lennie a consent default parancsnak. Ha csak a gtm.js van ott, a süti-kezelő túl későn indul. - Nézd meg az oldal forrását (jobb klikk, forrás megtekintése). A süti-kezelő scriptjének a
headelején kell lennie, a GTM-kód és a GA4-kód előtt. - Ellenőrizd a cache-bővítményt. A JS-fájlok egyesítése, késleltetése és a "delay JavaScript until interaction" típusú kapcsolók rendszeresen a süti-kezelő scriptjét is hátrébb tolják.
- Nézd meg, van-e
defervagyasyncattribútum a süti-kezelő scriptjén. Neki blokkolóan kell betöltődnie. - Keress duplikált mérőkódot. Ha a GA4 a GTM-ben is és a témabeállításban is szerepel, a témából jövő példány jó eséllyel hozzájárulás nélkül fut.
- Nézd meg a Google Ads figyelmeztetéseit a konverziós műveleteknél, és a GA4 adatgyűjtés-diagnosztikát.
Miért van kint a süti-sáv, ha a jelzés mégsem ér célba?
Rövid válasz, saját nézőpont: a legtöbb hibás beállítás mögött nem hiányzó eszköz áll, hanem rossz sorrend, és a sorrendet WordPress-en általában nem a süti-kezelő rontja el, hanem a köré épült többi bővítmény.
Saját tapasztalat. A tipikus felállás: a süti-kezelő bővítmény jól van beállítva, a Consent Mode v2 kapcsoló be van kapcsolva, a GTM is rendben van. Aztán valaki bekapcsol egy sebességoptimalizáló bővítményt, ami minden JavaScriptet késleltet az első felhasználói interakcióig. Ettől a süti-kezelő is késleltetve indul, a témába kézzel beillesztett GA4-kód viszont nem. Az eredmény: a mérés hozzájárulás nélkül fut, a jelzés pedig soha nem ér célba. A sáv ott van, a látogató kattint, jogilag mégis védtelen az oldal, mérési oldalon meg mindkét világ hátrányát megkapod.
A másik gyakori eset a féloldalas beállítás. A GA4 szépen kezelve van a GTM-ben, a Meta pixel viszont közvetlenül a témában ül, és senkire nem figyel. Ilyenkor a Google-oldal rendben van, az adatkezelés összképe nem.
Ezért érdemes minden nagyobb WordPress-változtatás után (téma frissítés, cache-bővítmény csere, oldalépítő váltás) újra végigmenni a fenti ellenőrzőlistán. A beállítás nem egyszeri feladat, hanem karbantartandó állapot.
Mit tegyél, ha a bevezetés után beesik a GA4-forgalom?
Rövid válasz: a visszaesés egy része valós adatvesztés, és nem hiba, de mielőtt ezt elfogadod, zárd ki a technikai okot.
Először nézd meg, haladó módban vagy-e. Alapszintű módnál az elutasítók teljes egészében eltűnnek, tehát egy nagyobb esés várható. Haladó módnál a Google-jelentésekben látnod kell modellezett adatot is, feltéve, hogy elérted a küszöböket. Ha semmilyen jelzés nem érkezik, akkor nem az elfogadási arány a baj, hanem a beállítás.
Szakmai feltételezés. Ha az adat valóban kevesebb, akkor a jelentések értelmezésén is állítani kell: az abszolút számok helyett a trendek és az arányok maradnak megbízhatók, a napi bontású összehasonlítás a bevezetés előtti időszakkal pedig félrevezet. Érdemes a bevezetés dátumát megjegyezni a mérési dokumentációban, hogy fél év múlva se magyarázza félre senki a grafikont.
És ami nem árt: a hozzájárulás elfogadási aránya maga is befolyásolható. Egy érthető, magyarul megírt, nem tolakodó sáv, amin a beállítás valóban használható, jellemzően jobb elfogadási arányt hoz, mint egy zavaros, gyárilag hagyott angol felirat. Ez nem garantál javulást, de a kevés olcsó beavatkozás egyike.
Források és további olvasnivalók
- Google Ads Help: Consent Mode és a hozzájárulási beállítások dokumentációja
- Google Tag Manager Help: Consent overview és Consent Initialization trigger
- Google Developers: Tag Platform, Consent Mode API (gtag.js és GTM)
- Google Analytics Help: adatgyűjtés-diagnosztika és konverziómodellezés
- Google Tag Assistant dokumentáció
- Google tanúsított hozzájárulás-kezelő platformok (CMP) listája
- Európai Parlament és Tanács (EU) 2016/679 rendelete (GDPR)
- Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói a sütikről
- Az érintett WordPress süti-kezelő bővítmények hivatalos dokumentációi (Complianz, Cookiebot, CookieYes, Real Cookie Banner, Borlabs Cookie)
- A Consent Mode v2 négy jelzést használ: ad_storage, analytics_storage, ad_user_data és ad_personalization.
- Az alapszintű módnál a címke el sem indul hozzájárulás nélkül, a haladó módnál elindul, de süti nélküli jelzést küld.
- A default consent parancsnak minden mérőkód előtt, a HTML legelején kell lefutnia, különben az egész beállítás látszatmegoldás.
- A Tag Assistant Consent fülén ellenőrizhető, hogy a címke lát-e hozzájárulási állapotot, vagy csak "not configured" jelenik meg.
- WordPress-en a cache- és JS-optimalizáló bővítmények gyakran késleltetik a süti-kezelő scriptjét, és ezzel elrontják a sorrendet.
Gyakori kérdések
Kötelező a Consent Mode v2 minden magyar weboldalon?
Jogszabály önmagában nem írja elő a Consent Mode használatát, a hozzájárulás beszerzését viszont igen. A Consent Mode v2 a Google saját követelménye ahhoz, hogy az EGT-területről érkező forgalomra a személyre szabott hirdetési funkciók (remarketing, Customer Match) továbbra is működjenek. Ha nem hirdetsz a Google-ben és nem használsz Google-mérést, akkor nincs rá szükséged, a süti-kezelőre viszont akkor is.
Elég, ha felteszek egy süti-kezelő bővítményt WordPress-re?
Nem feltétlenül. A bővítmény telepítése után ellenőrizni kell, hogy ténylegesen küldi-e a négy hozzájárulási jelzést, és hogy a scriptje a mérőkódok előtt fut-e. A leggyakoribb hiba, hogy a beállítási oldalon minden zöld, de egy cache- vagy sebességoptimalizáló bővítmény hátrébb tolja a süti-kezelő betöltését, így a jelzés nem ér célba.
Alapszintű vagy haladó módot érdemes választani?
A haladó mód általában több használható adatot hagy, mert hozzájárulás hiányában is küld süti nélküli jelzést, amiből a Google modellezni tud. A modellezés viszont mennyiségi küszöbökhöz kötött, és nem garantál pontos számot. Az alapszintű mód akkor indokolt, ha a jogi tanácsadó ragaszkodik hozzá, hogy hozzájárulás előtt semmilyen kérés ne induljon harmadik fél felé.
Hogyan látom biztosan, hogy jó a sorrend?
Nyiss inkognitó ablakot, indítsd el a fejlesztői eszközök Hálózat fülét, és nézd meg, indul-e mérési kérés a süti-sáv megjelenése előtt. Utána utasíts el mindent, és ellenőrizd, létrejön-e a _ga süti. Ha bármelyik igen, a sorrend rossz. A Tag Assistant Consent fülén emellett címkénként is látszik, hogy megérkezett-e a hozzájárulási állapot.
Miért esett vissza a GA4-forgalmam a bevezetés után?
Egy részben ez várható és valós: azok a látogatók, akik elutasítják a mérést, kikerülnek a hagyományos adatgyűjtésből. Mielőtt viszont elfogadod, zárd ki a technikai okot, mert ugyanezt a tünetet okozza az is, ha a süti-kezelő blokkolja a mérőkódot, de hozzájárulási jelzést nem küld. A bevezetés dátumát érdemes feljegyezni, hogy a későbbi összehasonlítás ne legyen félrevezető.
A Meta pixelre és más nem Google-eszközökre is vonatkozik ez?
A Consent Mode maga Google-specifikus protokoll, de a hozzájárulási kötelezettség minden nyomkövető eszközre vonatkozik. A gyakorlatban ezért a süti-kezelőnek a Meta pixelt, a hőtérkép-eszközöket és a chat-widgetet is kezelnie kell, jellemzően blokkolással. Ezt külön kell ellenőrizni, mert a Google-oldali beállítás rendben lehet úgy is, hogy a többi eszköz szabadon fut.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.