De mi van akkor, hogyha pénteken még minden rendben volt egy általad hirdetett fogászat Meta kampányaiban, hétfőn meg azzal szembesülsz, hogy egész hétvégén egyetlen Lead sem érkezett? A kampány elkezd kiszáradni: pénteken még látta a konverziót, hétfőn már nem látja. Közben semmin nem változtattatok. Furcsa, nagyon furcsa… Az Analytics-ben minden rendben, de a Meta egyszerűen nem látja a konverziókat. Kezdhetsz aggódni.

Mi történik?

A Meta folyamatosan figyelgeti a pixelen és a CAPI-n átadott adatokat és ezekből következtet arra, hogy milyen tematikájú egy adott oldal. Megnézi a hostname-et, page path-t és az url paramétereket is. Az oldalakat bizonyos kategóriákba helyezi aszerint, hogy milyen url-ek vannak az adott site-on. Mindezt azért teszi, hogy kiszűrje azokat az oldalakat, akik esetleg a Terms-nek nem adatot adnak át a Metának.

Bizony a Terms-ben szerepel olyan kitétel, hogy nem adhatunk át egészségügyi információkat a Metának. Ha viszont a Meta pixel lefut például egy bestever.md/ful-orr-gegeszeti-mutetek (kitalált) oldalon, akkor pontosan egészségügyi információt adunk át a Metának: aki ezen az oldalon jár alighanem olyan problémával küzd, hogy ilyen kezelésre legyen szüksége – és ezzel meg is valósítottuk a tiltott adatok átadását a Meta felé.

Így sajnos szembementünk a Terms-szel, pedig mi igazából semmi rosszat nem tettünk: csak kint a pixel a weboldalon. Sajnos nagyon könnyű belefutni egy ilyen blokkolásba, ahonnan már sajnos nem nagyon van kiút.

Milyen témájú oldalakat tilt a Meta?

A már említett egészségügyi oldalakon kívül tiltja például a szerencsejáték, felnőtt, fegyver, vallás, dohány, fintech témákat és még sok mást is. Sokszor tiltottak az ügyfélportálok, regisztrációs kapuval rendelkező oldalak is.

A legnagyobb fejtörést a legtöbb hirdetőnek mégis az egészségügyi, fogászati oldalat tiltása okozza. Ez egy hatalmas piac, rengeteg ügyfél lehet érintett ezekben a tiltásokban.

Külső foglalórendszerek

Fontos megemlíteni, hogy a külső foglalórendszerrel rendelkező egészségügyi szolgáltatók szerencsés helyzetben lehetnek. Ha a foglalás nem közvetlenül a szolgáltató blokkolt domain-jént történik, hanem egy külső url-en, azok a szolgáltatók megúszhatják a tiltást. Nincs Meta tiltás például az itthon népszerű Medio oldalán. Ennek oka az, hogy nem használnak olyan url-eket amik tiltást okozhatnának. Nézzünk egy kitalált Medio-s url-t: besteverdoctor.mymedio.hu/doctors?specializationId=86435 nincs benne semmi olyan, ami szenzitív egészségügyi információt tartalmazna. Így a mymedio.hu domain-t nem tiltja a Meta, és az őket használó egészségügyi szolgáltatókat nem éri konverzió kiesés.

Nem kapunk (sajnos) pénzt a Medio-tól az ingyen reklámért, csak az ő példájukon keresztül szerettük volna bemutatni a blokkolási logika működését. Ha például a Medio foglalót iFrame-mel betennénk a blokkolt bestever.md oldalba, akkor nem lenne konverziókövetés a Meta felé, külső foglaló használata esetén pedig lenne.

Auditunk

Egy automatizált folyamattal több mint 36 ezer Meta pixel-lel rendelkező egészségügyi oldalt auditáltunk, ezeknek az oldalaknak a 41,2%-a került blokkolás alá.

Az auditáltak közül több mint 15.000 hirdető blokkolt, ami egy óriási szám! Ezek az oldalak nem tudna úgy hirdetni mint a versenytársaik akiket nem blokkol a Meta. Másrészről ez hatalmas üzleti pontenciál is a nem blokkolt hirdetőknek, mert ha megoldják a blokkolást akkor egy válogatott versenyben tudnak részt venni.

Még ennyi weboldal auditja után sem rajzolódott ki igazán egy pontos kép, hogy mi alapján blokkolja X oldalt a Meta, ha Y oldalt nem. Még akkor sem, hogyha egyébként a két oldal ugyanahoz a Business Manager-hez is tartozik. A Meta szúrópróbaszerűen tesz tiltást egyik-másik oldalra, látszólag teljesen random módon.

Milyen tiltást kap a weboldal?

A Meta tiltása háromszintű lehet:

Minimális tiltás: Core setup

Ilyenkor csak page path-okat és/vagy url paramétereket tesz elérhetetlenné a Meta. Ez azt jelenti, hogy például talált olyan url paramétereket a Meta, amit inkább elrejt. Például ha egy pénzügyi oldalról van szó és a futamidő át van adva url paraméterként, akkor azt általában tiltja. Ezzel a tiltástípussal nem igazán van dolgunk. Arra kell figyelni, hogy egyéni konverziókat és célközönségeket nem tudunk definiálni a letiltott paraméterek vagy oldalak alapján.

Közepes tiltás: Bizonyos standard event-ek tiltása

Itt már komolyabb probléma van: A Meta-nak nem lehet átadni bármilyen event-et. Rendszerint a közép és alsó funnel event-eket tiltja a Meta. Például CompleteRegistration és Lead. Ezekre innentől kezdve nem lehet kampányt optimalizálni és az esetleg ezekre optimalizált kampányok nem kapnak a tiltástól kezdve friss event-eket. A kampányok továbbra is optimalizálhatóak nem tiltott event-ekre, vagy landing page view-ra.

Teljes tiltás

A Meta teljesen blokkolja az adatátadást az így kategorizált oldalról. Ez azt jelenti, hogy még PageView sem igazán érkezik be, vagy csak nagyon limitált számban. Teljes tiltás esetén a legtöbb amire optimalizálhatunk a hirdetéskattintás, ami igencsak távol áll a konverziótól.

Mit lát ebből a hirdető?

Alapesetben nem túl sokat. Egy borús napon a Meta Business Manager adminja kap egy emailt arról, hogy az adott oldal 30 nap múlva adatatadási korlátozás alá fog esni. Az email ugyanolyan, mint bármelyik Meta BM system email: könnyű figyelmen kívül hagyni. Ez különösen akkor veszélyes, hogyha a PPC kampánymenedzer nem admin a Business Manager-ben: csak az ügyfél kapja meg az adott emailt, és mivel nagyjából egyik ügyfél sem érti, hogy miről szól, így az infó elsikkad, hogy 30 nap múlva bizony probléma lesz a konverziókövetéssel. Az email maga így néz ki:

Ha ilyet kap a Meta BM adminja, akkor az azt jelenti, hogy 30 nap múlva az eddig ismert konverziókövetésnek vége. Mikor ez az email megérkezik, a Meta Event Manager-ben megjelenik egy tájékoztató üzenet is:

Aki hozzáfér az Event Manager-hez és nem admin a Meta BM-ben innen is megtudhatja, hogy itt bizony nagyon hamar probléma lesz. De úgy gondolom nem sok PPC kampánymenedzsernek van dolga az Event Manager-ben, tehát valószínűleg innen sem egyszerű tájékozódni.

Ugyanitt az Event Manager-ben lehet fellebbezni a döntés ellen a Manage categories gomb segítségével. Ezt csak akkor érdemes megtenni, hogyha valóban tévedett a Meta automatizmusa és olyan kategóriába sorolta be a weboldalt, amibe nem tartozik. Ha a kategorizálás helyes, akkor alkalmazkodni kell a megváltozott helyzethez.

Mi történik 30 nap múlva?

Amint letellik a türelmi időszak, ismét érkezik egy system email a Metától és ismét csak a Meta BM adminok kapják azt meg:

Egyúttal persze az Event Manager üzenet is megváltozik:

Ez azt jelenti, hogy mostantól sosem tudtok megfelelően konverziós kampányokat futtatni a Metán? Szerencsére nem, de az biztos, hogy nem ugyanúgy ahogy eddig.

Ami nem működik

A probléma tehát a domain név. Épp ezért nem megoldás az, hogy új pixelt teszünk az oldalba. A domain blokkolt, így az új pixelen keresztül sem lehet adatot átadni onnan a Meta felé.

A Meta Conversions API bevezetése egy nagyszerű lépés, hiszen több adathoz juthat a Meta, amit jobb eredményekkel tud meghálálni. Ha viszont azért vezetjük be, hogy a Meta által a pixelre tett tiltás megszűnjön, akkor sajnos csalódni fogunk – nem fog megszűnni. Ugyanis magát a domain nevet kategorizálta be a Meta olyan kategóriába, amikre adatmegosztási korlátotásokat tett.

Működhet egy olyan megoldás, hogy regisztrálunk egy új domain nevet, áttesszük oda az egész weboldalt és a page path-okat olyanra alakítjuk, hogy sose jöjjön rá a Meta, hogy egészségügyi weboldalunk van. Ezt az ötletet szerintem már csírájában el kell felejteni, mert brand és SEO szempontból ez a legrosszabb amit tehetünk.

Ami valóban működik

A feljebb bemutatott közepes és teljes tiltás esetén ugyanaz a megoldás. Az, hogy 1-1 event-et blokkol a Meta vagy teljeskörűen az egész domain-t az üzletünk számára kvázi mindegy. Mindkét esetben nagy korlátozás ez a hirdethetőség szempontjából.

A cél tehát az, hogy a Meta ne lássa a domain-t ahonnan az adat érkezik és ne kapjon olyan page path-t ami esetleg újra kiválthatná a blokkolást. A Meta pixelt tehát el kell felejtenünk, mert nem lehet befolyásolni, hogy milyen adatokat adjon át a Metának: ahol lefut, onnan átadja a site url-t. A megoldás egy 100%-os Meta Conversions API setup: a Meta kizárólag CAPI-n keresztül kaphat adatot és az átadott adatban meg kell változtatni az esemény forrás paraméterét, hogy ne blokkolt domain-t küldjön és olyan page path-t ami vélhetően ismét blokkolást váltana ki.

Adatátadás kizálólag CAPI-n keresztül

A megoldást sGTM-mel vagy backend oldali méréssel lehet megfelelően kialakítani. Ez viszont nagy költség lehet, illetve mindenképpen szakavatott team-et (Crew-t ) kell bevonni a projektbe, hogy ez a probléma megoldódjon. A projekt során kiemelten fontos odafigyelni arra is, hogy az event match quality ne merüljön le a mélységekbe a setup után, különben a Meta nem fog megfelelően attribútálni.

Egy CAPI only setup esetén ez a legnagyobb bökkenő amit meg kell oldani: a Meta pixel jelenléte önmagában sokat tesz az attribúcióért, pixel nélkül sok dolgot manuálisan kell megoldanunk. Ha nem megfelelően kerül kialakításra egy CAPI only szerver-oldali mérés, könnyen két szék közé eshetünk. Lesz mérésünk, csak nem attribútálható. A setup komplexitása miatt egy ilyen projekt sokszázezer forintosra nőhet, hogyha adatot akarunk újra átadni a Metának. Sok kisebb vállalkozásnál nincs erre megfelelő büdzsé.

Végül az adu ász: Metamorph

Erre a problémára készítettük el a Metamorph-ot, ami keresztülvágja ezt a gordiuszi csomót. Ez egy előfizetéses szoftver, aminek pixelenként havi 100 EUR + áfás árát a legkisebb blokkolt egészségügyi intézmény is ki tudja termelni.

A Metamorph használatakor tulajdonképpen ugyanaz történik a háttérben, mintha sGTM-mel mérnénk, de sokkal egyszerűbben. A Metamorph teljesen a pixel helyébe tud lépni, például lementi a megfelelő attribúcióhoz szükséges cookie-kat. Az adatokat pedig Conversion API-on keresztül adja át a Metának egy site számára generált domain nevet használva adatforrásként.

Ezzel meg tudja kerülni a blokkolást, mert a Meta azt fogja látni, hogy egy eddig ismeretlen domain-ről kap adatot ami nem szerepel a blokkolási listáján. Az adatokat pedig page path nélkül adja át, így nem tud blokkolást sem kiváltani a Metától az új domain-re.

A Metamorph bevezetését némi GTM fókuszú technikai tudással felvértezett szaki meg tudja lépni, de jelenleg korlátozott ideig a setup-ot ingyenesen el is készítjük mi. Az előfizetés egy ingyenes 7 napos trial-lal indul ami idő alatt gond nékül meg lehet győződni a tool hatékonyságáról. Illetve bármikor lemondható a Metamorph ha szükséges.

Tiltott az oldal?

A tiltás tehát elég technikai dolog, ráadásul nehezen detektálható ügyfél vagy PPC szemmel. Erre a problémára van a Metamorph audit amivel bármilyen oldalról megállapítható, hogy jelenleg blokkolja-e a Meta vagy sem. Az eszköz a domain név megadása után meg tudja mondani, hogy az oldal

• Nem blokkolt
• Egyes szintű blokkolása van
• Kettes vagy hármas szintű blokkolása van Ez utóbbi esetben lehet szükség a Metamorph használatára vagy blokkolást megoldó sGTM setup bevezetésére.

Ha esetleg egészségügyi PPC ügyféljelölt jön szembe egy ügynökségnél, akkor érdemes a Metamorph auditot is megfuttatni a weboldalra ajánlatadás előtt, hogy tudjuk hányadán állunk.

Mi a DataCrew részéről drukkolunk, hogy minden tiltásban érintett hirdető és ügyfél megoldja a nyakába szakadt tiltásokat.

Key takeaways

• A Meta nem a pixelt blokkolja, hanem a domain nevet magát – ezért új pixel nem oldja fel a blokkolást.
• Háromféle blokkolás lehetséges, ezekből az első szint nem komoly probléma.
• Nagyjából az egészségügyi business-ek 41.2%-a érintett a nyugati világban. Magyarországon 31.1% ez a szám.
• A tiltás megoldható megfelelő szerver-oldali méréssel vagy a Metamorph bevezetésével.

The post Minden a Meta adatátadási korlátozásáról first appeared on DataCrew Blog.

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.

The post Minden a szerver oldali mérésről first appeared on DataCrew Blog.