A szerver oldali tracking 2026-ban: nem a cookie-kat kell megmenteni, hanem a marketing döntéseket

A szerver oldali tracking (server-side tracking) néhány éve még technikai újdonságnak tűnt. Olyasvalaminek, amiről főleg analitikai specialisták, fejlesztők és PPC-szakemberek beszélgettek, miközben a cégvezetés udvariasan bólogatott, majd visszatért a fontosabbnak tűnő kérdésekhez: mennyi a lead, mennyi az árbevétel, mennyi a ROAS.

2026-ban viszont a helyzet megváltozott.

Ma már nem az a kérdés, hogy van-e a weboldalon Google Analytics, futnak-e hirdetési pixelek, vagy látunk-e valamilyen konverziós számot a riportban. A valódi kérdés az, hogy az adatok, amelyek alapján üzleti döntéseket hozunk, mennyire megbízhatóak. Mert ha a mérés hibás, akkor a riport is hibás. Ha a riport hibás, akkor a kampányoptimalizálás is hibás. Ha pedig a kampányoptimalizálás hibás, akkor a marketingbüdzsé nem skálázódik, hanem szépen, csendben elég. Nem látványosan. Nem drámaian. Csak pont úgy, ahogy a rossz marketing általában működik: elegáns dashboardok mögött.

Mi változott 2021 óta?

Amikor néhány éve a szerver oldali trackingről beszéltünk, a fő narratíva még a „cookie-k nélküli világ” (cookie apokalipszis) volt. A piac arra készült, hogy a harmadik féltől származó cookie-k teljesen eltűnnek, és emiatt új mérési megoldásokra lesz szükség.

Ez részben igaz lett, részben nem. A Google Chrome végül nem vezette ki teljesen a 3rd party cookie-kat abban a formában, ahogy azt éveken át vártuk. A Privacy Sandbox körüli stratégia többször változott, és a teljes tiltás helyett a hangsúly inkább a felhasználói választáson (user-choice modell), a böngészőszintű adatvédelmi beállításokon és az alternatív mérési megoldásokon maradt.

De ettől még a probléma nem tűnt el. Sőt.

A Safari (ITP) és a Firefox (ETP) továbbra is agresszívan korlátozza a követést. Az adblockerek használata tovább nőtt, és ma már a felhasználók jelentős hányadát érinti. Az EU-ban a kötelező Consent Mode v2 és a szigorúbb adatvédelmi működés miatt jelentős mennyiségű mérési adat esik ki vagy válik modellezetté. Az iparágtól és a hozzájárulási arányoktól (consent rate) függően ez a hiányzó adat mérési környezetenként eltérő, de tipikusan nem elhanyagolható nagyságrend. Közben a felhasználók egyre tudatosabban döntenek arról, hogy mit engednek mérni és mit nem. 

Az adatok elvesztése ma már nem elméleti kérdés: a globális adblock-penetráció 12.33%, Nyugat-Európában 9.46%, Közép- és Kelet-Európában 23.24%, miközben egyes 2026-os összefoglalók szerint a világ internethasználóinak 42.7%-a használ adblockert legalább egy eszközön. Emellett a GDPR-kompatibilis cookie bannereknél az EU-s látogatók 60–70%-a is elutasíthatja a sütiket, így a browser-side mérés egyre nagyobb arányban kerül modellezésre vagy marad hiányos.

Ezért 2026-ban a pontosabb állítás nem az, hogy „megszűntek a cookie-k”. Hanem az, hogy: a böngészőkből érkező marketingadatok egyre hiányosabbak, töredezettebbek és kevésbé megbízhatóak. És ez már nem technikai probléma, hanem kőkemény üzleti probléma.

A cookie-k nem eltűntek, hanem megbízhatatlanná váltak

A klasszikus kliens oldali mérés arra épült, hogy a felhasználó böngészőjében futó tagek, pixelek és JavaScriptek összegyűjtik az adatokat, majd továbbítják azokat a hirdetési és analitikai rendszereknek. Ez sokáig kényelmes modell volt. A hirdető elhelyezte a Google Analytics kódot, a Google Ads konverziós taget, a Meta pixelt, esetleg néhány remarketing- és heatmap-eszközt, majd úgy tett, mintha a riportban megjelenő számok a valóságot mutatnák.

A gond csak az, hogy ma már egyre gyakrabban nem azt mutatják.

A böngészők, az adatvédelmi beállítások, az adblockerek és a hozzájáruláskezelő rendszerek miatt a kliensoldali mérés egyre több ponton sérülhet. B2B leadgenerálásban ez különösen fájdalmas. Egy webshopnál legalább sokszor elérhetőek a közvetlen vásárlási adatok, a kosárérték, a tranzakciók és az ismételt vásárlások. Egy B2B cégnél viszont a valódi üzleti érték gyakran csak később derül ki: amikor a leadből MQL, SQL, ajánlat, majd szerződés lesz.

Ha ezt a láncot nem tudjuk pontosan visszakötni a marketingforrásokhoz, akkor a kampányoptimalizálás legjobb esetben is félvak. Rosszabb esetben teljesen félremegy.

Mi az a szerveroldali tracking?

A szerver oldali mérés lényege, hogy a mérési adatok nem kizárólag a felhasználó böngészőjéből, kliens oldali scripteken keresztül jutnak el az analitikai és hirdetési rendszerekbe. A mérési folyamatba bekerül egy saját vagy kontrollált szerveroldali réteg (egyfajta „biztonsági kapuőr”), amelyen keresztül az adatokat tisztítani, strukturálni, dúsítani, szabályozni és továbbítani lehet a megfelelő rendszerek felé.

Egyszerűbben: nem minden adatot közvetlenül a böngészőből küldünk szanaszét a különböző platformoknak, hanem egy kontrollált, központi mérési rétegen keresztül kezeljük őket. Ez lehet Google Tag Manager server-side környezet, Stape, Google Cloud, AWS, saját szerveres megoldás, vagy egyre gyakrabban edge-alapú infrastruktúra.

A lényeg nem maga az eszköz. A lényeg az, hogy a vállalat visszaveszi az irányítást a tech óriásoktól, és teljes kontrollt kap afelett, hogy milyen adatot gyűjt, hogyan strukturálja, mit küld tovább a Google, Meta, TikTok, LinkedIn vagy más rendszerek felé, és mit tart meg saját üzleti döntési célra.

A szerver oldali mérés nem varázspálca

Fontos tisztázni: a szerver oldali tracking nem azt jelenti, hogy hirtelen mindent mérhetünk, amit korábban nem.

• Nem adatvédelmi kiskapu.
• Nem „okosban megoldjuk a consentet” technológia.
• Nem arra való, hogy a felhasználói döntéseket megkerüljük.

Aki így adja el, attól érdemes óvatosan hátralépni. Lehetőleg gyorsan. És ha lehet, ne hagyjunk nála hozzáférést semmihez. A szerver oldali tracking valódi értéke nem a szabályok megkerülése, hanem a mérés minőségének, kontrolljának és üzleti használhatóságának javítása. Egy jól felépített szerver oldali mérési rendszer csökkenti a mérés sérülékenységét, támogatja az Enhanced Conversions és Conversion API megoldásokat, segíti az offline konverziók visszakötését, és jobb adatminőséget biztosít az algoritmikus kampányoptimalizáláshoz.

Ez már nem analitikai finomhangolás, hanem alapvető marketinginfrastruktúra.

A 2026-os kompromisszum: megérkezett a Google Tag Gateway (GTG)

A teljes szerver oldali GTM (sGTM) bevezetése komoly döntés, ami infrastruktúra-költségekkel jár. De mi van akkor, ha egy cég nem akar havi szinten cloud szervereket fizetni, viszont azonnal orvosolni szeretné az ITP (Safari/Apple korlátozások) és az adblockerek okozta adatvesztést?

Erre az igényre válaszul lépett be a piacra a Google hibrid adatgyűjtési infrastruktúrája: a Google Tag Gateway (GTG).

A GTG áthidalja a hagyományos kliensoldali címkézés és a komplex szerveroldali architektúrák közötti szakadékot. Lényegében egy menedzselt „reverse proxy”, amely a vállalat saját domainje (pl. metrics.cegnev.hu) alatt fut.

Hogyan működik a GTG?

1. Első feles (first-party) kérés: a látogató böngészője nem a Google szervereit hívja meg, hanem a te saját aldomainedet.
2. Proxying és transzformáció: a GTG fogadja a kérést, elrejti a kliens IP-címét, módosítja a HTTP fejléceket, majd biztonságosan továbbítja az adatot a Google végpontjaira.
3. Cookie-túlélés: mivel a mérés hitelesített, első féltől származó kontextusban történik, a Safari ITP és a Chrome szigorításai nem vágják le drasztikusan a cookie-k élettartamát. Az attribúció és a remarketing újra pontosabb lesz.

Melyiket válasszuk? Kliens vs. GTG vs. szerveroldali GTM

Funkció / tulajdonság	Kliensoldali (hagyományos)	Google Tag Gateway (GTG)	Szerveroldali GTM (sGTM)
Infrastruktúra-igény	Nincs (böngészőben fut)	Egyszerű (CDN / DNS szint)	Komplex (GCP / AWS / Cloud Run)
Üzemeltetési költség	$0	Ingyenes vagy minimális (CDN-forgalom)	Nagyságrendileg havi cloud-költség
Adatvédelmi ellenállás	Gyenge (könnyen blokkolható)	Kiváló (first-party HTTP/DNS kontextus)	Kiváló (teljesen rejtett)
Adatmanipuláció (PII-tisztítás)	Korlátozott	Nincs (black-box működés)	Teljes körű (saját kontroll)
Harmadik fél támogatása	Minden platform	Csak Google (GA4, Ads, Floodlight)	Bármely platform (Meta CAPI, TikTok stb.)
Core Web Vitals (SEO) hatás	Terheli a böngészőt (lassú)	Kismértékben javítja	Maximálisan javítja (gyors)

Architekturális javaslatunk:

• Válaszd a GTG-t, ha: a marketingbüdzséd túlnyomó része Google Ads-be megy, nincs külön fejlesztői kereted havi felhőköltségekre, és a célod a konverzióvesztés gyors, ROI-maximalizáló mérséklése.
• Válts teljes szerveroldali GTM-re (sGTM), ha: kritikus a Meta CAPI vagy más, nem Google API-k szerveroldali támogatása; ha GDPR okokból tisztítanod/anonimizálnod kell az adatokat (PII), mielőtt azok a Google-höz kerülnének; vagy ha a webes adatokhoz CRM/offline konverziókat akarsz valós időben hozzákapcsolni.

A jövő nem a tökéletes mérésről szól, hanem a jobb becslésről

Mindenki tudja fejből a mondatot: „majd az analitikában megnézzük”. Mögötte ott a csendes meggyőződés, hogy az analitika mindent lát, mindent mér, és a riportban szereplő szám a teljes igazság. Ez a meggyőződés ma már téves. A böngészők, a consent és az adblockerek miatt a riport nem a valóságot tükrözi, hanem annak egy hiányos, helyenként már csak modellezett részét. 

A modern marketingmérés egyre inkább valószínűségi (probabilistic), modellezett rendszer. A Google hivatalos dokumentációja is azt hangsúlyozza, hogy a Consent Mode és a behavioral modeling lényege éppen az, hogy a hiányzó vagy elutasított hozzájárulás miatt elvesző jeleket modellezett adatokkal pótolja. A Google, a Meta és más hirdetési platformok tehát egyre több esetben nem közvetlenül megfigyelt konverziókból dolgoznak, hanem részben modellezett adatokból.

Ez nem feltétlenül baj. Sőt, bizonyos környezetben ez az egyetlen működőképes irány. A kérdés az, hogy milyen minőségű inputot adunk ezeknek a modelleknek. Ha rossz, hiányos vagy torz adatot kapnak, rossz következtetéseket vonnak le. Ha viszont jobb minőségű, strukturált, first-party alapú adatot kapnak a szerverünkről (legyen az GTG vagy sGTM), akkor sokkal jobb döntéseket tudnak támogatni.

Az AI-alapú hirdetési rendszerek nem gondolatolvasók. A „smart bidding” sem mágikus kis manókból áll, akik éjszaka optimalizálják a céged profitabilitását, miközben te alszol. 

Az algoritmus abból tanul, amit megetetünk vele.

Ezért a jövő marketingmérése nem arról szól, hogy minden felhasználói mozdulatot 100%-ban mérjünk. Hanem arról, hogy a rendelkezésre álló adatokból a lehető legjobb, legüzletibb döntéstámogató rendszert építsük fel.

First-party adatstratégia: itt dől el a verseny

A szerver oldali tracking önmagában kevés. Akkor lesz igazán értékes, ha egy átgondolt first-party adatstratégiába illeszkedik. Egy komoly first-party adatstratégia magában foglalja:

• a CRM és a marketingrendszerek mély összekötését,
• a leadek minőségi státuszainak visszamérését,
• az offline konverziók importálását,
• a titkosított (hashed) email és más privacy-safe azonosítók kezelését,
• az ügyfélérték (LTV) vagy pipeline value visszakötését.

B2B-ben ez különösen kritikus. Egy leadgeneráló kampány papíron sikeres lehet attól, hogy olcsó a CPL. Csak ha a leadek fele irreleváns diákmunka után érdeklődő, akkor üzletileg nem vagyunk sokkal előrébb. Maximum van egy szép riportunk. És egy sales csapatunk, amelyik csendben gyűlöl minket.

A first-party adatstratégia célja pont az, hogy ne csak azt mérjük, mi történt a weboldalon, hanem azt is, hogy abból mi lett az üzletben. Ez az a pont, ahol a adat- és webanalitika már nem riportkészítés, hanem üzleti döntéstámogatás.

Identity resolution: nem eszközöket kell követni, hanem üzleti kapcsolatokat kell érteni

A cookie-megbízhatatlan világ egyik kulcskérdése az identity resolution. Ez arról szól, hogyan tudjuk a különböző érintkezési pontokat értelmezhető módon összekapcsolni úgy, hogy közben adatvédelmileg is korrekt rendszerben dolgozzunk.

Nem az a cél, hogy mindenkit mindenáron üldözzünk az interneten (ezt hívják rossz remarketingnek). A cél az, hogy a vállalat jobban megértse a saját ügyfélútjait: melyik kampány hozza azokat a leadeket, amelyekből valódi ajánlat lesz? Melyik tartalom indítja el az érdeklődést, és hol veszítünk el értékes embereket? Ehhez nem elég egy pixel. Ehhez mérési architektúra kell.

SEO és szerver oldali tracking: indirekt, de bivalyerős hatás

A Google nem azért fog jobb organikus helyezést adni egy oldalnak, mert szerver oldali technológiát használ. A SEO-hatás indirekt. Ha a weboldal frontendjéről eltávolítunk sok felesleges harmadik feles scriptet (tagging consolidation), drasztikusan csökkentjük a JavaScript-terhelést. Gyorsítjuk az oldalt, javítjuk az interakciós élményt, ezzel pedig javulnak a Core Web Vitals (CWV) mutatók. 2026-ban a SEO-teljesítmény szempontjából már kritikus metrika az INP (Interaction to Next Paint), valamint az LCP (Largest Contentful Paint).

A gyorsabb, stabilabb weboldal pedig SEO-szempontból is erősebb alap. A szerver oldali tracking tehát nem SEO-trükk, hanem mérési infrastruktúra, amelynek van komoly SEO-hozadéka.

GEO: hogyan kapcsolódik a mérés az AI-keresések világához?

A Generative Engine Optimization (GEO) a ChatGPT Search, a Google AI Overviews és a Perplexity világára optimalizál. Fontos: a nagy nyelvi modellek (LLM-ek) nem férnek hozzá közvetlenül a céged first-party tracking adataihoz. A szerver oldali mérés nem közvetlen GEO-rangsorolási faktor.

Érdemes leszögezni, hogy a Google Search Central hivatalos anyagai szerint az AI-alapú keresési felületekben való megjelenéshez továbbra is a klasszikus SEO-alapok kellenek: crawlolhatóság, strukturáltság, relevancia és minőségi tartalom. Vagyis a GEO nem egy külön világ, hanem a SEO kiterjesztése — entitás-alapú, strukturált, citálható tartalom.

A szerver oldali mérés ebben indirekt szereplő. Ha jobb a mérés, jobb a döntés. Ha jobb a döntés, jobb a tartalom- és csatornaallokáció. A server-side tracking így az AI-korszak marketing döntéseinek egyik legfontosabb adatminőségi inputja: nem rangsorol helyetted, de segít abban, hogy oda tedd az erőforrást, ahonnan valóban értékes érdeklődő jön.

Mit érdemes 2026-ban bevezetni?

Egy valóban használható mérési rendszer több elemből áll:

1. Consent Mode v2 korrekt beállítása: nem pusztán technikai checkbox, hanem az adathiányt pótló modellezés kritikus alapja.
2. GTG vagy szerveroldali GTM réteg: az üzleti céloknak és büdzsének megfelelő (Google-only vagy hibrid) biztonsági kapuőr kiválasztása.
3. Google Ads Enhanced Conversions: kötelező trend, amely titkosított first-party adatokkal segíti a licitstratégiák tanulását.
4. Meta CAPI, TikTok API, LinkedIn integrációk (ha sGTM-et használsz): a mérési architektúrának vendorfüggetlenül kell gondolkodnia.
5. Offline konverziók és CRM-integráció: az üzleti érték a CRM-ben dől el, kritikus, hogy a marketingrendszerek visszakapják ezeket a jeleket.

Ezeknek a rétegeknek a gyakorlati, lépésről lépésre történő felépítését — GTM server-side, GA4 routing, Looker Studio riportálás — külön, részletes útmutatóban írtuk meg: adatvezérelt mérési rendszer építése 2026-ban. Ott a teljes technikai checklist és a leggyakoribb buktatók is megtalálhatók.

Mikor indokolt a bevezetés?

A szerver oldali mérés bevezetése nem mindenkinek, nem azonnal és nem önmagáért indokolt. Akkor van üzleti alapja, ha az alábbiak közül legalább egy igaz rád:

• jelentős az EU-s forgalmad, ahol a consent-vesztés közvetlenül rontja a riportálást,
• üzletileg kritikus a konverziós pontosság (drága lead, hosszú sales-ciklus, magas kosárérték),
• több platformot integrálsz (Google Ads, Meta, CRM, email automation),
• gyenge a consent rate-ed, és sok jel elveszik,
• vagy a weboldalad túl sok böngészőoldali scriptet futtat, ami a sebességet is viszi.

Ha ezek közül egyik sem áll fenn, akkor a szerver oldali mérés könnyen drága technikai projektté válik valódi megtérülés nélkül. Ha viszont egy is igaz, akkor jó eséllyel nem költség, hanem befektetés.

A legnagyobb hiba: technológiai projektként kezelni

Sok projekt ott csúszik el, hogy kizárólag informatikai feladatként kezelik. Kell egy server-side GTM. Kell egy fejlesztő. Kész.

Ez így kevés. A jó mérési rendszer nem azzal indul, hogy milyen taget hova teszünk, hanem üzleti kérdésekkel: mit tekintünk valódi üzleti konverziónak? Milyen adatot tudunk visszakapni a CRM-ből? Milyen riport alapján hoz döntést a menedzsment?

A leggyakoribb technikai buktatók — és hogyan kerüld el őket

A szerver oldali mérés ott szokott elcsúszni, ahol a csapat túl korán „késznek” tekinti a rendszert. A jó hír, hogy a tipikus hibák nagy része egy fegyelmezett előkészítéssel és QA-folyamattal megelőzhető.

Buktató	Mi a gond	Hogyan előzd meg	Miért fontos
Dupla eseményküldés	Ugyanaz a konverzió browser-side és server-side is lefut, ezért felülmért adat lesz.	Használj event ID / transaction ID alapú deduplikációt, és szabályozd, melyik csatorna küldheti tovább az eseményt.	A konverziós riport és a ROAS torzulhat.
Hibás consent logika	A CMP, a Consent Mode v2 és a GTM nem ugyanazt a consent státuszt kezeli.	Dokumentált consent flow, tesztelt paraméterek és egységes consent mapping kell.	EU-s mérésnél ez a pontos adat alapja.
Rossz endpoint vagy DNS	A server container aldomainje, HTTPS-e vagy routingja hibás.	Először stagingben ellenőrizd a DNS-t, az SSL-t, a válaszidőt és az endpoint elérhetőségét.	Teljes adatvesztést vagy instabil mérést okozhat.
Túl sok párhuzamos tracking	Hardcoded tagek, pluginek és GTM-es megoldások egyszerre futnak.	Takarítsd ki a redundáns tageket, és legyen egy központi mérési logika.	Nélküle a debug és a hibakeresés szinte lehetetlen.
Nincs üzleti célhoz kötve	A projekt technikai marad, de nem lesz világos a megtérülése.	Határozd meg előre, mit akarsz javítani: attribúció, bidding input, adatminőség, compliance.	Csak így lehet valódi üzleti döntést hozni róla.
Hibás szerveroldali deduplikáció	A rendszer nem különbözteti meg, hogy egy esemény már el lett küldve.	Használj szigorú dedupe logikát a server containerben és a downstream platformokban.	Kétszeres konverzió, hamis teljesítmény.
Nem megfelelő QA	Élesítés előtt nincs elég tesztelés, így rejtett hibák maradnak bent.	Preview, debug, request inspection, majd kontrollált élesítés.	A tracking hibák később drágán javíthatók.
Hiányzó first-party adatstratégia	A rendszer át van helyezve szerverre, de nincs CRM / login / hashed email integráció.	Kapcsold össze a server-side mérést a first-party adatgyűjtéssel és aktiválással.	Ettől lesz valóban erős az adatkontroll.

Összegzés: nem adatból van kevés, hanem jó adatból

2026-ban a digitális marketing kihívása nem az, hogy ne lenne elég adat. A gond az, hogy az adatok egy része hiányos, torz, rosszul strukturált, vagy olyan dashboardokban él, amelyeket mindenki nézeget, de senki nem használ valódi döntésre.

A szerver oldali tracking, a GTG, a Consent Mode v2 és a first-party adatstratégia együtt adják azt az alapot, amelyre a modern marketing épülhet. A kérdés nem az, hogy kell-e szerver oldali mérés. Hanem az, hogy meddig érdemes még olyan marketingdöntéseket hozni, amelyekről pontosan tudjuk, hogy hiányos adatokra épülnek.

Ez kicsit olyan, mint ködben vezetni GPS nélkül, miközben valaki a hátsó ülésről azt mondja: „szerintem jó lesz balra”. Lehet így is haladni. Csak drága.

---

Szeretnéd látni, mennyire megbízhatóak a saját marketingadataid?

A szerver oldali mérés bevezetésében az iWebMa csapata segít feltérképezni, hol veszít adatot a jelenlegi mérési rendszered, mennyire pontosak a konverziós riportjaid, és hogyan lehet jövőálló (GTG- vagy sGTM-alapú) mérési architektúrát kialakítani. Mi nem csak tageket kötünk be. Olyan mérési rendszert építünk, amelyből a marketing, a sales és a cégvezetés is jobb döntéseket tud hozni.