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 tagjadefault, é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.entriesobjektum kulcsonként megmutatja az egyes állapotokat, és azt is, hogy jött-e rájuk frissítés. Agoogle_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 Initializationesemé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.
- Friss munkamenet. Inkognitó ablak, törölt sütik, fejlesztői eszközök nyitva már az első kérés előtt.
- Alapértelmezett állapot megléte. A konzolban megjelenik a
consentésdefaultbejegyzés, mind a négy hirdetési és mérési állapottal. - 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.
- Kiindulási jel. Az elfogadás előtti találatokban
gcs=G100, EGT-s látogatónáldma=1. - Frissítés elfogadás után. A következő találatban
gcs=G111, és létrejönnek a várt sütik. - 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
G101vagyG110érték jön-e ki. - 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.
- 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.
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
- A bevezetés fél munka: a másik fele annak igazolása, hogy a jelek valóban kimennek, és a banner előtt más értéket mutatnak, mint utána.
- A leggyorsabb mérőszám a mérési kérés gcs paramétere: G100 elfogadás előtt, G111 teljes elfogadás után.
- A négy leggyakoribb hiba: hiányzó alapértelmezett állapot, elmaradó update a banner után, a bannernél korábban tüzelő tag, és a régiónként eltérő alapértelmezés.
- A Tag Assistant megmutatja a tagek hozzájárulási állapotát, de nem bizonyítja, hogy a CMP a valós felhasználói döntést fordítja-e le helyesen.
- Minden oldalindítás után érdemes ugyanazt a 8 pontos kört lefuttatni, mert egy sablonfrissítés vagy egy új plugin csendben elronthatja a beállítást.
Gyakori kérdések
Elfogadás előtt is mehet ki mérési kérés? Nem hiba ez?
Nem feltétlenül. A hozzájárulási mód alapmodelljében a Google mérőkódja a döntés előtt is küld egy azonosító és süti nélküli jelzést, amiben a gcs paraméter értéke G100. Hiba akkor van, ha ilyenkor létrejön a _ga vagy a _gcl_au süti, vagy ha a gcs paraméter engedélyezett állapotot mutat.
Mit jelent pontosan a gcs=G100 és a gcs=G111?
A G1 előtag után az első szám az ad_storage, a második az analytics_storage állapota. A G100 azt jelenti, hogy mindkettő tiltott, a G111 azt, hogy mindkettő engedélyezett. A G101 hirdetési tiltást és mérési engedélyt jelöl, a G110 pedig a fordítottját.
Elfogadtam a bannert, de nem látok új hálózati kérést. Elromlott valami?
Nem biztos. A GA4 nem küld automatikusan új oldalmegtekintést pusztán azért, mert megváltozott a hozzájárulás. Navigálj egy másik aloldalra, vagy válts ki egy eseményt, és azt a találatot nézd meg. Ha az is G100 értékkel megy ki, akkor viszont valóban elmaradt a frissítés.
A Tag Assistant elég az ellenőrzéshez, vagy kell mellé a hálózati fül is?
A Tag Assistant megmutatja a tagek hozzájárulási állapotát és a tüzelési sorrendet, ami nagyon hasznos, de a ténylegesen kimenő kérés tartalmát a hálózati fül mutatja meg. A kettőt érdemes együtt használni: az egyik a logikát, a másik a valóságot ellenőrzi.
Hogyan tesztelem a régiónkénti beállítást anélkül, hogy külföldre utaznék?
A legegyszerűbb, ha a konzolban kiolvasod a teljes alapértelmezett konfigurációt, és összeveted az elemzőrendszered országonkénti forgalmi megoszlásával. Ha a fő forrásországok közül bármelyik hiányzik a régiólistáról, és nincs globális alapértelmezés, ott hiány van. VPN-es teszt is működhet, de lassabb és kevésbé megbízható.
Milyen gyakran érdemes újra lefuttatni az ellenőrzést?
Minden éles oldalindítás után mindenképpen, továbbá sablonfrissítés, nagyobb plugintelepítés, CMP-csere vagy méréskód-átalakítás után. Saját tapasztalat, hogy a hibák többsége nem az induláskor keletkezik, hanem egy későbbi, látszólag ártalmatlan módosítás mellékhatásaként.
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.