Mérés és adat
A böngészőből futó mérés évről évre kevesebbet lát: a süti-visszautasítás, a hirdetésblokkolók és a böngészők élettartam-korlátai miatt a konverziók egy része egyszerűen nem jelenik meg a Google Analytics 4-ben és a hirdetési fiókokban. A szerver oldali követés ezt úgy oldja meg, hogy az események nem közvetlenül a böngészőből mennek a Google felé, hanem az Ön saját szerverén futó gyűjtőkonténeren keresztül, ahol Ön dönti el, mi megy tovább, milyen formában és milyen hozzájárulás mellett.
Ezt nálunk nem marketinges állítja össze kattintgatva, hanem az a csapat, amelyik a webáruházat is fejleszti. Ez a különbség ott látszik, ahol a legtöbb bevezetés elakad: a rendelés-visszaigazolás szerverről küldött eseményénél, a duplikációmentes esemény-azonosításnál, a hozzájárulás állapotának helyes továbbadásánál és a hirdetési fiók visszamérésénél.
Kiesett konverziók
A böngészőben blokkolt vagy megszakadt méréseket a szerverről küldött esemény pótolja. A vásárlás akkor is rögzül, ha a felhasználó böngészője a Google szkriptjeit nem engedi lefutni.
Rövid élettartamú azonosítók
A böngészők a JavaScriptből írt sütik élettartamát korlátozzák, így a visszatérő látogató új felhasználóként jelenik meg. Szerveroldalról kiszolgálva ez a probléma megszűnik.
Hozzájárulás-kezelés
A Consent Mode v2 nem checkbox, hanem állapot, amit végig kell vinni a méréslánc minden pontján. Mi a sütibanner, a konténer és a szerveroldali továbbítás között is konzisztensen kezeljük.
Fontos elvárást tisztázni az elején: a szerver oldali követés nem eszköz a hozzájárulás megkerülésére. Aki nem járult hozzá a mérési célú adatkezeléshez, annak az adata nem megy tovább azonosítható formában, ezt a rendszer felépítése biztosítja. A nyereség abból jön, hogy a hozzájáruló felhasználók adata hiánytalanul megérkezik, nem abból, hogy a nem hozzájárulóké is.
- Szerveroldali gyűjtőpont a saját infrastruktúrán. Akár sGTM konténerrel, akár saját fejlesztésű mérőréteggel dolgozunk, a gyűjtőpont az Ön szerverén fut, saját aldomainen és tanúsítvánnyal, nem harmadik fél szolgáltatásán. A mérési adat nem hagyja el az infrastruktúrát, mielőtt eldőlne, hova megy.
- GA4 e-commerce eseménylánc. Terméklista-megtekintés, kosárba tétel, pénztár-lépések és vásárlás, a teljes lánc bekötve, a webshop tényleges adatmodelljére illesztve, nem általános sablonnal.
- Consent Mode v2 fejlesztői implementáció. Az alapállapot, a frissítés és a hozzájárulás továbbadása a szerveroldali konténer felé, a sütibanner tényleges eseményeire kötve.
- Enhanced Conversions. A Google Ads visszamérés pontosítása a rendelési adatokból, a Google előírásainak megfelelő előfeldolgozással.
- Facebook / Meta Conversions API. Szerverről küldött események, a böngészőoldali pixellel duplikációmentesen párosítva.
- Rendelés-alapú visszamérés. Ahol a rendelés a vásárlás után módosulhat (sztornó, visszáru, utólagos jóváhagyás), ott a valós, végleges rendelésállapotra mérünk, nem a köszönőoldal megjelenésére.
- Ellenőrzés és dokumentáció. Átadáskor eseménytérkép, tesztjegyzőkönyv és a konténer konfigurációja írásban, hogy később bárki tovább tudja vinni, ne csak mi.
A szerver oldali mérésnek nincs egyetlen helyes megvalósítása. Kétféle megoldást építünk és a felmérés után azt ajánljuk, amelyik az Ön rendszeréhez és forgalmához illik. Mindkettő az Ön szerverén fut és mindkettőnél ugyanaz a csapat állítja be, aki a webáruházat is fejleszti.
1. sGTM konténer a saját VPS-eden
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. Akkor jó választás, ha sok hirdetési rendszert kell bekötni, vagy ha fontos, hogy a beállítás bárki számára átvehető legyen. Cserébe egy külön konténert is üzemeltetni kell.
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 és egyedi PHP rendszerekhez is. Kevesebb mozgó alkatrész, alacsonyabb üzemeltetési költség, és a rendelés végleges állapotára is pontosan tud mérni. Akkor jó választás, ha a mérés a webshoppal együtt fejlődik és nem kell tucatnyi külső rendszert kiszolgálni.
Költségben a különbség jellemzően az üzemeltetésben jelentkezik: bérelt szolgáltatáson futó konténer havidíjas és a kérésszám alapján skálázódik, a saját szerveres megoldásoknál egyszeri beállítási költség után lényegében csak 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, ezért minden esetben felmérés után adunk írásos ajánlatot.
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.
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.
A leggyakoribb kérdések, amiket ajánlatkérés előtt feltesznek, őszinte válaszokkal, beleértve azt is, amikor a válasz az, hogy még nem éri meg.
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 adatveszteség. Ezt a mérési auditban díjmentesen elvégezzük, még a döntés előtt.
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.
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.
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.
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.
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.
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.
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.
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.
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.