A konverziómérés az a pont, ahol a marketing átfordul számvitelbe: ha a mérőléc rossz, akkor minden ráépülő döntés is rossz lesz. A kellemetlen az, hogy ez nem hangos hiba. A riport nem dob hibaüzenetet, hanem magabiztosan kiír egy értéket, te pedig hónapokig egy olyan szám alapján állítod a költést, ami soha nem is stimmelt. A tapasztalatom az, hogy amikor egy fiókban a hirdetési eredmény és a valós bevétel szétcsúszik, tíz esetből nyolcszor nem stratégiai gond van, hanem mérési.
Az alábbi hét hiba a leggyakoribb okozó. Nem elméleti lista: mindegyikhez leírom, miről ismered fel, és mit csinálj vele.
Miért mutat minden rendszer mást ugyanarról a hónapról?
Rövid válasz: részben azért, mert a rendszerek eleve máshogy számolnak (más attribúciós ablak, más modell, más időzóna), részben azért, mert tényleges hiba van a mérésben. A kettőt szét kell választani, mielőtt bárki bármit megmagyaráz.
A szétválasztás módszere egyszerű: keress egy olyan mutatót, ami elvileg nem függhet az attribúciótól. Ilyen a leadott rendelések száma vagy a beérkezett ajánlatkérések száma egy adott napon. Ha a webshop adminfelületén 40 rendelés van, az analitikában 47, akkor ez nem attribúciós különbség, hanem mérési hiba. Ha viszont a hirdetési fiók mond 22-t, az analitika 15-öt ugyanarra a kampányra, az simán lehet módszertani eltérés is.
Szakmai feltételezés a részemről: ha a saját rendszered (webshop, CRM) és az analitika közti eltérés tartósan 5 százalék felett van, akkor érdemes végigmenni ezen a listán. Ez nem hivatalos küszöbérték, hanem gyakorlati ökölszabály.
Hogyan ismered fel és javítod a duplikált konverziós eseményeket?
Rövid válasz: a duplikáció akkor keletkezik, ha ugyanaz az esemény két úton is beérkezik, és nincs rajta egyedi azonosító, ami alapján a rendszer felismerhetné, hogy ez ugyanaz.
Tipikus árulkodó jelek: a konverziószám gyanúsan pontosan a duplája a rendelésszámnak, egy tranzakcióazonosítóhoz több vásárlás esemény tartozik, vagy a köszönőoldal frissítése után újra megnő a szám.
A leggyakoribb okok, amikkel találkozni szoktam:
- A mérőkód be van illesztve a weboldal sablonjába és ki van adva címkekezelőn keresztül is.
- Egyoldalas (SPA) webhelyen a virtuális oldalletöltésre és egy gombkattintásra is elsül ugyanaz a címke.
- Böngészőoldali és szerveroldali mérés párhuzamosan fut, de nincs közös eseményazonosító.
- A vásárló visszalép vagy frissít a köszönőoldalon, és a kód újra lefut.
- Egy bővítmény (webshop modul) és a címkekezelő is elküldi ugyanazt.
A javítás mindig ugyanaz a három lépés. Először: legyen egy forrás. Döntsd el, hogy a vásárlás eseményt a bővítmény vagy a címkekezelő küldi, és a másikat kapcsold ki. Másodszor: minden tranzakciós eseményre kerüljön egyedi azonosító.
dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'WEB-2026-10482', value: 34900, currency: 'HUF', items: [] } });
Harmadszor: ha böngészőoldali és szerveroldali küldés is fut (például Meta Conversions API mellett pixel), akkor mindkét oldalon ugyanaz az eseményazonosító menjen ki, mert a deduplikáció ezen múlik.
fbq('track', 'Purchase', { value: 34900, currency: 'HUF' }, { eventID: 'WEB-2026-10482' });
Hivatalos információ: a Meta dokumentációja szerint a böngészőoldali és a szerveroldali esemény összepárosítása az eseménynév és az eseményazonosító egyezésén alapul, tehát ha az azonosító kimarad, a rendszer két külön eseménynek látja őket.
Mit ront el a hiányzó vagy félrekonfigurált hozzájárulás-kezelés?
Rövid válasz: hozzájárulás nélkül vagy nem mérsz (aluljelentés), vagy jogszerűtlenül mérsz. Mindkettő valós kockázat, csak az egyik a riportban látszik, a másik nem.
A hibának két iránya van. Az egyik, amikor a süticsík rendesen blokkol, de nincs mögötte semmilyen modellezés, így a mérés egyszerűen elveszíti azokat, akik nem fogadták el. Ilyenkor a konverziószám valós, csak jóval kevesebb, mint a valóság, és a hirdetési optimalizálás kevesebb jelből dolgozik. A másik irány a veszélyesebb: a banner ott van, de a mérőcímkék a döntés előtt elsülnek. Ez adatvédelmi szempontból problémás, ráadásul gyakran duplikációt is okoz, mert a címke a döntés után újra lefut.
Hivatalos információ: a Google Consent Mode négy jelzést kezel (ad_storage, analytics_storage, ad_user_data, ad_personalization), és a Google dokumentációja szerint az alapértelmezett állapotot a mérőcímkék betöltése előtt kell beállítani.
gtag('consent', 'default', { ad_storage: 'denied', analytics_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', wait_for_update: 500 });
Az ellenőrzés így néz ki a gyakorlatban: nyisd meg az oldalt inkognitó ablakban, és játszd végig mindhárom esetet. Elfogadás után menjen ki minden. Elutasítás után ne menjen ki mérőcímke. Ha nem nyúlsz a bannerhez, akkor is a tiltott állapot legyen érvényben. Ha bármelyik eset máshogy viselkedik, ott a hiba.
Miért mérsz rossz célt, és mi lenne a jó?
Rövid válasz: mert könnyebb bejelölni minden gombkattintást konverziónak, mint eldönteni, melyik esemény jelent tényleg üzletet.
Klasszikus tünet: a fiókban tizenkét konverziós esemény van bekapcsolva elsődlegesként, köztük a telefonszám-kattintás, a menü megnyitása, a görgetés 75 százalékig és a kapcsolat oldal megtekintése. A gond nem az, hogy ezeket méred (mikrokonverziónak hasznosak), hanem az, hogy elsődleges célként adod oda az automata licitnek. Az algoritmus pontosan azt fogja csinálni, amit kérsz tőle: megkeresi azt a közönséget, amelyik a legolcsóbban görget és kattint a menüre.
A rendezés menete:
- Írd le egy mondatban, mi az üzleti esemény, ami pénzt hoz (leadott rendelés, elküldött ajánlatkérés, foglalás).
- Ez legyen az egy elsődleges konverzió kampánycélonként. A többi maradjon másodlagos, megfigyelésre.
- Ha lead-alapú vagy, mérd a minőséget is: a CRM-ben minősített lead visszatöltése offline konverzióként jóval pontosabb jelzés, mint a puszta űrlapküldés.
- A telefonos érdeklődést kezeld külön eseményként, ne olvaszd össze az űrlappal, mert máshogy viselkedik.
Saját tapasztalat: ahol az űrlapküldésről átálltunk minősített leadre mint elsődleges célra, ott a konverziószám látszólag leesett, viszont a licit végre a valóban értékes érdeklődőkre tanult. Ez nem garantál jobb eredményt minden fiókban, de a jelzés minősége jó eséllyel javul.
Miért hazudik az alapértelmezett érték a bevételi riportban?
Rövid válasz: mert ha minden konverzióhoz fix értéket rendelsz, akkor a ROAS nem bevételt mér, hanem a konverziószámot szorozza egy kitalált számmal.
Ez a hiba különösen alattomos, mert a riport szép: van bevétel oszlop, van megtérülési mutató, minden zöld. Közben a mérőkódban ott van egy value: 1, vagy egy egyszer beállított átlagos kosárérték, amit két éve senki nem nézett meg.
Amit érdemes átnézni:
- Dinamikus-e az érték, vagy fix? Webshopnál a tényleges rendelési összegnek kell átmennie.
- Nettó vagy bruttó? Válassz egy szabályt, és tartsd mindenhol. Vegyesen a legrosszabb.
- Benne van-e a szállítási díj? Ha a hirdetési oldalon igen, a könyvelésben nem, az eltérés állandó lesz.
- Kuponnal csökkentett végösszeg megy át, vagy a listaár?
- Pénznem mezője ki van töltve? Hiányzó pénznemnél a rendszer a fiók alapértelmezettjét feltételezi, ami több devizás webshopnál komoly torzítás.
- Lead esetén: van-e mögötte számolás (átlagos ügyletérték és záródási arány szorzata), vagy csak egy tetszőleges szám?
Lead-alapú üzletben teljesen legitim becsült értéket használni, csak legyen dokumentálva, honnan jön, és legyen felülvizsgálva legalább negyedévente. A becsült érték nem hazugság, a felülvizsgálatlan becsült érték viszont az.
Milyen csendes hibák maradnak még a rendszerben?
Rövid válasz: a szűretlen saját forgalom, az összekevert attribúciós ablakok és a hiányzó visszacsatolás. Ezek nem törik el a mérést, csak folyamatosan félrehúzzák.
Ötödik hiba: saját és gépi forgalom a számban
A fejlesztői környezet ugyanazzal a mérőazonosítóval fut, mint az éles oldal. A tesztrendelések bent maradnak. Az elérhetőségfigyelő percenként lehívja a köszönőoldalt. Az irodai IP-ről naponta végigkattintjátok a folyamatot. Kisebb forgalmú oldalnál ez akár kétszámjegyű százalékos torzítás. Megoldás: külön mérőazonosító a tesztkörnyezetnek, belső forgalom szűrése IP alapján, és ha teszteltek, azt tegyétek egy külön paraméterrel, amit ki tudtok szűrni.
Hatodik hiba: eltérő attribúciós ablakok és időzónák
Hivatalos információ: a hirdetési rendszerek jellemzően a kattintás napjára könyvelik a konverziót, míg az analitika arra a napra, amikor a konverzió megtörtént. Ez önmagában napi szintű eltérést okoz akkor is, ha minden hibátlan. Ehhez jön az eltérő ablak (kattintás utáni és megtekintés utáni időszak), és az, ha a két fiókban nem ugyanaz az időzóna van beállítva. Ez nem javítandó hiba, hanem tudnivaló: ne hasonlítsd össze őket úgy, mintha ugyanazt mérnék, és mindig ugyanabból a rendszerből riportolj egy adott mutatót.
Hetedik hiba: nincs visszacsatolás a valóságból
A mérés a rendelés leadásáig tart, de az élet nem. Lemondott rendelés, visszaküldött termék, sosem fizetett utánvét, spam lead, rossz számot megadó érdeklődő: mind ott marad a konverziók között. Ha van rá mód, küldj vissza sztornó eseményt (webshopnál refund), lead esetén pedig töltsd vissza a CRM-ből a valós státuszt offline konverzióként. Enélkül a legjobban mért kampányod lehet éppen az, amelyik a legtöbb minőségtelen érdeklődőt hozza.
Hogyan ellenőrzöd végig a konverziómérést lépésről lépésre?
Rövid válasz: egy valós eszközön végigjátszott folyamattal és egy fix ellenőrzőlistával, negyedévente megismételve. Ez körülbelül egy óra, és több pénzt ment meg, mint egy kampányoptimalizálás.
- Mérési terv. Írd össze egy táblázatban: esemény neve, mit jelent üzletileg, hol sül el, milyen paraméterek mennek vele, elsődleges vagy másodlagos.
- Végigjátszás. Valós telefonon és asztali gépen is menj végig a teljes folyamaton, hibakeresési módban. Ne a fejlesztő mutassa meg, csináld te.
- Duplikáció-teszt. A köszönőoldalon nyomj frissítést, lépj vissza, majd előre. Nézd meg, hányszor sült el a vásárlás esemény.
- Consent-teszt. Játszd le mindhárom esetet (elfogad, elutasít, nem válaszol), és nézd meg, mi megy ki.
- Érték-ellenőrzés. Vess össze egy lezárt hónapot a webshop vagy CRM saját riportjával. Darabszám és összeg is.
- Szűrők. Belső IP, tesztkörnyezet, ismert botok kizárva.
- Dokumentálás és újranézés. Minden nagyobb weboldal-módosítás, sablonváltás vagy bővítményfrissítés után ellenőrizd újra. A mérés jellemzően ilyenkor romlik el, csendben.
Gyors ellenőrzőlista, amit havonta végig lehet futni:
- A konverziószám és a valós rendelésszám eltérése belül van a megszokott sávon?
- Van olyan tranzakcióazonosító, ami többször szerepel?
- Minden elsődleges konverzió tényleg üzleti esemény?
- A bevétel oszlop dinamikus értékből jön?
- Van-e pénznem minden tranzakciós eseményen?
- A süticsík döntése előtt tényleg nem sül el mérőcímke?
- Van visszacsatolás a sztornókról vagy a rossz leadekről?
A jó konverziómérés nem attól jó, hogy sok mindent mér, hanem attól, hogy kevés dolgot mér megbízhatóan, és ezt te is végig tudod követni. Ha a számra rá mered bízni a költési döntést, akkor kész van. Ha magyarázni kell, miért nem stimmel, akkor még nem.
Források és további olvasnivalók
- Google Analytics Súgó: konverziók és kulcsesemények beállítása
- Google Ads Súgó: konverziókövetés és attribúciós modellek
- Google Tag Manager dokumentáció (Google Developers)
- Google Consent Mode dokumentáció (Google Developers, Tag Platform)
- Meta Business Help Center: Conversions API és eseménydeduplikáció
- Európai Adatvédelmi Testület (EDPB) iránymutatásai a sütikről és a hozzájárulásról
- Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói
- Schema.org: Order és Product típusok
- W3C: Web Analytics és adatvédelmi ajánlások
- A duplikált konverziót szinte mindig egyedi azonosító (transaction_id, event_id) hiánya engedi át, nem a mérőrendszer.
- Hozzájárulás nélkül a mérés jogilag és számszakilag is hibás lesz: alapból tiltás, majd a felhasználó döntése után frissítés a helyes sorrend.
- Ha mindent konverziónak jelölsz, az automata licit is a legolcsóbb, legértéktelenebb eseményre fog optimalizálni.
- Fix, alapértelmezett érték mellett a ROAS nem bevételt mér, hanem a konverziószámot szorozza egy kitalált számmal.
- A rendszerek közti eltérés önmagában nem hiba, de csak akkor értelmezhető, ha ismered az attribúciós ablakot és az időzónát mindkét oldalon.
Gyakori kérdések
Honnan tudom, hogy duplikált-e a konverziómérésem?
Hasonlítsd össze egy lezárt hónap konverziószámát a webshopod vagy CRM-ed saját rendelésszámával. Ha az analitikában érdemben több van, keresd meg, van-e olyan tranzakcióazonosító, amelyik többször szerepel. Ha van, akkor két úton is beérkezik ugyanaz az esemény, és nincs deduplikáció.
Miért csökkent a konverziószám, amikor kitettem a süticsíkot?
Mert a hozzájárulást megtagadó látogatók adatai már nem kerülnek be a mérésbe. Ez nem hiba, hanem a helyes működés következménye. A veszteség egy része mérsékelhető a Consent Mode helyes beállításával és szerveroldali méréssel, de a mérés így is konzervatívabb lesz, mint korábban.
Mennyi eltérés fogadható el a hirdetési fiók és az analitika között?
Nincs hivatalos küszöb, mert a két rendszer eleve máshogy attribuál és máshogy dátumoz. Gyakorlati tapasztalat, hogy a stabil, jól beállított méréseknél a különbség jellemzően egy megszokott sávon belül mozog. A lényeg nem a nulla eltérés, hanem az, hogy tudd megmagyarázni az okát, és mindig ugyanabból a rendszerből riportolj.
Hány konverziós célt érdemes elsődlegesnek jelölni?
Kampánycélonként egyet, azt, amelyik ténylegesen pénzt hoz. A mikrokonverziók (telefonszám-kattintás, letöltés, hosszú oldalon töltött idő) hasznosak megfigyelésre és másodlagos jelzésként, de ha az automata licit is rájuk tanul, jó eséllyel a legolcsóbb, legkevésbé értékes eseményre optimalizál.
Lead-alapú vállalkozásnál mi legyen a konverzió értéke?
Ne fix egyes, hanem becsült érték: az átlagos ügyletérték és a leadből ügyféllé válás arányának szorzata, lehetőleg forrásonként vagy szolgáltatásonként külön. A becslést dokumentáld, és nézd felül legalább negyedévente. Ha van rá mód, a CRM-ből visszatöltött, minősített lead ennél is pontosabb jelzést ad.
Mikor érdemes újra ellenőrizni a mérést?
Minden olyan esetben, amikor a weboldal változik: sablonfrissítés, új űrlap, webshop bővítmény frissítése, süticsík csere, domainváltás vagy átirányítások módosítása. Emellett érdemes negyedévente akkor is végigmenni az ellenőrzőlistán, ha látszólag semmi nem történt.
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.