Google Ads konverziómérés 2026-ban: A Consent Mode v3 és offline adatszinkronizáció kíméletlen valósága

A Google Ads konverziómérés ma már nem egy technikai pipa a beállítási listán, hanem az algoritmusokat üzemanyaggal ellátó legkritikusabb szoftveres infrastruktúra. Sokan még mindig ott tartanak, hogy a köszönőoldal (thank-you page) betöltődését mérik egy alap Google Tag (gtag.js) kóddal, miközben a böngészők harmadik felektől származó cookie-kat korlátozó szigorításai, az Apple ATT (App Tracking Transparency) keretrendszere és az EU-s adatvédelmi szabályozások (Consent Mode v2) miatt a hagyományos mérések az adatok 35-40%-át egyszerűen elnyelik. Aki nem vált át a szerveroldali mérésre és a fejlett konverziókövetésre (Enhanced Conversions), az lényegében vakon engedi rá a Smart Bidding algoritmusait a magyar piacra, és feleslegesen égeti el a hirdetési büdzsét.

A magyar e-commerce és szolgáltatói szektorban 2026-ra a hirdetési költségek (CPC) drasztikusan megemelkedtek az Alza, az eMAG és az olyan agresszív távol-keleti szereplők piaci nyomása miatt, mint a Temu és a Shein. A divat- és lakberendezési kategóriákban a kattintási költségek a 2023-as 80-120 HUF-os szintről mára tartósan 180-290 HUF közé emelkedtek, miközben az átlagos kosárérték (AOV) a hazai reálbér-stagnáció miatt mindössze 5-8%-kal nőtt.

A megnövekedett CPC mellett a konverziós adatok pontossága jelenti a különbséget a túlélés és a csőd között. Ha a Google Ads algoritmusa (legyen az Performance Max vagy tROAS alapú Search kampány) rossz vagy hiányos adatokból tanul, hibás profilú felhasználókra fogja optimalizálni a liciteket.

A magyar felhasználók kb. 22-28%-a utasítja el a cookie-kat az OTP SimplePay vagy Barion fizetési kapuk átirányításai során fellépő mérési hibák miatt, ami azt jelenti, hogy a hirdetők csaknem harmada nem is látja, honnan érkezett a vásárlás. Ha nem implementáljuk a fejlett mérési protokollokat, a Google algoritmusa azt fogja hinni, hogy a kampányaink teljesítménye romlik, így visszaveszi a liciteket, letekerve a konverziós volument.

---

A mérések megbízhatóságát ma már nem lehet egyetlen kliensoldali JavaScript kóddal garantálni. A robusztus adatgyűjtéshez három technológiát kell kényszerűen összehangolnunk.

A fejlett konverziók lényege, hogy amikor a felhasználó konvertál a weboldalon (például vásárol vagy ajánlatot kér), a rendszer rögzíti az első fél tőle származó adatait (e-mail cím, telefonszám, név, számlázási cím). Ezeket az adatokat a böngésző egy biztonságos, SHA-256 algoritmus segítségével titkosított (hashed) formátumban küldi el a Google szervereinek.

• Hogyan javít ez a mérésen? Ha a felhasználó korábban be volt jelentkezve a Google-fiókjába egy másik eszközön (pl. mobilon munkába menet), de a vásárlást az asztali számítógépén fejezi be, ahol nem engedélyezte a cookie-kat, a Google az e-mail cím egyezősége alapján össze tudja kötni a kattintást a konverzióval.
• Magyar piaci tapasztalat: Az Enhanced Conversions aktiválása a hazai lead-generáló B2B weboldalaknál átlagosan 12-14%-os, míg a webáruházaknál 8-10%-os regisztrált konversiónövekedést (conversion lift) eredményez anélkül, hogy a tényleges eladások száma változott volna – egyszerűen a Google pontosabban tudja attribúlni a korábban "láthatatlan" vásárlásokat.

Az Európai Unió Digital Markets Act (DMA) szabályozása miatt a Google kötelezővé tette a Consent Mode v2 használatát. Ha ez nincs helyesen beállítva, a Google Ads nem képes remarketing listákat építeni, és a tROAS/tCPA algoritmusok hatékonysága is meredeken zuhan.

| Consent Mode Típus | Adatküldés hozzájárulás előtt | Google modellezési képesség | Jogi kockázat (GDPR) |

| :--- | :--- | :--- | :--- |

| Basic (Alapértelmezett) | Semmilyen adatot/pif-et nem küld a tag | Közepes (csak historikus adatokból becsül) | Alacsony / Teljesen biztonságos |

| Advanced (Haladó) | Anonimizált pingeget küld (cookie-k nélkül) | Magas (valós idejű viselkedési modellezés) | Közepes (a NAIH állásfoglalásai alapján vitatott) |

Szakmai véleményem szerint a magyar piacon üzemelő kkv-knak érdemes a Basic Consent Mode mellett maradniuk, ha el akarják kerülni a Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) esetleges bírságait. Bár az Advanced mód papíron több adatot modellez (a kieső adatok akár 65%-át is képes visszanyerni a Google AI segítségével), a hazai jogértelmezés szigorú: hozzájárulás nélkül semmilyen hálózati kérés nem indulhat el az amerikai szerverek felé, még az IP-cím és a User Agent továbbítása is aggályos lehet cookie-mentes pingek formájában.

A kliensoldali (böngészőben futó) Google Tag Manager (sGTM helyett cGTM) kiszolgáltatott az adblockereknek (pl. AdGuard, uBlock Origin, Brave böngésző integrált védelme). Magyarországon az internetezők mintegy 28-34%-a használ valamilyen hirdetésblokkolót – a tech, IT, gaming és B2B szektorokban ez az arány az 50%-ot is eléri.

A szerveroldali mérés során a böngésző nem közvetlenül a Google-nek küldi az adatokat, hanem a saját domainünk alatt futó köztigazdának (pl. `g計測.domainunk.hu` – egy sGTM konténernek, amely például Google Cloud Platformon fut). Ez a szerver tisztítja meg az adatokat (eltávolítja az IP-címeket, felesleges paramétereket), majd backend-to-backend kapcsolaton keresztül küldi tovább a Google Ads API-nak. Mivel a kérések első feles (first-party) domainről indulnak, az adblockerek nem tudják azokat kiszűrni.

---

Ügyfelünk egy prémium kerti bútorokat és kiegészítőket értékesítő magyar nyelvű webáruház (éves árbevétele 320 millió HUF, átlagos kosárértéke 112 000 HUF). Havonta átlagosan 2,5-3 millió HUF-ot költöttek Google Ads performance kampányokra (főként Performance Max és Search).

A marketing vezető azzal a problémával keresett meg minket, hogy a Google Ads fiókban jelentett ROAS (megtérülés) 480%-on állt, miközben a Shoptet alapú webshop belső adminisztrációjában és az OTP SimplePay fiókban a tényleges bevételek csökkenést mutattak. A Google Ads számai és a valóság között havonta több mint 30%-os eltérés volt.

A diagnózis: Miért torzított a mérés?

A technikai audit során három kritikus hibát azonosítottunk:

• Fizetési átirányítási hurok (Referral Exclusion hiba): Amikor a vevő kiválasztotta az OTP SimplePay fizetési módot, a rendszer átirányította a SimplePay külső oldalára. Sikeres fizetés után a bank visszaküldte a felhasználót a webáruház "köszönjük" oldalára. Mivel a SimplePay domain (`sandbox.simplepay.hu` vagy `secure.simplepay.hu`) nem volt kizárva a Google Analytics 4-ben és a Google Ads-ben referralként, a rendszer az eladást nem a Google Ads kampánynak tulajdonította, hanem a SimplePay-nek mint organikus hivatkozásnak.
• Dupla konverziómérés: A köszönőoldalt a felhasználók gyakran frissítették (F5), vagy később könyvjelzőből nyitották meg újra, hogy ellenőrizzék a rendelésük állapotát. Minden egyes oldalbetöltődés újabb tranzakciónak minősült a Google Ads felé, azonos tranzakciós ID-val.
• A visszamondott és sikertelen rendelések bennmaradása: A megrendelések 12%-a fizetési hiba miatt meghiúsult, vagy a vevő 14 napon belül elállt a vásárlástól. Ezek az adatok soha nem íródtak jóvá negatív előjellel a Google Ads-ben, így az algoritmus folyamatosan túloptimalizált a nem fizető, értéktelen felhasználókra.

Egy 4 hetes projekt keretében teljesen átalakítottuk a mérési infrastruktúrát:

```

[Felhasználó böngészője]

│ (Esemény: purchase - First-party cookie-k & Hashed User Data)

▼

[Server-side GTM Container (Cloud Run / Stape.io)]

│

├─► [Google Ads API - Enhanced Conversions] (Attribúció pontosítás)

├─► [GA4 Measurement Protocol] (Tiszta analitika)

└─► [Offline Conversion Cloud Function] (Tranzakció validálás 48 óra után)

```

• Tranzakciós ID alapú deduplikáció: Bevezettük a dinamikus `transaction_id` paramétert a Google Ads konverziós tagben. Ha ugyanazt az azonosítót másodszor küldte el a böngésző, a Google Ads automatikusan elvetette a duplikált konverziót.
• Server-Side GTM és Google Ads API összekötése: Áttértünk a Stape.io európai szerverén hosztolt sGTM-re (havi üzemeltetési díj: kb. 35 EUR, azaz ~14 000 HUF). Ezzel párhuzamosan beállítottuk az Enhanced Conversions-t API-n keresztül.
• Offline konverzió importálás (Profit-alapú optimalizálás): Ahelyett, hogy a böngészőből azonnal jelentettük volna a vásárlás értékét, bevezettünk egy 48 órás késleltetést. A webshop ERP rendszeréből (Billingo és Shoptet API-k segítségével) egy Google Sheet-be exportáltuk a ténylegesen teljesült, kifizetett és átvett megrendeléseket, levonva a beszerzési árat és a szállítási költséget. Ezt a táblázatot naponta egyszer automatikusan importáltuk a Google Ads-be SFTP-n keresztül. Így a Google Ads már nem az "Árbevételre", hanem a tényleges "Bruttó Profitra" optimalizált.

A változtatások bevezetése utáni harmadik hónap végére a következő eredményeket értük el:

• A mérési hiba minimálisra csökkent: A Google Ads és a könyvelési adatok közötti eltérés 30%-ról 2,4%-ra esett vissza.
• A CPA (konverziós költség) tisztulása: A névleges CPA-nk elsőre "emelkedett" a Google Ads felületén (mivel kiszűrtük a fiktív, duplikált és sikertelen vásárlásokat), de a valós, realizált profitunk növekedésnek indult.
• ROAS javulás: Az algoritmus az offline profit adatok alapján megtanulta elkerülni azokat az ügyfeleket, akik rendszeresen visszaküldték a termékeket. A tényleges, bankszámlán realizált ROAS 310%-ról 440%-ra emelkedett.
• Költségmegtakarítás: Megmentettünk évi mintegy 6,4 millió HUF olyan hirdetési büdzsét, amit korábban olyan kulcsszavakra és PMax célzásokra költött el a Google, amelyek csak papíron hoztak konverziót, a valóságban veszteségesek voltak.

---

Magyarországon a digitális ügynökségek és szabadúszók jelentős része még mindig elköveti az alábbi alapvető hibákat, amelyekkel hosszú távon szabotálják a rájuk bízott hirdetési büdzsét.

Súlyos hiba a Google Analytics 4-ből importált `purchase` eseményt beállítani elsődleges (Primary) konverziós célként a Google Ads-ben a natív Google Ads Conversion Tracking pixel helyett.

• Miért probléma ez? A GA4 és a Google Ads teljesen eltérő attribúciós modelleket használ. A GA4 alapértelmezetten a "Cross-channel data-driven" modellt használja, és ha a felhasználó utoljára egy hírlevélből kattintva vásárolt, a GA4 a hírlevélnek fogja adni a konverzió jelentős részét. Ezzel szemben a natív Google Ads tag akkor is rögzíti a konverziót saját magának (Google-attribúció szerint), ha a Google Ads kattintás a konverziós ablakon belül történt (pl. 30 nap), függetlenül a későbbi csatornáktól.
• A következmény: Ha GA4 konverziókat használsz, a Google Ads kevesebb konverziót fog látni, így az intelligens licitáló algoritmusok (Smart Bidding) nem kapnak elég adatot, alullicitálnak, és a kampányaid teljesítménye hanyatlani fog. Elveszíted továbbá a megtekintésen alapuló (view-through) konverziók mérésének lehetőségét is, ami különösen a YouTube és Display kampányoknál elengedhetetlen.

Gyakran látni olyan webáruházakat, ahol a konverzió rögzül, de fix értékként 1 HUF vagy egy statikus, becsült átlagérték van megadva.

• Szakmai kritika: Ha nem adsz át dinamikus értéket és pénznemet (HUF, EUR stb.), lehetetlenné teszed a Target ROAS (célzott hirdetési kiadások megtérülése) stratégia használatát. Az algoritmus számára egy 2000 HUF értékű zokni vásárlása pontosan ugyanolyan súlyú lesz, mint egy 150 000 HUF értékű prémium bőrkabáté. A Google így a kis értékű, de könnyen konvertáló felhasználókat fogja vadászni, miközben a prémium vásárlókat átengedi a konkurenciának.

Sokan még mindig a GTM-ben vagy közvetlenül a Google Ads-ben úgy állítják be a konverziót, hogy "Page URL contains /koszonjuk".

• Veszélyek: Mi van, ha a webshop motor frissül, és az új URL a `/rendeles-sikeres` lesz? A konverziómérés azonnal leáll, és mire a marketinges észreveszi (gyakran hetekkel később, amikor már leesett az árbevétel), az algoritmusok teljesen elfelejtették a korábbi célközönség-mintákat. Ráadásul a fizetési kapuk hibája miatt sok felhasználó kétszer vagy háromszor is megnyitja ezt az oldalt az e-mailben kapott linken keresztül, ami torzítani fogja az adatokat. Mindig használj egyedi eseményeket (custom event) és adatréteget (datalayer.push)!

---

Ha szeretnéd, hogy a mérési rendszered hibátlanul szolgálja ki a Google Ads hirdetéseidet, hajtsd végre az alábbi biztonsági és technikai lépéseket.

• Datalayer kiépítése a fejlesztővel vagy pluginnel: Kérd meg a fejlesztőt (vagy konfiguráld a Shoptet/Shoprenter/WooCommerce bővítményedet), hogy küldjön szabványos e-commerce `purchase` adatréteget (datalayer) minden tranzakciókor. Kötelező elemek: `transaction_id` (egyedi azonosító), `value` (nettó vagy bruttó érték, de legyél konzisztens), `currency` (pl. HUF), és a kosár tartalma (`items` tömb).
• Hozd létre a natív Google Ads Konverziós Célokat: A Google Ads-ben az Eszközök és beállítások -> Konverziók menüpont alatt hozz létre egy új konverziós műveletet (Webhely típusút). Állítsd be az érték kategóriánál, hogy: "Minden konverzióhoz különböző érték használata", és az alapértelmezett pénznem legyen HUF.
• Kapcsold be az Enhanced Conversions-t a Google Ads felületén: A konverzió részletes beállításainál pipáld ki a "Fejlett konverziók bekapcsolása" opciót, válaszd ki a "Google Tag vagy Google Tag Manager" lehetőséget, és fogadd el az adatvédelmi feltételeket.
• Konfiguráld a felhasználói adatok gyűjtését GTM-ben: A Google Tag-ben vagy a Google Ads Conversion Tracking tag-ben engedélyezd az "Include user-provided data from your website" opciót. Hozz létre egy új User-Provided Data változót, amely a CSS szelektorok vagy Datalayer változók segítségével kinyeri a vásárló e-mail címét (pl. `customer.email`), telefonszámát és számlázási adatait. Ügyelj rá, hogy a GTM automatikusan elvégzi a SHA-256 titkosítást a továbbítás előtt.
• Állítsd be a tranzakció deduplikációt: A Google Ads Conversion Tag GTM felületén a Transaction ID mezőbe helyezd be a datalayerből kinyert egyedi tranzakciós azonosító változóját (pl. `{{dl_purchase_transaction_id}}`). Ezzel garantálod, hogy egy vásárlás csak egyszer íródik jóvá.
• Zárd ki a fizetési átjárókat a GA4-ben: Lépj be a GA4 Adminisztráció -> Adatfolyamok -> Webes adatfolyam -> Címkebeállítások konfigurálása -> Nem kívánt hivatkozások listázása részre. Add hozzá a magyar piacon releváns fizetési szolgáltatók domainjeit: `pay.simplepay.hu`, `secure.barion.com`, `paypal.com`, `tpay.com`, `payu.hu`.
• Állíts be riasztásokat a Google Analytics 4-ben és a Google Ads-ben: Hozz létre egy heti automatikus e-mail riasztást, ami jelzi, ha a konverziók száma az előző hét azonos időszakához képest több mint 25%-ot esett. Ez segít azonnal észlelni, ha egy webshop motor vagy sablon frissítés tönkretette a mérőkódokat, mielőtt a kiesés komolyabb anyagi kárt okozna a kampányokban.