Magento GA4 és szerver oldali mérés
A webáruház rendeléseinek egy része soha nem ér el a Google Analyticsig. Megmutatjuk, hol veszik el, miért a böngésző az oka és hogyan mérhető pontosan egy Magento 2 áruház.
A hiba nem a Google Analyticsben keletkezik, hanem a böngészőben
A legtöbb webáruház úgy néz a GA4 riportjára, mintha könyvelés lenne. A valóság az, hogy a klasszikus mérés a látogató böngészőjéből indul, a böngésző pedig ma már sok esetben nem engedi végig a kérést. Süti lejár, hozzájárulás hiányzik, bővítmény blokkol, a fizetési átirányítás közben elszakad a munkamenet. A rendelés a Magento adatbázisában ott van, a GA4-ben nincs.
Ez nem riportálási kényelmetlenség. A hirdetési rendszerek ebből az adatból tanulnak. Ha a vásárlások egy része nem jut vissza a Google Adsbe vagy a Metába, akkor az algoritmus rossz mintát kap, a licit a gyengébb közönségre megy el és a megtérülés úgy romlik, hogy közben a webáruházban semmi nem romlott el.
A szerver oldali mérés ezt a szakadékot zárja be. Az esemény nem a látogató böngészőjéből indul, hanem a Magento szerveréről, abban a pillanatban, amikor a rendelés ténylegesen létrejön.
Frissítve: 2026. augusztus 26.
Öt tényező dönti el, mennyire pontos ma egy Magento 2 webáruház konverziómérése.
| Süti élettartama a böngészőben | korlátos |
| Hozzájárulás kezelése (Consent Mode v2) | kötelező |
| Hirdetésblokkolás és tartalomszűrés | kockázat |
| Az esemény forrása: böngésző vagy szerver | ez a lényeg |
| Összevetés a Magento rendelésszámával | ellenőrzés |
Három pont, ahol a Magento webáruház adata elveszik
Mindhárom a böngésző oldalán történik, ezért egyik sem javul meg a GA4 beállításaiban.
A látogató hét nap múlva idegen lesz
A Safari és az iOS korlátozza a JavaScriptből írt sütik élettartamát, jellemzően hét napra. Aki hirdetésre kattint, majd két hét múlva vásárol, az új felhasználóként érkezik. A rendelés megvan, csak éppen forrás nélkül, tehát a kampány nem kapja meg az érdemét.
A mérőkód el sem indul
Reklámblokkoló, tartalomszűrő böngésző, vállalati proxy vagy szűrt DNS: a gtag és a Tag Manager konténer letöltése megakadhat. Ilyenkor a vásárlás lezajlik, a mérés viszont meg sem kezdődik. A böngészőből induló mérés minden ilyen esetben néma marad.
A fizetési átirányítás elszakítja a szálat
A Magento pénztára külön alkalmazásként fut, a bankkártyás fizetés pedig elviszi a látogatót a szolgáltatóhoz. A visszatérés néha nem a köszönő oldalra érkezik, néha a vásárló egyszerűen bezárja az ablakot. A purchase esemény pont ott hiányzik, ahol a legtöbbet érne.
A mérés átkerül a szerverre
Böngészőből induló mérésnél minden hirdetési rendszer külön kérést kap a látogató gépéről. Ha a böngésző blokkol, mindegyik kérés elmarad egyszerre. Szerver oldali mérésnél a webáruház szervere küldi tovább az eseményt, egyetlen megbízható forrásból.
Magento 2 alatt ez a rendelés mentéséhez kötött eseményre épül. Amikor a rendelés létrejön, a szerver összeállítja a purchase eseményt a valós kosártartalomból, az értékből és a szállítási díjból, majd elküldi a GA4 Measurement Protocol felé. A GA4 azonosítóit a látogatói sütiből olvassuk ki, így a szerverről küldött esemény ugyanahhoz a munkamenethez kapcsolódik, amelyben a látogató végigment az oldalon.
Ehhez nem kell külön mérőszerver a felhőben. A megoldás azon a szerveren fut, amelyen a webáruház is, tehát nincs új infrastruktúra és nincs havi felhőszámla.
Három út vezet a pontosabb méréshez
A különbség nem elsősorban az adatminőségben van, hanem abban, hogy hány rendszert kell hozzá üzemeltetni és mennyibe kerül a fenntartása.
| Megoldás | Mit igényel | Költség jellege | Adat teljessége |
|---|---|---|---|
| Csak böngészőoldali gtag vagy Tag Manager | Egy konténer a webáruházban | Nincs külön költség | Hiányos, a böngésző dönti el |
| Tag Manager szerver konténer felhőben | Külön mérőszerver, saját aldomén, folyamatos üzemeltetés | Havi felhőszámla plusz üzemeltetés | Jó, amíg valaki karban is tartja |
| Közvetlen szerver oldali mérés a Magento szerverről | Fejlesztés a meglévő környezetben | Egyszeri bevezetés | Teljes a rendelési eseményekre |
A szerver konténeres út nagy forgalomnál és sok párhuzamos mérési rendszer mellett indokolt. Egy közepes magyar webáruháznak jellemzően több üzemeltetést hoz, mint amennyi többlet adatot ad.
Mit mérünk egy Magento 2 webáruházban
A mérési terv nem eseménylista, hanem döntés arról, hogy melyik eseményt hol keletkeztetjük. Ez adja a különbséget a szép riport és a használható adat között.
view_item és view_item_list
Termékoldal és kategórialista. A rétegelt navigáció szűrt nézeteit nem küldjük külön listának, különben a riport szétesik több ezer variánsra.
add_to_cart és remove_from_cart
A kosár tényleges változásához kötve, nem a gomb kattintásához. Így a sikertelen kosárba tétel nem növeli mesterségesen a számot.
begin_checkout és add_payment_info
A pénztár lépéseihez kötve. Ebből látszik, melyik lépésnél esik ki a vásárló, ami a legtöbb webáruháznál a legnagyobb kihasználatlan tartalék.
purchase a szerverről
A rendelés mentésekor keletkezik, a Magento saját adataiból. Ha a böngészőből is megérkezik, a két eseményt közös azonosító alapján összevonjuk, tehát nem lesz dupla bevétel a riportban.
refund
Jóváírás kiadásakor. Enélkül a hirdetési megtérülés tartósan magasabbnak látszik a valóságosnál, ami rossz irányba viszi a költést.
Azonosítók a rendelés mellett
A kattintási azonosítót és a hasított vevői e-mail címet a rendeléshez kötjük. Ez adja az alapot a Google Ads Enhanced Conversions és a Meta Conversions API pontosabb párosításához.
A szerver oldali mérés nem a hozzájárulás megkerülése
Ezt érdemes az elején tisztázni, mert sok ajánlat pont az ellenkezőjét sugallja. Az adatvédelmi szabály nem arról szól, honnan indul a kérés, hanem arról, hogy mit kezelünk a látogatóról. Ha valaki nem járul hozzá a hirdetési célú adatkezeléshez, akkor a szerverről sem küldünk róla hirdetési azonosítót.
Amit a gyakorlatban beállítunk: a hozzájárulás állapota együtt utazik az eseménnyel, a Consent Mode v2 jelzései a süti sávból érkeznek, hozzájárulás nélkül pedig csak a névtelen, összesített adat marad. A vevő e-mail címe soha nem nyers formában megy tovább, hanem hasított értékként, amiből a személy nem fejthető vissza.
Az adatvédelmi tájékoztatót ehhez hozzá kell igazítani. Ez néhány bekezdés munka, viszont enélkül a legjobb mérés is hiányos jogi háttérrel működik.
| Hozzájárulás nélkül nincs hirdetési azonosító | mindig |
| Vevői e-mail csak hasítva | mindig |
| Consent Mode v2 a süti sávból | bekötve |
| Adatvédelmi tájékoztató kiegészítése | része a munkának |
Mit tartalmaz a bevezetés
- Mérési audit: mi mér ma a webáruházban, mi hiányzik, mekkora az eltérés a GA4 és a Magento rendelési listája között
- Az adatréteg rendbetétele a témában, akár Luma, akár Hyvä alapú
- Szerver oldali eseményküldés a Magento rendelési eseményeire
- GA4 és Google Ads összekötése, Enhanced Conversions bekötése
- Meta Conversions API, ha a webáruház hirdet ott
- Consent Mode v2 összekötése a süti sávval
- Dokumentáció és átadás, hogy a rendszer ne legyen fekete doboz
Hogyan derül ki, hogy tényleg működik
Az ígéret önmagában semmit nem ér, ezért a bevezetést mérhető elfogadási feltételhez kötjük.
- Egy valós rendelés végigkövetése a GA4 DebugView felületén, a teljes kosártartalommal
- Hét napos párhuzamos összevetés: a GA4 purchase darabszáma a Magento ugyanazon időszaki rendelésszámához mérve
- Bevétel egyeztetése, hogy a szállítási díj és az áfa kezelése egységes legyen a két rendszerben
- Duplikáció ellenőrzése, tehát hogy egy rendelés valóban egyszer szerepel
Az igazságforrás mindig a Magento rendelési listája. Amíg a két szám nem simul össze, addig a munka nincs kész.
Gyakori kérdések
Nem kerüli meg ez a sütiszabályokat?
Nem. A hozzájárulás állapota ugyanúgy érvényes a szerverről küldött eseményre. Ha a látogató elutasítja a hirdetési célú adatkezelést, akkor róla nem megy tovább hirdetési azonosító. A szerver oldali mérés a technikai veszteséget szünteti meg, nem a jogi keretet kerüli ki.
Kell hozzá külön szerver a felhőben?
Nem. A megoldás a webáruház meglévő szerverén fut, ezért nincs új aldomén, nincs külön konténer és nincs havi felhőszámla. A Tag Manager szerver konténeres út ettől függetlenül választható, csak nagyobb üzemeltetési terhet hoz.
Működik Hyvä témával és PWA-val?
A szerver oldali rész témától független, mert a Magento rendelési eseményéhez kapcsolódik. A böngészőoldali adatréteg viszont témánként eltér, ezért a Luma és a Hyvä esetében külön kell rendezni. PWA Studio alatt a fejlesztési rész nagyobb, ezt az audit után látjuk pontosan.
Mennyi idő a bevezetés?
Egy átlagos webáruháznál néhány munkanap a fejlesztés, utána egy hét az ellenőrzés. Sok bővítményt használó vagy erősen egyedi pénztárú áruháznál hosszabb. Pontos időt a mérési audit után mondunk.
Mi lesz a meglévő Tag Manager konténerrel?
Marad. A szerver oldali mérés kiegészíti a mostani rendszert, nem váltja le. A dupla számlálást közös eseményazonosító zárja ki, így egy rendelés egyszer szerepel a riportban.
Mennyibe kerül?
Az állapotfelmérés ingyenes és kötelezettségmentes. A bevezetés egyszeri fejlesztési tétel, a nagyságrendekről a Magento árak 2026 oldal ad részletes képet.
Kapcsolódó oldalak: Magento SEO és AI-láthatóság · Magento karbantartás és üzemeltetés · Magento tárhely és VPS szerver
Nézzük meg, mennyi rendelés hiányzik a riportjából
Az ingyenes állapotfelmérésben összevetjük a GA4 adatait a Magento rendelési listájával, majd írásban megkapja, hol veszik el a különbség és mennyibe kerül a javítása.
