Egy GA4-fiók ritkán a mérőkódtól romlik el. Sokkal gyakrabban attól, hogy az eseménynevek néhány hónap alatt három ember fejében születnek meg: a fejlesztő beköti a saját nevén, az űrlap-bővítmény hoz egy sajátot, te pedig a Tag Managerben felveszel egy harmadikat. Az adat közben szépen gyűlik, a jelentés mégis használhatatlan, mert senki nem tudja megmondani, hogy a kapcsolat_kuldes és a form_submit_2 ugyanazt jelenti-e, vagy két különböző dolgot.
Miért válik kezelhetetlenné egy GA4-fiók három-négy hónap alatt?
Rövid válasz: mert a GA4-ben az eseménynév maga az adatszerkezet, és a már beérkezett adatban nem lehet megváltoztatni. Minden elgépelés, minden párhuzamos elnevezés véglegesen benne marad az előzményben.
Tovább a témában: Meta Pixel és konverziómérés · UTM-címkézési rend
A szétesés nem egyszerre történik. Az első hónapban két-három esemény van, mindenki fejből tudja, mit jelentenek. A harmadik hónapra egy átlagos KKV-fiók eseménylistája nagyjából így néz ki:
kapcsolat_kuldes: a fejlesztő kötötte be a köszönőoldalra, magyarul.urlap-ok: kötőjellel, ami nem is érvényes eseménynév.form_submit_2: valaki duplikálta a címkét, mert az első „nem működött”.Ajanlatkeres: nagy kezdőbetűvel, ezért a GA4 külön eseményként tartja számon.form_submit: a bővített mérés beépített eseménye, ami közben szintén fut.
Hivatalosan igazolt: a GA4 eseménynevei kis- és nagybetű-érzékenyek, tehát az Ajanlatkeres és az ajanlatkeres két külön esemény. A név csak betűt, számot és alulvonást tartalmazhat, betűvel kell kezdődnie, és hossza korlátozott (a súgó szerint 40 karakter). A ga_, google_ és firebase_ előtag fenntartott, ezekkel kezdődő saját nevet a rendszer nem fogad el.
A gyakorlati kár nem az, hogy csúnya a lista. Az, hogy öt sorból kell összeadni egy számot, és senki nem meri kimondani, melyik ötből. Ha közben valaki kulcseseménnyé is tett kettőt, a Google Ads oldalán duplán számolódik ugyanaz a kitöltés, ami a licitálásra is kihat. Saját tapasztalat: átvett fiókoknál a leggyakoribb hiba nem a hiányzó mérés, hanem a többszörös, egymást átfedő mérés, és ezt utólag már csak becsléssel lehet szétszálazni.
Mi számít eseménynek, és mi paraméternek?
Rövid válasz: az esemény azt mondja meg, hogy mi történt, a paraméter azt, hogy milyen körülmények között. Az esemény a sor, a paraméter az oszlop.
Ha ezt a két szintet összekevered, robbanni fog az eseménylista. Az ajanlatkeres_fooldal, ajanlatkeres_szolgaltatas, ajanlatkeres_kapcsolat hármas helyett egyetlen esemény kell, form_location paraméterrel. Így az összesített szám és a bontás is egy helyről jön.
Hivatalosan igazolt: egy eseményhez legfeljebb 25 paraméter tartozhat, és a saját paraméter csak akkor jelenik meg a szabvány jelentésekben, ha egyedi dimenzióként (custom dimension) regisztrálod. A regisztráció nem visszamenőleges: az adat csak a beállítás napjától látszik a riportokban. Ez az egyik legdrágább félreértés a GA4 körül, mert a paraméter ott van a nyers adatban, de a jelentésben hetekig nem, és emiatt sokan újra beépítik ugyanazt.
Milyen konvenciót érdemes felvenni?
Rövid válasz: kisbetű, alulvonás, ige_tárgy szerkezet az eseményeknél, főnév_tulajdonság szerkezet a paramétereknél, és minden érték normalizálva.
Kisbetű és alulvonás, kivétel nélkül
Nincs nagybetű, nincs kötőjel, nincs szóköz, nincs ékezet. Ez nem esztétikai kérdés: a kötőjel érvénytelen karakter, a nagybetű pedig új eseményt hoz létre. Az ékezetes karakter az eseménynévben elkerülendő, a paraméter értékében viszont megengedett, ha ott is következetes maradsz.
Ige_tárgy szerkezet
Az esemény cselekvést ír le, ezért igével kezdődik: generate_lead, click_phone, download_pricelist, book_appointment. Ez nem önkényes: a Google saját ajánlott eseményei is így épülnek fel (view_item, add_to_cart, select_promotion), tehát ha ugyanezt a mintát követed, a saját és a beépített események egy logika szerint olvashatók. A tárgy egyes számban áll, és soha nem kerül bele a hely, az eszköz vagy a variáns, mert az mind paraméter.
A paramétereknek külön névtere van
A paraméter nem cselekvés, ezért soha nem igével kezdődik, hanem az entitás nevével: form_id, form_location, lead_type, service_name, file_name, contact_point. Így ránézésre eldönthető, hogy egy név eseményt vagy paramétert takar. Érdemes egy szűk, zárt paraméter-készletet tartani, amit több esemény újrahasznál: a form_location ugyanazt jelentse az ajánlatkérőn és a visszahívás-kérőn is.
Külön névteret érdemes adni a dataLayer-eseményeknek is, mert azok nem azonosak a GA4 eseményneveivel. A Tag Manager trigger-listája sokkal olvashatóbb marad, ha a küldött objektum így néz ki:
dataLayer.push({event: 'ga4_generate_lead', form_id: 'ajanlatkero_fooldal', form_location: 'fooldal_hero', lead_type: 'arajanlat'});
A ga4_ előtag csak a GTM-en belül él, a GA4-be már a tiszta generate_lead megy fel.
Az értékek is konvenció alá esnek
A paraméter értéke ugyanúgy kis- és nagybetű-érzékeny. Az Ajánlatkérés és az ajanlatkeres két külön sor lesz a jelentésben. Döntsd el előre: minden érték kisbetűs, ékezet nélküli, alulvonással tagolt, és rögzített szótárból jön.
Magyarul vagy angolul nevezd el az eseményeket?
Rövid válasz: mindegy, melyiket választod, de csak az egyiket szabad. A kevert lista minden jelentésben megbosszulja magát.
Szakmai feltételezés: a legtöbb magyar KKV-fióknál az angol névadás a kevesebb súrlódással járó út, mert a GA4 automatikusan gyűjtött és ajánlott eseményei angolul érkeznek (page_view, session_start, file_download, form_submit, purchase). Ha melléjük magyar neveket teszel, az ábécésorrendbe rendezett eseménylistában a saját és a beépített események összekeverednek, és minden új kollégának el kell magyarázni, hogy a kapcsolat_kuldes a generate_lead magyar párja.
Ha az ügyfél nem beszél angolul, és ő is nézi a jelentést, a magyar névadás védhető döntés. Ilyenkor viszont a beépített angol eseményeket ne próbáld magyarítani, hanem a dokumentumban vezess mellé egy magyar leírást. Ami nem működik: a féllel elkezdett magyarítás, ahol a telefon_kattintas mellett ott van a download_pricelist.
Hogyan néz ki egy tízsoros minta a leggyakoribb KKV-eseményekre?
Ez a tíz sor a szolgáltató KKV-k eseményeinek jó részét lefedi. Minden sor: eseménynév, mikor tüzel, milyen paraméterek kötelezők hozzá.
generate_lead: ajánlatkérő űrlap sikeres beküldése (köszönőoldal vagy visszaigazolt AJAX-válasz). Paraméterek:form_id,form_location,lead_type. Kulcsesemény.submit_callback: visszahívás-kérő űrlap sikeres beküldése. Paraméterek:form_id,form_location,preferred_time. Kulcsesemény.click_phone:tel:hivatkozásra kattintás. Paraméterek:contact_point,link_url,page_type. Kulcsesemény.click_email:mailto:hivatkozásra kattintás. Paraméterek:contact_point,link_url,page_type. Kulcsesemény.download_pricelist: árlista vagy katalógus PDF letöltése. Paraméterek:file_name,file_extension,file_category. Kulcsesemény.view_pricelist: az árlista blokk vagy oldal tényleges megtekintése (láthatóság-alapú trigger). Paraméterek:page_type,content_group.open_chat: chat vagy üzenetküldő gomb megnyitása. Paraméterek:contact_point,chat_provider,page_type.click_map: térkép vagy útvonaltervező hivatkozás kattintása. Paraméterek:contact_point,location_id.select_service: szolgáltatás kiválasztása kalkulátorban vagy szűrőben. Paraméterek:service_name,service_category.book_appointment: időpontfoglalás visszaigazolva. Paraméterek:booking_type,service_name,location_id. Kulcsesemény.
Két ütközésre figyelj a mintánál. A bővített mérés (enhanced measurement) alapból küld file_download, form_start és form_submit eseményt is. Ha te is bekötsz egy sajátot ugyanarra a kattintásra, kétszer méred ugyanazt. A döntést (a beépítettet használod, vagy kikapcsolod és sajátot építesz) írd bele a dokumentumba, mert ez a kérdés fél évvel később már senkinek nem lesz nyilvánvaló.
Mit kell rögzíteni még a bevezetés előtt?
Rövid válasz: mindent, ami a névből nem derül ki. Ez a cikk saját nézőpontja: a mérési terv nem a bevezetés utáni dokumentáció, hanem a bevezetés feltétele, mert a GA4-ben a történeti adatot nem lehet átnevezni.
Egy táblázat is elég hozzá, de legyen benne minden eseményre:
- eseménynév pontosan úgy, ahogy menni fog;
- egy mondatos, félreérthetetlen definíció arról, mikor tüzel és mikor nem;
- a kötelező és opcionális paraméterek, értékkészlettel együtt;
- kulcsesemény-e, és importálva van-e a hirdetési fiókba;
- hol van megvalósítva (GTM-címke neve, bővítmény, forráskód);
- regisztrálva van-e egyedi dimenzióként, és mikortól;
- ki a felelőse, mikor került élesbe, és melyik verzió ez.
Saját tapasztalat: az a szakasz, ami a leggyakrabban hiányzik, a definíció. Az generate_lead névből nem derül ki, hogy a spam-szűrőn átment kitöltésre tüzel-e, vagy minden gombnyomásra. Fél év múlva pontosan ez lesz a vita tárgya, amikor a GA4 és a CRM száma nem egyezik.
Hogyan nevezz át egy élő eseményt anélkül, hogy elveszne az előzmény?
Rövid válasz: sehogy, ha az „előzmény” alatt azt érted, hogy a régi adat visszamenőleg az új néven jelenik meg. Amit el lehet érni: hogy a váltás dokumentált, egyértelmű és összefésülhető legyen. Ez az ellenőrzőlista ehhez való.
- Írd le, mit nyersz vele. Ha csak szebb lesz a név, de a jelentés ugyanaz, hagyd békén. Az átnevezésnek ára van, és az árat mindig az idősor fizeti meg.
- Mentsd ki a régi adatot, mielőtt bármihez hozzányúlnál. Exportáld a régi eseménynév havi bontású számait, és tedd az átvezetési tábla mellé. Ha van BigQuery-export, a nyers adat ott hosszabb távon is megmarad.
- Vezess átvezetési (mapping) táblát: régi név, új név, a váltás dátuma, ok, felelős. Ez a tábla lesz az egyetlen hely, ahol két év múlva is kiderül, miért törik ketté a grafikon.
- Használd az adminfelület Esemény módosítása (Modify event) funkcióját, ha a régi nevet a beérkezéskor akarod átírni az újra. Hivatalosan igazolt: ez a szabály a beérkező adatra hat, a korábban gyűjtött adatot nem írja át.
- Ne mérd sokáig párhuzamosan mindkét néven. Ha mégis szükség van rövid átfedésre a hitelesítéshez, tudd, hogy közben az összes esemény száma felfelé torzul, és a mérés csak a legszükségesebb ideig menjen így.
- Kulcseseménynek soha ne állítsd be egyszerre a régi és az új nevet. Ez a leggyorsabb út a duplán számolt konverzióhoz.
- Nézd végig, mi épül a régi névre: közönségek, egyedi dimenziók, felfedezések, szegmensek, Looker Studio jelentések, GTM-triggerek, hirdetési konverzióimport. Mindegyiket át kell vezetni, és a listát előre készítsd el, ne futás közben.
- A hirdetési oldalt kezeld külön kockázatként. Szakmai feltételezés: ha a kulcsesemény neve változik, a hirdetési fiókban jó eséllyel új konverzióművelet jön létre, a régi pedig elapad. Ez az intelligens licitálás tanulására is kihathat, ezért az átvezetést érdemes a hirdetéskezelővel egyeztetve, nem kampányindítás közben elvégezni.
- A riportokban az átmeneti időszakot reguláris kifejezéssel fésüld össze, például az eseménynévre illesztett
^(regi_nev|uj_nev)$szűrővel. Ez nem javítja meg az adatot, de egy grafikonon láthatóvá teszi a folytonosságot. - Zárd a műveletet változásnaplóval: dátum, ki csinálta, mi változott, honnan meddig érvényes a régi név. A jelentések tetejére tegyél egy megjegyzést a váltás dátumáról, hogy a nézője ne az adatot hibáztassa.
Milyen korlátokkal érdemes előre számolni?
Rövid válasz: a GA4 nem végtelen, és a korlátokba pont a rendezetlen fiókok futnak bele. Hivatalosan igazolt nagyságrendek a standard tulajdonban: property-nként 500 különböző nevű esemény, eseményenként 25 paraméter, 50 esemény-hatókörű és 25 felhasználó-hatókörű egyedi dimenzió, 40 karakteres név- és 100 karakteres értékhossz. A pontos számok idővel változhatnak, ezért éles beállítás előtt mindig nézd meg a súgó aktuális oldalát.
Ezek a keretek egy tiszta, tíz-tizenöt eseményes KKV-mérésnél kényelmesen elegendők. Akkor fogynak el, ha a helyet, a variánst és a nyelvet is a névbe építed, mert onnantól minden új aloldal új eseményt szül. A konvenció tehát nem adminisztratív luxus: ez tartja a fiókot a saját korlátain belül.
Ha most kezded, a legolcsóbb lépés egy egyoldalas dokumentum a tíz eseményről, mielőtt az első címke élesbe megy. Ha már fut a mérés, akkor egy leltár: mi tüzel valójában, melyik névhez tartozik értelmes definíció, és mi az a kettő-három átnevezés, ami tényleg megéri az idősor törését.
Források és további olvasnivalók
- Google Analytics Súgó: Események a Google Analytics 4-ben (automatikusan gyűjtött, bővített mérési, ajánlott és egyedi események)
- Google Analytics Súgó: Egyedi dimenziók és mutatók beállítása
- Google Analytics Súgó: Események módosítása és létrehozása (Modify event, Create event)
- Google Analytics Súgó: Adatgyűjtési és -konfigurációs korlátok
- Google Analytics Developers: gtag.js és Measurement Protocol eseményreferencia
- Google Analytics Developers: BigQuery Export séma
- Google Tag Manager Súgó: adatréteg (dataLayer) és triggerek
- Google Ads Súgó: Analytics-kulcsesemények importálása konverzióként
- Google Search Central: dokumentáció a technikai mérés és a felhasználói élmény kapcsolatáról
- A GA4 eseménynevei kis- és nagybetű-érzékenyek, és a történeti adatban nem nevezhetők át, tehát minden elgépelés véglegesen benne marad a fiókban.
- Egy működő konvenció négy döntésből áll: kisbetű, alulvonás, ige_tárgy szerkezet és a paraméterek külön, főnév_tulajdonság alakú névtere.
- Magyar vagy angol névadás közül bármelyik jó, de csak az egyik: mivel a GA4 saját eseményei angolok, a kevert lista nehezíti a riportolást.
- Az eseményparaméter csak akkor jelenik meg a jelentésekben, ha egyedi dimenzióként regisztrálod, és a regisztráció nem visszamenőleges.
- Átnevezés előtt kell mentés, párhuzamos futás és átvezetési tábla, különben a régi és az új név két külön, összefésülhetetlen idősor marad.
Gyakori kérdések
Át lehet nevezni egy GA4 eseményt visszamenőleg?
Nem. A GA4 a már beérkezett adatot a gyűjtéskori néven tárolja, és ezt utólag nem lehet átírni. Az adminfelület Esemény módosítása funkciója csak a beállítás után beérkező eseményekre hat, ezért érdemes a nevet a bevezetés előtt dokumentumban rögzíteni.
Számít, hogy kis- vagy nagybetűvel írom az eseménynevet?
Igen, a GA4 eseménynevei kis- és nagybetű-érzékenyek, tehát az Ajanlatkeres és az ajanlatkeres két külön esemény, két külön idősorral. Ezért szól a konvenció csupa kisbetűről és alulvonásról, kivétel nélkül.
Miért nem látom a saját paraméteremet a jelentésekben?
Mert a saját eseményparaméter csak akkor jelenik meg a szabvány jelentésekben, ha egyedi dimenzióként regisztrálod. A regisztráció nem visszamenőleges: az adat a beállítás napjától kezdve látszik, a korábbi időszakra nem töltődik vissza.
Magyar vagy angol eseményneveket használjak?
Bármelyik működik, de következetesen csak az egyik. Mivel a GA4 automatikus és ajánlott eseményei angolok, az angol névadás általában kevesebb súrlódással jár; ha magyarul nevezel el, a beépített angol eseményeket akkor se magyarítsd, hanem magyar leírást tegyél melléjük a dokumentumban.
Hány eseményt bír el egy GA4 tulajdon?
A súgó szerint tulajdonságonként 500 különböző nevű esemény, eseményenként legfeljebb 25 paraméter, és 50 esemény-hatókörű egyedi dimenzió a standard keret. Ez tiszta szerkezetnél bőven elég; akkor fogy el, ha a helyet és a variánst is a névbe építed a paraméter helyett.
Mi a legnagyobb kockázat egy kulcsesemény átnevezésénél?
A hirdetési oldal. Névváltásnál jó eséllyel új konverzióművelet keletkezik, a régi pedig elapad, ami kihathat az intelligens licitálás tanulására. Ezért az átnevezést érdemes a hirdetéskezelővel egyeztetve, nem kampányindítás vagy szezoncsúcs idején elvégezni.
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.