Szerveroldali mérés bevezetése előtt: mit kell eldönteni és ki fogja üzemeltetni

Scheo · 2026-09-27 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A szerveroldali mérés (server-side tagging) azt jelenti, hogy a látogató böngészője a mérési adatokat először a saját mérőszerveredre küldi, és onnan továbbítod őket a Google Analytics 4, a Google Ads vagy a Meta felé. Így jobban kézben tartod az adatokat, cserébe egy új, folyamatosan futó rendszert kapsz. Ez a cikk arról szól, mit kell eldöntened, mielőtt egyetlen címkét is átköltöztetnél, és ki fogja ezt a rendszert hónapokon, éveken át életben tartani.

A szövegben háromféle jelölést használunk. Hivatalosan igazolt az, ami a Google vagy a Meta fejlesztői dokumentációjában szerepel. Saját tapasztalat az, amit bevezetések és karbantartás közben rendszeresen látunk. Szakmai feltételezés az, ami logikus következtetés, de nem mért, általános érvényű adat.

Miért üzemeltetési feladat a szerveroldali mérés, és miért nem elég egyszer beállítani?

A mérőszerver egy folyamatosan futó szolgáltatás, amelynek van tárhelye, felelőse, frissítési igénye és kiesési kockázata, ugyanúgy, mint a weboldaladnak. A böngészőoldali Google Tag Managert egyszer beállítod, a terhet a Google szerverei viszik. A szerveroldali konténert viszont neked kell futtatnod valahol, és ha az a gép leáll, vele áll le a mérésed is.

A gyakorlatban ez három új kérdést hoz. Ki fizeti és ki látja a felhőszámlát? Ki kap értesítést, ha a szerver éjjel kettőkor hibát dob? Ki frissíti a konténert, amikor a Google új verziót ad ki, vagy amikor a Meta módosít a Conversions API-n? Ha ezekre nincs név szerinti válasz, a bevezetés még nem áll készen.

Saját tapasztalat. A legtöbb gond hónapokkal a beállítás után jelentkezik. A beállító szakember addigra másik projekten dolgozik, lejár egy bankkártya a felhőfiókban, vagy valaki módosít a weboldal adatrétegén, és senki nem veszi észre, hogy a konverziók egy része eltűnt.

Milyen tárhely vagy felhőkörnyezet kell a szerveroldali méréshez?

Kell egy konténer futtatására alkalmas környezet, egy saját aldomain (például sgtm.domained.hu) és valaki, aki a hozzáféréseket kezeli. Három elterjedt út van, mindegyiknek más az üzemeltetési terhe.

Google Cloud Run

Hivatalosan igazolt. A Google Tag Manager dokumentációja a Cloud Runt adja meg alapértelmezett telepítési útként, és éles használatra több futó példányt javasol, hogy egyetlen példány kiesése ne okozzon adatvesztést. Mellette külön fut egy előnézeti (preview) szerver, ezt hibakereséshez használod. A mérőszervert a saját domained alá érdemes tenni, így a sütik first-party környezetben keletkeznek.

Előnye, hogy automatikusan skálázódik a forgalommal. Hátránya, hogy Google Cloud fiókot, számlázási fiókot, jogosultságkezelést és költségriasztást is be kell állítanod, és ezeket valakinek figyelnie kell.

Menedzselt szolgáltató

Vannak szolgáltatók, amelyek kifejezetten szerveroldali Tag Manager konténerek futtatására szakosodtak. Te a konténer beállításait adod meg, a gépet ők üzemeltetik. Szakmai feltételezés. Kis cégnél ez jó eséllyel kisebb üzemeltetési terhet jelent. Cserébe egy újabb adatfeldolgozó kerül a láncba, akivel adatfeldolgozói szerződést kell kötnöd, és akinek a kiesése a te kiesésed is.

Saját szerver Dockerrel

A szerveroldali konténer Docker-képként is elérhető, tehát saját szerveren is futtatható. Ez akkor ésszerű, ha már van rendszergazdád, aki szervereket üzemeltet, figyel és frissít. Ha nincs, ez a legkockázatosabb út, mert a biztonsági frissítés, a tanúsítvány, a terheléselosztás és a naplózás is a te felelősséged.

Bármelyiket választod, dokumentáld le egyetlen oldalon, hol fut, melyik fiókban, ki a tulajdonos, ki fér hozzá, és hová megy a riasztás. Ez az oldal ér a legtöbbet, amikor valaki kilép a csapatból.

Ki tartja karban a mérőszervert, és mi a rendszeres feladat?

Kell egy név szerinti felelős, aki legalább havonta ránéz a szerverre és a mérési adatokra, és kell mellé egy helyettes. Ez lehet belső munkatárs, ügynökség vagy fejlesztő, a lényeg, hogy írásban rögzítve legyen.

A rendszeres feladatok, amelyeket érdemes naptárba tenni:

• Hetente a fő konverziók (vásárlás, ajánlatkérés, feliratkozás) számának összevetése a háttérrendszerrel, például a webshop rendeléseivel vagy a CRM-mel.
• Havonta a szerver hibaarányának, válaszidejének és felhőköltségének átnézése.
• Negyedévente a konténer, a sablonok (templates) és a kliensek frissítése, utána tesztelés előnézeti módban.
• Minden weboldal-módosítás után az adatréteg (dataLayer) ellenőrzése, mert témacserénél vagy új pénztároldalnál gyakran változnak az eseménynevek.
• Évente a hozzáférések átnézése, a kilépett kollégák és volt partnerek eltávolítása.

Saját tapasztalat. A leggyakoribb csendes hiba az, amikor a weboldal fejlesztője módosít valamit, a böngészőoldali címke még működik, de a szerverre küldött esemény már hiányos paraméterekkel érkezik. Ezért a karbantartó és a fejlesztő között kell egy egyszerű megállapodás, hogy a pénztár és az űrlapok módosításáról előre szólnak.

Mi történik, ha a mérőszerver kiesik?

Ha a böngésző a saját mérőszerveredre küld, és az nem válaszol, az adott időszak eseményei jó eséllyel végleg elvesznek, mert a legtöbb beállításban nincs utólagos újraküldés. A weboldal közben ugyanúgy működik, a látogató semmit nem vesz észre, ezért a hiba csak a riportokban látszik, gyakran napokkal később.

Hivatalosan igazolt. A Google emiatt javasol éles környezetben több szerverpéldányt, a felhőszolgáltatók pedig állapotfigyelést (health check) és riasztást kínálnak a futó szolgáltatásokhoz.

Kiesésre három dolgot készíts elő:

1. Riasztás. Állíts be állapotfigyelést a mérőszerver címére, és ha egymás után többször nem válaszol, menjen értesítés e-mailben vagy üzenetben a felelősnek és a helyettesnek. Egyszer teszteld is, hogy tényleg megérkezik.
2. Tartalék útvonal. Döntsd el előre, hogy tartós kiesésnél ideiglenesen visszaállsz-e a böngészőoldali küldésre. Ehhez a böngészőoldali konténer előző verzióját tartsd meg közzétehető állapotban.
3. Kiesési napló. Írd fel, mikor kezdődött és mikor ért véget a kiesés, hogy a havi riportban meg tudd magyarázni a konverziós visszaesést, és a hirdetési fiókban ne hozz rossz döntést egy mérési lyuk miatt.

Szakmai feltételezés. Az automatikus ajánlattételű kampányok a beérkező konverziókból tanulnak, így egy többnapos mérési kiesés a riport mellett jó eséllyel a kampány optimalizálását is rontja.

Hogyan teszteld párhuzamosan a böngészőoldali méréssel?

A biztonságos út az, hogy egy ideig mindkét mérés fut egymás mellett, és naponta összeveted a számokat. Így kiderül, hogy a szerveroldali lánc hozza-e ugyanazokat az eseményeket, mielőtt a régit kikapcsolnád.

A párhuzamos futtatás két gyakori módja:

• Külön GA4 tulajdon a tesztre. A szerveroldali lánc egy teszt-tulajdonba küld, a meglévő böngészőoldali mérés érintetlen marad. Így az éles riportban nincs duplikáció.
• Deduplikált párhuzamos küldés hirdetési platformra. A Meta pixel és a Conversions API egyszerre küldheti ugyanazt az eseményt, ha mindkettő ugyanazt az eseménynevet és eseményazonosítót (event_id) kapja. Hivatalosan igazolt. A Meta dokumentációja szerint ilyenkor a rendszer a két beérkezést egy eseménynek számolja.

Az eseményazonosítót a böngészőben érdemes előállítani, és ugyanazt az értéket továbbadni mindkét irányba. Egy vásárlási adatréteg-bejegyzés így nézhet ki: dataLayer.push({event: 'purchase', event_id: 'purchase-' + order.id, transaction_id: order.id, value: order.total, currency: 'HUF'}). A transaction_id a GA4-ben segít kiszűrni a duplán rögzített vásárlásokat, az event_id a Meta-oldali deduplikációhoz kell. Mivel mindkettő a rendelésszámból képződik, egy oldalfrissítés sem hoz létre új azonosítót.

Saját tapasztalat. A párhuzamos időszak legyen legalább két-négy hét, fedjen le legalább egy teljes hetet hétvégével, és ha lehet, egy hónap eleji vagy akciós csúcsot is. Alacsony forgalmú oldalon ennél hosszabb kell, mert néhány konverzióból nem lehet eltérést megállapítani.

Hogyan ellenőrzöd, hogy nem veszett el esemény?

Háromszintű összevetéssel, amelyben a háttérrendszer tényadata, a böngészőoldali mérés és a szerveroldali mérés számai egymás mellett állnak, naponta, eseménytípusonként. A háttérrendszer (webshop-rendelések, CRM-be érkezett ajánlatkérések) számít valóságnak, a két mérést ehhez képest nézed.

Egy egyszerű táblázat elég hozzá. Az oszlopok a dátum, az eseménytípus, a háttérrendszer darabszáma, a böngészőoldali és a szerveroldali darabszám, végül az eltérés százalékban.

Az összevetésnél ezekre figyelj:

• Az eltérés iránya. Ha a szerveroldali szám tartósan kisebb, valahol elveszik esemény (hibás kliens, hiányzó paraméter, időtúllépés). Ha nagyobb, lehet, hogy duplán küldesz.
• Az eltérés stabilitása. Egy-két napos kiugrás lehet véletlen, a tartós, azonos irányú eltérés hibára utal.
• A paraméterek teljessége. Az esemény megérkezése mellett a value, a currency és a transaction_id értékének is ott kell lennie.
• A hozzájárulás kezelése. Hivatalosan igazolt. A Google hozzájárulási módja (Consent Mode) szerveroldalon is érvényesül, a szerver a böngészőtől kapott hozzájárulási állapotot viszi tovább. Ha a szerveroldali szám gyanúsan nagyobb, ellenőrizd, hogy hozzájárulás nélküli látogatók adatai nem kerülnek-e olyan helyre, ahová nem mehetnének.

Szakmai feltételezés. A két mérés között néhány százalékos eltérés természetes, mert az adatok eltérő időpontban és eltérő hálózati úton érkeznek. Az elfogadható küszöböt a saját adataidon, a párhuzamos időszakban érdemes kijelölni, még az élesítés előtt.

Milyen öt lépésből áll a bevezetési ellenőrzőlista?

Döntés, környezet, párhuzamos futtatás, átállás, utókövetés. Ezt az öt lépést érdemes sorrendben, pipálható listaként végigvinni.

1. Döntés és felelősök. Rögzítsd írásban, melyik adatot akarod megbízhatóbban mérni, ki a felelős, ki a helyettes, és ki fizeti a környezetet. Egyeztesd az adatvédelmi felelőssel, milyen adat hová megy, és frissítsd az adatkezelési tájékoztatót.
2. Környezet és domain. Válaszd ki a futtatási környezetet, állítsd be a saját aldomaint és a tanúsítványt, a több példányt, az előnézeti szervert, a költség- és állapotriasztást. Próbáld ki, hogy a riasztás tényleg megérkezik.
3. Párhuzamos futtatás. Kösd be a szerveroldali láncot külön teszt-célhelyre vagy deduplikációval, és vezesd a napi összevető táblázatot legalább két-négy hétig. Az elfogadható eltérést rögzítsd előre.
4. Átállás. Ha a számok stabilan a küszöbön belül vannak, kapcsold át az éles célhelyeket. A régi böngészőoldali konténer-verziót tartsd meg közzétehető állapotban, és jegyezd fel a verziószámát.
5. Utókövetés. Az átállás utáni első hónapban hetente, utána havonta nézd át a számokat, és tedd naptárba a negyedéves frissítést.

Mi legyen a leállítási terv, ha valami nem működik?

A leállítási terv egy előre megírt, néhány soros forgatókönyv arról, milyen jelre, ki és milyen lépésekkel állítja vissza a böngészőoldali mérést. Akkor ér a legtöbbet, ha még a bevezetés előtt elkészül, így a hiba közben már csak végre kell hajtani.

Egy működő leállítási terv részei:

• Kiváltó feltétel. Például ha a fő konverzió szerveroldali száma két egymást követő napon a megállapított küszöbnél jobban elmarad a háttérrendszertől, vagy a szerver órákig nem érhető el.
• Döntéshozó. Egy ember, aki kimondja a visszaállást, hogy ne a hiba közben kelljen egyeztetni.
• Visszaállítási lépések. A böngészőoldali konténer mentett verziójának közzététele, a hirdetési platformokon a böngészőoldali küldés visszakapcsolása, és a szerveroldali küldés leállítása, hogy ne legyen duplikáció.
• Ellenőrzés a visszaállás után. Előnézeti módban és a platformok eseménykezelőjében megnézni, hogy az események újra beérkeznek.
• A visszatérés feltétele. Mikor és milyen javítás után próbálkozol újra a szerveroldali lánccal.

Saját tapasztalat. A Google Tag Manager verziókezelése miatt maga a visszaállás néhány perc, ha a mentett verzió megvan. Az időigényes rész a hirdetési fiókok korábbi beállításainak visszakeresése, ezért ezeket is írd bele a tervbe.

Mikor nem javasolt kis cégnek belevágni a szerveroldali mérésbe?

Ha nincs, aki hosszú távon karbantartsa, vagy ha a böngészőoldali mérés sem megbízható még, a szerveroldali mérés jó eséllyel több kockázatot hoz, mint hasznot.

Ezekben az esetekben érdemes várni:

• Nincs név szerinti felelős és helyettes, a beállítást egy külsős végezné, akivel nincs folyamatos megállapodás.
• A böngészőoldali mérés sem tiszta, konverziók hiányoznak vagy duplán futnak, nincs rendes adatréteg. A szerveroldali lánc ezeket a hibákat egyszerűen továbbviszi.
• Havonta csak néhány konverzió történik, így a párhuzamos időszakban sem lehet megbízhatóan összevetni a két mérést.
• Nem fut fizetett hirdetés, és a riportokat senki nem használja döntésre.
• A weboldal zárt rendszeren fut, ahol nem tudsz saját aldomaint vagy adatréteget beállítani.
• A hozzájáruláskezelés és az adatkezelési tájékoztató nincs rendben. Ezt előbb kell megoldani.

Szakmai feltételezés. Ilyenkor a böngészőoldali mérés rendbetétele, egy tiszta adatréteg és a Meta Conversions API platform által kínált, beépített integrációja (sok webshopmotorhoz van ilyen bővítmény) jellemzően kisebb terhet jelent, és a mérés megbízhatóságát szintén javíthatja. A szerveroldali konténer később is bevezethető, amikor már van, aki üzemeltesse.

Források és további olvasnivalók

• Google Tag Manager fejlesztői dokumentáció, szerveroldali címkézés (Server-side tagging)
• Google Tag Manager dokumentáció, a szerveroldali konténer telepítése Cloud Runon és éles környezetben
• Google Cloud Run dokumentáció, skálázás és minimális példányszám
• Google Analytics 4 súgó, hozzájárulási mód (Consent Mode) és tranzakcióazonosító
• Meta for Developers, Conversions API és a pixel- és szerveresemények deduplikációja
• Európai Adatvédelmi Testület (EDPB) iránymutatásai a hozzájárulásról