Az űrlap az a pont, ahol a forgalomból érdeklődő lesz, vagy nem lesz. A legtöbb weboldalon mégis egyetlen dolgot mérünk róla: elment-e a kitöltés. Ez körülbelül annyi információ, mintha egy boltban csak a pénztárgépet figyelnéd, a polcok között viszont sötét lenne. Tudod, hányan fizettek, de fogalmad sincs, hol tette vissza a többség a terméket.
Ebben a cikkben végigmegyünk azon, hogyan állítasz be mezőszintű mérést, hogyan építesz belőle tölcsérriportot a GA4-ben, és hogyan olvasod ki a számokból, melyik mező töri meg a kitöltést. A saját nézőpontom egyszerű: a félbehagyott űrlapok többsége mögött nem elpárolgott motiváció áll, hanem egy technikai akadály, amit egy nap alatt el lehet takarítani.
Miért nem motivációhiány a legtöbb űrlapelhagyás?
Rövid válasz: mert aki eljutott az űrlapig és elkezdte kitölteni, az már döntött. Ha ezután áll meg, akkor a folyamat állította meg, nem a szándéka.
Tovább a témában: Versenytárs AI-láthatóság elemzése · Amikor AI-ügynök tölti ki az űrlapodat
Érdemes elválasztani két nagyon különböző viselkedést. Az egyik, amikor valaki megnyitja az űrlapot, ránéz, és hozzá sem kezd. Ez tényleg lehet motiváció vagy bizalom kérdése: nem elég meggyőző az oldal, sok a kért adat, nem világos, mi történik a küldés után. A másik, amikor valaki beleír két mezőbe, aztán eltűnik. Ez már munkabefektetés volt a részéről, és jellemzően akadályba futott.
Saját tapasztalat: a mezőszintű mérés bevezetése után az esetek nagy részében kirajzolódik egy vagy két mező, amelyik feltűnően több kilépést hoz, mint a többi. Szinte mindig ugyanaz a kör: telefonszám, adószám, jelszó-megerősítés, irányítószám, illetve az adatkezelési jelölőnégyzet. Ezek nem véletlenszerűen szóródnak, ami önmagában is arra utal, hogy nem hangulat kérdése a kilépés.
Szakmai feltételezés: a látogató nem tudja megkülönböztetni a saját hibáját a weboldal hibájától. Ha kap egy piros keretet és nem érti, mit ront el, jellemzően nem kezd nyomozni, hanem elmegy. A hibás validáció ezért nem bosszúságot okoz, hanem csendes kiesést.
Mit jelent a mezőszintű mérés, és mit nem szabad mérni?
Rövid válasz: a mezőszintű mérés azt rögzíti, hogy a látogató melyik mezőbe lépett be, melyiket hagyta el kitöltve, melyiknél kapott hibaüzenetet, és eljutott-e az elküldésig. A mezők tartalmát soha nem rögzíti.
Ez a határvonal nem stílus kérdése. Hivatalosan igazolt: a Google Analytics használati feltételei tiltják a személyes azonosításra alkalmas adatok küldését a rendszerbe, tehát a névbe, e-mail címbe, telefonszámba beírt érték nem kerülhet eseményparaméterbe. Amit rögzíthetsz: a mező technikai neve, sorrendje, a hiba típusa, az űrlap azonosítója, és az, hogy a mező üresen maradt-e vagy sem. Ennyi bőven elég a diagnózishoz.
Két további hivatalos korlát, amivel tervezéskor számolj: a GA4-ben az eseménynév és a paraméternév legfeljebb 40 karakter, a paraméter szöveges értéke legfeljebb 100 karakter lehet, és az egyéni, esemény-hatókörű dimenziók száma standard tulajdonban korlátozott (50 körüli nagyságrend). Ne akarj tehát minden mezőhöz külön eseményt gyártani. Egy esemény, benne a mező nevével mint paraméterrel, sokkal takarékosabb.
Hogyan néz ki a konkrét eseményterv hat eseménnyel?
Rövid válasz: hat esemény elég ahhoz, hogy a teljes kitöltési utat lásd, a megjelenéstől a sikeres elküldésig.
- form_view: az űrlap ténylegesen láthatóvá vált a képernyőn (nem az oldalbetöltés, hanem a görgetés utáni láthatóság). Paraméterek:
form_id,form_step. - form_field_focus: a látogató belekattintott vagy beleugrott egy mezőbe. Mezőnként egyszer érdemes küldeni. Paraméterek:
form_id,field_name,field_order. - form_field_complete: a mező elhagyásakor volt benne érték. Paraméterek: ugyanazok, kiegészítve azzal, hogy kötelező mezőről van-e szó.
- form_field_error: a mezőhöz hibaüzenet jelent meg. Paraméterek:
field_name,error_type(hiányzó, formátum, hossz, szerveroldali), és egy jelző arról, hogy a hibaszöveg látható volt-e. - form_submit_attempt: a látogató megnyomta a küldés gombot, függetlenül attól, hogy átment-e a validáción. Ez a legtöbbször kihagyott, mégis a legárulkodóbb esemény.
- form_submit_success: a szerver visszaigazolta a beküldést. Ez a konverziós esemény, ezt jelöld kulcseseménynek a GA4-ben.
A hatból az első öt diagnosztikai célú, a hatodik az üzleti mérőszám. Ha csak egyet tudsz bevezetni a diagnosztikaiak közül, az legyen a form_submit_attempt: a kísérlet és a siker közötti rés a legdrágább vakfolt.
Hogyan teszed fel a mérést a gyakorlatban?
A legegyszerűbb út egy Google Tag Managerben elhelyezett egyéni HTML-címke, amelyik a dataLayer-be tolja az eseményeket, onnan pedig GA4-eseménycímkék viszik tovább. A váz nagyjából így néz ki:
var urlap = document.querySelector('form#kapcsolat'); var mezok = urlap.querySelectorAll('input, select, textarea'); mezok.forEach(function (mezo, i) { mezo.addEventListener('focus', function () { window.dataLayer.push({ event: 'form_field_focus', form_id: 'kapcsolat', field_name: mezo.name, field_order: i + 1 }); }, { once: true }); mezo.addEventListener('blur', function () { if (mezo.value.trim() !== '') { window.dataLayer.push({ event: 'form_field_complete', form_id: 'kapcsolat', field_name: mezo.name, field_order: i + 1 }); } }); });
A hibák elkapására a böngésző beépített validációja ad kapaszkodót. Az invalid esemény akkor sül el, amikor a mező megbukik az ellenőrzésen:
mezo.addEventListener('invalid', function () { var tipus = mezo.validity.valueMissing ? 'hianyzo' : (mezo.validity.typeMismatch || mezo.validity.patternMismatch ? 'formatum' : 'egyeb'); window.dataLayer.push({ event: 'form_field_error', form_id: 'kapcsolat', field_name: mezo.name, error_type: tipus }); });
Ha a weboldal saját validációs szkriptet használ (a legtöbb WordPress-bővítmény ilyen), akkor a hibaüzenet DOM-ba kerülését figyeld egy MutationObserver-rel a hibakonténerre. A lényeg ugyanaz: azt rögzítsd, hogy megjelent-e a hibaszöveg, mert később pont az lesz a döntő kérdés, hogy a látogató kapott-e visszajelzést.
A form_submit_attempt-ot ne a form submit eseményére kösd, mert az sikertelen validációnál el sem sül. Kösd a küldés gomb kattintására, és külön a submit-ra a sikeres esetet.
Hogyan épül fel ebből a tölcsérriport a GA4-ben?
Rövid válasz: a Felfedezések menü Tölcsér-felderítés riportjában öt lépést veszel fel az eseményekből, nyitott tölcsérként, és mező szerint bontod.
Hivatalosan igazolt: a GA4 tölcsér-felderítése legfeljebb tíz lépést kezel, és támogatja a nyitott (bárhol beléphet a felhasználó) és a zárt (csak az első lépéstől) módot. A mezőszintű elemzéshez a nyitott tölcsér a hasznosabb, mert a látogatók egy része közvetlen linkről vagy visszatérve esik be a folyamatba.
A javasolt felépítés:
- 1. lépés:
form_view - 2. lépés:
form_field_focus, szűrve az első mezőre - 3. lépés:
form_field_complete, szűrve a gyanús kritikus mezőre (például telefonszám vagy adószám) - 4. lépés:
form_submit_attempt - 5. lépés:
form_submit_success
A riportban kapcsold be az elhagyás megjelenítését, a bontásba pedig tedd be az eszközkategória dimenziót, majd egy második nézetben a field_name egyéni dimenziót. Ne felejtsd el, hogy az egyéni paraméterek csak akkor jelennek meg dimenzióként, ha az Adminban regisztráltad őket, és a regisztráció után gyűjtött adatokra érvényesek visszamenőleg nem.
Egy második, szabad formájú riport is kell mellé: sorokban a field_name, oszlopokban a form_field_focus és a form_field_complete eseményszáma. A kettő hányadosa mezőnként megadja a kitöltési arányt, és ez az a táblázat, amiből ránézésre látszik a szűk keresztmetszet.
Hogyan olvasod ki, hol szakad meg a kitöltés?
Négy mintázatot érdemes keresni, mindegyik más beavatkozást kíván.
- Sok fókusz, kevés kitöltés ugyanazon a mezőn. A látogató belekattintott, de üresen hagyta. Ez tartalmi akadály: nincs kéznél az adat, vagy nem érti, miért kéred. Tipikus gazdája az adószám és a cégnév mező.
- Sok hibaesemény ugyanarra a mezőre, ismétlődve. Ha ugyanaz a látogató többször kap hibát ugyanott, a validációd szigorúbb vagy homályosabb a kelleténél. Klasszikus eset a telefonszám.
- Elküldési kísérlet van, sikeres elküldés nincs, hibaesemény sincs. Ez a legrosszabb minta, mert a látogató megnyomta a gombot és nem történt semmi látható. Néma bukás: eldobta egy spamszűrő, elhalt a szerveroldali kérés, vagy a hibaüzenet a képernyőn kívülre került. Saját tapasztalat: ez az a hiba, amiről a weboldal tulajdonosa jellemzően nem tud, mert neki saját böngészőből mindig működik.
- Megjelenés van, első fókusz alig. Az űrlapig eljutnak, de hozzá sem kezdenek. Itt már tényleg a meggyőzés és a kért adatok mennyisége a kérdés, nem a technika.
Minden nézetet bonts mobil és asztali eszközre külön. A mezőszintű problémák nagy része mobilon jelentkezik erősebben, mert ott kisebb a képernyő, más a billentyűzet, és a hibaüzenet könnyebben kerül a látható terület alá.
Milyen űrlaphibák okozzák a legtöbb kiesést?
Ez az ellenőrzőlista végigmegy azokon a hibákon, amiket a mérés után a leggyakrabban találsz meg. Mindegyik javítható fejlesztési projekt nélkül.
- Kötelező adószám mező lakossági érdeklődőnél. Ha ugyanaz az űrlap szolgál ki céges és magánszemély érdeklődőt, az adószám nem lehet feltétel nélkül kötelező. Tedd feltételessé egy "cégként érdeklődöm" kapcsolóra, vagy hagyd üresen kitölthetőnek. Az ajánlatkéréshez ritkán kell adószám, a számlázáshoz viszont igen, és ez a két lépés nem ugyanaz.
- Túl szigorú telefonszám-validáció. A magyar számokat az emberek sokféleképpen írják: 06 20, +36 20, 0620, szóközzel, kötőjellel, zárójellel. Ha a szabály csak egy formátumot fogad el, a többit elveszíted. Praktikus megoldás: küldés előtt normalizáld a beírt értéket (szóközök és kötőjelek eltávolítása), és csak a számjegyek darabszámát ellenőrizd. A hibaüzenet mondja meg konkrétan, mit vársz, ne csak annyit, hogy "érvénytelen".
- Hiányzó vagy láthatatlan hibaüzenet. A piros keret önmagában nem üzenet. Hivatalosan igazolt: a WCAG 3.3.1 pontja megköveteli, hogy a hibát szövegesen is azonosítsd, a 3.3.3 pedig azt, hogy javaslatot adj a javításra. Gyakorlatban: a hibaszöveg a mező mellett legyen, a küldés után görgess automatikusan az első hibás mezőhöz, és jelöld
aria-liveterülettel, hogy a felolvasó is közölje. - Adatkezelési jelölőnégyzet a hajtás alatt. Az űrlap kitöltve, a gomb megnyomva, semmi nem történik, mert lejjebb van egy bepipálatlan kötelező négyzet, amit a látogató nem lát. Ez a néma bukás leggyakoribb oka. Tedd a jelölőnégyzetet a küldés gomb fölé, közvetlenül mellé, és a hibaüzenetét ugyanoda.
- Némán letiltott küldés gomb. Ha a gomb inaktív, amíg minden mező hibátlan, de nem írod ki, mi hiányzik, ugyanaz a helyzet áll elő. Inkább legyen aktív a gomb, és mondja meg kattintásra, mi a baj.
- Túl agresszív spamvédelem. A rejtett mezős csapdák és a pontszám alapú védelmek időnként valódi kitöltést dobnak el. Ha a mérésed sok elküldési kísérletet mutat kevés sikerrel, először ezt nézd meg, mert a beérkező levelek alapján soha nem fog kiderülni.
- Rossz beviteli típusok mobilon. Az e-mail mezőnél
type="email", a telefonnáltype="tel", a számnál megfelelőinputmode. Ezek nélkül a mobilbillentyűzet rossz elrendezéssel nyílik, és nő az elgépelés, tehát a hibaesemények száma is. - Az automatikus kitöltés akadályozása. Ha nem használsz szabványos
autocompleteértékeket, a böngésző nem tudja kitölteni a mezőket, és minden adatot kézzel kell begépelni.
Mit lehet ebből tényleg egy nap alatt megcsinálni?
Egy reális napi menetrend: délelőtt felteszed a hat eseményt és teszteled a GTM előnézetében, délután pedig a mérés első eredményei alapján javítod a legdurvább akadályt. A mérés önmagában nem hoz eredményt, a javítás hoz, de a javítás sorrendjét a mérés adja meg.
Ha nincs időd megvárni az adatot, a fenti listából három beavatkozás szinte mindig indokolt: a telefonvalidáció lazítása, a hibaüzenet láthatóvá tétele a hibás mező mellett, és az adatkezelési jelölőnégyzet felhozása a küldés gomb közelébe. Ezek nem garantálnak több beérkező érdeklődőt, de jó eséllyel megszüntetik azokat a kieséseket, amelyek nem döntésből fakadnak.
Miért számít ez az AI-keresők korában?
Szakmai feltételezés: ahogy a felhasználók egy része chatalapú asszisztensen keresztül szűkíti a választást, a weboldalra érkező látogatók száma csökkenhet, a döntéshez való közelségük viszont nő. Ha kevesebb, de érettebb látogatót kapsz, akkor arányaiban drágább minden technikai akadály az űrlapon. Egy elrontott telefonvalidáció korábban a forgalom töredékét vitte el, ilyen összetételnél viszont pont a legértékesebb érdeklődőket. Ez a feltételezés a forgalmi mintázatok logikájából következik, nem publikált mérésből, ezért érdemes a saját adataidon ellenőrizni: nézd meg külön a mesterséges intelligencia felületeiről érkező forgalom űrlaptölcsérét, ha a hivatkozó forrás azonosítható.
Források és további olvasnivalók
- Google Analytics Súgó: eseménygyűjtés, egyéni dimenziók és mutatók, Tölcsér-felderítés
- Google Analytics Használati feltételek: személyes azonosításra alkalmas adatok tilalma
- Google Tag Manager Súgó: dataLayer és egyéni HTML-címkék
- Google Search Central: dokumentáció és fejlesztői útmutatók
- W3C Web Content Accessibility Guidelines (WCAG) 2.2, 3.3 Bevitel segítése
- W3C WAI-ARIA Authoring Practices Guide: űrlapok és élő régiók
- MDN Web Docs: Constraint Validation API, HTML input attribútumok
- Schema.org: ContactPoint és kapcsolódó típusok
- Nemzeti Adatvédelmi és Információszabadság Hatóság tájékoztatói az adatkezelési hozzájárulásról
- Az elküldés mérése önmagában semmit nem árul el arról, hol szakad meg a kitöltés: mezőszintű események kellenek.
- Hat esemény (megjelenés, fókusz, kitöltés, hiba, elküldési kísérlet, sikeres elküldés) elég a teljes képhez.
- A legveszélyesebb minta az, amikor van elküldési kísérlet, de nincs se hibaesemény, se sikeres elküldés: ilyenkor némán vész el a lead.
- A mezők tartalmát soha ne küldd analitikába, csak a mező nevét és a hiba típusát.
- A gyakori akadályok (kötelező adószám, szigorú telefonvalidáció, láthatatlan hibaüzenet, hajtás alatti adatkezelési jelölőnégyzet) többsége egy munkanap alatt orvosolható.
Gyakori kérdések
Mérhetem-e, hogy mit írt be a látogató a mezőbe?
Nem. A mező tartalma jellemzően személyes adat, és a Google Analytics feltételei tiltják ilyen adat küldését. Azt rögzítsd, hogy a mező üres maradt-e vagy sem, illetve milyen típusú hiba történt. A diagnózishoz ez elég.
Mennyi adat kell ahhoz, hogy értelmezhető legyen a mezőszintű riport?
Nincs univerzális küszöb, de a mezőnkénti összehasonlításhoz több tucat kitöltési kísérlet kell, hogy ne egy-két véletlen eset vezesse félre a képet. Kis forgalmú oldalnál inkább havi bontásban nézd, és a néma bukás mintázatát keresd, ami már néhány esetből is látszik.
Mi a különbség a form_submit_attempt és a form_submit_success között?
Az első akkor sül el, amikor a látogató megnyomja a küldés gombot, függetlenül attól, hogy a validáció átengedi-e. A második akkor, amikor a szerver visszaigazolta a beküldést. A kettő közti rés mutatja meg, hányan akartak küldeni, de nem sikerült nekik.
A GA4 beépített form_start és form_submit eseménye nem elég?
A továbbfejlesztett mérés automatikus űrlapeseményei jó kiindulás, de nem mezőszintűek, és nem mindig sülnek el megbízhatóan a JavaScript alapú, több lépcsős vagy bővítménnyel készült űrlapoknál. Ha tudni akarod, melyik mezőnél áll meg a kitöltés, saját eseményekre lesz szükséged.
Kötelező-e cookie-hozzájárulás a mezőszintű méréshez?
Ha az adatot analitikai eszközbe küldöd és az sütit vagy hasonló azonosítót használ, akkor a hozzájárulás-kezelés szabályai érvényesek rá ugyanúgy, mint a többi mérésre. A mezőszintű események ettől nem lesznek külön kategória, viszont pont ezért fontos, hogy semmilyen beírt értéket ne továbbíts.
Mit tegyek, ha a mérés szerint egyetlen mező sem hibás, mégis sokan kilépnek?
Akkor valószínűleg nem a kitöltés közben, hanem előtte dől el a dolog: az űrlap túl sok adatot kér, nem világos, mi történik a küldés után, vagy nem elég meggyőző az azt megelőző tartalom. Ilyenkor a mezők számának csökkentése és a küldés utáni folyamat leírása a következő lépés.
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.