Google Tag Manager beállítás: mire jó és mikor kell

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

A Google Tag Managert sokan úgy emlegetik, mintha egy mérőeszköz lenne. Nem az. A GTM egy kódkezelő rendszer (tag management system), ami a weboldalad és a mérőrendszerek közé ékelődik. Nem gyűjt adatot, nem készít riportot, nem mond meg semmit a látogatóidról. Azt teszi lehetővé, hogy a mérőkódokat és a hirdetési pixeleket egy felületről kezeld, verziózd és publikáld, ahelyett hogy minden apró módosításnál a sablonfájlokhoz nyúlnál.

Ez a különbség a gyakorlatban ott válik érdekessé, amikor eldöntöd, hogy egyáltalán szükséged van-e rá.

Mikor van tényleg szükséged GTM beállításra?

Akkor éri meg, ha egynél több mérőkódot futtatsz, vagy ha rendszeresen módosulnak a mért események. Ha csak egy GA4-alapmérés fut egy ritkán változó bemutatkozó oldalon, a natív GA4-kódrészlet is elegendő, és a GTM inkább csak egy plusz réteg, amit karban kell tartani.

Tipikus helyzetek, ahol a GTM beállítás valódi különbséget hoz:

• Webshop vagy ajánlatkérős oldal, ahol GA4, Google Ads és Meta pixel is fut, és mindegyiknek ugyanazokat az eseményeket kell megkapnia.
• Több kampányforrás fut párhuzamosan, és a konverziókat forrásonként akarod visszamérni.
• Nincs állandó fejlesztői kapacitásod, de havonta lenne 2-3 mérési módosítás.
• Hozzájárulás-kezelést (cookie banner) kell összekötnöd a mérőkódokkal úgy, hogy a beállítás dokumentálva és visszakövethető legyen.
• Külső eszközöket tesztelsz (hőtérkép, chat, A/B teszt), és nem akarod minden próbához újratelepíteni az oldalt.

Ahol viszont óvatos lennék (ez saját tapasztalat, nem hivatalos ajánlás): egyoldalas kampányoldalnál, ahol egy darab űrlap van és fél éve nem nyúlt hozzá senki, a GTM bevezetése önmagában nem javít semmin. Rétegzettséget hoz oda, ahol nincs mit rétegezni.

Hogyan épül fel egy GTM konténer?

Három építőelemet kell megértened: tag, trigger, változó. Minden más ezekből áll össze.

• Tag (címke): maga a kód, ami elindul. Például egy GA4-esemény, egy Google Ads konverziókövetés vagy egy Meta pixel esemény.
• Trigger (aktiváló): a feltétel, ami eldönti, hogy a tag mikor fusson. Oldalletöltés, kattintás, űrlapbeküldés, vagy saját adatréteg-esemény.
• Változó (variable): az érték, amit a tag felhasznál. Például a rendelés összege, a termék azonosítója, a kattintott gomb szövege.

Ezek fölött van az dataLayer, vagyis az adatréteg: egy JavaScript-tömb, amin keresztül az oldalad átadja az információt a GTM-nek. A hivatalos Google-dokumentáció szerint ez az ajánlott módja annak, hogy strukturált adatot juttass a konténerbe, és a saját tapasztalatom is az, hogy a DOM-ból kiszedegetett értékek (például a kosárösszeg kiolvasása egy CSS-szelektorral) az első sablonfrissítéskor elromlanak. Az adatréteg stabilabb.

Hogyan állítasz be egy konverziós eseményt lépésről lépésre?

Az üzleti definícióval kezdd, a kóddal folytasd, és mindig teszteléssel zárd. Vegyünk egy konkrét példát: egy szolgáltatói oldalon az ajánlatkérő űrlap sikeres beküldését akarod konverzióként mérni.

1. Definiáld, mi számít konverziónak

Nem a gombra kattintás, hanem a sikeres beküldés. Ez fontos különbség: a kattintás akkor is megtörténik, ha a validáció hibát dob, és ilyenkor felfelé torzul a konverziószámod.

2. Told be az eseményt az adatrétegbe

A fejlesztőd (vagy a form plugin beállítása) a sikeres beküldés visszaigazolásakor futtassa le ezt:

window.dataLayer = window.dataLayer || []; window.dataLayer.push({ 'event': 'ajanlatkeres_kesz', 'form_id': 'kapcsolat_fo', 'szolgaltatas': 'tetofelujitas' });

Az event kulcs kötelező, ez lesz a trigger neve a GTM-ben. A többi mező szabadon választott kontextus, amit később szegmentálásra használhatsz.

3. Hozd létre a változókat

A GTM felületén Variables, majd User-Defined Variable, típus: Data Layer Variable. A neve pontosan egyezzen a push-ban használt kulccsal (form_id, szolgaltatas). Kis- és nagybetű számít.

4. Készítsd el a triggert

Triggers, új trigger, típus: Custom Event, az esemény neve ajanlatkeres_kesz. Ha csak bizonyos oldalakon akarod, szűkítsd Page Path feltétellel.

5. Állítsd be a taget

Tags, új tag, típus: Google Analytics: GA4 Event. Event Name legyen beszédes és konzisztens (például generate_lead, ami a GA4 ajánlott eseménynevei között szerepel). Paraméterként add át a változókat. Triggerként válaszd az előző lépésben készítettet.

6. Teszteld Preview módban

A GTM Preview (Tag Assistant) funkciója egy külön ablakban nyitja meg az oldaladat, és mutatja, milyen események futottak le, melyik tag tüzelt, és milyen értékekkel. Küldj be egy valódi tesztűrlapot, és nézd meg: egyszer tüzelt-e a tag, és a paraméterek nem üresek-e. A GA4 DebugView-ban ellenőrizd, hogy az esemény meg is érkezett.

7. Publikálj és zárd le a kört

Publikálás után a GA4-ben jelöld kulcseseménynek (key event), és ha hirdetsz, importáld a Google Ads konverziók közé. Ez a lépés marad ki a leggyakrabban: a mérés működik, de a hirdetési fiók nem tud róla, így az ajánlattétel-optimalizálás vakon fut.

Mit kell tudni a hozzájárulás-kezelésről a GTM-ben?

Az EGT-ben futó hirdetési méréshez a Google hivatalos elvárása a Consent Mode v2 használata, ami két új jelet is tartalmaz: ad_user_data és ad_personalization.

A logika: a cookie banner megjelenése előtt beállítasz egy alapértelmezett (default) hozzájárulási állapotot, majd a látogató döntése után frissíted (update). A GTM-ben a legtöbb ismertebb hozzájárulás-kezelő rendelkezik hivatalos sablonnal, ezért a kézi megoldást csak akkor javaslom, ha nincs jobb.

Amit érdemes tudni (szakmai feltételezés a piaci gyakorlat alapján, nem jogi tanács): a modellezett konverziók pontossága függ a hozzájárulási arányoktól, ezért egy rosszul időzített banner nemcsak jogi kockázat, hanem mérési adatvesztés is. A banner megjelenítése előtt lefutó mérőkód mindkét szempontból problémás.

Milyen hibákat látni a leggyakrabban a GTM beállításnál?

A hibás adat legtöbbször nem a GTM működéséből, hanem a rossz konfigurációból jön. Ezekkel találkozom a leggyakrabban:

• Dupla mérés. A GA4 kód a sablonba is be van építve, és a GTM-ben is fut egy konfigurációs tag. Az eredmény: felezett munkamenet-hossz, torz visszafordulási arány.
• All Pages trigger a konverziós tagen. Klasszikus eset, amikor a köszönőoldal helyett minden oldalletöltés konverziót jelent.
• Köszönőoldal-alapú mérés ott, ahol nincs köszönőoldal. Az AJAX-os űrlapoknál nincs átirányítás, így az oldalletöltés-alapú trigger soha nem tüzel.
• Kattintás mérése beküldés helyett. Felfelé torzítja a konverziót, és rontja a hirdetési optimalizálást.
• Nem publikált konténer. A Preview módban minden működik, de a változtatás bent maradt piszkozatként.
• Belső forgalom kiszűrésének hiánya. Saját magad és a fejlesztőd tesztjei is bekerülnek az adatba.
• Beszélhetetlen elnevezések. A "Tag 7" és a "Trigger új2" fél év múlva senkinek nem mond semmit. Használj következetes névkonvenciót, például GA4 - Esemeny - ajanlatkeres.
• Verziók leírás nélkül. A GTM verziózik, de csak akkor tudsz visszalépni magabiztosan, ha tudod, melyik verzióban mi változott.

Hogyan ellenőrizd a GTM beállítást?

Egy jó ellenőrzés nem a felületen, hanem az oldalon zajlik: valódi tranzakciót vagy űrlapot kell végigvinned. Ellenőrzőlista publikálás előtt és után:

1. A GTM konténerkód a <head> elején és a <body> nyitása után is szerepel, minden sablonon.
2. Csak egy GTM konténer fut az oldalon (a Tag Assistant ezt kiírja).
3. A GA4 mérés vagy a natív kódból, vagy a GTM-ből jön, de nem mindkettőből.
4. Preview módban végigvitted a teljes útvonalat: nyitóoldal, szolgáltatásoldal, űrlap, visszaigazolás.
5. Minden konverziós tag pontosan egyszer tüzelt, a megfelelő ponton.
6. Az adatréteg-változók nem üresek, és nem undefined értéket adnak vissza.
7. A GA4 DebugView-ban megjelent az esemény a várt paraméterekkel.
8. A konverziós esemény kulceseményként meg van jelölve, és ha hirdetsz, importálva van a hirdetési fiókba.
9. A hozzájárulás megtagadása esetén a mérőkódok tényleg nem futnak le teljes körűen.
10. A belső IP-cím vagy a fejlesztői forgalom ki van szűrve.
11. A publikált verzió leírásában szerepel, mi változott és mikor.
12. 24-48 óra múlva visszanézed: a mért konverziók száma és a CRM-be érkező érdeklődések száma nagyságrendileg találkozik.

Az utolsó pont a legfontosabb. A mérés akkor jó, ha egy másik, független forrással (beérkezett e-mailek, CRM, telefonos naplózás) összevetve stimmel. Kis eltérés mindig lesz, ez normális, de kétszeres különbségnél biztosan van hiba valahol.

Mikor érdemes szerveroldali GTM-re gondolni?

Akkor, ha a böngészőoldali mérésben már mérhető adatvesztést látsz, és van kapacitásod a többletmunkára. A szerveroldali GTM lényege, hogy a mérési adat először a saját (vagy általad kezelt) szerverkonténerbe érkezik, és onnan megy tovább a különböző rendszerekbe.

Ez segítheti a mérés stabilitását olyan környezetben, ahol a böngészők korlátozzák a harmadik féltől származó sütiket, és jó eséllyel jobb adatminőséget ad a hirdetési platformoknak. Garanciát viszont nem jelent: a szerveroldali beállítás sem tudja visszahozni azt az adatot, amire nincs hozzájárulás. Kisebb oldalnál a többletköltség és a karbantartási igény miatt ez ritkán éri meg, jelentős hirdetési kiadásnál viszont gyakran indokolt.

Források és további olvasnivalók

• Google Tag Manager Help (hivatalos súgó)
• Google Tag Manager Developer Guide, Data Layer dokumentáció
• Google Analytics 4 Help: ajánlott események és kulcsesemények
• Google Ads Help: konverziókövetés és GA4 konverzióimport
• Google Consent Mode dokumentáció (Google Developers, Privacy and Consent)
• Google Tag Assistant dokumentáció
• Google Search Central dokumentáció (általános technikai háttér)
• W3C Web Performance ajánlások (a mérőkódok teljesítményhatásáról)