Egy esemény átnevezése a mérésben apró módosításnak tűnik, mégis ebből lesz utólag a legtöbb fejtörés. A form_submit helyett az ajanlatkeres_kuldes beszédesebb, jobban illik a mérési tervbe, és a kollégák is értik. A riportod viszont attól a naptól két külön eseményt lát, és a kettő között semmilyen automatikus kapcsolat nincs. Ebben a cikkben végigmegyünk azon, mi törik el ilyenkor, milyen sorrendben érdemes átállni, és hogyan dokumentáld úgy, hogy fél év múlva is értsd, mi történt.
A kiinduló álláspontom egyszerű. Az átnevezés mindig tudatos vágás az idősorban. Varratmentessé nem tudod tenni, ezért a cél az, hogy a vágás látható, dátumozott és visszakereshető legyen. Aki elrejti, az a következő negyedéves riportnál magyarázkodni fog egy nem létező visszaesés miatt.
A cikkben három jelölést használok. Hivatalosan igazolt, ha a Google vagy a Meta dokumentációja írja le. Saját tapasztalat, ha mérési projektekben rendszeresen így láttuk. Szakmai feltételezés, ha logikus következtetés, de nincs rá hivatalos megerősítés.
Mi történik pontosan, ha átnevezel egy régóta gyűjtött eseményt?
Az új név új eseményként indul nulláról, a régi név alatt gyűjtött adat pedig a régi néven marad. A Google Analytics 4 visszamenőleg nem nevezi át a már feldolgozott adatot, így az idősor két darabra esik, és minden riport, szűrő vagy import, ami a régi névre épült, onnantól üresen fut.
Hivatalosan igazolt. A GA4 az eseményneveket kis- és nagybetű-érzékenyen kezeli, tehát a Lead_Submit és a lead_submit két külön eseménynek számít. Az adminisztrációs felületen elérhető eseménymódosítás és eseménylétrehozás csak a beállítás után beérkező adatra hat, a már begyűjtött adatot nem írja át. Egy eseménynév legfeljebb 40 karakter lehet, és vannak foglalt nevek, amelyeket nem használhatsz.
A gyakorlatban a vágás egyszerre több helyen jelenik meg.
- Standard riportok és feltárások. Az eseménynévre szűrt táblák a váltás napjától nullát mutatnak, az új név pedig előzmény nélkül jelenik meg.
- Kulcsesemények. A jelölés a névhez kötődik, így a konverziós arány látszólag összeomlik.
- Hirdetési importok. A Google Ads-be importált konverziós művelet nem kap több adatot.
- Közönségek. Az eseményre épülő remarketing-listák nem töltődnek tovább, és lassan kiürülnek.
- BigQuery export és Looker Studio. Minden lekérdezés, ami a régi nevet keresi, csendben kevesebb sort ad vissza.
Ez utóbbi a legveszélyesebb, mert hibaüzenet nincs, csak kisebb szám.
Miért válnak ketté a riportok és a kulcsesemények?
A GA4 minden jelölést, szűrőt és importot a pontos eseménynévhez köt, ezért az átnevezés után a régi és az új név két független sorként él tovább. Az összesített konverziós szám csak akkor folytonos, ha a riportban kifejezetten összefűzöd a kettőt.
Hivatalosan igazolt. A kulcsesemény-jelölés eseménynévre szól. Az új nevet külön meg kell jelölnöd kulcseseményként (akár előre, mielőtt az első találat beérkezik), és ez a jelölés sem hat visszamenőleg. A standard tulajdonságokban a jelölhető kulcsesemények száma korlátozott, ezért a régi név jelölését a kivezetés végén érdemes levenni.
Saját tapasztalat. A leggyakoribb tünet, hogy valaki a váltás utáni héten jelzi, hogy leesett a konverzió. Közben a látogatók ugyanúgy küldik az űrlapot, csak a jelölés a régi néven maradt, az új név pedig kulcsesemény nélkül gyűlik. A második leggyakoribb eset ennek a fordítottja. Mindkét név kulcsesemény, a párhuzamos gyűjtés alatt mindkettő érkezik, és a konverziószám hirtelen megduplázódik.
A feltárásokban (Explorations) és a Looker Studióban minden olyan szegmens, szűrő vagy számított mező, ami eseménynévre hivatkozik, kézi átírást igényel. Ezeket a GA4 nem listázza ki neked, ezért a leltárt magadnak kell elkészíteni.
Hogyan érinti az átnevezés a Google Ads és a Meta konverzió-importot?
A hirdetési rendszerek egy konkrét eseménynévből vagy kulcseseményből kapják a konverziót, így az átnevezés után a régi konverziós művelet elnémul, az újat pedig külön be kell kötni. Ha az ajánlattételi stratégia erre a műveletre optimalizál, a jelvesztés a kampány teljesítményén is meglátszhat.
Hivatalosan igazolt. A Google Ads a GA4-ből importált konverziós műveletet egy adott kulcseseményhez köti. Új eseménynévhez új importot kell létrehozni. A Google Ads-ben minden konverziós műveletnél beállítható, hogy elsődleges vagy másodlagos legyen. Az ajánlattétel az elsődleges műveletekre optimalizál, a másodlagosakat csak megfigyelésre használja.
Szakmai feltételezés. Ha egy automatikus ajánlattételi stratégia egyik napról a másikra egy teljesen új, előzmény nélküli konverziós műveletre vált, a rendszernek újra kell tanulnia. Emiatt átmenetileg ingadozhat a költés és a konverziószám. Ennek mértéke fiókonként eltér, előre nem lehet megmondani.
Saját tapasztalat. A Meta oldalon az egyéni konverziók és a kampányok optimalizálási eseménye szintén névhez kötődik. Ha a pixel vagy a Conversions API egyéni eseményének nevét módosítod, az erre épülő egyéni konverzió nem kap több adatot, és a hirdetéskezelőben ez sokszor csak napokkal később tűnik fel.
Mi a biztonságos átállási sorrend?
A biztonságos átállás öt lépés: dokumentálás, párhuzamos gyűjtés, riportok átírása, hirdetési import átkapcsolása, végül a régi név kivezetése. A sorrend azért számít, mert így soha nincs olyan nap, amikor egyik név sem mér.
- Rögzítsd a döntést, mielőtt bármit módosítasz. A mérési tervben és az átállási naplóban legyen ott a régi név, az új név, az ok, a tervezett váltási dátum és a felelős.
- Indítsd el a párhuzamos gyűjtést. Egy átmeneti ideig mindkét név érkezzen ugyanarra a felhasználói műveletre. Ezt megoldhatod a kódban, a Tag Managerben (két GA4 eseménycímke ugyanarra az aktiválási szabályra), vagy a GA4 eseménylétrehozási funkciójával, ami a régi eseményből szerveroldalon készít egy új nevűt, és az eredetit is megtartja.
- Írd át a riportokat. Looker Studio, feltárások, közönségek, BigQuery-lekérdezések. A cél az, hogy minden riport a váltási dátum előtt a régi, utána az új nevet számolja.
- Kapcsold át a hirdetési importot. Az új konverziós műveletet először másodlagosként importáld, és hasonlítsd össze a régivel. Ha a két szám napról napra fedi egymást, cseréld meg a szerepüket.
- Vezesd ki a régi nevet. Kapcsold ki a régi küldést, vedd le róla a kulcsesemény-jelölést, a Google Ads-ben tedd a régi műveletet inaktívvá. A régi nevet a mérési tervből ne töröld, jelöld megszűntnek dátummal.
A párhuzamos gyűjtés Tag Manager nélküli, gtag-alapú változata ennyi.
gtag('event', 'form_submit', params); gtag('event', 'ajanlatkeres_kuldes', params);
Mindkét hívás ugyanazt a paraméterobjektumot kapja, így az összehasonlítás tiszta marad.
Szakmai feltételezés. Az átmeneti időszak hossza legalább egy teljes üzleti ciklus legyen. Egy hétköznap erős B2B oldalon ez minimum két teljes hét, hirdetési importnál pedig addig érdemes várni, amíg az új műveleten az összehasonlításhoz elég konverzió gyűlt össze. Két-négy hét a legtöbb esetben elég, ritka konverziónál több kell.
A párhuzamos időszak alatt döntsd el előre, melyik név számít kulcseseménynek a riportokban. Ha mindkettő az, a GA4 összesített kulcsesemény-száma erre az időszakra duplán számol. Ezt a naplóba írd be, hogy később senki ne higgye valódi növekedésnek.
Hogyan fűzd össze a két nevet egy folytonos riportba?
A folytonos idősorhoz a riport szintjén egy vágási dátumot kell használni, ami előtt a régi, utána az új nevet számolod. Így a párhuzamos időszak sem okoz duplázást.
BigQuery exportnál ez egyetlen feltétellel megoldható.
SELECT event_date, COUNTIF((event_name = 'form_submit' AND event_date < '20261015') OR (event_name = 'ajanlatkeres_kuldes' AND event_date >= '20261015')) AS ajanlatkeres FROM `projekt.analytics_123456.events_*` GROUP BY event_date ORDER BY event_date
Looker Studióban ugyanezt egy számított mezővel éred el, ami a dátum és az eseménynév alapján egy közös címkét ad (például „Ajánlatkérés”), és a diagram erre a címkére szűr. A vágási dátumot ne írd bele tíz különböző riportba kézzel. Tartsd egy helyen, és onnan hivatkozz rá, mert ha a váltás csúszik, csak egyszer kell átírni.
Saját tapasztalat. A párhuzamos időszak adatait érdemes napi bontásban egymás mellé tenni. Ha a két név száma között tartósan néhány százaléknál nagyobb az eltérés, az aktiválási szabály vagy a paraméterezés nem egyezik, és ezt a kivezetés előtt kell kideríteni.
Mire jó a GA4 eseménymódosítási funkciója, és hol a határa?
Az eseménymódosítás kódmódosítás nélkül, a GA4 felületén nevezi át a beérkező eseményt. Gyors, de csak előre hat, és a módosítás a kódból nem látszik, ezért dokumentáció nélkül könnyen elfelejtődik.
Hivatalosan igazolt. A módosítási és létrehozási szabályok a gyűjtés után, a feldolgozás előtt futnak le, a tulajdonságonként beállítható szabályok száma korlátozott, és a már feldolgozott adatot nem érintik.
Saját tapasztalat. A felületi átnevezés ott okoz gondot, ahol a kódot később valaki más is módosítja. A fejlesztő a Tag Managerben átírja a nevet, a GA4-ben ülő szabály pedig onnantól a nem létező régi nevet figyeli. Ha felületi szabályt használsz, a naplóban külön jelöld, hogy az átnevezés hol él, a kódban vagy az adminban.
Hogyan jelöld a vágást a mérési tervben és a riportokban?
Minden átnevezésnek legyen dátuma a mérési tervben, jegyzete a riport idővonalán és sora az átállási naplóban. Ez a három együtt teszi láthatóvá a vágást annak is, aki nem volt ott a döntésnél.
A mérési tervben az eseménysor ne tűnjön el, kapjon állapotot („aktív”, „párhuzamos”, „megszűnt”) és dátumot. A GA4-ben a riportok idővonalára dátumhoz kötött megjegyzést is felvehetsz, erre írd rá a váltás napját és a napló azonosítóját. Looker Studióban egy szövegdoboz a diagram alatt ugyanezt a célt szolgálja.
Hogyan néz ki egy átállási napló-sablon?
Az átállási napló egy táblázat, amelyben minden eseménynév-változás egy sor, és fél év múlva is kiolvasható belőle, mi, mikor, miért és hol változott.
Javasolt oszlopok:
- Azonosító (például MV-2026-07), erre hivatkozik a riport-jegyzet.
- Régi név és új név, pontos írásmóddal, kis- és nagybetűvel.
- Ok, egy mondatban, miért kellett változtatni.
- Hol él az átnevezés (kód, Tag Manager, GA4 felületi szabály).
- Párhuzamos gyűjtés kezdete és vége.
- Vágási dátum, amit a riportok használnak.
- Kulcsesemény-változás, melyik név mikor kapta meg és mikor vesztette el a jelölést.
- Hirdetési import, az érintett konverziós műveletek és az elsődleges-másodlagos csere napja.
- Átírt riportok és közönségek listája.
- Ismert torzítás, például a párhuzamos időszak duplázása az összesített számban.
- Felelős és ellenőrzés dátuma.
Egy kitöltött minta sor így nézhet ki. MV-2026-07, form_submit helyett ajanlatkeres_kuldes, ok az egységes magyar névkonvenció, átnevezés helye a Tag Manager, párhuzamos gyűjtés október 1. és október 28. között, vágási dátum október 15., a kulcsesemény-jelölés október 1-jén került az új névre, a régi név jelölése október 28-án megszűnt, a Google Ads csere október 20-án történt, és a naplóba bekerült, hogy október 1. és 28. között a GA4 összesített kulcsesemény-száma dupla.
Mit ellenőrizz az átállás előtt és után?
Előtte a leltárt, utána a számok egyezését. Ha a két lista kész, az átnevezés kockázata jól kezelhető.
- Megvan-e minden riport, feltárás, közönség és lekérdezés listája, ami a régi névre hivatkozik?
- Az új név pontosan egyezik-e minden rendszerben, kis- és nagybetűre is?
- Az új név kulcsesemény-e, és pontosan melyik napon lett az?
- Az új importált konverziós művelet másodlagosként fut-e a csere előtt?
- A párhuzamos időszakban a két név napi száma közel egyezik-e?
- A riportok vágási dátuma egy helyről jön-e?
- Kikapcsoltad-e a régi küldést, és levetted-e róla a kulcsesemény-jelölést?
- A mérési terv és a napló tartalmazza-e a dátumokat és az ismert torzítást?
Mikor ne nevezz át egyáltalán?
Ha a változtatás csak kozmetikai, jobb a riport szintjén szép nevet adni, a gyűjtést pedig békén hagyni. Az átnevezés akkor éri meg, ha a régi név félrevezető, ütközik a névkonvenció többi részével, vagy több, ténylegesen eltérő műveletet mos össze.
Szakmai feltételezés. Egy több éve futó, hirdetési importhoz kötött eseménynél az átnevezés költsége (elvesztett folytonosság, újratanuló ajánlattétel, átírandó riportok) jó eséllyel nagyobb, mint egy csúnya technikai név kényelmetlensége. Ilyenkor a Looker Studióban adott megjelenítési név vagy egy leíró eseményparaméter sokszor elég.
Ha mégis átnevezel, vállald fel a vágást. Egy jól dokumentált törés az idősorban hiteles adat, egy elrejtett törés viszont minden későbbi döntést rossz irányba vihet.
Források és további olvasnivalók
- Google Analytics súgó, Események módosítása és létrehozása
- Google Analytics súgó, Eseménygyűjtési korlátok és elnevezési szabályok
- Google Analytics súgó, Kulcsesemények kezelése
- Google Analytics súgó, Megjegyzések a riportokban
- Google Ads súgó, Google Analytics kulcsesemények importálása
- Google Ads súgó, Elsődleges és másodlagos konverziós műveletek
- Google Analytics fejlesztői dokumentáció, BigQuery Export séma
- Google Tag Manager súgó, GA4 eseménycímkék
- Meta Business súgó, Egyéni konverziók
- A GA4 az átnevezett eseményt új eseményként kezeli, a korábbi adatot visszamenőleg nem nevezi át.
- A kulcsesemény-jelölés és a Google Ads import a pontos névhez kötődik, ezért az új nevet külön be kell kötni.
- A biztonságos sorrend a dokumentálás, a párhuzamos gyűjtés, a riportok átírása, az import átkapcsolása, végül a régi név kivezetése.
- A folytonos riporthoz egy helyen tárolt vágási dátum kell, ami előtt a régi, utána az új nevet számolod.
- Az átállási napló minden változás dátumát, helyét és ismert torzítását rögzíti, így fél év múlva is értelmezhető az idősor.
Gyakori kérdések
Átnevezi a GA4 a régi adatot, ha módosítom az esemény nevét?
Nem. Az eseménymódosítás és a kódban végzett átnevezés is csak az ezután beérkező adatra hat, a korábbi adat a régi néven marad.
Mennyi ideig gyűjtsem párhuzamosan a régi és az új eseménynevet?
Szakmai tapasztalat alapján legalább egy teljes üzleti ciklusig, a legtöbb esetben két-négy hétig. Hirdetési importnál addig, amíg az új konverziós műveleten elég adat gyűlik az összehasonlításhoz.
Mi történik a Google Ads konverziókkal az átnevezés után?
A régi névhez kötött importált konverziós művelet nem kap több adatot. Az új kulcseseményt új műveletként kell importálni, érdemes először másodlagosként, és csak az egyezés ellenőrzése után elsődlegesként használni.
Miért duplázódott meg a konverziószám az átállás alatt?
Valószínűleg a párhuzamos gyűjtés alatt mindkét név kulcseseményként számol. Ezt a riportban vágási dátummal kezeld, és jelöld az átállási naplóban ismert torzításként.
Mikor nem érdemes átnevezni egy eseményt?
Ha a változtatás csak kozmetikai. Ilyenkor a riport szintjén adott megjelenítési név vagy egy leíró paraméter jó eséllyel kisebb kockázattal jár, mint az idősor megtörése.
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.