Server-side GTM magyar webshopoknak: Megéri havi 50-100 ezer forint plusz költséget a pontosabb mérés?

A magyar e-commerce szektorban az elmúlt két évben csendes, de kíméletlen technológiai mészárlás zajlik: a hagyományos, böngészőalapú (client-side) mérések pontossága átlagosan 25-35%-kal esett vissza. Miközben a legtöbb hazai webshop tulajdonosa abban a hitben ringatja magát, hogy a Google Consent Mode v2 zöld pipái mögött minden mérési adatuk biztonságban van, a valóságban a Google Ads és Meta algoritmusok vakon repülnek, ami közvetlenül égeti el a marketingbudgetet. Az adblokkolók terjedése, az iOS Safari ITP (Intelligent Tracking Prevention) szigorításai, valamint a böngészők harmadik féltől származó cookie-kat (third-party cookies) kivezető lépései miatt a régi mérési módszertan végérvényesen összeomlott. Aki ma kizárólag kliensoldali Google Tag Manager (GTM) kódokra alapozza a PPC kampányait, az nem optimalizál, hanem tippel.

A magyar online kiskereskedelmi piacon 2026-ra a technológiai felkészültség vált a növekedés és a túlélés első számú zálogává. A hazai prémium vásárlóerő jelentős része – a magasabb kosárértékkel rendelkező, budapesti és megyeszékhelyi célcsoportok – körében az iOS (Safari) eszközök aránya eléri a 35-42%-ot. Ezen az operációs rendszeren a Safari ITP technológiája a kliensoldalon beállított cookie-k élettartamát mindössze 1-7 napra korlátozza, amennyiben a látogató valamilyen hirdetési platformról (például `gclid` vagy `fbclid` paraméterrel) érkezik.

Ez a gyakorlatban azt jelenti, hogy ha egy vásárló hétfőn rákattint egy OTP SimplePay integrációt használó magyar webshop Meta hirdetésére, de csak a következő kedden tér vissza közvetlenül az oldalra és vásárol, a kliensoldali GA4 és Meta Pixel már képtelen lesz összekötni a konverziót az eredeti hirdetéssel. A kampány sikertelennek fog tűnni, a Meta algoritmus nem kapja meg a szükséges visszacsatolást, a hirdető pedig leállítja azt a kreatívot, ami valójában profitot termelt.

Súlyosbítja a helyzetet a hálózati szintű blokkolás (pl. Brave böngésző, uBlock Origin, DNS-alapú szűrők, mint a Pi-hole vagy az AdGuard), amelyek a magyar internetezők körében már 18-22%-os penetrációval bírnak. Ezek a szoftverek kapásból blokkolják a `google-analytics.com` vagy a `connect.facebook.net` domainek felé induló kliensoldali kéréseket.

Ha egy 500 millió HUF éves árbevételű webshop ezen mérési pontatlanságok miatt csak 15%-os mérési veszteséggel működik, az éves szinten 75 millió HUF láthatatlan forgalmat jelent, amelyet a hirdetési rendszerek nem tudnak attribúciós csatornához rendelni. Ennek következtében a Target CPA (akvizíciós költség) alapú intelligens ajánlattételi stratégiák eltorzulnak: a Google Ads és a Meta Ads drágább liciteket fog alkalmazni, ami a magyar CPC árak (divatban 80-150 HUF, építőiparban vagy B2B-ben akár 300-600 HUF) mellett villámgyorsan felemészti a profitmarzsot. A server-side tracking (SST) nem egy kényelmi funkció, hanem az egyetlen technológia, amellyel a méréseket visszaterelhetjük a saját, ellenőrzött infrastruktúránkba, függetlenítve magunkat a böngészők önkényes korlátozásaitól.

---

A hagyományos, kliensoldali követés során a látogató böngészője közvetlenül kommunikál a külső marketingplatformok (Google, Meta, TikTok) szervereivel. Ez a modell teljesen kiszolgáltatott a böngésző biztonsági beállításainak és a hálózati szűrőknek.

```

Kliensoldali mérés (Hagyományos):

[Látogató Böngészője] -- (Blokkolható script) --> [Meta / Google Szerverek]

-- (Safari ITP törli a cookie-t 1-7 nap után)

```

A szerveroldali mérés (Server-Side Tracking) ezzel szemben egy biztonsági és adatkezelési pufferzónát iktat be a látogató böngészője és a marketingplatformok közé. A böngésző kizárólag a webshop saját aldomainjével kommunikál (például a `tracking.webshopom.hu` címen futó szerverrel), ahonnan az adatok a háttérben, biztonságos, szerver-szerver közötti API hívásokon keresztül jutnak el a célszervezetekhez.

```

Szerveroldali mérés (SST):

[Látogató Böngészője] -- (Saját domain kérés: tracking.webshopom.hu) --> [Saját Cloud Szerver (GTM)]

|

(Szerver-Szerver API)

|

v

[Meta CAPI / GA4 Szerverek]

```

Amikor egy felhasználó uBlock Origin kiterjesztést használ, a böngészője nem engedi letöltődni a Meta `fbevents.js` fájlját. Az esemény meg sem történik a Meta számára. Ha azonban szerveroldali mérést használunk, a böngészőből nem a Meta felé indul a hívás, hanem a saját `tracking.webshopom.hu/collect` végpontunkra. Mivel ez megegyezik a főoldal domainjével, az adblokkolók nem akadályozhatják meg a kommunikációt anélkül, hogy magát a weboldalt is használhatatlanná tennék.

A Safari ITP ellen a védekezést a cookie-k elhelyezésének módja jelenti. A JavaScript segítségével (kliensoldalon) írt cookie-kat a Safari könyörtelenül törli. Ha viszont a szerveroldali GTM-ünk a HTTP válasz fejlécében (HTTP `Set-Cookie` header), `HttpOnly` és `Secure` flaggökkel ellátva küldi vissza a követési azonosítót (mint az `_ga` vagy `_fbp`), akkor a böngésző ezt első feles (First-Party) adatként kezeli, és az élettartama akár 1-2 év is lehet.

A szerveroldali követés legfontosabb technikai feltétele, hogy a szerver container ne egy idegen URL-en fusson, hanem a webshop saját domain struktúrájában.

• DNS konfiguráció: Be kell állítani egy CNAME rekordot a domain regisztrátornál (pl. Dotroll, Rackhost, Tarhely.hu). A `tracking.webshop.hu` aldomaint rá kell irányítani a szerveroldali konténerünket hosztoló felhőszolgáltatás (pl. Google Cloud Platform vagy Stape) IP-címére vagy egyedi URL-jére.
• Saját IP-cím: Prémium szinten törekedni kell arra, hogy a szerver dedikált IP-címmel rendelkezzen, amely megegyezik a webshop tárhelyének IP-tartományával (vagy legalábbis földrajzilag azonos helyen van), mivel a legújabb böngésző-motorok már az IP-címek eltérését is vizsgálják a first-party státusz megítélésekor.
• SSL tanúsítvány: Biztosítani kell a folyamatos, automatikusan megújuló SSL (Let's Encrypt) tanúsítványt az aldomainre, különben a böngészők biztonsági okokból blokkolni fogják a HTTPS kéréseket.

---

A szerveroldali mérés bevezetése nem ingyenes. Hardveres erőforrást (felhő alapú szervereket) igényel, és komoly fejlesztői, elemzői szakértelmet feltételez. Vizsgáljuk meg a költségeket a hazai piacon jellemző két legnépszerűbb alternatíva tükrében.

A Google Tag Manager Server Container hivatalosan a Google Cloud Platform (GCP) App Engine szolgáltatására épül.

| Költségtényező | Google Cloud Platform (GCP) | Stape.io (SST-re optimalizált hosting) |

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

| Alapértelmezett konfiguráció | Min. 3 flexibilis App Engine példány (magas rendelkezésre állás) | Cloud virtuális szerver dedikált proxy-val |

| Havi fix költség (HUF) | ~ 44 000 - 55 000 HUF ($120 - $150 / hó) | ~ 7 300 HUF ($20 / hó - 500k kérésig) vagy ~ 36 000 HUF ($100 / hó - 5M kérésig) |

| Ingyenes tesztidőszak | Van (1 tesztpéldány, korlátozott erőforrással) | Van (10 000 kérés/hó-ig teljesen ingyenes) |

| Technikai bonyolultság | Magas (GCP számlázás, IAM jogosultságok, skálázási szabályok) | Alacsony (1-klikkes GTM integráció, egyszerű DNS beállítás) |

| Adatvédelmi megfelelőség | EU-n kívüli szerverek kockázata (ha rosszul konfigurálják) | EU-székhelyű szerverek választhatóak (GDPR kompatibilis) |

A magyar kkv szektor számára (50 millió és 1 milliárd HUF közötti éves árbevétel) a Stape.io jelenti a racionális és költséghatékony belépőt. Egy átlagos, havi 80 000 - 150 000 látogatót kezelő webshop kényelmesen belefér a $20-os (kb. 7300 HUF) Pro csomagba. Ezzel szemben a GCP minimális éles konfigurációja (legalább 3 instanciával a terheléselosztás miatt) havi 45 000 HUF feletti fix költséget jelent, ami egy kisebb webshopnál azonnal elviszi a mérési pontosságból származó marginális profitnövekedést.

A piacon jelenleg hatalmas a szórás az SST implementáció árazásában. Sokan "házi barkács" módszerekkel, hiányos paraméterezéssel próbálják eladni a szolgáltatást, ami hosszú távon veszélyes hiba.

• Alapszintű implementáció (SaaS platformokhoz, pl. Shoprenter, Unas, Shoptet):

Díj:* Egyszeri 150 000 - 300 000 HUF.

Tartalom:* Stape.io setup, DNS beállítás, GA4 és Meta CAPI alap események (PageView, ViewContent, AddToCart, Purchase) szerveroldali átirányítása, alapszintű deduplikáció.

• Egyedi fejlesztésű webshopok (WooCommerce, Shopify egyedi sablonnal, custom Laravel/React):

Díj:* Egyszeri 350 000 - 750 000 HUF.

Tartalom:* dataLayer struktúra optimalizálása, egyedi események lefejlesztése, user-data paraméterek (hashed email, telefon, lakcím) biztonságos átadása, kiterjesztett e-commerce mérések (Refund, Checkout Steps, Promo Clicks).

• SST karbantartási és audit díjak:

Díj:* Havi 30 000 - 80 000 HUF vagy óradíjas elszámolás (átlagosan 25 000 - 45 000 HUF/óra).

Tartalom:* API változások követése (pl. Meta Graph API frissítések), hibás eseményazonosítók javítása, szerveroldali erőforrások monitorozása.

Szakmai vélemény és kritika: Ha egy magyar szabadúszó vagy ügynökség 50 000 Ft-ért ajánlja a "teljes körű szerveroldali GTM bevezetést", azonnal utasítsd vissza. Ennyiért kizárólag egy sablon importálását végzik el, anélkül, hogy ellenőriznék a deduplikációt, a szerveroldali hibakódokat vagy az egyedi adatvédelmi követelményeket. Egy rosszul beállított SST több kárt okoz a kampányokban (pl. duplikált vásárlások mérése miatti hibás büdzsé-allokáció), mint a mérés teljes hiánya.

---

A Meta Conversions API (CAPI) bevezetésekor a legfontosabb mérőszám, amelyet folyamatosan figyelni kell, az Event Match Quality (EMQ). Ez a pontszám (egy 1-től 10-ig terjedő skálán) azt mutatja meg, hogy a Meta mennyire képes az Ön szerveréről érkező konverziós eseményeket összekötni egy valós Facebook vagy Instagram felhasználói profillal.

Az alacsony EMQ pontszám (például 3.5 - 5.0) azt jelenti, hogy a Meta nem tudja, ki vásárolt, így nem tudja a hirdetéseket az optimális célcsoporthoz igazítani. A cél a 8.0 feletti EMQ pontszám elérése.

| Esemény paraméter | Kliensoldali küldés | Szerveroldali küldés (SST) | Biztonsági szint (SHA-256 hash) | Hatása az EMQ pontszámra |

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

| Email cím (`em`) | Nem ajánlott / tiltott plain textként | Kötelező (szerveroldalon hashelve) | Igen | Rendkívül magas (+2.5 pont) |

| Telefonszám (`ph`) | Nehézkes / ritkán pontos | Kötelező (szerveroldalon hashelve) | Igen | Magas (+1.8 pont) |

| IP-cím (`client_ip_address`) | Automatikus (de adblokkolók elrejtik) | Kötelező (a szerver adja át közvetlenül) | Nem szükséges | Közepes (+0.8 pont) |

| Böngésző ujjlenyomat (`client_user_agent`) | Automatikus (de csonkított) | Kötelező (teljes, nyers adatként) | Nem szükséges | Közepes (+0.5 pont) |

| Vezetéknév / Keresztnév (`ln` / `fn`)| Kliensoldalon adatvédelmi kockázat | Kötelező (szerveroldalon hashelve) | Igen | Közepes (+1.2 pont) |

| Külső felhasználói ID (`external_id`)| Csak bejelentkezett felhasználónál | Webshop belső DB azonosító / cookie ID | Nem szükséges | Rendkívül magas (+2.0 pont) |

A sikeres integráció alapja a hibrid mérés megvalósítása. Ez azt jelenti, hogy mind a kliensoldali Meta Pixel, mind a szerveroldali Meta CAPI aktív. Ahhoz, hogy a Meta ne számolja duplán a konverziókat, tökéletes deduplikációra van szükség.

Ennek menete:

• Minden eseményhez (pl. `purchase`) generálni kell egy teljesen egyedi azonosítót a webshop backendjében vagy a kliensoldali GTM-ben (pl. egy `event_id` változót, ami megegyezik a rendelésszámmal: `ORDER_2026_89432`).
• Ezt a pontosan azonos `event_id`-t kell elküldeni a kliensoldali Meta Pixelnek és a szerveroldali Meta CAPI-nak is.
• A Meta szerverei, amikor megkapják mindkét irányból az adatot, az `event_id` és az `event_name` egyezősége alapján törlik a szerveroldali eseményt, és csak a kliensoldalit tartják meg (ha az sikeresen beérkezett). Ha a kliensoldali kérést blokkolta egy adblokkoló, a Meta automatikusan a szerveroldali eseményt használja fel. Így a mérési pontosságunk garantáltan 100%-os lesz, duplikáció nélkül.

---

A következő valós adatokon alapuló esettanulmány egy hazai divat és kiegészítő webáruház (nevezzük TrendiDivat.hu-nak) adatait mutatja be. A webshop egyedi Shopify motoron fut, és a magyar piac mellett Romániába és Szlovákiába is szállít.

• Éves árbevétel: 450 000 000 HUF
• Átlagos kosárérték (AOV): 16 500 HUF
• Havi hirdetési budget (Meta + Google Ads): 4 500 000 HUF
• Probléma: Az iOS látogatók aránya meghaladta a 40%-ot. A Shopify backend 1850 vásárlást mutatott egy adott hónapban, miközben a GA4 csak 1320 vásárlást regisztrált (28.6%-os mérési hiány). A Meta Ads kampányok ROAS mutatója a korábbi 4.2-es szintről 2.1-re esett vissza, mert a hirdetési rendszer nem látta a konverziók jelentős részét, így nem tudott hatékonyan optimalizálni. A CPC árak az eltorzult licitálási algoritmus miatt 35%-kal emelkedtek.

A cég felkért egy hazai analytics ügynökséget az átállás lebonyolítására.

• Hosting platform: Stape.io (Business csomag, havi $100 / kb. 36 000 HUF a magas kérésszám és a többnyelvű aldomainek miatt).
• Egyedi aldomain beállítása: `metrics.trendidivat.hu` (CNAME rekord irányítása a Stape európai szerverére).
• Kliensoldali átalakítás: A meglévő Shopify GTM konténer átírása úgy, hogy az összes GA4 eseményt a `metrics.trendidivat.hu` felé küldje.
• Szerveroldali konfiguráció:

* GA4 kliens beállítása a szerveroldali GTM-ben.

* Meta Conversions API tag telepítése.

* Felhasználói adatok (email cím, telefonszám) SHA-256 alapú hashelése szerveroldali transzformációval (mielőtt az adatok elhagynák az EU-t).

* `Set-Cookie` HTTP fejlécek beállítása, amely a GA4 `_ga` cookie élettartamát kliensoldali 7 napról szerveroldali 2 évre terjesztette ki Safari böngészőben is.

```

Mérési folyamat TrendiDivat.hu esetén:

• Vásárló leadja a rendelést a Shopify oldalon -> GTM dataLayer push.
• A kliensoldali Google Tag elküldi az adatokat titkosított HTTPS kéréssel a metrics.trendidivat.hu címre.
• A szerveroldali GTM fogadja az adatot, elvégzi az email cím SHA-256 hashelését.
• A szerveroldali GTM elküldi a Purchase eseményt a GA4-nek és a Meta CAPI-nak egyaránt.
• Visszaküldi a HTTP Set-Cookie választ a böngészőnek a cookie-k megújításával.

```

A szerveroldali mérés bevezetése után drasztikus változások történtek a hirdetési fiókokban:

| Mérőszám | Bevezetés előtt | Bevezetés után (90 nap) | Változás %-ban |

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

| Regisztrált konverziók (GA4 vs. Backend) | 71.4% egyezőség | 98.2% egyezőség | + 26.8% pontosság |

| Meta Ads Event Match Quality (Purchase) | 4.8 / 10 | 8.9 / 10 | + 85.4% minőségjavulás |

| Átlagos CPC (Meta Ads) | 118 HUF | 86 HUF | - 27.1% költségcsökkenés |

| Hirdetési megtérülés (Blended ROAS) | 2.1x | 3.8x | + 80.9% hatékonyság |

| Havi hirdetési pazarlás csökkenése | ~ 950 000 HUF | < 50 000 HUF | ~ 900 000 HUF megtakarítás |

A Meta algoritmus az EMQ pontszám növekedésével végre pontosan be tudta azonosítani a tényleges vásárlókat, és képes volt hasonló tulajdonságokkal bíró Lookalike (LAL) és Advantage+ célzásokat építeni. A kampányok hatékonysága úgy növekedett, hogy a havi hirdetési büdzsé változatlan maradt. Az egyszeri 450 000 HUF implementációs és a havi 36 000 HUF szerverüzemeltetési díj kevesebb mint 2 hét alatt teljesen megtérült.

---

Gyakori hibák: Hogyan bukj el 500 000 Ft-ot és a domained reputációját?

Bár az SST előnyei vitathatatlanok, a szakszerűtlen kivitelezés súlyos anyagi és jogi következményekkel járhat. Az alábbi három hiba a leggyakoribb a magyar e-commerce szférában.

Sokan aktiválják a Meta CAPI-t anélkül, hogy gondoskodnának a megfelelő `event_id` alapú deduplikációról. Ha a szerveroldali és a kliensoldali események egyszerre futnak be dedikált azonosító nélkül, a Meta rendszere két külön vásárlásként fogja kezelni őket.

Példa a katasztrófára: Ha a vásárló vesz egy 20 000 HUF értékű terméket, a Meta Ads Managerben 40 000 HUF konverziós érték jelenik meg. A marketinges örül, hogy a ROAS az egekben van, így megduplázza a kampány büdzséjét. Valójában azonban a cég veszteséget termel, mert a hirdetési fiók fals, duplikált adatok alapján skálázott fel. Mindig ellenőrizze a Meta Eseménykezelőben (Events Manager), hogy a "Deduplication Rate" (Deduplikációs arány) eléri-e a 98-100%-ot!

Az adblokkolók fejlesztői nem hülyék. Ha a szerveroldali méréshez olyan aldomaint használ, mint a `tracking.webshop.hu`, `analytics.webshop.hu` vagy `stape.webshop.hu`, a modern szűrőlisták (pl. EasyList) ezt automatikusan blokkolni fogják reguláris kifejezések (regex) alapján.

• Mit NE tegyen: Ne használjon sablonos elnevezéseket az aldomainnél.
• Helyes megoldás: Használjon ártalmatlan, technikainak tűnő alneveket, például: `engine.webshop.hu`, `secure-gateway.webshop.hu`, vagy egy véletlenszerű karaktersorozatot, mint a `ss-prod-v1.webshop.hu`.

Sokan azt hiszik, hogy mivel a szerveroldali követés láthatatlan a böngésző számára, ott már nem vonatkoznak rájuk az európai és a magyar adatvédelmi (NAIH) szabályok. Ez óriási tévedés, ami több millió forintos bírságot vonhat maga után.

• A hiba: Felhasználói hozzájárulás nélkül elküldeni a hashelt személyes adatokat (email, telefon) a szerverről a Meta vagy a Google számára.
• A szabály: Ha a látogató az oldalon megjelenő cookie banneren (pl. Cookiebot, Consentmo, CookieYes) elutasította a marketing célú sütik használatát, akkor a szerveroldali GTM-ben is szigorúan tiltani kell a hirdetési platformok felé irányuló szerveroldali kéréseket. Az SST nem a jogszabályok megkerülésének eszköze, hanem a méréstechnológiai pontosság helyreállításának fegyvere.

---

Ha szeretné bevezetni a szerveroldali mérést a webáruházában, kövesse ezt a strukturált, tesztelt implementációs folyamatot.

```

[DNS beállítás] -> [Szerver hosting (Stape)] -> [Kliensoldali átirányítás] -> [Szerveroldali Tag-ek] -> [Deduplikáció] -> [NAIH/Consent teszt]

```

Regisztráljon egy Stape.io fiókot (kezdésnek a Free vagy a $20-os Pro csomag tökéletes). Hozzon létre egy új szerveroldali GTM konténert a Google Tag Manager fiókjában, majd másolja ki a konténer konfigurációs kódját (Container Config). Ezt a kódot illessze be a Stape.io felületén létrehozott új container beállításaiba.

A tárhelyszolgáltatója (pl. Dotroll, Tarhely.hu) DNS kezelő felületén adjon hozzá egy új CNAME rekordot:

• Host/Név: `metrics` (vagy az Ön által választott egyedi név, pl. `secure-gtm`)
• Típus: `CNAME`
• Érték/Cél: A Stape.io által biztosított egyedi tartomány cím (pl. `your-container-id.stape.io`).

Várjon 1-4 órát a DNS terjedésére, majd a Stape felületén ellenőrizze az SSL tanúsítvány meglétét.

Nyissa meg a meglévő, kliensoldali GTM konténerét. Keresse meg a Google Tag-et (korábban GA4 Configuration Tag).

A beállításoknál adjon hozzá egy új paramétert:

• Paraméter neve: `server_container_url`
• Érték: `https://metrics.yourwebshop.hu` (a saját, egyedi aldomainje)

Ezzel az összes standard GA4 eseményt átirányította a saját szerverére.

Lépjen be a szerveroldali GTM konténerbe.

• Győződjön meg róla, hogy a Clients fül alatt aktív a "Google Analytics: GA4" kliens. Ez a kliens fogadja a kliensoldali GTM-ből érkező hívásokat.
• Hozzon létre egy új GA4 Tag-et szerveroldalon, amely a beérkező adatokat továbbküldi a valós GA4 szervereknek.
• Telepítse a Meta Conversions API tag-et (letölthető a GTM Template Gallery-ből). Állítsa be a Meta Pixel ID-t és a Meta API Access Token-t (ezt a Meta Events Manager -> Settings fül alatt tudja generálni).

Gondoskodjon róla, hogy a kliensoldali GTM-ből átadott `event_id` (pl. tranzakció azonosító) megegyezzen a szerveroldalon fogadott `event_id` paraméterrel.

A szerveroldali Meta CAPI tagben képezze le a felhasználói adatokat (User Data):

• `user_data.email_address` -> Hashelt email cím
• `user_data.phone_number` -> Hashelt telefonszám

A Stape.io beépített transzformációs szabályai automatikusan elvégzik a SHA-256 hashelést, ha az adatok nem lennének előre titkosítva a kliensoldalon.

Konfigurálja a szerveroldali GTM konténert úgy, hogy az csak akkor indítsa el a Meta CAPI hívást, ha a kliensoldali kérésben szereplő Consent Mode paraméterek engedélyezik azt.

• Ha az `ad_storage` értéke `denied` (elutasítva), a szerveroldali Meta tag-nek nem szabad lefutnia.
• Használja a Google Consent Mode v2 beépített állapotjelzőit (`gcs` és `gcd` paraméterek) a szerveroldali triggerek szabályozásához.

Mielőtt élesítené a konténereket, futtasson le egy tesztvásárlást a GTM Preview módban mind a kliens, mind a szerver oldalon. Ellenőrizze:

• A böngésző hálózati (Network) fülén, hogy a kérések valóban a `metrics.yourwebshop.hu` domainre mennek-e.
• A Meta Events Managerben, hogy a teszt események (Test Events) sikeresen megérkeznek-e mind a böngészőből, mind a szerverről, és a deduplikáció zöld jelzést kapott-e.
• Élesítést követően 7 nappal az Event Match Quality (EMQ) pontszámnak el kell érnie a minimum 8.0-as szintet Purchase eseményeknél, és a mérési eltérésnek a belső adatbázis és a GA4 között 3% alá kell csökkennie.

---

• Meta Title: Szerveroldali Tracking (SST) Útmutató Magyar Webshopoknak 2026
• Meta Description: Hogyan nyerj vissza 25-35% elveszett konverziós adatot? Mélyreható, gyakorlati útmutató a szerveroldali GTM, Meta CAPI és Safari ITP kezeléséhez hazai webáruházaknak konkrét HUF árakkal és esettanulmánnyal.