Miért mutat kevesebb vásárlást a GA4, mint a webshopod?

A webshop adminisztrációjában több rendelést látsz, mint a Google Analytics 4-ben. A bevétel sem egyezik, a hirdetési riport pedig egy harmadik számot mutat. Ilyenkor könnyű arra gondolni, hogy elromlott a mérés, vagy nem megbízható a kampányokról kapott beszámoló.

Az eltérés valóban jelezhet hibát, de önmagában még nem bizonyítja azt. Előfordulhat, hogy más rendelési állapotot, más időpontot vagy más bevételi tartalmat hasonlítasz össze.

A helyes ellenőrzési sorrend: először egyeztesd a fogalmakat és az időszakot, utána a rendelésazonosítókat, végül teszteld a hiányzó vagy hibás eseményeket. Ne az összesített számokból próbáld kitalálni, hol szakadt meg az adatküldés.

Először tisztázd, mit hasonlítasz össze

A webshop rendeléslistája, az analitikai rendszer és a hirdetési riport nem ugyanarra a kérdésre válaszol.

Az első vizsgálatban a webshop webes rendeléseit a GA4 összes webes vásárlásával vesd össze. Ne csak a Google Ads forrásra szűrt vásárlásokat nézd, és ne keverd a rendelésszámot az eladott termékdarabszámmal: egyetlen rendelésben több termék is lehet.

A pénzügyi teljesítmény megítéléséhez a rendelési és pénzügyi nyilvántartás az alap. A GA4 ezt kiegészíti a vásárlási viselkedés megértésével; nem helyettesíti a könyvelést.

Hét ellenőrzési pont a különbség feltárásához

1. Ugyanazt az időszakot nézed?

Ellenőrizd a kezdő és záródátumot, az időzónát, valamint azt, hogy az adott lista melyik dátum alapján szűr: rendeléslétrehozás, fizetés vagy teljesítés szerint.

Egy éjfél körüli vásárlás másik napra kerülhet, ha eltérnek az időzónák. Egy pénteken leadott, hétfőn kifizetett rendelés pedig más időszakhoz tartozhat a kétféle lekérdezésben.

A legfrissebb adatokat kezeld előzetesként. A Google szerint a GA4 adatfeldolgozása 24–48 órát is igénybe vehet, és közben változhatnak a riportok. Első összevetésre válassz már lezárult időszakot, és írd fel a lekérdezés időpontját. Ez nem garancia arra, hogy minden későbbi korrekció megszűnik. Google: adatfrissesség.

2. Ugyanaz számít vásárlásnak?

A rendelésrendszerben szerepelhet sikertelen fizetés, tesztrendelés, adminisztrátor által rögzített telefonos rendelés vagy később törölt megrendelés is.

Először azt tisztázd, nálatok mikor küldődik a GA4 purchase, vagyis vásárlási eseménye. A rendelés sikeres létrehozásakor? A kártyás fizetés visszaigazolásakor? Egy későbbi rendszerüzenet alapján?

Szemléltető példa: egy utánvétes rendelés létrejön hétfőn, de a vásárló később nem veszi át. Ha a mérésetek a rendelés leadásakor küld vásárlási eseményt, ez az esemény már bekerülhetett a GA4-be. A teljesített rendelések pénteki listájában viszont nem fog szerepelni.

Ez még nem feltétlenül hibás adatküldés: lehet eltérő üzleti definíció. A hibát akkor tudod megállapítani, ha előbb leírjátok az elvárt működést. A visszatérítésekhez a GA4 külön refund eseményt biztosít; a webshopban átállított státusz önmagában nem bizonyítja, hogy a korrekciót az analitika is megkapta. Google: vásárlások és visszatérítések mérése.

3. Minden vásárlási útvonal elküldi az eseményt?

Nem elég azt látni, hogy a GA4 méri az oldalmegtekintéseket. A vásárlási eseményt és a hozzá tartozó rendelési adatokat külön is ellenőrizni kell.

Gyanús lehet, ha az eltérés egy meghatározott helyzethez kötődik:

• csak egy fizetési módnál hiányoznak rendelések,
• a banki fizetőoldalról visszatérve nem jelenik meg az esemény,
• mobilon jelentkezik a probléma, asztali gépen nem,
• a hiány egy pénztárfrissítés vagy bővítménycsere napján kezdődött.

Ha az esemény csak a köszönőoldal betöltésekor indul, ellenőrizni kell azt az esetet is, amikor a vásárlás sikeres, de a vevő nem jut vissza erre az oldalra. A fejlesztő ilyenkor az eseményindítás feltételét vizsgálja meg; nem egy újabb mérőkód vaktában történő telepítése a következő lépés.

A Google e-kereskedelmi ellenőrzési útmutatója a pontos eseménynevet, a paramétereket és a bekötés hibáit is vizsgálja. A purchase helyett használt saját eseménynév nem válik automatikusan szabványos vásárláseseménnyé. Google: e-kereskedelmi mérés ellenőrzése.

4. Helyes a tranzakcióazonosító?

A transaction_id a vásárláshoz küldött egyedi azonosító. Az egyeztetéshez akkor használható jól, ha következetesen megfeleltethető a webshop rendelésazonosítójának.

A Google webes adatfolyamoknál ezzel is szűri az ismételten beküldött vásárlásokat. Ezért minden külön rendeléshez külön azonosító kell, ugyanannak a rendelésnek az ismételt küldésekor viszont ugyanazt kell használni. Az üres vagy több rendeléshez újrahasznált azonosító alulmérést okozhat; a minden betöltéskor újragenerált azonosító pedig megnehezíti az ismétlések felismerését. Az azonosítóba ne kerüljön név, e-mail-cím vagy más, vevőt azonosító adat. Google: tranzakcióazonosítók és duplikációszűrés.

Szemléltető példa: ha a fejlesztő egy tesztből bent maradt ORDER123 értéket küld minden vásárláshoz, a rendszer nem kapja meg a rendelések valós, egyedi azonosítóit. Ilyenkor nem a kampányok átállítása, hanem az adatküldés javítása az első feladat.

5. Megfelelően működik a hozzájáruláskezelés?

A látogató hozzájárulási döntése és a mérés technikai megvalósítása befolyásolja, milyen adatok jutnak el az analitikába. A Consent Mode a Google-címkék viselkedését igazítja a megadott hozzájárulási állapothoz; önmagában nem helyettesíti a hozzájárulást kérő felületet. Google: Consent Mode megvalósítása.

Magyar célközönségnél az EGT-re vonatkozó Google-követelményekkel is számolni kell. Ezek az érintett mérési és hirdetési felhasználásoknál a felhasználó hozzájárulási választásának továbbítását írják elő. A konkrét adatkezelési megoldást külön ellenőriztesd; a mérési pontosság nem indok a látogató döntésének felülírására. Google: EGT-hozzájárulási követelmények.

A modellezés sem jelent tételesen visszaállított rendeléslistát. A GA4 viselkedési modellezése adat- és megvalósítási feltételekhez kötött, ezért nem jár automatikusan minden webshopnak. Modellezett összesítésből nem lehet minden hiányzó rendelésazonosítót kikeresni. Google: a modellezés feltételei.

Fontos különbség: a hozzájárulás elutasítása nem ugyanaz, mint amikor a látogató engedélyezte a mérést, de egy hibás beállítás miatt mégsem indul el. Utóbbit teszteléssel kell feltárni. Az eltérés százalékából önmagában nem számolható ki a hozzájárulást elutasítók aránya.

6. Ugyanazt jelenti a bevétel a két rendszerben?

Lehet helyes a rendelésszám, miközben az értékek eltérnek. Ilyenkor nézd meg a termékértéket, az adót, a szállítási díjat, a kedvezményeket, a pénznemet és a visszatérítéseket.

A GA4 vásárlási eseményének value mezőjébe a termékek price × quantity összege kerül; a szállítás és az adó külön paraméter, nem a value része. A currency a pénznemet jelöli. Google: purchase esemény paraméterei.

Szemléltető példa, nem ügyféladat: egy rendelés kedvezmény utáni, adó nélküli termékértéke 20 000 Ft, az adó 5 000 Ft, a szállítás 1 500 Ft. A példabeli végösszeg 26 500 Ft, míg a value 20 000. Ha ezt a két különböző tartalmú összeget hasonlítod össze, 6 500 Ft eltérést kapsz anélkül, hogy vásárlás veszett volna el. A számok nem adókulcsra vonatkozó útmutatást jelentenek.

Több pénznem használatakor a riport pénznemét és az átváltást is egyeztesd. Ne feltételezd, hogy a webshop és az analitika ugyanazon árfolyammal dolgozik.

7. Nem szűrő vagy csatornabontás okozza a különbséget?

Nézd meg, ugyanazt a GA4-tulajdont és webes adatfolyamot vizsgáljátok-e. Nincs-e bekapcsolva ország-, eszköz- vagy kampányszűrés? A tesztforgalom kizárása érinti-e a saját próbarendelésedet?

Ha a vásárlás megvan a GA4-ben, csak nem ahhoz a csatornához kerül, amelyre számítottál, az más probléma, mint a hiányzó vásárlásesemény. Először a teljes mért rendelésállományt ellenőrizd, és utána a források közötti elosztást.

A Google Ads és a GA4 napi számait sem szabad automatikusan egyenlőnek tekinteni. A hirdetési interakcióhoz és a konverzió időpontjához rendelt riportolás eltérhet; az összevetéshez a Google Ads konverziós idő szerinti oszlopai is hasznosak lehetnek. Google: hirdetési adateltérések ellenőrzése.

Így egyeztesd a rendeléseket egy konkrét mintán

Ne azzal kezdj, hogy mekkora eltérés „fér bele”. Először készíts összehasonlítható rendeléscsoportot.

Az alábbi számítás kizárólag szemléltető példa. Egy lezárt héten a webshopban 120 rendelésrekord szerepel. Közülük nyolcat telefonon vettek fel és kézzel rögzítettek, tizenkettő pedig nem jutott el a nálatok vásárlási eseménynek meghatározott állapotig. A webes mérés vizsgálatához így 100 rendelés marad.

A GA4 tranzakcióazonosítós kimutatásában ezek közül 85 rendelés megtalálható. A vizsgált csoport tételesen azonosított aránya:

85 / 100 × 100 = 85%.

Ez nem általános mérési pontosság, nem hozzájárulási arány és nem elfogadhatósági küszöb. Csak azt mutatja meg, hogy a kiválasztott száz rendelésből hányat sikerült az adott kimutatásban azonosítani. A fennmaradó tizenötöt kell tovább vizsgálni.

Az egyeztetőtáblához ezek a mezők elegendők lehetnek:

A GA4-ben tranzakcióazonosító szerinti kimutatást vagy feltárást kérj, a megfelelő vásárlási mutatókkal. Ellenőrizzétek a megjelenő adatminőségi jelzéseket és a lekérdezés korlátait is. Egy táblázatból hiányzó sor még nem bizonyítja önmagában, hogy az esemény soha nem érkezett meg.

Vevőnevet, telefonszámot és e-mail-címet ehhez nem szükséges az analitikába küldeni. Az egyeztetést belső, megfelelően védett környezetben végezzétek.

A hiányzó rendelésekben keress közös mintázatot. Ugyanaz a fizetési mód? Ugyanaz az új pénztárverzió? Azonos napszak? A hipotézist ezután célzott próbavásárlással ellenőrizd. Ha az ok nem igazolható, maradjon „ismeretlen”; ne könyvelj el minden különbséget automatikusan sütielutasításként.

Mit kérj a fejlesztőtől és a marketingesedtől?

Egy rövid tesztjegyzőkönyvet kérj, ne pusztán azt a választ, hogy „a kód működik”.

A jegyzőkönyv mutassa meg:

1. Melyik fizetési módot, eszközt és hozzájárulási állapotot tesztelték.

2. Mikor kellett elküldődnie a vásárlási eseménynek, és ténylegesen mi történt.

3. Milyen transaction_id, value, currency és termékadatok mentek át.

4. Mi történt a köszönőoldal újratöltésekor: nem keletkezett-e új vásárlás.

5. Hogyan kezelik a sikertelen fizetést és a visszatérítést.

A Google Tag Assistant és a GA4 DebugView segít az események és paraméterek ellenőrzésében. A DebugView használatához hibakeresési mód szükséges; a hozzájárulás elutasítása befolyásolhatja, mi látható benne. Emiatt az elutasított állapot tesztjét nem lehet kizárólag a DebugView üressége alapján minősíteni. Google: DebugView használata.

A tesztadatokat különítsétek el az üzleti riportoktól. A javítás után ne csak egy próbarendelést nézzetek meg: figyeljétek meg, megszűnt-e a korábban azonosított mintázat a normál forgalomban is.

Mikor mérési hibát javíts, és mikor a marketinget?

Ha a webshop rendelései változatlanok, de a GA4 egy fejlesztés napjától kevesebb vásárlást mutat, először a mérést vizsgáld. Ha mindkét rendszerben visszaesnek az összehasonlítható rendelések, üzleti vagy vásárlási folyamatot érintő probléma is lehet a háttérben.

Ha a rendelési darabszám egyezik, de a bevétel nem, az értékmezőket nézd át. Ha a teljes vásárlásszám rendben van, csak a csatornák aránya változott, a forrásbesorolás és a kampánymérés legyen a következő vizsgálat.

A jó webshop marketing része, hogy a kampányok, a weboldal és az üzleti adatok összehangoltan értékelhetők. A Google Ads hirdetéskezelés során is fontos tudni, valódi teljesítményváltozásra vagy mérési problémára reagálsz-e.

Ha a mérés ellenőrzött, de továbbra is kevés a rendelés, akkor már érdemes külön megnézni, miért nem konvertál a webshopod.

Nem az a cél, hogy minden riportban erővel ugyanaz a szám szerepeljen. Hanem hogy a különbségeknek ismert oka legyen, és megalapozott döntést tudj hozni.

Beszéljük át a webshopod mérését és marketingjét!