Hétfő reggel megnyitod az Analyticset, és a tegnapi nap oszlopa feleakkora, mint egy héttel korábban. A konverziók száma nulla. Az első reflex ilyenkor a pánik, hogy büntetett a Google, elvitte a versenytárs a helyezéseket, vagy rossz lett a tartalom. A tapasztalatunk az, hogy az egy nap alatti, éles letörés mögött legtöbbször nem a látogatók tűntek el, hanem a mérés szakadt meg. Ez a cikk egy sorrendet ad arra, hogyan zárd ki a lehetséges okokat, mielőtt bármihez hozzányúlsz az oldalon.
Miért a mérési hibára érdemes először gyanakodni?
Mert a valódi kereslet ritkán változik egyik napról a másikra, a mérés viszont egyetlen mentéssel eltörhet. Egy rangsorvesztés vagy piaci visszaesés jellemzően fokozatosan, napok vagy hetek alatt rajzolódik ki, és nem ugyanabban az órában kezdődik, amikor valaki frissített egy bővítményt.
[Saját tapasztalat] A „tegnaptól semmi nincs” típusú riasztások döntő többségénél a Search Console és a telefonforgalom változatlan volt, az ok pedig a mérésben volt. Kikapcsolódott egy címke, rosszul állt be a sütibanner, egy gyorsítótár-bővítmény késleltette vagy összevonta a követőkódot, vagy megváltozott a köszönőoldal címe.
[Szakmai feltételezés] Ennek oka egyszerű. A mérőkód egy JavaScript-lánc végén fut, amelyet sok szereplő érint (fejlesztő, automatikus bővítményfrissítés, tárhelyszolgáltató, CDN, jogi okból módosított banner), és a módosítás után ritkán nézi meg bárki a mérést. A keresőben elért láthatóság ezzel szemben sok, egymástól független tényező eredője, ezért ritkán omlik össze egyetlen nap alatt.
Mit csinálj az első negyedórában?
Semmit ne módosíts, csak rögzítsd a tüneteket, vagyis hogy mikor kezdődött, mi esett le pontosan, és hol. Ha ilyenkor kapkodva átírsz címeket vagy visszaállítasz egy mentést, a nyomokat is eltünteted.
- Jegyezd fel az első érintett nap dátumát, és ha lehet, az órát is. GA4-ben egy felfedező jelentésben az óra dimenzió gyakran pontosan megmutatja a törés idejét.
- Bontsd csatornára. Ha minden csatorna egyszerre és hasonló arányban esett (organikus, közvetlen, fizetett, közösségi), az szinte biztosan mérési jel. Ha csak az organikus esett, akkor jöhet szóba keresőoldali ok.
- Bontsd eszközre és böngészőre. Ha csak Safariban vagy csak mobilon tűnt el a forgalom, az szkript- vagy bannerhibára utal.
- Bontsd oldalra. Az egész webhely esett, vagy csak néhány URL? Az egész oldalra kiterjedő, egyik napról a másikra jelentkező esés ritkán tartalmi eredetű.
- Készíts képernyőképet a jelenlegi állapotról, mert a legfrissebb napok adatai utólag még módosulhatnak.
[Hivatalosan igazolt] A Google Analytics súgója szerint az adatok feldolgozása akár 24-48 órát is igénybe vehet, ezért a tegnapi és a mai nap számai még változhatnak. Az „esés” egy része néha csak feldolgozási késés.
Egy általános forgatókönyv, hogy lásd, hogyan fest ez a gyakorlatban. Kedden délután frissül egy sütikezelő bővítmény, szerda reggel a GA4 minden csatornán nagyjából kétharmados esést mutat, a Search Console kattintásai viszont nem változnak, és a postafiókba ugyanannyi ajánlatkérés érkezik, mint korábban. Ilyenkor nem a tartalommal van gond, hanem azzal, hogy a hozzájárulás után nem indul el a mérőkód. Tíz perc tesztelés kideríti, két nap tartalmi átírás viszont semmit nem javítana.
Változott bármi a méréskódban, a sütibannerben, a tárhelyen vagy a sablonban?
Ez a legfontosabb kérdés, és a válasz jó eséllyel itt van. Keress minden módosítást az esés előtti 48 órából, akkor is, ha első ránézésre semmi közük a méréshez.
Méréskód és Tag Manager
A Google Tag Manager Verziók menüpontjában látod, ki és mikor tett közzé új verziót. Ha a közzététel ideje egybeesik a töréssel, hasonlítsd össze az előző verzióval, és keress törölt vagy szüneteltetett címkét, módosított triggert, átírt mérési azonosítót. Nézd meg a forráskódban azt is, hogy a G- kezdetű GA4-azonosító egyszer szerepel-e, és a helyes tulajdonhoz tartozik-e. Gyakori hiba, hogy egy sablonfrissítés után a kód kétszer fut, vagy egy teszttulajdon azonosítója kerül élesre.
Gyors ellenőrzés a böngésző fejlesztői konzoljában:
typeof gtag; window.dataLayer && window.dataLayer.length
Ha a gtag értéke undefined, vagy a dataLayer üres, a kód nem töltődött be. A Tag Assistant és a GA4 DebugView megmutatja, hogy a böngésző tényleg küld-e eseményt.
Sütibanner és hozzájárulás
[Hivatalosan igazolt] A Google Consent Mode alapmódjában a Google-címkék addig nem töltődnek be, amíg a látogató nem ad hozzájárulást. Ha a banner beállítása megváltozik (például alapértelmezetten mindent elutasít, vagy az elfogadás gomb nem küldi el a frissítést a címkéknek), a mért forgalom egyik napról a másikra a töredékére eshet, miközben a valódi látogatók száma változatlan.
Ellenőrizd inkognitóablakban. Fogadd el a sütiket, és nézd meg a DebugView-ban, megjelenik-e a munkamenet. Utána ismételd meg elutasítással. Ha elfogadás után sem jön adat, a banner és a címke közti kapcsolat szakadt meg. Nézd meg a bannerszolgáltató változásnaplóját is, mert automatikus frissítés után a sütikategóriák hozzárendelése néha visszaáll alapértékre.
Tárhely, gyorsítótár, CDN
Költözés, PHP-verzióváltás, új gyorsítótár-bővítmény vagy CDN-beállítás (JavaScript késleltetése, összevonása, tömörítése) mind eltörheti a mérést. [Saját tapasztalat] A „JavaScript késleltetése felhasználói interakcióig” típusú optimalizálás különösen alattomos, mert a mérőkód csak görgetés vagy kattintás után indul, így a gyorsan távozó látogatók eltűnnek a jelentésből. Kapcsold ki ideiglenesen az optimalizálást, ürítsd a gyorsítótárat, és nézd meg újra a DebugView-t.
Ellenőrizd a DNS-t és a tanúsítványt is. Ha a webhely egy része régi szerveren vagy más címen fut tovább, a forgalom kettéválhat, és a mérés csak az egyik felét látja.
Sablon és oldalszerkezet
Konverzió-eséskor először azt nézd meg, létezik-e még a köszönőoldal ugyanazon az URL-en. Ha az űrlap új verziója oldalújratöltés nélkül küld, és már nem irányít át, az URL-alapú konverzió többé nem teljesül. Ugyanez a helyzet, ha a gomb CSS-osztálya vagy azonosítója megváltozott, és a kattintásos trigger erre épült.
Mit mutat a Search Console ugyanarra az időszakra?
Ha a Search Console kattintásai nem estek, az organikus forgalom sem esett, csak a mérése. A Search Console a Google oldaláról számolja a kattintásokat, a webhelyen futó kódtól és a sütibannertől függetlenül, ezért ez az első független kontrollpont.
[Hivatalosan igazolt] A Google dokumentációja szerint a Search Console és az Analytics számai nem egyeznek pontosan, mert más eseményt és más módon számolnak. Ne az egyezést keresd, hanem a görbe alakját, vagyis hogy ugyanazon a napon tört-e meg mindkettő.
- Nyisd meg a Teljesítmény jelentést, és állíts be összehasonlítást az esés előtti és utáni, azonos hosszúságú, azonos napokat tartalmazó időszakra (hétfőt hétfővel).
- Nézd a kattintásokat és a megjelenéseket külön. Ha a megjelenések stabilak, de a kattintások csökkentek, a találati oldal változhatott (új elem, AI-összefoglaló, több hirdetés), nem feltétlenül a helyezésed.
- Szűrj oldalra és lekérdezésre, hogy lásd, koncentrált-e a csökkenés.
- Nézd meg az Oldalindexelés jelentést és a Kézi műveletek menüt.
- Vesd össze a dátumot a Google Search Status Dashboard bejelentett frissítéseivel.
A Search Console legfrissebb napjai még hiányosak lehetnek, ezért ha a törés a tegnapi napon van, egy-két nap múlva nézd meg újra.
Mit mutat a szerveroldali napló?
A hozzáférési napló minden kiszolgált kérést rögzít JavaScript és süti nélkül, ezért ez mutatja meg a legtisztábban, jöttek-e emberek. Ha a napló szerint a lapletöltések száma változatlan, a látogatók megvannak.
Apache vagy Nginx alapértelmezett, combined formátumú naplójánál ez a parancs naponként megszámolja a HTML-kéréseket, a nyilvánvaló botok és a statikus fájlok nélkül:
grep -viE 'bot|crawl|spider|slurp' access.log | grep -vE '\.(css|js|png|jpe?g|webp|svg|woff2?|ico)' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
Az eredmény napokra bontott darabszám. Ha az esés napján ez a szám nem csökkent, a GA4 esése mérési eredetű. A Google-ből érkező látogatásokat a hivatkozó mező alapján külön is megszámolhatod, ha a fenti lánc elejére teszel egy grep 'google\.' szűrést.
Két korlátra figyelj. Ha CDN vagy teljes oldalas gyorsítótár szolgálja ki az oldalakat, a kérések egy része el sem jut a szerverig, ilyenkor a CDN saját statisztikáját nézd. [Szakmai feltételezés] A böngészőazonosító alapú botszűrés pontatlan, ezért a naplót trendre használd, ne abszolút számra. Ha a naplóban a vizsgált időszak előtt hirtelen ugrás látszik, az is lehet, hogy a korábbi „normál” szint volt botokkal felfújva.
Mit mutat a valós üzleti jelzés?
A telefonhívások, a beérkező levelek és a webshop rendelései a végső bíró. Ha ezek a megszokott szinten vannak, üzleti értelemben nincs baj, a mérést kell javítani.
- Webshopnál a háttérrendszer rendeléslistáját vesd össze naponként a GA4 vásárlási eseményeivel. Ha a rendelések megvannak, de az esemény nem, a mérés tört el.
- Űrlapnál nézd meg az űrlapbővítmény saját beküldési listáját (ha tárolja), és külön a postafiókot. Ha a bővítmény rögzít, de levél nem érkezik, a levélküldés romlott el (SMTP, SPF, DKIM), nem a forgalom.
- Küldj be egy tesztet te magad, más eszközről és mobilnetről, hogy kizárd a saját hálózatod hatását.
- Telefonnál nézd meg a hívásnaplót, vagy kérdezd meg a kollégákat, akik a hívásokat fogadják.
[Saját tapasztalat] Előfordul, hogy a konverzió valóban esett, de nem a forgalom miatt. Kiesett egy fizetési mód, nem megy ki az értesítő levél, vagy egy frissítés után hibát dob a kosár. Ez valós esés, de a gyökere technikai, nem marketing.
Hogyan néz ki az egyoldalas kizárási lista?
Felülről lefelé haladj, és csak akkor lépj tovább, ha az adott sort kizártad. Érdemes kinyomtatni vagy a csapat közös mappájába tenni.
- Adatkésés. Eltelt legalább 48 óra az érintett nap után?
- Időzóna és szűrők. Nem változott a tulajdon időzónája, adatszűrője vagy belső forgalmi szabálya?
- Tag Manager. Volt közzététel az esés előtti 48 órában?
- Forráskód. Egyszer és a helyes azonosítóval fut a mérőkód?
- Sütibanner. Elfogadás után megjelenik a munkamenet a DebugView-ban?
- Bővítmények és sablon. Frissült bármi, változott a köszönőoldal vagy a gombok azonosítója?
- Tárhely és CDN. Rendben van a költözés, a gyorsítótár, a JavaScript-optimalizálás, a DNS és a tanúsítvány?
- Csatornabontás. Minden csatorna egyszerre esett? Ha igen, szinte biztosan mérési hiba.
- Search Console. A kattintások görbéje ugyanazon a napon tört meg?
- Szervernapló. Csökkent a HTML-lapletöltések száma?
- Üzleti jelzés. Kevesebb a hívás, a levél, a rendelés?
- Külső esemény. Ünnepnap, szezonvége, leállt hirdetés, lejárt fizetési mód a hirdetési fiókban?
Mikor szabad tartalmi vagy rangsorbeli okra gyanakodni?
Csak akkor, ha a független források (Search Console, szervernapló, üzleti jelzés) közül legalább kettő is mutatja az esést, és a mérési oldalon semmi nem változott. Ezt a szabályt érdemes szigorúan tartani, mert a tartalomhoz nyúlni drága és lassan visszafordítható döntés.
A szabály három feltétele:
- A GA4 esése mellett legalább két független forrás is csökkenést mutat ugyanarra az időszakra.
- Az esés az organikus csatornára vagy meghatározott oldalakra, lekérdezésekre koncentrálódik, nem egyenletes az egész webhelyen és minden csatornán.
- A kizárási lista első hét sorában nincs a töréssel egybeeső változás.
Ha ez teljesül, jöhet a rangsorvizsgálat. Mely lekérdezéseknél csökkent az átlagos pozíció, esett-e ki oldal az indexből, egybeesik-e a dátum egy bejelentett alapfrissítéssel? [Hivatalosan igazolt] A Google Search Central útmutatója szerint egy alapfrissítés utáni csökkenés nem feltétlenül jelent hibát az oldalon, és egyedi javítással nem biztos, hogy gyorsan visszaállítható. [Szakmai feltételezés] Emiatt rangsorbeli esésnél érdemes néhány hétig adatot gyűjteni, mielőtt nagy tartalmi átalakításba kezdesz.
Milyen csapdákba szokás belesétálni a vizsgálat közben?
A leggyakoribb hiba a rossz összehasonlítás és az, hogy egyszerre több dolgot változtatsz. Mindkettő elfedi a valódi okot.
- Rossz összehasonlítási alap, amikor hétvégét hétköznappal vagy ünnepnapot munkanappal vetsz össze.
- Felfújt korábbi szint, ha az előző időszakban spam- vagy botforgalom volt, így a „normális” szám sosem volt valós.
- [Hivatalosan igazolt] A GA4 bizonyos esetekben (például bekapcsolt Google-jelek mellett) adatküszöböt alkalmaz, és elrejti a kis elemszámú sorokat, ami kis forgalmú szegmensben látszólagos eltűnést okozhat.
- Több változó egyszerre. Ha a hibakeresés közben három dolgot állítasz vissza, nem fogod tudni, melyik volt az ok. Egyszerre egyet változtass, és jegyezd fel az időpontját.
- Hirdetési oldal. Ha a fizetett forgalom esett, nézd meg, fut-e a kampány, érvényes-e a fizetési mód, és nem utasítottak-e el hirdetést.
Végül vezess változásnaplót. Egy egyszerű közös táblázat (dátum, óra, ki, mit módosított) a következő esésnél percekre rövidítheti a kizárást, mert a 3-7. sort egyetlen pillantással le tudod zárni.
Források és további olvasnivalók
- Google Search Central, Search Console súgó (Teljesítmény jelentés, Oldalindexelés, Kézi műveletek)
- Google Search Central, útmutató a Google Kereső forgalmának csökkenéséhez
- Google Search Status Dashboard
- Google Analytics súgó (adatfeldolgozási idő, DebugView, adatküszöbök)
- Google Tag Manager súgó (tárolóverziók és közzététel)
- Google fejlesztői dokumentáció, Consent Mode
- Apache HTTP Server dokumentáció, naplófájlok
- Nginx dokumentáció, ngx_http_log_module
- Az egyik napról a másikra jelentkező, éles letörés jó eséllyel mérési hiba, mert a valódi kereslet ritkán változik ilyen gyorsan.
- Az esés előtti 48 óra minden módosítását nézd át, a Tag Managertől a sütibanneren és a gyorsítótáron át a sablonig.
- A Search Console, a szervernapló és a valós üzleti jelzés egymástól független kontrollpontok, a GA4-et ezekhez mérd.
- Tartalmi vagy rangsorbeli okra csak akkor gyanakodj, ha legalább két független forrás is esést mutat, és a mérési oldalon semmi nem változott.
- Egy egyszerű változásnapló a következő esésnél percekre rövidítheti a kizárást.
Gyakori kérdések
Honnan tudom gyorsan, hogy mérési hiba vagy valódi esés történt?
Bontsd a GA4 adatait csatornára, és nézd meg a Search Console kattintásait ugyanarra a napra. Ha minden csatorna egyszerre esett, a Search Console viszont stabil, jó eséllyel mérési hibáról van szó.
Miért nem egyeznek a Search Console és a GA4 számai?
A két eszköz mást számol. A Search Console a Google találati oldalán történt kattintásokat, a GA4 a webhelyen lefutott mérőkód eseményeit, amelyet a sütibanner és a böngésző is befolyásol. A görbék alakját érdemes összevetni, nem a pontos számokat.
Okozhat forgalomesést a sütibanner frissítése?
Igen. Ha Consent Mode alapmódban a hozzájárulás nem jut el a címkékhez, a GA4 nem kap adatot, így a mért forgalom egyik napról a másikra töredékére eshet, miközben a valódi látogatók száma változatlan.
Mit nézzek a szervernaplóban?
A HTML-oldalakra érkező kérések napi számát, botok és statikus fájlok nélkül. Ha ez nem csökkent, a látogatók megvannak. CDN vagy teljes oldalas gyorsítótár esetén a CDN statisztikáját is nézd meg.
Mikor érdemes a tartalmat átírni egy esés után?
Csak ha legalább két független forrás is esést mutat, az esés meghatározott oldalakra vagy lekérdezésekre koncentrálódik, és a mérési oldalon nem történt változás. Alapfrissítés után érdemes néhány hétig adatot gyűjteni a nagy átalakítás előtt.
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.