- A szerveroldali mérés adatminőségi eszköz, nem adatvédelmi megkerülés: hozzájárulás nélkül továbbra sem mérhetsz.
- Havi néhány ezer látogatónál és néhány tucat konverziónál a nyereség jellemzően elvész a mérési zajban.
- A szerveroldali konténer futó infrastruktúra: saját aldomain, felügyelet, frissítés és hibakeresés tartozik hozzá.
- Egy elrontott vagy leálló konténer nem egy tag-et ront el, hanem az egész mérést leállítja.
- A bevezetés előtt érdemes a böngészőoldali mérést hibátlanra hozni, mert a legtöbb adathiány onnan ered.
A szerveroldali Google Tag Manager az elmúlt években a magyar piacon is divatszóvá vált. Ügynökségi ajánlatokban, konferencia-előadásokban és LinkedIn-posztokban gyakran úgy jelenik meg, mint általános válasz a mérési problémákra: hirdetésblokkolókra, romló attribúcióra, gyengülő Meta- és Google-visszajelzésre. A valóság ennél szűkebb és pontosabb. A technológia valóban megold néhány konkrét problémát, néhány másikat pedig egyáltalán nem, viszont cserébe egy folyamatosan üzemelő rendszert hoz a cégedbe, aminek gazdája kell.
Ez a cikk abban segít, hogy egy 5-50 fős magyar vállalkozás vezetőjeként vagy marketingeseként el tudd dönteni: neked most kell-e ez, vagy jobban jársz, ha a pénzt és a figyelmet máshová teszed.
Mi a különbség a böngészőoldali és a szerveroldali mérés között?
A böngészőoldali mérésnél a látogató gépe küldi az adatot közvetlenül a Google-nek, a Metának vagy más rendszernek. A szerveroldalinál a látogató gépe egyetlen helyre küld adatot, a te saját aldomainedre, és onnan egy általad futtatott konténer osztja tovább a mérőrendszerek felé.
Hivatalosan igazolt: a Google dokumentációja szerint a szerveroldali konténer egy önálló, Google Cloud Run vagy más hosting környezetben futó alkalmazás, amely HTTP-kéréseket fogad, kliensek dolgozzák fel őket, majd tag-ek küldik tovább az eseményeket. A böngészőben ilyenkor is fut kód, csak lényegesen kevesebb: nem tíz külföldi domainre megy kérés, hanem egyre, a sajátodra.
A gyakorlati beállítás egyetlen paraméteren múlik a méréskódban, például így:
gtag('config', 'G-XXXXXXXXXX', { server_container_url: 'https://mm.sajatdomain.hu' });
Innentől a GA4-események a saját aldomainedre futnak be, és a továbbküldés a te felügyeleted alatt történik. Ez adja a technológia minden előnyét és minden kockázatát egyszerre.
Mit old meg valóban a szerveroldali mérés?
Röviden: azt oldja meg, hogy az adat egyáltalán eljusson a mérőrendszerbe, és hogy tovább maradjon azonosítható a visszatérő látogató. Konkrétan:
- Böngészős követésblokkolás. A tartalomblokkolók és a beépített böngészővédelem jelentős része domain-listák alapján dolgozik. Ha a kérés a saját aldomainedre megy, jó eséllyel átmegy, mert nem szerepel az ismert mérő-domainek listáján. Szakmai feltételezés: ez nem végleges állapot, a listakezelők folyamatosan reagálnak, tehát ezt az előnyt nem érdemes örökkévalónak tekinteni.
- Sütiélettartam. Hivatalosan igazolt: az Apple WebKit dokumentációja szerint a Safari intelligens követésmegelőzése a JavaScripttel beállított sütik élettartamát hét napra korlátozza, bizonyos esetekben ennél is rövidebbre. A szerver által HTTP-fejlécben beállított süti ezt a korlátot más elbírálás alá esik. A gyakorlatban ez azt jelenti, hogy a visszatérő látogató hosszabb ideig marad ugyanannak a felhasználónak.
- Adatminőség és kontroll. A szerveroldali konténerben te döntöd el, milyen mező megy tovább és milyen nem. Ki lehet szűrni felesleges paramétereket, meg lehet tisztítani URL-eket, össze lehet fűzni belső rendszerből érkező adatot (például valós rendelési értéket) a beérkező eseménnyel.
- Betöltési sebesség. Kevesebb harmadik féltől érkező szkript fut a böngészőben. Saját tapasztalat: ez leggyakrabban mérhető, de ritkán látványos javulás. Ha az oldalad lassú, annak jellemzően a képek, a téma és a bővítmények az oka, nem a mérőkód.
Saját tapasztalat: jól beállított szerveroldali méréssel a GA4 és a hirdetési platformok által látott konverziószám tipikusan közelebb kerül a valós, háttérrendszerben látható számhoz. A javulás mértéke erősen függ a közönségtől: mobilos, iOS-túlsúlyos, fiatalabb látogatóknál nagyobb, idősebb, asztali gépes, Chrome-os közönségnél kisebb.
Mit nem old meg a szerveroldali mérés?
A legfontosabb mondat az egész témában: a hozzájárulás hiánya továbbra is hiány marad. Ha a látogató a süti-sávon nem engedélyezte a mérést, a szerveroldali konténer sem mérheti. Nem arról van szó, hogy technikailag nem tudná, hanem arról, hogy jogilag nem szabad.
Hivatalosan igazolt: a Google hirdetési és mérési termékei a Consent Mode kereteit használják, ahol az ad_storage, analytics_storage, ad_user_data és ad_personalization jelzések döntik el, mi történhet. Ezek a jelzések a böngészőből indulnak, és a szerveroldali konténerbe is átmennek. Ha a hozzájárulás nemleges, ott is nemleges marad.
Amiben tehát a technológia nem segít:
- a süti-sávon elutasító látogatók mérése,
- rosszul felépített konverziós esemény, hibás e-kereskedelmi adatréteg, hiányzó tranzakciós azonosító,
- a többeszközös vásárlói út teljes összefűzése bejelentkezés nélkül,
- gyenge kreatív, rossz céloldal vagy értelmetlen kampánystruktúra,
- jogi megfelelés: adatkezelési tájékoztató, jogalap, adatfeldolgozói szerződések ugyanúgy kellenek.
Ha valaki úgy ajánlja a szerveroldali mérést, hogy "így a süti-sáv is megkerülhető", az adatvédelmi kockázatot ad el neked megoldásként. Ezt érdemes elutasítani.
Milyen forgalomnál és költésnél éri meg egyáltalán?
Rövid válasz: akkor éri meg, ha a mérési nyereség forintosítható összeggé válik, és van, aki a rendszert üzemelteti. Négy szempontot érdemes együtt nézni, mert külön-külön mindegyik félrevezet.
- Havi látogatószám. Havi tízezer munkamenet alatt a szerveroldali mérésből származó adattöbblet jellemzően elvész a természetes ingadozásban. Nem tudod megkülönböztetni a javulást a heti szezonalitástól. Nagyságrendileg havi 25-30 ezer munkamenet fölött kezd a különbség stabilan látszani.
- Konverziók száma. Ez fontosabb, mint a látogatószám. Havi 50 konverzió alatt a hirdetési algoritmusok amúgy sem tudnak érdemben tanulni, tehát a jobb adatminőség nem alakul jobb kampányteljesítménnyé. Havi 100-200 konverzió fölött viszont már a hirdetési rendszer optimalizálása is meghálálja a pontosabb visszajelzést.
- Hirdetési költés nagyságrendje. A mérési nyereség tipikusan a konverziók néhány százalékát jelenti. Ha a havi költésed olyan nagyságrendű, hogy ennek a néhány százaléknak a forintértéke nem éri el egy komolyabb fejlesztői nap értékét, akkor a beruházás nem térül meg. Ha a hirdetés a fő bevételi csatornád és folyamatosan, jelentős összeggel fut, más a helyzet.
- Fejlesztői kapacitás. Ez a leggyakrabban kihagyott szempont. Kell valaki, aki a konténert frissíti, figyeli, és hiba esetén két órán belül hozzányúl. Ha nincs ilyen ember vagy partner, a többi három szempont már nem is számít.
Saját tapasztalat: a magyar KKV-k jelentős részénél a mérés valódi problémája nem a blokkolás, hanem az, hogy az űrlapküldés kétszer tüzel, a köszönőoldal újratöltéskor is konverziót jelent, vagy a webshop tranzakciós eseménye nem tartalmaz értéket. Ezeket a hibákat a szerveroldali konténer nem javítja meg, csak átviszi a szerverre.
Mivel jár a konténer üzemeltetése a mindennapokban?
A szerveroldali GTM nem beállítás, hanem futó szolgáltatás. Ez a legnagyobb szemléleti különbség a böngészőoldali méréshez képest, ahol a konténer a Google infrastruktúráján fut, és neked semmi dolgod vele.
Amivel számolnod kell:
- Saját aldomain. Kell egy aldomain a fő domainedről, például
mm.sajatdomain.hu, saját SSL-tanúsítvánnyal és DNS-bejegyzéssel. Ha a domainedet más kezeli, ez már az első lépésnél függőséget jelent. - Futtatókörnyezet. Jellemzően Google Cloud Run, de működik más felhő- vagy saját szerveres környezetben is. Számlázási fiók, hozzáférés-kezelés, felhasználói jogosultságok tartoznak hozzá.
- Skálázás. Ha minimum példányszám nélkül futtatod, hideg indításnál késhet a válasz, és események veszhetnek el. Ha folyamatosan futó példányt tartasz, van havi üzemeltetési költséged akkor is, amikor nincs forgalom.
- Frissítés. A konténer képfájlját időnként frissíteni kell. Ez nem heti feladat, de nem is felejthető el évekre.
- Hibakeresés. Az előnézeti mód működik, de a hiba több rétegben lehet: böngésző, DNS, konténer, kimenő tag. Egy egyszerű állapotellenőrzés is sokat segít, például
curl -I https://mm.sajatdomain.hu/healthz, de a valódi vizsgálathoz szerveroldali naplók kellenek. - Felelősség. Ha leáll, nincs kihez fordulni azon kívül, aki beállította. Nincs Google-ügyfélszolgálat, aki visszakapcsolja neked.
Miért lehet kis forgalomnál nagyobb a kockázat, mint a nyereség?
Ez a cikk legfontosabb saját álláspontja: alacsony forgalomnál a szerveroldali mérés jellemzően kockázatot ad hozzá, nem eredményt. Az ok egyszerű aszimmetria. A nyereség fokozatos és apró: néhány százalékkal több mért konverzió. A kockázat viszont bináris és teljes: ha a konténer leáll, rosszul konfigurálódik, lejár a tanúsítvány vagy elfogy a felhőkeret, akkor nem néhány százalék hiányzik, hanem minden adat.
Saját tapasztalat: a leggyakoribb csendes hiba nem a leállás, hanem az, hogy a mérés hetekig részlegesen működik, és senki nem veszi észre. A havi riportban csak annyi látszik, hogy "kicsit gyengébb hónap volt". Kis forgalomnál pontosan ez a helyzet a legveszélyesebb, mert ott a természetes ingadozás elfedi a hibát. Nagy forgalomnál egy 40 százalékos esés azonnal feltűnik.
Ehhez jön a szervezeti kockázat: ha a beállítást végző partnerrel megszakad a kapcsolat, a rendszer gazdátlanul fut tovább. Böngészőoldali GTM-nél ez kellemetlen, szerveroldalinál viszont működő infrastruktúrát hagysz felügyelet nélkül.
Hogyan érdemes bevezetni, ha a döntés mégis igen?
Ha a négy küszöböt átléped, és van üzemeltetői háttered, érdemes fokozatosan haladni:
- Hozd rendbe a böngészőoldali mérést: minden konverzió pontosan egyszer tüzeljen, értékkel és azonosítóval.
- Rögzítsd a kiindulási állapotot: 30 nap GA4-, Google Ads- és Meta-konverziószám, mellette a háttérrendszer valós adata.
- Állítsd be a hozzájárulás-kezelést tisztán, dokumentált jogalappal, és ellenőrizd a jelzések továbbadását.
- Hozd létre az aldomaint és a konténert, minimum példányszámmal, hogy ne legyen hideg indítás.
- Először csak a GA4-adatot vezesd át szerveroldalra, párhuzamos mérés mellett, két-három hétig.
- Hasonlítsd össze a két adatforrást. Ha eltérés van, azt előbb értsd meg, mint hogy továbblépnél.
- Csak ezután kösd rá a hirdetési konverziókat, egyesével, mindig visszaellenőrizve a platform felületén.
- Állíts be riasztást: ha egy nap alatt az események száma egy küszöb alá esik, kapjon valaki értesítést.
Milyen ellenőrzőlistával dönts?
- Van havi 100 fölötti konverzióm, ami ténylegesen üzleti értéket jelent?
- A hirdetési költésem elég nagy ahhoz, hogy néhány százalék pontosabb mérés érzékelhető összeg legyen?
- Van olyan ember vagy partner, aki 24 órán belül hozzányúl a konténerhez hiba esetén?
- A böngészőoldali mérésem már hibátlan, vagy még mindig vannak duplikált eseményeim?
- A hozzájárulás-kezelésem rendben van, és nem azért akarok szerveroldalra menni, hogy megkerüljem?
- Hozzáférek a saját domainem DNS-beállításaihoz?
- Elviselem, ha a mérés egy hétig hibás, vagy ez azonnali üzleti döntéseket borítana?
Ha ezek közül kettőnél többre nem tudsz igent mondani, a szerveroldali mérés még nem a te feladatod. Ez nem lemaradás, hanem sorrend kérdése. Ugyanaz a figyelem és költségkeret a legtöbb magyar KKV-nál nagyobb hozamot ad tiszta konverziómérésre, jobb céloldalra vagy egyetlen működő hirdetési struktúrára fordítva.
Források és további olvasnivalók
- Google Tag Manager Developer Guide, Server-side tagging dokumentáció
- Google Analytics Help, GA4 mérés és adatgyűjtés
- Google Ads Help, Consent Mode és hozzájárulás-kezelés
- Google Cloud Run hivatalos dokumentáció
- WebKit Blog, Intelligent Tracking Prevention bejelentések
- Mozilla Developer Network, HTTP cookies referencia
- Európai Parlament és Tanács (EU) 2016/679 rendelete (GDPR)
- Nemzeti Adatvédelmi és Információszabadság Hatóság tájékoztatói a sütikezelésről
- W3C, Tracking Preference Expression és kapcsolódó adatvédelmi munkacsoport anyagai
Gyakori kérdések
A szerveroldali mérés megkerüli a süti-sávot?
Nem, és nem is szabad így használni. Ha a látogató nem járult hozzá a méréshez, a szerveroldali konténer sem mérheti. A hozzájárulási jelzések a böngészőből átmennek a szerverre, és ott is érvényesek maradnak.
Mennyi forgalom alatt felesleges belevágni?
Nagyságrendileg havi tízezer munkamenet és havi ötven konverzió alatt a nyereség elvész a természetes ingadozásban. Ilyenkor nem tudod megkülönböztetni a mérési javulást a szezonalitástól, viszont a leállás kockázatát már megvetted.
Kell hozzá saját szerver?
Saját fizikai szerver nem, de futtatókörnyezet igen. A leggyakoribb a Google Cloud Run, ehhez kell egy felhőfiók, egy saját aldomain és SSL-tanúsítvány. A konténer folyamatosan fut, tehát üzemeltetési feladat és költség tartozik hozzá akkor is, amikor nincs forgalom.
Mi történik, ha a konténer leáll?
Akkor nem néhány százaléknyi adat hiányzik, hanem gyakorlatilag az összes esemény. A veszélyesebb eset a részleges hiba, amikor hetekig csak az adatok egy része megy át, és a riportban ez csupán gyengébb hónapnak látszik. Ezért érdemes eseményszám-alapú riasztást beállítani.
Javítja a szerveroldali mérés a hirdetési eredményeimet?
Közvetlenül nem, közvetve segítheti. Pontosabb konverziós visszajelzésből a hirdetési algoritmus jobban tanulhat, de ehhez elég konverzió is kell. Havi néhány tucat konverziónál a rendszer amúgy sem tud érdemben optimalizálni, tehát az eredmény nem garantált.
Mit érdemes megcsinálni előtte?
A böngészőoldali mérés rendbetételét: minden konverzió pontosan egyszer tüzeljen, legyen értéke és azonosítója, a köszönőoldal újratöltése ne generáljon új konverziót. A hiányzó adat nagyobb része tapasztalat szerint ilyen alapbeállítási hibákból ered, nem blokkolásból.
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.