GA4 User-ID beállítása bejelentkezett felhasználóknál

Scheo · 2026-10-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A GA4 alapból eszközönként és böngészőnként számolja a felhasználókat. Aki reggel telefonon nézi meg a kosarát, este pedig laptopon fizet, az két külön embernek látszik a riportban. A User-ID ezt a torzítást csökkenti azoknál a látogatóknál, akik bejelentkeznek nálad. Ebben a cikkben végigmegyünk azon, mit nyersz vele, mikor éri meg a munkát, hogyan adod át az azonosítót dataLayeren keresztül, és mit kell mellé rendbe tenned adatvédelmi oldalon.

A szövegben három címkét használunk. A Hivatalosan igazolt állítások a Google dokumentációjából származnak. A Saját tapasztalat a beállítások során látott, általános mintákat jelöli. A Szakmai feltételezés olyan következtetés, amit érdemes a saját adataidon ellenőrizned.

Mit ad hozzá a User-ID a GA4 riportjaihoz?

A User-ID egy általad kiosztott, tartós azonosító, amellyel a GA4 egyetlen felhasználóhoz köti ugyanannak a bejelentkezett embernek a különböző eszközökön és böngészőkben indított munkameneteit. Ettől pontosabb lesz a felhasználószám, a visszatérési arány és a vásárlásig vezető út képe.

Hivatalosan igazolt. User-ID nélkül a GA4 az eszközazonosítóra támaszkodik, ami weben a böngészőben tárolt first-party süti értéke. Sütitörlésnél, új böngészőnél vagy másik eszköznél ez új felhasználót jelent. A User-ID-val küldött eseményeket az Analytics egy felhasználóhoz rendeli, függetlenül attól, melyik eszközről érkeztek. Ha valaki a munkamenet közben jelentkezik be, a GA4 az ugyanabban a munkamenetben korábban rögzített eseményeket is ehhez az azonosítóhoz köti. A kijelentkezés utáni események viszont már nem kapják meg.

A gyakorlatban három helyen látod a különbséget:

• Felhasználószám. A több eszközt használó, bejelentkezett látogatók egyszer számítanak, így az összes felhasználó értéke jellemzően csökken, az egy főre jutó munkamenet és bevétel pedig nő.
• Visszatérés és megtartás. A visszatérő felhasználók aránya és a megtartási riport közelebb kerül a valósághoz, mert a sütitörlés nem csinál új látogatót a régi vásárlóból.
• Eszközök közötti út. A Felfedezések között a felhasználói felfedező és az útvonal-elemzés egyben mutatja a telefonos böngészést és az asztali gépen leadott rendelést.

Hivatalosan igazolt. A riportokban összehasonlítást építhetsz a „Bejelentkezve felhasználói azonosítóval” dimenzióra, és a User-ID a BigQuery-exportban is külön mezőként jelenik meg. Szakmai feltételezés. A javulás mértéke azon múlik, a forgalmad mekkora része jelentkezik be. Ha ez a hányad alacsony, a riportok összképe alig mozdul.

Milyen oldalaknál van értelme bevezetni?

Ott éri meg, ahol a látogatók érdemi része rendszeresen bejelentkezik, és a bejelentkezés után történik az üzletileg fontos tevékenység. Egy bemutatkozó oldalon, ahol nincs fiók, a User-ID-nak nincs mit összekötnie.

• Webshop fiókkal. Visszatérő vásárlók, újrarendelés, kívánságlista, hűségprogram. Itt látod meg, hány vásárlás indul telefonon és zárul asztali gépen.
• Ügyfélportál. Számlák, megrendelések, hibajegyek, időpontfoglalás. A kérdés itt általában az, hogy mely funkciókat használják ténylegesen az ügyfelek, és hol akadnak el.
• Tagsági oldal, online kurzus, előfizetéses szolgáltatás. A megtartás és az aktivitás a fő mutató, ehhez pedig stabil felhasználói azonosítás kell.

Saját tapasztalat. A vendégként is rendelhető webshopoknál a vásárlók számottevő része sosem lép be, ezért ott a User-ID a törzsvásárlói körről ad jobb képet, a teljes forgalomról kevésbé. Érdemes előre megnézned a saját rendszeredben, a rendelések mekkora hányada érkezik belépett fiókból. Szakmai feltételezés. Ha ez a rész csekély, a bevezetés haszna jó eséllyel kisebb, mint a ráfordított fejlesztői munka, és előbb a fiókhasználat ösztönzésén érdemes dolgozni.

Milyen azonosítót adhatsz át, és mi nem kerülhet bele?

Olyan belső, tartós azonosítót adj át, amely a saját adatbázisodon kívül senkinek nem mond semmit az emberről. E-mail-cím, név, telefonszám és felhasználónév nem kerülhet bele.

Hivatalosan igazolt. A Google Analytics szabályzata tiltja, hogy személyazonosításra alkalmas adatot küldj a rendszerbe, és ez a User-ID értékére is vonatkozik. Az azonosító legfeljebb 256 karakter hosszú lehet. Kijelentkezett látogatónál a paramétert nem szabad üres karakterlánccal vagy helykitöltő szöveggel elküldeni, ilyenkor az érték null legyen, vagy maradjon ki.

Ami megfelel:

• az ügyféltábla belső sorszáma vagy UUID-ja, például U-483920,
• a CRM-ben használt ügyfélkód, ha nem tartalmaz nevet vagy születési adatot,
• egy kifejezetten erre a célra generált véletlen azonosító, amelyet a fiók mellett tárolsz.

Ami nem megfelel:

• e-mail-cím, akár nyersen, akár URL-be kódolva,
• teljes név, felhasználónév, becenév,
• telefonszám, adóazonosító vagy olyan kártyaszám, amelyből az ember közvetlenül kikereshető,
• a GA saját kliensazonosítója (a _ga süti értéke), mert az eszközhöz kötött, és eszközönként más.

Szakmai feltételezés. Az e-mail-cím egyszerű, só nélküli hash-elését kerüld. Ugyanaz a cím mindig ugyanazt a lenyomatot adja, így az érték visszakereshető, és a megítélése jogi oldalon is bizonytalan. A belső adatbázis-azonosító egyszerűbb és tisztább megoldás.

Hogyan adod át a User-ID-t dataLayeren keresztül?

A szerveroldal bejelentkezett állapotban kiírja az azonosítót a dataLayerbe, a Google Tag Manager egy adatréteg-változóval kiolvassa, a Google-címke pedig user_id paraméterként küldi tovább a GA4-nek. A sorrenden múlik minden, az értéknek már ott kell lennie, amikor a címke lefut.

1. Írd ki az azonosítót a GTM-kód előtt. A sablonban, a Tag Manager konténerkódja fölött helyezd el a push-t, és csak bejelentkezett felhasználónál rendereld ki: window.dataLayer = window.dataLayer || []; window.dataLayer.push({ 'user_id': 'U-483920' });
2. Kezeld a bejelentkezés pillanatát. Ha a belépés oldalújratöltés nélkül történik (például felugró ablakban vagy egyoldalas alkalmazásban), küldj külön eseményt: window.dataLayer.push({ 'event': 'login', 'method': 'email', 'user_id': 'U-483920' }); A login a GA4 ajánlott eseménye, így a riportokban is jól használható.
3. Hozz létre adatréteg-változót. A GTM-ben a Változók között adj hozzá egy új, Adatréteg-változó típusú elemet, a változó neve user_id legyen. Alapértelmezett értéket ne állíts be, így kijelentkezett látogatónál a változó üres marad, és a paraméter nem megy el.
4. Add hozzá a Google-címkéhez. A Google-címke konfigurációs beállításainál vegyél fel egy user_id nevű paramétert, értékként pedig add meg a most létrehozott változót. Így az azonosító minden eseménnyel együtt megy, a vásárlással is.
5. Kijelentkezéskor töröld az értéket. Erre szolgál a window.dataLayer.push({ 'user_id': null }); sor. Közös gépen ezzel előzöd meg, hogy a következő látogató eseményei az előző fiókhoz kerüljenek.
6. Kösd a hozzájáruláshoz. A címke csak akkor küldjön azonosítót, ha a látogató elfogadta az analitikai sütiket. Consent Mode használatakor ezt az analytics_storage állapota vezérli.

Ha nem használsz Tag Managert, a gtag.js-ben ugyanez egy sor: gtag('config', 'G-XXXXXXX', { 'user_id': 'U-483920' });

Saját tapasztalat. A leggyakoribb hiba az időzítés. Ha a dataLayer push a konténerkód után, a lábléc környékén fut le, az első oldalmegtekintés azonosító nélkül megy el. WordPress és WooCommerce alatt ezért a kiírást a fejléc elejére érdemes időzíteni, a bejelentkezett felhasználó numerikus azonosítójával. Gyorsítótárazott oldalaknál arra is figyelj, hogy a cache ne szolgálja ki egy másik felhasználó azonosítóját, a belépett állapotú oldalakat ezért jellemzően ki kell venni a teljes oldalas gyorsítótárból.

Melyik jelentési identitást állítsd be?

A legtöbb fiókos oldalnál a Megfigyelt vagy a Vegyes identitás a jó választás, mert mindkettő elsőként a User-ID-t veszi figyelembe. Eszközalapú beállítás mellett a GA4 a riportokban figyelmen kívül hagyja az azonosítót, hiába gyűjtöd.

Hivatalosan igazolt. A beállítást az Adminisztráció részben, az Adatmegjelenítés alatt, a Jelentési identitás pontnál találod. Három lehetőség van:

• Vegyes (Blended). Sorrendben a User-ID-t, az eszközazonosítót, végül a modellezést használja. A modellezés a hozzájárulást megtagadó látogatók viselkedését becsli, ha a tulajdon megfelel a feltételeknek.
• Megfigyelt (Observed). User-ID, ennek hiányában eszközazonosító. Modellezett adat nincs benne.
• Eszközalapú (Device-based). Csak az eszközazonosítóval számol.

A jelentési identitás megjelenítési beállítás. Az adatgyűjtést nem érinti, bármikor átváltható, és a váltás a korábbi időszak riportjaira is hat. Saját tapasztalat. Hasznos ellenőrzés, ha ugyanazt az időszakot megnézed Eszközalapú és Megfigyelt módban is. A két felhasználószám különbsége megmutatja, mekkora duplikációt szüntet meg nálad a User-ID. Azt viszont tudnod kell, hogy az azonosító nem visszamenőleges, a bevezetés előtti eseményeket a GA4 utólag nem köti össze.

Mit kell kiegészítened az adatvédelmi tájékoztatóban?

Le kell írnod, hogy a bejelentkezett felhasználók tevékenységét egy belső azonosítóval, eszközökön átívelően is méred, és ehhez milyen jogalapot használsz. A User-ID álnevesített adat, de a te adatbázisodban egy konkrét emberhez köthető, ezért személyes adatnak számít.

Hivatalosan igazolt. A Google feltételei szerint a látogatókat megfelelően tájékoztatnod kell az azonosítók használatáról, a GDPR pedig az átláthatóságot és a jogalap megjelölését írja elő. A tájékoztatóba és a sütikezelési leírásba ezek kerüljenek be:

• bejelentkezett állapotban egyedi, belső azonosítót adsz át a Google Analyticsnek,
• az adatkezelés célja (látogatottsági statisztika, a szolgáltatás fejlesztése, eszközök közötti használat mérése),
• a jogalap, ami a gyakorlatban jellemzően a hozzájárulás,
• az, hogy az azonosító nem tartalmaz nevet vagy e-mail-címet, a te rendszeredben viszont összeköthető a fiókkal,
• az adatfeldolgozó megnevezése és a megőrzési idő (a GA4 adatmegőrzési beállítása szerint),
• a hozzájárulás visszavonásának és az adatok törlésének módja.

Szakmai feltételezés. A sütisáv szövegét is érdemes hozzáigazítani, mert az általános „statisztikai sütik” megfogalmazás jó eséllyel kevés ahhoz, hogy az eszközök közötti összekötést lefedje. Ez a rész szakmai áttekintés, a végleges szöveget egyeztesd adatvédelmi szakértővel vagy az adatvédelmi tisztviselőddel.

Hogyan ellenőrzöd DebugView-ban, hogy jól megy át az azonosító?

Kapcsold be a hibakereső módot, jelentkezz be egy tesztfiókkal, és nézd meg, hogy az események mellett megjelenik-e a várt azonosító. Az éles riportokban az adat csak órákkal később látszik, a DebugView viszont szinte azonnal mutatja az eseményeket.

1. Indítsd el a GTM előnézeti módját (Tag Assistant), ez hibakereső módba teszi a böngésződet. Tag Manager nélkül a Google Analytics Debugger bővítmény vagy a debug_mode paraméter adja ugyanezt.
2. A GA4-ben nyisd meg az Adminisztráció, Adatmegjelenítés, DebugView oldalt, és válaszd ki a saját eszközödet a listából.
3. Nyiss meg egy oldalt kijelentkezve. A Tag Assistant Adatréteg fülén ilyenkor a user_id nem szerepelhet, vagy null az értéke.
4. Jelentkezz be. Az idővonalon megjelenik a login esemény és az utána következő page_view. Kattints rá, és nézd át a paramétereket, illetve a felhasználói tulajdonságok panelt.
5. Nyisd meg a böngésző fejlesztői eszközeinek Hálózat fülét, szűrj a collect kérésekre, és keresd meg bennük az uid paramétert. Az értékének pontosan egyeznie kell a dataLayerbe írt azonosítóval.
6. Jelentkezz ki, és ellenőrizd, hogy a következő kérésekből az uid eltűnt.
7. Ismételd meg a belépést egy másik böngészőben vagy telefonon ugyanazzal a fiókkal. A két eszközön ugyanazt az értéket kell látnod.

Saját tapasztalat. A DebugView felülete nem minden esetben jeleníti meg feltűnően az azonosítót, ezért a hálózati kérés uid paramétere a megbízhatóbb bizonyíték. Egy-két nappal később érdemes megnézni a felhasználói felfedezőt is, ahol a tesztfiók azonosítója alatt a két eszköz eseményeinek egy idővonalon kell szerepelniük.

Milyen hibákat érdemes kizárnod élesítés előtt?

A hibák többsége az időzítésből, a rossz értékből és a kimaradt kijelentkezésből adódik. Élesítés előtt menj végig ezen a listán:

• A dataLayer push a GTM-konténer előtt fut, vagy külön esemény indítja a címkét.
• Az érték belső azonosító, nincs benne e-mail-cím, név vagy telefonszám.
• Kijelentkezett látogatónál a paraméter hiányzik, üres karakterlánc sem megy el.
• Kijelentkezéskor az érték null-ra áll.
• A belépett oldalak nem kerülnek teljes oldalas gyorsítótárba.
• A jelentési identitás Megfigyelt vagy Vegyes.
• A hozzájárulás-kezelés és a tájékoztató frissítve van.
• Ugyanaz a fiók két eszközön ugyanazt az uid értéket adja.

A User-ID nem garantál hibátlan mérést. A be nem jelentkező látogatókat továbbra is eszközönként látod, a hozzájárulást megtagadók adatai pedig hiányozni fognak, vagy modellezettek lesznek. A fiókkal rendelkező, legértékesebb közönségedről viszont megbízhatóbb képet kapsz, és ez segítheti a megalapozottabb döntéseket.

Források és további olvasnivalók

• Google Analytics Súgó: Tevékenység mérése platformok között a User-ID funkcióval
• Google Analytics Súgó: Jelentési identitás
• Google for Developers: Felhasználói azonosítók küldése (Google Analytics 4)
• Google Analytics Súgó: Események megfigyelése a DebugView-ban
• Google Analytics Súgó: Személyazonosításra alkalmas adatok küldésének elkerülése
• Google Tag Manager Súgó: Adatréteg és adatréteg-változók
• Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR)
• Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói