GA4 Measurement Protocol: szerveroldali események küldése, amikor a böngésző nem tudja

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

Mire való a GA4 Measurement Protocol?

A GA4 Measurement Protocol egy egyszerű HTTP-felület, amelyen keresztül a saját szervered közvetlenül küld eseményt a Google Analytics 4 tulajdonodba. Akkor van rá szükség, amikor egy üzletileg fontos esemény a böngészőn kívül válik biztossá, vagy a látogató böngészője abban a pillanatban már nincs ott.

A webes mérés alapból a látogató böngészőjében fut. A gtag vagy a Google Címkekezelő akkor küld adatot, amikor az oldal betöltődik, a felhasználó kattint, vagy elér egy köszönőoldalt. Ha a döntő pillanat máshol történik, a böngészős címke egyszerűen nem tud róla. Három gyakori helyzetben ez komoly adatvesztést okoz.

• Banki visszaigazolás utáni vásárlás. A vásárló átmegy a fizetési oldalra, kifizeti a rendelést, aztán bezárja a lapot, és sosem ér vissza a köszönőoldalra. A rendelés sikeres, a bank szerverről szerverre küldött értesítése meg is érkezik a webshopodhoz, a GA4 viszont vásárlást nem lát.
• A CRM-ben lezárt üzlet. Az ajánlatkérő űrlapot a weboldalon töltik ki, de a tényleges szerződés két-három héttel később születik meg az értékesítő gépén. Ha csak az űrlapot méred, a hirdetési rendszereid azt tanulják meg, ki tölt ki űrlapot, azt viszont nem, hogy ki vásárol.
• Előfizetés-megújítás. A számlázó rendszer havonta terheli a kártyát, a felhasználó közben nincs is a weboldalon. A megújulás valódi bevétel, böngészős esemény mégsem tartozik hozzá.

Mindhárom esetben a szerver tudja a biztos tényt, és a Measurement Protocol ezt juttatja el a GA4-be. [Hivatalosan igazolt] A Google fejlesztői dokumentációja a protokollt a gtag, a Címkekezelő és a Firebase melletti kiegészítésként írja le, amely az automatikus gyűjtést bővíti, és nem helyettesíti.

Mire nem alkalmas a Measurement Protocol?

A Measurement Protocollal nem tudsz munkamenetet, oldalmegtekintés-folyamot vagy forgalmi forrást pótolni. A szerverről küldött esemény akkor hasznos, ha egy már létező, böngészőben elindult látogatói történethez kapcsolod hozzá.

[Hivatalosan igazolt] Bizonyos eseménynevek fenntartottak, ezeket a protokollon nem küldheted. Ilyen többek között a session_start, a first_visit, a user_engagement és az ad_click, és tiltottak a _, firebase_, ga_, google_ és gtag. előtagú nevek is. Munkamenetet indítani szerverről tehát nem lehet, csak meglévőhöz csatolni.

A szerver ráadásul nem látja azt, amit a böngésző lát. Nincs előtte a hivatkozó oldal, az UTM-paraméterek, a gclid, a képernyőméret és a böngésző nyelve. [Saját tapasztalat] Ahol szerveres eseményekkel próbálták pótolni a reklámblokkolók miatt elveszett oldalmegtekintéseket, ott a riportokban sok forrás nélküli, „(not set)” vagy „Unassigned” sor jelent meg, és a földrajzi meg az eszköz szerinti bontás is megbízhatatlanná vált. Az a látogató pedig, aki elutasította a mérést, a szerveres úton sem kerülhet be, erre lent még visszatérünk.

Honnan kell a client_id?

A client_id a böngészőben keletkezik, a GA4 _ga sütijében él, és azon a ponton kell elmentened, ahol a látogató még az oldaladon van, például az űrlap beküldésekor vagy a rendelés leadásakor. A szerver magától nem tudja kitalálni.

A _ga süti értéke valahogy így néz ki, GA1.1.1234567890.1698765432. A client_id az utolsó két számcsoport ponttal összekötve, vagyis 1234567890.1698765432. Ennél tisztább út, ha a gtag-től kéred el.

gtag('get', 'G-XXXXXXX', 'client_id', function (id) { document.getElementById('ga_client_id').value = id; });

A gyakorlatban egy rejtett űrlapmezőbe vagy a rendelés adatai közé teszed, és a szerver onnan veszi elő, amikor megjön a banki visszaigazolás vagy a CRM-ben megnyert üzlet. Webshopnál a rendelés rekordja mellé, ajánlatkérésnél a CRM lead-rekordjába érdemes menteni. Ha a felhasználó be van jelentkezve, a saját azonosítódat user_id mezőben is elküldheted. Ez a client_id-t kiegészíti, webes adatfolyamnál a client_id ettől még kell.

Honnan jön a session_id, és mire kell?

A session_id is a böngészőből jön, a _ga_ kezdetű, tulajdonhoz tartozó sütiből vagy a gtag-ből, és az esemény paraméterei közé kell tenni. Ettől tudja a GA4 a szerveres eseményt a látogató meglévő munkamenetéhez kötni, így az esemény örökli a munkamenet forrását és kampányát.

gtag('get', 'G-XXXXXXX', 'session_id', function (sid) { document.getElementById('ga_session_id').value = sid; });

[Saját tapasztalat] A sütiből való kiolvasás törékeny. A _ga_XXXXXXX süti formátuma megváltozott (a régi, GS1.1. kezdetű, ponttal tagolt alak mellett megjelent a GS2.1. kezdetű, dollárjellel tagolt változat), és ahol a szerveroldali feldolgozó a régi formára épült, ott csendben üres session_id-k mentek tovább. A gtag-es lekérdezés ezt a gondot megkerüli.

[Hivatalosan igazolt] A Google javasolja, hogy a session_id mellé engagement_time_msec paramétert is küldj, mert enélkül az esemény a valós idejű nézetben és egyes aktivitási mutatókban nem feltétlenül jelenik meg. A timestamp_micros mezővel legfeljebb 72 órával dátumozhatod vissza az eseményt.

Itt jön a CRM-es eset csapdája. Ha az üzlet három héttel az űrlap után zárul, a 72 órás határ miatt az eseményt nem tudod az eredeti időpontra tenni, a munkamenet pedig rég lezárult. [Szakmai feltételezés] Ilyenkor a GA4 a konverziót jó eséllyel a felhasználóhoz tudja kötni, a munkamenet szintű forráshoz viszont már gyengén vagy egyáltalán nem. Hosszú értékesítési ciklusnál ezért a GA4 mellett a hirdetési platform saját offline konverziós importját is érdemes megnézni (Google Ads esetén a gclid-alapú vagy a felhasználói adatokra épülő feltöltést).

Mi történik client_id és session_id nélkül a forrás-hozzárendeléssel?

Client_id nélkül a webes adatfolyamba küldött kérés érvénytelen, kitalált client_id-vel pedig új, előzmény nélküli felhasználó születik, akinek nincs forrása. Session_id nélkül a felhasználó megvan, de a munkamenet szintű forrás és kampány jellemzően „(not set)” lesz.

Érdemes külön végiggondolni a három esetet.

• Helyes client_id és session_id. Az esemény a látogató munkamenetébe kerül, és a forgalomszerzési riportban a valódi forrás, médium és kampány mellett jelenik meg. Ezt kell elérned.
• Helyes client_id, session_id nélkül. [Saját tapasztalat] A felhasználói szintű első forrás jellemzően rendben van, a munkamenet-forrás és -médium dimenzióban viszont „(not set)” vagy „Unassigned” sorok jelennek meg. A vásárlás megvan, csak nem tudod, melyik kampány hozta.
• Szerveren generált, véletlen client_id. Minden esemény egy vadonatúj felhasználóhoz tartozik, akinek egyetlen oldalmegtekintése sincs. Ez felfújja a felhasználószámot, a bevétel pedig forrás nélkül lóg a levegőben.

A harmadik hibát azért kell kiemelni, mert a beérkező szám első ránézésre rendben lévőnek tűnik. A bevétel egyezik a webshoppal, csak a forrás szerinti bontás üres. [Szakmai feltételezés] Ha a GA4-et Google Ads-szel is összekötötted, a munkamenethez nem kötött kulcsesemények a hirdetési jelentésekben is gyengébben rendelhetők hozzá a kampányokhoz, ami az optimalizálást is ronthatja.

Hogyan épül fel egy szerveroldali vásárlás-esemény lépésről lépésre?

Egy POST kérést küldesz a mérési azonosítóval és egy API-titokkal, a törzsben a client_id-vel és az eseménnyel. A lépések így követik egymást.

1. A GA4 adminisztrációban, a webes adatfolyam beállításai között hozz létre egy Measurement Protocol API-titkot. Ez a kulcs csak a szerveren lehet, a böngészőbe kerülő JavaScriptbe soha.
2. A fizetés indításakor mentsd el a rendelés mellé a client_id-t és a session_id-t.
3. Amikor a bank visszaigazolása megérkezik, a szerver ebből a két értékből és a rendelés adataiból összeállítja a kérést.
4. Fejlesztés közben előbb a validációs végpontra küldöd, élesben a gyűjtő végpontra.

A gyűjtő végpont címe a következő.

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=TITKOS_KULCS

A kérés törzse egy vásárlásnál legalább ennyit tartalmaz.

{"client_id": "1234567890.1698765432", "events": [{"name": "purchase", "params": {"session_id": "1698765432", "engagement_time_msec": 100, "transaction_id": "R-10452", "currency": "EUR", "value": 49.9, "items": [{"item_id": "SKU-12", "item_name": "Minta termék", "quantity": 1, "price": 49.9}]}}]}

[Hivatalosan igazolt] A value mellé a currency mező is kell, különben a bevétel nem számolódik. A GA4 az azonos transaction_id értékű vásárlásokat kiszűri, ezért ha a böngésző is küld vásárlást, mindkét oldalon ugyanazt a rendelésszámot használd. Uniós adatgyűjtéshez a region1.google-analytics.com domain is használható ugyanezzel az útvonallal.

[Saját tapasztalat] A legtisztább, ha egy vásárlást egyetlen helyről küldesz. Ha a köszönőoldal és a szerver is jelez, a duplikáció-szűrés megfogja ugyan az ismétlést, de nehezebb lesz kideríteni, melyik út esett ki, amikor valami elromlik.

Mi változik a CRM-es és a megújítási esetnél?

A CRM-nél az űrlap rejtett mezőiből a client_id és a session_id a lead-rekordba kerül. Amikor az értékesítő megnyertre állítja az üzletet, a CRM webhookja meghív egy kis szerveroldali szkriptet, amely close_convert_lead eseményt küld. Ez a Google ajánlott eseményei között szerepel, a lead-életút lezárásának jelölésére. Megújításnál a számlázó rendszer a sikeres terhelés után küld eseményt, a client_id-t és a user_id-t az előfizető adataiból veszi.

Hogyan ellenőrizd a validációs végponttal?

Ugyanazt a kérést a /debug/mp/collect útvonalra küldöd, és a válaszban kapott validationMessages lista megmondja, mi a hiba. Ha a lista üres, a kérés formailag rendben van. A validációs végpontra küldött adat nem kerül be a riportokba.

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXX&api_secret=TITKOS_KULCS

Erre a lépésre azért van szükség, mert [Hivatalosan igazolt] az éles gyűjtő végpont akkor is 2xx választ ad, ha a törzs hibás. A szervered naplójában minden zöldnek látszik, a GA4-ben közben semmi nem jelenik meg. A validáció a formai hibákat fogja meg, például a hiányzó client_id-t, a túl hosszú eseménynevet vagy a fenntartott nevet. Azt viszont nem mondja meg, hogy az esemény a jó tulajdonba megy-e, és hozzá tud-e kapcsolódni a munkamenethez.

Élesítés előtt ezt a listát érdemes végigvenni.

• A validációs végpont üres validationMessages listát ad vissza.
• Tesztelés közben az esemény paraméterei közé tett debug_mode értékkel az esemény megjelenik a GA4 DebugView nézetében, a saját tesztböngésződ munkamenetében.
• A valós idejű jelentésben a tesztvásárlás a tesztlátogatás forrásával együtt látszik.
• Egy kérésben legfeljebb 25 esemény megy, az eseménynév legfeljebb 40 karakter, és eseményenként legfeljebb 25 paraméter van (ezek a Google által közölt korlátok).
• Az API-titok nincs benne semmilyen böngészőbe kerülő fájlban vagy nyilvános kódtárolóban.
• Egy-két nap után a forgalomszerzési riportban a szerveres vásárlások „(not set)” aránya nem ugrott meg.

[Saját tapasztalat] Az utolsó pontot gyakran kihagyják, pedig a session_id-gondok jellemzően csak ott derülnek ki.

Mi a helyzet a hozzájárulással?

A szerveres küldés nem kerüli meg a süti-hozzájárulást. Ha a látogató elutasította az analitikai mérést, érvényes client_id-d sincs, és az eseményt nem is szabad hozzá kötnöd.

[Hivatalosan igazolt] A protokoll kérésében van consent objektum, benne az ad_user_data és az ad_personalization mezővel, ezekkel jelzed a Google felé a felhasználó hirdetési célú döntését. [Szakmai feltételezés] Hogy a saját folyamatodban milyen jogalap mellett mit küldhetsz, az adatvédelmi kérdés, ezt az adatvédelmi tisztviselőddel vagy jogásszal érdemes egyeztetni. A technikai lehetőség önmagában nem jelent engedélyt.

Mikor elég a Measurement Protocol, és mikor indokolt a teljes szerveroldali GTM?

A Measurement Protocol akkor elég, ha néhány jól körülhatárolt, szerveren biztossá váló eseményt kell pótolnod a GA4-ben. A szerveroldali Google Címkekezelő (sGTM) akkor indokolt, ha az egész mérési adatfolyamot a saját szervereden át akarod terelni, szűrni és több platformnak továbbadni.

A Measurement Protocol jó eséllyel elég, ha

• egy-három eseményről van szó (banki visszaigazolás, CRM-ben zárt üzlet, megújítás),
• csak a GA4-be kell küldeni, vagy a többi platformhoz már van külön integrációd,
• van fejlesztőd, aki a webshop vagy a CRM szerveroldalába beírja a hívást,
• a böngészős mérés egyébként jól működik, csak a végső esemény hiányzik.

A szerveroldali GTM felé billen a mérleg, ha

• ugyanazt az eseményt a GA4-be, a Google Ads-be és a Meta Conversions API-ba is el akarod juttatni, egyetlen helyről kezelve,
• a mérést saját aldomainen szeretnéd futtatni, és a továbbküldés előtt személyes adatokat akarsz kiszűrni vagy átalakítani,
• marketingesként a címkéket fejlesztő nélkül akarod módosítani,
• van, aki a szerverkonténer tárhelyét és üzemeltetését hosszú távon vállalja.

[Szakmai feltételezés] A kettő jól megfér egymás mellett. Az sGTM nagyrészt a böngészőből érkező kéréseket dolgozza fel, a banki visszaigazolás vagy a CRM-es zárás ott is a szerverről indul, és ilyenkor is egy külön hívás vagy webhook juttatja be a konténerbe. Kisebb webshopnál vagy szolgáltatónál általában a Measurement Protocol a gyorsabb, kevesebb üzemeltetéssel járó első lépés, az sGTM pedig akkor jön, amikor a több platformos igény ténylegesen megjelenik.

Milyen hibákat érdemes elkerülni?

[Saját tapasztalat] A legtöbb gond a folyamatban keletkezik, maga a kód ritkábban hibás. Ezek fordulnak elő a leggyakrabban.

• A client_id-t a szerver generálja, mert a fejlesztő nem tudta, hogy a böngészőből kell átvenni.
• A bankból visszatérő látogatónál az oldal új sütit olvas ki, és nem a rendelés mellé elmentett client_id-t használja.
• A transaction_id eltér a böngészős és a szerveres vásárlásnál, így a duplikáció-szűrés nem működik, és a bevétel kétszer számolódik.
• Az eseményt a 72 órás határnál régebbi időbélyeggel küldik, és nem jelenik meg a riportokban.
• A megújítást minden hónapban ugyanazzal a régi session_id-vel küldik. [Szakmai feltételezés] Megújításnál tisztább a client_id és a user_id, munkamenet-azonosító nélkül, mert a régi munkamenet forrása félrevezető lenne.

Források és további olvasnivalók

• Google for Developers, Google Analytics Measurement Protocol (GA4) dokumentáció
• Google for Developers, Measurement Protocol események validálása
• Google for Developers, Measurement Protocol korlátozások és fenntartott eseménynevek
• Google Analytics súgó, A munkamenetek a Google Analytics 4-ben
• Google Analytics súgó, Ajánlott események (purchase, lead-események)
• Google Tag Manager dokumentáció, Szerveroldali címkézés
• Google Analytics súgó, Beleegyezési mód