Duplikált vásárlás esemény a GA4-ben és a köszönőoldal újratöltésének kiszűrése

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

Ha a GA4 több vásárlást mutat, mint amennyi rendelés a webshop adminjában szerepel, akkor a hirdetési fiókjaid is hamis képet kapnak. A Google Ads a duplán számolt konverziókból tanul, a megtérülési mutatóid szebbek a valóságnál, és a költségkeretről rossz adatok alapján döntesz. A hiba ráadásul csendes, mert semmi nem jelez, a riport egyszerűen jobbnak látszik a valóságnál.

Ebben a cikkben végigmegyünk azon, hogyan veszed észre a duplikált purchase eseményt, mi okozza, mire jó a transaction_id, és hogyan éred el, hogy egy rendelés csak egyszer kerüljön be a mérésbe. A végén kapsz egy havi egyeztető rutint és egy véleményt arról, mekkora eltéréssel lehet még együtt élni. A szövegben három jelölést használok. A Hivatalosan igazolt a Google dokumentációjában leírt működést jelenti, a Saját tapasztalat a webshopos mérési munkák során látott mintákat, a Szakmai feltételezés pedig a logikus, de hivatalosan meg nem erősített következtetést.

Honnan derül ki, hogy a GA4 több vásárlást rögzít, mint ahány rendelés van?

Onnan, hogy ugyanarra az időszakra a GA4 vásárlásszáma magasabb a webshop rendeléslistájánál, vagy ugyanaz a rendelésazonosító többször szerepel a GA4-ben. A második jel a pontosabb, mert az összesített számokban a duplázódást elfedheti az, hogy közben más rendelések a hozzájárulás hiánya miatt kimaradnak a mérésből.

A gyors ellenőrzés lépései a következők.

1. Nyiss egy új felfedezést (Explore) a GA4-ben, szabad formátumú táblával.
2. Dimenziónak vedd fel a tranzakcióazonosítót, mutatónak az eseményszámot és a vásárlásból származó bevételt.
3. Szűrj az esemény nevére, hogy csak a purchase maradjon.
4. Rendezd a táblát eseményszám szerint csökkenő sorrendbe.

Ha a lista tetején olyan azonosítók állnak, amelyeknél az eseményszám kettő vagy több, megvan a duplázódás. Külön figyeld azt a sort, ahol a tranzakcióazonosító üres vagy (not set). Ha ebben a sorban sok esemény gyűlik össze, akkor a webshop egyáltalán nem ad át azonosítót, és ez nagyobb baj, mint néhány duplán mért rendelés.

Saját tapasztalat. A gyanút sokszor az kelti fel először, hogy egy átlagos napon hirtelen megugrik a bevétel, miközben a rendelések száma a webshopban a megszokott. Ilyenkor érdemes megnézni, nincs-e egy nagy értékű rendelés, amelynek a köszönőoldalát valaki többször megnyitotta.

Mi okozza leggyakrabban a duplikált purchase eseményt?

A legtöbb esetben az, hogy a purchase esemény a köszönőoldal betöltéséhez van kötve, és az oldal minden újabb betöltése ismét elküldi. A mérőkód nem tudja magától, hogy ezt a rendelést már jelentette, ezért minden oldalmegtekintést új vásárlásként kezel.

A tipikus helyzetek a következők.

• A köszönőoldal frissítése. A vásárló újratölti az oldalt, mert nem biztos benne, hogy a rendelés átment, vagy látni szeretné az összesítőt.
• Visszalépés a böngészőben. A rendelés után továbbkattint, majd a vissza gombbal újra a köszönőoldalra érkezik.
• Visszaállított böngészőfül. Mobilon a böngésző a háttérből előhozva újratölti a nyitva hagyott lapot, akár napokkal később.
• E-mailből újranyitott rendelésoldal. A visszaigazoló levélben lévő link egyes rendszerekben ugyanarra a köszönőoldalra visz, ahol a mérőkód is fut.
• Dupla mérés. A webshop beépülő modulja és a GTM is küld purchase eseményt, vagy ugyanaz a címke két aktiválási szabályra indul.
• Fizetési szolgáltató utáni visszairányítás. A fizetőoldalról visszatérve a vásárló kétszer jut el a visszaigazolásig, például egy köztes átirányító oldal miatt.

Saját tapasztalat. A dupla mérés a legkönnyebben javítható, mégis sokáig észrevétlen marad, mert minden rendelés pontosan kétszer szerepel, így az arányok hihetőnek tűnnek. Az újratöltésből eredő duplázódás ezzel szemben szórványos, a rendelések kisebb részét érinti, és főleg a nagyobb kosárértékű vásárlásoknál fordul elő, ahol a vevő többször visszanéz az összesítőre.

Mit csinál a transaction_id, és miért nem elég önmagában?

A transaction_id a rendelés egyedi azonosítója, amely alapján a GA4 felismeri, hogy ugyanazt a vásárlást többször kapta meg. Ez a paraméter a deduplikáció alapja, és nélküle a rendeléslistával való egyeztetés sem végezhető el.

Hivatalosan igazolt. A Google Analytics súgója szerint a GA4 az ugyanattól a felhasználótól érkező, azonos tranzakcióazonosítójú vásárlásokat deduplikálja. A dokumentáció azt is kiemeli, hogy az azonosítónak minden rendelésnél egyedinek kell lennie, és üres értéket nem szabad küldeni, mert az üres azonosítójú vásárlásokat a rendszer egymás duplikátumának tekintheti. A Google Ads konverziókövetése szintén a tranzakcióazonosítót használja az ismétlődő konverziók kiszűrésére.

A beépített védelem három ponton szokott elvérezni.

• A webshop nem ad át azonosítót, vagy az érték üres szöveg, undefined, esetleg minden rendelésnél ugyanaz.
• Az azonosító formátuma változik a betöltések között, például egyszer a belső sorszám, máskor az előtaggal ellátott rendelésszám megy ki.
• A második esemény másik eszközről vagy másik böngészőből érkezik, ahol a GA4 új felhasználót lát.

Szakmai feltételezés. A dokumentáció az azonos felhasználóra szűkíti a deduplikációt, ebből az következik, hogy az e-mailből másik eszközön megnyitott köszönőoldal purchase eseménye átcsúszhat a szűrőn. Ezt a Google külön nem részletezi, ezért érdemes úgy tervezni, mintha a GA4 védelme csak az azonos böngészőben történő újratöltést fogná meg.

Saját tapasztalat. A deduplikáció a feldolgozott riportokban érvényesül. A BigQuery exportban a nyers események jellemzően megmaradnak, és a GTM-ből indított többi címke, például a Meta vagy más hirdetési rendszer konverziós kódja, a GA4 szűréséből semmit nem lát. Ha a forrásnál nem állítod meg a dupla küldést, a többi platformon a hiba megmarad.

Hogyan biztosítod a webshop oldalán, hogy a vásárlás csak egyszer menjen ki?

Úgy, hogy a webshop a rendeléshez elment egy jelölőt az első sikeres megjelenítéskor, és a mérési adatokat csak akkor írja ki az oldalra, ha ez a jelölő még nincs meg. Ez a szerveroldali megoldás a legmegbízhatóbb, mert független a böngészőtől, az eszköztől és a sütiktől.

A logika minden webshopmotorban ugyanaz.

1. A köszönőoldal betöltésekor a rendszer lekéri a rendelést.
2. Megnézi, van-e rajta mérési jelölő, például egy mert_vasarlas nevű egyedi mező.
3. Ha nincs, kiírja a purchase adatokat az adatrétegbe, majd elmenti a jelölőt.
4. Ha van, az oldal megjelenik a vásárlónak, de az adatréteg-küldés kimarad.

Az adatrétegbe kerülő blokk vázlata így néz ki.

dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'R-2026-004512', value: 18990, currency: 'HUF', items: [ ... ] } });

WooCommerce esetén a rendelés metaadata alkalmas a jelölő tárolására, és a legtöbb mérési beépülő modul tartalmaz ilyen kapcsolót. Bérelhető webshopmotoroknál a szolgáltató beállításai között érdemes keresni, vagy az ügyfélszolgálattól megkérdezni, hogy a köszönőoldal ismételt megnyitásakor újra kiírják-e az adatokat.

Saját tapasztalat. A szerveroldali jelölőnek van egy mellékhatása. Ha a vásárló első betöltéskor elutasította a mérési hozzájárulást, majd később elfogadja, a rendelés már jelöltként szerepel, és nem kerül be a mérésbe. Ez a hiány irányába torzít, ami kisebb baj a duplázódásnál, de jó tudni róla az egyeztetéskor.

Hogyan szűröd ki a köszönőoldal újratöltését GTM-ben?

GTM-ben úgy, hogy a böngészőben eltárolod a már elküldött rendelésazonosítókat, és a purchase címkére kivételt állítasz be arra az esetre, ha az aktuális azonosító már szerepel a listában. Ez akkor hasznos, ha a webshop kódjához nem férsz hozzá, vagy második védvonalat szeretnél.

A beállítás négy elemből áll.

1. Adatréteg-változó, amely kiolvassa az ecommerce.transaction_id értékét.
2. Egyéni JavaScript-változó, amely megmondja, hogy az azonosító szerepel-e a böngésző helyi tárolójában.
3. Kivétel típusú aktiválási szabály a purchase címkén, amely akkor él, ha a változó értéke igaz.
4. Egy egyéni HTML-címke, amely a purchase címke sikeres lefutása után (címkesorrenddel) beírja az azonosítót a tárolóba.

Az egyéni JavaScript-változó törzse nagyjából ennyi.

function() { var id = {{DLV - transaction_id}}; if (!id) { return true; } var lista = (localStorage.getItem('elkuldott_rendelesek') || '').split(','); return lista.indexOf(String(id)) !== -1; }

A változó üres azonosítónál is igazat ad vissza, vagyis azonosító nélkül nem megy ki vásárlás. Ez szándékos, mert az azonosító nélküli purchase esemény később sem egyeztethető semmivel. Az utólagos beíró címke lényege egyetlen sor.

localStorage.setItem('elkuldott_rendelesek', lista.concat(id).join(','));

Ugyanezt a kivételt tedd rá minden olyan címkére, amely a vásárlásra indul, tehát a Google Ads konverzióra és a többi hirdetési rendszer kódjára is. Így a szűrés egy helyen dől el, és minden platform ugyanazt a rendelésszámot kapja.

Szakmai feltételezés. A böngészőoldali tárolás csak az adott böngészőben véd. Másik eszközön, privát ablakban vagy törölt tárolóval az azonosító ismeretlen lesz, ezért ez a módszer a szerveroldali jelölőt kiegészíti, kiváltani nem tudja. A helyi tároló használatát a sütikezelési tájékoztatóban is érdemes szerepeltetni, a pontos jogi besoroláshoz kérd ki az adatvédelmi szakértőd véleményét.

Hogyan néz ki a havi egyeztetés a rendeléslista és a GA4 között?

A havi egyeztetés egy rendelésazonosító szintű összevetés, amely megmutatja, mely rendelések szerepelnek mindkét rendszerben, melyek hiányoznak a GA4-ből, és melyek szerepelnek ott többször. Egy táblázatkezelővel elvégezhető, és a hónap lezárása után érdemes megcsinálni.

1. Exportáld a webshop rendeléseit az előző naptári hónapra, rendelésazonosítóval, dátummal, állapottal, fizetési móddal és végösszeggel.
2. Exportáld a GA4 felfedezést ugyanerre az időszakra tranzakcióazonosítóval, eseményszámmal és bevétellel.
3. Ellenőrizd az időzónát mindkét rendszerben, mert az éjfél körüli rendelések különben átcsúsznak a szomszédos hónapba.
4. Kösd össze a két listát azonosító alapján egy keresőfüggvénnyel.
5. Sorold három csoportba a rendeléseket. Az első csoportban mindkét helyen megvannak, a másodikban csak a webshopban, a harmadikban a GA4-ben többször vagy csak ott.
6. Számolj két arányt. Az egyik a GA4-ből hiányzó rendelések aránya, a másik a többször mért rendeléseké.
7. Nézd meg a mintázatot. A hiányzók között sok az utánvétes vagy átutalásos rendelés? A duplázódók egy fizetési módhoz vagy egy eszköztípushoz köthetők?
8. Jegyezd fel az eredményt egy állandó táblába, hogy a hónapok összehasonlíthatók legyenek.

Saját tapasztalat. A bevétel összevetésénél gyakran okoz látszólagos eltérést, hogy az egyik rendszer bruttó, a másik nettó értéket mutat, vagy a szállítási díj az egyikben benne van, a másikban nincs. A törölt és visszatérített rendelések kezelését is rögzítsd előre, különben minden hónapban máshogy számolsz. Az egyeztetésnek akkor van értelme, ha a szabályai hónapról hónapra változatlanok.

Mekkora eltérés fogadható még el, és miért?

A véleményem szerint a két irányt külön kell megítélni. A GA4-ből hiányzó rendeléseknél egy mérsékelt, stabil hiány elfogadható, a többször mért rendeléseknél viszont a cél a nulla közeli érték. A hiány a mérés természetéből fakad, a többlet technikai hiba, amely kijavítható.

Hivatalosan igazolt. A GA4 csak azokat az eseményeket rögzíti teljes értékűen, amelyekhez a látogató hozzájárult, és a hozzájárulási mód beállításától függ, mi történik a többivel. A böngészők követésvédelme és a hirdetésblokkolók szintén megakadályozhatják az esemény elküldését. Ebből következően a GA4 rendelésszáma a valós rendelésszám alatt marad.

Saját tapasztalat. Hozzájárulás-kezelővel működő magyar webshopoknál a rendelések nagyjából 5-15 százalékának hiánya a GA4-ből megszokott tartomány. Ha a hiány ennél nagyobb, vagy egyik hónapról a másikra megugrik, akkor a sütisáv beállítását, a fizetési szolgáltató utáni visszairányítást és az utánvétes rendelések köszönőoldalát érdemes átnézni. Ezek tájékoztató értékek, hivatalos küszöb erre nem létezik, és a vásárlóközönség összetétele erősen befolyásolja.

A többletnél szigorúbb vagyok. Ha a többször mért rendelések aránya 1-2 százalék fölé megy, azt javítandó hibának tekintem, akkor is, ha az összesített szám közben szépen egyezik. Ennek három oka van.

• A duplán mért vásárlás a hirdetési rendszerek automatikus ajánlattételét torzítja, mert a rendszer a ténylegesnél értékesebbnek látja az adott kampányt vagy közönséget.
• A duplázódás a nagy kosárértékű rendeléseknél gyakoribb, így a bevételben nagyobb torzítást okoz, mint a darabszámban.
• A hiány és a többlet kiolthatja egymást, ezért az egyező összesítés mögött két külön hiba is megbújhat.

Szakmai feltételezés. A stabil eltérés kevésbé veszélyes, mint az ingadozó. Ha a GA4 hónapról hónapra hasonló arányban marad el a webshoptól, a trendek és a kampányok egymáshoz viszonyított teljesítménye jó eséllyel megbízhatóan olvasható. Ha az arány ugrál, a hónapok közötti összehasonlítás bizonytalanná válik, még akkor is, ha az átlagos eltérés kicsi.

Milyen hibákat érdemes elkerülni javítás közben?

A leggyakoribb hiba az, hogy a duplázódás megszüntetése közben a mérés a másik irányba billen, és valós rendelések esnek ki. Javítás után ezért mindig tesztelj végig egy teljes vásárlást, és nézd meg az eredményt a GTM előnézetében és a GA4 hibakereső nézetében.

• Teszteld a köszönőoldal frissítését, a visszalépést és az e-mailből való megnyitást is, minden fizetési módnál.
• Ellenőrizd, hogy a tesztrendelések azonosítója nem ütközik valós rendeléssel.
• Ne módosítsd utólag a rendelésazonosító formátumát az egyeztetés rögzítése nélkül, mert a régi és az új hónapok nem lesznek összevethetők.
• A javítás dátumát írd fel megjegyzésként, hogy a korábbi időszak felfújt számait később senki ne tekintse visszaesésnek.
• A javítás utáni első hónapban végezd el soron kívül az egyeztetést, és vesd össze a két arányt a korábbiakkal.

A pontos vásárlásmérés nem garantál jobb kampányeredményt, de segítheti, hogy a döntéseid valós rendelésekre épüljenek. A havi egyeztetés pedig jó eséllyel még azelőtt jelzi a következő mérési hibát, hogy az a hirdetési költésben is megjelenne.

Források és további olvasnivalók

• Google Analytics Súgó, az ismétlődő kulcsesemények minimalizálása tranzakcióazonosítóval
• Google for Developers, GA4 e-kereskedelmi mérés (purchase esemény és paraméterei)
• Google Tag Manager Súgó, aktiválási szabályok, kivételek és címkesorrend
• Google Ads Súgó, tranzakcióazonosító használata az ismétlődő konverziók kiszűrésére
• Google Analytics Súgó, hozzájárulási mód (Consent Mode)
• Google Analytics Súgó, BigQuery export séma
• WooCommerce fejlesztői dokumentáció, rendelések és rendelés-metaadatok