Egy magyar KKV-oldal havi forgalma tipikusan néhány száz munkamenet. Ebben a nagyságrendben minden egyes látogatás súlya nagy, és pont ezért fáj, ha a mérésben ott van a tulajdonos napi háromszori ellenőrzése, az ügynökség heti átnézése, a fejlesztő tesztelése és a szövegíró korrektúrázása. Nagy oldalon ez elvész a zajban, kis oldalon viszont ez maga a zaj. Az alábbiakban végigmegyünk azon, hogyan zárod ki ezt a GA4-ből úgy, hogy közben ne semmisítsd meg visszafordíthatatlanul a saját adatodat.
Miért torzít ennyire a saját forgalom egy kis oldalon?
Rövid válasz: mert a belső látogatás viselkedése szisztematikusan más, mint az ügyfélé, így nem csak felhígítja, hanem el is húzza a mutatókat.
Vegyünk egy egyszerű számpéldát. Az oldalnak havi 240 munkamenete van. Ebből a tulajdonos hetente ötször ránéz, ez 20 munkamenet. Az ügynökség havi 12 alkalommal nyitja meg, a fejlesztő egy módosítás alatt 25-30 oldalletöltést produkál. Összesen 60 körüli munkamenet, a teljes forgalom negyede. Ez a 25 százalék nem semleges: a belső látogató jellemzően közvetlen forgalomként érkezik, sokáig nézi az oldalt (mert dolgozik rajta), soha nem konvertál, és többnyire ugyanarról a néhány eszközről jön.
Ennek három konkrét következménye van. Az elköteleződési arány és az átlagos munkamenet-időtartam felfelé torzul, tehát jobbnak látod az oldalt, mint amilyen. A konverziós arány lefelé torzul, mert a nevezőben ott vannak azok a munkamenetek, amelyek eleve nem konvertálhattak. A csatorna-eloszlás pedig a közvetlen forgalom felé csúszik, ami elfedi, hogy valójában mennyit hoz az organikus keresés vagy a hirdetés. (Saját tapasztalat: a legtöbb vitát a konverziós arány szüli, mert az ügyfél a hirdetést hibáztatja olyan mutató alapján, amit a saját kattintásai rontanak el.)
Mit nevez a GA4 belső forgalomnak, és mit fejlesztői forgalomnak?
Rövid válasz: a belső forgalom IP-cím alapján megjelölt látogatás, a fejlesztői forgalom pedig a hibakeresési módban futó mérés. Két különböző mechanizmus, két külön szűrővel.
(Hivatalosan igazolt.) A belső forgalomnál a GA4-ben megadsz egy IP-szabályt, és az arról a címről érkező eseményekre a rendszer ráteszi a traffic_type paramétert, alapértelmezetten internal értékkel. Fontos, hogy a szabály önmagában semmit nem zár ki: csak címkéz. A tényleges kiszűrést a property szintjén létrehozott adatszűrő végzi, amely a traffic_type paraméter értékére illeszkedik.
A fejlesztői forgalom ettől független: ott a debug_mode paraméter a jelzés, amit a GTM előnézeti módja, a Tag Assistant vagy a kód szintjén beállított hibakeresési kapcsoló tesz rá az eseményekre. Ehhez a GA4-ben külön szűrőtípus tartozik. (Saját tapasztalat: sok cégnél csak a belső forgalom szűrő van beállítva, a fejlesztői nincs, pedig egy nagyobb átalakítás alatt a GTM előnézetben töltött órák önmagukban is elviszik egy hét adatát.)
Hogyan állítod be az IP-alapú belső forgalom szabályt lépésről lépésre?
Rövid válasz: az adatfolyam beállításai között hozod létre a szabályt, majd a property adatszűrői között kapcsolod élesbe, előbb tesztelő állapotban.
- Nézd meg a kizárandó IP-t. Nyisd meg abban a hálózatban a böngészőt, és keress rá arra, hogy mi az IP-címem. Ezt kérd el az ügynökségtől és a fejlesztőtől is, az irodai és az otthoni hálózatra külön.
- A GA4-ben menj a Rendszergazda menübe, ott az Adatgyűjtés és -módosítás alatt az Adatfolyamok pontba, és nyisd meg a webes adatfolyamot.
- Kattints a Címkebeállítások konfigurálása lehetőségre, majd az Összes megjelenítése gombra. Itt találod a Belső forgalom meghatározása pontot.
- Hozz létre egy szabályt. Adj neki beszédes nevet (például
iroda-fix-ipvagyfejleszto-otthoni), atraffic_typeértékét hagydinternalértéken, és válaszd ki az illesztés típusát. - Az illesztésnél nem csak pontos egyezés adható meg: kezdődik ezzel, végződik ezzel, tartalmazza, illetve CIDR-tartomány is használható. Ha a szolgáltató egy tartományon belül osztja az IP-t, a tartomány a praktikusabb.
- Minden hálózathoz külön szabályt vegyél fel, ne próbáld egy sorba gyömöszölni őket. Így később egyesével kivehetők, ha valaki elköltözik vagy szolgáltatót vált.
- Ezután menj vissza a Rendszergazda menübe, és nyisd meg az Adatszűrők pontot. Itt már ott van egy Belső forgalom nevű szűrő, alapértelmezetten Tesztelés állapotban. Ellenőrizd, hogy a paraméter értéke pontosan az, amit a szabályban megadtál.
- A fejlesztői forgalomhoz hozz létre egy második, Fejlesztői forgalom típusú szűrőt, szintén tesztelő állapotban.
(Hivatalosan igazolt.) A GA4 az IP-címet nem tárolja el az adatbázisban, azt a földrajzi feloldáshoz és az ilyen szabályok kiértékeléséhez használja, majd eldobja. Ezért a szűrést a beérkezés pillanatában kell eldönteni, nem lehet utólag IP alapján visszakeresni a saját látogatásaidat.
Miért kell a szűrőt tesztelő módban indítani?
Rövid válasz: mert az aktív szűrő által eldobott adat végleg elveszik, visszamenőleg nem állítható helyre.
(Hivatalosan igazolt, és ez a cikk legfontosabb pontja.) Ha a szűrő Aktív állapotba kerül, a rá illeszkedő események be sem kerülnek a property adataiba. Nem elrejtve vannak, hanem nincsenek. Ha egy hét múlva kiderül, hogy elgépelted az IP-t, és véletlenül egy szolgáltatói tartományt zártál ki, amelyben ott van fél Székesfehérvár, akkor az az egy hét adat nem hozható vissza a szűrő kikapcsolásával.
Ez az a hiba, amit nem lehet visszacsinálni, ezért a saját szabályom egyszerű: a szűrő legalább két hétig tesztelő állapotban marad, és csak akkor kapcsolom aktívra, ha a tesztelési adat egyértelműen azt mutatja, hogy pontosan a kívánt forgalmat fogja meg. (Saját tapasztalat.) A kockázat nem elméleti: mobilhálózaton vagy CGNAT mögött ugyanaz a kimenő IP több száz előfizetőé lehet.
Tesztelő állapotban az adat továbbra is bekerül a mérésbe, csak megjelölve. Ezt a Felfedezés (Explore) felületen tudod megnézni: hozz létre egy szabad formátumú jelentést, és vedd fel a Teszt adatszűrő neve dimenziót. Ahol ez a dimenzió kitöltött, ott a szűrő aktív állapotban kizárta volna az adott sort. Így számszerűen látod, mennyi forgalmat érintene a szűrés, még mielőtt véglegesítenéd.
Mit csinálj, ha nincs fix IP-d?
Rövid válasz: ilyenkor nem az IP-t, hanem az eszközt jelölöd meg, sütivel vagy böngészőbővítménnyel, és a jelölés alapján állítod be a traffic_type paramétert.
A magyar KKV-k többségénél nincs fix IP, mert az külön szolgáltatás. Két járható út van.
Böngészőbővítményes kizárás
A Google saját, hivatalos leiratkozó bővítménye (Google Analytics Opt-out Browser Add-on) a legegyszerűbb megoldás: telepítés után az adott böngészőből egyáltalán nem megy mérési adat egyetlen GA-property felé sem. Előnye, hogy nem kell hozzá kódot módosítani, és a fejlesztőnek vagy a szövegírónak is egy perc feltenni. Hátránya, hogy mindent letilt, tehát ha a saját forgalmadat külön szeretnéd látni (például ellenőrzésképp), erre nem alkalmas. Böngészőnként és gépenként külön kell telepíteni, és inkognitó ablakban általában nem aktív.
GTM-es, sütialapú vagy debug módú kizárás
A rugalmasabb megoldás, ha a kizárást a Google Tag Managerben oldod meg. A logika: egy titkos paraméterrel meghívott URL beállít egy hosszú élettartamú sütit az adott böngészőben, és amíg az a süti létezik, a GA4 címke belső forgalomként jelöli az eseményeket.
A süti beállítása egyszeri, egy egyedi HTML-címkével, amely csak akkor fut le, ha az URL-ben ott a paraméter (például ?belso=1):
if (location.search.indexOf('belso=1') > -1) { document.cookie = 'scheo_belso=1; max-age=63072000; path=/'; }
Ezután készíts egy elsőfél sütiváltozót scheo_belso néven, majd a GA4 konfigurációs címkéden vedd fel a traffic_type mezőt, értéke pedig legyen egy olyan változó, amely a süti megléte esetén internal, egyébként üres. gtag.js-t használó, GTM nélküli oldalon ugyanez így néz ki:
gtag('config', 'G-XXXXXXXXXX', { traffic_type: 'internal' });
A GA4 oldalán semmit nem kell máshogy csinálni: ugyanaz a Belső forgalom adatszűrő fogja meg, amelyik az IP-alapú jelölést, hiszen mindkettő ugyanazt a paramétert állítja.
A GTM előnézeti mód külön eset: az abban töltött látogatás debug_mode paramétert kap, ezt pedig a Fejlesztői forgalom szűrő kezeli. (Szakmai feltételezés: ez a szűrő a hibakeresési jelzésre épül, ezért ha valaki kódszinten állandóan bekapcsolva hagyja a hibakeresést az éles oldalon, akkor a valódi látogatók is kieshetnek. Ilyet ritkán látni, de átalakítás után érdemes ellenőrizni.)
Mikor kell a hivatkozó kizárása, és mikor nem?
Rövid válasz: akkor, ha a látogató az oldalról átmegy egy külső rendszerbe és onnan visszatér, mert a visszatérés különben új munkamenetnek és hivatkozó forgalomnak látszik.
A tipikus eset a fizetési átjáró és a foglalási rendszer. A látogató a kosárból átmegy a bank vagy a fizetési szolgáltató felületére, ott fizet, majd visszaérkezik a köszönőoldalra. Ha a szolgáltató domainje nincs a nem kívánt hivatkozók listáján, akkor a GA4 a visszatérést új forrásnak veszi, és a konverzió annak a hivatkozónak lesz jóváírva, nem az eredeti kampánynak. A saját aldomainek ugyanígy viselkedhetnek, ha a domainek közötti mérés nincs beállítva.
A beállítás ugyanott van, mint a belső forgalom szabály: Adatfolyamok, Címkebeállítások konfigurálása, Összes megjelenítése, Nem kívánt hivatkozók listázása. Ide a fizetési szolgáltató, a foglalórendszer és a saját, külön domainen futó aldomainek kerülnek. Amit ne tegyél ide: az általános hivatkozó forrásokat (partneroldal, katalógus, sajtómegjelenés), mert azokat pont látni akarod.
Honnan tudod, hogy tényleg működik a szűrő?
Rövid válasz: ha a DebugView-ban látod a paramétert, a Felfedezésben látod a teszt szűrő nevét, és a szűrő élesítése után a valós idejű jelentés nem mutat téged.
- Nyisd meg a saját gépeden az oldalt, és a GA4 DebugView felületén ellenőrizd, hogy az eseményeken ott van-e a
traffic_typeparaméterinternalértékkel. Ha nincs, a jelölés nem működik, és hiába állítasz be bármilyen szűrőt. - Készíts egy szabad formátumú felfedezést a Teszt adatszűrő neve dimenzióval, legalább hét napra visszamenőleg. A kitöltött sorok mennyisége mutatja, mennyi forgalmat érintene az élesítés.
- Nézd meg, hogy a megjelölt forgalom nagyságrendje reális-e. Ha havi 240 munkamenetből 200-at jelöl belsőnek, valamit elrontottál, jó eséllyel túl tág IP-tartományt adtál meg.
- Ellenőrizd, hogy a megjelölt munkamenetek között nincs-e konverzió olyan eseménnyel, amit csak valódi ügyfél tud kiváltani (ajánlatkérés, vásárlás). Ha van, a szabály idegen forgalmat is elkap.
- Az élesítés után nyisd meg az oldalt a saját gépedről, és nézd meg a valós idejű jelentést. Ha nem jelensz meg benne, a szűrő dolgozik.
- Adj neki időt. (Saját tapasztalat: az állapotváltás nem azonnal látszik minden jelentésben, ezért egy teljes napot érdemes várni az értékeléssel.)
- Írd fel az élesítés dátumát, és tedd rá megjegyzésként a riportjaidra. Enélkül fél év múlva senki nem fogja érteni, miért esett vissza a forgalom egy adott napon.
- Évente egyszer nézd át a szabályokat. Az irodai IP változik, a fejlesztő lecserélődik, az ügynökség átköltözik.
Milyen hibák jönnek elő a leggyakrabban?
Rövid válasz: a jelölés és a szűrés összekeverése, a túl tág IP-tartomány, és az aktív állapot túl korai bekapcsolása.
A leggyakoribb félreértés, hogy valaki felveszi a belső forgalom szabályt, aztán csodálkozik, hogy semmi nem változik. A szabály csak címkéz, a szűrő zár ki, és a szűrő alapból tesztelő módban van. A második gyakori hiba a mobilnetes vagy megosztott IP kizárása: itt tényleg érdemes inkább a sütialapú megoldást választani. A harmadik, hogy csak a tulajdonos IP-je kerül be, az ügynökségé és a fejlesztőé nem, pedig a nyers oldalletöltések nagyobb része tőlük származik egy fejlesztési szakaszban.
Végül egy elvi pont. A belső forgalom kizárása nem javítja meg a rossz mérést, csak leveszi róla a zajt. Ha a konverziókövetés hibás, a szűrő attól még hibás konverziókat fog mutatni, csak kevesebbet. Ezért a sorrend: előbb működő mérés, utána szűrés, és csak azután következtetés. A tiszta alapadat segítheti a jó döntést, de önmagában nem garantál eredményt.
Források és további olvasnivalók
- Google Analytics Súgó: Belső forgalom szűrése (Filter out internal traffic)
- Google Analytics Súgó: Adatszűrők (Data filters) és a szűrőállapotok
- Google Analytics Súgó: Nem kívánt hivatkozók listázása (Unwanted referrals)
- Google Analytics Súgó: DebugView és a hibakeresési mód
- Google Analytics fejlesztői dokumentáció: gtag.js konfigurációs paraméterek
- Google Tag Manager Súgó: elsőfél sütiváltozók és az előnézeti mód
- Google Analytics Opt-out Browser Add-on (hivatalos Google bővítmény)
- Google Search Central: mérés és analitika alapok
- Kis forgalmú oldalon a belső látogatás nem zaj, hanem a mért kép jelentős része, ezért a kizárás nem finomhangolás, hanem alapfeltétel.
- A belső forgalom szabály csak megjelöli a látogatást a traffic_type paraméterrel, a tényleges kizárást a property-szintű adatszűrő végzi.
- Az adatszűrőt tesztelő módban kell indítani, mert az aktív szűrő által eldobott adat visszamenőleg nem állítható helyre.
- Változó IP esetén a böngészőbővítményes vagy sütialapú GTM-es megoldás használható, a debug_mode alapú fejlesztői szűrő pedig a GTM előnézeti módot fedi le.
- A fizetési és foglalási átirányítások miatt a nem kívánt hivatkozók listáját is érdemes karbantartani, különben a saját tranzakcióid hivatkozásként jönnek vissza.
Gyakori kérdések
Miért nem tűnik el a saját forgalmam, pedig beállítottam a belső forgalom szabályt?
Mert a szabály csak megjelöli a látogatást a traffic_type paraméterrel, a tényleges kizárást a property-szintű adatszűrő végzi. Az a szűrő alapértelmezetten tesztelő állapotban van, tehát nem szűr, csak jelöl. Nézd meg a Rendszergazda menü Adatszűrők pontját, és a tesztelési időszak után váltsd aktívra.
Visszakapom az adatot, ha kikapcsolom az aktív szűrőt?
Nem. Az aktív szűrő által kizárt események be sem kerülnek a property adataiba, tehát visszamenőleg nem állíthatók helyre. Pontosan ezért érdemes a szűrőt előbb tesztelő módban futtatni, és a Felfedezés felületen a Teszt adatszűrő neve dimenzióval ellenőrizni, mit fogna meg.
Mit tegyek, ha az irodánknak nincs fix IP-je?
Két megoldás van. Az egyik a Google hivatalos leiratkozó böngészőbővítménye, amely az adott böngészőből minden mérést letilt. A másik egy sütialapú GTM-megoldás: egy titkos URL-paraméterrel beállítasz egy hosszú élettartamú sütit, és amíg az megvan, a GA4 címke traffic_type internal értékkel küldi az eseményeket.
Hogyan zárom ki a fejlesztő GTM előnézeti módban töltött látogatásait?
A GTM előnézeti mód a debug_mode paramétert teszi az eseményekre, ehhez pedig a GA4-ben külön Fejlesztői forgalom típusú adatszűrő tartozik. Ezt is tesztelő állapotban hozd létre, és ugyanúgy ellenőrizd, mint a belső forgalom szűrőt.
Kell a fizetési szolgáltatót felvenni a nem kívánt hivatkozók közé?
Ha a látogató az oldalról átmegy a fizetési vagy foglalási felületre, majd visszatér a köszönőoldalra, akkor igen. Enélkül a visszatérés új munkamenetnek és hivatkozó forgalomnak látszik, és a konverzió nem az eredeti forráshoz kerül. Általános hivatkozó oldalakat viszont ne tegyél ide, azokat látni akarod.
Mennyi belső forgalom számít soknak?
Nincs hivatalos küszöb, de kis oldalon a tíz százalék fölötti arány már érdemben torzítja a konverziós arányt és a csatorna-eloszlást. Ha a tesztelő módú mérés azt mutatja, hogy a forgalom nagy részét belsőnek jelölnéd, az inkább hibás szabályra utal, mint valós belső használatra.
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.