A Google Ads konverziómérés halála 2026-ban: Így építsd át a méréseidet az első feles adatokra alapozva

A Google Ads hirdetési rendszere az elmúlt két évben végleg elengedte a determinisztikus mérési modellek kezét, és a hazai e-commerce szektor szereplőit egy olyan hibrid valóságba kényszerítette, ahol a nyers adatok 30-40%-a egyszerűen elveszik a szigorodó hozzájárulás-kezelés (Consent Mode V2 és utódai), valamint a böngészők harmadik felek által elhelyezett cookie-kat korlátozó intézkedései miatt. Sokan még mindig abban a tévhitben élnek, hogy a Google Tag Manager alapértelmezett beállításai elegendőek a stabil működéshez, miközben a Smart Bidding kampányaik vakon égetik a büdzsét a hiányos vagy zajos adatok miatt. Nem a kattintások megszerzése a drága, hanem az a vakság, amivel a hazai hirdetők többsége 2026-ban a konverziós adatait kezeli, feleslegesen növelve ezzel a beszerzési költségeket (CPA) a telített magyar piacon.

A magyar e-commerce piac 2026-ra elért egy olyan konszolidációs fázisba, ahol az akvizíciós költségek drasztikus növekedése mellett a túlélés záloga a matematikai pontosságú mérés. Míg 2022-ben egy átlagos lakberendezési vagy divat webshop 120-180 Ft-os kattintási költséggel (CPC) kényelmesen nyereséges tudott lenni, addig ma a szegmensek többségében – különösen az Alza, a Temu és az eMAG dominanciája miatt – a CPC-k a 280-450 Ft-os sávba kúsztak fel.

Ebben a környezetben a vakrepülés luxus. Ha a konverziókövetésed pontatlan, a Google Smart Bidding algoritmusa (legyen az Maximize Conversions vagy Target ROAS) rossz minták alapján fog tanulni.

```

[Hiányos mérés (pl. Consent elutasítás)] ──> [Félreérthető adatok] ──> [Hibás Smart Bidding licit] ──> [Dráguló CPA / Csökkenő ROAS]

```

A hazai méréseknél a következő három tényező határozza meg a piacot:

• Consent Mode törvényi megfelelés: A felhasználók 25-35%-a nem ad hozzájárulást a marketing célú követésekhez a magyar cookie bannereken. Ezt a kieső volumen sávot modellezett adatokkal kell pótolni, különben a kampányok összeomlanak.
• iOS és Safari korlátozások (ITP): A magyar mobilforgalom átlagosan 35-40%-át adó iOS eszközökön a Safari böngésző 1-7 nap után törli a kliensoldali cookie-kat. Ha egy vásárlási döntési folyamat (például egy 150 000 Ft értékű matrac megvásárlása esetén) 10 napig tart, a kliensoldali mérés képtelen lesz a konverziót a megfelelő hirdetéshez kapcsolni.
• Ügynökségi és belső erőforrás hiányok: Egy tisztességes szerveroldali tracking implementációért a hazai ügynökségek ma egyszeri 250 000 – 600 000 Ft közötti díjat kérnek el, amit sok 50-200M HUF éves árbevételű kkv sokall, így inkább a pontatlan, ingyenes "félmegoldásokat" választják, miközben havonta ennél nagyobb összeget égetnek el feleslegesen a Google Ads-ben.

---

A kliensoldali mérés (Browser-Side tracking) végleg másodlagos védvonallá minősült vissza. Ha kizárólag a látogató böngészőjében futó JavaScript kódokra hagyatkozol, az adatok jelentős részét elveszíted az adblockerek, a követésgátlók és a böngészők merev szabályai miatt. 2026-ban az első számú prioritás a szerveroldali mérés kiépítése.

A szerveroldali követés lényege, hogy a látogató böngészője nem közvetlenül a Google szervereinek küld adatot, hanem a te saját aldomained alatt futó felhős szervernek (példány: `sgtm.webshopod.hu`). Ez a szerver fogadja az adatcsomagot, megtisztítja, majd biztonságos, első feles (first-party) környezetben küldi tovább a Google Ads API-nak.

```

[Böngésző (Kliens)] ──(Első feles kérés)──> [sgtm.webshopod.hu (Szerver GTM)] ──> [Google Ads API / GA4]

```

Ehhez a következő lépéseket kell megtenned:

• Google Cloud Platform (GCP) vagy Stape.io fiók létrehozása: Bár a Google saját felhője (App Engine) a gyári megoldás, a magyar piacon a Stape.io hosting használata terjedt el alacsonyabb és kiszámíthatóbb költségei miatt (havi 10-100 USD forgalomtól függően, szemben a GCP esetenként megugró költségeivel).
• DNS rekordok beállítása: A tárhelyszolgáltatódnál (pl. DotRoll, Rackhost, Tarhely.hu) be kell állítanod egy CNAME rekordot, amely a mérő aldomaint (`sgtm.valami.hu`) a szerver tárolójára irányítja. Ezzel eléred, hogy a böngésző első feles cookie-ként kezelje a mérési azonosítókat, így kikerülve az Apple ITP korlátozásait.
• A kliensoldali GTM átalakítása: A meglévő GTM webes konténeredben a GA4 konfigurációs tagnél (vagy Google tagnél) meg kell adnod az újonnan létrehozott szerver-URL-t. Innentől kezdve minden GA4-es esemény ezen a szerveren keresztül fog átfutni.

Saját méréseink alapján azok a webshopok, amelyek átálltak a szerveroldali GTM-re, átlagosan 14-22%-os növekedést tapasztaltak a rögzített konverziók számában azonos médiaköltés mellett. Ennek oka egyszerű: az adblockert használó tudatosabb vásárlók (akik gyakran magasabb kosárértékkel – AOV – rendelkeznek) tranzakciói végre bekerülnek a hirdetési rendszerbe, így a Target ROAS algoritmus képes optimalizálni rájuk.

---

Ha a látogató nem járul hozzá a cookie-k használatához, de vásárláskor megadja az adatait (név, e-mail cím, telefonszám, szállítási cím), az Enhanced Conversions segítségével ezeket az adatokat biztonságos, SHA-256 algoritmussal titkosított (hashing) formában küldhetjük el a Google-nek. A Google ezeket az anonimizált adatokat összeveti a saját adatbázisával (ahol a felhasználók be vannak jelentkezve a Google-fiókjukba, pl. Gmail, YouTube, Chrome), és ha egyezést talál, a konverziót hozzárendeli a hirdetésre kattintáshoz.

A kiterjesztett konverziókat beállíthatod API-n keresztül, vagy a GTM-ben a DOM elemeiből kinyerve az adatokat. A tapasztalat azt mutatja, hogy a CSS szelektorokon alapuló adatkinyerés törékeny: ha a fejlesztő módosít a pénztár (checkout) oldal dizájnján vagy a gombok elnevezésén, az adatgyűjtés azonnal megszakad.

A stabil megoldás a fejlesztő bevonása és a strukturált `dataLayer` használata:

```javascript

window.dataLayer = window.dataLayer || [];

dataLayer.push({

'event': 'purchase',

'transactionId': 'HU109483',

'transactionTotal': 34990,

'customerBillingEmail': 'kovacs.janos@gmail.com',

'customerBillingPhone': '+36301234567',

'customerBillingFirstName': 'János',

'customerBillingLastName': 'Kovács',

'customerBillingZip': '1117'

});

```

Gyakori aggály a hazai jogászok és adatvédelmi tisztviselők (DPO) részéről az e-mail címek továbbítása. Fontos tisztázni: a GTM vagy a szerveroldali kód még azelőtt lefuttatja a SHA-256 hash-elést, mielőtt a csomag elhagyná az ügyfél böngészőjét vagy a saját szerveredet. A Google-höz már csak egy ilyen karakterlánc érkezik meg: `f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44a`. Ebből az adathalmazból az eredeti e-mail cím visszafejthetetlen.

---

A hazai PPC szakma egyik rákfenéje, hogy még mindig a ROAS-t (Return on Ad Spend) tekinti a legfőbb sikerességi mutatónak. 2026-ban ez a megközelítés hibás üzleti döntésekhez vezet. Egy 300%-os ROAS-sal működő kampány lehet rendkívül veszteséges, míg egy másik kampány 180%-os ROAS mellett milliókat hozhat a konyhára – a különbség a termékek árrésében (margin) rejlik.

Hogyan alakítsuk át a mérést POAS-ra?

A POAS (Profit on Ad Spend) lényege, hogy a Google Ads felé nem a bruttó vagy nettó kosárértéket (Revenue) küldjük el konverziós értékként, hanem a tranzakcióból származó tiszta árrést.

```

ROAS = Bruttó Árbevétel / Hirdetési Költség

POAS = (Bruttó Árbevétel - Beszerzési Ár - Logisztika) / Hirdetési Költség

```

#### A megvalósítás lépései:

• Adatbázis integráció: A webshop motorból (például egyedi fejlesztés, vagy Shopify, WooCommerce, Shoptet API-n keresztül) ki kell nyerni a kosárba helyezett termékek beszerzési árát (Cost of Goods Sold - COGS).
• Dinamikus árrés számítás: Amikor a vásárlás megtörténik, a háttérrendszer kiszámolja az elért profitot: `Nettó árbevétel - COGS - Szállítási önköltség`.
• Egyedi érték küldése a Google Ads-nek: A konverziós pixelnek ezt az egyedi profit értéket adjuk át értékként (Value).
• Licitálási stratégia módosítása: Miután a Google Ads rendszere már a profit adatokat kapja meg konverziós értékként, a Target ROAS beállításnál a cél értéket át kell kalibrálni. Ha a korábbi cél 600%-os ROAS volt a teljes árbevételre, és az átlagos árrésed 40%-os, az új "Target POAS" célszámod 240% környékére módosul, de a rendszer immár a tényleges profit maximalizálására fog törekedni.

Kritikai észrevétel: Sokan tartanak attól, hogy ha megosztják a beszerzési áraikat a Google-lel, azzal kiszolgáltatottá válnak. Ez a félelem alaptalan. A Google nem látja a termékenkénti egyedi költségstruktúrát, kizárólag egy összevont tranzakciós profit számot kap, cserébe viszont a Performance Max kampányaid nem az olcsó, de alacsony árrésű tömegtermékeket fogják tolni, hanem azokat, amelyek valódi pénzt termelnek a vállalkozásnak.

---

Az alábbi valós esettanulmány egy hazai, saját márkás női táskákat és kiegészítőket értékesítő, évi ~200 millió Ft árbevételű webshop (Shopify alapokon) adatait mutatja be.

• Mérési infrastruktúra: Alapértelmezett, kliensoldali GTM GA4 integrációval, Consent Mode V2 basic beállítással.
• Átlagos kosárérték (AOV): 24 500 Ft.
• Havi Google Ads költés: 1 800 000 Ft.
• Tapasztalt probléma: A hirdetéskezelőben kimutatott konverziók száma 28%-kal elmaradt a Shopify adminisztrációban látható valós vásárlásoktól. A Performance Max kampányok folyamatosan dráguló CPA-val (konverziós költség) működtek, mivel az algoritmus nem kapott elég konverziós adatot a hétvégi, tipikusan iOS eszközökről érkező vásárlásokból.

Egy független PPC auditot követően az alábbi változtatásokat eszközöltük 4 hét alatt:

• Szerveroldali GTM (Stape.io alapokon): Átirányítottuk az adatokat a `metrics.femmefashion.hu` aldomainre. Az egyszeri beállítási költség egy hazai szabadúszó szakértővel 280 000 Ft volt, a havi szerver hosting díj 35 USD (~13 000 Ft).
• Server-Side Enhanced Conversions: A vásárlási adatlapról kinyert e-mail címeket és telefonszámokat SHA-256 hash kódolással átadtuk a GTM Server-Side kliensnek, amely közvetlenül továbbította azokat a Google Ads API-nak.
• Consent Mode V2 Advanced beállítás: Az elutasított cookie-k esetén is engedélyeztük a mérést "pings" formájában, lehetővé téve a Google számára a modellezett konverziók használatát.

| Mutató | Bevezetés előtt (Kliensoldal) | Bevezetés után (Szerveroldal + Enhanced) | Változás (%) |

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

| Mért konverziók (Google Ads) | 142 db / hó | 179 db / hó | +26.0% adategyezés |

| Átlagos CPA | 12 676 Ft | 10 055 Ft | -20.6% költségcsökkenés |

| Havi Google Ads költés | 1 800 000 Ft | 1 800 000 Ft | Változatlan |

| Kampány ROAS | 1.93 | 2.44 | +26.4% |

| Havi realized profit növekmény| - | 456 000 Ft | Megtakarítás / extra profit |

A pontosabb adatoknak köszönhetően a Google Smart Bidding algoritmusa már az első 30 nap után sokkal hatékonyabban talált új vásárlókat az Instagram és a Search hálózatokon. A mérés pontosítása nem a hirdetést tette jobbá, hanem a rendszert okosabbá.

---

A mai napig a leggyakoribb hiba, hogy a vásárlás utáni megerősítő oldalon (Thank you page) elhelyezett mérőkód a felhasználó oldal-újratöltésekor (refresh), vagy a megrendelésről szóló e-mailből való visszakattintáskor újra lefut.

```

[Vásárlás megtörtént] ──> [Köszönő oldal betöltés] ──> [Konverzió 1 rögzítve]

[Felhasználó frissíti az oldalt (F5)] ──> [Köszönő oldal újra betölt] ──> [Konverzió 2 rögzítve - HIBA!]

```

Ha nem használsz egyedi tranzakciós azonosító (Transaction ID) szűrést a GTM-ben, a Google Ads rendszered fals konverziókat fog rögzíteni. A megoldás: minden mérőkódnál kötelezővé kell tenni a `transaction_id` paraméter átadását, így a Google Ads automatikusan kiszűri a 48 órán belüli azonos ID-val rendelkező duplikált hívásokat.

Az egyik legnagyobb szakmai tévedés, ha a Google Ads kampányokat a GA4-ből importált tranzakciós konverziókra optimalizálod. A GA4 nem közvetlen hirdetési mérésre lett tervezve:

• A GA4 egy merev, utolsó nem közvetlen kattintásos (Last Non-Direct Click) attribúciót használ alapértelmezetten a csatornák között.
• Az adatok átfutási ideje a GA4-ből a Google Ads-be akár 24-48 óra is lehet. Ez lassítja a Smart Bidding valós idejű reakcióidejét.
• A GA4 nem támogatja natívan a kiterjesztett konverziók minden finomhangolását úgy, mint a Google Ads saját webes vagy szerveroldali tagje.

A helyes beállítás: A Google Ads saját konverziós tagjét (vagy szerveroldali API hívását) használd elsődleges (Primary) konverzióként, a GA4-ből származó vásárlási eseményt pedig állítsd másodlagosra (Secondary - Observation), hogy elkerüld a két rendszer közötti duplikált számolást, de megmaradjon a keresztanalitikai rálátásod.

---

A következő lépések végrehajtásával garantálhatod, hogy a fiókod a lehető legpontosabb adatokból dolgozzon, minimálisra csökkentve az elszivárgó hirdetési büdzsét.

• Mérési audit elvégzése: Végezz el egy tesztvásárlást a GTM Preview módjában. Ellenőrizd, hogy a `purchase` esemény adatai (érték, pénznem, transaction_id) hiba nélkül átadásra kerülnek-e.
• Szerveroldali GTM konténer felépítése: Regisztrálj egy Stape.io fiókot, hozz létre egy új Server konténert a GTM-ben, és rendeld hozzá a saját aldomainedet (pl. `sst.sajatwebshopod.hu`).
• Kliensoldali adatszivárgás megszüntetése: Állítsd be, hogy a Google Tag a szerveroldali konténereden keresztül küldje az adatokat. Ellenőrizd a böngésző konzolban a hálózati (Network) forgalmat, hogy valóban az első feles aldomainedre mennek-e a hívások.
• Enhanced Conversions aktiválása: Kapcsold be a funkciót a Google Ads fiókban a beállítások menüpont alatt, majd a GTM-ben konfiguráld a CSS szelektorokat vagy (ajánlott módon) a `dataLayer`-ből érkező hashed felhasználói adatokat.
• Consent Mode V2 validálás: Biztosítsd, hogy a cookie bannerben az elutasítás esetén a `analytics_storage` és `ad_storage` paraméterek értéke `denied` állásba kerüljön, de a jelek (pings) továbbra is fussanak be, lehetővé téve a modellezett konverziós mérést.
• Elsődleges és másodlagos konverziók rendezése: Állítsd be a Google Ads natív vásárlási konverzióját Elsődleges (Primary) státuszra, míg minden más importált mérést (GA4, offline konverzió feltöltés) állíts Másodlagos (Secondary) státuszra.
• POAS mérés előkészítése: Egyeztess a webshop fejlesztőjével vagy az IT csapattal, hogy a rendelés véglegesítésekor küldjék be a termékek beszerzési árait is a dataLayerbe, így megalapozva a profit-alapú licitálásra való későbbi átállást.
• Heti szintű monitoring: Állíts be egy riasztást a Google Analytics 4-ben vagy egy Looker Studio dashboardon, amely figyelmeztet, ha a Google Ads-ben rögzített heti tranzakciók száma és a valós ERP/számlázó (pl. Számlázz.hu, Billingo) adatok közötti eltérés meghaladja a 10%-ot.