GA4 mérési kimaradás: hogyan ismerd fel és mit kezdj a hiányzó napokkal

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

A mérési kimaradás ritkán jelentkezik látványos hibaként. Nem jön hibaüzenet, a weboldal működik, a rendelések befutnak, csak a GA4-ben lesz egyre kevesebb adat. A legtöbb esetben hetekkel később derül ki, amikor valaki megnyitja a havi riportot, és nem érti, miért esett vissza a forgalom a hónap közepétől.

Ez a cikk arról szól, hogyan ismered fel a kiesést, hogyan szűkíted le az okát egy ellenőrzőlistával, mit tudsz visszamenőleg tenni (és mit nem), és hogyan dokumentálod úgy, hogy egy év múlva ne vezessen félre az év/év összehasonlítás. Az állításoknál külön jelölöm, mi hivatalosan igazolt Google-információ, mi saját tapasztalat, és mi szakmai feltételezés.

Miből veszed észre, hogy kiesett a GA4-mérés?

Rövid válasz: a napi bontású görbe éles töréséből és a tartósan üres Realtime jelentésből. Ha a napi munkamenetszám egyik napról a másikra nullára vagy a töredékére esik, majd később ugyanilyen élesen visszaugrik, az technikai hiba, nem piaci mozgás. A valódi keresleti ingadozás lejtős, nem függőleges.

Az ellenőrzéshez ne a beépített áttekintő kártyákat használd, mert azok hetes vagy havi összegzést mutatnak, és elmossák a lyukat. Nyiss inkább egy szabad formájú elemzést (Explorálás), tedd sorba a Dátum dimenziót, oszlopba a munkameneteket, a felhasználókat és az eseményszámot, és állíts be legalább 90, inkább 180 napos tartományt. Így soronként látod, melyik nap hány esemény érkezett.

A Realtime jelentés a második bizonyíték. Nyisd meg a weboldalt egy inkognitóablakban, kattints két-három aloldalra, és nézd a valós idejű nézetet: ha fél percen belül nem jelensz meg benne, a gyűjtés jelenleg is áll. Saját tapasztalat: a legtöbb kárt nem a teljes leállás okozza, hanem a részleges kiesés, amikor például csak a termékoldali sablonból tűnik el a kód, vagy csak mobilon fut hibára egy szkript. Ilyenkor a görbe nem nullázódik, csak visszaesik mondjuk a negyvenedére, és ez hihetőnek tűnik. Ezért érdemes a gyanús időszakot céloldal, eszközkategória, böngésző és forrás bontásban is végignézni: ha a visszaesés egyetlen szeletre koncentrálódik, az mérési hiba, nem kereslet.

Mik a leggyakoribb kiváltó okai a kimaradásnak?

Rövid válasz: majdnem mindig egy olyan változtatás, amit nem a mérés miatt csináltak. A mérőkód járulékos áldozat.

• Sablon- vagy témafrissítés. A fejlécbe kézzel beillesztett kódot a frissítés felülírja. Gyermektéma vagy beépülő modul nélkül ez borítékolható.
• Bővítmény-ütközés, gyorsítótár és optimalizálás. Egy JS-összefűző, halasztó vagy tisztító modul kiszedheti, késleltetheti vagy hibára futtathatja a mérőkódot.
• Sütikezelő (CMP) átállítása. Ha az alapértelmezés minden kategóriában elutasított, és a tag csak elfogadás után indul, a mért forgalom drasztikusan lecsökken. Hivatalosan igazolt: a Google Consent Mode működésének lényege, hogy hozzájárulás hiányában a tag korlátozott módban vagy egyáltalán nem küld adatot, a beállítástól függően.
• Tag Manager konténer visszaállítása. Valaki publikál egy régebbi verziót, és ezzel visszatűnik egy hónapokkal korábbi állapot.
• Rossz mérési azonosító. Fejlesztés vagy költöztetés után a G- kezdetű azonosító a teszt-adatfolyamra mutat, és az adat egy másik property-be folyik.
• Túl szigorú belső forgalomszűrő. Ha az IP-tartomány tágabb a kelleténél, valódi látogatókat is kizár.
• Domain- vagy protokollváltás. Aldomain-váltás, új URL-szerkezet, hibás átirányítás után a kód egyes útvonalakon nem töltődik be.

Szakmai feltételezés: az esetek túlnyomó többségében a kiesés kezdőnapja egybeesik egy frissítéssel, egy publikálással vagy egy fejlesztői kiadással. Ezért a dátum ismerete önmagában a legerősebb nyom.

Hogyan határozod meg pontosan a kiesés dátumtartományát?

Rövid válasz: az utolsó ép nap és az első újra ép nap közötti szakasz a kiesés, a két határnapot pedig órabontásban is nézd meg, mert azok jellemzően részlegesek.

1. Exportáld a napi bontású táblát (dátum, felhasználók, munkamenetek, eseményszám) legalább a gyanús időszak előtti és utáni két-két hétre.
2. Jelöld meg az utolsó olyan napot, amely a megelőző időszak normál sávjába esik. Ez az utolsó ép nap.
3. Jelöld meg az első napot, amely újra a normál sávba tér vissza. Az előtte lévő nap a kiesés utolsó napja.
4. A két határnapot bontsd órára. Gyakori, hogy a kód délután tűnt el, tehát a nap fele még mért. Ilyenkor a napot félig hiányosnak jelöld, ne teljesnek.
5. Ellenőrizd a property időzónáját. Hivatalosan igazolt: a GA4 a jelentésekben a property beállított időzónája szerint csoportosít, a nyers export viszont UTC időbélyeget használ, ezért a határnapok egy nappal elcsúszhatnak.
6. Számold ki az érintettség mértékét: a kiesés alatti napi átlagot oszd el az előtte lévő négy hét azonos napjainak átlagával. Ha az eredmény nulla közeli, teljes kiesés; ha például 0,3, akkor részleges.

A végeredmény egyetlen mondat legyen, például: a mérés 2026. március 4. délutánjától március 19. reggeléig hiányos, a becsült lefedettség a szokásos szint 8 százaléka. Ez a mondat lesz a dokumentáció magja.

Milyen ellenőrzőlistával deríthető ki a kiváltó ok?

Rövid válasz: kívülről befelé haladva, a böngészőben látható valóságtól a szerveroldali naplókig.

• Nézd meg az oldal forrását, és keresd a gtag/js hivatkozást vagy a Tag Manager kódrészletét. Ha nincs ott, a kód hiányzik, nem a beállítás rossz.
• Nyisd meg a böngésző hálózati fülét, és szűrj a /g/collect kérésre. Ha nincs ilyen kérés, semmi nem indul el.
• A konzolba írd be a window.dataLayer parancsot. Üres tömb vagy hiányzó objektum a konténer betöltésének hibájára utal.
• Futtasd a Tag Assistant előnézeti módot, és a GA4 DebugView-ban nézd meg, megérkeznek-e az események.
• Vesd össze a kiesés kezdőnapját a Tag Manager verzió-előzményével: ki, mikor, mit publikált.
• Nézd át a tartalomkezelő rendszer frissítési naplóját (téma, bővítmények, mag), és keresd az adott napi bejegyzéseket.
• Kapcsold ki ideiglenesen a gyorsítótárazó és optimalizáló modult, majd töltsd újra az oldalt inkognitóban, és nézd újra a hálózati kéréseket.
• Ellenőrizd a sütikezelő beállítását és naplóját: mikor módosult, és mi az alapértelmezett állapot.
• Ellenőrizd az adatfolyam mérési azonosítóját, és hasonlítsd össze azzal, ami az oldalon szerepel.
• Nézd meg a GA4 adatfolyam beállításainál a belső forgalom és a nem kívánt hivatkozók szabályait.
• Ha van hozzáférésed a szerver hozzáférési naplójához, keress rá a mérőszkript kérésére, például grep 'gtag/js' access.log. Ez megmutatja, mikortól nem töltődött be.

Saját tapasztalat: ez a lista jellemzően az első négy pontnál eldől. Ha a kód fizikailag ott van és a kérés is elindul, akkor már nem gyűjtési, hanem szűrési vagy hozzájárulási kérdésről van szó.

Mit lehet és mit nem lehet visszamenőleg pótolni GA4-ben?

Rövid válasz: a nem gyűjtött forgalmi adat utólag nem kerül be a fiókba. Amit tehetsz, az a becslés és a dokumentálás, nem a feltöltés.

Hivatalosan igazolt: a GA4 azokat az eseményeket dolgozza fel, amelyeket a gyűjtés idején megkapott. Nincs olyan funkció, amely visszamenőleg újraszámolná a nem küldött webes eseményeket. Az adatmegőrzési beállítás módosítása szintén előre hat, a már elévült részletes adatot nem hozza vissza.

A Measurement Protocol elvileg felmerülhet mint pótlás, de a gyakorlatban nem alkalmas erre. Hivatalosan igazolt: a protokoll időbélyeg-mezője (timestamp_micros) csak szűk, néhány napos visszamenőleges ablakot fogad el, a régebbi időbélyeggel küldött esemény a feldolgozás során a jelenlegi időpontot kapja vagy elutasításra kerül. Szakmai feltételezés: egy hetekkel korábbi időszak utólagos feltöltése ezért nem rekonstrukció, hanem adattorzítás lenne, ami a jelenlegi napokat rontja el a múlt megszépítéséért.

Az adatimport sem megoldás: felhasználói, terméknév- vagy költségadat gazdagítására való, nem munkamenetek létrehozására. A BigQuery export szintén attól a naptól kezdve tölt, amikortól bekapcsoltad. Ami viszont működik: az integrációk egy része a saját forrásrendszeréből hoz historikus adatot, például a Search Console összekapcsolása után a keresési jelentésekben visszamenőleg is megjelenik a kattintás és megjelenés. Ez azonban nem pótolja a hiányzó munkameneteket, csak egy párhuzamos nézetet ad.

Milyen külső forrásokkal érdemes keresztellenőrizni a hiányt?

Rövid válasz: mindennel, ami a látogatót a GA4-től függetlenül is látta. A cél nem a pontos szám, hanem egy védhető nagyságrend.

• Search Console: napi bontású kattintás és megjelenés, jellemzően 16 hónapra visszamenőleg. A kiesés alatti kattintásszámból és az ép időszak kattintás/munkamenet arányából becsülhető az elveszett szerves forgalom.
• Hirdetési fiókok: a Google Ads és a Meta kattintásadata a saját rendszerében sértetlen, akkor is, ha a GA4-be semmi nem jutott el. Ez a legmegbízhatóbb kapocs a fizetett forgalomra.
• CRM, webshop, számlázás: a rendelések és az ajánlatkérések száma az üzleti valóságot mutatja. Ha ez nem esett vissza, miközben a GA4 igen, a mérés hibázott, nem a piac.
• Űrlap-e-mailek és hívásnapló: a beérkező megkeresések darabszáma napi bontásban is kinyerhető.
• Szerveroldali hozzáférési napló: a nyers kéréslista bot-szűrés után nagyságrendi képet ad a látogatottságról.

Saját tapasztalat: a Search Console és a hirdetési kattintások kombinációja általában elég ahhoz, hogy a kiesés mértékét egy jól védhető sávban meg lehessen adni. A becslést mindig sávként közöld, ne egyetlen számként, és írd oda, milyen arányból számoltad.

Hogyan dokumentáld a kiesést, hogy ne rontsa el a későbbi összehasonlítást?

Rövid válasz: jegyzettel a jelentésben, sorral a mérési naplóban, és figyelmeztetéssel minden olyan riportban, amely az érintett időszakot használja bázisként.

Ez a cikk szakmai álláspontja: a kiesést nem eltüntetni kell, hanem dokumentálni. Egy megjegyzés nélküli lyuk évekig rontja a döntéseket, mert egy év múlva valaki az adott hónapot fogja bázisnak venni, és a mesterségesen alacsony érték mellett egy gyenge évet is növekedésnek fog látni. A hamis siker drágább, mint a bevallott hiány.

A dokumentálás három rétege:

1. Jegyzet a GA4-ben. A jelentésekhez rendelhető jegyzet funkció pontosan erre való: rögzítsd a dátumtartományt és egy mondatban az okot, például hogy a mérőkód témafrissítés után hiányzott.
2. Mérési napló külön táblázatban. Oszlopok: dátum, mi változott, ki csinálta, mi lett a hatása a mérésre, mikor állt helyre. Ebbe ne csak a hibák kerüljenek, hanem minden tag-, sütikezelő- és sablonváltozás. Saját tapasztalat: ez a táblázat a következő incidensnél percek alatt megadja a választ arra, hogy mi történt aznap.
3. Figyelmeztetés a vezetői riportban. Looker Studio vagy táblázatos riport esetén az érintett napokat jelöld eltérően, és tegyél a diagram alá egy rövid megjegyzést. Ha év/év összehasonlítást mutatsz, és a bázisidőszak hiányos, az összehasonlítást vagy hagyd ki, vagy jelöld becslésként.

Ha becsült értékkel dolgozol tovább, tartsd külön a mért és a becsült számot. A becslés akkor használható, ha látszik rajta, hogy becslés, és tudható, miből készült.

Hogyan csökkenthető a következő kimaradás esélye?

Rövid válasz: rendszeres, automatikus ellenőrzéssel és azzal, hogy a mérés része lesz a fejlesztési folyamatnak. Ez nem szünteti meg a hibákat, de a felismerési időt hetekről órákra rövidítheti.

• Állíts be a GA4-ben egyéni elemzést (custom insight) a napi felhasználószámra, alsó küszöbbel, e-mail értesítéssel. Ha egy nap a szám a küszöb alá esik, másnap reggel tudsz róla.
• Vegyél fel a frissítési rutinba egy kötelező lépést: téma-, bővítmény- vagy sablonfrissítés után ellenőrizd a Realtime nézetet.
• A mérőkódot ne a témába illeszd kézzel, hanem Tag Manager konténerbe vagy gyermektémába, hogy a frissítés ne írja felül.
• A sütikezelő minden átállítása után nézd meg egy elfogadott és egy elutasított körben is, mi jut el a mérésbe.
• Tartsd külön az éles és a teszt adatfolyamot, és a kiadás előtt ellenőrizd a mérési azonosítót.
• Ha van rá kapacitás, a szerveroldali mérés vagy egy független naplóelemzés jó eséllyel csökkenti a teljes vakfolt kockázatát, mert nem ugyanattól a kliensoldali szkripttől függ.

Egyik eszköz sem zárja ki a hibát. A reális cél az, hogy a kiesés napokban mérhető legyen, ne hónapokban, és hogy minden ilyen esemény írásos nyomot hagyjon.

Források és további olvasnivalók

• Google Analytics súgó (Analytics Help): adatgyűjtés, adatmegőrzés, adatfolyam-beállítások, jegyzetek a jelentésekben
• Google Analytics Developers: Measurement Protocol for Google Analytics 4, gtag.js referencia
• Google Tag Manager súgó: konténerverziók, előnézeti és hibakereső mód
• Google Search Central: Search Console teljesítményjelentés dokumentációja
• Google Privacy and Consent dokumentáció: Consent Mode működése
• Google BigQuery Export a Google Analytics 4 property-hez (hivatalos dokumentáció)