Szerveroldali GTM saját aldomainen: a first-party beállítás lépései és buktatói

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

Ha már fut a szerveroldali Google Tag Manager tárolód, a következő lépés, hogy a böngésző ne a Google által adott, run.app végű címre küldje a méréseket, hanem a saját domainedre. Ez a cikk végigvisz a beállításon az aldomain kiválasztásától a böngésző hálózati fülén végzett ellenőrzésig. Külön szó lesz a Safari sütikezeléséről és arról, mi történik, ha a szerver leáll. A szövegben három jelölést használok. A Hivatalosan igazolt állítás a Google vagy a WebKit dokumentációjában szerepel. A Saját tapasztalat az, amit beállítások során visszatérően látunk. A Szakmai feltételezés indokolt következtetés, de nincs rá hivatalos megerősítés.

Miért kell saját domain a szerveroldali GTM-hez?

A saját domainen futó szervertároló first-party környezetbe kerül, így a szerver által beállított sütik a te domainedhez tartoznak, és a böngészők kevésbé korlátozzák őket. A Cloud Run alapértelmezett címe egy idegen domain, az onnan érkező süti a weboldalad szemszögéből harmadik féltől származik.

Hivatalosan igazolt. A Google szerveroldali dokumentációja két támogatott utat ír le. Az egyik a same-origin beállítás, ahol a mérés a fő domain egy útvonalán fut (például example.hu/metrics), egy terheléselosztón vagy CDN-en keresztül. A másik az aldomain (például data.example.hu). A dokumentáció a same-origin megoldást ajánlja elsőként.

Szakmai feltételezés. Az aldomain akkor jó választás, ha nincs hozzáférésed a fő domain előtti CDN-hez vagy terheléselosztóhoz, vagy a tárhely nem enged útvonal szerinti továbbítást. Ez sok kisebb WordPress-oldalnál így van, ezért a cikk ezt az utat írja le részletesen.

Hogyan válaszd ki az aldomaint?

Válassz semleges nevű aldomaint ugyanazon a regisztrált domainen, amelyen a weboldal fut. A www.example.hu oldalhoz tehát data.example.hu vagy m.example.hu jó, egy másik domain alá tett cím viszont már nem számít first-partynek.

• Ne a gtm, tracking, analytics vagy metrics szót használd. Szakmai feltételezés. A hirdetésblokkolók szűrőlistái gyakran ilyen mintákra keresnek, így egy semleges név jó eséllyel ritkábban akad fenn, de garanciát erre senki nem tud adni.
• Ne használj olyan aldomaint, amely már foglalt (levelezés, régi mobilos oldal, CDN). Az m. előtag például ütközhet egy régi mobilverzióval.
• Ha több domainen fut ugyanaz a mérés (például .hu és .com), mindegyikhez külön aldomain kell, mert a süti csak a saját domainjén él.

Milyen DNS-rekord kell, és mikor CNAME, mikor A-rekord?

A rekord típusa attól függ, hogyan érhető el a szervertároló. Cloud Run domain-hozzárendelésnél CNAME kell a Google címére, terheléselosztónál A-rekord a fix IP-címre, külső tárhelyszolgáltatónál pedig az, amit ők megadnak.

Hivatalosan igazolt. A Cloud Run beépített domain-hozzárendelése aldomainhez CNAME-rekordot kér, így néz ki.

data.example.hu. 3600 IN CNAME ghs.googlehosted.com.

A Google ezt a funkciót előzetes (preview) állapotúként jelöli, és csak bizonyos régiókban érhető el. Éles üzemhez a dokumentáció a globális külső terheléselosztót javasolja, ahol a DNS-ben A-rekord mutat a lefoglalt statikus IP-re.

data.example.hu. 3600 IN A 34.120.xx.xx

Saját tapasztalat. A váltás előtt egy nappal érdemes a TTL-t 300 másodpercre csökkenteni, így egy elírt rekord gyorsabban javítható. Hogy a rekord él-e, a terminálból néhány másodperc alatt kiderül.

dig +short data.example.hu

Hogyan kerül tanúsítvány az aldomainre?

A Google által kezelt tanúsítvány automatikusan elkészül, amint a DNS-rekord a jó helyre mutat. Ez percektől akár egy napig is eltarthat, és addig a HTTPS-kérések hibát adnak.

Hivatalosan igazolt. A Google-kezelt tanúsítvány kiadását a domainen beállított CAA-rekord megakadályozhatja. Ha a domainnek van CAA-rekordja, abban szerepelnie kell a Google tanúsítványkiadójának (pki.goog), különben a kiadás elakad.

Saját tapasztalat. A Cloudflare-en kezelt domaineknél gyakori hiba, hogy az aldomain proxyzott (narancssárga felhő) módban marad. Ez zavarhatja a tanúsítvány kiadását, és megváltoztatja, milyen IP-címet lát a böngésző, ami a Safari miatt is számít (lásd lent). Az első beállításnál hagyd csak DNS módban. A tanúsítvány és a szerver együttes ellenőrzésére a szervertároló állapotjelző útvonala a legegyszerűbb.

curl -I https://data.example.hu/healthy

Ha a válasz HTTP/2 200, a tanúsítvány érvényes, és a tároló válaszol.

Mit kell átállítani a szervertárolóban?

A szervertároló beállításaiban fel kell venni az új címet szervertároló-URL-ként, és be kell kapcsolni azokat a klienseket, amelyek a kéréseket fogadják és a szkripteket kiszolgálják.

1. A GTM felületén a szervertárolóban nyisd meg az Adminisztráció, majd a Tároló beállításai menüt, és a Server container URL mezőbe írd be a https://data.example.hu címet. Több domain esetén több URL is felvehető.
2. Az előnézeti szerver maradjon a saját, külön címén. Az egyedi domaint az éles szolgáltatáshoz rendeld, az előnézetihez ne.
3. A GA4 kliensben nézd meg a sütibeállítást. Hivatalosan igazolt. A szerver által kezelt mód (FPID süti) HttpOnly sütit állít be a saját domaineden, amelyet a böngészőben futó szkript nem tud olvasni.
4. Ha a gtm.js-t is a saját domainről akarod betölteni, kapcsold be a Google Tag Manager: Web Container klienst, és add meg benne az engedélyezett webes tároló-azonosítót (GTM-XXXXXXX).

Hogyan irányítod a gtag-et és a GTM betöltőt a saját domainre?

Két külön dolgot kell átirányítani. Az egyik az adatküldés, vagyis hová mennek a mérési kérések. A másik a betöltő, vagyis honnan töltődik le maga a gtm.js vagy gtag.js fájl. A kettő egymástól függetlenül állítható.

Az adatküldés átirányítása

Közvetlen gtag-beépítésnél a konfigurációs hívásba kerül a szervertároló címe.

gtag('config', 'G-XXXXXXX', { 'server_container_url': 'https://data.example.hu' });

Ha a GA4 a webes GTM-tárolón keresztül fut, a Google-címke konfigurációs paraméterei közé vedd fel a server_container_url paramétert ugyanezzel az értékkel. Ezt egy helyen, a Google-címkén állítsd be, így minden GA4-esemény örökli.

A betöltő átirányítása

A GTM beépítő kódjában a https://www.googletagmanager.com/gtm.js?id= részt cseréld le erre.

https://data.example.hu/gtm.js?id=

A noscript részben lévő ns.html címet is ugyanígy írd át. Közvetlen gtag.js-nél a GA4 kliens tudja kiszolgálni a gtag.js fájlt a megadott mérési azonosítókhoz, ekkor a gtag/js?id= kezdetű cím domainjét kell kicserélni.

Saját tapasztalat. WordPressnél a gyorsítótárazó és a szkript-összevonó bővítmények néha a régi beépítő kódot szolgálják ki napokig. Csere után ürítsd a bővítmény és a CDN gyorsítótárát is, és nézd meg az oldal forrását, valóban az új cím van-e benne.

Hogyan ellenőrzöd a böngésző hálózati fülén, hogy a kérések a saját domainre mennek?

A böngésző fejlesztői eszközeinek Hálózat (Network) fülén a kérések címéből egyértelműen látszik, melyik domain kapja az adatot. Ha a collect kérés és a gtm.js is a saját aldomainedről jön, a beállítás jó.

1. Nyisd meg az oldalt inkognitó ablakban, és fogadd el a sütiket, ha a mérés hozzájáruláshoz kötött.
2. Nyisd meg a fejlesztői eszközöket (F12), lépj a Network fülre, kapcsold be a Preserve log és a Disable cache opciót, majd töltsd újra az oldalt.
3. A szűrőmezőbe írd be, hogy collect. A GA4-kérés címének így kell kezdődnie, https://data.example.hu/g/collect?v=2, az állapotkód pedig 200 vagy 204.
4. Ellenőrizd, hogy nem maradt-e párhuzamos kérés a google-analytics.com vagy region1.google-analytics.com domainre. Ha van, a mérés duplán fut, és a GA4-ben kétszeres adatot kaphatsz.
5. Szűrj rá a gtm.js kifejezésre. Ha a betöltőt is átirányítottad, a kérés gazdagépe a saját aldomained.
6. Az Application (Alkalmazás) fülön a Cookies alatt keresd meg az FPID sütit. Domainje .example.hu legyen, a HttpOnly jelölés legyen bepipálva, és nézd meg a lejárati dátumot.
7. Közben nyisd meg a szervertároló előnézeti módját. A bejövő kérések listájában meg kell jelennie az oldalbetöltésnek és az eseményeknek.

Ugyanezt Safariban is érdemes megcsinálni a Webes vizsgáló (Web Inspector) Hálózat és Tárolás fülén, mert a sütik lejárata ott eltérhet a Chrome-ban látottól.

Mi köze a CNAME-alapú megoldásnak a Safari ITP-hez?

A Safari Intelligens Követésmegelőzése (ITP) 7 napra korlátozza azoknak a szerver által beállított sütiknek az élettartamát, amelyeket egy CNAME-mel elfedett harmadik fél, vagy a fő weboldaltól eltérő IP-tartományban futó szerver állít be. Egy Google-infrastruktúrára mutató aldomain jó eséllyel ebbe a körbe esik.

Hivatalosan igazolt. A WebKit 2020-ban vezette be a CNAME-elfedés elleni védelmet, amely a cloaked aldomainről beállított sütiket 7 napra korlátozza. A Safari 16.4-től (2023) a korlát akkor is él, ha a sütit beállító szerver IP-címe nem egyezik a weboldal IP-címével. IPv4-nél az első 16 bitet, IPv6-nál az első 64 bitet hasonlítja össze. A böngészőben JavaScripttel beállított sütik élettartama ettől függetlenül eddig is legfeljebb 7 nap volt.

Szakmai feltételezés. Emiatt ajánlja a Google a same-origin megoldást. Ha a mérés a fő domain egy útvonalán, ugyanazon a terheléselosztón vagy CDN-en fut, mint a weboldal, az IP-egyezés teljesül. Ha a weboldal egy hazai tárhelyen fut, a szervertároló pedig a Google felhőjében, az aldomaines megoldás Safariban valószínűleg 7 napos sütit ad.

Saját tapasztalat. Ez a korlát a visszatérő látogatók felismerését rontja Safariban, a mérést magát nem állítja le. Az adatok beérkeznek, de egy héten túl visszatérő iPhone-os látogató új felhasználóként jelenhet meg. Hogy ez nálad mekkora torzítás, azt a Safari-forgalom aránya és a vásárlási ciklus hossza dönti el.

Mi történik, ha a szerveroldali tároló leáll?

Ha a szervertároló nem válaszol, a kiesés ideje alatt küldött mérési kérések elvesznek, a böngésző nem gyűjti és nem küldi el őket később. Ha a gtm.js is a saját szerverről töltődik, akkor a teljes webes tároló sem töltődik be, vagyis minden GTM-ből indított címke kiesik.

A második eset a súlyosabb. Ha a sütisávot (consent bannert) is a GTM tölti be, a kiesés alatt az sem jelenik meg. A hirdetési címkék, a Meta Pixel és minden más, amit a webes tároló indít, szintén leáll, akkor is, ha egyébként közvetlenül a hirdetési platformnak küldenének.

Szakmai feltételezés. A beacon-alapú küldés nem próbálkozik újra, ezért egy félórás kiesés félórányi adathiányt jelent, amit utólag nem lehet pótolni.

A kockázat így csökkenthető.

• Hivatalosan igazolt. A Google éles üzemhez több, folyamatosan futó példányt javasol (minimum instances), hogy egy példány kiesése vagy hidegindítása ne okozzon adatvesztést.
• Állíts be rendelkezésre állás-figyelést a /healthy útvonalra (például Google Cloud Monitoring uptime check), riasztással e-mailre. A figyelő csak szóljon, a beavatkozásról ember döntsön.
• Állíts be költségriasztást a felhőprojekten, mert a példányszám emelése a számlán is megjelenik.
• Saját tapasztalat. Ha a csapatban nincs, aki kiesés esetén gyorsan reagál, érdemes az első hónapokban csak az adatküldést átirányítani, a gtm.js-t pedig a Google domainjéről hagyni. Így egy szerverhiba a GA4-adatokat érinti, a sütisávot és a webes címkéket nem.

Milyen további buktatókat érdemes átnézni élesítés előtt?

A legtöbb hiba a beállítás szélein jelentkezik, a hozzájárulásnál, a biztonsági fejléceknél és a duplikált mérésnél.

• A saját domain jogilag semmit nem változtat. A GDPR és az ePrivacy szerinti hozzájárulás ugyanúgy kell, a Consent Mode jeleit a szervertárolónak is meg kell kapnia.
• Ha az oldalnak van Content-Security-Policy fejléce, a script-src és a connect-src sorba vedd fel a https://data.example.hu címet, különben a böngésző csendben letiltja a kéréseket.
• Nézd meg, nem maradt-e az oldalon egy régi, közvetlen GA4-beépítés egy bővítményben vagy a sablonban.
• Az előnézeti szervert ne tedd ki a saját domainre, és ne skálázd fel feleslegesen.
• Élesítés után egy hétig vesd össze a GA4 felhasználó- és munkamenetszámát a korábbi időszakkal. Egy hirtelen kétszeres vagy feleakkora érték beállítási hibára utal.
• A hirdetésblokkolók elleni hatást ne ígérd senkinek. A saját domain segíthet, de a szűrőlisták az útvonalakra (/g/collect, /gtm.js) is kereshetnek.

Források és további olvasnivalók

• Google Tag Manager Server-side dokumentáció (developers.google.com/tag-platform), Custom domain és Cloud Run setup guide
• Google Cloud Run dokumentáció, Mapping custom domains
• Google Cloud Load Balancing dokumentáció, Google-managed SSL certificates
• Google Analytics 4 súgó, Server-side tagging és Consent Mode
• WebKit Blog, CNAME Cloaking and Bounce Tracking Defense (2020)
• WebKit Features in Safari 16.4 (2023)
• MDN Web Docs, Content-Security-Policy és Network Monitor