Mennyi adatot veszítesz a süti-sávval, és hogyan számold ki a valós számot

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

Rövid válasz elöl: a süti-sáv nem tünteti el a forgalmadat, csak elrejti egy részét. Aki elutasítja a mérést, ugyanúgy megnézi az oldalt, ugyanúgy telefonál, ugyanúgy vásárol, csak a Google Analytics 4-ben nem hagy nyomot. A gyakorlati kérdés ezért nem az, hogy hogyan tornászd fel az elfogadást száz százalékra (nem lehet, és nem is cél), hanem az, hogy tudd, mekkora a vakfolt, és ehhez igazítsd a döntéseidet.

Mit jelent pontosan, hogy adatot veszítesz a süti-sávval?

Azt jelenti, hogy a mérőkód elindulása feltételhez kötött. Ha a látogató nem járul hozzá az analitikai tároláshoz, a GA4 nem tesz ki mérési sütit, így az adott munkamenet jó eséllyel meg sem jelenik a riportban, vagy csak modellezett formában.

Hivatalosan igazolt: a Google Consent Mode dokumentációja két üzemmódot ír le. Az alap változatban a tag hozzájárulás előtt el sem indul, tehát semmilyen adat nem megy el. A bővített változatban egy azonosító nélküli, süti nélküli jelzés elmegy, és a Google viselkedési modellezéssel próbálja pótolni a hiányt, de a modellezés csak akkor kapcsol be, ha a property eléri a súgóban leírt forgalmi küszöböket. Kis és közepes magyar oldalak jelentős része ezeket a küszöböket nem éri el, ezért náluk a bővített mód sem hoz vissza modellezett adatot.

Saját tapasztalat: a legtöbb hiba nem abból származik, hogy a mérés hiányos, hanem abból, hogy erről senki nem tud. A havi riportban a GA4-szám úgy szerepel, mintha a teljes valóság lenne, aztán valaki elcsodálkozik, hogy a webshop adatbázisában másfélszer annyi rendelés van, mint amennyit az analitika mutat.

Mely riportok maradnak teljesek, és melyek csonkulnak?

Rövid válasz: minden teljes, ami nem a böngészőben futó mérőkódból jön. Minden csonka, ami onnan jön.

Teljes marad (a hozzájárulástól függetlenül):

• a szerveroldali hozzáférési napló (Apache, Nginx, tárhely statisztika), mert a kérést a szerver akkor is kiszolgálta;
• a Google Search Console adatai, mert azok a keresőoldali megjelenésből és kattintásból jönnek, nem a te sütidből;
• a hirdetési fiókok megjelenés-, kattintás- és költésadatai (a konverziós oszlop már nem, arra mindjárt visszatérünk);
• a webshop vagy a CRM saját rendelés- és érdeklődés-adatbázisa;
• az űrlapok szerveroldali beérkezése, a hívásnapló, az e-mail-küldési statisztika;
• a CDN vagy a proxy (például Cloudflare) süti nélküli forgalmi kimutatása.

Csonka lesz: a GA4 munkamenet- és felhasználószám, a forgalmi forrás és médium bontás, a céloldal-riport, a helyszíni események (görgetés, gombkattintás, videó), a konverziós útvonalak és a csatorna-hozzárendelés, valamint a remarketinglisták mérete.

Szakmai feltételezés, de erős: a hiány nem véletlenszerű. Nem egy egyenletesen szétszórt mintát veszítesz el, hanem egy sajátos szeletet. Eltérő az elfogadási hajlandóság eszköz szerint, böngésző szerint (a szigorúbb alapbeállítású böngészők használói tudatosabbak), és valószínűleg forrás szerint is: aki a hírlevélből érkezik és ismer téged, más arányban kattint az Elfogadom gombra, mint aki egy hirdetésből esik be először. Ezt a saját oldaladon mérni is tudod, ha a sütikezelőd naplózza a döntést a beérkezés forrásával együtt.

Hogyan torzítja a hozzájárulás hiánya a konverziós arányt?

Rövid válasz: akkor torzít a legdurvábban, ha a hányados két fele két különböző világból jön. Ha a nevező (munkamenetszám) csonka GA4-adat, a számláló (rendelésszám) viszont a teljes webshop-adatbázisból való, felfelé hazudsz magadnak.

Vegyünk egy tiszta példát. Az oldalon egy hónap alatt tízezer valós munkamenet volt, és kétszáz rendelés érkezett. A tényleges konverziós arány két százalék. Ha a hozzájárulási arány hatvanöt százalék, a GA4 hatezer-ötszáz munkamenetet lát, és nagyjából százharminc rendelést, mert ugyanabból a szeletből méri mindkettőt. A GA4-en belül számolt arány így továbbra is két százalék körül lesz: önmagában konzisztens, csak nem a teljes populációra igaz. Ha viszont a kétszáz rendelést osztod el a hatezer-ötszáz munkamenettel, 3,08 százalékot kapsz. Ez több mint ötven százalékkal magasabb a valóságnál, és minden rá épülő döntés (mennyit ér egy látogató, mennyit költhetsz kattintásra, megéri-e a kampány) ugyanennyivel csúszik el.

A másik irány ritkábban jut eszébe az embereknek: ha a hirdetési fiókban a konverziót a mérőkód küldi vissza, akkor a hirdetés eredménye is alulmérve látszik. Ilyenkor pont a jól teljesítő kampányt állítod le, mert a fiókban kevesebb konverzió jelenik meg, mint amennyi valójában megtörtént. Ezt a torzítást a hirdetési oldalon szerveroldali konverzióküldéssel vagy offline konverzió-feltöltéssel szokás enyhíteni, de az már külön projekt.

Hogyan becsüld meg a hozzájárulási arányt szerveroldali adatból?

Rövid válasz: vess össze két számot ugyanarra az időszakra, ugyanarra a domainre. A GA4 munkamenetszámát, és egy szerveroldali naplóból tisztított munkamenet-becslést. A hányadosuk a hozzájárulási arány durva közelítése.

1. lépés: szedd ki a naplóból az emberi oldalletöltéseket

A nyers naplóban minden benne van: a képek, a CSS, a botok, a monitorozó szolgáltatások. Ezek nélkül kell dolgozni. Egy Nginx vagy Apache combined formátumú naplón ez a szűrés így néz ki:

zcat access.log.*.gz | grep -viE 'bot|crawl|spider|slurp|monitor|uptime|preview' | awk '$9 ~ /^(200|304)$/ && $7 !~ /\.(css|js|png|jpg|jpeg|gif|svg|webp|woff2?|ico|map|json|xml|txt)/ {print $1}' | sort | uniq -c | wc -l

Ez egyedi IP-címeket számol, ami felfelé és lefelé is torzít (közös mobilhálózati IP, illetve váltakozó IP), de nagyságrendre használható. Pontosabb becsléshez az IP és a user agent párosát vedd egységnek, és a harminc percnél hosszabb szünetet tekintsd új munkamenetnek, ahogy a GA4 is teszi.

2. lépés: hozd azonos alapra a két számot

Ugyanaz a naptári időszak, ugyanaz az időzóna, és ugyanaz a hosztnév. Ha a naplóban a www és a nem www változat, vagy egy aldomain is benne van, a GA4-ben viszont csak az egyik property mér, akkor almát hasonlítasz körtével. A GA4 oldalán a Riportok, Forgalomszerzés nézetből vedd a munkamenetszámot, és zárd ki a belső forgalmat, ha van rá szűrőd.

3. lépés: számolj, és értelmezd óvatosan

A becsült hozzájárulási arány a GA4 munkamenetszám osztva a naplóból becsült munkamenetszámmal. Ha ez az érték hatvan százalék, akkor minden GA4-ben látott munkamenetre nagyjából 1,67 valós munkamenet jut. Ez a szorzó a vakfolt mérőszáma.

Saját tapasztalat: a naplóalapú becslés jellemzően felfelé lövi a forgalmat, mert bot mindig marad benne, ezért a kapott hozzájárulási arányt inkább alsó becslésnek érdemes venni. Ha van sütikezelőd, amelyik naplózza az elfogadás és az elutasítás eseményét, azt is vesd össze ezzel a számmal: két, egymástól független módszer egybevágó eredménye sokkal többet ér, mint egy tizedesjegyre pontosnak látszó egyetlen szám.

Milyen hibák rontják el a becslést?

• Bot-forgalom. A user agent alapú szűrés a jólnevelt botokat kifogja, a rosszindulatúakat nem. Ha hirtelen megugrik a naplós szám, előbb botot keress, ne consent-romlást.
• Gyorsítótár és CDN. Ha a kiszolgálás egy része a CDN-ből megy ki, az az eredeti szerver naplójába be sem kerül. Ilyenkor a CDN saját statisztikáját kell alapul venni.
• Előtöltés és prerender. A böngésző néha megkéri az oldalt anélkül, hogy a felhasználó látná. Ez a naplóban forgalom, a GA4-ben nem.
• A GA4 mérőkód hibája. Mielőtt hozzájárulási problémára gyanakszol, ellenőrizd, hogy a kód minden sablonon fut-e. Egy kimaradó köszönőoldal vagy egy hibás egyoldalas navigáció pont ugyanolyan hiányt okoz.
• Saját és kollégák forgalma. Kis oldalnál ez érdemi tétel, és a naplóban benne van, a GA4-ben viszont gyakran ki van szűrve.

Hogyan javíthatod a hozzájárulási arányt a jogszerűség feladása nélkül?

Rövid válasz: a sáv érthetőségén, hosszán és időzítésén sokat javíthatsz, a két gomb egyenrangúságán nem.

Hivatalosan igazolt: az európai adatvédelmi hatóságok álláspontja szerint az elutasításnak legalább olyan könnyűnek kell lennie, mint az elfogadásnak, előre bepipált jelölőnégyzet nem használható, és a megtévesztő vizuális megoldások (sötét minták) nem elfogadhatók. Az EDPB süti-sávokkal foglalkozó munkacsoportjának jelentése és a megtévesztő felületekről szóló iránymutatás konkrétan kitér arra, amikor az egyik gomb feltűnő, a másik alig látható. Tehát az a tanács, hogy tegyél nagyobb kontrasztot az Elfogadom gombra, ebben a formában nem járható út.

Ami viszont valóban javítható:

1. Elhelyezés. Az alsó sáv jellemzően kevésbé zavaró, mint a képernyő közepét eltakaró ablak, és nem kényszeríti ki az ösztönös bezárást. Kerüld, hogy a sáv eltakarja a fő tartalmat vagy a mobil menüt.
2. Időzítés. Ne az oldal betöltésének első pillanatában ugorjon be, hanem akkor, amikor a látogató már látta, hova érkezett. Rövid késleltetés vagy az első görgetés utáni megjelenés emberibb, ugyanakkor a mérés csak a döntés után indulhat.
3. Szöveg. Két rövid mondat, magyarul, szakzsargon nélkül: mit mérsz, és mire használod. A jogi hivatkozás mehet a bővebb nézetbe. A homályos, hosszú szöveg bizalmatlanságot szül, és a bizalmatlan látogató elutasít.
4. Gombok. Két, azonos súlyú, azonos méretű gomb (Elfogadom, Elutasítom), mellette a Beállítások link. Az egyenrangúság nemcsak jogi elvárás: azt is jelenti, hogy a mért elfogadási arány valódi információ lesz a bizalomról, nem a felület trükkjéről.
5. Konzisztencia. Ha a márkád komolyan veszi az adatvédelmet, és ez az oldal többi pontján is látszik (érthető adatkezelési tájékoztató, kevés harmadik feles kód), az segítheti az elfogadási arányt. Garanciát persze nem ad.
6. Kevesebb kategória. Minél kevesebb külső szolgáltatót kell megjelölnöd, annál rövidebb és annál kevésbé riasztó a sáv. A nem használt beépülők és követőkódok kigyomlálása gyakran többet segít, mint bármilyen szövegcsiszolás.

Saját tapasztalat: a legnagyobb ugrást általában nem a gombok színe hozza, hanem az, hogy a sáv addig rossz volt: ismételten felugrott, mobilon nem lehetett bezárni, vagy a döntést nem tárolta el. Ezek javítása mérhető, és jogilag teljesen szabad terep.

Mit tegyél, ha a vakfolt nagy marad?

Fogadd el, és számolj vele. A gyakorlatban ez négy szokást jelent.

• Ne keverd a forrásokat egy hányadosban. Vagy mindkét fele GA4, vagy mindkét fele teljes rendszerből jön. A vegyes hányados a legveszélyesebb szám a riportban.
• Az arányokat és a trendeket használd, ne az abszolút számokat. Ha a hozzájárulási arány hónapról hónapra nagyjából stabil, akkor a GA4-ben látott növekedés valós növekedést tükröz, még ha a nagyságrend alacsonyabb is.
• A pénzhez kötött döntést teljes adaton hozd meg. A tényleges bevétel, a rendelésszám és az érdeklődések száma a saját rendszeredben van, hiánytalanul. A GA4 arra jó, hogy megmondja, honnan jönnek.
• Írd le a szorzót a riport tetejére. Egyetlen mondat, például hogy a mérés a becsült forgalom hozzávetőleg kétharmadát látja, több félreértést előz meg, mint tíz további grafikon.

Havi ellenőrzőlista

1. Fut-e a mérőkód minden sablonon, a köszönőoldalt is beleértve?
2. Mennyi a naplóból becsült munkamenetszám, botszűrés után?
3. Mennyi ugyanerre az időszakra a GA4 munkamenetszám?
4. Mennyi a kettő hányadosa, és mennyit változott az előző hónaphoz képest?
5. Egyezik-e ez a szám a sütikezelő saját elfogadási statisztikájával, plusz-mínusz néhány százalékponton belül?
6. A konverziós arányt tartalmazó riportokban azonos világból jön-e a számláló és a nevező?
7. Van-e olyan külső kód az oldalon, amit ki lehetne venni, és ezzel a sávot rövidíteni?

A süti-sáv nem az ellenséged, és nem is a mérés vége. Egy ismert nagyságú vakfolt szakmailag kezelhető. Az ismeretlen nagyságú viszont csendben rossz döntésekhez vezet, és ez a különbség sokkal nagyobb, mint néhány százalékpont az elfogadási arányban.

Források és további olvasnivalók

• Google Analytics Súgó: Hozzájárulási mód (Consent Mode) és viselkedési modellezés
• Google Tag Manager Súgó: hozzájárulási beállítások és tag-vezérlés
• Google Search Central dokumentáció: Search Console teljesítményriport
• Európai Adatvédelmi Testület (EDPB): a süti-sávokkal foglalkozó munkacsoport jelentése
• Európai Adatvédelmi Testület (EDPB) 03/2022 iránymutatás a közösségi felületek megtévesztő tervezési mintáiról
• Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói a sütikezelésről
• Általános adatvédelmi rendelet (GDPR) 4. és 7. cikk: a hozzájárulás fogalma és feltételei
• Nginx és Apache HTTP Server hivatalos dokumentáció: hozzáférési napló formátumok
• Cloudflare dokumentáció: süti nélküli webanalitika