GA4 bővített mérés kapcsolóinak felülvizsgálata: mit hagyj bekapcsolva és mit ne

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

Mit csinál pontosan a GA4 bővített mérése?

A bővített mérés a GA4 webes adatfolyamának beépített funkciója, ami kódírás nélkül rögzít hét gyakori interakciót. Kényelmes, de minden kapcsoló külön döntés, mert ami az egyik oldalon hasznos adat, az a másikon zaj vagy duplikált esemény.

A kapcsolókat az Adminisztráció menü Adatfolyamok pontjában éred el. Kattints a webes adatfolyamra, majd a Bővített mérés sor fogaskerék ikonjára. Hivatalosan igazolt. A Google Analytics súgója szerint a változtatás csak az átállítás utáni adatgyűjtésre hat, a korábbi adatokat nem írja át. Az eseményeket a weboldalon futó Google-címke küldi, akár közvetlenül a gtag.js-ből, akár a Google Tag Managerben (GTM) beállított Google-címkéből.

A felülvizsgálat azért éri meg, mert a bővített mérés semmit nem tud a GTM-ben épített saját eseményeidről. Ha ugyanazt a kattintást, letöltést vagy beküldést két helyről is méred, két esemény érkezik, és a riportban minden duplán látszik. Ez a hiba sokáig rejtve marad, mert a számok első ránézésre hihetőek.

Mikor hasznos az oldalmegtekintés előzményváltozáskor?

Az előzményalapú oldalmegtekintés akkor ad használható adatot, ha az oldalad egyoldalas alkalmazás (SPA), ahol az URL újratöltés nélkül változik. Hagyományos, többoldalas weboldalon jellemzően felesleges, szűrős vagy füles felületen pedig hamis oldalmegtekintéseket termel.

Hivatalosan igazolt. Az oldalmegtekintés alapkapcsolója a bővített mérésen belül nem kapcsolható ki külön, a speciális beállításai között viszont kikapcsolhatod az „oldalváltozás a böngészőelőzmény-eseményei alapján” opciót. Ez a böngésző History API változásaira (pushState, replaceState, popstate) küld újabb page_view eseményt.

Ott okoz gondot, ahol egy termékszűrő, egy galéria vagy egy fülváltó is átírja az URL-t. Ilyenkor egy látogató egyetlen oldalon tíz oldalmegtekintést is összegyűjthet. A másik csapda a GTM, mert ha ott egy Előzményváltozás (History Change) aktiválóra már küldesz page_view eseményt, a két forrás egymásra rakódik. Szakmai feltételezés. Egy WordPress-alapú szolgáltatói oldalon ezt az opciót jó eséllyel nyugodtan kikapcsolhatod, de előtte DebugView-ban nézd meg, változik-e az URL valamilyen felületi elemre.

Mit mér a görgetés esemény, és mikor félrevezető?

A görgetés esemény oldalanként egyszer fut le, amikor a látogató eléri az oldal függőleges hosszának 90 százalékát. Hosszú cikkeknél ad némi képet az olvasottságról, rövid oldalakon szinte minden megtekintésre beérkezik, ezért ott értelmezhetetlen.

Hivatalosan igazolt. Az esemény neve scroll, a paramétere percent_scrolled, és a bővített mérés csak a 90 százalékos küszöböt figyeli. Köztes mélységet (25, 50, 75 százalék) nem mér.

Ha részletesebb görgetési adatra van szükséged, a GTM Görgetési mélység aktiválójával építs saját eseményt. Ilyenkor vagy kapcsold ki a bővített görgetést, vagy adj a saját eseménynek eltérő nevet, például scroll_depth. Ha a GTM-es eseményt is scroll néven küldöd, a 90 százalékos érték két forrásból érkezik, és a riportban összemosódik.

Mikor ad használható adatot a kimenő kattintás?

A kimenő kattintás akkor hasznos, ha a látogató egy másik domainre távozása üzleti jelentőségű, például partneroldalra, külső foglalási rendszerre vagy affiliate linkre kattint. Szennyezi a riportot, ha a saját domainjeid között nincs beállítva a domainek közötti mérés.

Hivatalosan igazolt. Az esemény neve click, és olyan paramétereket kap, mint a link_url, a link_domain és az outbound. A Google-címke beállításainál megadott domainekre mutató linkeket nem számolja kimenőnek.

Ha a webshopod egy aldomainen fut, vagy a foglalás egy saját, külön domainen zajlik, és ezt nem adtad meg a domainek konfigurálásánál, minden átlépés kimenő kattintásként és új munkamenetként jelenik meg. A másik gyakori ütközés az eseménynév. A click általános név, és ha a GTM-ben is click néven küldesz gombkattintásokat, a két adatkör egy eseménybe olvad. A saját eseményeidnek adj beszédes nevet, például cta_click.

Hogyan állítsd be a webhelyen belüli keresést?

A webhelyen belüli keresés akkor működik jól, ha a keresés eredményoldala URL-paraméterben adja át a keresett kifejezést. Az AJAX-os élő keresőt, ami nem tölt be új oldalt, ez a kapcsoló nem látja.

Hivatalosan igazolt. Az esemény neve view_search_results, a keresett szó a search_term paraméterbe kerül. Alapból a q, s, search, query és keyword paramétereket figyeli, és a speciális beállításokban további paramétereket adhatsz meg vesszővel elválasztva. A WordPress alapkeresője az s paramétert használja, így ott általában beállítás nélkül is beérkezik.

Figyelj az adatvédelemre is. A Google szabályai tiltják a személyazonosításra alkalmas adat (e-mail-cím, telefonszám) küldését, a látogatók pedig néha ilyet írnak a keresőmezőbe. Saját tapasztalat. A keresési kifejezések listája az egyik leghasznosabb tartalomötlet-forrás, mert megmutatja, mit nem talált meg a látogató a menüben.

Mikor működik a videóbevonódás?

A videóbevonódás csak beágyazott YouTube-videókat mér, és csak akkor, ha a beágyazás engedélyezi a JavaScript API-t. Vimeo-, saját tárhelyes vagy háttérvideóra nem ad adatot.

Hivatalosan igazolt. Három eseményt küld, ezek a video_start, a video_progress (10, 25, 50 és 75 százaléknál) és a video_complete. A beágyazási kódban az enablejsapi=1 paraméternek szerepelnie kell, például így.

<iframe src="https://www.youtube.com/embed/VIDEOAZONOSITO?enablejsapi=1"></iframe>

Zajt okoz az automatikusan induló, némított YouTube-videó, mert a video_start minden oldalbetöltéskor beérkezik, a látogató szándékától függetlenül. Szakmai feltételezés. A késleltetett betöltésű YouTube-bővítmények (amelyek előbb csak egy képet mutatnak) gyakran a kattintás után illesztik be az iframe-et, és ilyenkor az első esemény kimaradhat. Ezt mindig DebugView-ban teszteld.

Mit mér a fájlletöltés, és mikor duplikál?

A fájlletöltés minden olyan linkkattintást rögzít, ami egy ismert kiterjesztésű fájlra mutat, például PDF-, DOCX-, XLSX- vagy ZIP-fájlra. Szolgáltató cégnél az árlista, a referenciaanyag vagy a katalógus letöltése hasznos szándékjel lehet.

Hivatalosan igazolt. Az esemény neve file_download, paraméterei között van a file_extension, a file_name, a link_text és a link_url. A képformátumok (JPG, PNG) nincsenek a figyelt kiterjesztések között.

A duplikáció tipikus oka, hogy valaki korábban a GTM-ben is felépített egy Kattintás, Csak linkek aktiválót, ami a .pdf végű linkekre file_download eseményt küld. A bekapcsolt bővített méréssel együtt minden letöltés kétszer jelenik meg. Vagy a GTM-es címkét töröld, vagy a kapcsolót kapcsold ki, mindkettőt egyszerre ne futtasd.

Miért megbízhatatlan gyakran az űrlapinterakció?

Az űrlapinterakció a böngésző űrlapeseményeire figyel, ezért egy beküldési kísérletet mér, a sikeres beküldést viszont nem tudja megkülönböztetni tőle. Leadek számolására emiatt önmagában kockázatos.

Hivatalosan igazolt. Két eseményt küld. A form_start az első interakciónál fut le egy űrlappal a munkamenetben, a form_submit a beküldéskor. Paraméterei a form_id, a form_name, a form_destination és a form_submit_text.

Saját tapasztalat. Az AJAX-szal beküldő űrlapbővítményeknél a form_submit sokszor akkor is beérkezik, ha a validáció elbukik, és a látogató hibaüzenetet kap. Máskor pedig egyáltalán nem érkezik be, mert a bővítmény nem a szabványos beküldést használja. Ráadásul a hírlevél-feliratkozás, a fejlécbeli kereső, a belépés és a kosár mennyiségmezője is űrlap, így mind a form_start, mind a form_submit számát növeli.

Mikor kapcsold ki az űrlapinterakciót a saját űrlapesemény javára?

Kapcsold ki, amint van egy saját eseményed, ami csak a sikeres beküldés után fut le, és ezt jelölted meg kulcseseményként. Ilyenkor a form_submit már csak zajt ad, és könnyen összekeveredik a valódi leadszámmal.

A saját esemény legtisztább forrása az űrlapbővítmény sikeres beküldési visszajelzése vagy a köszönőoldal. Egy dataLayer-üzenet így nézhet ki, amit a GTM egy Egyéni esemény aktiválóval fog meg.

window.dataLayer = window.dataLayer || []; dataLayer.push({ event: 'generate_lead', form_name: 'ajanlatkeres' });

Akkor érdemes kikapcsolni, ha a következők közül legalább egy igaz.

• A form_submit száma tartósan nagyobb, mint a CRM-ben vagy a postafiókban ténylegesen beérkezett megkeresések száma.
• Több különböző célú űrlap fut az oldalon, és a riportban nem tudod őket szétválasztani.
• A GTM-ben már van sikeres beküldésre futó saját eseményed.
• A hirdetési fiókba importált konverziót a form_submit adja, ami a kampányoptimalizálást félreviheti.

Szakmai feltételezés. A form_start megtartása tájékoztató jelleggel hasznos lehet az űrlap-elhagyás becslésére, de mivel a kapcsoló a két eseményt együtt kezeli, ehhez is saját GTM-eseményre van szükség.

Hogyan ellenőrizd DebugView-ban, hogy egy kapcsoló ütközik-e a GTM-mel?

Egyetlen műveletet hajts végre a tesztoldalon, és nézd meg, hány esemény érkezik rá DebugView-ban. Ha ugyanaz az eseménynév ugyanabban a másodpercben kétszer jelenik meg, vagy két eltérő nevű esemény ugyanazt a dolgot méri, ütközést találtál.

Hivatalosan igazolt. A DebugView az Adminisztráció menü Adatmegjelenítés pontja alatt található, és csak a hibakeresési módban lévő eszközök eseményeit mutatja. Hibakeresési módot a GTM Előnézet (Tag Assistant) indít, de a debug_mode paraméterrel is bekapcsolhatod.

gtag('config', 'G-XXXXXXXXXX', { debug_mode: true });

A lépések sorban a következők.

1. Nyisd meg a GTM-ben az Előnézet módot, és csatlakoztasd a weboldalt.
2. A GA4-ben nyisd meg a DebugView-t, és a bal felső eszközválasztóban válaszd ki a saját böngésződet.
3. Várj, amíg a page_view és a session_start beérkezik, így tudod, hogy jó eszközt nézel.
4. Hajts végre egy műveletet, például tölts le egyetlen PDF-et vagy kattints egyetlen külső linkre.
5. Az idővonalon keresd az azonos nevű eseménypárt. Kattints mindkettőre, és nézd meg a paramétereiket. A bővített mérés eseményein a gyári paraméterek vannak (például link_domain), a GTM-esen a saját paramétereid.
6. A Tag Assistant felületén ellenőrizd, hogy az adott pillanatban lefutott-e GTM-es GA4-eseménycímke. Ha igen, és DebugView-ban két esemény van, a második a bővített mérésből jött.
7. Döntsd el, melyik marad. Kapcsold ki a bővített kapcsolót, vagy szüneteltesd a GTM-es címkét, majd közzététel után ismételd meg a tesztet.

Saját tapasztalat. A legtöbb ütközés a letöltésnél, a görgetésnél és az előzményalapú oldalmegtekintésnél bukkan fel, mert ezekre a GTM-ben is gyakran épülnek régi címkék. Érdemes minden kapcsolót külön tesztelni, egyszerre egy műveletet végezve.

Milyen beállítás illik egy szolgáltató céghez?

Szolgáltató cégnél a lead a fő cél, ezért a saját űrlapesemény és a hívásszándék mérése a lényeg, a bővített kapcsolók többsége csak kiegészítő adat.

• Az oldalmegtekintés maradjon, az előzményalapú opciót kapcsold ki, ha nem SPA az oldal.
• A görgetést hagyd bekapcsolva, ha van blogod, de konverzióként ne kezeld.
• A kimenő kattintás maradhat, ha partner- vagy foglalási oldalra vezetsz, és a saját domainjeid szerepelnek a domainbeállításban.
• A webhelyen belüli keresést kapcsold be, ha van keresőmező az oldalon.
• A videóbevonódást csak akkor hagyd bekapcsolva, ha van YouTube-beágyazásod enablejsapi=1 paraméterrel, és nincs automatikusan induló videó.
• A fájlletöltés maradjon, ha árlistát vagy anyagot adsz le, de előtte töröld a GTM-ben az ugyanezt mérő címkét.
• Az űrlapinterakciót kapcsold ki, és a sikeres beküldésre küldj saját generate_lead eseményt, ezt jelöld kulcseseménynek.

Milyen beállítás illik egy webshophoz?

Webshopnál a vásárlási folyamat e-kereskedelmi eseményei a mérés gerince, ezért a bővített kapcsolókat úgy állítsd, hogy ne zavarják a kosár és a pénztár adatait.

• Az előzményalapú oldalmegtekintést kapcsold ki, ha a kategóriaoldali szűrők vagy a termékvariáns-választó átírja az URL-t.
• A webhelyen belüli keresést kapcsold be, és ellenőrizd, hogy a webshopmotor keresési paramétere szerepel a listában.
• A kimenő kattintásnál add meg a domainbeállításban a fizetési szolgáltató domainjét, ha a vásárló onnan tér vissza, különben a visszatérés új munkamenetet és hibás forrásadatot okozhat.
• A görgetés jellemzően kevés döntési értéket ad, a terméklista végtelen görgetése mellett pedig torz is lehet.
• Az űrlapinterakciót kapcsold ki, mert a kosár, a kuponmező és a pénztár űrlapjai elárasztják az adatokat.
• A fájlletöltést csak akkor tartsd meg, ha letölthető termékleírást vagy használati útmutatót adsz.
• Minden változtatás után DebugView-ban futtass végig egy tesztvásárlást, és ellenőrizd, hogy a purchase egyszer érkezik be.

Szakmai feltételezés. A felülvizsgálatot érdemes negyedévente vagy minden nagyobb téma-, bővítmény- és GTM-módosítás után megismételni, mert egy új űrlapbővítmény vagy szűrőmodul csendben megváltoztathatja, mit lát a bővített mérés. Vezess egy rövid változásnaplót arról, melyik kapcsolót mikor és miért állítottad át, így a riportban látott törést később meg tudod magyarázni.

Források és további olvasnivalók

• Google Analytics Súgó, Bővített mérés események
• Google Analytics Súgó, DebugView és hibakeresési mód
• Google Analytics fejlesztői dokumentáció, Google-címke (gtag.js) és eseményparaméterek
• Google Tag Manager Súgó, aktiválótípusok (Előzményváltozás, Görgetési mélység, Egyéni esemény)
• Google Tag Assistant dokumentáció
• YouTube IFrame Player API dokumentáció
• W3C HTML specifikáció, a form elem és a submit esemény