Google Tag Manager verziókezelés, munkaterületek és visszaállítás hibás közzététel után

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

A Google Tag Manager tárolója olyan, mint egy közös fiók a konyhában. Mindenki beletesz valamit, és egy idő után senki sem tudja, mi miért van ott. A verziókezelés, a munkaterületek és néhány egyszerű elnevezési szokás arra való, hogy ez a fiók rendben maradjon, és ha egy közzététel elrontja a mérést, gyorsan vissza tudj lépni. A cikkben három jelölést használok. A Hivatalosan igazolt rész a Google saját súgójában leírt működés, a Saját tapasztalat az, amit ügynökségi munkában rendszeresen látunk, a Szakmai feltételezés pedig olyan következtetés, amelyre nincs hivatalos megerősítés.

Mi az a GTM-verzió, és miért érdemes mindegyiket elnevezni?

A verzió a tároló teljes állapotának pillanatfelvétele, amely tartalmazza az összes címkét, eseményindítót, változót és beállítást úgy, ahogy a mentés pillanatában álltak. A név és a leírás az egyetlen hely, ahol utólag kiderül, mit akart az, aki a változtatást kiadta.

Hivatalosan igazolt. A Tag Manager minden közzétételkor automatikusan verziót hoz létre, és verziót közzététel nélkül is menthetsz. A Verziók fülön a korábbi állapotok visszanézhetők, előnézetben megnyithatók, újra közzétehetők és exportálhatók. A küldés (Submit) ablakban a verzió neve és leírása szabadon kitölthető, de egyik sem kötelező.

Saját tapasztalat. Mivel a két mező nem kötelező, az átvett tárolók nagy részében üresen áll. Ilyenkor a lista csak sorszámokat és dátumokat mutat, és egy hiba után egyenként kell megnyitni a verziókat, hogy kiderüljön, melyik hozta be a gondot. Ez a keresgélés viszi el az időt, maga a visszaállítás utána már gyors.

Hogyan érdemes elnevezni és leírni a verziókat?

A jó verziónév egy sorban megmondja, mi változott és melyik területen, a leírás pedig megadja az okot, a kérőt és az ellenőrzés módját. Egy egyszerű, mindig ugyanúgy használt minta többet ér, mint egy részletes, de következetlenül vezetett rendszer.

Nálunk ez a névminta vált be.

[terület] művelet + tárgy (hivatkozás)

Néhány példa arra, hogyan néz ki ez a gyakorlatban.

• [GA4] purchase esemény: items tömb javítása (feladat #214)
• [Ads] ajánlatkérés konverzió hozzáadása a köszönőoldalhoz
• [Consent] hirdetési címkék hozzájárulási beállításainak szigorítása
• [Takarítás] 6 használaton kívüli Universal Analytics címke törlése

A leírásba négy rövid sort érdemes írni.

• Mi változott. A hozzáadott, módosított és törölt elemek neve.
• Miért. Az üzleti vagy technikai ok egy mondatban.
• Ki kérte, ki tesztelte. Név vagy monogram, hogy legyen kit megkérdezni.
• Hogyan ellenőrizhető. Például az, hogy a GA4 DebugView nézetében egy próbavásárlásnál megjelenik-e a purchase esemény.

Szakmai feltételezés. A névminta formája másodlagos. Az számít, hogy a csapatból mindenki ugyanazt használja, és hogy a terület a név elején álljon, mert a verziólistában így lehet a leggyorsabban szemmel szűrni.

Mire valók a munkaterületek, ha többen dolgoztok egy tárolóban?

A munkaterület a tároló egy elkülönített piszkozata, amelyben úgy dolgozhatsz egy feladaton, hogy közben a kollégád félkész módosításai nem kerülnek bele a te kiadásodba. Akkor van rá szükség, ha egyszerre több, egymástól független változtatás készül.

Hivatalosan igazolt. Az ingyenes Tag Manager fiókban tárolónként három munkaterület használható egyszerre, a Tag Manager 360 esetében nincs ilyen korlát. Amikor egy munkaterületből verzió készül, az a munkaterület megszűnik. A többi munkaterület jelzést kap, hogy elavult, és frissíteni kell a legújabb verzióra. Ha ugyanazt az elemet két helyen is módosították, a felület ütközést jelez, és elemenként kell eldöntened, melyik változat maradjon.

Saját tapasztalat. A legtöbb gond a hetekig nyitva hagyott munkaterületekből jön. Minél régebbi egy munkaterület, annál több ütközést hoz a frissítésnél, és annál nehezebb felidézni, mi volt benne félkész. Három szokás sokat segít ezen.

• Egy munkaterület egy feladatot szolgál, és a neve megegyezik a tervezett verzió nevével.
• A munkaterület leírásába bekerül, ki dolgozik rajta, és mi a célja.
• Közzététel előtt mindig frissítesz a legújabb verzióra, és a frissítés után újra tesztelsz.

Az alapértelmezett munkaterületet (Default Workspace) érdemes apró, azonnali javításokra fenntartani. Ha minden munka ott gyűlik, egy sürgős javítással együtt a félkész fejlesztés is kimegy, és ezt sokszor csak napokkal később veszi észre valaki.

Hogyan használd az előnézeti módot közzététel előtt?

Az előnézeti mód a saját böngésződben futtatja a munkaterület aktuális állapotát, miközben a látogatók továbbra is az élő verziót kapják. Így kockázat nélkül megnézheted, melyik címke sül el, melyik nem, és milyen értékek kerülnek a változókba.

Hivatalosan igazolt. Az Előnézet gomb a Tag Assistant felületét nyitja meg, ahol meg kell adnod az oldal címét. A weboldal külön ablakban töltődik be, a Tag Assistant pedig eseményenként mutatja az elsült és el nem sült címkéket, a változók értékét, az adatréteg tartalmát és a hozzájárulási állapotot. Az előnézet megosztható hivatkozással másnak is átadható, és egy korábbi verzió is megnyitható előnézetben.

Egy alapos teszt nagyjából így néz ki.

1. Végigmész a teljes folyamaton, tehát a kosáron, a pénztáron és a köszönőoldalon, vagy az űrlap kitöltésén és elküldésén.
2. Minden érintett eseménynél megnézed, hogy a várt címke elsült-e, és pontosan egyszer sült-e el.
3. A változók fülön ellenőrzöd az értékeket, például a tranzakció összegét, a pénznemet és a termékazonosítót.
4. Megnézed a hozzájárulás elutasítása melletti viselkedést is, mert ott csak az futhat, aminek szabad.
5. A fogadó oldalon is megerősíted az eredményt, például a GA4 DebugView nézetében vagy a hirdetési rendszer diagnosztikai felületén.

Saját tapasztalat. A leggyakoribb tévedés az, hogy az előnézetben zölden megjelenő címkét valaki késznek tekinti. Az előnézet azt igazolja, hogy a címke lefutott. Azt már a fogadó rendszer mutatja meg, hogy az adat helyes paraméterekkel érkezett-e meg, ezért a két ellenőrzés együtt ad megbízható képet.

Mi legyen a kiadási ellenőrzőlistán?

Egy rövid, minden közzététel előtt végigolvasott lista jó eséllyel kiszűri a hibák nagy részét, mert a legtöbb gond figyelmetlenségből és nem tudáshiányból fakad. A lista akkor működik, ha elég rövid ahhoz, hogy tényleg mindig végigmenjen rajta az, aki a kiadást indítja.

1. A munkaterület frissítve van a legújabb verzióra, és nincs feloldatlan ütközés.
2. A módosítások listájában csak az szerepel, amit ki akarsz adni, idegen vagy félkész elem nincs benne.
3. Az előnézeti teszt megvolt asztali gépen és mobilon, elfogadott és elutasított hozzájárulás mellett is.
4. Az új elemek neve követi a tároló elnevezési szabályát, és a megfelelő mappában vannak.
5. A teszthez használt ideiglenes címkék, eseményindítók és hibakereső beállítások ki vannak véve.
6. A verzió neve és leírása ki van töltve.
7. Tudod, melyik az utolsó biztosan működő verzió, amelyhez gond esetén visszatérsz.
8. A közzététel után az élő oldalon is lefuttatsz egy gyors próbát, és a következő napokban ránézel a számokra.

Szakmai feltételezés. Nagyobb módosítást érdemes olyan időpontban kiadni, amikor utána még van, aki figyeli az adatokat. A péntek délutáni közzététel hibája jellemzően csak hétfőn derül ki, és addig hiányos marad a mérés.

Hogyan állítasz vissza egy korábbi verziót hibás közzététel után?

A Verziók fülön kiválasztod az utolsó működő verziót, és újra közzéteszed. Ez néhány kattintás, a hatása pedig rövid időn belül megjelenik az élő oldalon. A lassú rész annak eldöntése, melyik verzió volt még rendben.

1. Nyisd meg a Verziók fület, és keresd meg a hibás kiadás előtti verziót. Itt térül meg az elnevezés.
2. Ha bizonytalan vagy, nyisd meg a kiszemelt verziót előnézetben, és ellenőrizd, hogy a mérés azzal rendben fut-e.
3. A verzió műveleti menüjében válaszd a közzétételt, és erősítsd meg.
4. Az élő oldalon ellenőrizd, hogy a korábbi működés visszaállt.
5. Jegyezd fel, mettől meddig volt élő a hibás verzió, mert erre az időszakra az adatok hiányosak vagy torzak lehetnek.

Hivatalosan igazolt. Egy korábbi verzió újbóli közzététele az élő állapotot cseréli le, a munkaterületek alapja viszont a legújabb verzió marad. Erre szolgál a verzió menüjében a beállítás legújabb verzióként (Set as Latest Version) lehetőség, amely a kiválasztott régi állapotot teszi a további munka kiindulópontjává.

Saját tapasztalat. Ezt a lépést sokan kihagyják. Ha csak újra közzéteszed a régi verziót, a hibás módosítás benne marad a munka alapjában, és a következő kiadással észrevétlenül visszakerül az élő oldalra. Visszaállítás után ezért vagy a működő verziót állítod be legújabbként, vagy egy új munkaterületben célzottan kijavítod a hibát, és azt adod ki.

Fontos korlát, hogy a visszaállítás a jövőbeli mérést hozza rendbe. Az az adat, amely a hibás időszakban nem érkezett meg vagy duplán érkezett, a Tag Managerből nem pótolható.

Miért érdemes exportálni a tárolót mentésként?

Az exportált fájl a tároló egy adott verziójának vagy munkaterületének teljes másolata JSON formátumban, amely a Tag Manager fiókon kívül is megmarad. Akkor ad biztonságot, ha a hozzáférés elveszik, ha valaki véglegesen töröl egy tárolót, vagy ha a beállításokat egy másik tárolóba kell átvinni.

Hivatalosan igazolt. Az exportálás az Adminisztrálás menüből indítható, és megadható, melyik verzió vagy munkaterület kerüljön a fájlba. Importáláskor választhatsz a teljes felülírás és az egyesítés között. Egyesítésnél azt is eldöntöd, hogy az azonos nevű elemeket a rendszer felülírja vagy átnevezze.

Saját tapasztalat. Három helyzetben érdemes mindig exportálni. Az első a nagyobb átalakítás előtti állapot, a második egy weboldal átvétele vagy átadása, a harmadik pedig a rendszeres, például negyedévenkénti mentés. A fájl nevébe kerüljön bele a tároló azonosítója, a verziószám és a dátum, a fájl pedig olyan tárhelyre menjen, amelyhez a megbízónak is van hozzáférése.

A fájl tartalmazza a mérési azonosítókat és az egyedi kódokat is, ezért ne küldd tovább gondolkodás nélkül, és ne tedd nyilvános helyre.

Milyen jogosultsági szintet kapjon, aki a tárolóban dolgozik?

Mindenki a feladatához szükséges legalacsonyabb szintet kapja, és közzétenni csak az tudjon, aki a kiadásért felelősséget is vállal. A túl bőkezűen kiosztott közzétételi jog az egyik leggyakoribb oka annak, hogy senki sem tudja, ki mit adott ki.

Hivatalosan igazolt. Fiókszinten adminisztrátori és felhasználói szerep létezik. A tároló szintjén öt fokozat van.

• Nincs hozzáférés. A felhasználó a tárolót nem látja.
• Olvasás. Megnézheti a címkéket, eseményindítókat és változókat, de nem módosíthat.
• Szerkesztés. Munkaterületet hozhat létre és szerkeszthet, verziót viszont nem készíthet, és nem tehet közzé.
• Jóváhagyás. Verziót is létrehozhat, de közzétenni nem tud.
• Közzététel. Minden műveletre jogosult, a közzétételt is beleértve.

Saját tapasztalat. A tároló tulajdonosa mindig a megbízó cég fiókja legyen, a külső partner pedig meghívott felhasználóként dolgozzon benne. Ha egy együttműködés véget ér, így elég a hozzáférést visszavonni, és a tároló a teljes verziótörténettel együtt a cégnél marad. A felhasználók listáját félévente érdemes átnézni, mert a régi partnerek és a távozott kollégák hozzáférése gyakran évekig bent ragad.

Milyen minimális dokumentálás kell, hogy egy év múlva is érthető legyen a tároló?

Az a véleményünk, hogy külön, vastag dokumentációra a legtöbb kis és közepes tárolónál nincs szükség, mert azt senki sem frissíti. Öt apró szokás elég, ha a dokumentáció magában a tárolóban él, és a munka részeként készül el.

1. Következetes elemnevek. A név elején a platform, utána a típus, a végén a cél áll, például GA4 - esemény - ajánlatkérés elküldve vagy Ads - konverzió - vásárlás. Az eseményindítók és a változók ugyanezt a logikát követik.
2. Mappák terület szerint. Külön mappa kerül az analitikának, a hirdetési rendszereknek, a hozzájárulás-kezelésnek és a segédváltozóknak.
3. Kitöltött verziónév és leírás. Ez adja a változásnaplót, külön táblázat nélkül.
4. Megjegyzés az egyedi kód elején. Minden egyedi HTML címke és egyedi JavaScript változó első sora mondja meg, mit csinál a kód, ki írta, és mikor.
5. Egy egyoldalas mérési terv. Egy megosztott dokumentum sorolja fel, mely eseményeket méritek, hová mennek az adatok, és ki a felelős.

Szakmai feltételezés. A dokumentálás azért marad el, mert külön feladatnak tűnik. Ha a kiadási ellenőrzőlista része, akkor kiadásonként egy-két perc, és egy év múlva megspórolja azt a fél napot, amíg valaki visszafejti, mit mér egy „teszt2 végleges” nevű címke.

Egy egyszerű próba megmutatja, hol tartasz. Kérj meg valakit, aki még nem látta a tárolót, hogy tíz perc alatt mondja meg, mi méri a vásárlást, és mikor változott utoljára. Ha sikerül neki, a dokumentálás elég jó.

Források és további olvasnivalók

• Google Tag Manager Súgó, a verziók, a közzététel és a munkaterületek leírása
• Google Tag Manager Súgó, a tárolók exportálása és importálása, valamint a környezetek
• Google Tag Manager Súgó, a felhasználók és a jogosultságok kezelése
• Google Tag Assistant Súgó, az előnézeti és hibakeresési mód
• Google Analytics Súgó, a DebugView használata
• Google for Developers, a Tag Manager fejlesztői dokumentációja