Miért veszít el egy cég mindent a mérésből, ha egy kolléga távozik?
Rövid válasz: mert a GA4, a Search Console és a tag-kezelő soha nem a céghez tartozik, hanem ahhoz a Google-fiókhoz, amelyik létrehozta. Ha ez egy magánfiók (a marketinges saját gmail címe, a fejlesztő személyes profilja, egy régi gyakornok e-mailje), akkor a cég egyik legértékesebb adatvagyona egy olyan azonosító mögött ül, amihez a cégnek sem jogi, sem gyakorlati hozzáférése nincs.
A lefolyás szinte mindig ugyanaz. A kolléga felmond vagy az ügynökséggel megszakad a kapcsolat, a fiókot senki nem adja át, a jelszó nincs meg, a helyreállító telefonszám a távozó emberé. A GA4 tulajdon ettől még működik, az adat gyűlik, csak éppen senki nem tud új felhasználót felvenni rá, mert a fiók szintű rendszergazda pontosan az a fiók volt. A cég ilyenkor hónapokig tapogatózik: látja a weboldalt, látja a hirdetési költést, de nem látja, mi történik a kettő között.
Saját tapasztalat: a fájdalmas rész nem a jogosultság, hanem a historikus adat. Ha új GA4 tulajdont kell nyitni, az idősor nulláról indul, és egy-másfél évig nincs mihez hasonlítani a szezonalitást. Hivatalosan igazolt: a Google dokumentációja szerint a tulajdonban összegyűlt adat nem vihető át egy másik tulajdonba, a nyers eseményadat kimentésére a BigQuery-export ad utat, de az is csak attól a naptól kezdve, amikor bekapcsoltad.
Miért a cég legyen a tulajdonos, és miért ne az ügynökség?
Rövid válasz: mert a mérési fiók nem szolgáltatás, hanem eszköz. A szolgáltatást megveszed és felmondod, az eszköz viszont a tiéd marad.
Sok ügynökség jóhiszeműen hozza létre a GA4-et és a tag-kezelőt a saját fiókjában, mert így gyorsabb az indulás. A gond akkor jelentkezik, amikor a kapcsolat véget ér, és a szolgáltató jogosan mondja, hogy a saját fiókjába nem enged be idegent. Ilyenkor nem rosszindulatról van szó, hanem arról, hogy a felállás eleve rossz volt.
A helyes minta egyszerű: a legfelső szintű tulajdonos mindig egy céges, szerepkör alapú fiók (például meres@cegneve.hu), amit a cég vezetése vagy IT-je kontrollál, kétlépcsős azonosítással és dokumentált helyreállítási adatokkal. Mindenki más, beleértve a saját marketingesedet és az ügynökséget is, nevesített felhasználóként kap hozzáférést. Ez a fiók nem napi munkára való, hanem arra, hogy bármikor vissza tudd venni az irányítást.
Szakmai feltételezés: a következő években ez még fontosabb lesz, mert a mérés egyre inkább szerver oldalra és adattárházba költözik, ahol a hozzáférés már nem egy felület megnyitása, hanem szolgáltatásfiókok és API-kulcsok kérdése. Aki most nem rendezi a személyhez kötött hozzáféréseket, az később egy jóval bonyolultabb kupacot fog örökölni.
Milyen szerepek vannak GA4-ben, és kinek melyik való?
Rövid válasz: rendszergazdából legyen kettő, szerkesztőből kevés, nézőből annyi, amennyi kell.
Hivatalosan igazolt szerepek a Google dokumentációja alapján, fiók és tulajdon szinten egyaránt kiosztva:
- Rendszergazda: mindent lát és mindent állít, beleértve a felhasználók kezelését. Ide a cég két belső embere való, nem több.
- Szerkesztő: beállítást módosíthat (adatfolyam, kulcsesemény, csatornacsoport), de felhasználót nem vehet fel. Ez az ügynökség vagy a mérésért felelő szakember tipikus szintje.
- Marketingszakember: közönségeket, konverziókat és attribúciós beállításokat kezelhet, a többihez nem nyúl.
- Elemző: saját elemzéseket készíthet és megoszthat, konfigurációt nem bánt.
- Megtekintő: csak olvas. A vezetőség, a könyvelés és a legtöbb érdeklődő ide tartozik.
Ehhez jön két adatkorlátozás (költségadat és bevételadat elrejtése), ami akkor hasznos, ha külsős partnernek adsz betekintést, de az árrés-számításodat nem akarod megmutatni. A fiók szintű jog leöröklődik a tulajdonokra, ezért az ügynökséget lehetőleg tulajdon szinten vedd fel, ne a fiók tetején.
Két apró beállítás sokat segít. Az egyik, hogy a tulajdon szintű hozzáférést mindig konkrét tulajdonhoz add, ne a fiók tetejére, mert a fiók szintű jog automatikusan leöröklődik minden későbbi tulajdonra is, tehát olyasmire, ami még nem is létezik. A másik, hogy a GA4 felhasználólistát ne a fejedből ellenőrizd: a felületen exportálható, és az exportált listát érdemes összevetni a HR-nyilvántartással, amikor valaki kilép.
Hogyan működik a Search Console tulajdonosi rendszere?
Rövid válasz: a Search Console-ban az számít tulajdonosnak, aki a domaint igazolni tudja, tehát a hozzáférés valójában a DNS-nél vagy a szerveren dől el.
Hivatalosan igazolt: háromféle szint van. Az igazolt tulajdonos hitelesítési módszerrel bizonyította a birtoklást, ő teljes jogú. A delegált tulajdonos egy igazolt tulajdonostól kapja a jogát, és elveszíti, ha a delegáló hitelesítése megszűnik. A teljes és a korlátozott felhasználó csak olvas és bizonyos műveleteket indíthat, felhasználót nem kezel.
A gyakorlati tanulság ebből következik: ha a hitelesítés a fejlesztő által feltöltött HTML-fájlon vagy egy GTM-konténeren keresztül él, akkor a tulajdonosi státuszod egy másik ember döntésétől függ. Ha a fejlesztő lecseréli az oldalt vagy kikapcsolja a konténert, a hitelesítés elszáll, és vele a delegált tulajdonosok is.
Ezért a legstabilabb megoldás a DNS TXT rekord alapú, domain szintű tulajdon, amit a cég saját domainkezelőjében helyezel el, például google-site-verification=abc123... formában. A domain szintű tulajdon egyben minden aldomaint és mindkét protokollt lefedi, tehát a klasszikus „csak a www-t látom, a gyökeret nem” típusú hiányt is megszünteti.
Mire figyelj a tag-kezelőben, ha nem akarsz kockázatot?
Rövid válasz: a tag-kezelőben a közzétételi jog a legerősebb jogosultság az egész rendszerben, mert azzal bárki tetszőleges kódot futtathat a weboldaladon.
A Google Tag Manager két szinten oszt jogot. Fiók szinten felhasználó vagy rendszergazda lehetsz, tároló szinten pedig nincs hozzáférés, olvasás, szerkesztés, jóváhagyás vagy közzététel jár. Ez a második lista a lényeg: a szerkesztés jogával valaki készíthet munkaverziót, de élesíteni nem tud. A közzététel joga viszont azonnal a látogatók böngészőjébe juttat mindent, amit oda tesznek.
Jó gyakorlat, hogy külsős partner alapból szerkesztési jogot kap, közzétételt pedig csak akkor, ha a munka ritmusa ezt indokolja, és van visszakövethető verziózás. A GTM minden közzétételről verziót készít, tehát a visszaállítás megoldható, de csak akkor, ha valaki egyáltalán észreveszi a bajt.
Saját tapasztalat: a legtöbb káros GTM-beállítás nem szándékos, hanem egy elfelejtett, régen bekötött külső szkript, amit senki nem mer kivenni, mert nem tudja, mi kapcsolódik rá. Ezért érdemes minden címkére felelőst és dátumot írni a nevébe vagy a megjegyzésébe.
Ugyanez a logika él a Google-ön kívül is. A közösségi platformok üzleti kezelőjében a hirdetési fiókot, az oldalt és a pixelt vagy konverziós API-forrást a cég saját üzleti portfóliójának kell birtokolnia, a partner pedig partneri hozzáférést kap rá. Ha ez fordítva történik, ugyanaz a csapda zárul be: a hirdetési előzmény, a mért közönségek és a tanulási időszak eredménye a másik fél portfóliójában marad, és nem mozdítható át egyszerűen.
Milyen ellenőrzőlistával világítsd át a jelenlegi állapotot?
Az átvilágítás fél nap, a következményei évekre kihatnak. Menj végig ezeken, és írd le a választ, ne csak nézd meg:
- Melyik fiók a legfelső szintű tulajdonos GA4-ben, a Search Console-ban, a tag-kezelőben, a hirdetési fiókokban és a közösségi üzleti kezelőben? Céges vagy magán?
- Hány rendszergazda van rendszerenként, és mindegyikük aktív munkatárs még?
- Van olyan hozzáférés, ami távozott kolléga vagy megszűnt partner nevén fut?
- A Search Console hitelesítése min áll: DNS, HTML-fájl, meta tag, GTM vagy GA?
- Ki tud közzétenni a tag-kezelőben?
- Kinek van hozzáférése a domain regisztrátori fiókhoz és a DNS-hez? Ez a legfelső fogaskerék, nélküle a többi rendezés bizonytalan.
- Be van kapcsolva a BigQuery-export vagy bármilyen nyers adat mentése?
- Van írásos nyilvántartás arról, ki mihez fér hozzá, és mikor nézte át valaki utoljára?
A nyilvántartás lehet egy táblázat, nem kell hozzá eszköz. Egy sor, egy hozzáférés, ilyen oszlopokkal: rendszer;azonosito;tulajdonos_fiok;szerep;szemely;cel;utolso_ellenorzes. Ha ez a táblázat megvan és negyedévente ránéz valaki, a probléma nagy része meg sem születik.
Hogyan rendezed a már elrontott felállást, lépésről lépésre?
A sorrend számít, mert rossz sorrendben könnyű pont azt a hozzáférést elveszíteni, amit még használnod kellene.
- Hozd létre a céges gazda-fiókot (például
meres@cegneve.hu), kapcsold be a kétlépcsős azonosítást, és rögzítsd a helyreállítási adatokat egy jelszókezelőben, amihez a cégvezetés is hozzáfér. - Vedd fel ezt a fiókot mindenhová rendszergazdának, még a régi tulajdonossal együttműködve. Ez a lépés az egyetlen, amihez tényleg kell a régi hozzáférés, tehát ezt ne halogasd.
- Ellenőrizd, hogy a jog tényleg él: lépj be az új fiókkal, és próbálj meg felvenni egy tesztfelhasználót. Ha ez sikerül, a visszavétel megtörtént.
- Rendezd a Search Console hitelesítést DNS-re, és csak utána bontsd a régi módszereket.
- Vedd le a felesleges jogokat, a magánfiókokat cseréld nevesített céges vagy partneri fiókokra.
- Kapcsold be a nyers adat mentését (BigQuery-export), hogy a jövőben ne a felülethez legyen kötve az adatvagyonod.
- Írd le a nyilvántartásba, mi lett a végeredmény, és tegyél naptárba negyedéves felülvizsgálatot.
Ha a régi tulajdonos elérhetetlen, marad a nehezebb út: a Google támogatási folyamatai bizonyos esetekben segíthetnek a domain igazolásán keresztül, de ez időigényes, és nem garantál eredményt. Ilyenkor általában gyorsabb új tulajdont indítani a régi adat kimentése nélkül, és vállalni az idősor megszakadását.
Mit adj át és mit kérj vissza ügynökségváltáskor?
Rövid válasz: hozzáférést adj, tulajdont soha, és váltáskor a fiókok maradnak, az emberek cserélődnek.
Amit induláskor adni szoktál, és nyugodtan adhatsz: GA4 szerkesztő jog tulajdon szinten, Search Console teljes felhasználó, tag-kezelő szerkesztési (indokolt esetben közzétételi) jog, hirdetési fiókokhoz szabványos hozzáférés vagy kezelői fiók-összekapcsolás. Mindezt mindig nevesített munkatársi címekre, nem egy közös postafiókra.
Amit váltáskor vissza kell venned vagy meg kell kapnod:
- Minden korábbi hozzáférés törlése a távozó fél oldalán, rendszerenként ellenőrizve.
- A hirdetési fiókok tulajdonjoga, ha az ügynökség kezelői fiókjában jöttek létre. Ezt előre kell kikötni, utólag nehéz.
- A tag-kezelő konténer exportja (JSON), akkor is, ha a konténer marad. Ez a mérés dokumentációja.
- A mérési terv: milyen esemény mit jelent, melyik kulcsesemény mihez tartozik, milyen paraméterek mennek együtt vele.
- A szerver oldali mérés, a feed-ek és bármilyen egyedi szkript forrása és leírása.
- A kreatívok, landing oldalak és egyedi kódok forrásfájljai, plusz a szerzői jogi vagy felhasználási helyzet tisztázása.
Saját tapasztalat: az átadásnál a leggyakrabban nem a fiók hiányzik, hanem a tudás. A hozzáférés fél óra, a mérési logika visszafejtése hetek. Ezért a szerződésbe érdemes beírni, hogy a mérési dokumentáció a szolgáltatás része, nem külön kérés.
Miért stratégiai kérdés ez, és nem adminisztráció?
A saját nézőpontom röviden: aki a mérőfiókokat birtokolja, az dönti el, mi számít eredménynek. Ha az adat egy külső szereplő fiókjában él, akkor a riport is az ő szűrőjén keresztül érkezik, és a váltás költsége mesterségesen magas marad. Ez nem összeesküvés, hanem szerkezeti következmény.
A rendezett hozzáférés ezzel szemben olcsó szabadság: bármikor válthatsz szolgáltatót, bevonhatsz második szakértőt, adhatsz betekintést a könyvelésnek vagy egy befektetőnek anélkül, hogy bárkitől engedélyt kellene kérned. Az adatvagyon így ugyanolyan céges eszközzé válik, mint a domain vagy a védjegy. Egy délutánnyi munka most, sokéves mozgástér cserébe.
Források és további olvasnivalók
- Google Analytics Súgó: Access management, felhasználói szerepek és adatkorlátozások
- Google Search Console Súgó: Tulajdon hitelesítése és felhasználókezelés
- Google Tag Manager Súgó: Fiók- és tárolóengedélyek
- Google Search Central: Dokumentáció a webhelytulajdonosoknak
- Google Ads Súgó: Fiókhozzáférés szintjei és kezelői fiókok
- Google Cloud dokumentáció: BigQuery Export a Google Analytics 4-hez
- NAIH és GDPR (EU 2016/679) adatkezelői kötelezettségek, hozzáférés-kezelés
- A GA4, a Search Console és a tag-kezelő legfelső szintű tulajdonosa mindig céges, szerepkör alapú fiók legyen, ne magánfiók.
- Az ügynökség szerkesztő vagy felhasználó szintet kapjon, rendszergazdából a cégnek legyen kettő.
- A Search Console tulajdonjog a hitelesítésen múlik, ezért a DNS TXT rekord a legstabilabb megoldás.
- A tag-kezelőben a közzétételi jog a legerősebb jogosultság, mert azzal bárki kódot futtathat az oldalon.
- Ügynökségváltáskor a fiókok maradnak, a hozzáférések cserélődnek: kérd vissza a konténer-exportot és a mérési dokumentációt is.
Gyakori kérdések
Kinek legyen rendszergazda jogosultsága a GA4-ben?
Két belső, céges embernek: jellemzően a marketingért felelős vezetőnek és egy második, helyettesítő kollégának. A külsős partnernek szerkesztő jog is elég, mert az minden mérési beállítást lefed, felhasználót viszont nem tud felvenni vagy törölni.
Miért baj, ha az ügynökség fiókjában van a GA4 tulajdon?
Mert a kapcsolat végén a szolgáltató jogosan nem enged idegent a saját fiókjába, te pedig nem tudsz hozzáférést adni senki másnak. A tulajdonban lévő historikus adat nem vihető át másik tulajdonba, tehát az idősor jó eséllyel megszakad.
Hogyan hitelesítsem a Search Console tulajdont, hogy ne vesszen el?
Domain szintű tulajdonnal, DNS TXT rekorddal, a cég saját domainkezelő fiókjában. Így a hitelesítés nem függ attól, hogy a fejlesztő mit tölt fel az oldalra vagy mi történik a tag-kezelő konténerrel.
Kapjon-e az ügynökség közzétételi jogot a tag-kezelőben?
Alapból elég a szerkesztési jog, közzététel pedig akkor, ha a munka üteme ezt indokolja és van rendszeres átnézés. A közzététel joga azonnal a látogatók böngészőjébe juttat mindent, ami a konténerbe kerül.
Mit kérjek vissza, ha ügynökséget váltok?
A tag-kezelő konténer JSON-exportját, a mérési tervet (esemény, paraméter, kulcsesemény), a szerver oldali mérés és egyedi szkriptek leírását, valamint a hirdetési fiókok tulajdonjogát. Ezzel párhuzamosan minden korábbi hozzáférést rendszerenként törölj.
Mi a teendő, ha a régi fiók tulajdonosa elérhetetlen?
Előbb próbáld meg a domain igazolásán alapuló hivatalos utakat, ez azonban időigényes és nem garantál eredményt. Ha nem vezet célra, általában gyorsabb új tulajdont indítani, és vállalni, hogy az összehasonlítási alap egy időre megszakad.
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.