dataLayer specifikáció fejlesztőnek: hogyan kérd meg úgy, hogy elsőre jó legyen

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

Miért nem elég azt kérni a fejlesztőtől, hogy „mérjük az űrlapot”?

Ez a mondat öt-hat döntést hagy nyitva, és a fejlesztő mindegyiket a saját logikája szerint hozza meg. Mi számít mérendő eseménynek, a gombra kattintás vagy a sikeres beküldés? Milyen néven érkezzen az esemény? Kell-e mellé az űrlap azonosítója, a kiválasztott szolgáltatás, egy becsült érték? Mi történjen, ha a validáció elbukik? A fejlesztő ezekre ésszerű, de tőled független válaszokat ad, és hogy ezek megfelelnek-e neked, az csak a GA4-riportban vagy a hirdetési konverzióknál derül ki, sokszor hetekkel később.

Saját tapasztalat. Átvételkor a leggyakrabban azt látjuk, hogy az esemény a gomb megnyomására tüzel, így a hibás vagy félbehagyott kitöltés is konverziónak számít. A második leggyakoribb hiba, hogy ugyanaz az esemény oldalanként más néven jön (form_submit, formSubmit, ajanlatkeres), és a GTM-ben egyik trigger sem kapja el mindet. Mindkettő megelőzhető egy írott specifikációval, amely ezekre a kérdésekre előre válaszol.

Mi a dataLayer, és mit kell róla tudnia a marketingesnek?

A dataLayer egy JavaScript-tömb az oldalon. A weboldal kódja üzeneteket tesz bele, a Google Tag Manager pedig ezekből olvas, és ezek alapján indítja el a címkéket.

Hivatalosan igazolt. A Google Tag Manager dokumentációja szerint az adatréteget a window.dataLayer = window.dataLayer || []; sor hozza létre, új adatot pedig a dataLayer.push() hívással adunk hozzá. Ha a push tartalmaz egy event kulcsot, a GTM-ben az azonos nevű egyéni esemény (Custom Event) trigger reagálni tud rá, a többi kulcsot pedig adatréteg-változóval (Data Layer Variable) olvassuk ki. A GA4 szabályai szerint az eseménynév betűvel kezdődik, csak betűt, számot és aláhúzást tartalmazhat, és legfeljebb 40 karakter hosszú.

A marketingesnek ebből három dolog fontos. A fejlesztő az adat átadásáért felel, a GA4-be vagy a hirdetési fiókba küldést te állítod be a GTM-ben. Az esemény neve és a kulcsok nevei szerződésként működnek, és ha valamelyik megváltozik, a mérés csendben leáll. Végül a dataLayer tartalma bárki számára látható a böngésző konzoljában, ezért személyes adat nem kerülhet bele.

Milyen elemekből áll egy jól megírt dataLayer specifikáció?

Egy jó specifikáció minden eseményhez megadja a nevet, a pontos kiváltó pillanatot, a paraméterek listáját típussal és kötelezőséggel, és egy bemásolható példa-kódot. Ha ezek közül bármelyik hiányzik, a fejlesztőnek találgatnia kell.

1. Eseménynév. Kisbetűs, aláhúzással tagolt angol név (snake_case). Ahol a GA4-nek van ajánlott eseménye, használd azt (generate_lead, add_to_cart), mert a riportok egy része ezekre a nevekre épül.
2. Mikor tüzel. Egy mondat, ami kizárja a félreértést, például „a szerver sikeres válasza után, a köszönőüzenet megjelenésekor, egyszer”. Írd le azt is, mikor nem tüzelhet (validációs hiba, dupla kattintás, oldalfrissítés).
3. Paraméterek. Táblázatszerűen a név, az adattípus, a kötelező vagy opcionális jelölés, egy példaérték és a megengedett értékek.
4. Adattípus. A szám legyen szám (2), a szöveg szöveg ('HUF'). A szóközzel tagolt, idézőjelbe tett összeg szövegnek számít, és a GA4-ben nem összegezhető.
5. Példa push-kód. Konkrét értékekkel, pontosan úgy, ahogy a böngészőben meg kell jelennie.
6. Előfordulás. Azoknak az oldalaknak vagy sablonoknak a listája, ahol az eseménynek tüzelnie kell.
7. Átvételi feltétel. Az, ami alapján kimondod, hogy a munka kész.

Szakmai feltételezés. A specifikáció egyetlen közös dokumentumban (táblázatban vagy wiki-oldalon) működik a legjobban, verziószámmal és dátummal. Ha a fejlesztő e-mailből, chatüzenetből és hívásjegyzetből rakja össze a feladatot, jó eséllyel kimarad valami.

Hogyan néz ki egy dataLayer sablon lead-űrlapra?

A lead-űrlapnál az a lényeg, hogy az esemény csak sikeres beküldés után, egyszer tüzeljen, és azonosítsa, melyik űrlapról jött a megkeresés.

A generate_lead esemény specifikációja

• Mikor tüzel. Amikor a szerver visszaigazolta a beküldést, és a felhasználó a köszönőüzenetet vagy a köszönőoldalt látja. Validációs hibánál, sikertelen küldésnél és a köszönőoldal frissítésekor nem tüzel.
• form_id (string, kötelező). Az űrlap állandó azonosítója, például 'ajanlatkeres_fooldal'. Ne a keretrendszer által generált, időnként változó azonosító legyen.
• form_name (string, kötelező). Ember által olvasható név, például 'Ajánlatkérés'.
• lead_type (string, opcionális). Előre rögzített értékek közül egy, például 'ajanlat', 'visszahivas' vagy 'idopont'.
• service (string, opcionális). A legördülő menüben választott szolgáltatás kódja, ha van ilyen mező.
• value (number, opcionális) és currency (string, kötelező, ha van value). Becsült lead-érték, ha a marketingcsapat dolgozik ilyennel. A pénznem háromjegyű ISO 4217 kód.

A példa push-kód a sikeres válasz ágában.

window.dataLayer = window.dataLayer || []; dataLayer.push({ event: 'generate_lead', form_id: 'ajanlatkeres_fooldal', form_name: 'Ajánlatkérés', lead_type: 'ajanlat', service: 'weboldal_karbantartas' });

Hivatalosan igazolt. A Google Analytics szabályai tiltják, hogy személyazonosításra alkalmas adat (név, e-mail-cím, telefonszám) kerüljön a mérésbe. A specifikációba ezért írd bele kifejezetten, hogy a beírt mezőértékek nem kerülhetnek a dataLayerbe. A hirdetési rendszerek bővített konverziójának saját, dokumentált beállítási módja van, ezt ne keverd az általános eseménnyel.

Saját tapasztalat. Oldalújratöltés nélküli (AJAX-os) űrlapoknál a GTM beépített űrlapküldés-triggere gyakran nem jelez, vagy a sikertelen próbálkozást is elkapja. Ilyenkor a fejlesztő által a sikeres válasz ágába tett push a megbízható megoldás.

Hogyan néz ki egy dataLayer sablon kosárba helyezésre?

Kosárba helyezésnél a GA4 ajánlott add_to_cart eseményét és annak ecommerce objektumát érdemes követni, mert a webshop-riportok erre a szerkezetre épülnek.

Hivatalosan igazolt. A GA4 e-kereskedelmi dokumentációja szerint az add_to_cart eseménynél a currency, a value és az items tömb a meghatározó paraméterek, és minden tételnél meg kell adni az item_id vagy az item_name közül legalább az egyiket. A Google azt is javasolja, hogy egy új e-kereskedelmi esemény előtt a kód ürítse az előző ecommerce objektumot, különben a korábbi esemény adatai átkerülhetnek az újba.

Az add_to_cart esemény specifikációja

• Mikor tüzel. Amikor a termék ténylegesen bekerült a kosárba, vagyis a kosár-végpont sikeres válasza után. A terméklapon, a listanézetben és a gyorsnézetben egyaránt. Ha a felhasználó a kosárban növeli a darabszámot, az is add_to_cart, a hozzáadott mennyiséggel.
• ecommerce.currency (string, kötelező). ISO 4217 kód.
• ecommerce.value (number, kötelező). A hozzáadott tételek összértéke, vagyis az egységár és a mennyiség szorzata, pénznemjel nélkül.
• items[].item_id (string, kötelező). Ugyanaz a cikkszám, ami a termékfeedben szerepel.
• items[].item_name (string, kötelező a mi specifikációnkban). A vásárló által is látott terméknév, változat nélkül.
• items[].price (number, kötelező) és items[].quantity (egész szám, kötelező).
• items[].item_variant, item_brand, item_category (string, opcionális).

A példa push-kód, az ürítéssel együtt. A számok csak illusztrációk.

dataLayer.push({ ecommerce: null }); dataLayer.push({ event: 'add_to_cart', ecommerce: { currency: 'HUF', value: 25980, items: [{ item_id: 'SKU-1042', item_name: 'Kerámia bögre', item_variant: 'kék', price: 12990, quantity: 2 }] } });

Saját tapasztalat. Ha a feedben szereplő azonosító eltér a dataLayer item_id értékétől, a hirdetési rendszerek gyakran nem tudják a konverziót a termékhez kötni. Ezt egy mondattal rögzíteni a specifikációban sokkal kevesebb munka, mint utólag kideríteni. Akciós terméknél írd le azt is, hogy a price a ténylegesen fizetendő egységár legyen, mert erre a fejlesztő magától ritkán kérdez rá.

Milyen kérdéseket tegyen fel a fejlesztő az átvételkor?

A jó átvétel kérdésekkel kezdődik. Ha a fejlesztő nem kérdez, add át neki ezt a listát, mert a válaszok a legtöbb későbbi hibát előre kiszűrik.

• Pontosan melyik pillanatban tüzeljen az esemény, a böngészőben futó validáció után vagy a szerver válasza után?
• Mi történik, ha a felhasználó kétszer kattint, vagy frissíti a köszönőoldalt?
• Minden űrlapra (hírlevél, kapcsolat, ajánlatkérés, felugró ablak) kell az esemény, vagy csak a listában szereplőkre?
• Honnan jön a paraméter értéke, és mi legyen, ha üres? Üres szöveg, undefined, vagy kimarad a kulcs?
• Van-e az oldalon már meglévő dataLayer-használat (bővítmény, téma, webshopmotor), amivel az új push ütközhet?
• A sütikezelő eszköz befolyásolja-e a push-t, vagy az esemény minden esetben bekerül, és a hozzájárulást a GTM kezeli?
• Melyik környezetben (fejlesztői, teszt, éles) lehet tesztelni, és ott ugyanaz a GTM-tároló fut-e?
• Ki szól, ha később megváltozik az űrlap vagy a kosár kódja?

Szakmai feltételezés. A hozzájárulásnál általában az a legtisztább felállás, ha a dataLayer-push mindig megtörténik, és a címkék viselkedéséről a Google hozzájárulási mód (Consent Mode) és a GTM beállításai döntenek. Ez sütikezelőnként eltérhet, ezért a választ az adott eszköz dokumentációja alapján érdemes meghozni.

Hogyan teszteld az átadást a GTM előnézeti módjában?

Az átvétel akkor kész, ha a GTM előnézeti módjában (Tag Assistant) minden esemény a megadott néven, a megadott pillanatban, egyszer és helyes adattípusú paraméterekkel jelenik meg, és a hozzá tartozó címke elindul.

Hivatalosan igazolt. Az előnézeti mód a bal oldali idővonalon listázza a dataLayer üzeneteit. Eseményenként megmutatja, mely címkék indultak el és melyek nem, a Változók és az Adatréteg (Data Layer) fülön pedig az adott pillanatban érvényes értékeket látod.

Az átvételi tesztlistát lépésenként érdemes végigvinni.

1. Nyisd meg az előnézetet a tesztelendő URL-lel, és ellenőrizd, hogy a Tag Assistant csatlakozott.
2. Töltsd ki az űrlapot hibásan, és küldd be. Az idővonalon nem jelenhet meg generate_lead.
3. Töltsd ki helyesen. Pontosan egy generate_lead jelenjen meg, a köszönőüzenettel egy időben.
4. Kattints az eseményre, nyisd meg az Adatréteg fület, és vesd össze minden kulcs nevét és értékét a specifikációval, betűre.
5. Ellenőrizd a típusokat. A szám idézőjel nélkül jelenik meg, a szöveg idézőjelben.
6. Nézd meg, hogy egyik paraméterbe sem került név, e-mail-cím vagy telefonszám.
7. Frissítsd a köszönőoldalt, és nyomd meg kétszer gyorsan a küldés gombot. Egyik sem okozhat második eseményt.
8. Kosárnál adj hozzá egy terméket a terméklapról, egyet a listanézetből, és egy több változatú terméket másik változattal. Mindháromnál nézd meg az items tömböt, és azt, hogy előtte megjelent-e az ecommerce ürítése.
9. Számold utána, hogy a value egyezik az ár és a mennyiség szorzatával.
10. A Címkék nézetben ellenőrizd, hogy a GA4- és a hirdetési címke az eseményre elindult, máshol pedig nem.
11. A GA4 DebugView nézetében nézd meg, hogy az esemény a paraméterekkel együtt beérkezett.
12. Ismételd meg mobilon is, ha a mobilos űrlap vagy kosár külön kódot használ.

Saját tapasztalat. A tesztet érdemes képernyőképekkel dokumentálni, és a specifikáció mellé tenni. Ha hónapok múlva eltűnnek a konverziók, ebből gyorsan kiderül, mi változott az átadás óta.

Mit írj még bele, hogy a mérés hosszú távon is működjön?

A specifikációt élő dokumentumként érdemes kezelni, verziókövetéssel, felelősökkel és rögzített névkonvencióval, mert a mérési hibák nagy része egy későbbi weboldal-módosításnál keletkezik.

• Rögzítsd a névkonvenciót (snake_case, angol nevek, ajánlott GA4-eseménynév, ahol van ilyen).
• Minden eseményhez tartozzon egy felelős a fejlesztői és egy a marketing oldalon.
• Kérd, hogy téma- vagy bővítménycsere és nagyobb frissítés után a fejlesztő jelezzen, és a tesztlistát fussátok újra.
• A GTM-ben a változókat a specifikáció kulcsneveivel nevezd el, így egy átnézésnél azonnal látszik az összefüggés.

Szakmai feltételezés. Egy jól megírt specifikáció nem garantál hibátlan mérést, de jó eséllyel lerövidíti az átadást, és a hibákat még az élesítés előtt hozza felszínre, amikor a javításuk a legkisebb munka.

Források és további olvasnivalók

• Google Tag Manager fejlesztői dokumentáció, The data layer
• Google Analytics súgó, ajánlott események (GA4)
• Google Analytics fejlesztői dokumentáció, e-kereskedelmi mérés (GA4)
• Google Analytics súgó, eseménygyűjtési korlátok és elnevezési szabályok
• Google Analytics súgó, a személyazonosításra alkalmas adatokra vonatkozó irányelvek
• Google Tag Manager súgó, előnézeti és hibakereső mód (Tag Assistant)
• Google fejlesztői dokumentáció, hozzájárulási mód (Consent Mode)
• ISO 4217 pénznemkód-szabvány