Mérés ellenőrzése új weboldal élesítése után: az első 72 óra ellenőrzőlistája

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

Amikor új vagy átépített weboldal megy élesbe, a mérés jellemzően csendben romlik el. Az oldal betölt, a hirdetések futnak, a GA4 is mutat valamennyi forgalmat, csak éppen a konverziók tűnnek el, vagy duplán számolódnak. Hibaüzenet nincs, és sokszor csak hetekkel később derül ki, hogy a hirdetési rendszer napok óta vakon optimalizál. Ez a cikk sorrendben végigmehető ellenőrzőlistát ad az első 72 órára a GA4, a Google Tag Manager, a Search Console, a hirdetési konverziók és a hívásmérés számára. Minden pontnál jelöljük, mi hivatalosan igazolt működés, mi saját tapasztalat és mi szakmai feltételezés.

Miért törik el a mérés éppen az élesítéskor?

Azért, mert az új oldal más kóddal, más URL-ekkel és más sütikezeléssel fut, a mérés beállításai viszont még a régi oldalhoz igazodnak. A fejlesztő az oldal működését teszteli, a mérést ritkán, és a mérési hibák semmilyen látható jelet nem adnak a látogatónak.

A leggyakoribb törések, amelyekkel átállásoknál találkozni lehet (Saját tapasztalat):

• Régi vagy hiányzó GTM-konténer. A fejlesztői környezetben egy tesztkonténer futott, vagy az új sablonból egyszerűen kimaradt a kód.
• Elveszett űrlapesemény. Az új űrlapmodul (például egy másik WordPress-bővítmény) nem küldi ugyanazt az eseményt, vagy AJAX-szal küld, oldalbetöltés nélkül.
• Megváltozott köszönőoldal URL. A konverzió a /koszonjuk oldal megtekintésére volt állítva, az új oldalon ebből /koszonjuk-az-erdeklodest lett, vagy nincs is köszönőoldal.
• Új sütibanner. Más hozzájáruláskezelő került fel, amely nem ad jelet a Consent Mode-nak, vagy elfogadás után is blokkolja a címkéket.
• Rossz domain a hivatkozáskizárásban. Domainváltáskor a régi domain marad a beállításokban, és a fizetési szolgáltató vagy a saját domain hivatkozó forrásként jelenik meg.
• Dupla címke. A sablonba beégetett gtag.js mellett a GTM is küld oldalmegtekintést, így minden kétszer számolódik.

Mit készíts elő még az élesítés előtt?

Mentsd ki az élesítés előtti időszak adatait viszonyítási alapnak, és írd le pontosan, mit és hogyan mérsz most. Enélkül 72 óra múlva nem fogod tudni eldönteni, hogy egy visszaesés valós vagy csak mérési.

1. Exportáld a GA4-ből az elmúlt 28 nap napi bontását csatornánként (munkamenetek, aktív felhasználók, kulcsesemények).
2. Mentsd ki a Search Console Teljesítmény jelentését ugyanerre az időszakra, napi bontásban.
3. Írd össze a konverziós pontokat egy táblázatba. Minden sorba kerüljön az esemény neve, a kiváltó feltétel, a köszönőoldal URL-je és az, hogy melyik hirdetési fiókba megy át.
4. Jegyezd fel a GTM-konténer azonosítóját, a GA4 mérési azonosítót (G- kezdetű) és a hirdetési konverziós címkék azonosítóit.
5. Írd fel a weboldalon szereplő összes telefonszámot és a hívásmérési számokat.
6. Számold meg egy független forrásból az elmúlt hetek leadjeit (űrlapértesítő e-mailek, CRM vagy jegykezelő).

Az utolsó pont a legfontosabb. Élesítés után ez lesz az a szám, amelyet sem a sütibanner, sem a címkék nem befolyásolnak.

Mit ellenőrizz az első órában a GTM-ben és a GA4-ben?

Az első órában azt kell igazolni, hogy a helyes konténer fut minden oldalon, pontosan egyszer, és a GA4 valós időben látja a látogatást. Ehhez a Tag Assistant előnézeti módja és a GA4 DebugView elég.

GTM-ellenőrzés

• Nyisd meg az oldal forráskódját, és keresd a gtm.js?id=GTM- szöveget. Az azonosító egyezzen a feljegyzettel, és csak egy konténer legyen, hacsak nem szándékosan fut több.
• Keresd a gtag/js?id= szöveget is. Ha a sablonban beégetett GA4-kód van, és a GTM is küld GA4-címkét, duplán mérsz.
• Indítsd el a GTM előnézeti módját az éles domainen. Nézd meg, hogy a Google-címke az Initialization vagy a Container Loaded eseménynél lefut-e.
• Ellenőrizd a Verziók fület. A fejlesztés alatt végzett konténermódosítás csak közzététel után él (Hivatalosan igazolt).
• Nézd végig az URL-re vagy CSS-osztályra épülő triggereket. Az új sablonban az osztálynevek és az útvonalak jó eséllyel megváltoztak.

GA4-ellenőrzés

• Nyisd meg a Valós idejű jelentést, és a saját gépeden kívül mobilról, mobilnetről is látogasd meg az oldalt.
• A DebugView-ban kövesd végig az eseménysort. Egy oldalbetöltésre egy page_view jöjjön. Ha kettő érkezik, dupla címke fut.
• Ellenőrizd a Nem kívánt hivatkozások listáját az adatfolyam címkebeállításaiban. Ide kerüljön a fizetési szolgáltató domainje (például SimplePay vagy Barion), domainváltásnál pedig nézd meg a domainek közötti mérés beállítását is.
• Ellenőrizd a belső forgalom szűrését. Az első napokban a fejlesztők és a saját csapat forgalma aránytalanul nagy lehet.

A GA4 standard jelentéseiben az adatfeldolgozás akár 24-48 órát is igénybe vehet, ezért az első órában csak a valós idejű nézetre és a DebugView-ra támaszkodj (Hivatalosan igazolt).

Hogyan ellenőrizd az űrlapokat és a köszönőoldalt?

Minden űrlapot küldj el élesben, és kövesd végig, hogy az esemény megérkezik-e a GA4-be, a hirdetési fiókba és a CRM-be. A tesztlead legyen egyértelműen felismerhető (például „TESZT” a név mezőben), hogy később ki tudd szűrni.

Ha a konverzió köszönőoldal-megtekintésre épül, nézd meg a pontos új URL-t, és igazítsd hozzá a kulcsesemény feltételét. Ha az új űrlap AJAX-szal küld, és nincs külön köszönőoldal, a legmegbízhatóbb megoldás az, ha a fejlesztő sikeres beküldéskor dataLayer eseményt küld, és erre épül a GTM-trigger. Egy egyszerű minta, amelyet a sikeres szerverválasz után lehet futtatni.

window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'urlap_elkuldve', form_name: 'ajanlatkeres' });

A GTM-ben ehhez egy Egyéni esemény trigger kell urlap_elkuldve eseménynévvel, a GA4-esemény pedig kapja ugyanezt a nevet. A GA4 bővített mérésének beépített űrlapinterakció-mérése sok űrlapnál pontatlan, és akkor is beküldést jelezhet, ha a validáció hibát dobott (Saját tapasztalat). Ajánlatkérésre vagy kapcsolatfelvételre épülő kulcseseményhez ezért a saját dataLayer-esemény jó eséllyel megbízhatóbb.

Ellenőrizd azt is, hogy az esemény csak sikeres beküldésnél fusson le. Próbáld ki szándékosan hibás e-mail-címmel, és nézd meg, hogy ilyenkor nem jelenik meg az esemény a DebugView-ban.

Mi a teendő az új sütibannerrel és a Consent Mode-dal?

Ellenőrizd, hogy a banner elfogadás előtt helyes alapértelmezett állapotot küld, döntés után pedig frissíti a hozzájárulást. Ha ez elmarad, a GA4 és a hirdetési konverziók jelentős része egyik napról a másikra eltűnhet.

Az Európai Gazdasági Térségben a Google 2024 márciusa óta elvárja a Consent Mode v2 jeleit (ad_storage, analytics_storage, ad_user_data, ad_personalization) a hirdetési mérés és a remarketing egyes funkcióihoz (Hivatalosan igazolt).

1. Nyisd meg az oldalt inkognitóablakban, és a Tag Assistantban nézd meg a Consent fület. Az első eseménynél látszania kell az alapértelmezett állapotnak.
2. Fogadd el a sütiket, és ellenőrizd, hogy az érintett jelek granted értékre váltanak.
3. Egy másik böngészőben utasítsd el őket, és nézd meg, hogy hozzájárulást igénylő címke ilyenkor nem fut le.
4. Mobilon nézd meg, hogy a banner nem takarja-e el az űrlap gombját vagy a hívógombot.

Hivatalos információ, hogy alap módban a Google-címkék a hozzájárulásig nem küldenek adatot, haladó módban pedig süti nélküli jeleket küldenek, amelyekből a Google modellezni tud. Szakmai feltételezés, hogy ha az új banner elfogadási aránya alacsonyabb a régiénél, a GA4-ben látott visszaesés egy része ebből jön, és ez a mérés működésének következménye, nem törés.

Mit nézz meg a Search Console-ban az első 24 órában?

A Search Console-ban azt ellenőrizd, hogy a tulajdon igazolása megmaradt, a Google feltérképezheti és indexelheti az új oldalt, és a régi URL-ek átirányítása működik. A Search Console kattintásai a GA4-től független számot adnak, ezért az összehasonlításnál is hasznosak lesznek.

• Igazolás. Ha a tulajdont GA4- vagy GTM-kóddal igazoltad, és a kód megváltozott, az igazolás elveszhet. A DNS-alapú domaintulajdon ettől független (Hivatalosan igazolt).
• robots.txt és noindex. Nyisd meg a /robots.txt fájlt, és nézd meg, hogy nem maradt-e benne a fejlesztői Disallow: / sor. Az URL-vizsgálóval ellenőrizz néhány fontos oldalt noindex után kutatva. WordPressben a „Keresőmotorok kizárása” jelölőnégyzet gyakran bekapcsolva marad (Saját tapasztalat).
• Webhelytérkép. Küldd be az új sitemapot, és nézd meg, hogy a Google be tudja-e olvasni.
• Átirányítások. Nyisd meg a régi oldal 20 legforgalmasabb URL-jét, és nézd meg, hogy 301-es átirányítással a megfelelő új oldalra visznek-e. A Google útmutatója webhely-áthelyezésnél tartós átirányítást javasol, domainváltásnál pedig a Cím módosítása eszköz használatát (Hivatalosan igazolt).
• Oldalindexelés jelentés. A következő napokban figyeld a 404-es és az átirányítást tartalmazó oldalak számát.

A Search Console teljesítményadatai jellemzően pár nap késéssel frissülnek, így a 72. órában az első egy-két nap adata lesz meg biztosan.

Hogyan ellenőrizd a hirdetési konverziókat?

Minden hirdetési konverziót egy valós teszttel kell kiváltani, és meg kell nézni, hogy a hirdetési felület is rögzíti. A Google Ads és a Meta saját diagnosztikája az első napokban jelzi, ha egy konverziós művelet elhallgatott.

• Google Ads. A Konverziók oldalon nézd meg az egyes műveletek állapotát. Ha egy korábban aktív művelet az élesítés után friss konverzió nélküli vagy inaktív állapotba kerül, ott törés van. A GTM-ben ellenőrizd a Conversion Linker címkét is, mert enélkül a kattintásazonosító mentése nem megbízható.
• gclid megmaradása. Nyisd meg a céloldalt egy tesztparaméterrel (például ?gclid=teszt), és nézd meg, hogy az átirányítások után a paraméter megmarad-e az URL-ben. Az új átirányítási szabályok, a nyelvi előtagok vagy a záró perjel kezelése levághatja (Saját tapasztalat).
• Végső URL-ek. A hirdetésekben szereplő végső URL-eket nyisd meg egyenként. A régi címre mutató hirdetés átirányításon keresztül fut, ami lassít, hibás átirányításnál pedig a hirdetés el is utasítható.
• Meta. Az Eseménykezelő Teszt események fülén kövesd a böngészős és, ha van, a Conversions API-eseményeket. A pixel azonosítója egyezzen a régivel, különben a korábbi közönségek és a tanult optimalizálás elszakad.
• Bővített konverziók. Ha használod, ellenőrizd, hogy az új űrlapmezők (e-mail, telefon) neve vagy CSS-kiválasztója nem változott-e.

Szakmai feltételezés, hogy egy elhallgatott konverziós művelet mellett az okos ajánlattételi stratégiák jelzés nélkül maradnak, és pár nap után rosszabb minőségű forgalmat vásárolhatnak. Ezért a hirdetési konverziókat a 24. órában is nézd meg, ne csak a 72.-ben.

Hogyan mérd a hívásokat az új oldalon?

A hívásmérésnél azt kell ellenőrizni, hogy a kattintható telefonszám eseményt küld, és a hívásmérési számcsere, ha használod, az új sablonban is lefut. Mobilon a hívás gyakran a fő konverzió, és átálláskor ez vész el a legkönnyebben.

• Minden telefonszám legyen tel: linkként kattintható. Képen vagy sima szövegként szereplő szám kattintásként nem mérhető.
• A GTM-ben a csak linkekre figyelő kattintás-trigger feltétele az legyen, hogy a Click URL a tel: előtaggal kezdődjön. Előnézetben nézd meg, hogy a fejlécben, a láblécben és a lebegő hívógombon is lefut.
• A Google Ads webhelyhívás-konverziója a kódban megadott telefonszámot cseréli Google-továbbítási számra (Hivatalosan igazolt). Ha az új oldalon más formátumban szerepel a szám (szóközökkel, vagy +36 helyett 06-tal), a csere jó eséllyel nem fut le (Saját tapasztalat). Hirdetésre kattintva nézd meg, hogy a cserélt szám megjelenik-e.
• Külső hívásmérő szolgáltatónál ellenőrizd, hogy a szkript az új sablonban is betöltődik, és a cserélendő szám karakterre egyezik.
• Indíts egy valós próbahívást mobilról, és nézd meg, hogy a hívásmérőben és a hirdetési fiókban is megjelenik-e.

Hogyan hasonlítsd össze az élesítés előtti és utáni napokat?

Ugyanazokat a hétnapokat vesd össze, abszolút számok helyett arányokat nézz, és minden GA4-számot egy független forrással ellenőrizz. Ha a független forrás stabil, a GA4 pedig hirtelen esik, az jó eséllyel mérési törés.

1. Hétnap-azonosság. Az élesítés utáni napokat az előző 3-4 hét ugyanazon napjainak átlagával hasonlítsd össze. A hétvégi és a hétköznapi forgalom sok szolgáltatónál erősen eltér.
2. Search Console és GA4 aránya. A két szám soha nem egyezik, de az arányuk egy oldalon belül általában stabil. Ha a Search Console kattintásai a megszokott szinten vannak, a GA4 organikus munkamenetei pedig harmadával kevesebbek, a hiba nagy valószínűséggel a mérésben van (Szakmai feltételezés, a tipikus arány oldalanként eltér).
3. Lead-egyeztetés. A GA4 kulcseseményeinek számát vesd össze a CRM-be vagy e-mailben ténylegesen beérkezett leadekkel. Élesítés előtt is volt egy arány, például 10 valós leadből 8 látszott a GA4-ben. Ha ez hirtelen 3-ra esik, a mérés tört el.
4. Arányszámok. Nézd meg a munkamenetenkénti oldalmegtekintést és eseményszámot. Ha hirtelen megduplázódik, vagy az elköteleződési arány gyanúsan 90% fölé ugrik, dupla oldalmegtekintés-címke fut.
5. Forrásmegoszlás. A közvetlen (direct) forgalom hirtelen növekedése és a saját domain megjelenése hivatkozó forrásként arra utal, hogy elvész a forrásinformáció. Ennek oka lehet a domainek közötti mérés hiánya, egy UTM-paramétert levágó átirányítás vagy olyan oldal, ahol nem fut a címke.
6. Céloldal (not set). Ha a céloldal-jelentésben megnő a (not set) aránya, a munkamenet eleje nem rögzül rendesen, ennek gyakori oka a hozzájárulás késleltetett frissítése (Saját tapasztalat).
7. Az élesítés jelölése. Rögzítsd az élesítés és minden javítás pontos idejét. Ha a GA4-fiókodban elérhető a jegyzet (annotáció) funkció, oda írd be, különben egy közös dokumentumba.

Ha a független források ugyanannyit esnek, mint a GA4, a visszaesés valós lehet. Ilyenkor az okát az oldal tartalmában, sebességében vagy az átirányításokban érdemes keresni.

Mi legyen a 24., 48. és 72. órás ellenőrzés tartalma?

Az első 72 órát három körre érdemes bontani. Az első kör a működést igazolja, a második az adatok megérkezését, a harmadik az arányokat.

• 0-2. óra. GTM-azonosító, dupla címke, DebugView, űrlapteszt, hívásteszt, a sütibanner mindhárom állapota, robots.txt és noindex.
• 24. óra. Megjelennek-e a kulcsesemények a GA4 standard jelentéseiben, mi a Google Ads konverziós műveletek állapota, mit mutat a Meta Eseménykezelő, megvan-e a Search Console igazolás és a sitemap, ki vannak-e szűrve a tesztleadek.
• 48. óra. Forrásmegoszlás (direct, saját domain, fizetési szolgáltató), céloldal (not set), átirányítási hibák az Oldalindexelés jelentésben.
• 72. óra. Hétnap-azonos összevetés, Search Console és GA4 aránya, lead-egyeztetés a CRM-mel, és döntés arról, hogy maradt-e javítandó törés.

Ha bármelyik ponton törést találsz, javítsd, és a javítás időpontját is jegyezd fel. A javítás előtti napok adatát később ne kezeld összehasonlítható adatként, mert félrevezetheti a hirdetési és a SEO-döntéseket.

Források és további olvasnivalók

• Google Analytics súgó (DebugView, Nem kívánt hivatkozások, adatfeldolgozási idő)
• Google Tag Manager súgó és Tag Assistant dokumentáció
• Google Search Central, Webhely áthelyezése URL-módosítással
• Google Search Console súgó (tulajdon igazolása, Oldalindexelés jelentés)
• Google Ads súgó (konverziókövetés, hozzájárulási mód, webhelyhívás-konverziók)
• Meta Business súgó (Eseménykezelő, Conversions API)