Server-side tracking sGTM-mel: A 100 milliós magyar webshopok kötelező szintlépése

SEO Cím: Server-Side Tracking Bevezetése Google Tag Managerrel: Útmutató Magyar Webáruházaknak

Meta leírás: Hogyan akadályozza meg a szerveroldali mérés (sGTM) a konverziós adatok 30%-os elvesztését? Gyakorlati útmutató, bevezetési költségek és magyar esettanulmány webshopoknak.

Ha összeveti a Google Analytics 4 (GA4) tranzakciós adatait az ERP-rendszerével (legyen az Billingo, Számlázz.hu, vagy az UNAS/Shoprenter belső adminisztrációja), egyértelmű, 20% és 35% közötti hiányt fog tapasztalni. Ez a szakadék nem egy átmeneti mérési hiba vagy egy rosszul beállított tag eredménye, hanem a kliensoldali (böngészőalapú) mérések strukturális összeomlása. A böngészőből futó követőkódok kora lejárt; a hirdetésblokkolók, a Safari ITP (Intelligent Tracking Prevention) algoritmusa és a Chrome harmadik féltől származó cookie-kat korlátozó lépései miatt a magyar webáruházak vakon égetik el a PPC-büdzséjük harmadát a félreoptimalizált hirdetési algoritmusokban.

A magyar e-commerce piac szereplőinek többsége még mindig abban a hitben él, hogy a kliensoldali Google Tag Manager (GTM) és a Meta Pixel tökéletesen végzi a dolgát. A valóság ezzel szemben az, hogy a mérések pontossága exponenciálisan romlik. A Safari mobilböngésző piaci részesedése a vásárlóerőben erős magyar fogyasztók körében (különösen a 25 000 Ft feletti kosárértékű, prémium szegmensekben) gyakran meghaladja az 50%-ot. Mivel az Apple ITP az első feles (first-party) sütik élettartamát is 1-7 napra korlátozza, a 30 napos attribúciós ablakok teljesen hiteltelenné váltak.

Ha egy felhasználó hétfőn rákattint egy 450 Ft-os CPC-vel futó Meta hirdetésre, majd a következő kedden közvetlen látogatásként (Direct) vásárol 35 000 Ft értékben, a Meta algoritmusa nem fogja megkapni a konverziós visszacsatolást. Az eredmény? A hirdetési rendszerek nem tanulnak, a ROAS látszólag csökken, a marketinges pedig leállítja a valójában profitot termelő kampányokat.

Az iparági konszenzus szerint a szerveroldali mérés (Server-Side Tracking – SST) bevezetése nem egy opcionális technológiai fejlesztés, hanem a túlélés záloga. Azok a hazai webshopok, amelyek nem váltanak át szerveroldali Google Tag Manager (sGTM) infrastruktúrára, fokozatosan elveszítik a versenyképességüket az olyan, adatalapon optimalizáló óriásokkal szemben, mint az Alza, az eMAG vagy a nemzetközi Shein és Temu, amelyek tízmillió eurós büdzséket futtatnak tűpontos szerveroldali adatokkal.

A hagyományos mérési módszerek során a böngésző közvetlenül küld adatokat a Google, a Meta, a TikTok vagy a Hotjar szervereinek. Ezt a folyamatot a böngészők és a felhasználói kiegészítők rendkívül egyszerűen blokkolják.

Magyarországon a Brave böngésző és a különböző adblocker bővítmények (például az AdBlock Plus vagy az uBlock Origin) használata a fiatalabb, tech-szenzitív és magasabb jövedelmű vásárlók (különösen a 18-35 év közötti férfiak) körében eléri a 28-32%-ot. Ezek a szoftverek egyszerűen blokkolják a `gtm.js` és a `fbevents.js` fájlok letöltődését. Ha a script be sem töltődik, a látogatásról, a kosárba helyezésről és a vásárlásról semmilyen információ nem jut el a hirdetési rendszerekhez.

A modern PPC kampányok (mint a Google Performance Max vagy a Meta Advantage+ Shopping Campaigns) szinte kizárólag a konverziós adatok sűrűségére és minőségére támaszkodnak. Amikor a böngésző elrejti a vásárlások 25%-át, a hirdetési algoritmusok hibás adatokból próbálnak mintázatokat felismerni.

Véleményem szerint a magyar marketingügynökségek legnagyobb bűne, hogy amikor a ROAS csökkenését tapasztalják, azonnal a kreatívokat vagy a célzást kezdik el eszeveszetten cserélgetni, miközben az igazi probléma az adatinfrastruktúra hiányosságaiban rejlik. Ha rossz az adatbeáramlás, a világ legjobb kreatívja is elbukik a gépi tanulási fázisban.

A szerveroldali mérés során a böngésző nem a hirdetési hálózatoknak küldi az adatokat, hanem a webáruház saját domainje alatt futó mérőszervernek (például az `sst.webshopom.hu` aldomainnek). Mivel a kérések ugyanarra a domainre futnak be, ahonnan a webshop is kiszolgálja a tartalmat, az adblockerek és a böngészők adatvédelmi algoritmusai nem tudják különbséget tenni a mérési adatok és a funkcionális weboldal-elemek között.

---

```

[ Felhasználó Böngészője ]

│

│ (First-Party adatokküldése: sst.webshopom.hu)

▼

[ sGTM Szerver (Stape.io / Google Cloud) ]

│

├────────────────────────┼────────────────────────┐

▼ ▼ ▼

[ Google Analytics 4 ] [ Meta CAPI Szerver ] [ Egyéb API-k (TikTok, Pinterest) ]

```

A szerveroldali méréshez szükség van egy szerverre, amely fogadja, feldolgozza és továbbítja az adatokat. A Google hivatalos ajánlása a Google Cloud Platform (GCP) App Engine használata. Bár ez a leginkább skálázható megoldás, egy átlagos, havi 100 000 - 300 000 munkamenetet bonyolító magyar webshop számára indokolatlanul drága és komplex lehet.

A GCP alapbeállításon (minimum 3 darab szerverpéldány a magas rendelkezésre állás miatt) havonta körülbelül 120-150 USD (kb. 43 000 - 54 000 Ft) költséget generál, ami Black Friday vagy szezonális csúcsok idején a többszörösére is megugorhat.

Ezzel szemben az európai fókuszú Stape.io hosting szolgáltató egy kiváló alternatíva. A Stape lényegében egy leegyszerűsített felületet biztosít a szerveroldali GTM konténerek futtatásához, saját szerverparkkal.

• Egy havi 10 000-50 000 látogatót fogadó magyar kiswebshop (pl. egy kézműves ékszerbolt vagy egy niche B2B kereskedő) akár ingyen vagy a 10 USD-s (kb. 3 600 Ft/hó) csomaggal is kényelmesen elboldogul.
• Egy nagyobb, havi 500 000 eseményt generáló e-commerce szereplő (pl. egy 500M HUF feletti éves árbevételű divat webáruház) havi 100 USD-s (kb. 36 000 Ft/hó) költségből meg tudja oldani a teljes szerveroldali infrastruktúrát.

Az SST beállításának legfontosabb lépése a DNS rekordok konfigurálása. Ha nem állítunk be saját aldomaint, és a Stape vagy a Google alapértelmezett URL-jét használjuk, az egész projekt értelmét veszti, hiszen a böngészők harmadik féltől származóként fogják azonosítani az adatokat.

A folyamat során a webáruház tárhelyszolgáltatójánál (pl. Tarhely.park, Rackhost, DotRoll) be kell állítani egy új CNAME rekordot:

| Rekord típus | Forrás (Host) | Cél (Value) | TTL |

| :--- | :--- | :--- | :--- |

| CNAME | `sst.webshopom.hu` | `sst-configured-endpoint.stape.io` | 3600 |

Ez a konfiguráció biztosítja, hogy a mérőkódok betöltése és az adatok küldése az `sst.webshopom.hu` domainen keresztül történjen. Mivel ez megegyezik a fő domainnel (`webshopom.hu`), az adatok első fél általinak minősülnek, így a sütik élettartamát a Safari nem fogja drasztikusan lerövidíteni 24 órára.

---

Nézzünk meg egy valós, anonimizált esetet a hazai piacról. A "TrendiDivat Kft." egyedi ruházati termékeket értékesít, éves szinten 350 millió Ft árbevétellel. Átlagos kosárértékük (AOV) 18 500 Ft. Havonta átlagosan 3 millió Ft-ot költenek Meta (Facebook/Instagram) hirdetésekre és 2 millió Ft-ot Google Ads (főként PMax) kampányokra.

A cégvezetés és a marketinges csapat azt tapasztalta, hogy míg az UNAS webáruház belső adminisztrációja havi 1 500 sikeres tranzakciót regisztrált, addig a Google Analytics 4-ben csak 1 120 vásárlás jelent meg, a Meta hirdetéskezelő pedig mindössze 950 konverziót tudott közvetlenül összekötni a hirdetésekkel.

A Meta ROAS mutatója papíron 2,4-es szinten állt, ami a magas beszerzési árak mellett éppen csak az önköltségi szintet érte el. A marketing vezető a büdzsé drasztikus csökkentését fontolgatta, mert a számok alapján a hirdetések nem hozták meg a várt profitot.

A mérések rendbetételére egy 3 hónapos projektet indítottunk el. A következő lépéseket hajtottuk végre:

• sGTM konténer létrehozása és hosztolása Stape.io platformon keresztül (üzembiztos, havi 20 USD-s csomag).
• CNAME rekord beállítása: `analytics.trendidivat.hu` -> Stape szerver.
• Meta Conversions API (CAPI) integráció: A szerveroldali GTM-en keresztül beállítottuk a hibrid mérési modellt. A kliensoldali Pixel és a szerveroldali CAPI egyszerre küldi az adatokat, egy egyedi dedikált azonosító (`event_id`) használatával, ami lehetővé teszi a Meta számára az átfedések (duplikációk) kiszűrését.
• Felhasználói adatok biztonságos továbbítása: A szerveroldalon keresztül SHA-256 hash-eléssel ellátott ügyféladatokat (e-mail cím, telefonszám, város) kezdtünk el küldeni a Metának a vásárlási eseményekkel együtt. Ez drasztikusan javította az Event Match Quality (EMQ) pontszámot.

Az SST bevezetése utáni harmadik hónap végén az adatok a következőképpen alakultak:

| Metrika | Bevezetés előtt (Kliensoldal) | Bevezetés után (SST + CAPI) | Változás (%) |

| :--- | :--- | :--- | :--- |

| Mért vásárlások száma (GA4) | 1 120 | 1 455 | +29,9% |

| Meta attribúciós vásárlások | 950 | 1 310 | +37,8% |

| Meta Event Match Quality (EMQ) | 4.2 / 10 | 8.8 / 10 | +109,5% |

| Meta bejelentett ROAS | 2.4 | 3.5 | +45,8% |

| Tényleges CPA (HUF) | 3 157 Ft | 2 290 Ft | -27,4% |

```

Konverziós adatok pontossága a webshop adminisztrációhoz képest (100%):

Kliensoldali GA4: [████████████░░░░░] 74%

Szerveroldali sGTM: [████████████████░] 97%

```

Azzal, hogy a Meta algoritmusa 37%-kal több konverziós eseményt látott, sokkal pontosabban tudta azonosítani a vásárlókat. Nem változtattunk a kreatívokon, sem a célzási beállításokon, csupán az algoritmus adatellátása javult.

A hatékonyabb optimalizálásnak köszönhetően a Meta kampányok CPA-ja (konverziónkénti költség) 3 157 Ft-ról 2 290 Ft-ra csökkent. A havi 3 millió forintos költés mellett ez azt jelentette, hogy korábban 950 vásárlást hozott a rendszer, míg az SST után ugyanebből a keretből 1 310 vásárlás realizálódott.

Ez havi szinten plusz 360 vásárlást jelentett. 18 500 Ft-os kosárértékkel és 35%-os árréssel számolva ez havonta 2 331 000 Ft többlet profitot eredményezett a TrendiDivat Kft.-nek, miközben a feleslegesen elégetett ad-spend mértéke szinte nullára csökkent. Az éves szinten több mint 25 millió forintos profitnövekedést jelent egy alig havi 7 200 Ft-os sGTM szerverköltség mellett.

---

Gyakori hibák: Amit a magyar ügynökségek 80%-a elront

Bár egyre több magyar digitális ügynökség és szabadúszó veszi fel a portfóliójába a szerveroldali mérések beállítását, a technikai implementáció minősége sok esetben kritikus sebekből vérzik. Ha az alábbi hibák bármelyikét elköveti, az SST nemhogy nem segít, de kifejezetten rombolni fogja a kampányai teljesítményét.

A leggyakoribb hiba, hogy a hibrid követés beállításakor (amikor a böngésző és a szerver is küld eseményeket a Metának vagy a Google-nek) elmarad a megfelelő deduplikáció. Ha a Meta Pixel és a Meta CAPI is elküldi a `Purchase` eseményt, de nem egyezik meg az `event_id` paraméterük, a Meta rendszere két külön vásárlásként fogja elszámolni őket.

Ez a hiba kezdetben hamis eufóriát okozhat a marketingesnek, hiszen a ROAS hirtelen megduplázódik a hirdetéskezelőben. Azonban az algoritmus gyorsan rájön a turpisságra, amikor a pénzügyi valóság (a bankszámlára érkező összeg) nem találkozik a fiktív adatokkal.

Mindig ellenőrizze a Meta Event Managerben, hogy a deduplikációs ráta eléri-e a 98-100%-ot! Ehhez a kliensoldali és a szerveroldali eseményeknél is kötelező pontosan ugyanazt az `event_id`-t (pl. a megrendelés azonosítóját vagy egy egyedi generált stringet) továbbítani.

A GDPR (és a hazai NAIH) szabályozás értelmében a felhasználók személyes adatait (e-mail cím, telefonszám, név, IP-cím) nem szabad nyers formátumban átadni harmadik félnek, és különösen nem tengerentúli szervereknek, hozzájárulás nélkül.

Sok "csináld magad" vagy hanyagul konfigurált sGTM rendszer nyers szövegként (plain text) továbbítja az e-mail címeket a szerveroldali tageken keresztül. Ez nemcsak adatvédelmi szempontból aggályos, de a hirdetési rendszerek is elutasíthatják az ilyen adatokat.

A személyes adatokat a küldés előtt SHA-256 algoritmussal kell titkosítani (hashing) még a kliensoldalon, vagy a szervernek kell elvégeznie ezt a transzformációt a továbbítás előtt.

```json

// HIBÁS, jogsértő adatküldés:

{

"event_name": "Purchase",

"user_data": {

"email": "kovacs.janos@gmail.com"

}

}

// HELYES, GDPR-kompatibilis adatküldés:

{

"event_name": "Purchase",

"user_data": {

"email": "e1f13b659c9d4b53298c39cfc166dcfdf425310b80ef11a681c6fb6168e9863a"

}

}

```

Ha a szerveroldali mérést egy instabil, alulméretezett szerveren futtatja, a szerver összeomolhat, amikor hirtelen megugrik a látogatószám. Egy nagyobb hazai webshopnál a Black Friday vagy egy karácsonyi kampány indítása során a normál forgalom tíz- vagy húszszorosa is bezúdulhat pár óra alatt.

Ha a szerver nem bírja a terhelést, 503-as vagy 504-es hibakódot ad vissza, és az adatok teljesen elvesznek. Sőt, ha a kliensoldali kódok szinkron módon várnak a szerver válaszára, a webáruház betöltési sebessége is drasztikusan lelassulhat, ami közvetlen bevételkiesést okoz.

Ezért elengedhetetlen az aszinkron betöltés konfigurálása és a szerver automatikus skálázásának (Auto-scaling) beállítása, vagy a Stape esetében a megfelelő forgalmi csomag kiválasztása még az akciók megkezdése előtt.

---

Ha el akarja kerülni a fenti hibákat, és szeretné maximalizálni a hirdetési kampányai hatékonyságát, kövesse ezt a strukturált, tesztelt implementációs folyamatot.

Mielőtt bármilyen kódhoz hozzányúlna, határozza meg a jelenlegi adatveszteség mértékét. Hasonlítsa össze az elmúlt 30 nap webshop adminisztrációs adatait (összes megrendelés száma) a GA4-ben és a Meta Ads Managerben látható számokkal. Ha az eltérés meghaladja a 15%-ot, az SST bevezetése azonnali, kritikus prioritású feladat.

Hozza létre az aldomaint a tárhelyszolgáltatójánál (pl. `sst.sajatwebshopom.hu`). Állítsa be a CNAME rekordot a kiválasztott szerver (javasoljuk a Stape.io-t az európai szerverhelyszínek és a kedvező árazás miatt) felé. Várja meg a DNS propagációt, ami általában 1-4 órát vesz igénybe Magyarországon.

A Google Tag Manager fiókjában hozzon létre egy új konténert, de a típusánál a Server opciót válassza. Az új konténer beállításaiban adja meg a saját szerverének URL-jét (`https://sst.sajatwebshopom.hu`).

Módosítsa a meglévő, hagyományos (Web) GTM konténerét. A GA4 konfigurációs tagben (vagy a Google Tag-ben) állítsa be a `server_container_url` paramétert, és értéknek adja meg a saját sGTM URL-jét. Ettől a pillanattól kezdve a böngészőből futó Google Tag nem a Google szervereinek küldi az adatokat, hanem a saját proxy szerverének.

A szerveroldali GTM konténerben telepítse a hivatalos Meta Conversions API tag-et. Konfigurálja az események leképezését (Page View, View Content, Add To Cart, Initiate Checkout, Purchase).

• Győződjön meg arról, hogy az `event_id` paramétert mind a webes Meta Pixel, mind a szerveroldali CAPI tag megkapja, és azok megegyeznek.
• Konfigurálja az ügyfél-paraméterek (User Data) biztonságos, SHA-256 hash-elt továbbítását a jobb egyeztetési arány elérése érdekében.

Használja a GTM Web és Server konténerének Preview (előnézet) módját egyszerre. Hajtson végre egy tesztvásárlást a webáruházban. Ellenőrizze, hogy:

• Minden esemény sikeresen megérkezik-e a szerveroldalra (200-as státuszkód).
• A Meta Event Manager jelzi-e a sikeres deduplikációt.
• Nincsenek-e nyers, titkosítatlan személyes adatok a kimenő hálózati kérésekben.

Publikálja mindkét GTM konténert. A következő 14 napban kövesse figyelemmel a GA4 és a Meta Ads adatokat. A cél az, hogy a Meta Event Match Quality (EMQ) pontszáma a korábbi alacsony szintről legalább 8.0 fölé emelkedjen, és a GA4-ben mért tranzakciók száma megközelítse a tényleges (ERP-ben látható) vásárlások 95-98%-át.