- A szerver oldali mérés tágabb fogalom, mint a szerveroldali GTM: a webáruház-motor közvetlen hirdetési integrációja vagy az offline konverzióimport is ide tartozik.
- 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, ezért a működést a háttérrendszer számaihoz mérve rendszeresen ellenőrizni kell.
- 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.
Egy vásárlás útja a két esetben így néz ki egymás mellett:
- Böngészőoldalon: a köszönőoldal betölt, a böngésző külön kérést küld a Google Analyticsnek, a Google Adsnek és a Metának. Ha a látogató böngészője bármelyik domaint tiltja, az a rendszer nem kap adatot, a többi igen.
- Szerveroldalon: a köszönőoldal betölt, a böngésző egyetlen kérést küld a saját aldomainedre. A konténer ebből az egy eseményből állítja elő a három rendszernek szóló üzenetet. Ha ez az egy kérés nem ér célba, egyik rendszer sem kap adatot.
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.
Egy gyors fejszámolás segít elhelyezni magad. Szakmai feltételezés: ha a szerveroldali mérés a konverziók nagyjából 5 százalékát hozza vissza, akkor havi 40 mért konverziónál ez 2 darab többletet jelent. Egy ekkora vállalkozásnál a havi konverziószám magától is 30 és 50 között mozog, tehát a 2 darabot sem te, sem a hirdetési rendszer nem veszi észre. Havi 400 konverziónál ugyanez az arány 20 darab, ami már kilóg a szokásos ingadozásból, és a kampányok ajánlattételében is megjelenhet. Az 5 százalék szemléltető szám, a saját arányodat csak a párhuzamos mérés mutatja meg.
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.
Mielőtt elindulsz, érdemes írásban rögzíteni, kinek a nevén van a felhőfiók és a számlázás, ki fér hozzá a DNS-hez, ki kapja a riasztást, és ki helyettesíti őt szabadság alatt. Ha ezekre a kérdésekre ugyanaz az egy külső ember a válasz, akkor a mérésed egy emberen múlik.
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.
Mit jelent a szerver oldali mérés, és ugyanaz-e, mint a szerveroldali Google Tag Manager?
A szerver oldali mérés azt jelenti, hogy a látogatói eseményeket (oldalmegtekintés, űrlapküldés, vásárlás) a látogató böngészője helyett egy szerver továbbítja a mérő- és hirdetési rendszereknek. A szerveroldali Google Tag Manager ennek az egyik megvalósítása, a kettő tehát nem ugyanaz. A szerver oldali mérés a tágabb fogalom, a szerveroldali GTM pedig egy eszköz hozzá.
A gyakorlatban három formájával találkozhatsz:
- Szerveroldali GTM-konténer. Saját aldomainen futó konténer, amely egy helyen fogadja az eseményeket, és onnan osztja szét őket. Ez a legrugalmasabb megoldás, és ennek van a legnagyobb üzemeltetési igénye.
- Közvetlen szerver-szerver integráció. A webáruház-motor vagy a CRM maga küldi el a vásárlást a hirdetési rendszernek. Hivatalosan igazolt: a Meta erre a Conversions API-t adja, a Google Analytics 4 pedig a Measurement Protocolt, amellyel HTTP-kérésben lehet eseményt beküldeni. Sok webáruház-motorhoz létezik ilyen kész bővítmény, konténer nélkül.
- Offline konverzióimport. A lezárt üzletet vagy a kifizetett megrendelést utólag töltöd vissza a hirdetési fiókba. Ajánlatkérésre építő cégeknél ez sokszor többet ér minden másnál, mert a hirdetési rendszer így a tényleges bevételt látja, nem az űrlapküldést.
Saját tapasztalat: egy kisebb webáruháznál jellemzően a második forma adja a legjobb arányt a ráfordítás és az eredmény között. Bekapcsolsz egy bővítményt a motorban, és a vásárlások szerverről is beérkeznek, miközben nincs külön infrastruktúra, amit felügyelni kell. Egy dologra viszont figyelned kell. Ha a böngésző és a szerver is elküldi ugyanazt a vásárlást, a rendszernek tudnia kell, hogy ez egyetlen esemény. Hivatalosan igazolt: a Meta ehhez az esemény nevét és az eseményazonosítót (event_id) használja, tehát mindkét oldalról ugyanazzal az azonosítóval kell küldeni. Ha ez hiányzik, a konverziók megduplázódnak, és a mérésed rosszabb lesz, mint előtte volt.
A hozzájárulás szabálya mindhárom formára ugyanúgy érvényes. Attól, hogy az adatot szerver küldi, a látogató döntése a süti-sávon ugyanúgy köt téged.
Hogyan ellenőrizd, hogy a szerver oldali mérés tényleg működik?
A szerver oldali mérés akkor működik jól, ha a mérőrendszerekben látott konverziószám tartósan közel áll a háttérrendszered valós számához, és ezt rendszeresen össze is veted. Az, hogy "be van kötve", önmagában semmit nem bizonyít. Egy havonta megismételhető ellenőrzés így néz ki:
- Nézd meg a hálózati forgalmat. Nyisd meg az oldalt a böngésző fejlesztői eszközeivel, és a hálózati fülön keresd meg a méréshez tartozó kéréseket. Ha a saját aldomainedre mennek, és 200-as választ kapnak, az első réteg rendben van.
- Futtass le egy próbavásárlást vagy próba-ajánlatkérést. A szerveroldali konténer előnézeti módjában látnod kell a beérkező eseményt és azt is, hogy melyik tag küldte tovább, milyen válasszal.
- Ellenőrizd a fogadó oldalt. A GA4 valós idejű nézetében és a hirdetési platform eseménykezelőjében ugyanannak az eseménynek pontosan egyszer kell megjelennie, értékkel és azonosítóval.
- Teszteld az elutasítást. Töröld a sütiket, utasítsd el a mérést a süti-sávon, és ismételd meg a próbát. Ilyenkor a hozzájárulási jelzésnek nemlegesen kell megérkeznie a szerverre is.
- Vesd össze a háttérrendszerrel. Vedd ki az elmúlt 30 nap rendeléseit vagy ajánlatkéréseit a webáruházból vagy a CRM-ből, és tedd mellé a GA4, a Google Ads és a Meta számát. A bevezetés előtt rögzített kiindulási állapothoz képest az eltérésnek csökkennie kell.
Szakmai feltételezés: teljes egyezést ne várj. A hozzájárulást elutasító látogatók és az eltérő attribúciós szabályok miatt a mérőrendszerek száma jellemzően a valós szám alatt marad. Figyelmeztető jel az, ha a mért konverzió több, mint a valós, mert ez szinte mindig duplikációt jelent, és az is, ha az arány egyik hónapról a másikra hirtelen megváltozik.
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 Analytics Developer Guide, Measurement Protocol (GA4)
- Google Ads Help, Consent Mode és hozzájárulás-kezelés
- Google Cloud Run hivatalos dokumentáció
- Meta for Developers, Conversions API dokumentáció és eseményduplikáció-kezelés
- 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 a javulás egyáltalán nem biztos.
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.
Mit jelent egyszerűen a szerver oldali mérés?
Azt, hogy a látogatói eseményeket a böngésző helyett egy szerver továbbítja a mérő- és hirdetési rendszereknek. Megvalósítható szerveroldali Google Tag Manager konténerrel, a webáruház-motor közvetlen hirdetési integrációjával vagy offline konverzióimporttal. A hozzájárulás szabályai mindegyik formára ugyanúgy érvényesek.
Lehet szerver oldali mérést csinálni Google Tag Manager nélkül?
Igen. A webáruház-motor vagy a CRM közvetlenül is küldhet eseményt a hirdetési rendszernek, például a Meta Conversions API-n vagy a GA4 Measurement Protocolon keresztül. Ilyenkor nincs külön konténer, amit üzemeltetni kell, de a böngészős és a szerveres esemény duplikációját közös eseményazonosítóval ki kell szűrni.
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.