Alapok és adatvesztés
Mi az a szerver oldali követés és miben más, mint a böngészős mérés?
A hagyományos mérésnél a látogató böngészője küldi az adatot közvetlenül a Google-nek és a többi rendszernek. Ezt a láncot sok minden megszakítja: hirdetésblokkoló, böngésző-védelem, rövid élettartamú sütik, lassan betöltődő szkriptek.
Szerver oldali követésnél a böngésző csak az Ön saját szerverének küld adatot, és innen megy tovább, ellenőrzött formában a mérő és hirdetési rendszerek felé. Így kevesebb adat vesz el, és Ön dönti el, milyen mezők hagyják el a rendszert.
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 adatvesztés. Ezt a mérési auditban díjmentesen elvégezzük, még a döntés előtt.
Mi történik, ha a látogató hirdetésblokkolót használ?
A blokkolók névlista alapján tiltják a jellegzetes mérő és hirdetési címeket, ezért a böngészőből induló kérés egyszerűen nem megy el. Magyar webshopoknál ez a látogatók érzékeny hányada, technikai és fiatalabb közönségnél a legmagasabb.
Saját aldoménről kiszolgált mérésnél a kérés az Ön domainjére megy, így jellemzően átmegy. Ez nem a látogató döntésének megkerülése: ha valaki nem járult hozzá a méréshez, az adata továbbra sem megy sehová.
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.
Mi a különbség a régi Google Analytics és a GA4 között?
A régi Google Analytics (Universal Analytics) munkamenetekben és oldalmegtekintésekben gondolkodott, 2023 nyarán leállt. A GA4 eseményalapú: minden interakció (görgetés, kosárba tétel, vásárlás) önálló esemény, paraméterekkel. Ettől rugalmasabb, a beállítása viszont több tervezést kíván.
A szerver oldali követés a GA4 eseménymodelljére épül: ugyanazokat az eseményeket küldi, csak a saját szerveren át. Magyarországon a „google analytics” kifejezésre havonta 8 100, a „ga4” kifejezésre 480 keresés jut a Kulcsszótervező szerint, a téma tehát sok webshop-tulajdonost foglalkoztat.
Adatvédelem és megfelelés
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.
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.
Technikai megvalósítás
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.
Kell hozzá saját aldomén? Mit jelent a first-party kiszolgálás?
Igen, a mérő végpont az Ön saját doménjénél, jellemzően egy aldoménen fut, például adat.sajatdomain.hu néven, saját tanúsítvánnyal. Ez a first-party kiszolgálás: a böngésző szempontjából a kérés nem külső szolgáltatóhoz megy, hanem az oldal saját rendszeréhez.
Ennek két haszna van: a sütik élettartama hosszabb marad, és a blokkolók ritkábban szűrik ki a kérést. A DNS-beállítást és a tanúsítványt mi intézzük.
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.
Lassítja az oldalt a mérés?
A szerver oldali megoldás jellemzően gyorsít: a böngészőnek kevesebb szkriptet kell letöltenie és futtatnia, mert a nehezét átveszi a szerver. A különbség mobilon és gyengébb készüléken a legláthatóbb, ott, ahol a Core Web Vitals értékek is dőlnek el.
A szerver oldali feldolgozás a látogató számára észrevétlen, mert nem az oldalbetöltés útjában történik. A mérési audit része, hogy megnézzük, mennyi felesleges mérőszkript fut jelenleg az oldalon.
Mi az a Google Tag Manager és mi a szerveroldali konténer?
A Google Tag Manager (GTM) címkekezelő: egy helyről irányítható, milyen mérő- és hirdetési kódok futnak az oldalon, fejlesztői beavatkozás nélkül. A hagyományos webkonténer a látogató böngészőjében fut.
A szerveroldali konténer (sGTM) ugyanez a logika egy szerveren: a böngésző egyetlen kérést küld a saját aldomainre, a konténer pedig onnan osztja szét az eseményt a GA4, a Google Ads és a Meta felé. A webkonténer ettől még megmarad, csak jóval kevesebb kódot futtat.
Platformok és események
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.
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.
Mit jelent az Enhanced Conversions és a Meta Conversions API?
Mindkettő arra való, hogy a konverzió a hirdetési rendszerhez akkor is biztosan megérkezzen, ha a böngészős út megszakad. A Google Enhanced Conversions a hozzájárulással megadott e-mail cím titkosított változatát küldi, a Meta Conversions API pedig a vásárlási eseményt továbbítja szerverről.
A kettő együtt használva adja a legpontosabb képet, és mindkettő a hozzájárulási állapothoz igazodik. A WebPot rendszereiben a Meta CAPI bekötés beépített, nem külön fejlesztés.
Hogyan ellenőrizhetem, hogy tényleg jól mér?
Három független forrást vetünk össze egy adott időszakra: a webshop saját rendelési listáját, a GA4 adatait és a hirdetési fiókok konverzióit. Ha ezek 5 százalékon belül vannak egymáshoz képest, a mérés rendben van.
Átadáskor ezt az összevetést írásban is megkapja, és megmutatjuk, hogyan tudja bármikor maga is elvégezni. Így nem kell elhinnie, hogy jól működik: ellenőrizni tudja.
Mi az az adatréteg (dataLayer) és miért ezen múlik a mérés?
Az adatréteg az a strukturált adatcsomag, amelyet a webáruház ad át a mérőrendszernek: termékazonosító, név, ár, mennyiség, rendelésszám, végösszeg. A GA4 e-commerce riportjai, az Enhanced Conversions és a dinamikus remarketing mind ebből dolgoznak.
Ha az adatréteg hiányos vagy pontatlan, a legjobb szerveroldali beállítás is hibás adatot továbbít. Ezért a bevezetés első lépése az adatréteg rendbetétele a webshop kódjában, amit fejlesztőként mi végzünk el.
Ár, határidő, üzemeltetés
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.