Az ajánlatkérésre épülő vállalkozásoknál a hirdetési fiók egyetlen számot tol az arcodba: hány űrlap érkezett. Ez könnyen mérhető, jól mutat a havi riportban, és pont arról hallgat, ami a céget eltartja: hány szerződés lett belőle. Az offline konverziók visszatöltése arra a szakadékra épít hidat, ami az űrlap elküldése és a hetekkel későbbi aláírás között tátong.
Miért félrevezető, ha csak a leadek számát nézed?
Rövid válasz: mert a lead nem bevétel, hanem egy ígéret arra, hogy talán lesz bevétel, és ennek az ígéretnek csatornánként teljesen más a beváltási aránya.
Tovább a témában: Landing page készítés Nyíregyháza · Hogyan növeljem a weboldalam forgalmát? Csatornánként
Nézz egy tisztán számtani illusztrációt (ez nem ügyféladat, hanem gondolatkísérlet): az egyik kampány 40 ajánlatkérést hoz, a másik 20-at. A felület alapján az első a jobb. Ha viszont az elsőből 2, a másodikból 6 szerződés születik, akkor valójában a második hozza a háromszoros üzletet, miközben te éppen a másikba tolod át a keretet. Minél hosszabb és emberibb az értékesítés, annál nagyobb lehet ez az eltérés.
A minőségkülönbségnek ritkán van rejtélyes oka. Aki általános kulcsszóra, széles célzásra vagy erős kedvezmény-ígéretre érkezik, máshol tart a döntésben, mint aki egy konkrét szolgáltatásoldalról, névre keresve írt. Saját tapasztalat: a hosszú átfutású, tervezéssel vagy kiszállással járó szolgáltatásoknál a legnagyobb torzítást nem a rossz hirdetés okozza, hanem az, hogy az árérzékeny és a valóban vásárlásra kész érdeklődő ugyanabban a leadszámban ül, megkülönböztetés nélkül.
A másik gyakori vakfolt az idő. Ha az ajánlattól az aláírásig hat hét telik el, a hirdetési rendszer akkor is optimalizál, amikor még egyetlen valós üzleti visszajelzést sem kapott. Amit visszatöltesz, az nem csak riport: az a tanulóadat, amiből az algoritmus dolgozik.
Mit jelent pontosan az offline konverziók visszatöltése?
Rövid válasz: azt, hogy a rendszeren kívül, emberi munkával megtörtént eseményt (megkötött szerződés, kiszámlázott munka) visszakötöd ahhoz a kattintáshoz vagy leadhez, ahonnan az érdeklődő eredetileg érkezett.
Hivatalosan igazolt: a Google Ads súgója leírja az offline konverziók importálásának folyamatát, amely a kattintáskor keletkező azonosítóra (gclid, illetve az alkalmazás- és iOS-forgalomnál gbraid, wbraid) épül, valamint a leadekhez készült kibővített konverziók lehetőségét, ahol kattintásazonosító helyett hash-elt kapcsolati adat a kulcs. A Meta Business Help Center hasonlóan dokumentálja az offline eseménykészleteket és a Conversions API-t, a Microsoft Advertising pedig a saját msclkid alapú offline importját. A módszer tehát nem trükk, hanem a felületek hivatalosan támogatott funkciója.
Fontos, hogy a visszatöltés nem hoz új üzletet, csak láthatóvá teszi a meglévőt. Attól, hogy pontosabban méred, nem lesz több szerződés, viszont a döntéseid jó eséllyel kevesebb vakon szórt keretet égetnek el.
Hogyan néz ki a teljes lánc az űrlaptól a szerződésig?
Rövid válasz: négy kapcsolódó láncszem van, és ha bármelyik hiányzik, az egész értéktelen: azonosító mentése, átadás a nyilvántartásba, státuszfrissítés, visszatöltés.
1. Azonosító mentése az űrlapnál
Az érkező látogató URL-jében ott a kattintásazonosító. Ezt még az első oldalbetöltéskor el kell kapni, sütiben eltenni (mert a látogató sokszor több oldalt bejár, mielőtt kitölti az űrlapot), majd az űrlap rejtett mezőjébe beírni. Emellett érdemes minden leadnek saját, egyedi azonosítót adni: egy egyszerű sorszám vagy véletlen karakterlánc, ami később az e-mailben, az ajánlatban és a nyilvántartásban is szerepel.
2. Átadás a nyilvántartásba
A beérkező lead ugyanabban a percben kerüljön be oda, ahol az értékesítés dolgozik: CRM-be, ha van, közös munkalapba, ha nincs. A kritikus pont, hogy az azonosító és a beérkezés időbélyege is átjöjjön, ne csak a név és a telefonszám. Ha az azonosító elveszik itt, a lánc vége már nem menthető.
3. Státusz frissítése
Ez a lépés bukik el a leggyakrabban, és ez a legkevésbé technikai. Kell egy rövid, zárt státuszlista (például: új, elértük, ajánlat kiment, megnyert, elveszett, nem valós), és kell egy ember, aki ezt vezeti. Saját tapasztalat: a háromnál több szintű, finomra hangolt státuszrendszer néhány hét alatt kiürül, a négy-öt elemű pedig évekig életben marad.
4. Visszatöltés
A megnyert leadeket a kattintásazonosítóval, a konverzió időpontjával és lehetőleg az értékkel együtt töltöd vissza a hirdetési rendszerbe, vagy ha erre még nem álltok készen, legalább egy közös munkalapon vezetitek, ahol csatornánként összesíthető. Már az utóbbi is döntést tud megváltoztatni.
Milyen kód kell a kattintásazonosító elmentéséhez?
Rövid válasz: néhány sor, ami kiolvassa az azonosítót az URL-ből, elteszi sütibe, és az űrlap küldése előtt beírja egy rejtett mezőbe.
A minta, amit a legtöbb oldalon használni tudsz: const q = new URLSearchParams(location.search); const id = q.get('gclid') || q.get('wbraid') || q.get('gbraid'); if (id) { document.cookie = 'sc_clickid=' + id + ';max-age=7776000;path=/;SameSite=Lax'; }
Az űrlapba pedig egy rejtett mező kerül, például <input type="hidden" name="click_id">, amit küldés előtt töltesz fel a sütiben tárolt értékkel. Ugyanez a logika működik a Meta fbclid és a Microsoft msclkid paraméterére is, csak külön mezőbe téve.
Három apróság, ami rendszeresen elrontja: az oldalon belüli átirányítás lenyeli a paramétert, a gyorsítótárazó bővítmény a sütit nem adja vissza, az űrlap-bővítmény pedig nem menti el a rejtett mezőt az adatbázisba. Élesítés előtt küldj magadnak egy tesztleadet úgy, hogy kézzel írsz egy hamis azonosítót az URL-be, és nézd meg, tényleg megérkezett-e a nyilvántartásig.
Mi legyen a táblázatban, ha nincs CRM?
Rövid válasz: nyolc oszlop, egy felelős és heti egy frissítési időpont. Ennyi. Ez a saját nézőpontunk: a legtöbb kkv-nál a fegyelmezetten vezetett táblázat többet hoz, mint egy félig bekötött integráció.
- lead azonosítója
- beérkezés dátuma
- kattintásazonosító (ha volt)
- forrás és kampány neve
- szolgáltatás vagy termékkör
- státusz a zárt listából
- a megnyert üzlet nettó értéke
- a lezárás dátuma
Ebből havonta kiszámolható a csatornánkénti lezárási arány és az egy szerződésre jutó költség, ami már valódi döntési alap. A gyakorlati tapasztalat szerint a táblázat nem attól hal meg, hogy kevés benne az oszlop, hanem attól, hogy senkinek nem feladata a kitöltése. Nevesített felelős és fix időpont nélkül két hónap alatt használhatatlanná válik.
Ha később integrációra váltotok, ez a táblázat lesz a specifikáció: pontosan tudni fogod, milyen mezőkre van szükség, mert egy éve azokat töltitek kézzel.
Milyen adatvédelmi feltételeknek kell megfelelnie?
Rövid válasz: jogalap, tájékoztatás, szerződéses háttér és megőrzési idő nélkül nem szabad elindulni, akkor sem, ha a technika már készen áll.
- Van érvényes jogalap a hirdetési célú adattovábbításra, és a hozzájárulás kérése valódi választást hagy.
- Az adatkezelési tájékoztató néven nevezi a hirdetési rendszereket, mint címzetteket.
- Sütikezelő fut az oldalon, és a mérőkódok a hozzájárulás állapotához igazodnak (a Google ehhez a hozzájárulási módot, angolul consent mode dokumentálja).
- Kapcsolati adat csak hash-elve (SHA-256) hagyja el a rendszeredet, ahol a felület ezt előírja.
- Az adatfeldolgozói és adattovábbítási feltételek elfogadva, a harmadik országba történő továbbítás kérdése átgondolva.
- Rögzített megőrzési idő, és működő eljárás a törlési kérelemre, beleértve a már feltöltött eseményeket is.
- A táblázat vagy CRM hozzáférése névre szól, nem közösen ismert jelszóval megy.
Ez a lista tájékoztató jellegű szakmai összefoglaló, nem jogi tanácsadás. Érzékeny ágazatban (egészségügy, pénzügy) mindenképpen kérj jogi véleményt, mielőtt bármit feltöltesz.
Milyen technikai buktatók dobják vissza a feltöltést?
Rövid válasz: majdnem mindig az időablak, az időzóna, a hiányzó konverziómenet vagy az elveszett azonosító.
- Az automatikus címkézés (auto-tagging) be van kapcsolva a hirdetési fiókban, különben nem keletkezik kattintásazonosító.
- Létezik külön konverziós művelet az offline eseményre, importálásra állítva, hogy ne keveredjen az űrlapkitöltéssel.
- A kattintás és a lezárás között eltelt idő belefér a felület által megengedett ablakba (a Google súgója konkrét napszámot ad meg, ezt a feltöltés előtt ellenőrizd, mert időnként változik).
- Az időbélyeg formátuma és időzónája megegyezik a fiók beállításával.
- A pénznem és az érték mezője kitöltött, ha értékalapú licitálást tervezel.
- Nincs duplikáció: ugyanaz a lead ne kerüljön fel kétszer, ha átsorolják.
- A visszaigazoló képernyő hibasorait tényleg elolvassa valaki, mert a részlegesen sikeres feltöltés csendben torzít.
Mennyi adat kell ahhoz, hogy ebből a rendszer tanuljon?
Rövid válasz: a riportoláshoz kevés adat is elég, az automatikus licitálás tanításához viszont folyamatos, havi szinten értelmezhető mennyiség kell.
Szakmai feltételezés: havi néhány megkötött szerződésnél a visszatöltött adat elsősorban emberi döntést támogat (hol nyisd a keretet, melyik kulcsszócsoportot vedd vissza), nem gépi optimalizálást. Az algoritmusok akkor tudnak érdemben építeni rá, ha a jelzés rendszeres és nem szakad meg. Kevés adatnál az érték szerinti licitálásra váltás inkább instabillá teheti a fiókot, ezért ilyenkor sokszal biztonságosabb a visszatöltést először csak mérésre használni, és a kampánybeállításhoz hozzá sem nyúlni.
Semmilyen mérési fejlesztés nem garantál jobb eredményt. Attól, hogy pontosabban látod a valóságot, még lehet, hogy az derül ki: a hirdetés nem a probléma, hanem az, hogy az ajánlatkérésekre két nap múlva hív vissza valaki.
Mikor éri meg valódi integrációt építeni?
Rövid válasz: akkor, ha a kézi vezetés már bizonyítottan működik, és a mennyiség miatt fárasztó, nem előtte.
Az integráció költsége nem a bekötés, hanem a fenntartása: a hitelesítés lejár, a mezőnevek elmozdulnak, az űrlap-bővítmény frissül. Az a cég, amelyik előbb vezette be a fegyelmet és csak utána az automatizálást, észreveszi, ha a lánc elszakad. Az, amelyik fordítva csinálta, hónapokig üres adatra optimalizál, és jóhiszeműen hoz rossz döntéseket.
Gyakorlati küszöbnek azt szokás nézni, hogy heti szinten mennyi kézi rögzítés van, és hány ember nyúl ugyanahhoz a sorhoz. Amíg egy ember tíz percben végez vele hetente, addig a táblázat a jobb üzlet.
Források és további olvasnivalók
- Google Ads Súgó: offline konverziók importálása, kibővített konverziók leadekhez
- Google Ads Súgó: automatikus címkézés és a kattintásazonosító működése
- Google fejlesztői dokumentáció: hozzájárulási mód (consent mode)
- Google Search Central: dokumentáció és irányelvek
- Meta Business Help Center: Conversions API és offline eseménykészletek
- Microsoft Advertising Help: offline konverziókövetés
- Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR) hivatalos szövege
- Európai Adatvédelmi Testület (EDPB) iránymutatásai
- Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói
- Schema.org és W3C hivatalos specifikációk
- A lead nem bevétel: azonos leadszám mellett a csatornák lezárási aránya többszörösen eltérhet.
- A lánc négy eleme: azonosító mentése az űrlapnál, átadás a nyilvántartásba, státuszfrissítés, visszatöltés.
- A kattintásazonosítót (gclid, fbclid) rejtett mezőben és sütiben is érdemes megőrizni, mert enélkül nincs mit visszakötni.
- Adatvédelmi oldalról hozzájárulás, tájékoztató, hash-elt adattovábbítás és megőrzési idő nélkül nem indulhat a folyamat.
- A legtöbb kkv-nál egy fegyelmezetten vezetett közös táblázat többet ér, mint egy félig bekötött integráció.
Gyakori kérdések
Mi történik, ha az érdeklődő telefonon hív, nem űrlapot tölt ki?
Ilyenkor nincs kattintásazonosító, ezért a hívásokat külön kell kezelni: hívásmérő megoldással, vagy azzal, hogy a hívást fogadó kolléga megkérdezi és rögzíti, honnan érkezett az érdeklődés. A telefonos szál a gyakorlatban mindig pontatlanabb marad, ezért érdemes külön sorban vezetni, és nem összemosni az űrlapos leadekkel.
Elveszik a kattintásazonosító, ha az érdeklődő több nap múlva tér vissza?
Igen, ha nincs elmentve. Ezért kell sütibe tenni az első érkezéskor, több hónapos élettartammal. Ha a látogató időközben törli a sütijeit, más eszközről tér vissza, vagy nem fogadta el a mérési hozzájárulást, az azonosító akkor is elveszhet. Ez normális veszteség, nem hiba: a leadek egy részét sosem fogod visszakötni.
Muszáj feltölteni a hirdetési rendszerbe, vagy elég a táblázat?
A táblázat önmagában is használható döntéshez, mert megmutatja a csatornánkénti lezárási arányt. A feltöltésnek attól van többlete, hogy az automatikus licitálás is megkapja a jelzést. Kis mennyiségnél a táblázat sokszor elég, és lényegesen kevesebbet romlik el.
Milyen értéket írjak a megnyert üzlethez, ha részletekben számlázunk?
A leggyakoribb megoldás a szerződés nettó összértéke a lezárás dátumával. Ha ez erősen szóródik vagy csak később derül ki, használhatsz egységes átlagértéket is, de akkor ezt következetesen alkalmazd, mert a vegyes logika összehasonlíthatatlanná teszi a csatornákat.
Kell hozzá külön hozzájárulás a látogatótól?
A mérőkódok és a hirdetési célú adattovábbítás jogalapot igényel, és az adatkezelési tájékoztatónak tartalmaznia kell a címzetteket. Ez nem jogi tanácsadás: a pontos megoldást az adott adatkezelésre szabva, jogi segítséggel érdemes rögzíteni, különösen érzékeny adatokat érintő ágazatban.
Mennyi idő alatt látszik, hogy megérte-e?
Annyi idő alatt, amennyi az értékesítési ciklusod, plusz még egy ciklus. Ha az ajánlattól az aláírásig jellemzően hat hét telik el, három hónapnál hamarabb nem lesz értelmezhető mintád, és az ez alapján hozott korai kampánydöntés jó eséllyel többet árt, mint használ.
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.