GA4 e-kereskedelmi események ellenőrzése a terméklistától a vásárlásig

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

A GA4 e-kereskedelmi mérése akkor ér valamit, ha a vásárló útjának minden lépése beérkezik, és minden lépés ugyanazt a terméket ugyanúgy írja le. A gyakorlatban sok webshopban csak a purchase esemény él, vagy él az egész lánc, de az árak, a pénznem és a lista-adatok eseményről eseményre mást mutatnak. Ez a cikk végigmegy az ajánlott eseményeken, és megmutatja, hogyan ellenőrizd őket a DebugView-ban és a böngésző fejlesztői eszközeiben.

A szövegben háromféle jelölést használok. Hivatalosan igazolt az, ami a Google Analytics dokumentációjában szerepel. Saját tapasztalat az, amit webshopok mérésének átnézésekor rendszeresen látunk. Szakmai feltételezés az, ami logikusan következik, de nincs rá hivatalos megerősítés.

Melyik GA4 eseményekből áll az e-kereskedelmi lánc?

Az ajánlott lánc hét eseményből áll, a terméklista megjelenésétől a sikeres fizetésig. Ha bármelyik hiányzik, a tölcsér azon a ponton megszakad, és a riport hamis lemorzsolódást mutat.

1. view_item_list a terméklista (kategóriaoldal, keresési találatok, kapcsolódó termékek blokk) megjelenésekor.
2. select_item amikor a látogató egy listából rákattint egy termékre.
3. view_item a termékoldal betöltésekor.
4. add_to_cart kosárba tételkor.
5. begin_checkout a pénztár indításakor.
6. add_payment_info a fizetési mód megadásakor.
7. purchase a sikeres rendelés után, a köszönőoldalon vagy a visszaigazolás pillanatában.

Hivatalosan igazolt: a Google ezeket ajánlott eseményként dokumentálja, rögzített paraméternevekkel. A lánc része még az add_shipping_info, a view_cart és a remove_from_cart is, ezek hiánya kevésbé fáj, de a kosárelhagyás elemzéséhez hasznosak.

Saját tapasztalat: a leggyakrabban kimaradó két esemény a view_item_list és a select_item. A sablonos webshop-bővítmények egy része csak a termékoldaltól mér, és ezt a tulajdonos ritkán veszi észre, mert a bevétel ettől még látszik.

Milyen paraméterek kellenek az egyes eseményekhez?

Minden eseménynek kell egy items tömb, a pénzt hordozó eseményeknek pedig currency és value. A purchase eseményhez ezen felül kötelező a transaction_id.

• Lista-események (view_item_list, select_item): item_list_id, item_list_name, items.
• Termék- és kosár-események (view_item, add_to_cart): currency, value, items.
• Pénztár-események (begin_checkout, add_payment_info): currency, value, coupon, items, a fizetésnél payment_type is.
• Vásárlás (purchase): transaction_id, currency, value, tax, shipping, coupon, items.

Hivatalosan igazolt: ha a value paramétert küldöd, a currency is kötelező, különben a bevételi metrikák nem számolódnak. Az items tömb minden elemében legalább az item_id vagy az item_name meg kell legyen.

Hogyan nézzen ki egy jó items elem?

Egy jól felépített elem az azonosítón és a néven túl a márkát, a kategóriát, a változatot, az egységárat, a mennyiséget és a lista-adatokat is tartalmazza. A lenti példában a változónevek helyén a webshop saját adatai állnak.

gtag('event', 'add_to_cart', { currency: 'HUF', value: kosarErtek, items: [{ item_id: termek.sku, item_name: termek.nev, item_brand: termek.marka, item_category: termek.fokategoria, item_category2: termek.alkategoria, item_variant: termek.valtozat, item_list_id: 'kategoria_' + kategoriaSlug, item_list_name: kategoriaNev, index: pozicio, price: termek.egysegAr, discount: termek.kedvezmeny, quantity: darab }] });

Hivatalosan igazolt: a price mező az egységár, kedvezmény esetén a már kedvezményes egységár, a kedvezmény összege pedig a discount mezőbe kerül. A value jellemzően az elemek ár és mennyiség szorzatának összege.

Hogyan ellenőrizd az eseményeket a DebugView-ban?

A DebugView valós időben, eseményenként mutatja a beérkező adatokat, ha a böngésződ debug módban küld. Ezt a Google Tag Assistant előnézeti módjával, a Google Tag Manager Preview funkciójával vagy a debug_mode paraméterrel érheted el.

A folyamat lépésről lépésre így néz ki.

1. Nyisd meg a GA4-ben az Adminisztráció menüben a DebugView-t.
2. Indítsd el a Tag Assistant előnézetet a webshop címével.
3. Járd végig a teljes vásárlási utat egy tesztrendeléssel, a kategóriaoldaltól a köszönőoldalig.
4. A DebugView idővonalán kattints rá minden e-kereskedelmi eseményre, és nyisd le a paramétereket, valamint az Items fület.
5. Jegyezd fel eseményenként, mi érkezett meg és mi hiányzik.

Ellenőrzőlista a DebugView-hoz

• Mind a hét esemény megjelenik az idővonalon, a megfelelő sorrendben?
• A view_item_list eseményben van item_list_name, és az a valódi kategória nevét mutatja?
• A select_item ugyanazt a lista-nevet és lista-azonosítót viszi, mint az előző listamegjelenés?
• Minden pénzt hordozó eseményben ott a currency, és mindenhol ugyanaz a háromjegyű ISO kód (például HUF vagy EUR)?
• A value szám típusú, pont a tizedesjel, és nincs benne szóköz vagy pénznemjel?
• Az item_id ugyanaz a termékoldalon, a kosárban és a vásárlásban?
• A pénztár-eseményekben és a vásárlásban megjelenik a coupon, ha használtál kupont a teszt során?
• A purchase eseményben van transaction_id, és az megegyezik a webshop admin felületén látható rendelésszámmal?

Saját tapasztalat: a DebugView néha késve vagy hiányosan mutatja a gyorsan egymás után érkező eseményeket, főleg átirányításos fizetésnél. Ha egy esemény hiányzik, mielőtt hibát állapítasz meg, nézd meg a hálózati forgalmat is.

Mit nézz a böngésző fejlesztői eszközeiben?

A böngésző hálózati lapja megmutatja, mi ment ki ténylegesen a GA4 felé, függetlenül attól, hogy a felület mit jelenít meg. Ez a leggyorsabb módja annak, hogy elválaszd a mérési hibát a megjelenítési késéstől.

1. Nyisd meg a fejlesztői eszközöket, és válts a Network fülre.
2. Szűrj a collect szóra, így csak a GA4 kérések maradnak láthatók.
3. Kapcsold be a naplómegőrzést (Preserve log), különben a köszönőoldalra érkezéskor elveszik a korábbi kérés.
4. Kattints egy kérésre, és nézd meg a lekérdezési paramétereket és a kérés törzsét.

Saját tapasztalat: a kérésben az en paraméter az esemény neve, a cu a pénznem, a termékek pedig pr1, pr2 és így tovább formában érkeznek, a mezőket hullámvonallal elválasztva. Több esemény egy kérésbe is összevonódhat, ilyenkor a törzsben soronként találod őket.

Ellenőrzőlista a fejlesztői eszközökhöz

• A konzolban nézd meg a dataLayer tartalmát, és ellenőrizd, hogy minden e-kereskedelmi push előtt van-e ecommerce: null törlés, különben az előző esemény termékei átszivároghatnak.
• A köszönőoldal frissítésekor nem indul újabb purchase kérés?
• Fizetési szolgáltatótól visszatérve is kimegy a vásárlás, vagy elveszik a munkamenet?
• A sütihozzájárulás elutasításakor a beállított Consent Mode szerint viselkedik a mérés?

Miért kiemelt az items tömb, a pénznem és a tranzakció-azonosító?

Ez a három elem dönti el, hogy a bevételi és termékriportok összeadhatók és összevethetők-e. Ha bármelyik hibás, a riport számol, csak rossz számot mutat, és ez veszélyesebb a hiányzó adatnál.

Az items tömb a termékszintű riportok forrása. Ha az item_id a termékoldalon SKU, a vásárlásban viszont belső adatbázis-azonosító, a GA4 két külön terméknek látja ugyanazt az árut, és a nézettségből vásárlásba vezető arány értelmezhetetlen lesz.

A pénznem akkor okoz gondot, ha több nyelvű vagy több pénznemű a webshop. Hivatalosan igazolt: a GA4 a beérkező összegeket a tulajdon pénznemére váltja át, ha a currency helyesen érkezik. Ha viszont a pénznem fixen HUF egy euróban fizető vásárlónál, a bevétel nagyságrendekkel elcsúszik.

A tranzakció-azonosító a duplikációt szűri. Hivatalosan igazolt: az azonos transaction_id értékkel érkező ismételt vásárlást a GA4 kiszűri. Ebből következik, hogy az üres, a fix vagy a véletlenszerűen generált azonosító egyformán rossz. Az üres vagy fix érték miatt valódi rendelések tűnhetnek el, a minden betöltéskor újragenerált érték pedig átengedi a köszönőoldal frissítéséből adódó duplikációt.

Melyek a leggyakoribb hibák?

A tipikus hibák nem okoznak hibaüzenetet, ezért csak tudatos ellenőrzéssel derülnek ki. Az alábbiakat látjuk a legtöbbször.

Hiányzó lista-név

A view_item_list és a select_item lefut, de az item_list_name üres, vagy minden oldalon ugyanaz az általános érték áll benne, például „termeklista”. Saját tapasztalat: ez főleg akkor fordul elő, ha a sablon egyetlen közös lista-komponenst használ a kategóriaoldalon, a keresési találatoknál és a kapcsolódó termékeknél. A javítás az, hogy a lista-név a kategória valódi nevét vagy a blokk szerepét kapja meg.

Nettó és bruttó ár keveredése

A termékoldalon a price nettó, a vásárlásban a value bruttó, vagy fordítva. Saját tapasztalat: ezt az okozza, hogy a termékoldal adatát a sablon, a rendelés adatát a pénztár-bővítmény állítja elő, más forrásból. A Google nem írja elő, hogy nettót vagy bruttót küldj. A lényeg a következetesség, és hogy az ÁFA a tax, a szállítás a shipping mezőbe kerüljön, ne olvadjon bele észrevétlenül az értékbe.

Kupon nélküli adat

A vásárló kuponnal fizet, de a coupon paraméter sehol nem jelenik meg, vagy csak a purchase eseményben. Szakmai feltételezés: kupon-adat nélkül egy akció hatását csak a dátumok alapján tudod becsülni, ami a párhuzamosan futó kampányok miatt jó eséllyel félrevezető. Érdemes a kupont rendelés- és termékszinten is küldeni, ha a webshop termékszintű kedvezményt is kezel.

További gyakori hibák

• A value szövegként érkezik ezres elválasztóval.
• A purchase a köszönőoldal minden frissítésekor újra lefut.
• A kosár-eseményben a teljes kosár szerepel, nem csak a most hozzáadott tétel.
• A termékváltozat a névbe kerül, így ugyanaz a termék tucatnyi néven jelenik meg.

Miért nem értékelhetők a kategóriaoldalak terméklista-adatok nélkül?

A saját nézőpontom az, hogy lista-adatok nélkül a kategóriaoldalakról csak forgalmi adatod van, teljesítményadatod nincs. Látod, hányan nyitották meg az oldalt, de azt nem, hogy a megjelenített termékekből hányra kattintottak, és ebből mennyi vásárlás lett.

A view_item_list és a select_item együtt adja meg a lista átkattintási arányát. Ha a lista-név és a lista-azonosító a kosár- és vásárlási eseményekben is továbbmegy, az is látszik, melyik kategória hozza a bevételt. Az index paraméterből pedig az derül ki, hogy a lista elején álló termékek mennyivel jobban teljesítenek, mint a lap alján lévők.

Szakmai feltételezés: a kategóriaoldalak rendezésére, szűrőire és a kiemelt termékekre vonatkozó döntések e nélkül jórészt megérzésen alapulnak. Egy A/B teszt is csak akkor mérhető tisztán, ha a lista-szintű események megbízhatóak. A jó mérés önmagában nem javít a konverzión, de segítheti, hogy a változtatásaidat adatra építsd.

Hivatalosan igazolt: a GA4 termékriportjaiban a lista-név és a lista-pozíció külön dimenzióként érhető el, ha az eseményekben megérkezik. Ha üres, a riportban „(not set)” érték jelenik meg.

Milyen sorrendben érdemes javítani a hibákat?

Először a vásárlást hozd rendbe, utána a pénznemet és az items tömböt, végül a lista-eseményeket. A bevétel pontossága hat a legtöbb döntésre, ezért azzal kezdj.

1. A purchase egyszer fusson le, egyedi transaction_id értékkel, helyes currency és value mellett.
2. Az item_id legyen egységes minden eseményben.
3. Dönts a nettó vagy bruttó logikáról, és vezesd át minden eseményen.
4. Pótold a coupon paramétert a pénztár-eseményekben és a vásárlásban.
5. Építsd be a view_item_list és select_item eseményeket valódi lista-nevekkel.
6. Minden javítás után járd végig újra a teljes tesztrendelést.

Saját tapasztalat: a javítás után érdemes néhány napig összevetni a GA4 vásárlásainak számát a webshop admin felületén látható rendelésekkel. Teljes egyezés ritkán lesz a hozzájárulás-kezelés és a hirdetésblokkolók miatt, de a tartósan nagy eltérés még mérési hibát jelez.

Források és további olvasnivalók

• Google Analytics súgó: Ajánlott események
• Google for Developers: GA4 e-kereskedelmi mérés (Measure ecommerce)
• Google Analytics súgó: Események ellenőrzése a DebugView-ban
• Google Tag Manager súgó: Előnézet és hibakeresés
• Google for Developers: Consent Mode dokumentáció
• ISO 4217 pénznemkód-szabvány