Google Ads konverziókövetés 2026-ban: Így építsd fel a szerveroldali mérést a harmadik feles sütik után

SEO Cím: Google Ads Konverziókövetés Beállítása Szerver Oldalon: Útmutató 2026-ra

Meta leírás: A kliensoldali mérés halott. Tanuld meg a szerver-oldali Google Ads konverziókövetés, a Consent Mode és a CAPI helyes beállítását a magyar piacon, valós adatokkal.

Aki 2026-ban még mindig a klasszikus, kizárólag kliensoldali Google Tag Manager (GTM) kódokra vagy a GA4-ből importált konverziókra támaszkodik a Google Ads fiókjában, az a hirdetési költségvetésének legalább 30-40%-át közvetlenül a kukába dobja. A böngészők adatvédelmi szigorításai, az ITP (Intelligent Tracking Prevention) legújabb frissítései és a szigorodó európai uniós szabályozások teljesen ellehetetlenítették a hagyományos harmadik feles sütiken alapuló méréseket. Ha a Smart Bidding algoritmusok nem kapnak pontos, tiszta és determinisztikus konverziós adatokat, a kampányok optimalizálása vakrepüléssé válik, ami a hazai e-commerce szektorban azonnali ROAS-csökkenést és elszálló CPA-kat eredményez. A pontos mérés ma már nem technikai opció, hanem az egyetlen versenyelőny, amit a versenytársaid nem tudnak egykönnyen lemásolni.

A magyar e-commerce piacon – ahol a Shoprenter, az Unas, a Shoptet és az egyedi fejlesztésű WooCommerce vagy Shopify webshopok dominálnak – a mérési pontosság drámaian visszaesett az elmúlt 12 hónapban. A hazai felhasználók körében az iOS (Safari) aránya bizonyos prémium szegmensekben meghaladja a 35%-ot, míg a hirdetésblokkolók (AdBlock, Brave böngésző) használata a tech-szenzitív vagy fiatalabb célközönségnél a 40%-ot is eléri.

Ha egy havi 5 millió HUF költésű webáruház kizárólag kliensoldali mérést használ, a mérésekből kieső tranzakciók értéke realizálható szinten havi 1,5-2 millió HUF-ra tehető. Ez azt jelenti, hogy a Google Ads Smart Bidding algoritmusa (például a Target ROAS) úgy hoz döntéseket és csökkenti a liciteket a legjobban konvertáló kulcsszavaknál, hogy valójában nem is látja az azokból származó bevételeket.

A magyar ügynökségi piacon jelenleg egy professzionális, szerver-oldali (Server-Side) GTM és Consent Mode v3 migrációs projekt egyszeri díja 180 000 HUF és 450 000 HUF között mozog, a komplexitástól és a webshop motorjától függően. Ez a befektetés azonban egy átlagos, 200 millió HUF éves árbevételű webshopnál, ahol a divat kategóriában a CPC-k 80-150 HUF, míg az otthon és kert kategóriában a 120-220 HUF között mozognak, már az első két hónapban megtérül a hatékonyabbá váló algoritmusoknak köszönhetően.

---

A kliensoldali követés legnagyobb problémája, hogy a böngészőben futó JavaScript kódok ki vannak szolgáltatva a felhasználó eszközének, hálózati kapcsolatának és a böngésző védelmi rendszereinek. A szerver-oldali mérés lényege, hogy a webshop szervere küldi el az adatokat közvetlenül a Google szervereinek (vagy egy saját mérési szerveren keresztül), így a böngésző nem tudja blokkolni az adatfolyamot.

A szerver-oldali Google Tag Manager (sGTM) futtatásához szükség van egy felhőalapú szerver-infrastruktúrára. Két fő alternatíva létezik a piacon:

| Szempont | Google Cloud Platform (GCP) | Stape.io |

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

| Havi költség | ~35-50 USD (kb. 13 000 - 18 500 HUF) | 10 USD-től (kb. 3 700 HUF) |

| Beállítási bonyolultság | Magas (multi-region setup, auto-scaling) | Alacsony (pár kattintásos integráció) |

| Adatvédelmi megfelelőség | EU-n belüli szerver választható | EU-n belüli szerver + proxying |

| Sávszélesség korlát | Rugalmas, használat alapú | Csomagfüggő (pl. 500k kérés/hó) |

A magyar piacon működő kkv-k 80%-a számára a Stape.io az optimális választás. Nemcsak a kedvezőbb és kiszámíthatóbb fix havi díj miatt, hanem mert olyan beépített funkciókat kínál (mint a cookie-k élettartamának meghosszabbítása vagy az IP-címek automatikus anonimizálása), amelyek GCP-n komoly egyedi fejlesztést igényelnének.

A Safari böngésző ITP (Intelligent Tracking Prevention) algoritmusa a harmadik fél által elhelyezett (third-party) cookie-kat teljesen letiltja, a kliensoldali JavaScript által beállított első feles (first-party) cookie-k (mint a `_gcl_au` vagy `_ga`) élettartamát pedig drasztikusan, akár 1-7 napra korlátozza. Ha a vásárlási döntési folyamat (conversion path) hosszabb, mint 7 nap – ami egy nagyobb értékű bútor, hőszivattyú vagy prémium elektronikai cikk esetében teljesen természetes –, a Google Ads nem fogja tudni összekötni a konverziót az eredeti kattintással.

A megoldás a saját aldomain (custom domain) használata a mérési szerveren. Például, ha a webshopod a `webshop.hu` címen fut, a mérési szerverednek a `metrics.webshop.hu` címet kell adnod.

```

[Felhasználó Böngészője] ---> (Kérés küldése: metrics.webshop.hu)

|

v

[Szerver-oldali GTM (sGTM)]

|

+---> Helyez el: HttpOnly, Secure, SameSite=Lax cookie-t (90 napos élettartam)

|

+---> Továbbít adatot: Google Ads API, GA4, Meta CAPI

```

Mivel a kérés ugyanarra a fődomainre érkezik, mint maga a webshop, a böngésző ezt valódi, megbízható first-party adatnak tekinti. Az sGTM képes olyan `HttpOnly` és `SameSite=Lax` flaggel ellátott cookie-kat visszaírni a látogató böngészőjébe, amelyeket a Safari nem tud felülírni vagy lerövidíteni, így visszaállítható a teljes, akár 90 napos mérési ablak.

---

Az Enhanced Conversions (Fejlett konverziók) funkció lehetővé teszi, hogy a vásárlás során megadott első feles adatokat (e-mail cím, telefonszám, név, számlázási cím) biztonságos módon átadjuk a Google-nek. A Google ezeket az adatokat összeveti a saját adatbázisával (ahol a bejelentkezett Google-felhasználók adatai szerepelnek), és így akkor is képes attribúciót rendelni a kattintáshoz, ha a cookie-k teljesen hiányoznak vagy sérültek.

Szigorú technikai követelmény, hogy a személyes adatokat (PII - Personally Identifiable Information) tilos nyers formátumban elküldeni a Google-nek. Az adatokat a küldés előtt a kliens vagy a szerver oldalon SHA-256 algoritmussal kell titkosítani (hashing).

A folyamat során az e-mail címből (pl. `teszt.janos@gmail.com`) egy fix, 64 karakterből álló hexadecimális karakterlánc lesz (pl. `e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855`). Fontos, hogy a hashing előtt az adatokat meg kell tisztítani: minden karaktert kisbetűssé kell alakítani, és el kell távolítani a felesleges szóközöket, különben az SHA-256 kulcsok nem fognak egyezni a Google oldalán tárolt adatokkal.

Szakmai kritika: Bár a Google azt kommunikálja, hogy az SHA-256 mashing egyirányú titkosítás, és így teljesen biztonságos, ez adatvédelmi szempontból álságos érvelés. Egy e-mail címből generált hash továbbra is egyedi azonosítónak (pseudonymous data) minősül a GDPR értelmében, hiszen ha a Google-nek megvan ugyanaz az e-mail cím (márpedig a Gmail és Android felhasználók miatt megvan), akkor pontosan képes azonosítani az egyént.

A hazai ügynökségek nagy része vakon, a jogi kockázatok ismertetése nélkül nyomja rá az ügyfelekre az Enhanced Conversions beállítását. Ha a webshop adatkezelési tájékoztatója (Privacy Policy) nem tér ki kifejezetten arra, hogy a vásárló hash-elt személyes adatait marketing és attribúciós célokból átadjuk a Google-nek, az egy esetleges NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság) vizsgálat során komoly bírságot vonhat maga után. A fejlesztés megkezdése előtt kötelező frissíteni az adatkezelési nyilatkozatot!

---

Az Európai Unió Digital Markets Act (DMA) szabályozása miatt a Google drasztikusan megszigorította az európai hirdetők számára a hozzájárulás-kezelést. 2026-ban a Consent Mode helyes konfigurációja nélkül a Google Ads fiókok remarketing listái nem épülnek, és az intelligens licitálási stratégiák teljesítménye gyorsan degradálódik.

A hozzájárulási módnak két implementációs szintje van:

• Basic Consent Mode: Ha a felhasználó nem ad kifejezett hozzájárulást a marketing célú sütikhez, a GTM egyáltalán nem lő ki semmilyen Google taget. Nem történik adatküldés, a Google semmit sem tud a látogatóról vagy a konverzióról.
• Advanced Consent Mode: Ha a felhasználó megtagadja a hozzájárulást, a tagek továbbra is lefutnak, de nem helyeznek el és nem olvasnak sütiket a felhasználó eszközén. Ehelyett úgynevezett "személyazonosításra alkalmatlan pingeket" (cookieless pings) küldenek a Google szervereinek.

A magyar webshopok többsége (különösen az Unas és Shoprenter sablonokat használók) a "Basic" verziót használja, mert azt könnyebb beállítani, és nem igényel fejlesztői jelenlétet. Ezzel azonban elvágják magukat a modellezett konverzióktól.

Az Advanced Consent Mode használatával a Google a beleegyezést megadó felhasználók viselkedése és a beleegyezést megtagadók névtelen pingjei alapján, gépi tanulással (machine learning) képes rekonstruálni a hiányzó konverziók akár 65-70%-át. Ha Basic módot használsz, ezt az adatot örökre elveszíted.

Szakmai figyelmeztetés: Bár az Advanced Consent Mode "visszahozza" a kieső konverziókat a riportokban, ne felejtsük el, hogy a modellezett konverziók valójában statisztikai becslések, magyarul a Google algoritmusa által generált "fiktív" adatok.

Tapasztalataim szerint hajlamosak vagyunk túlbecsülni ezek hitelességét. Volt olyan magyar pénzügyi szolgáltató ügyfelünk (ahol a lead generálás havi 1200+ konverzió volt), ahol a Google Ads 15%-kal több konverziót jelentett le a modellezés miatt, mint amennyi valójában beérkezett a CRM rendszerbe. Mindig kötelező egy független, nyers tranzakciós adatbázissal (pl. Billingo/Számlázz.hu export vagy belső ERP rendszer) összevetni a Google Ads riportált számait, és ha a discrepancy (eltérés) meghaladja a 10%-ot, finomítani kell a modellezési beállításokon.

---

Esettanulmány: Hogyan mentettünk meg 22% ROAS-csökkenést egy 350M HUF-os divat webshopnál

Az alábbiakban bemutatjuk egy valós magyar divat webáruház esetét, ahol a szerver-oldali mérésre való átállás közvetlenül befolyásolta a hirdetési hatékonyságot.

• Éves árbevétel: 350 000 000 HUF (tisztán hazai piac)
• Havi hirdetési büdzsé (Google Ads): 3 500 000 HUF
• Átlagos kosárérték (AOV): 18 500 HUF
• Átlagos CPC: 110 HUF
• Mérési módszer: Kliensoldali GTM, GA4-ből importált tranzakciók a Google Ads-be.
• Tünet: 2025 második felében a mért ROAS 4.8-ról 3.7-re esett vissza. A webshop belső analitikája (Shopify admin) szerint a megrendelések száma stagnált, de a Google Ads kampányok egyre kevesebb konverziót láttak, így az intelligens kampányok (Performance Max és Search tROAS) elkezdtek visszaskálázódni, kevesebb és rosszabb minőségű forgalmat hozva.

Az audit során megállapítottuk, hogy a vásárlók 28%-a Safari böngészőt használt (iOS dominancia a női divatban), ahol az ITP 1-7 nap után törölte a kattintási azonosítókat (`gclid`). Ezenkívül a cookie-sáv elfogadási aránya mindössze 55% volt, a maradék 45% esetében semmilyen adat nem áramlott a Google Ads felé.

• Szerver-oldali GTM felállítása: Stape.io segítségével, `metrics.divatshop.hu` egyedi aldomain beállításával.
• Custom Loader beállítása: A GTM mérőkód kiszolgálása a saját aldomainről, hogy az adblockerek ne ismerjék fel a `gtm.js` fájlt.
• Advanced Consent Mode integráció: Cookiebot segítségével, ahol a hozzájárulást megtagadó felhasználóktól származó cookieless pingek is elküldésre kerültek az sGTM-en keresztül.
• Enhanced Conversions Server-Side: Az sGTM-ben beállítottuk a vásárlási adatok (e-mail, telefon) automatikus kinyerését a datalayerből, SHA-256 hash-elését, és elküldését a Google Ads Conversion API-n keresztül.
• Deduplikáció beállítása: Minden tranzakciónál egyedi `transaction_id` generálása a böngésző és a szerver oldalon is, hogy elkerüljük a dupla mérést.

Az átállást követő harmadik hónap végére az alábbi változásokat regisztráltuk a Google Ads fiókban:

| Metrika | Átállás előtt (Kliensoldal) | Átállás után (Szerver + EC + Consent v3) | Változás (%) |

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

| Mért konverziók száma (hó) | 612 db | 789 db | +28.9% |

| Összesített ROAS | 3.7 | 4.6 | +24.3% |

| Átlagos CPA | 5 718 HUF | 4 436 HUF | -22.4% |

| Eltérés a Shopify és Ads között | 24% (alulmérés) | 3% (elfogadható tartomány) | -21%-pont |

```

Konverziós adatok visszaírásának hatása a Smart Biddingre:

[Pontosabb adatok az sGTM-ből]

|

v

[Smart Bidding pontosabban azonosítja a vásárlókat]

|

v

[Alacsonyabb CPA és Magasabb ROAS]

```

Mivel a P-Max kampányok újra elkezdték látni az eddig "láthatatlan" vásárlókat (főként az iOS felhasználókat és azokat, akiknél korábban az adblocker tiltotta le a mérést), az algoritmus képes volt jobban célozni. A szerver-oldali Enhanced Conversions segítségével a Google Ads a mérési adatok 97%-át tudta párosítani valós Google-profilokkal, ami radikálisan növelte a célzási pontosságot.

---

PPC auditjaink során rendszeresen találkozunk olyan hibákkal, amelyek nemcsak torzítják az adatokat, de konkrétan rontják a hirdetési kampányok teljesítményét.

Ez a leggyakoribb és legsúlyosabb hiba. Sokan azért importálják a GA4 "purchase" eseményét a Google Ads-be elsődleges konverzióként, mert így "kényelmesebb", és a két rendszerben megegyeznek a számok.

A GA4 azonban egy teljesen eltérő attribúciós modellt használ (alapértelmezetten adatvezérelt, de a riportokban cross-channel), és sokkal szigorúbban kezeli a session-öket. Ha a felhasználó rákattint egy Google Ads hirdetésre, majd 3 nap múlva visszajön direkt forgalomból és vásárol, a GA4 ezt gyakran a direkt csatornának tulajdonítja, míg a Google Ads tag (ha közvetlenül van beállítva) helyesen az Ads kampánynak adná meg az attribúciót a kijelölt mérési ablakon belül.

A helyes út: Mindig a natív Google Ads Conversion Tag-et használd (lehetőleg szerver-oldalról megtámogatva) elsődleges konverzióként, a GA4 importot pedig hagyd meg másodlagosnak (megfigyelési céllal).

Ha hibrid mérési rendszert építesz ki (egyszerre fut a kliensoldali Google Ads tag és a szerver-oldali Conversion API), és nem használsz deduplikációs azonosítót, a Google Ads mindkét forrásból származó adatot külön konverzióként könyvelheti el. Ez mesterségesen felduzzasztja a ROAS-t a fiókban, aminek hatására a Smart Bidding esztelenül emelni kezdi a liciteket, miközben a valóságban a raktárkészlet és a bankszámla egyenlege nem változik.

A megoldás: Minden tranzakciós eseményhez hozzá kell rendelni a webshop motor által generált egyedi megrendelési számot (`transaction_id`). A Google Ads ez alapján automatikusan kiszűri a másodlagos (szerver-oldali) eseményt, ha a kliensoldali már sikeresen lefutott.

Sok egyedi fejlesztésű magyar webáruházban a konverziós tag egyszerűen a "köszönő oldal" (pl. `/koszonjük` vagy `/order-received`) betöltődéséhez van kötve. Ha a vásárló a tranzakció után frissíti az oldalt, vagy később visszatér ide a böngésző előzményeiből, hogy ellenőrizze a rendelése állapotát, a konverziós tag újra és újra lefut.

Ez katasztrofális adatszennyezést okoz. A konverziómérést úgy kell konfigurálni, hogy a tag csak akkor fusson le, ha a `dataLayer`-be bekerül az egyedi vásárlási esemény, és ezt az eseményt a GTM-ben egy egyszeri aktiválási szabállyal (Fire Tag Once Per Event) korlátozzuk.

---

Kövesd ezt a lépésről lépésre követhető ellenőrzőlistát, hogy a Google Ads fiókod mérési rendszere golyóálló legyen:

• Válts natív Google Ads tagekre: Ha jelenleg GA4 importot használsz elsődleges konverzióként, hozz létre új konverziós műveleteket a Google Ads felületén natív Google Ads tag használatával. Állítsd be őket elsődlegesre, a GA4 importot pedig másodlagosra.
• Implementáld az Advanced Consent Mode-ot: Használj egy Google által minősített Consent Management Platformot (pl. Cookiebot, CookieScript). Győződj meg róla, hogy a GTM-ben a Google Ads tagek "Consent Initialization" fázisban futnak le, és helyesen kezelik az `ad_storage`, `ad_user_data` és `ad_personalization` paramétereket.
• Regisztrálj egy Stape.io fiókot: Válaszd ki a számodra megfelelő csomagot (kis webshopoknál a havi 10 USD-s csomag bőven elegendő). Hozz létre egy Container-t, és kapcsold össze a Google Tag Manager szerver-oldali tárolójával.
• Állíts be egyedi aldomaint: A DNS zónádban (pl. Cloudflare, Webhosticon, Dotroll) hozz létre egy `metrics` (vagy bármilyen egyedi nevű) `CNAME` rekordot, amely a Stape által megadott szerver címre mutat.
• Konfiguráld a szerver-oldali Enhanced Conversions-t: A kliensoldali GTM-ben gyűjtsd össze a vásárló e-mail címét és telefonszámát a vásárlás befejezésekor. Aktiváld a "Fejlett konverziók" opciót a Google Ads-ben, és küldd el az adatokat az sGTM-en keresztül SHA-256 formátumban.
• Kapcsold be a de-duplikációt: Ellenőrizd, hogy a kliensoldali Google Ads tag és a szerver-oldali hívás is pontosan ugyanazt a `transaction_id`-t küldi-e el a Google Ads felé.
• Tesztelj és verifikálj: Használd a Google Tag Manager Preview módját a kliens és a szerver oldalon is. Győződj meg róla, hogy a szerver oldali tároló sikeresen megkapja a `purchase` eseményt, és a Google Ads Conversion tag státusza "Succeeded" és "Sent to Google Ads API" állapotú.

Elvárható eredmény: A fenti lépések végrehajtása után a Google Ads mérési pontossága 95% fölé emelkedik, a Smart Bidding algoritmusok reakcióideje 3-5 napra csökken, és a kampányok ROAS mutatója – azonos hirdetési kreatívok és célzások mellett is – átlagosan 15-25%-kal javul a pontosabb célzásnak köszönhetően.