Kliens vagy szerver?
Kliens oldali mérésnek nevezzük azt, hogyha a követőkódok és a mérés a látogató böngészőjében fut le és ad át adatot egy külső analitikai vagy hirdetési rendszernek. Ilyen megoldás például az, hogyha egy Analytics követőkódot, vagy egy hirdetési rendszer pixel-jét elhelyezzük weboldalunkban.
Ezzel szemben a szerver oldali mérés lényege, hogy egy saját vagy bérelt szervert is igénybe veszünk az adattovábbításhoz a célrendszerek (Analytics, Meta, TikTok…) felé. Emiatt ugyanúgy szerver oldali mérésnek lehet hívni egy egyszerű szerver logot, mint egy pazarul kialakított Server-side Google Tag Manager setup-ot.
Mikor lehet szükség szerver oldali mérésre?
Ha csökkenteni szeretnénk a hirdetési költségeket
A modern böngszőkben a cookie-k kerülnek egyre gyakrabban célkeresztbe. A third-party cookie-kat sok böngésző (pl. Safari, Firefox) már eleve blokkolja, de a first party cookie-k élettartamát is lerövidítik bizonyos esetekben. A szerver oldali mérési megoldások viszont nem használnak feltétlenül cookie-kat, sőt néha még a látogató böngészőjét sem, így egy sokkal biztosabb és pontosabb adatátadást tesz lehetővé a hirdetési rendszerek felé.
A hirdetési rendszer pedig akkor tud jól dolgozni, ha minél több adathoz jut: fontos tudnia azt, hogy akit a weboldalra irányít az milyen viselkedést mutat ott. Ha azt látja, hogy egy bizonyos látogatói szegmens sokkal több konverziót hoz mint egy másik, akkor igyekszik ahhoz a szegmenshez hasonló látogatót az oldalra küldeni, így vélhetően magasabb konverziónk lesz. Tehát ahhoz, hogy minél több konverziónk legyen, minél több adatra van szüksége a rendszernek, hogy csiszolhassa az AI a hirdetések kiszolgálását.
A több adat tehát csökkeni az egy eredményre jutó hirdetési költséget, illetve növeli a bemért konverziók számát. Mennyivel? Ez nagyon függ a weboldal célközönségétől, de világátlagban a Meta szerint 13%-kal csökken az egy eredményre jutó hirdetési költség és 19%-kal több konverziót mér a rendszer.
Ha több és pontosabb adatot szeretnénk
Aki rendszeresen böngészi az Analytics-et az láthatja, hogy a user számok és a új user számok közötti differencia egyre kisebb, illetve látható a direct forrású látogatók egyre növekvő aránya is. Ez a jelenség is arra vezethető vissza, hogy bizonyos böngészők csökkentik a cookie-k élettartamát. Az Analytics alapesetben 1 éves lejáratú first-party cookie-val azonosítja weboldalunk látogatóját, de például egy Safari böngésző ezt 7 naposra csökkenti.
Ez azt jelenti, hogyha 8 nap múlva érkezik vissza látogatónk, akkor ismét új userként fog megjelenni riportjainkban. Ezen kívül ha nem kampányból érkezik második alkalommal, de konverziót is végrehajt, akkor direct forrásúként fog megjelenni a konverzió, attól függetlenül, hogy mekkora az Analytics-ben beállított data retention-ünk.
Egy jól kialakított szerver oldali méréssel elérhető akár a 100%-os adatpontosság is. Gondoljunk bele abba, hogy egy webshopot üzemeltetünk, akkor pontosan annyi tranzakciót és bevételt láthatunk az Analytics-ban mint a site admin-ban. Ez sci-finek tűnhet a kliens oldali méréshez szokott hirdetőknek, pedig egyáltalán nem az.
Javítani szeretnénk weboldalunk sebességét
A szerver oldali mérési megoldások nem csak az adatpontosságon javítanak, kedvezően hatnak a weboldalunk sebességére is. Ez amiatt történik, mert nincs szükség sok-sok külső script betöltésére. Ehelyett saját közeli szerverünkre küldünk request-eket. Ez a megoldás növeli az oldalbetöltési sebességet és kedvezően hat SEO tevékenységeinkre is.
Nagyobb kontroll a gyűjtött adatok fölött
Sokszor a szerver-oldali mérések bevezetésére adatvédelmi okokból van szükség. A szerverünket lehet használni egy saját proxy-nak is, ami megszűri az adatokat mielőtt az analitikai rendszerekbe érkeznének. Például előfordul olyan use case ügyfeleinknél, hogy weboldal minden input mezőjének értékét viszont szeretnék látni az Analytics-ban. Ezek a mezők tartalmazhatnak személyes adatokat, amiket tilos az Analytics-ba küldenünk. Ilyenkor is jól jön egy saját szerver, ami például kiszűri az ilyen adatokat.
Olyan esettel is találkoztunk már, hogy a jogi team csak akkor hagyta jóvá az Analytics használatát egy adott weboldalon, hogyha a küldött adatok nem tartalmaznak IP címet, mert az személyes adatnek minősül. Ebben az esetben létre lehet hozni egy olyan setup-ot, ahol az IP cím 0.0.0.0 értékkként megy tovább az Analytics-ba. Ezzel a megoldással az IP-alapú GEO-adat meghatározástól sajnos le kellett mondania ügyfelünknek, de ennek fejében a jogi team hozzájárulás nélkül is engedélyezte ügyfelünknek az Analytics futtatását ami sokat segített a kampányattribúcióban.
Szerver oldali méréssel lehetségessé válik akár a profit értékek becsatornázása is az Analytics-ba és hirdetési rendszerekbe. Ennek lényege, hogy a bevétel értékek helyett a termékeken realizált profitot használjuk fel. Alapesetben egy ecommerce oldal esetén a bevétel érték a vásárlások értékének összértéke szokott lenni. Ehelyett van arra lehetőség, hogy egy adatbázisból letöltjük, a vásárlolt termékek profittartalmát és azt küldjük tovább a célrendszerek felé.
Ezzel pontossá válik a ROAS, látni fogjuk pontosan, hogy melyik kampányon mekkora profitra tettünk szert. Mivel a profitrátánk minden esetben üzleti titok, ezért fontos, hogy a konkurencia ne tudja azt „kifürkészni” szerencsére ez a szerver oldali méréssel megoldott, kliens oldalon semmi nem látszik a profit értékeinkből.
Off-site események
A fenti esetekben olyan use case-eket láttunk ahol a szerver-oldali mérés hozzáadott értékekkel bír a kliens oldali méréshez képest. Léteznek viszont olyan megoldások is, amiket egyáltalán nem lehet megoldani szerver-oldali setup nélkül. Ezek azok az események amikor az ügyfelünk nem is tartózkodik weboldalunkon, de vele kapcsolatos interakciót szeretnénk mérni.
Egyre elterjedtebbek az előfizetéses modellek, ahol visszatérő fizetés történik. Ilyen esetekben a bankkártyaterheléskor nincs a látogató az oldalunkon, tehát kliens oldali kódokat nem tudunk futtatni. Szerver oldali méréssel megoldható az, hogy amikor a kártyaterhelés történik bekerüljön a rendszerekbe a bevétel. Természetesen ugyanúgy kampányhoz és forráshoz attribútálva, mintha ott lenne. A látogató mért lifetime value-ja is növekedhet attól függetlenül, hogy nem tartózkodik oldalunkon.
A visszatérítések mérésénél is szükség lehet a szerver-oldali mérésre: ha pontosítani szeretnénk adatainkat, akkor nem csak a bevétel felhasználásáról kell gondoskodnunk, hanem az esetleges sztornókat is kezelnünk kell. Ezek sok esetben nem akkor történnek, amikor a látogató használja oldalainkat, de szerver oldalról gond nélkül kezelhetőek.
Gondoljunk csak bele: azt is lehet automatizálni így, hogyha egy webshop sztornózza a futár által kiszállított, de át nem vett rendelést. Esetleg azt is, hogyha átutalási fizetési mód esetén nem érkezik be határidőre a várt összeg. A sztornók bevezetése alapvetően fontos ahhoz, hogy reális ROAS-t és bevételt lássunk az analitikánkban.
Leadgen oldalaknál is nagyon hatékony a szerver-oldali mérés: Ha a weboldalon látogatónk csak egy formot tud kitölteni, de a végső deal már offline történik, akkor sem kell lemondanunk a bevétel értékekről. Különösen hatékony setup, ha például CRM rendszerünk minden fontos lead mérföldkövét becsatornázzuk Analytics-be, így láthatjuk minden státuszban lévő lead-ünk kampányforrás adatait is, értékkel ellátva. Mekkora különbség ez ahhoz képest, mintha csak a lead form kitöltését kezelnénk konverzióként! Hát bizony hatalmas.
Jó, de ez legális?
Természetesen. A szerver oldali mérés nem arról szól, hogy bármit úgy mérjünk, hogy a látogató nem ad ehhez hozzájárulást. Itt mindössze arról van szó, hogyha megfelelő hozzájárulást ad, akkor valóban meglegyenek az adatok. Tehát szerver oldalról egyáltalán nem mérünk mást, mint kliens oldalról tennénk, csak máshogyan mérünk.
A szerver oldali mérés nem egy feketegalláros tool, csak segít maximalizálni a gyűjtött adatok pontosságát.
Hogyan vezessük be?
Láthattuk, hogy rengeteg esetben jól jöhet vagy egyenesen szükséges szerver oldali mérés ahhoz, hogy megfelelő adatokkal tudjunk dolgozni. Itt az ideje beszélni arról is, hogy hogyan tudjuk mindezt kialakítani.
Sokfajta setup-ra lehet mondani azt, hogy szerver-oldali mérés. Szerver oldali mérés az is, hogyha bérelt webshopunk gyárilag támogatja a Meta Conversions API-t (CAPI), de szerver oldali mérésnek hívjuk azt is, hogyha egy backend-ről indított request-el adatot továbbítunk az Analytics szerverei felé. Mivel nagyon sok megvalósítási mód létezhet, ezért ezek ára és pontossága is hasonlóan széles skálán mozog.
Ahogy már láthattuk igen sok lehetőség van a szerver oldali mérés kialakítására, fontos megtalálnunk azt a setup-ot ami kialakítható nálunk és lefedi adatéhségünket. Fontos, hogy nem minden setup adaptálható minden környezetbe. Ahhoz, hogy ne tévedjünk el az útvesztőben, érdemes inkább megbízni ügynökségünket a szerver oldali mérések bevezetésével.
Lehetőségek a szerver oldali mérések kialakításához
Ha eldöntöttük, hogy szerver oldali mérést szeretnénk bevezetni, több megoldást is használhatunk.
sGTM
A legelterjedtebb megoldás a szerver oldali Tag Manager bevezetése. Ennek előnye hasonló, mint a kliens oldali Tag Manager-nek: egy adatforrásból több célrendszer felé is küldhetünk adatot.
Amire szükségünk lesz az sGTM bevezetéséhez:
- Saját vagy bérelt szerver
- GTM
- Domain rekordok módosítása
Saját vagy bérelt szerver
Az sGTM-ünk egy erre a célra dedikált saját tulajdonú vagy bérelt szerveren futhat. Ügyfeleink sokszor úgy gondolják, hogyha már úgyis üzemeltetnek saját szervert, akkor az sGTM szervert is ők maguk szeretnék megoldani. Ez azonban a gyakorlatban nem szokott megtörténni. A saját szerveres megoldás jóval drágábbra szokott kijönni, mint a bérelt szerveré. Ráadásul nem csak a kialakításnak van költsége, visszatérő költségként jelentkezik a szerver üzemeltetése, karbantartása, valamint az ezzel kapcsolatos HR költségek is.
Nehezít továbbá a dolgon, hogy a Google túl sok információt nem ad a manuális szerver kialakításáról, tehát például minimális rendszerkövetelményeket sem tudunk.
Gyakorlatilag minden esetben bérelt szerver kialakítással szoktunk sGTM tárolót hosting-olni. Erre van lehetőség a Google Cloud-ban, illetve más, direkt erre specializálódott szolgáltatóknál. Mi a Stape.io-t szoktuk javasolni. Ennek a szolgáltatónak árazása egyértelmű, előre tervezhető és olcsóbb mint a Google Cloud megoldásé. Egy csekély forgalmú weboldalon az sGTM hosting ára akár ingyenes is lehet, de közepes forgalom mellett sem drágább a költsége havi €50-nál. A pontos összeget könnyen lehet kalkulálni a szolgáltató weboldalán lévő kalkulátorban.
GTM
Az sGTM bevezetés előtt szükség van GTM bevezetésre is, ha a mérések natív kódokkal voltak elkészítve. Erre azért van szükség, mert a kliens oldali GTM küldi az adatokat a szerver oldali GTM-be, és onnan megy tovább az adat a célrendszerek felé. Tehát a kliens oldali tárolóra is szükség van.
Domain rekordok módosítása
Ahhoz, hogy sGTM-ünk minél ellenállóbb legyen az adblocker-ek ténykedéseire, fontos, hogy a saját url-ünk alatt legyen elhelyezve az sGTM tároló. Tehát ha például valami.hu a weboldalunk url-je, akkor a server.valami.hu alatt futhat az sGTM tároló, így az oda küldött request-ek a mi hostname-ünkre érkeznek meg. Ilyen aldomain-t DNS rekordok módosításával lehet készíteni.
Ennél a megoldásnál is jobb, hogyha a meglévő hostname-ünk alatt egy page path-t alakítunk ki az sGTM-nek, például valami.hu/server lenne az url. Ilyenkor a /server oldalon egy service worker küldené tovább a request-et a server.valami.hu oldalunkra.
A megfelelő aldomain megtalálása fontos feladat: nem érdemes túl egyértelmű neveket adni, pl gtm.valami.hu vagy tracking.valami.hu, nehogy már az elnevezés is blokkolást váltson ki egy-egy adblocker-ből, mert akkor hiába dolgoztunk.
Előnyök és hátrányok
Az sGTM bevezetés minimális fejlesztői erőforrás felhasználásával megoldható, viszont nagy előnyre tehetünk szert a hirdetési rendszerek szemében. Szerver oldali méréseket alakíthatunk ki vele rengeteg célrendszer felé. Bevezethetővé válik a Meta/TikTok/Twitter CAPI, szerver oldalról mehet adat a Google Ads-be, Analytics-ba és mér sok-sok más rendszer felé.
Hátránya ennek a setup-nak, hogy a kliens oldali kódok indítják át adatátadást, tehát nem garantálható 100%-ban, hogy nem blokkolódik valami folytán az adatátadás. Emellett visszatérő költsége is van, ami bár nem magas, mégis számolnunk kell vele.
Backend oldali mérések
Van arra is lehetőség, hogy közvetlenül a backend-ünkről küldjük az eseményeket a célrendszerek szerverei felé. Ebben az esetben nem használunk szerver oldali GTM-et. Előnye, hogy a látogató böngészője nem vesz részt az adattovábbításban, tehát ezzel a megoldással elérhető a 100%-os adatpontosság. További előnye még ennek, hogy egyszeri kialakítási költséggel jár, nincs visszatérő költség.
Hátránya viszont, hogy nagyon nem rugalmas: mivel itt nem használunk GTM-et, minden módosításhoz ismét fejlesztőre lesz szükség. Ezen kívül minden célrendszer felé külön-külön el kell készíteni a méréseket. Ha például az Analytics mellett Meta és TikTok CAPI-t is használni szeretnénk, az három adatátadás, három fejlesztéssel.
Mivel az adatot a backend-ünk küldi a célrendszer felé, ezért az átadott event-nél a saját szerverünk lokációadatai kerülnek be a rendszerekbe. Akinek szüksége van a pontos GEO-adatokra, annak nem ajánljuk ezt a megoldást.
Ezen kívül a backend oldali mérések esetében is szükség van kliens oldalon futtatot kódokra. Ha ezeket a kliens oldalon futtatott kódokat blokkolja valami, a backend-ről küldött event-ek akkor is bekerülnek a célrendszerekbe, viszont kampányattribúcióra már nem lesznek használhatóak. Ez gyakorlatban úgy néz ki, hogy Analytics-ban a konverzió (not set) forrásúként fog megjelenni. Meta esetén pedig nem fog kampányhoz attribútálódni.
Hibrid megoldás
Van lehetőség arra, hogy bevezessük a szerver oldali GTM-et, de a főbb konverziókat backend oldalról küldjük be. Ez a két fenti megoldás előnyeit ötvözi: javítjuk a kiens oldali mérések pontosságát sGTM-mel, de az igazán fontos KPI-ként kezelt event(ek) backend-ről érkeznek be oda, tehát elérhető a 100%-os pontosság. További előnye, hogy csak egy adatátadást kell a backend-en létrehozni ami el tudja látni az összes célrendszert adattal.
Ez egy igazán haladó megoldás, ügyfeleink általában ezt szokták választani.
Gateway-ek
A legegyszerűbb és legolcsóbb megoldás a szerver-oldali mérések létrehozására a különböző gateway-ek. Minden egyes gateway 1-1 célrendszer felé továbbít adatot. Tehát ahány rendszerünk van annyi gateway-re lesz szükségünk. Előnye, hogy nagyon olcsó: havi €10 körüli összegbe kerül egy gateway bérleti díja az általunk preferált stape.io-nál.
Ezért a pénzért viszonylag magas eventszám korlátot kapunk, egy közepesen-nagy forgalmú weboldalt le lehet vele fedni. A pontossága megegyezik az sGTM pontosságával, tehát elméletileg blokkolható az adatátadás, mert nem backend oldali mérést valósít meg.
A beüzemelése nagyon egyszerű egy gateway-nek, megfelelő jogosultságok birtokában pár perces feladatról van szó.
Ha egy-kettőnél több célrendszerre is szükségünk van, akkor érdemes lehet inkább az sGTM-ben gondolkodni, mert forgalomtól függően akár olcsóbbra is kijöhet annak beüzemelése, illetve az egy sokkal rugalmasabb ökoszisztéma.
Weboldalunkban egyébként mi is Google Tag Gateway-t használjuk, mert nincs szükségünk más célrendszerre, csak pontos adatot szeretnénk látni weboldalunk látogatottsáságól.
Hátránya a gateway-eknek is, hogy a pontos földrajzi adatoktól sajnos búcsút kell vennünk: az Analytics-ban a szerver lokációját látjuk, ami legtöbb esetben magyarorországi látogató esetén Ausztria. Ha valakinek fontosak a GEO-adatok, azoknak nem javasoljuk a backend oldali mérés mellett a gateway-ek használatát sem.
Konklúzió
Láthattuk, hogy a szerver-oldali mérések bevezetése egy igen tág fogalom ami sok mindent jelenthet. Jelentheti egy néhány eurós gateway használatát, de akár egy több ezer eurós fejlesztést is. Fontos látni, hogy egy megfelelően bevezetett, de olcsó megoldás adaptálásával is hatalmasat léphetünk előre adatpontosságban, attribúcióban. Persze mindent lehet jobban csinálni, ezért ha fontos a pontosság, akármilyen tökéletes setup-ot is létre lehet hozni.
2025-ben kvázi megkerülhetetlen szükség van szerver-oldali mérésekre olyan szegmensekben is, amik korábban megvoltak kliens oldali mérésekkel is. Azonban nagyon fontos a megfelelő kivitelezés is:
- Figyelembe kell venni a weboldal meglévő adottságait;
- Az elérendő mérési célt;
- A rendelkezésre álló erőforrásokat
Ha nem megfelelően alakítjuk ki a dolgokat, akkor nem lesz több adatunk szerver oldali mérések mellett sem, viszont nyakunkba veszünk egy plusz költséget. Épp ezért javasoljuk, hogyha szerver-oldali mérések kialakításába szeretnél belevágni, akkor kérj tőlünk ajánlatot és segítünk benne.
Ügynökségünk az első hazai ügynökség volt aki elérte a Stape partneri státuszt, és azóta sincs túl sok ilyen ügynökség. Szükség esetén kiemelt support-tal és kimagasló tapasztalatunkkal tudjuk támogatni ügyfeleinket.
