Űrlapküldés mérése úgy, hogy a köszönőoldal nem töltődik be

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

Ha egy WordPress-oldal űrlapja AJAX-szal küld, a látogató ugyanazon az oldalon marad, és csak egy rövid visszajelzés jelenik meg arról, hogy az üzenet elment. Nincs új URL, nincs köszönőoldal, így nincs mire oldalmegtekintés-alapú konverziót építeni. Ilyenkor sokan a GA4 automatikus űrlapméréséhez nyúlnak, aztán azon csodálkoznak, hogy a riportban látott szám vagy jóval kevesebb a valóságnál, vagy a duplája. Ebben a cikkben végigmegyünk rajta, hogyan méred megbízhatóan a sikeres küldést a négy legelterjedtebb bővítménynél (Contact Form 7, WPForms, Elementor Pro, Gravity Forms), és hogyan ellenőrzöd, hogy a mért szám közel van-e a ténylegesen beérkezett üzenetekhez.

A cikkben háromféle állítást jelölünk külön. Hivatalosan igazolt az, ami a Google vagy a bővítmény fejlesztőjének dokumentációjában szerepel. Saját tapasztalat az, amit mérési beállítások során rendszeresen látunk. Szakmai feltételezés az, ami logikusan következik, de nem mértük minden esetben.

Miért nem elég a GA4 automatikus form_submit eseménye?

Röviden: a GA4 bővített mérése a böngészőben lezajló küldési műveletre figyel, és nem tudja, hogy a szerver elfogadta-e az üzenetet, ezért AJAX-os WordPress-űrlapoknál könnyen kimarad, rossz űrlapra számol vagy sikertelen próbálkozást is konverzióként rögzít.

Hivatalosan igazolt. A GA4 adatfolyam bővített mérésében van egy „Űrlapinterakciók” kapcsoló, amely form_start és form_submit eseményt gyűjt. A Google súgója maga jelzi, hogy ez a funkció nem minden oldalon és nem minden űrlaptípussal működik megbízhatóan, és a kapcsoló külön kikapcsolható.

Saját tapasztalat. A gyakorlatban három hibát látunk újra és újra.

• A form_submit akkor is lefut, ha a látogató kihagyott egy kötelező mezőt, és az űrlap hibaüzenettel visszadobta. A riportban így sikertelen próbálkozások is konverziónak látszanak.
• Ha a bővítmény a küldést teljesen JavaScriptből intézi, és a böngésző klasszikus küldési eseménye nem fut le, a form_submit el is maradhat.
• A fejlécben lévő keresőmező, a hírlevél-feliratkozás és a belépési űrlap ugyanúgy űrlap. A form_id paraméter sokszor üres vagy automatikusan generált, ezért utólag nem tudod szétválogatni, melyik esemény volt valódi ajánlatkérés.

Miért érdemes mindig egyedi eseményt építeni az űrlapokhoz?

Röviden: mert csak azt az eseményt tudod később visszakeresni és számon kérni, amelynek a nevét, a paramétereit és a kiváltó feltételét te határoztad meg, és le is írtad.

A saját nézőpontunk egyszerű. Űrlapoknál kapcsold ki az automatikus eseménygyűjtést, és építs egyetlen, jól elnevezett egyedi eseményt, például urlap_elkuldve néven, amely csak sikeres küldés után fut le. Adj mellé legalább két paramétert, a bővítmény nevét (form_plugin) és az űrlap azonosítóját (form_id). Fél év múlva, amikor valaki megkérdezi, miért esett vissza az ajánlatkérések száma, egy kereséssel meg tudod mondani, melyik űrlapról jött kevesebb üzenet, és pontosan mi váltotta ki az eseményt. Egy általános form_submit mögött ezt már nem látod.

Hivatalosan igazolt. A GA4 eseménynevek kis- és nagybetűérzékenyek, legfeljebb 40 karakteresek lehetnek, és betűvel kell kezdődniük. Ékezetes karaktert ezért ne használj bennük, a biztonságos minta a kisbetű és az aláhúzásjel.

Hogyan kapcsolod ki az automatikus űrlapmérést a GA4-ben?

Röviden: a GA4 adminfelületén, az adatfolyam bővített mérési beállításainál kapcsold ki az „Űrlapinterakciók” opciót, a többi bővített mérést (görgetés, kimenő kattintás) nyugodtan hagyhatod bekapcsolva.

1. Nyisd meg a GA4-ben az Adminisztráció menüt, majd az Adatfolyamok pontot.
2. Válaszd ki a webes adatfolyamot, és kattints a Bővített mérés melletti fogaskerékre.
3. Kapcsold ki az Űrlapinterakciók kapcsolót, és mentsd el.

Ez akkor is a GA4 felületén dől el, ha a GA4-et Google Tag Manageren keresztül telepítetted. A korábban gyűjtött form_submit adatok megmaradnak, csak új nem keletkezik. Ha a form_submit kulcseseménynek volt jelölve, vedd le róla a jelölést, hogy a két számot ne keverd össze az átállás hónapjában.

Hogyan azonosítod a bővítmény saját JavaScript-eseményét?

Röviden: a nagy WordPress-űrlapbővítmények sikeres AJAX-küldés után saját böngészőeseményt váltanak ki. Ennek a nevét a bővítmény fejlesztői dokumentációjában találod, a működését pedig a böngésző konzoljában egy ideiglenes figyelővel ellenőrzöd.

Contact Form 7

Hivatalosan igazolt. A Contact Form 7 DOM-eseményeket küld a dokumentumra. A wpcf7submit minden küldési kísérletnél lefut, a wpcf7invalid hibás kitöltésnél, a wpcf7spam spamgyanúnál, a wpcf7mailfailed sikertelen levélküldésnél, a wpcf7mailsent pedig akkor, ha a levél elküldése sikerült. Mérésre a wpcf7mailsent kell. Az űrlap azonosítója az event.detail.contactFormId értékben érkezik.

WPForms

Hivatalosan igazolt. A WPForms AJAX-küldés esetén sikeres beküldés után a wpformsAjaxSubmitSuccess jQuery-eseményt váltja ki az űrlapon. Ehhez az űrlap beállításaiban be kell kapcsolni az AJAX-os beküldést, különben az oldal újratöltődik. Az űrlap azonosítóját a form elem data-formid attribútumából olvashatod ki.

Elementor Pro

Saját tapasztalat. Az Elementor Pro űrlap-widgetje sikeres küldés után a submit_success jQuery-eseményt váltja ki az űrlap elemén. Azonosításra az űrlap name attribútuma használható, amelyet a widget beállításainál te adsz meg. Szakmai feltételezés: mivel az Elementor gyakran frissül, egy nagyobb verzióváltás után érdemes újra ellenőrizni, hogy az esemény neve változatlan-e.

Gravity Forms

Hivatalosan igazolt. A Gravity Forms a gform_confirmation_loaded jQuery-eseményt küldi, amikor egy AJAX-os űrlap szöveges visszaigazolása betöltődött, és második paraméterként megkapod az űrlap azonosítóját. Ha a visszaigazolás átirányításra van állítva, ez az esemény nem fut le, mert akkor valódi oldalbetöltés történik.

Így ellenőrzöd a konzolban

Nyisd meg az űrlapot tartalmazó oldalt, a fejlesztői eszközök konzoljába illessz be egy ideiglenes figyelőt, majd küldj el egy tesztüzenetet. Contact Form 7-nél natív eseményt figyelsz:

document.addEventListener('wpcf7mailsent', function (e) { console.log('CF7 siker', e.detail); });

A másik három bővítménynél jQuery-eseményt, mert a jQuery által kiváltott egyedi eseményt a natív addEventListener nem látja:

jQuery(document).on('submit_success wpformsAjaxSubmitSuccess gform_confirmation_loaded', function (e) { console.log('Sikeres küldés', e.type, e.target); });

Ha a konzolban megjelenik a sor, megvan a kiindulópont. Ha nem jelenik meg, nézd meg, hogy az űrlap valóban AJAX-szal küld-e, és hogy a jQuery betöltődött-e az oldalon.

Hogyan tolod az eseményt a dataLayer-be?

Röviden: egy Google Tag Manager Egyéni HTML címkében feliratkozol a bővítmény sikereseményére, és a figyelőben egy dataLayer.push hívással átadod a GTM-nek az esemény nevét és az űrlap azonosítóját.

Contact Form 7-hez a címke tartalma (a <script> tagek közé):

if (!window.cf7Figyelo) { window.cf7Figyelo = true; document.addEventListener('wpcf7mailsent', function (event) { window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'urlap_elkuldve', form_plugin: 'cf7', form_id: String(event.detail.contactFormId) }); }, false); }

WPForms-hoz:

if (!window.wpfFigyelo) { window.wpfFigyelo = true; jQuery(document).on('wpformsAjaxSubmitSuccess', function (event) { window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'urlap_elkuldve', form_plugin: 'wpforms', form_id: String(jQuery(event.target).attr('data-formid')) }); }); }

Gravity Forms-hoz:

if (!window.gfFigyelo) { window.gfFigyelo = true; jQuery(document).on('gform_confirmation_loaded', function (event, formId) { window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'urlap_elkuldve', form_plugin: 'gravity', form_id: String(formId) }); }); }

Elementor Pro-nál ugyanez a minta, a submit_success eseménnyel és a jQuery(event.target).attr('name') értékkel.

A kódok elején álló if (!window...) feltétel azt akadályozza meg, hogy a figyelő kétszer iratkozzon fel, ha a címke valamiért kétszer fut le ugyanazon az oldalon. Saját tapasztalat: a jQuery-alapú változatnál a címkét a DOM Ready vagy a Window Loaded triggerre tedd, ne az oldalmegtekintésre, mert optimalizáló bővítmények gyakran késleltetik a jQuery betöltését, és akkor a jQuery hívás hibát dob.

Hogyan építesz rá GTM-triggert és GA4-címkét?

Röviden: egy Egyéni esemény triggert hozol létre az urlap_elkuldve névre, két adatréteg-változót a paraméterekre, és egy GA4-eseménycímkét, amely ezeket továbbküldi.

1. Hozz létre két Adatréteg-változót form_plugin és form_id névvel.
2. Hozz létre egy Egyéni esemény típusú triggert, az esemény neve urlap_elkuldve legyen, pontos egyezéssel.
3. Készíts egy Google Analytics GA4-esemény címkét, az eseménynév urlap_elkuldve, a paraméterek pedig a két változó.
4. A GA4 Adminisztráció menüjében az Egyéni definícióknál regisztráld a form_id és a form_plugin paramétert eseményhatókörű egyéni dimenzióként. Hivatalosan igazolt: enélkül a paraméter nem jelenik meg a standard riportokban.
5. Az első beérkezett esemény után jelöld az urlap_elkuldve eseményt kulcseseménynek.

Ha Google Ads-konverziót is mérsz, ugyanezt a triggert használd a Google Ads konverziós címkéhez is. Így a két rendszer ugyanarra a sikereseményre épül, és az eltérést nem a kiváltó feltétel különbsége okozza.

Hogyan zárod ki a dupla tüzelést és a sikertelen küldést?

Röviden: csak a bővítmény sikereseményére építs, a figyelőt egyetlen helyen helyezd el, és nézd végig, hogy sehol máshol nem keletkezik ugyanilyen nevű vagy jelentésű esemény.

Saját tapasztalat. A dupla számolás leggyakoribb forrásai ezek.

• A figyelőkód a témában vagy egy kódbeillesztő bővítményben is benne van, nem csak a GTM-ben.
• Az oldalon egyszerre fut egy beégetett gtag-kód és a GTM-ből betöltött GA4, és mindkettő küldi az eseményt.
• A GA4-ben egy korábbi „Esemény létrehozása” szabály a form_submit vagy egy oldalmegtekintés alapján is létrehoz egy urlap_elkuldve eseményt.
• Az Űrlapinterakciók kapcsoló bekapcsolva maradt, és valaki a form_submit eseményt is kulcseseménynek jelölte.

A sikertelen küldés kizárása a helyes eseményválasztással kezdődik. Contact Form 7-nél a wpcf7submit helyett a wpcf7mailsent kell, a többi bővítménynél pedig a „success” vagy „confirmation” eseményt figyeld, soha nem az általános küldést. Szakmai feltételezés: a bővítmény „sikeres” jelzése annyit jelent, hogy a szerver elfogadta és továbbította az üzenetet. Azt nem jelenti, hogy a levél ténylegesen meg is érkezett a postafiókba, ezért van szükség a lenti összevetésre.

Mi legyen az ellenőrzőlistán élesítés előtt?

Röviden: minden űrlapot tesztelj GTM előnézetben és GA4 DebugView-ban, sikeres és szándékosan hibás kitöltéssel is, és csak akkor élesíts, ha egy küldés pontosan egy eseményt ad.

1. GTM előnézet. Egy sikeres küldés után az urlap_elkuldve pontosan egyszer jelenik meg, a GA4-címke pedig egyszer fut le.
2. DebugView-teszt. A GTM előnézet mód automatikusan hibakereső módba teszi a munkamenetet (hivatalosan igazolt), így a GA4 Adminisztráció, DebugView felületén másodperceken belül látod az eseményt a form_id és form_plugin paraméterrel.
3. Hibás kitöltés. Hagyj üresen egy kötelező mezőt, írj hibás e-mail-címet. Ilyenkor semmilyen urlap_elkuldve nem keletkezhet.
4. Dupla tüzelés. Küldd el ugyanazt az űrlapot kétszer egymás után oldalfrissítés nélkül. Két esemény a helyes, négy a hiba.
5. Automatikus esemény. A DebugView-ban ne jelenjen meg form_start és form_submit.
6. Több űrlap egy oldalon. Ha a láblécben és a tartalomban is van űrlap, mindkettő saját, eltérő form_id értéket küldjön.
7. Mobil. Egy tesztet telefonról is végezz el, mert a késleltetett szkriptbetöltés ott gyakrabban okoz eltérést.
8. Hozzájárulás. Nézd meg, mi történik, ha a látogató elutasítja a sütiket, hogy tudd, milyen eltérésre számíts a riportban.
9. Dokumentáció. Egy közös táblázatban rögzítsd, melyik form_id melyik űrlap és melyik oldal, mikor élesítetted, és milyen triggerre épül.

Hogyan veted össze a mért számot a ténylegesen beérkezett üzenetekkel?

Röviden: egy lezárt időszakra számold meg a CRM-be vagy a postafiókba ténylegesen beérkezett, valódi üzeneteket űrlaponként, és hasonlítsd a GA4 urlap_elkuldve eseményszámához. Teljes egyezés nem várható, de az eltérés iránya és nagysága megmutatja, hol keresd a hibát.

1. Válassz egy két-négy hetes, lezárt időszakot. Hivatalosan igazolt: a GA4 standard riportjaiban az adatok feldolgozása 24-48 órát is igénybe vehet, ezért a tegnapi napot még ne számold bele.
2. Gyűjtsd össze a beérkezett üzeneteket. Contact Form 7-hez a Flamingo bővítmény tárolja az üzeneteket, a Gravity Forms és az Elementor Pro saját beküldés-listát vezet, a WPForms fizetős változata szintén. Ha semmi nem tárol, a postafiók szűrt mappája is jó forrás.
3. Vedd ki a spamet és a saját tesztküldéseidet.
4. Bontsd űrlaponként, és állítsd mellé a GA4 számot form_id szerint.

Szakmai feltételezés. Ha a GA4 szám alacsonyabb, a leggyakoribb ok a sütik elutasítása, a reklámblokkolók és a késleltetett szkriptbetöltés. Hozzájárulási mód esetén a GA4 modellezhet is, ezért a pontos arány oldalanként eltér. Ha a GA4 szám magasabb, szinte mindig dupla tüzelés, bent maradt tesztküldés vagy olyan spam a gyanús, amelyet a bővítmény átengedett, de a postafiók kiszűrt. Saját tapasztalat: ha a GA4 többet mutat, mint amennyi üzenet beérkezett, azt mindig hibának kezeld, mert egy jól beállított mérés jó eséllyel kevesebbet lát a valóságnál, többet nem.

Az összevetést érdemes havonta megismételni, és minden bővítményfrissítés, témacsere vagy sütibanner-módosítás után külön is. Egy frissítés átnevezheti az eseményt, és a mérés csendben leáll anélkül, hogy bárki hibaüzenetet látna.

Források és további olvasnivalók

• Google Analytics súgó: Bővített mérés események
• Google Analytics súgó: Eseménygyűjtési korlátok és elnevezési szabályok
• Google Analytics súgó: DebugView és egyéni dimenziók
• Google Tag Manager súgó: Egyéni esemény trigger és adatréteg-változók
• Google for Developers: Google Analytics 4 és a dataLayer használata
• Contact Form 7 dokumentáció: DOM events
• WPForms fejlesztői dokumentáció
• Gravity Forms dokumentáció: gform_confirmation_loaded
• Elementor fejlesztői dokumentáció
• MDN Web Docs: EventTarget.addEventListener()