Mérési terv dokumentum: az üzleti céltól az eseménynévig egy táblázatban

Scheo · 2026-09-07 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A mérési terv egy dokumentum, amiben minden sor egyetlen üzleti célt köt össze egyetlen eseménynévvel, és megmondja, hogy az esemény mikor sül el, milyen adatot visz magával, hol jelenik meg a riportban, ki felel érte, és mikor nézted meg utoljára. Nem projektterv, nem specifikáció, nem folyamatábra. Egy táblázat, ami elfér egy képernyőn, és amit bárki elolvashat a csapatból anélkül, hogy be kellene lépnie a GA4-be.

Miért nem elég a GA4 felülete mérési tervnek?

Rövid válasz: mert a GA4 adminja azt mutatja meg, mi van beállítva, azt nem, hogy miért. Az eseménylistából kiolvasod, hogy létezik egy form_submit_2 nevű esemény, de azt nem, hogy melyik űrlaphoz tartozik, ki tette fel, milyen üzleti kérdésre válaszol, és hogy az eredeti form_submit miért nem volt jó.

Hivatalosan igazolt: a Google Analytics 4 dokumentációja szerint az eseménynév legfeljebb 40 karakter, a paraméternév szintén 40, a paraméterérték 100 karakter lehet, eseményenként legfeljebb 25 egyedi paramétert küldhetsz, és az egyedi (custom) dimenziók száma property-szinten korlátos. Az is dokumentált, hogy egy paraméter csak akkor válik a riportokban választható dimenzióvá, ha külön regisztrálod egyedi dimenzióként, és a regisztráció előtti adatra ez visszamenőleg nem érvényes.

Ebből következik a lényeg: az eseménynév és a paraméterkészlet olyan döntés, amit nehéz visszacsinálni. Ha elgépeled, nem átnevezed, hanem új néven kezded elölről a gyűjtést, és a régi név ott marad a listában örökre. Ezért érdemes a nevet előbb leírni egy táblázatba, és csak utána bekattintani a GTM-be.

Milyen oszlopokból áll egy használható mérési terv?

Nyolc oszlop elég. Kevesebbel hiányzik valami, többel senki nem tölti ki.

• Üzleti cél: az a mondat, amit a tulajdonos is aláírna. Nem „több forgalom”, hanem például „több ajánlatkérés a klímatelepítésre”.
• A célt jelző felhasználói cselekvés: mit csinál az ember a képernyőn, amiből tudjuk, hogy a cél teljesült. Ez természetes nyelven íródik, nem kóddal.
• Eseménynév: a GA4-be kerülő, végleges, kisbetűs, alulvonással tagolt név.
• Paraméterek: a névhez tartozó mezők és a lehetséges értékkészletük.
• Kiváltó feltétel: pontosan mikor sül el. Melyik oldalon, melyik elemre, milyen előfeltétellel, mi az, ami NEM váltja ki.
• Hol jelenik meg a riportban: melyik GA4-nézet, melyik Looker Studio-blokk, kulcsesemény-e.
• Felelős: egy név, nem egy szerepkör és nem egy cég.
• Ellenőrizve: dátum. Az a nap, amikor valaki élesben látta működni.

Saját tapasztalat: a nyolcból a „kiváltó feltétel” és az „ellenőrizve” oszlopot hagyják ki a leggyakrabban, és pont ez a kettő az, ami később eldönti egy vitát. A kiváltó feltétel nélkül nem lehet megmondani, hogy a szám azért nőtt-e meg, mert több érdeklődő jött, vagy azért, mert az esemény kétszer sül el egy űrlapküldésnél.

Hogyan néz ki ez egy szolgáltató cégnél, sorról sorra?

A példa egy általános épületgépészeti szolgáltató, aki lakossági és céges megrendelést is vállal. A táblázat hat sora így néz ki kifejtve.

1. sor: ajánlatkérő űrlap

• Üzleti cél: több ajánlatkérés a fő szolgáltatásokra.
• Cselekvés: kitölti és sikeresen elküldi az ajánlatkérő űrlapot, megjelenik a köszönőüzenet.
• Eseménynév: ajanlatkeres_kuldes
• Paraméterek: urlap_azonosito, szolgaltatas (klima, futes, viz), ugyfel_tipus (lakossagi, ceges).
• Kiváltó feltétel: a form plugin sikeres visszajelzése után, oldalanként egyszer. Hibás beküldés, validációs hiba, spam-szűrő elutasítás nem váltja ki.
• Riportban: kulcsesemény, a Looker-riport felső sávjában és a landing oldalak bontásában.
• Felelős: a webfejlesztő.
• Ellenőrizve: az élesítés napja, majd minden negyedévben újra.

2. sor: telefonhívás mobilról

• Üzleti cél: a sürgős, hívásos megkeresések mérése.
• Cselekvés: rákattint egy tel: linkre.
• Eseménynév: telefon_kattintas
• Paraméterek: hely (fejlec, lablec, kapcsolat_oldal, uszo_gomb), eszkoz_tipus.
• Kiváltó feltétel: kattintás olyan linkre, aminek a hivatkozása tel: előtaggal kezdődik. Asztali gépen is gyűjtjük, de a riportban külön kezeljük.
• Riportban: másodlagos mérőszám, nem kulcsesemény, mert a kattintás nem bizonyítja a beszélgetést.
• Felelős: a hirdetéskezelő.

3. sor: visszahívás-kérés

• Üzleti cél: azok megfogása, akik nem akarnak hosszú űrlapot kitölteni.
• Cselekvés: megadja a nevét és a telefonszámát a visszahívás-kérő ablakban.
• Eseménynév: visszahivas_keres
• Paraméterek: hely, napszak.
• Kiváltó feltétel: a widget sikeres beküldése. A widget megnyitása külön esemény, nem ez.
• Riportban: kulcsesemény, az ajánlatkéréssel közös blokkban, de külön soron.

4. sor: referenciaanyag letöltése

• Üzleti cél: a hosszabb döntési idejű, céges érdeklődők azonosítása.
• Cselekvés: letölti a referencialistát vagy a műszaki adatlapot PDF-ben.
• Eseménynév: anyag_letoltes
• Paraméterek: fajl_nev, fajl_tipus, oldal_kategoria.
• Kiváltó feltétel: kattintás a fájlra mutató linkre. A GA4 automatikus file_download eseményével nem keverjük, mert az más feltételrendszerrel dolgozik.
• Riportban: érdeklődési jelzés, a tartalomblokkban.

5. sor: útvonaltervezés a telephelyre

• Üzleti cél: a személyes ügyfélfogadás forgalmának mérése.
• Cselekvés: rákattint a térképre vagy az útvonal gombra a kapcsolat oldalon.
• Eseménynév: utvonal_kattintas
• Paraméterek: telephely, hely.
• Kiváltó feltétel: kattintás a beágyazott térkép melletti gombra. A beágyazott térképen belüli mozgás nem mérhető, ezt a terv jegyzet oszlopában is rögzítjük.

6. sor: árajánlat elfogadása

• Üzleti cél: a mérés összekötése a valódi bevétellel.
• Cselekvés: az ügyfél az online ajánlat oldalon jóváhagyja a megrendelést.
• Eseménynév: ajanlat_elfogadas
• Paraméterek: ajanlat_azonosito, szolgaltatas.
• Kiváltó feltétel: a jóváhagyás utáni visszaigazoló oldal betöltése, ajánlatazonosítónként egyszer.
• Riportban: kulcsesemény, és ez az egyetlen sor, amit a CRM-ből is vissza lehet ellenőrizni.

Saját tapasztalat: hat sor általában elég egy szolgáltató cégnél. Ha valaki huszonöt sorral kezd, a negyedik hónapban már senki nem tudja, melyik szám mit jelent, és a riport helyett újra a megérzés dönt.

Hogyan lesz a tervsorból GTM-beállítás?

Úgy, hogy a Tag Managerben semmit nem találsz ki: minden mező a terv valamelyik oszlopából származik. A leképezés mechanikus.

1. A kiváltó feltétel oszlopból lesz a trigger. Ha a feltétel egy mondatban nem írható le, akkor még nincs kész a tervsor, és nem a GTM-ben kell gondolkodni tovább.
2. Az eseménynév oszlopból lesz a GA4 esemény tag neve, betűre pontosan. Itt nincs rögtönzés, nincs nagybetű, nincs ékezet.
3. A paraméterek oszlopból lesznek az eseményparaméterek és a hozzájuk tartozó GTM-változók.
4. A riportban oszlopból derül ki, hogy melyik paramétert kell egyedi dimenzióként regisztrálni a GA4-ben, és melyik eseményt kell kulcseseménnyé tenni.

Ahol a weboldal saját adatot tud adni, ott a legstabilabb megoldás a dataLayer-esemény, mert nem egy CSS-osztályra épül, amit a következő sablonfrissítés átír:

window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'ajanlatkeres_ok', urlap_azonosito: 'ajanlatkero_fo', szolgaltatas: 'klima', ugyfel_tipus: 'lakossagi' });

Ebből a GTM-ben egy Custom Event trigger figyeli az ajanlatkeres_ok nevet, a három mezőt pedig három Data Layer Variable olvassa ki. A GA4 esemény tag neve ajanlatkeres_kuldes, a paraméterei pedig a változókra mutatnak. Élesítés előtt a GTM előnézetében és a GA4 DebugView-ban is látszania kell, hogy az esemény egyszer sül el, és mind a három paraméter értéket kap.

Szakmai feltételezés: a CSS-osztályra vagy szövegre épülő triggerek nagyobb eséllyel romlanak el egy sablonfrissítéskor, mint a dataLayer-alapúak, mert a megjelenést sűrűbben módosítják, mint a beépülő adatréteget. Ez logikus következtetés a karbantartási gyakorlatból, nem mért adat.

Hogyan épül fel ebből a Looker Studio-riportblokk?

A riport négy sávra bontható, és mindegyik sáv a tervtáblázat egy-egy oszlopából kap tartalmat.

• Felső sáv, kulcsszámok: annyi mérőszámkártya, ahány kulcsesemény van a tervben. A példában három: ajánlatkérés, visszahívás-kérés, ajánlat elfogadása. Mindegyik mellett előző időszakhoz mért eltéréssel.
• Idősor: ugyanez a három esemény napi vagy heti bontásban. Itt látszik meg leggyorsabban, ha egy esemény elnémul, mert a görbe nem csökken, hanem nullára ül.
• Bontások: forgalmi forrás és céloldal szerinti táblázat, dimenzióként azokkal a paraméterekkel, amiket egyedi dimenzióként regisztráltál. Ha a szolgaltatas paraméter nincs regisztrálva, ez a blokk üres marad, hiába küldöd az adatot.
• Adatminőségi blokk: eseményenként az utolsó beérkezés dátuma és a napi darabszám. Ez a blokk nem az ügyfélnek szól, hanem neked. A mérési hiba itt derül ki, nem a havi riport írásakor.

A riport fejlécébe érdemes betenni a mérési terv linkjét és az utolsó felülvizsgálat dátumát. Így aki a számot nézi, egy kattintással eljut ahhoz a mondathoz, ami megmondja, mit jelent.

Miért pont az új esemény felrakása rontja el a mérést?

Mert az az első pillanat, amikor a valóság és a dokumentum szétválik, és onnantól minden további módosítás egy hibás alapra épül. Az első felrakott, tervbe be nem írt esemény önmagában általában nem okoz kárt. A második már ütközhet az elsővel, a harmadikat pedig már senki nem meri kivenni, mert nem tudja, ki használja.

Ez a dokumentum tehát fék: azt a néhány percet kényszeríti ki, amíg leírod, mit fogsz mérni és miért. Ha ez a néhány perc kimarad, később órákat visz el annak a kiderítése, hogy a lead, a generate_lead és a form_ok közül melyik a valódi ajánlatkérés. Nem bürokrácia, hanem a legolcsóbb pont, ahol a hiba még megállítható.

Saját tapasztalat: a leggyakoribb csendes hiba nem a hiányzó esemény, hanem a dupla mérés. Régi és új követőkód egyszerre, vagy két trigger ugyanarra a kattintásra. A szám ilyenkor nem hiányzik, hanem szép és túl nagy, ezért hónapokig senki nem kérdez rá.

Mit nézz át a terv negyedéves felülvizsgálatakor?

Negyedévente egy óra elég, ha van mihez nyúlni. Az ellenőrzőlista:

1. Minden tervsorhoz tartozik ténylegesen beérkező esemény az elmúlt 30 napban?
2. Van a GA4 eseménylistájában olyan név, ami nincs a tervben? Ha igen, ki tette fel, és mikor?
3. Van olyan tervsor, amihez nulla adat érkezik? Elromlott, vagy megszűnt a funkció?
4. A kulcsesemények listája megegyezik a tervben kulcseseményként jelölt sorokkal?
5. Nincs dupla mérés: egy űrlapküldés egy eseményt eredményez a DebugView-ban?
6. Minden riportban használt paraméter regisztrálva van egyedi dimenzióként?
7. Az eseménynevek megfelelnek a saját konvenciódnak, és beleférnek a hosszkorlátba?
8. Nem kerül személyes adat paraméterértékbe (e-mail, telefonszám, név, teljes cím)?
9. A süti- és hozzájárulási beállítás változott-e, és ha igen, hogyan hat a mért mennyiségre?
10. A Looker-riport minden blokkja tölt, nincs törött mező vagy átnevezett dimenzió?
11. Minden sorhoz tartozik élő felelős, aki még a cégnél vagy a partnernél van?
12. Az „ellenőrizve” dátum frissült, és aki beírta, tényleg élesben látta működni?

Amit a felülvizsgálat során törölnél, azt ne töröld ki azonnal a dokumentumból: húzd egy „megszűnt” szakaszba a dátummal és az okkal. Fél év múlva ez válaszol arra a kérdésre, hogy miért nincs adat egy régi kampányidőszakra.

Ez a szerkezet nem hozza magától a több érdeklődőt, és nem old meg minden mérési problémát. Azt segítheti, hogy a riportban látott szám visszavezethető legyen egy konkrét felhasználói cselekvésre, és hogy egy változás után jó eséllyel napokon belül kiderüljön, ha valami elhallgatott.

Források és további olvasnivalók

• Google Analytics Help: GA4 events, recommended events, event and parameter limits
• Google Analytics Help: Custom dimensions and metrics, Key events
• Google Tag Manager Help: Triggers, Variables, Data Layer
• Google Developers: Google tag (gtag.js) and Data Layer reference
• Looker Studio Help: Google Analytics connector, calculated fields
• Google Search Central: Search Console dokumentáció (forgalmi adatok értelmezése)
• Schema.org: strukturált adat típusok dokumentációja
• W3C: Web Content Accessibility Guidelines (űrlapok és interaktív elemek)
• Nemzeti Adatvédelmi és Információszabadság Hatóság: tájékoztatók a hozzájárulás kezeléséről