GA4 egyedi elemzések és riasztások: így kapj értesítést, ha leáll a lead-mérés

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

Ha egy űrlap csendben elromlik, a GA4-ben semmi nem villog. A jelentésekben egyszerűen kevesebb lead látszik, és ezt sokszor csak hetekkel később veszi észre valaki, amikor a havi számok gyanúsan alacsonyak. Erre a helyzetre való az egyedi elemzés (angolul custom insight). Megadod, melyik mutatót figyelje a GA4 és milyen feltétel mellett, és ha a feltétel teljesül, e-mailt kapsz róla. Az alábbiakban végigmegyünk a beállításon, a küszöbök kiválasztásán és azon, mi a teendő, amikor megjön a levél.

A cikkben jelöljük, mi a hivatalosan igazolt információ (a Google Analytics súgója alapján), mi saját tapasztalat, és mi szakmai feltételezés.

Mire jók a GA4 egyedi elemzései, és mire nem?

Az egyedi elemzés egy szabály, amelyet a GA4 óránként, naponta, hetente vagy havonta lefuttat az adataidon. Ha a feltétel teljesül, az eredmény megjelenik az elemzések listájában, és kérésre e-mailben is megérkezik. Gyors figyelmeztetésnek jó, valós idejű riasztásnak viszont nem alkalmas.

Hivatalosan igazolt. A Google Analytics súgója szerint egy tulajdonságon legfeljebb 50 egyedi elemzés hozható létre, és az óránkénti kiértékelés csak webes adatokra érhető el. Feltétel lehet egy konkrét érték alá vagy fölé kerülés, a százalékos változás, illetve a GA4 saját anomália-észlelése. Az anomália-észlelés tanuló időszakkal dolgozik, ez óránkénti figyelésnél két hét, napinál 90 nap, hetinél 32 hét, havinál 25 hónap.

Hivatalosan igazolt az is, hogy a standard tulajdonságok adatainak feldolgozása 24-48 órát is igénybe vehet. Egy napi riasztás ezért jellemzően a tegnapi vagy a tegnapelőtti napról szól.

Saját tapasztalat. Kis forgalmú oldalon az anomália-feltétel gyakran olyan ingadozásra is szól, aminek üzletileg nincs jelentősége. Ahol ismered a normál szintet, ott a fix küszöb kiszámíthatóbban működik.

Hogyan állítasz be egy egyedi elemzést lépésről lépésre?

Egy egyedi elemzés hat döntésből áll, ezek a gyakoriság, a szegmens, a mutató, a feltétel, a név és a címzettek. A teljes beállítás néhány perc, a küszöb átgondolása tart tovább.

1. Nyisd meg a GA4 tulajdonságot, és a Kezdőlapon vagy a Jelentések áttekintésén keresd meg az Elemzések és javaslatok kártyát. Ha megnyitod az összes elemzést, a Létrehozás gombbal indíthatsz új egyedi elemzést. A menüpontok neve frissítéskor változhat, ezért ha nem találod, a súgóban keress rá az „egyéni elemzés” kifejezésre.
2. Válaszd ki a kiértékelés gyakoriságát (óránként, naponta, hetente vagy havonta).
3. Add meg a szegmenst. Ez lehet az összes felhasználó vagy egy dimenzió értéke, például egy forgalmi csatorna, egy ország vagy egy eseménynév.
4. Válaszd ki a mutatót és a feltételt, például Kulcsesemények, kisebb mint 1.
5. Adj neki beszédes nevet, hogy a postafiókban első ránézésre kiderüljön, mi romlott el. Jól bevált minta a [LEAD] heti generate_lead nulla, cegnev.hu forma.
6. Add meg az értesítendő e-mail címeket, és mentsd el.

Saját tapasztalat. Mentés után érdemes egy próbát tenni. Állíts be ideiglenesen egy olyan feltételt, amely biztosan teljesül (például napi oldalmegtekintés nagyobb mint 1), várd meg a következő kiértékelést, és nézd meg, megérkezik-e a levél, illetve nem a spam mappában köt-e ki. Utána állítsd vissza a valódi küszöbre.

Hogyan kapsz értesítést, ha a kulcsesemények száma nullára esik?

A lead-mérés leállását két külön riasztás fogja meg a legjobban. Az egyik azt nézi, érkezik-e egyáltalán adat az oldalról, a másik a lead-eseményt figyeli.

Erre azért van szükség, mert a két hiba másképp néz ki. Ha az egész mérőkód eltűnik (például egy sablonfrissítés kiszedi a Tag Manager tárolót, vagy hibásan működik a süti-banner), minden mutató leesik. Ha csak az űrlap-esemény áll le (bővítményfrissítés, megváltozott köszönőoldal-URL), az oldalmegtekintések rendben vannak, a leadek viszont eltűnnek.

• Mérőkód-riasztás. Napi gyakoriság, összes felhasználó, Oldalmegtekintések kisebb mint a szokásos napi minimum fele.
• Lead-riasztás. Heti gyakoriság, szegmensként az Eseménynév legyen generate_lead, mutató az Eseményszám, feltétel kisebb mint 1.

A lead-riasztásnál azért érdemes eseménynévre szűrni, mert ha több kulcseseményed is van (például telefonszámra kattintás), azok a teljes számot nulla fölött tarthatják, miközben az űrlap már napok óta nem mér.

Hivatalosan igazolt. A generate_lead a Google által ajánlott eseménynév. Sikeres beküldés után így küldheted el gtag.js-sel.

gtag('event', 'generate_lead', { form_id: 'ajanlatkeres' });

Ezután az Adminisztráció Események menüjében jelöld meg kulcseseményként. Tag Managerben ugyanezt egy GA4 eseménycímke végzi, amely a beküldés sikerét jelző triggerre fut.

Hogyan figyeld az organikus forgalom hirtelen esését?

Az organikus esést heti gyakorisággal, százalékos csökkenésre érdemes figyelni, mert a napi szám a hét napjai között is erősen ingadozik.

A beállítás egyszerű. A szegmens a Munkamenet alapértelmezett csatornacsoportja, értéke Organikus keresés. A mutató a Munkamenetek, a feltétel pedig a százalékos csökkenés 30 százalék fölött, kisebb oldalnál 40 százalék fölött.

Szakmai feltételezés. Közepes forgalomnál (hetente néhány száz organikus munkamenet) a 30-40 százalékos sáv ritkán szól ok nélkül. Ünnepi hetekben (karácsony, nyári szabadságok, hosszú hétvégék) viszont szinte biztosan jön egy riasztás, ezért ezekre készülj fel előre.

Arra is figyelj, hogy a GA4 csak a kattintásokat látja. Ha a megjelenések száma a Search Console-ban stabil, a kattintások mégis csökkennek, annak más oka lehet (például a keresési találati oldal változása), mint egy indexelési hibának.

Hogyan kapsz riasztást, ha megugrik a 404-es oldalak száma?

404-es eseményt a GA4 magától nem küld, ezért előbb létre kell hoznod egy saját eseményt, és csak utána tudsz rá riasztást beállítani.

WordPress-oldalon a 404-es sablon címe jellemzően „Az oldal nem található” vagy valami hasonló. Tag Managerben egy oldalmegtekintéses trigger kell, amelynek feltétele, hogy a Page Title tartalmazza ezt a szöveget, a hozzá tartozó GA4 eseménycímke neve pedig legyen hiba_404. Ha a sablonhoz közvetlenül hozzáférsz, a 404-es oldalba ez a sor is beírható.

gtag('event', 'hiba_404', { page_location: location.href, page_referrer: document.referrer });

Az egyedi elemzés ezután napi gyakoriságú, a szegmens az Eseménynév hiba_404 értékkel, a mutató az Eseményszám, a feltétel pedig nagyobb mint a szokásos napi csúcs kétszerese. Az első két-három hétben csak figyeld, mekkora a normál szint, és utána állítsd be a küszöböt.

Saját tapasztalat. A hirtelen ugrás leggyakoribb oka egy törölt termék vagy aloldal, egy megváltozott URL, egy hibás menülink, vagy egy külső oldal (néha egy AI-válasz), amely nem létező címre hivatkozik. A sebezhetőséget kereső botok többsége nem futtat JavaScriptet, ezért ezek jó eséllyel nem jelennek meg ebben az eseményben.

Milyen küszöböt válassz kis forgalomnál, hogy ne jöjjön folyamatos téves riasztás?

Kis forgalomnál hosszabb kiértékelési időszakot és fix küszöböt válassz, így a természetes ingadozás nem vált ki riasztást. Az időszak legyen akkora, hogy benne átlagosan legalább 3-5 lead érkezzen.

Szakmai feltételezés. Ha a leadek egymástól függetlenül, egyenletes átlaggal érkeznek, akkor annak az esélye, hogy egy időszakban egy sem jön, nagyjából e^(-átlag). Heti 1 lead átlagnál ez körülbelül 37 százalék, vagyis majdnem minden harmadik héten téves riasztást kapnál. Heti 3 leadnél kb. 5 százalék (nagyjából húszhetente egy téves jelzés), heti 5-nél kb. 0,7 százalék. A valóságban a leadek nem teljesen függetlenek, és van szezonalitás is, ezért ezt kiinduló becslésnek tekintsd.

• Napi legalább 5 lead esetén napi figyelés, kisebb mint 1 küszöbbel.
• Heti 3-20 lead esetén heti figyelés, kisebb mint 1 küszöbbel.
• Havi 3-12 lead esetén havi figyelés, mellé pedig egy napi mérőkód-riasztás, amely gyorsabban jelez, ha a teljes mérés leáll.

A százalékos riasztásokhoz is kell egy minimális mennyiség. Heti 100 organikus munkamenet alatt egy 40 százalékos esés még lehet véletlen, ott 50 százalékos küszöb vagy havi figyelés a nyugodtabb választás (szakmai feltételezés).

Ki kapja az e-mailt?

Az e-mailt az kapja, aki a riasztás után tenni is tud valamit, és mellette legalább egy ember a vállalkozás oldaláról, aki látja a valós beérkező megkereséseket.

Saját tapasztalat. A technikai riasztások (mérőkód, 404) a mérést kezelő emberhez vagy ügynökséghez menjenek. A lead-riasztás menjen a cégvezetőnek vagy az értékesítőnek is, mert ő pár perc alatt meg tudja mondani, jöttek-e megkeresések a postafiókba vagy telefonon. Ha nyolc ember kapja ugyanazt a levelet, könnyen mindenki azt hiszi, hogy majd valaki más foglalkozik vele. Szabadság idején is jól működik egy közös cím vagy csoportos postafiók. A levelekre tegyél szűrőt és címkét a levelezőben, hogy ne vesszenek el a hírlevelek között.

Milyen alap riasztáscsomag kell egy szolgáltató cégnek és egy webshopnak?

Szolgáltató cégnél öt riasztás elég a legtöbb hiba elkapásához, webshopnál hét. Mindkét csomag jóval az 50-es tulajdonságonkénti korlát alatt marad.

Szolgáltató cég

1. [TAG] napi oldalmegtekintés kisebb mint a szokásos napi minimum fele.
2. [LEAD] heti (kis forgalomnál havi) generate_lead eseményszám kisebb mint 1.
3. [LEAD] heti kulcsesemények csökkenése több mint 50 százalék.
4. [SEO] heti organikus munkamenetek csökkenése több mint 30-40 százalék.
5. [404] napi hiba_404 eseményszám nagyobb mint a szokásos csúcs kétszerese.

Webshop

1. [TAG] napi oldalmegtekintés kisebb mint a szokásos napi minimum fele (nagy forgalomnál óránként is).
2. [VÁSÁRLÁS] napi purchase eseményszám kisebb mint 1, ha naponta legalább öt rendelés jön, egyébként heti figyeléssel.
3. [PÉNZTÁR] napi begin_checkout eseményszám kisebb mint 1. Ha a pénztár elindul, de vásárlás nem jön, a hiba jó eséllyel a fizetésnél vagy a köszönőoldalon van.
4. [BEVÉTEL] heti vásárlási bevétel csökkenése több mint 40 százalék.
5. [FIZETETT] napi fizetett keresésből érkező munkamenetek csökkenése több mint 50 százalék (leállt kampány, elfogyott keret, kártyahiba).
6. [SEO] heti organikus munkamenetek csökkenése több mint 30-40 százalék.
7. [404] napi hiba_404 eseményszám nagyobb mint a szokásos csúcs kétszerese. Webshopnál ez gyakran törölt termék miatt ugrik meg.

Saját tapasztalat. A külső fizetési oldalra irányító megoldásoknál előfordul, hogy a vásárló nem tér vissza a köszönőoldalra, így a purchase esemény kimarad. Ezért a vásárlás-riasztásnál mindig a webshop rendeléslistájával vesd össze a számot.

Mi a teendő, amikor megjön egy riasztás?

Először azt döntsd el, hogy mérési hiba vagy valódi üzleti esés történt. Ezt a valós rendszer (postafiók, CRM, webshop-admin) és a GA4 összevetése mutatja meg.

1. Nézd meg a valós rendszert. Ha a postafiókban vagy a rendelések között vannak új tételek, de a GA4 nem látja őket, akkor mérési hibáról van szó. Ha ott sincs semmi, akkor az oldal vagy az üzlet oldalán van a gond.
2. Nyisd meg a Valós idejű jelentést, és nézd meg, érkezik-e most adat.
3. Tölts ki egy próbaűrlapot vagy adj le egy tesztrendelést, közben pedig a Tag Assistantben vagy a DebugView-ban figyeld, elsül-e a generate_lead vagy a purchase.
4. Keresd meg, mi változott. Ilyen lehet a Tag Manager verziótörténete, a WordPress bővítmény- és sablonfrissítései, a süti-banner beállításai vagy egy új köszönőoldal.
5. Organikus esésnél nyisd meg a Search Console-t. Nézd meg a Teljesítmény-jelentést (megjelenés és kattintás külön), az oldalak indexelését és a kézi intézkedéseket. Azt is ellenőrizd, hogy nem került-e véletlenül noindex az oldalakra, vagy nem változott-e a robots.txt.
6. 404-es ugrásnál szűrd az Oldalak és képezők jelentést a hiba_404 eseményre, és a page_referrer alapján nézd meg, honnan jönnek a látogatók. A gyakori hibás címeket irányítsd át 301-es átirányítással a legközelebbi releváns oldalra.
7. Írd le, mi történt. Egy egyszerű naplóban rögzítsd a dátumot, a riasztást, az okot és a javítást. Ha a tulajdonságodban elérhető a jegyzet (annotation) funkció, a javítás napját ott is jelöld meg.

Saját tapasztalat. Ha egy riasztás többször is ok nélkül szól, ne hagyd figyelmen kívül, inkább igazítsd a küszöbét vagy a gyakoriságát. A rendszeresen téves riasztásokat egy idő után senki nem olvassa el, és akkor a valódi hiba is elsikkad.

Források és további olvasnivalók

• Google Analytics súgó, Egyéni elemzések létrehozása és kezelése
• Google Analytics súgó, Anomália-észlelés az Analyticsben
• Google Analytics súgó, Adatfrissesség és feldolgozási idő
• Google Analytics fejlesztői dokumentáció, Ajánlott események (gtag.js)
• Google Tag Manager súgó, Triggerek és GA4 eseménycímkék
• Google Search Central, Search Console Teljesítmény-jelentés és Oldalindexelési jelentés