Mérés és adat, fejlesztői kézből

GA4 szerver oldali követés
adatvesztés nélkül

A böngészőből futó mérés évről évre kevesebbet lát: a süti-visszautasítás és a hirdetésblokkolók miatt a konverziók egy része meg sem jelenik a GA4-ben. A szerver oldali követésnél az események az Ön saját szerverén át mennek tovább, így a hirdetési fiókokban is pontosabb adat érkezik.

sGTM saját VPS-en·Consent Mode v2·Enhanced Conversions·Meta CAPI
Mérési auditot kérek→

Mit old meg
a szerver oldali mérés?

Három dolgot. A böngészőben blokkolt vagy megszakadt mérést a szerverről küldött esemény pótolja, így a vásárlás akkor is rögzül, ha a Google szkriptje nem fut le. A saját aldomainről kiszolgált süti élettartama hosszabb, a visszatérő látogató visszatérő marad. A Consent Mode v2 állapota pedig a méréslánc minden pontján végigmegy.

A szerver oldali követés a hozzájárulást tiszteletben tartja: aki a méréshez nem járult hozzá, annak az adata azonosítható formában nem megy tovább. A nyereség abból jön, hogy a hozzájáruló felhasználók adata hiánytalanul megérkezik.

3–4 hétaz audittól az éles üzemig
5%alatti eltérés a rendelések és a GA4 között
0 Fta mérési audit
Szerver oldali Google Tag Manager: a webkonténer eseménye a szerverkonténeren át jut el a GA4-be
Webkonténer → szerverkonténer → GA4

Mit tartalmaz egy bevezetés nálunk?

Hat tétel, a webáruház tényleges adatmodelljére illesztve. Átadáskor eseménytérképet, tesztjegyzőkönyvet és a teljes konfigurációt írásban is megkapja.

  • 01

    Gyűjtőpont a saját infrastruktúrán

    sGTM konténer vagy saját mérőréteg az Ön szerverén, saját aldomainen és tanúsítvánnyal.

  • 02

    GA4 e-commerce eseménylánc

    Terméklista, kosárba tétel, pénztár-lépések és vásárlás, a teljes lánc bekötve.

  • 03

    Consent Mode v2

    Alapállapot, frissítés és továbbadás a szerver felé, a sütibanner tényleges eseményeire kötve.

  • 04

    Enhanced Conversions

    A Google Ads visszamérés pontosítása a rendelési adatokból, a Google előírásai szerinti előfeldolgozással.

  • 05

    Meta Conversions API

    Szerverről küldött események a Facebook hirdetésekhez, a böngészős pixellel duplikációmentesen párosítva.

  • 06

    Rendelés-alapú visszamérés

    Sztornó, visszáru vagy utólagos jóváhagyás esetén a végleges rendelésállapotra mérünk.

Mi az a szerver oldali követés?

A nagy webshopok és vállalkozások már tudják. Ön se maradjon le.

TemueMAGAlzaTelekomMediaMarktiPonBestByte

Ezek a webáruházak már szerver oldali követést használnak, ezért működnek jobban a hirdetéseik. Az új adatvédelmi szabályok, az iPhone és a privát böngészők miatt a hagyományos, böngészőből futó mérés ma már nem látja eléggé a vásárlásokat. A hirdetések kevésbé tanulnak, a költségek nőnek.

A nagyobb vállalkozások szervert bérelnek a Google-től és nagy marketing ügynökségekkel állítják be sok idő alatt, magas költséggel. Mi más utat is kínálunk: saját fejlesztésű, közvetlen szerveroldali mérést külön tracking szerver nélkül, WordPress, Magento és egyedi PHP oldalakhoz is.

Saját tárhellyel, egyszeri költséggel felveheti a versenyt a nagyokkal.

Így néz ki az adat útja
Látogató böngészője AZ ÖN SZERVERE mérőréteg vagy sGTM konténer hozzájárulás szerint GA4 Analytics Google Ads Enhanced Conversions Meta CAPI Conversions API

A nyers eseményfolyam először az Ön szerverén áll meg. Innen Ön dönti el, mi megy tovább és milyen formában.

Két út van rá: sGTM konténer.saját mérőréteg.

1. sGTM konténer a saját VPS-en

A Google szabványos szerveroldali Tag Manager konténere fut az Ön Ubuntu VPS-én, saját aldomainen. Ismerős GTM felület, sok kész sablon, könnyen továbbadható másik szakembernek.

  • Mikor jóSok hirdetési rendszerHa több platformot kell bekötni, vagy fontos, hogy a beállítást bárki át tudja venni.
  • ÜzemeltetésKülön konténer futA konténert frissíteni és figyelni kell, ezt a szerverüzemeltetés részeként viszünk.
  • KöltségEgyszeri beállítás + szerverSaját szerveren a havi költség a kérésszámtól független.

2. Saját fejlesztésű mérőréteg

Közvetlen szerveroldali mérés a webáruház kódjából, külön tracking konténer nélkül. WordPress, Magento 2, saját WShop és egyedi PHP rendszerekhez is elkészítjük.

  • Mikor jóA mérés a webshoppal együtt fejlődikHa nem kell tucatnyi külső rendszert kiszolgálni, csak a GA4-et, a Google Ads-et és a Metát.
  • PontosságVégleges rendelésállapotA mérés a rendelés tényleges sorsát követi: sztornó, visszáru, utánvétes átvétel.
  • KöltségKevesebb mozgó alkatrészNincs külön konténer, az üzemeltetési költség alacsonyabb.

A bérelt szolgáltatáson futó konténer havidíjas és a kérésszámmal nő, a saját szerveres megoldásoknál az egyszeri beállítás után lényegében a szerver költsége marad. A bevezetés ára a mérendő események számától, a platformtól és a bekötendő hirdetési rendszerek számától függ, felmérés után írásos, fix áras ajánlatot adunk.

Miért lett ez ennyire kritikus?

A nagy cégek már pontosan tudják, mit csinálnak. Nem véletlen, hogy a hirdetéseik ennyire hatékonyak: szerver oldali követést használnak, így a kampányaik valós adatok alapján tanulnak és optimalizálódnak.

Az elmúlt időszakban néhány marketingügynökség is elkezdte alkalmazni a server-side követést Google Tag szerver konténerrel. Ez azonban jellemzően csak nagyobb cégeknek éri meg, hiszen külön szervert, infrastruktúrát és folyamatos üzemeltetést igényel, ami jelentős költséggel jár.

A mi utunk

Kifejlesztettünk egy közvetlen, szerveroldali injektálási megoldást, amely a meglévő webszerverről működik, legyen szó WordPressről, Magentóról vagy egyedi PHP alapú weboldalról. Nincs külön tracking szerver, nincs extra infrastruktúra, mégis ugyanaz az adatminőség érkezik.

Itthon az elsők között alkalmazzuk ezt a technológiát. Jelenleg csak néhány fejlesztői csapat van az országban, amely valóban működő, éles környezetben használt szerver oldali követést tudott kifejleszteni és bevezetni. Ez nem sablonmegoldás vagy plugin, hanem valódi fejlesztői tudást igénylő rendszer, amelyet kevés helyen értenek és még kevesebben használnak hatékonyan.

Az új GDPR és adatvédelmi szabályozások, a privát böngészők, valamint az iPhone és a Safari szigorú adatvédelme alapjaiban változtatták meg a mérési környezetet. A klasszikus, böngészőoldali követés ma már nem látja a vásárlások jelentős részét.

Ennek a következményei

Nincs visszajelzés A hirdetési rendszerek nem kapják meg a vásárlás jelzését, így nem tudják, melyik kattintás hozott eredményt.
A kampányok nem tanulnak Az algoritmus hiányos adatból optimalizál, ezért egyre rosszabb közönséget céloz meg.
Romló megtérülés Kevesebb vásárló, drágább hirdetés, csökkenő megtérülés. A különbség hónapról hónapra nő.

A szerver oldali mérés ezt a szakadékot hidalja át: a vásárlás akkor is elér a hirdetési rendszerekhez, ha a böngészőben a mérőkód nem futott le.

Hogyan működik?

A hirdetések megértése 2026-ban

A követés alapja általában egy JavaScript kód, amely az oldalon betöltve rögzíti a látogatók és vásárlók adatait. Csakhogy nem mindenki szereti, ha követik. A fölösleges scriptek lassítják az oldalt, rontják a böngészési élményt, ezért egyre többen használnak reklámblokkolót, privát böngészőt vagy iPhone-t. Ezeken az eszközökön a követőkódok gyakran nem, vagy csak részben töltődnek be.

Képzeljük el a helyzetet: egy vásárló rákattint a hirdetésre, leadja a rendelést, de a Google erről semmit nem tud. A rendszer nem kap visszajelzést, így nem tud tanulni és finomítani a célközönséget. Ennek eredménye, hogy a hirdetések egyre több olyan embernek jelennek meg, akit valójában nem is érdekel a termék, a költség pedig csak nő.

A szerver oldali követés ezt a problémát hidalja át. A vásárlási adatok közvetlenül a szerverről jutnak el a hirdetési rendszerekhez, függetlenül a böngészőtől, a reklámblokkolóktól vagy az eszköztől.

Hol vesznek el az adatok
KLIENS OLDALI MÉRÉS hirdetésblokkoló, ITP, a süti visszautasítása Vásárlás az oldalon GA4, Ads, Meta hiányos adat SZERVER OLDALI MÉRÉS Vásárlás az oldalon Az Ön szervere első fél, saját domén GA4, Ads, Meta teljes adat a hozzájáruló látogatók adata hiánytalanul átér
Gyorsabb weboldal
→
Valós adatok
→
Pontosabb tanulás
→
Hatékonyabb hirdetések
→
Alacsonyabb költségek

Mennyit visz el a hiányzó mérés?

Állítsa be a saját számait és nézze meg, mekkora tétel forog kockán. A csúszkák csak szemléltetnek, a tényleges hiányt a mérési audit mutatja meg.

Az Ön számai
203 000
100 e Ft10 M Ft
5%55%
Amit ez jelent
Ennyi vásárlást nem lát a hirdetési fiók havonta 90 db
Ennyi hirdetési költés optimalizál hiányos adatra havonta 360 000 Ft
Ugyanez éves szinten 4 320 000 Ft
Amit a hirdetési fiók lát210 db
Ami valójában megtörtént300 db

Ez szemléltetés, nem ígéret. A tényleges hiány csak méréssel állapítható meg: össze kell vetni a GA4-ben látott rendelésszámot a webshop saját rendelési adataival. Ezt a mérési auditban díjmentesen elvégezzük, még a döntés előtt.

Hogyan zajlik a bevezetés?

Öt szakasz a mérési audittól a felügyelt éles üzemig. A megadott időtartamok egy átlagos webáruházra vonatkoznak; egyedi platformnál vagy sok integrációnál hosszabb lehet.

0101Audit

Mérési audit és eseménytérkép

Végignézzük, mi mérődik most és mi nem: a jelenlegi GA4 beállítást, a sütibannert, a hirdetési címkéket és a webshop adatrétegét. Ebből készül az eseménytérkép: melyik felhasználói lépéshez milyen esemény és milyen paraméterek tartoznak. Ez a dokumentum lesz később az átvevő teszt alapja is.

3–5 nap · eseménytérkép · adatréteg-átnézés
0202Szerver

Szerverkörnyezet és konténer

A szerveroldali konténer telepítése a saját VPS-re: saját aldomén, tanúsítvány, terheléshez méretezett erőforrás, monitorozás és naplózás. Ha bérelt szolgáltatás mellett dönt, itt azért is elkészül a saját alnevet használó végpont, mert e nélkül az előnyök egy része elvész.

2–4 nap · saját aldomén · tanúsítvány · monitorozás
0303Bekötés

Események bekötése és hozzájárulás-kezelés

A GA4 e-commerce eseménylánc, az Enhanced Conversions és a Meta Conversions API bekötése, duplikációmentes eseményazonosítással. Ezzel együtt épül be a Consent Mode v2: az alapállapot, a frissítés és a hozzájárulás továbbadása a szerveroldali konténernek. A legtöbb hiba ezen a ponton keletkezik, ezért itt a legalaposabb a munka.

1–2 hét · e-commerce eseménylánc · Meta CAPI · Consent Mode v2
0404Ellenőrzés

Ellenőrzés és összevetés

Párhuzamos futtatás a régi méréssel, majd összevetés a webshop tényleges rendelési adataival, ez az egyetlen értelmes referencia. Megnézzük a rendelésszám, a bevétel és a forrás szerinti bontás eltérését és addig hangolunk, amíg az eltérés magyarázható marad.

3–5 nap · párhuzamos futtatás · rendelési adat
0505Üzemeltetés

Átadás és felügyelet

Átadáskor Ön megkapja az eseménytérképet, a tesztjegyzőkönyvet és a konténer konfigurációját írásban. Utána felügyelet: a konténer rendelkezésre állása, a hibás események aránya és a platformok API-változásai figyelve maradnak, mert ezek évente többször változnak.

folyamatos · rendelkezésre állás · hibaarány · API-változások

Gyakori kérdések a szerver oldali követésről

23 kérdés öt témában, őszinte válaszokkal, beleértve azt is, amikor a válasz az, hogy még nem éri meg.

Kérdezzen tőlünk

Alapok és adatvesztés

Mi az a szerver oldali követés és miben más, mint a böngészős mérés?

A hagyományos mérésnél a látogató böngészője küldi az adatot közvetlenül a Google-nek és a többi rendszernek. Ezt a láncot sok minden megszakítja: hirdetésblokkoló, böngésző-védelem, rövid élettartamú sütik, lassan betöltődő szkriptek.

Szerver oldali követésnél a böngésző csak az Ön saját szerverének küld adatot, és innen megy tovább, ellenőrzött formában a mérő és hirdetési rendszerek felé. Így kevesebb adat vesz el, és Ön dönti el, milyen mezők hagyják el a rendszert.

Mennyi adatot veszít a webshopom a jelenlegi méréssel?

Ez nem tippelhető meg általánosságban, mert erősen függ a közönségtől, az eszközmegoszlástól és a sütibanner megfogalmazásától. Megállapítani viszont könnyen lehet: össze kell vetni a GA4-ben látott rendelésszámot és bevételt a webshop saját rendelési adataival ugyanarra az időszakra. Az eltérés a valós adatvesztés. Ezt a mérési auditban díjmentesen elvégezzük, még a döntés előtt.

Mi történik, ha a látogató hirdetésblokkolót használ?

A blokkolók névlista alapján tiltják a jellegzetes mérő és hirdetési címeket, ezért a böngészőből induló kérés egyszerűen nem megy el. Magyar webshopoknál ez a látogatók érzékeny hányada, technikai és fiatalabb közönségnél a legmagasabb.

Saját aldoménről kiszolgált mérésnél a kérés az Ön domainjére megy, így jellemzően átmegy. Ez nem a látogató döntésének megkerülése: ha valaki nem járult hozzá a méréshez, az adata továbbra sem megy sehová.

Kell-e szerver oldali követés egy kis webáruháznak?

Legtöbbször nem éri meg azonnal. Ha havi néhány tíz rendelésnél tart a webshop és nincs érdemi hirdetési költés, akkor a pontosabb mérés nem hoz annyit, amennyibe kerül. A határ ott van, ahol a hirdetési költés döntéseit már a mérés vezérli: ha az algoritmus rossz adatból tanul, akkor a hirdetési költség egy része biztosan elvész. Ilyenkor a bevezetés jellemzően gyorsan megtérül.

Mi a különbség a régi Google Analytics és a GA4 között?

A régi Google Analytics (Universal Analytics) munkamenetekben és oldalmegtekintésekben gondolkodott, 2023 nyarán leállt. A GA4 eseményalapú: minden interakció (görgetés, kosárba tétel, vásárlás) önálló esemény, paraméterekkel. Ettől rugalmasabb, a beállítása viszont több tervezést kíván.

A szerver oldali követés a GA4 eseménymodelljére épül: ugyanazokat az eseményeket küldi, csak a saját szerveren át. Magyarországon a „google analytics” kifejezésre havonta 8 100, a „ga4” kifejezésre 480 keresés jut a Kulcsszótervező szerint, a téma tehát sok webshop-tulajdonost foglalkoztat.

Adatvédelem és megfelelés

Megkerüli-e a süti-hozzájárulást a szerver oldali mérés?

Nem, és nem is szabad, hogy megkerülje. A hozzájárulás hiányában a felhasználó adata nem továbbítható azonosítható formában, függetlenül attól, hogy böngészőből vagy szerverről menne. Aki ezt másként ígéri, az kockázatot ad el. A szerver oldali megoldás előnye az, hogy a hozzájáruló felhasználók adata hiánytalanul átér és hogy Ön szabja meg, milyen mezők hagyják el a rendszert.

Mi a különbség a Consent Mode v2 és a sütibanner között?

A sütibanner az a felület, ahol a látogató dönt. A Consent Mode az a mechanizmus, amely ezt a döntést továbbadja a Google rendszereinek, hogy azok ehhez igazodjanak. A kettő gyakran úgy van bekötve, hogy a banner szépen megjelenik, de a döntés nem jut el sehová. Ilyenkor a webshop jogilag ugyanúgy kockázatos és még adatot is veszít. A bevezetés során mindig a tényleges banner-eseményekre kötjük rá az állapotváltást.

Elég-e a Consent Mode v2 a GDPR-megfeleléshez?

Nem önmagában. A Consent Mode technikai eszköz, nem jogi megfelelőség. Kell mellé rendes tájékoztató, valódi választási lehetőség, a hozzájárulás visszavonásának lehetősége és a hozzájárulások naplózása. A technikai részt mi megcsináljuk és dokumentáljuk; a jogi szövegezéshez ügyvédre van szükség, mi nem adunk jogi tanácsot.

Mi történik a meglévő GA4 adataimmal?

Semmi, a korábbi adatok megmaradnak, a mérés ugyanabba a GA4 tulajdonba érkezik tovább. Ami változik, az az adat teljessége, ezért az áttérés után a számok jellemzően magasabbak lesznek. Ezt érdemes az áttérés dátumával megjegyezni a riportokban, különben később új növekedésnek tűnik, ami valójában mérési pontosság.

Technikai megvalósítás

Saját szerveren vagy bérelt szolgáltatáson futtassam?

Kisebb forgalomnál a bérelt szolgáltatás gyorsabban elindul és kevesebb figyelmet igényel. Nagyobb forgalomnál a saját VPS jellemzően olcsóbb, mert a bérelt megoldások ára a kérésszámmal nő, a szerveré nem. A másik szempont az adat: saját szerveren a nyers eseményfolyam Önnél marad és Ön dönti el, miből mennyi megy tovább harmadik félnek. Mivel nálunk a szerverüzemeltetés alapértelmezetten megvan, a saját szerveres út nem jelent plusz szolgáltatót.

Kell hozzá saját aldomén? Mit jelent a first-party kiszolgálás?

Igen, a mérő végpont az Ön saját doménjénél, jellemzően egy aldoménen fut, például adat.sajatdomain.hu néven, saját tanúsítvánnyal. Ez a first-party kiszolgálás: a böngésző szempontjából a kérés nem külső szolgáltatóhoz megy, hanem az oldal saját rendszeréhez.

Ennek két haszna van: a sütik élettartama hosszabb marad, és a blokkolók ritkábban szűrik ki a kérést. A DNS-beállítást és a tanúsítványt mi intézzük.

Mi az a duplikációmentes eseményazonosítás és miért fontos?

Ha ugyanaz a vásárlás böngészőből és szerverről is elmegy, akkor kétszer számítódhat, és a hirdetési megtérülés látszatra megduplázódik. Ennek elkerülésére minden esemény egyedi azonosítót kap, amit mindkét út visz magával, és a fogadó rendszer ez alapján összevonja őket. Ez az egyik leggyakoribb hiba a rosszul bevezetett szerveroldali méréseknél.

Lassítja az oldalt a mérés?

A szerver oldali megoldás jellemzően gyorsít: a böngészőnek kevesebb szkriptet kell letöltenie és futtatnia, mert a nehezét átveszi a szerver. A különbség mobilon és gyengébb készüléken a legláthatóbb, ott, ahol a Core Web Vitals értékek is dőlnek el.

A szerver oldali feldolgozás a látogató számára észrevétlen, mert nem az oldalbetöltés útjában történik. A mérési audit része, hogy megnézzük, mennyi felesleges mérőszkript fut jelenleg az oldalon.

Mi az a Google Tag Manager és mi a szerveroldali konténer?

A Google Tag Manager (GTM) címkekezelő: egy helyről irányítható, milyen mérő- és hirdetési kódok futnak az oldalon, fejlesztői beavatkozás nélkül. A hagyományos webkonténer a látogató böngészőjében fut.

A szerveroldali konténer (sGTM) ugyanez a logika egy szerveren: a böngésző egyetlen kérést küld a saját aldomainre, a konténer pedig onnan osztja szét az eseményt a GA4, a Google Ads és a Meta felé. A webkonténer ettől még megmarad, csak jóval kevesebb kódot futtat.

Platformok és események

Működik-e Shoprenter, UNAS vagy Shopify felett?

Ahol a platform enged saját szkriptet és adatréteget, ott igen, de a bérelt rendszereknél mindig van korlát abban, hogy milyen eseményt és milyen paraméterrel lehet kinyerni, különösen a pénztár-lépéseknél. Egyedi vagy önfuttató rendszernél (Magento 2, WooCommerce, saját fejlesztés) a mérés teljes és a rendelés végleges állapotára is tudunk visszamérni. A felmérésben mindig megmondjuk, mi az, ami az adott platformon nem fog menni.

Mérhető-e a sztornózott vagy visszáruzott rendelés?

Igen, és érdemes is. A köszönőoldalra alapozott mérés a leadás pillanatát rögzíti, holott a valós bevétel később dől el. Ahol a rendszer engedi, ott a végleges rendelésállapotra mérünk vagy utólagos korrekciót küldünk, így a hirdetési algoritmus nem a lemondott rendelésekre optimalizál. Utánvétes webáruháznál ez különösen sokat számít.

Mit jelent az Enhanced Conversions és a Meta Conversions API?

Mindkettő arra való, hogy a konverzió a hirdetési rendszerhez akkor is biztosan megérkezzen, ha a böngészős út megszakad. A Google Enhanced Conversions a hozzájárulással megadott e-mail cím titkosított változatát küldi, a Meta Conversions API pedig a vásárlási eseményt továbbítja szerverről.

A kettő együtt használva adja a legpontosabb képet, és mindkettő a hozzájárulási állapothoz igazodik. A WebPot rendszereiben a Meta CAPI bekötés beépített, nem külön fejlesztés.

Hogyan ellenőrizhetem, hogy tényleg jól mér?

Három független forrást vetünk össze egy adott időszakra: a webshop saját rendelési listáját, a GA4 adatait és a hirdetési fiókok konverzióit. Ha ezek 5 százalékon belül vannak egymáshoz képest, a mérés rendben van.

Átadáskor ezt az összevetést írásban is megkapja, és megmutatjuk, hogyan tudja bármikor maga is elvégezni. Így nem kell elhinnie, hogy jól működik: ellenőrizni tudja.

Mi az az adatréteg (dataLayer) és miért ezen múlik a mérés?

Az adatréteg az a strukturált adatcsomag, amelyet a webáruház ad át a mérőrendszernek: termékazonosító, név, ár, mennyiség, rendelésszám, végösszeg. A GA4 e-commerce riportjai, az Enhanced Conversions és a dinamikus remarketing mind ebből dolgoznak.

Ha az adatréteg hiányos vagy pontatlan, a legjobb szerveroldali beállítás is hibás adatot továbbít. Ezért a bevezetés első lépése az adatréteg rendbetétele a webshop kódjában, amit fejlesztőként mi végzünk el.

Ár, határidő, üzemeltetés

Mennyibe kerül és mi a folyamatos költség?

A bevezetés ára a mérendő események számától, a platformtól és a bekötendő hirdetési rendszerek számától függ, ezért felmérés után adunk írásos ajánlatot, fix árral, nem óradíjjal. A folyamatos költség saját szerveren jellemzően magának a szervernek a díja; bérelt szolgáltatásnál a szolgáltató havidíja, amely a forgalommal nő.

Mennyi idő alatt áll össze?

Egy átlagos webáruháznál három-négy hét a mérési audittól az éles üzemig, ebből a legtöbb idő az események bekötése és az ellenőrzés. Egyedi platformnál vagy sok integrációnál hosszabb. A régi mérés végig működik, így nincs vak időszak.

Ki fér hozzá a rendszerhez az átadás után?

Ön. A konténer, a szerver és a mérőfiókok az Ön tulajdonában maradnak, mi csak hozzáférést kapunk a munkához. Átadáskor a teljes konfigurációt írásban is megkapja, hogy később bármelyik fejlesztő tovább tudja vinni. Nem építünk függőséget.

Mi történik, ha a Google vagy a Meta megváltoztatja az API-t?

Ez évente többször előfordul, és a rosszul karbantartott mérések ilyenkor csendben elromlanak, a riport továbbra is mutat számokat, csak már nem a valósat. Ezért érdemes felügyeletet tartani mellette: figyeljük a hibás események arányát és a platformok változásait, majd változás esetén módosítunk, mielőtt adat veszne el.

Fogalomtár amit érdemes érteni ajánlatkérés előtt

Ezek a kifejezések visszatérnek minden ajánlatban és minden szolgáltatónál. Érdemes tisztában lenni velük, már csak azért is, hogy össze lehessen hasonlítani az ajánlatokat.

Szerver oldali követés (server-side tracking)
Mérési mód, amelyben a weboldal eseményei nem közvetlenül a látogató böngészőjéből jutnak el a mérő- és hirdetési rendszerekhez, hanem egy köztes, saját irányítás alatt álló szerveren keresztül. Így szabályozható, mely adatok hagyják el a rendszert és a mérés kevésbé függ a böngésző korlátozásaitól.
sGTM (szerveroldali Google Tag Manager)
A Google Tag Manager azon változata, amely nem a böngészőben, hanem egy szerveren fut. Ide érkeznek be a weboldal eseményei, és innen mennek tovább a célrendszerekbe: szűrve, kiegészítve vagy átalakítva.
Consent Mode v2
A Google hozzájárulás-kezelési mechanizmusa, amely a látogató süti-döntését továbbítja a Google rendszereinek, hogy azok ehhez igazodjanak. Nem helyettesíti a sütibannert és nem önmagában jelent jogi megfelelőséget.
Enhanced Conversions
Google Ads funkció, amely a konverziós eseményhez előfeldolgozott, azonosításra alkalmas adatot csatol, hogy a hirdetési visszamérés pontosabb legyen ott is, ahol a böngészőoldali azonosítás nem működik.
Conversions API (CAPI)
A Meta szerver-szerver kapcsolata, amelyen keresztül a vásárlási és egyéb események a böngésző megkerülésével küldhetők. A böngészőoldali pixellel együtt, duplikációmentesen párosítva használandó.
Measurement Protocol
A Google Analytics felülete, amelyen keresztül szerverről közvetlenül küldhetők mérési események. Tipikus használata a később bekövetkező események visszavezetése, például rendelés-állapotváltozás vagy utólagos jóváhagyás.
Adatréteg (dataLayer)
A weboldal és a mérőrendszer közötti szabványos adatátadási felület. Minősége dönti el, hogy egyáltalán mit lehet mérni: ha a termékár, a mennyiség vagy a rendelésazonosító nem kerül bele, akkor a mérés sem látja.
Duplikációmentes eseményazonosítás (event deduplication)
Eljárás, amelyben ugyanaz az esemény mindkét úton (böngésző és szerver) egyedi azonosítóval érkezik, így a fogadó rendszer felismeri és egyszer számolja. Enélkül a konverziószám és a megtérülés felülmért lesz.
Első féltől származó adat (first-party data)
Az az adat, amelyet a saját rendszer gyűjt a saját doménen. A szerver oldali mérés lényege épp az, hogy az eseményfolyam először ide érkezik és csak innen megy tovább, nem fordítva.
ITP (Intelligent Tracking Prevention)
Böngészőoldali védelem, amely korlátozza a követésre alkalmas sütik élettartamát és használatát. Egyik következménye, hogy a visszatérő látogató új felhasználóként jelenhet meg a statisztikában.

Kapcsolódó szolgáltatásaink

A mérés akkor ér valamit, ha a mögötte lévő rendszer is rendben van. Ezeken dolgozunk még:

Tegye meg az első lépést egy sikeres vállalkozás felé!

A WebPot DEV 15 év tapasztalattal segít Magento, WordPress, e-commerce, egyedi webes rendszerek és mobilalkalmazások fejlesztésében.

A web mellett Android- és Windows-alkalmazás, szerverüzemeltetés, AI-integráció, Loxone okosotthon és robotfűnyíró telepítés is a profilunk.

Írja meg elképzelését vagy problémáját és nézzük meg együtt, hogyan valósíthatjuk meg.

Telefon: +36 30 199 1620 WebPot DEV a LinkedInen GitHub WebPot DEV a Facebookon WhatsApp

WebPot DEV logó

Tervezéstől a kivitelezésig: WebPot DEV

Ingyenes konzultáció

Foglaljon 30 perces konzultációt

Átnézzük a céljait és a jelenlegi oldalát, a hívás végén becsült ársávot és ütemezést kap.

2026. okt. 19. – 23. 43. HÉT
  
HÉTFŐ19 10 szabad
KEDD20 11 szabad
SZERDA21 12 szabad
CSÜT.22 13 szabad
PÉNTEK23 13 szabad
08:00
09:00
10:00
11:00
EBÉDSZÜNET 12:00–13:00
13:00
14:00
15:00
16:00
szabad foglalt kiválasztva · Europe/Budapest · 30 perc
IDŐPONTVálasszon egy szabad sávot a naptárból




VISSZAIGAZOLÁS E-MAILBEN · NAPTÁRBEJEGYZÉS
LEMONDÁS EGY KATTINTÁSSAL A LEVÉLBŐL
Fel az oldal tetejéreAz oldal megosztása

#szerveroldali követés #GA4 #server-side tracking #konverziómérés