A GA4 soha nem lát minden látogatót. A reklámblokkolók, a böngészőkbe épített követésvédelem és a sütisávon adott elutasítás együtt olyan rést nyit a mérésben, amelynek a mérete oldalanként és közönségenként nagyon eltérő. Az adatvesztés ténye ezért ritkán kérdés. Azt érdemes tudnod, hogy mekkora, mennyire stabil, és torzítja-e a döntéseidet. Ebben a cikkben végigmegyünk azon, hogyan becsülheted meg a hiányt a saját adataidból, mely címkéket érinti leginkább a blokkolás, és mikor érdemes technikai megoldásba fogni.
A szövegben három jelölést használunk. A Hivatalosan igazolt állítás a gyártók dokumentációjából ellenőrizhető, a Saját tapasztalat a mérési átvilágítások során visszatérő megfigyelés, a Szakmai feltételezés pedig megalapozott, de nem bizonyított következtetés.
Miért hiányzik adat a GA4-ből akkor is, ha a címkék hibátlanul működnek?
A GA4 mérése a látogató böngészőjében fut, ezért három, egymástól független ponton veszhet el adat. A címke be sem töltődik, betöltődik, de a sütije rövid ideig él, vagy a látogató nem járul hozzá a méréshez.
- Reklám- és követésblokkoló bővítmények. Nyilvános szűrőlisták alapján tiltják a kéréseket az ismert mérési tartományok felé. Ha a gtag.js vagy a Tag Manager konténer letöltése meghiúsul, a látogatás nyom nélkül marad, a GA4 szempontjából az az ember nem járt az oldalon.
- Böngészős védelem. Hivatalosan igazolt: a WebKit leírása szerint a Safari Intelligent Tracking Prevention funkciója a JavaScriptből beállított, első féltől származó sütik élettartamát hét napra korlátozza, bizonyos, követőként besorolt forrásból érkező, paraméterezett hivatkozásoknál pedig 24 órára. A Firefox Enhanced Tracking Protection egy követőlista alapján tilt, a Brave pedig alapbeállításban blokkolja az ismert követőket. A Safari esetében a látogatás megjelenik a riportban, viszont a nyolcadik napon visszatérő ember új felhasználónak látszik. Emiatt a felhasználószám felfelé torzul, a hosszabb döntési utak forrásmegjelölése pedig sérül.
- Sütielutasítás. Hivatalosan igazolt: a Google hozzájárulási módjának két megvalósítása van. Az alap változatban a címkék a hozzájárulásig nem futnak le, így az elutasító látogatóról semmilyen adat nem érkezik. A haladó változatban a címkék süti nélküli jelzéseket küldenek, és a GA4 ezekből modellezni tudja a hiányzó viselkedést. A dokumentáció szerint a viselkedésmodellezés adatmennyiségi küszöbökhöz kötött, ezért kisebb forgalmú oldalon gyakran be sem kapcsol.
A három ok másképp viselkedik. A blokkolás teljes munkameneteket tüntet el, a sütik rövidítése az azonosítást rontja, a hozzájárulás hiánya pedig attól függ, hogyan van megépítve a sütisávod. A becslésnél ezért érdemes külön kezelni őket.
Hogyan becsülöd meg a kimaradó konverziókat a rendeléslistából?
A legmegbízhatóbb becslést az adja, ha a webshop adminjában szereplő rendeléseket rendelésazonosító szerint összeveted a GA4 purchase eseményeivel. A webshop minden rendelést rögzít, a GA4 csak azt, amelyiknél a címke le is futott a vásárló böngészőjében.
- Válassz legalább négy teljes hetet. Olyan időszakot keress, amelyben nem volt leállás, sablonváltás vagy rendkívüli kampány. Rövid időszakban túl nagy a véletlen szerepe.
- Exportáld a rendeléseket azonosítóval, időponttal, állapottal, fizetési móddal. Vedd ki a nem weben keletkezett tételeket, vagyis a telefonon felvett, az adminból kézzel rögzített és a piactérről szinkronizált rendeléseket.
- Kérd le a GA4-ből a tranzakcióazonosítókat. A Felfedezés riportban a Tranzakcióazonosító dimenzióval megteheted, nagyobb adatmennyiségnél pedig a BigQuery export a jobb út, mert nyers eseményeket ad.
- Egyeztesd az időzónát és a napváltást. Ha a webshop és a GA4 tulajdon más időzónában számol, az éjfél körüli rendelések elcsúsznak.
- Párosíts azonosító szerint egy táblázatkezelő kereső függvényével. A puszta darabszám összevetése megtévesztő, mert a GA4-ben duplán rögzített vásárlások eltakarják a hiányzókat.
- Számold ki az arányt az alábbi képlettel.
mérési hiány (%) = (webes rendelések száma - GA4-ben megtalált rendelések száma) / webes rendelések száma × 100
Egy kitalált számpéldával élve, ha 400 webes rendelésből 332 azonosítója található meg a GA4-ben, akkor 68 rendelés hiányzik, a mérési hiány pedig 17 százalék.
Mit ellenőrizz, mielőtt a blokkolókra fogod a hiányt?
Saját tapasztalat: a hiány egy része rendszerint nem blokkolásból ered. Visszatérő ok, hogy a vásárló a külső fizetési oldalról nem jut vissza a köszönőoldalra, hogy a purchase esemény a hozzájárulási állapot visszatöltése előtt sül el, vagy hogy a címke csak bizonyos fizetési módoknál fut le. Bontsd ezért a hiányzó rendeléseket fizetési mód és eszköztípus szerint. Ha a bankkártyás rendelések hiányoznak aránytalanul, a visszairányítás környékén keresd a hibát. Ha a hiány nagyjából egyenletesen oszlik el, jó eséllyel a blokkolás és az elutasítás áll mögötte.
Szakmai feltételezés: a vásárlók blokkolási aránya eltérhet a teljes látogatóközönségétől, ezért a rendelésekből számolt hiány nem vihető át változtatás nélkül a látogatásszámra. A látogatásokhoz külön becslés kell.
Hogyan használható a szervernapló a látogatásszám becslésére?
A szervernapló minden kérést rögzít, amely eléri a szervert, függetlenül attól, hogy fut-e JavaScript a böngészőben. Ha kiszűröd belőle a robotokat és a statikus fájlokat, felső becslést kapsz az emberi látogatók számára, amelyet a GA4 felhasználószámával vethetsz össze.
Egy szokásos, kombinált formátumú hozzáférési naplón az alábbi parancs megszámolja azokat az egyedi IP-címeket, amelyek sikeresen lekértek legalább egy oldalt, és nem nevezték magukat robotnak.
grep -v -i -E 'bot|crawl|spider|slurp|monitor|preview' access.log | awk '$9 == 200 && $7 !~ /[.](css|js|png|jpg|webp|svg|ico|woff2)/ {print $1}' | sort -u | wc -l
Az eredményt óvatosan kezeld, mert a napló több irányban is torzít.
- Gyorsítótár és CDN. Ha az oldalaidat részben egy tartalomszolgáltató hálózat adja ki, a saját szervered naplójából hiányoznak ezek a letöltések. Ilyenkor a CDN naplójával dolgozz.
- Böngszőnek álcázott robotok. A felhasználói ügynök szűrése csak azokat a robotokat fogja meg, amelyek megnevezik magukat, a napló ezért rendszerint túlbecsül. Hivatalosan igazolt: a GA4 az ismert robotforgalmat automatikusan kizárja, a két forrás tehát eleve mást számol.
- Az IP-cím nem ember. Mobilhálózaton és céges hálózat mögött sokan osztoznak egy címen, míg ugyanaz az ember otthon és útközben két címről érkezik.
- Adatvédelem. Az IP-cím személyes adat, ezért a naplók megőrzési idejét és felhasználási célját az adatkezelési tájékoztatódhoz igazítsd.
Saját tapasztalat: a szervernapló nagyságrendi kontrollnak és trendfigyelőnek használható jól. Ha a napló és a GA4 aránya hónapokon át hasonló, majd hirtelen szétválik, az értékes jelzés. Ilyenkor többnyire megváltozott a sütisáv, kiesett egy címke, vagy átalakult a forgalom összetétele.
Pontosabb módszer egy saját számlálóval
Tisztább képet ad egy apró, saját tartományról kiszolgált szkript, amely az oldal betöltése után megnézi, létrejött-e a Google címke objektuma, és az eredményt egy összesített számlálóba küldi a saját szerveredre.
window.addEventListener('load', function () { setTimeout(function () { var blokkolt = !window.google_tag_manager; navigator.sendBeacon('/meres-ellenor', blokkolt ? 'blokkolt' : 'rendben'); }, 3000); });
A két érték arányából közvetlenül látod, a betöltések mekkora részénél nem indult el a címke. Szakmai feltételezés: a süti és azonosító nélküli, összesített számlálás adatvédelmi megítélése kedvezőbb, mint a személyhez köthető mérésé, de bevezetés előtt egyeztesd az adatvédelmi felelősöddel.
Hogyan választod szét a blokkolást és a sütielutasítást?
A sütikezelő eszközöd saját statisztikája megmutatja az elutasítási arányt, a teljes hiányból fennmaradó rész pedig a blokkolás és a technikai hibák együttes hatása. A két ok kezelése eltér, ezért megéri különválasztani őket.
A legtöbb hozzájáruláskezelő platform kimutatja, a megjelenítések mekkora részénél fogadták el, utasították el vagy hagyták válasz nélkül a sávot. A válasz nélküli látogató az alap megvalósításban ugyanúgy mérés nélkül marad, mint az elutasító, ezért őt is ide számold.
Hivatalosan igazolt: a GA4 jelentési identitás beállításában válthatsz a modellezett adatot is tartalmazó vegyes és az eszközalapú nézet között. A két nézet különbsége megmutatja, mennyit tesz hozzá a modellezés a számaidhoz. Ha nincs különbség, a modellezés jó eséllyel nem aktív a tulajdonodban.
A blokkolás oldalát kézzel is leellenőrizheted. Nyisd meg az oldalt egy elterjedt blokkoló bővítménnyel, majd Brave böngészőben és a Firefox szigorú védelmi szintjén, és a fejlesztői eszközök hálózati fülén nézd meg, mely kérések hiúsulnak meg.
Mely címkéket blokkolják a leggyakrabban?
A hirdetési és remarketing címkék a leginkább érintettek, utánuk az analitikai eszközök következnek, a saját tartományról futó szkriptek pedig a legkevésbé. Az alábbi sorrend saját tapasztalat, a nyilvános szűrőlisták és a böngészős tesztek alapján. A listák folyamatosan változnak, ezért a saját oldaladon is ellenőrizd.
- Meta Pixel és a többi közösségi hirdetési képpont (TikTok, LinkedIn Insight, Pinterest). Szinte minden követésvédelmi lista tiltja őket.
- Google Ads konverziókövetés és remarketing. A hirdetéskiszolgáló tartományok a reklámblokkoló listák alapelemei.
- GA4 és a gtag.js betöltése. Az adatvédelmi fókuszú listák jellemzően tiltják, az alapbeállítású böngészők többsége átengedi.
- A Tag Manager konténer. Ha a konténer nem töltődik be, minden benne lévő címke kiesik, azok is, amelyeket egyébként senki nem tiltana.
- Hőtérkép- és munkamenet-rögzítő eszközök. A felvételek így egy szűrt, kevésbé tudatos közönséget mutatnak.
- A/B tesztelő eszközök. A blokkoló látogatók mindig az eredeti változatot látják, és kimaradnak a mintából.
- A sütisáv szkriptje. Egyes, a zavaró elemeket szűrő listák magát a sávot rejtik el, ilyenkor hozzájárulás sem érkezik.
- Chat- és ügyfélszolgálati modulok. Ritkábban érintettek, de előfordul.
- Saját tartományról kiszolgált szkriptek és szerveroldali események. Ezeket éri a legkevesebb blokkolás.
A gyors ellenőrzéshez három lépés elég.
- Írd össze a konténeredben futó címkéket és azt, hogy melyik tartományra küldenek adatot.
- Töltsd be az oldalt blokkolóval, és jelöld meg, melyik kérés nem megy ki.
- Rangsorold a kieső címkéket aszerint, hogy üzleti döntés vagy automatikus ajánlattétel épül-e rájuk.
Mikor elég az eltérést ismerni és jelezni?
Akkor elég, ha a hiány stabil, a csatornák között nagyjából egyenletes, és a döntéseidet trendek és arányok alapján hozod. Ez a saját nézőpontunk, és a kisebb forgalmú oldalak többségére szerintünk érvényes.
A GA4-et ilyenkor érdemes mintavételként kezelni. A bevételt és a rendelésszámot a webshopból vagy a számlázóból vedd, a GA4-et pedig arra használd, amiben erős, vagyis útvonalak, arányok és időszakok összehasonlítására. A riport elejére kerüljön egy mondat arról, hogy a GA4 a webes rendelések hozzávetőleg mekkora részét látja, és mikor mérted ezt utoljára.
A becslést érdemes negyedévente megismételni, valamint minden olyan változás után, amely a mérést érinti. Ilyen a sütisáv cseréje, a sablonváltás, az új fizetési szolgáltató vagy a konténer átszervezése. Kézi ajánlattételnél és kevés csatornánál ennyi többnyire elég a megalapozott döntéshez.
Mikor indokolt technikai lépés?
Akkor indokolt, ha a hiányzó konverziók a hirdetési rendszerek automatikus ajánlattételét vagy a csatornák közötti költségelosztást torzítják. Ilyenkor a hiány már a pénzed elosztását is befolyásolja.
- Az automatikus ajánlattétel kevés konverzióból tanul, így minden kieső rendelés érezhetően rontja a jelzést.
- A hiány csatornánként eltér. Egy műszakilag tudatosabb, főleg asztali gépről érkező közönségnél a blokkolás gyakoribb, az a csatorna pedig rosszabbnak látszik a valósnál.
- A hiány hónapról hónapra ingadozik, így a trendekben sem bízhatsz.
- Hosszú a döntési út, és magas a Safari aránya, ezért a visszatérő látogatók forrása rendszeresen elvész.
A lépéseket növekvő ráfordítás szerint érdemes sorra venni.
- Tedd rendbe a meglévő mérést. Ellenőrizd a hozzájárulási mód megvalósítását, a purchase esemény megbízható elsülését és a tranzakcióazonosító átadását. Hivatalosan igazolt: a GA4 az azonos tranzakcióazonosítóval érkező vásárlásokat igyekszik kiszűrni, ezért az azonosító hiánya dupla számoláshoz vezethet.
- Kapcsold be a hirdetési rendszerek első féltől származó adatra épülő megoldásait. Ilyen a Google továbbfejlesztett konverziókövetése és a Meta Conversions API, mindkettő hozzájárulás mellett használható.
- Küldd be a rendelést a szerverről. A webshop a rendelés rögzítésekor a Measurement Protocolon keresztül maga is elküldheti a vásárlást, a böngészőből kiolvasott ügyfélazonosítóval.
- Vezess be szerveroldali címkézést saját altartományról, ha a fentiek után is jelentős a hiány.
POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=TITKOS_KULCS
{ "client_id": "UGYFEL_AZONOSITO", "events": [ { "name": "purchase", "params": { "transaction_id": "RENDELES_AZONOSITO", "value": RENDELES_ERTEKE, "currency": "HUF" } } ] }
Hivatalosan igazolt: a Google leírása szerint a Measurement Protocol a böngészős mérés kiegészítésére szolgál, a teljes kiváltására nem alkalmas. Ha a böngészős címke is lefut, a két vásárlás azonos tranzakcióazonosítóval érkezzen, különben duplán számolsz.
Egyik megoldás sem garantál teljes lefedettséget, és egyik sem írja felül a látogató döntését. Aki elutasította a mérést, annak az adatait a szerveroldali megoldásban is ennek megfelelően kell kezelned. A cél a technikai veszteség csökkentése, a hozzájárulás megkerülése jogi és bizalmi kockázatot jelent.
Miért számít ez az AI-keresőkből érkező forgalom megítélésénél?
Az AI-asszisztensekből érkező látogatások száma a legtöbb oldalon még alacsony, kis mintán pedig a mérési hiány aránytalanul nagy bizonytalanságot okoz. Néhány tucat munkamenetnél pár kieső látogatás is jelentősen eltolja az arányokat.
Szakmai feltételezés: az AI-eszközöket rendszeresen használó közönség technikailag tudatosabb, így nála a blokkolás gyakoribb lehet az átlagosnál. Ehhez jön, hogy a beágyazott böngészőkből és alkalmazásokból érkező kattintások egy része hivatkozó nélkül, közvetlen forgalomként jelenik meg. A GA4-ben látott AI-forgalmat ezért alsó becslésként érdemes kezelni, és a szervernaplóval együtt értelmezni.
Források és további olvasnivalók
- Google Analytics Súgó: hozzájárulási mód, viselkedésmodellezés, jelentési identitás
- Google Analytics Súgó: BigQuery export és az ismert robotforgalom kizárása
- Google for Developers: Measurement Protocol (Google Analytics 4)
- Google Tag Manager dokumentáció: szerveroldali címkézés
- Google Ads Súgó: továbbfejlesztett konverziókövetés
- WebKit: Intelligent Tracking Prevention és Tracking Prevention Policy
- Mozilla Support: Enhanced Tracking Protection a Firefoxban
- Meta for Developers: Conversions API
- A legmegbízhatóbb becslést a webshop rendeléseinek és a GA4 purchase eseményeinek tranzakcióazonosító szerinti párosítása adja.
- A szervernapló felső becslést ad a látogatásszámra, ezért nagyságrendi kontrollnak és trendfigyelőnek jó, pontos mérőszámnak kevésbé.
- A hirdetési képpontokat blokkolják a leggyakrabban, és ha a GTM konténer nem töltődik be, minden benne lévő címke kiesik.
- Stabil és csatornánként egyenletes hiánynál elég az eltérést ismerni és a riportban jelezni.
- Technikai lépés akkor indokolt, ha a hiány az automatikus ajánlattételt vagy a csatornák összehasonlítását torzítja, de a látogató elutasítását a szerveroldali mérésnek is tiszteletben kell tartania.
Gyakori kérdések
Mekkora mérési hiány számít normálisnak a GA4-ben?
Általános érvényű érték nincs, mert a hiány a közönség összetételétől, az eszközök arányától és a sütisáv megvalósításától függ. A saját oldaladon a rendeléslista és a GA4 tranzakcióazonosítóinak párosításával tudod megmérni, és az a fontos, hogy az érték időben stabil-e.
Miért megbízhatóbb a rendeléslista a szervernaplónál?
A rendelés egyértelmű, azonosítóval ellátott esemény, amelyet a webshop a böngészőtől függetlenül rögzít. A szervernaplóban a robotok, a gyorsítótár és a megosztott IP-címek miatt csak becsülni lehet az emberi látogatók számát.
Megoldja a szerveroldali címkézés a reklámblokkolók okozta adatvesztést?
Csökkentheti a technikai veszteséget, mert a kérések a saját tartományodra mennek, de teljes lefedettséget nem garantál. A látogató hozzájárulási döntését a szerveroldali mérésnél is tiszteletben kell tartani.
Mit tegyek, ha a GA4 több vásárlást mutat, mint a webshop?
Ez többnyire dupla rögzítésre utal, például a köszönőoldal újratöltése vagy a böngészős és a szerveroldali esemény együttes beküldése miatt. Ellenőrizd, hogy minden purchase esemény kap-e tranzakcióazonosítót, és hogy a két forrás ugyanazt az azonosítót küldi-e.
Milyen gyakran érdemes újramérni az eltérést?
Negyedévente érdemes megismételni, és minden olyan változás után, amely a mérést érinti. Ilyen a sütisáv cseréje, a sablonváltás, az új fizetési szolgáltató vagy a Tag Manager konténer átalakítása.
A Safari miatt is elvesznek látogatások?
A Safari sütikorlátozása a látogatást jellemzően nem tünteti el, viszont a visszatérő látogatót néhány nap után új felhasználóként mutatja. Ettől a felhasználószám nő, a hosszabb döntési utak forrása pedig elveszhet.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.