Köszönőoldal ajánlatkérés után: mérési pont és következő lépés egyben

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

Mire jó a köszönőoldal ajánlatkérés után?

A köszönőoldal két feladatot lát el egyszerre. Megbízható jelet ad a mérésnek arról, hogy egy ajánlatkérés tényleg beérkezett, és megmondja a látogatónak, mi történik vele ezután. Ha bármelyik hiányzik, akkor vagy a hirdetési rendszerek kapnak rossz adatot, vagy az érdeklődő marad bizonytalanságban, pont abban a percben, amikor a legnyitottabb.

A legtöbb oldalon a köszönőoldal egyetlen mondat („Köszönjük, hamarosan jelentkezünk”) és egy konverziós címke. Mérésre ez éppen elég, de sok lehetőség kimarad. Aki most küldött el egy ajánlatkérést, az döntést hozott, és figyel. Ilyenkor érdemes felkészíteni a beszélgetésre, megadni neki egy gyorsabb utat (hívás, időpont), és a mérést is úgy felépíteni, hogy egy elküldött űrlap pontosan egy konverziót jelentsen.

Mi kerüljön a köszönőoldalra, hogy a látogatónak is hasznos legyen?

A jó köszönőoldal három kérdésre felel. Megérkezett-e a kérés, mi lesz a következő lépés, és mit tehet addig a látogató. Minden más csak akkor kerüljön fel, ha ezt a hármat erősíti.

Mi történik ezután

Írd le a folyamatot lépésekben. Megkaptuk a kérésed, egy kolléga átnézi, felhív vagy e-mailben visszaír, ha kell, egyeztetünk egy felmérést, és utána jön az ajánlat. Konkrét órát vagy napot csak akkor írj, ha azt minden esetben tartani tudod. A be nem tartott ígéret rosszabb benyomást kelt, mint egy határidő nélküli, de világos sorrend.

Kit keresünk, és ki fog keresni

Ha megoldható, mutasd be név szerint, fotóval azt, aki visszahív. Így az ismeretlen szám kevésbé gyanús, és a látogató tudja, kit vár. Érdemes leírni azt is, milyen számról vagy címről érkezik majd a megkeresés, és hogy a visszaigazoló levél a promóciók vagy a levélszemét mappába is kerülhet.

Hasznos tartalom a várakozás idejére

Ide egy rövid felkészülési lista illik, ami lerövidíti az első beszélgetést. Egy felújításnál ez lehet az alapterület, néhány fotó a jelenlegi állapotról és az elképzelt kezdés. Tanácsadásnál a jelenleg használt eszközök, a döntéshozók köre és a fő cél. Mellé jöhet két-három gyakori kérdés a folyamatról. Ez a tartalom a sajátod, ezért a válaszokat is pontosan tudod.

Gyorsabb út azoknak, akik nem akarnak várni

Egy időpontfoglaló gomb vagy egy kattintható telefonszám annak jó, aki sürgősen szeretne beszélni. Ezek a gombok második mérési pontot is adnak, mert a foglalás és a mobilos hívásra koppintás külön eseményként rögzíthető. Az időpontfoglalót be is ágyazhatod, ha a foglalórendszer engedi, így a látogató nem hagyja el az oldalt.

Mi ne kerüljön a köszönőoldalra?

Hagyj le róla mindent, ami elvonja a figyelmet a következő lépésről, vagy rontja a mérést.

• Újabb hosszú űrlap. Aki most töltött ki egyet, ritkán tölt ki még egyet. Ha plusz adat kell, kérd a visszahíváskor.
• Felugró hírlevél-ajánlat. Zavarja a visszaigazolást, és a mérésben összekeveri a két célt.
• A beküldött személyes adatok az URL-ben. Ha az e-mail-cím vagy a telefonszám paraméterként kerül a köszönőoldal címébe, az oldalt betöltő összes mérőkód megkapja. A Google Analytics szabályai tiltják a személyazonosításra alkalmas adat küldését.
• Általános hírfolyam vagy blogajánló. Elviszi a látogatót, mielőtt elolvasná, mi a dolga.
• Zsákutca. A menü és a lábléc maradjon meg, hogy a látogató visszataláljon.

Miért kell noindex a köszönőoldalra, és hogyan állítsd be?

A köszönőoldalt a noindex robots metacímkével vagy X-Robots-Tag HTTP-fejléccel érdemes kizárni a keresési találatokból. Így nem jelenik meg a Google-ben, és nem hoz olyan organikus látogatót, aki ajánlatkérés nélkül érkezik oda, és felfújja a számaidat.

Hivatalosan igazolt. A Google Search Central leírása szerint a noindex csak akkor hat, ha a Googlebot fel tudja térképezni az oldalt. Ha a robots.txt tiltja a feltérképezést, a robot nem látja a metacímkét, és az URL a más oldalakról érkező hivatkozások alapján így is megjelenhet a találatok között. Ezért a köszönőoldalt ne tiltsd robots.txt-ben, ha noindexet használsz.

A beállítás a fejlécben egyetlen sor.

<meta name='robots' content='noindex, follow'>

WordPressben a legtöbb SEO-bővítmény oldalankénti kapcsolóval állítja ezt be. Vedd ki a köszönőoldalt az XML-oldaltérképből is, és ne linkeld a menüből vagy más oldalakról.

Szakmai feltételezés. Az AI-alapú keresők és válaszmotorok robotjai nem feltétlenül kezelik ugyanúgy a noindex utasítást, de egy ajánlatkérés utáni oldalnak amúgy sincs idézhető tartalma. Mérési szempontból az a fontosabb, hogy egy robot látogatása ne váltson ki konverziót. Erről szól a következő rész.

Hogyan szűrd ki a közvetlen eléréssel felfújt konverziót?

Ha a konverziót a köszönőoldal puszta betöltése indítja, minden olyan látogatás konverziónak számít, ami nem űrlapküldésből jön. Ide tartozik a könyvjelzőből visszatérő látogató, a kolléga, aki tesztből megnyitja, a megosztott link és minden JavaScriptet futtató robot. A megoldás az, hogy az eseményt az űrlap sikeres beküldéséhez kötöd, a köszönőoldal URL-je pedig csak a hely, ahol az esemény lefut.

Három bevált megoldás közül választhatsz, megbízhatóság szerinti sorrendben.

1. Szerveroldali, egyszer használatos azonosító. Az űrlap feldolgozása után a szerver egy egyedi lead-azonosítóval irányít át, például /koszonjuk/?lead=8f3a21. A köszönőoldal csak akkor küldi el az eseményt, ha az azonosító érvényes, és még nem használták fel. Ez a legmegbízhatóbb, de fejlesztői munkát igényel.
2. Böngészőoldali jelző. Sikeres beküldéskor az űrlapoldal beír egy jelzőt a sessionStorage-ba, a köszönőoldal pedig csak akkor mér, ha megtalálja, majd azonnal törli. Fejlesztő nélkül, a Google Címkekezelővel is megoldható.
3. A hivatkozó oldal vizsgálata. Csak akkor mérsz, ha a document.referrer az űrlapoldal. Ez gyenge szűrő, mert egyes böngészők és adatvédelmi beállítások levágják a hivatkozót, ezért önmagában ritkán elég.

Saját tapasztalat. A felfújt köszönőoldal-konverzió jellemzően akkor bukik ki, amikor a hirdetési felület több leadet mutat, mint ahány levél vagy CRM-bejegyzés valójában beérkezett. Ha a két szám tartósan eltér, először azt érdemes megnézni, mi indítja a konverziót, és ki van-e szűrve a belső forgalom.

Mi okozza a dupla eseményt frissítéskor, és hogyan előzöd meg?

A dupla esemény abból adódik, hogy a köszönőoldal újratöltésekor, a vissza gombbal való visszatéréskor vagy egy mobilböngésző lapjának újraélesztésekor a mérőkód újra lefut. Ellene két szinten védekezz, az oldalon és a hirdetési rendszer beállításaiban.

Az oldalon a jelző törlése a legegyszerűbb fék. Sikeres beküldéskor az űrlapoldal ezt a sort futtatja.

sessionStorage.setItem('lead_ok', '1');

A köszönőoldalon pedig az alábbi kód fut, a Címkekezelő egyéni HTML-címkéjében vagy a sablonban.

var nav = performance.getEntriesByType('navigation')[0];

var ujratoltes = nav && nav.type === 'reload';

if (sessionStorage.getItem('lead_ok') === '1' && !ujratoltes) { sessionStorage.removeItem('lead_ok'); window.dataLayer = window.dataLayer || []; dataLayer.push({ event: 'generate_lead', lead_id: 'A_LEAD_AZONOSITO' }); }

A Címkekezelőben a generate_lead egyéni eseményre indítod a GA4- és a hirdetési címkéket. A sessionStorage laphoz kötött, ezért ha az űrlap új lapon nyitja meg a köszönőoldalt, a jelző nem megy át. Ilyenkor a szerveroldali azonosító a jobb út.

Hivatalosan igazolt. A Google Ads konverziós műveleteinél a számlálás „Egy” értékre állítható, ami kattintásonként csak egy konverziót számol, és leadeknél a Google is ezt javasolja. Ha a címke tranzakcióazonosítót is kap (erre a lead-azonosítót használhatod), a Google Ads kiszűri az azonos azonosítójú ismételt konverziót. A GA4-ben a kulcsesemények számlálása átállítható munkamenetenként egyszerire. A Meta Pixel és a Conversions API párhuzamos használatakor az event_id paraméter alapján történik a duplikációszűrés.

Hogyan adod át a forrás adatait a köszönőoldalnak és a CRM-nek?

A forrás akkor marad meg biztosan, ha az űrlap rejtett mezőkben maga viszi tovább, a köszönőoldal pedig csak egy semleges lead-azonosítót kap az URL-ben. Így a hirdetési rendszer, az analitika és a CRM ugyanarra a leadre hivatkozik, és személyes adat nem kerül a címsorba.

Lépésről lépésre így néz ki.

1. Érkezéskor olvasd ki az URL-ből a gclid, gbraid, wbraid, fbclid és az utm_ kezdetű paramétereket, és tárold el első féltől származó sütiben vagy localStorage-ban, mert a látogató ritkán az érkezési oldalon tölti ki az űrlapot.
2. Ezekből töltődjenek ki az űrlap rejtett mezői, így a CRM-be a lead mellé bekerül a forrás és a kattintásazonosító.
3. A szerver a mentés után egy lead-azonosítóval irányít át a köszönőoldalra.
4. A köszönőoldal ezt az azonosítót adja át a dataLayer-be, és ez megy tranzakcióazonosítóként a hirdetési címkékbe.
5. Ha az űrlap vagy a köszönőoldal másik domainen van (például egy külső foglalórendszeren), állítsd be a domainek közötti mérést, különben a GA4 új munkamenetet nyit, és a lead hivatkozó forgalomként jelenik meg.

Hivatalosan igazolt. A Google Ads bővített konverziók leadekhez funkciója az űrlapon megadott e-mail-címet vagy telefonszámot hash-elve küldi el, így a később a CRM-ből importált offline konverziókat is a kattintáshoz tudja kötni. Ez akkor jó irány, ha azt akarod mérni, melyik ajánlatkérésből lett tényleges megrendelés. Az adatkezelési tájékoztatót és a hozzájárulás-kezelést ehhez igazítani kell.

Szakmai feltételezés. A kattintásazonosító eltárolása a hozzájárulás-kezelő beállításaitól függ. Ha a látogató elutasítja a marketingsütiket, a rejtett mező üres maradhat, és ezzel a CRM-ben is számolni kell. Erre nincs mindenhol egyforma megoldás, a jogi oldalt érdemes adatvédelmi szakemberrel egyeztetni.

Mikor jobb az oldalon belüli visszaigazolás a köszönőoldal helyett?

Az oldalon belüli visszaigazolás akkor jobb, ha az űrlap felugró ablakban, többlépéses varázslóban vagy egyoldalas alkalmazásban fut, és az átirányítás megtörné a folyamatot. Ilyenkor a mérés az űrlap saját sikeresemény-jelzésére épül, és nincs köszönőoldal, amit bárki közvetlenül megnyithatna.

Előnye, hogy a frissítéses duplázás és a közvetlen elérés problémája eleve kiesik, a látogató pedig ott marad, ahol volt. Hátránya, hogy nincs külön URL, amire közönséget építhetnél, vagy amit egy egyszerű oldalmegtekintés-szabály figyelhetne, és kevesebb hely jut a következő lépésnek.

Hivatalosan igazolt. A Contact Form 7 például sikeres küldéskor wpcf7mailsent DOM-eseményt ad ki, erre a Címkekezelőben egy rövid figyelőkóddal dataLayer-eseményt lehet indítani. A W3C akadálymentességi útmutatója szerint a dinamikusan megjelenő állapotüzenetet aria-live régióban vagy role='status' elemben érdemes megjeleníteni, hogy a képernyőolvasó is felolvassa.

Saját tapasztalat. A Címkekezelő beépített űrlapküldés-triggere AJAX-os űrlapoknál gyakran nem jelez, vagy akkor is jelez, ha a beküldés hibára futott, például mert egy kötelező mező üres maradt. Az űrlap saját sikereseményére építeni megbízhatóbb.

A kettő kombinálható is. Az oldalon belüli üzenet visszaigazol, alatta pedig ott van a hívás vagy az időpontfoglalás gombja, ugyanazzal a tartalommal, ami egy köszönőoldalra kerülne.

Mit tesztelj élesítés előtt?

Élesítés előtt minden pontot egy valós beküldéssel ellenőrizz, a GA4 DebugView és a Címkekezelő előnézeti módja mellett, és nézd meg, hogy a CRM-ben pontosan egy lead jelent meg.

1. Egy beküldés pontosan egy generate_lead eseményt ad a GA4-ben, és egy konverziót a hirdetési címkékben.
2. A köszönőoldal frissítése nem indít új eseményt.
3. A vissza gomb, majd az újbóli előrelépés sem indít új eseményt.
4. A köszönőoldal URL-jét új lapon, közvetlenül megnyitva nincs esemény.
5. Hibás vagy hiányos kitöltésnél (rossz e-mail-formátum, üres kötelező mező) nincs esemény.
6. A köszönőoldalon noindex van, a robots.txt nem tiltja, és az oldaltérképben nem szerepel. Ezt a Search Console URL-vizsgáló eszközével is megnézheted.
7. Az URL-ben és a dataLayer-ben nincs e-mail-cím, név vagy telefonszám.
8. Egy gclid-es és egy utm-es tesztlinkről érkezve a CRM-be bekerül a forrás és a kattintásazonosító.
9. A lead-azonosító tranzakcióazonosítóként megérkezik a Google Ads-címkéhez, a Meta-eseményeknél pedig az event_id egyezik a böngészős és a szerveroldali küldésben.
10. A hozzájárulás elutasításakor a címkék a beállított módon viselkednek.
11. Mobilon a telefonszámra koppintás hívást indít, az időpontfoglaló betölt, és mindkettő külön eseményként mérődik.
12. A belső forgalom (irodai IP-cím, fejlesztői gépek) ki van szűrve a GA4-ben, hogy a tesztek ne torzítsák az éles adatot.

Saját tapasztalat. Élesítés után az első egy-két hétben érdemes naponta összevetni a GA4 kulcseseményeit, a Google Ads konverzióit és a CRM-be érkezett leadeket. A hozzájárulás-kezelés és a hirdetésblokkolók miatt néhány százalékos eltérés jellemzően megmarad, a nagy eltérés viszont jó eséllyel mérési hibára utal.

Források és további olvasnivalók

• Google Search Central, Robots metacímke és X-Robots-Tag specifikáció
• Google Search Central, Letiltás a keresésből a noindex használatával
• Google Analytics súgó, Ajánlott események (generate_lead) és kulcsesemények
• Google Analytics súgó, A személyazonosításra alkalmas adatok küldésének tilalma
• Google Ads súgó, Konverziószámlálási beállítások és tranzakcióazonosítók
• Google Ads súgó, Bővített konverziók leadekhez
• Google Tag Manager súgó, Egyéni esemény trigger és előnézeti mód
• Meta for Developers, Conversions API, eseménydeduplikáció
• W3C WAI, ARIA élő régiók és WCAG 4.1.3 Állapotüzenetek
• MDN Web Docs, sessionStorage és PerformanceNavigationTiming
• Contact Form 7 dokumentáció, DOM-események