Egy ilyen céglistát ugyanis nagyszerűen lehet használni LinkedIn Ads-ben. Fel lehet tölteni egy cégeket tartalmazó csv file-t, majd a rendszer az adott cégnél dolgozókból készíthet egy célközönséget. Hatalmas potenciál van ebben: a B2B hirdetés alapvetően egy elég nehezített pálya, de ha valami alapján van egy szűrt listánk az tűpontos célzást tehet lehetővé.

Legális ez?

Személyes adattal egyáltalán nem találkozunk, kizárólag nyilvánosan elérhető cégadatokkal. A cégadatból a LinkedIn készít az ott dolgozókból egy audience listát, de konkrétan nem tudjuk kik szerepelnek rajta. Így vélhetően ez a folyamat nem okozhat jogi bonyodalmakat, de mindenképpen szükséges adatvédelmi szakjogász bevonása aki nevét adja ehhez a folyamathoz.

Mire van szüksége a LinkedIn-nek a jó eredményekhez?

A LinkedIn a megkapott listát igyekszik megfeleltetni a LinkedIn-en szereplő cégeknek. Ezután pedig az ott dolgozó embereket teszi fel egy listára akiknek hirdethetünk. A céglistának tartalmazia kell többek között a cég nevét, weboldalának domain nevét, kategória, város, irányítószám, ország. A jolly joker a LinkedIn cég url, hiszen ha azt megkapja akkor nincs kérdés hogy melyik cégre célzunk.

A lista akkor tölthető fel, hogyha legalább 300 céget tartalmaz, de maximum 300.000-et. Magyarországon egészen pontosan 300 darab blokkolt egészségügyi szolgáltató céget sikerült azonosítanunk, így van egy magyarországi egészségügyi blokkolt listánk is egyébként.

A lista feltöltése után a LinkedIn 2-3 napig igyekszik match-eltetni a kapott adatokat a cégeivel. Ha sikerül a match 1-1 cégre, akkor az ott dolgozókat felveszi egy listára akiknek már hirdethetünk. A folyamat végén látunk egy match rate-et, hogy mennyire sikerült a folyamat. 80% fölötti match rate már jónak számít, de sokszor 90% fölötti listát is sikerül létrehozunk.

És a többi hirdetési rendszer?

Sajnos lehetőségeink kizárólag a LinkedIn Ads-re korlátozódnak. A többi elterjedt felületen csak first party user adatokat tudnánk feltölteni. Viszont ahhoz, hogy legyen ilyenünk, kifejezett hozzájárulását kell hogy adja a user, hogy listára tegyük.

A LinkedIn egész máshogy működik: nem személyes adatokat használunk fel, hanem nyilvánosan elérhető adatokból képzünk listát. A jogi perspektívákon kívül valószínűleg az eljárás nem is lenne hatékony. A Google/Meta/etc. felületek személyes adatokat (email címet, telefonszámot) várnak el, weboldalon lévő hello@ kezdetű email címekkel aligha lenne meg a megfelelő match rate. Illetve az adott felületek felhasználási feltételeit sértenénk meg már magával a feltöltéssel, így az ilyen felhasználást nem javasoljuk.

Hogyan működött auditunk?

A Meta blokkolása egy technikai dolog. A Meta pixel ha lefut, akkor egy config file töltődik be. Ez a config tartalmazza azt, hogy az adott weboldalon van-e blokkolás és ha van, akkor milyen szintű. Konkrétan ki lehet olvasni a config-ból, hogy milyen szintű tiltása van a domain-nek ha fefut rajta a pixel.

Tehát nekünk csak egy domain nevet kell tudunk ahhoz, hogy megállapítsuk róla, hogy blokkolja-e a Meta. Persze azért nem ilyen egyszerű a dolog, mert sok oldalon példásul csak consent elfogadás után fut le a Meta pixel (nagyon helyesen). Szóval ahhoz, hogy sok-sok oldalt le tudjunk auditálni egy automatikus folyamattal szükség van egy headless böngészőre, ami

1. Megnyitja a domain-t
2. Elfogadja a marketing sütiket
3. Megnézi, hogy van-e Meta pixel
4. Ha van, akkor megnézi a facebook pixel config-ban, hogy van-e blokkolás
5. Ha van, akkor be kell gyűjteni a struktúrált adatokból vagy máshonnan minden szükséges adatot, hogy a LinkedIn megfelelően tudja azonosítani a céget
6. Ezekből pedig egy listát kellett képezni amit később feltölthetünk LinkedIn Ads-be

Az egész folyamatot Claude Code-dal raktuk össze, és a futtatásokat is az felügyelte. A futtatás körülbelül 1 hétig tartott. Ezidő alatt a Claude nem evett túl sok token-t. A számítógép futtatta a script-et amit a Claude írt. Persze a Claude a futtatás közben mindenféle statisztikákat gyártott az audit eredményéről, illetve pár óránként elmondta hol tart a folyamat. Tehát az AI számlát sem dobja meg túlzottan ez az ügyféljelölt-átvilágítás.

De honnan tudta az a headless böngésző, hogy milyen weboldalakat vizsgáljon?

Nyilvános adatbázisokból. A folyamathoz két adatbázist használtunk fel. Mindkettő teljesen ingyenes és jól struktúrált:

• OpenStreetMap
• Overture Maps

Tulajdonképpen rá kellett szűrnünk az egészségügyi szolgáltatókra egy adott országban. Az így megkapott lista már tartalmazott néhány adatot amikre szükség volt a LinkedIn számára. Ilyen volt a céges email cím, város és irányítószám. De a legfontosabb adat ezekben az adatbázisokban az adott cég weboldala. Hiszen mint feljebb bemutattuk, nekünk csak egy weboldal url kell ahhoz, hogy auditálni tudjunk.

Amint az adott cég domain-je elérhető, végig tudunk menni az auditálási folyamatokon. Persze nincs két egyforma weboldal, így előfordulhat olyan eset, hogy például nem tudja a headless browser feloldani a consent bar-t, esetleg nem tartalmaz a weboldal struktúrált adatot. Ilyenkor bizony az adott weboldalon kell totóznia a headless browser-nek, hogy megtalálja például a Kapcsolat oldalt, hátha ott találhatóak a számunkra aranyat érő információk.

Az ilyen plusz körök miatt az audithoz megfelelően erős (sok RAM-mal ellátott) számítógépet érdemes használni. Figyelni kell arra is, hogy párhuzamosan hány weboldalt auditáljon a headless böngésző.

Mire lehet ezt jól használni?

Mi tehát arra használtuk a folyamatot, hogy egy adott dolgot kiderítsünk az ügyféljelölt weboldaláról. Ugyanezt a folyamatot használjuk egyébként a Metamorph audit oldalán, csak ott az audit valós-időben történik. Tehát ha például LinkedIn-en meghirdetjük az audit oldalt az így nyert célközönség körében, akkor garantált a siker. Olyanok látják a hirdetést akikről mi már tudjuk hogy blokkolja őket a Meta, így a weboldali audit folyamat eredménye egyébként borítékolható.

Viszont nem kötelező auditálni a weboldalakat sem. Tehát lehetséges olyan ügyféllista elkészítése is ami egyszerűen a fenti adatbázisokra épül, weboldalról begyűjtött extra adatokkal fűszerezve. Készítettünk már például egy globális PPC-ügynökség listát is az adatbázisban szereplő adatok alapján.

Korlátok

Persze a folyamatnak megvannak a maga korlátai. Az adatbázisokban csak azok a cégek szerepelnek amiknek van fizikai üzletük/székhelyük vagy telephelyük. Teljesen online cégeket (mint sok PPC ügynökség) nem tartalmaz az adatbázis, így a listánk sem. Egészségügyi szolgáltatóknál általában ilyen probléma nem merül fel.

Eredmények

Lássuk hát hogyan működött az így nyert listánk! A már beharangozott 300 magyarországi Metán blokkolt egészségügyi szolgáltató céget tartalmazó listára hirdettünk rá egy Thought Leader Ads-et. LinkedIn-en kevésbé járatosaknak írjuk: Ez egy olyan hirdetési mód, amikor a cég egyik alkalmazottja (általában vezetője) a saját LinkedIn feed-jébe ír egy postot, majd egy cég azt kiemeli. Így hát Péterünk írt egy magyar nyelvű post-ot ami a Meta blokkolással foglalkozó blogpost-ot tartalmazta.

Az azonosított egészségügyi cégeket tovább szűkítettük azokra ahol 1-50 dolgozó van, hogy a legnagyobb Metán blokkolt cégeket kiszűrjük. A LinkedIn-en lehetőség lenne senior-ítás szerint is szűrni, de ezúttal ezzel nem éltünk.

Az eredmény 7.69%-os CTR lett, ami egy egyszerű képes LinkedIn hirdetésnél véleményünk szerint kimondottan szép eredmény.

The post B2B ügyféljelölt lista LinkedIn Company List-hez first appeared on DataCrew Blog.

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.

Mi ez és miért jó nekünk?

Az offline konverziómérés az, amikor egy nem online történő eseményből származó adatot küldünk el a hirdetési rendszereinknek. Ezekre a konverziókra is ugyanúgy lehetséges kampányt optimalizálni, mint az online konverziókra.

Elsősorban leadgen oldalakon lehet releváns az offline konverziókövetés, de ismerünk olyan agrár webshopot is ahol nagy szükség volt a telefonon történő offline konverziók pontos mérésére. Ezeken az oldalakon jellemzően van egy kapcsolatfelvételi form, esetleg egy telefonszám és netán egy kattintható email cím. Kizárólag online konverziókövetéssel miket tudunk itt mérni? Form kitöltést, telefonszám és email cím kattintást. De ezek bizony elég soványak konverziónak:

• Oké, hogy kitöltötte a formot valaki, de lehet, hogy teljesen irreleváns a kitöltés és sosem lesz belőle konverzió;
• Egyáltalán nem biztos, hogy aki kattint egy telefonszámra az utána fel is hívja. Sőt, egyébként legtöbben nem is kattintanak telefonszámra hanem bepötyögik telefonjukba – kimértük ezt. Ha esetleg telefonál is a telefonszám kattintó, egyáltalán nem biztos hogy bármi üzletünk számára releváns dolog történik a hívásban;
• Az email cím kattintás általában még nagyobb lutri. Ez csak akkor működik, hogyha a user az alapértelmezett email kliensével szeretne emailt küldeni azonnal – ami sem túl életszerű elképzelés.

Az ilyen csatornákon szerzett konverziók mérése alapvetően fontos ahhoz, hogy valódi eredményekre tudjon optimalizálni a hirdetési rendszer. Véleményünk szerint az ilyen-olyan kattintások csak mikrokonverziók lehetnek. A form kitöltés már azért valamilyen relevanciát jelent, de lássuk be hogy az sem az igazi.

Akkor tehát hogyan lehet megfelelően megoldani a konverziókövetést olyan oldalakon ahol ezekre a csatornákra építenénk a kampányoptimalizálást? Offline konverziókkal!

Technikai háttér

Az offline konverzióknak mindig van online előzményük. Tegyük fel, hogy a látogató aki sikeresen végrehajtott egy deal-t mondjuk Google Ads kampányból érkezett a weboldalra. Ilyenkor ahhoz, hogy offline konverziót küldjünk be, a weboldali landoláskori click id-ra (gclid) kell hivatkoznunk. Ennek segítségével tudja az Ads megfelelő kampányhoz attribútálni a későbbi offline konverziót. Offline konverziót a Google Ads-be háromféleképpen lehet küldeni:

1. Enhanced conversions for Leads – Ilyenkor beküldjük a Ads-be a form kitöltő hash-elt személyes adatait (email cím, telefonszám) és a conversion linker által rögzített gclid-et. A Google szépen lementi, hogy milyen hash-ekhez milyen gclid tartozik. Így ha később megkap mondjuk egy hash-elt email címet, akkor ki tudja keresni a hozzá tartozó gclid-et és be tudja húzni a konverziót a megfelelő kampányhoz;
2. Mi magunk mentjük le a gclid-et és ha beküldjük az offline konverziót, akkor átadjuk a lementett gclid-et is, és ez alapján tudja az Ads a megfelelő kampánynak adni a kreditet;
3. Ötvözzük a kettőt: form beküldéskor beküldjük a user adatokat, de mentjük a gclid-et is. Offline konverziókor pedig küldjük mindkettőt – ez a Google szerint medián 10% match rate növekedést jelent.

A Meta, TikTok, LinkedIn és a többi platform offline konverziói kicsit máshogyan működnek. A lényeg azonban ott is ugyanaz: online előzménye kell legyen az offline konverzióknak. Ehhez a látogató eszközéről click id-kat, cookie értékeket és hasonlókat kell lementeni, amikre hivatkozva utólag beküldhetők az offline konverziók.”

Hogyan mérhetjük az offline konverziókat?

Régebben ehhez komoly fejlesztés kellett. A fejlesztőknek egy belső adatbázisba menteni kellett mindenféle id-t, cookie értéket, consent szintet, stb. Ez ma már sokkal könyebb, mert vannak kész megoldások is rá. Sőt, mi is fejlesztettünk egyet, ezt mutatjuk be a továbbiakban. Ismerkedjetek meg a Phonevert-tel.

A Phonevert-et bármilyen weboldalba lehet integrálni weboldal motortól függetlenül. A telefonszámok vagy emailek követéséhez egy egysoros kódot kell elhelyezni a weboldal kódjában, amit akár Google Tag Manager-ből is meg lehet tenni – még GTM tag template is van hozzá. A form beillesztése a weboldalba hasonlóan könnyű feladat, de ahhoz akár fejlesztői támogatásra is szükség lehet.

Hívások követése

A Phonevert úgynevezett Dynamic Number Injection (DNI) megoldást használ a weboldalon lévő telefonszámok követésére. Ez azt jelenti, hogy a következő folyamat történik:

1. A Phonevert megkeresi és átírja a weboldalon lévő telefonszámokat egy egyedi proxy telefonszámra. Ezt a telefonszámot egy user kapja meg egy böngésző session-ben. Így ha erre a telefonszámra hívás érkezik, akkor pontosan tudjuk hogy melyik user telefonált, hiszen csak ő láthatta ezt a telefonszámot. Természetesen a céltelefonszámon a hívó száma fog megjelenni, nem a proxy szám.
2. A proxy számra érkező hívás rögzítésre kerül. Ez később vissza is hallgatható a Phonevert felületén;
3. A rögzített hívásból leirat készül, ami elolvasható a Phonevert felületén
4. A leiratot megkapja egy AI agent és konverziót keres benne. Azt, hogy mi a konverzió, szabadszabvasan lehet definiálni. Pl ‘Időpontfoglalás történik’ vagy ‘A hívó megrendelte a szuper porszívó terméket’
5. Ha konverzió történt, akkor a lementett attribúciós id-kra hivatkozva bemegy a hirdetési rendszerekbe

A fenti folyamatban az offline konverzióként bemegy a hirdetési rendszerekbe mint megvalósult hívás – ez sokkal több információval rendelkezik, mint egy telefonszám kattintás esemény, illetve ha konverziót is detektál a hívás leiratában az AI agent, akkor más konverzióként bemegy a megvalósult deal is. Sőt, egyébként Analytics felé ennél lényegesen több adat megy be ami segíti a precíz elemezhetőségét a hívásainknak.

Egyéb híváskövetési funkciók

A híváskonverziókon kívül is sok érdekes adat lehet egy hívásban. Például érdemes lehet elmenteni egy időpontfoglalás esetén az időpontfoglalás idejét, kezelési időt, megvásárolt terméket, stb. Ezeket a Phonevert egyéni dimenzióként tudja menteni és továbbítani a Google Analytics felé.

Időnként szükség lehet arra is, hogy ne csak a weboldalról érkező telefonhívásokat trackeljük. Erre a Phonevert tartalmaz dedikált telefonszám funkciót is. Ez azt jelenti, hogy kapunk egy fix, nem változó telefonszámot, ami mindig a Phonevert-ben beállított céltelefonszámra lesz továbbítva, de ugyanúgy végigmegy a hangfelvétel, AI elemzés, stb folyamaton. Az ilyen telefonszámot elsősorban offline megjelenésre érdemes használni. Pl névjegykártyára, plakátra, pólóra () nyomtatni.

A Phonevert-en keresztül vissza is lehet hívni ügyfelet: ilyenkor a kezelő kap egy proxy számot, amit ha felhív a saját telefonján, akkor az ügyfélnél csörög a telefon. Ez is nagyon hasznos funkció, hogyha éppen nem tudtuk felvenni a telefont.

Sok lépést tettünk, hogy a Phonevert hívás tracking GDPR compliant módon tudjon működni: a hívás kapcsolása előtt üdvözlőszöveget hall a hívó:

Tájékoztatjuk, hogy hívását ajánlatadás céljából rögzíti a DataCrew Kft. és egy évig megőrzi. Adatkezelési tájékoztatónk a weboldalunkon érhető el. Ha nem járul hozzá, keressen minket közvetlenül a +36201234567 számon. A hívás folytatásával hozzájárul a rögzítéshez.

A konverziókövetés is a consent mode v2 flag-ek szerint történik. Pontosan olyan consent-tel megy (vagy nem megy) be a konverzió a hirdetési rendszerekbe amilyen consent szintet a látogató a weboldalon adott.

A lementett hangfelvételt csak a Phonevert-ben lehet meghallgatni, end-to-end titkosítással rendelkezik.

Formok követése

Rengeteg fajta form van már a piacon. A Phonevert-en belül is lehetséges form létrehozása. Az app tartalmaz egy form szerkesztőt, amivel könnyen lehet létrehozni ilyen szép formokat:

(nem ígérem, hogy visszahívlak, ez csak demonak van itt #csaxólok

A formot kitöltők adatait meg lehet kapni emailben, illetve webhook-on keresztül akár CRM rendszerbe is integrálható. Ha valaki kitölti a formot, visszahívásra kerül a lead, majd deal lesz belőle, akkor egy kattintással konvertáltnak lehet jelölni a lead-et és akkor offline konverzióként bekerül a rendszerekbe a deal.
Sőt, a legjobb az egészben, hogyha csak weboldali formokból származó offline konverziót szeretnétek mérni, az limitált lehetőségekkel az ingyenes Phonevert csomagban is elérhető!

Email deal-ek mérése

A Phonevert képes arra is, hogy az email kattintáskor ne az alapértelmezett email kliens nyíljon meg, hanem egy bubble-ben egy mini form jelenjen meg helyette. Ez igazából ugyancsak egy olyan form, mint a fenti, tehát ha deal történik az innen érkező megkeresésből, az szintén be tud menni a hirdetési rendszerekbe offline konverzióként.

Egyéb funkciók

A Phonevert támogatja a konverziók átadását Google Ads, Google Analytics, Meta, LinkedIn, TikTok felé is.

Írhatnánk még nagyon hosszan a különböző Phonevert funkciókról. Lehetne szó például az egységes – CRM jellegű – ügyfélkezelésről, sGTM támogatásról, vagy akár arról is, hogy képes megkerülni a Meta adatmegosztási korlátozását, így Meta által tiltott oldalakon (pl egészségügy) is bevethető a Phonevert. De ezeknél sokkal fontosabb az, hogy a Phonevert-tel a hirdetési rendszer végre láthatja a megvalósult konverziókat, így képes azokra optimalizálni a kisebb konverziós pontok helyett.

Ahhoz, hogy adjunk egy lökést a kipróbáláshoz, a DCBLOG20 kuponkód segítségével 20% kedvezményt kaphattok az első havi csomagárból. Érdemes belevágni

Ügynökségi ügyfeleink egyéni ügynökségi fiókot tudnak regisztrálni. Ügynökségi ügyfélként meghívót tudsz küldeni ügyfeleidnek, ami után minden ügyféltranzakció után 10% jutalékra vagytok jogosultak. A program részletei az Ügynökségi Aloldalon találhatóak. Ügynökségként be tudtok lépni az általatok meghívott ügyfél Phonevert fiókjába, így akár Ti magatok be tudjátok kötni az integrációkat, illetve látjátok a szükséges telepítőkódot is.

The post Offline konverziómérés – Mint a profik 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.

Merengjünk el egy kicsit a nem is olyan távoli múltba, amikor anélkül tudtunk megnyitni egy weboldalt, hogy mindenféle sütikről, cookie-król, felhasználási célokról kellett olvasnunk és meghoznunk egy fontos döntést például egy hasonló felületen:

Nem is volt ez olyan régen! Az egész hacacáré 2018-ban indult. Akkor élesedett ugyanis a GDPR-t, ami meghonosította az Adatkezelő és Adatfeldolgozói szerepköröket, kötelezte a szolgáltatókat sok dologra, például a személyes adatok töröltetésének jogára. Bizony a nagy cégeknek is kijutott a jóból és a Google sem szeretett volna ilyen-olyan büntetésekkel játszani, így hát lépnie kellett.

A megoldás neve: Consent Mode

Azt mindenképpen fontos látnunk, hogy a Google elsősorban nem az ügyfelek és a hirdetők szempontjait nézte amikor bevezetésre került a Consent Mode. Ő csupán a büntetést kellett, hogy elkerülje, ezért találta ki úgy ahogy kitalálta.

Soha, senki nem mondta azt, hogy a Consent Mode bevezetésével meg fogsz felelni a GDPR-nak!

Tehát a Consent Mode bevezetésével nem biztos, hogy megfelel a weboldalad vagy mobilappod a GDPR-nak. A pontos működés kialakításához elengedhetetlen adatvédelmi szakjogász bevonása. Mi nem tudunk és nem is szeretnénk jogi tanáncsot adni, minden további információt ennek fényében vegyen figyelembe a kedves olvasónk.

Mi az a Consent Mode?

A Consent Mode lényege, hogy a látogató megadott hozzájárulása szerint futnak le a Google tag-ek. A tag-ek többféle hozzájárulást is támogatnak:

• analytics_storage
• ad_storage
• ad_personalisation
• ad_user_data

Illetve ezeken kívül is van még néhány, de azok nem befolyásolják a Google tag-ek működését. Ezeket a hozzájárulásokat flag-eknek nevezzük. Mindegyik flag-nek meg van a maga funkciója, akit ez mélyebben érdekel, az nyugodtan pörgesse át a Google ide vágó dokumentációját.

A lényeg tömören az, hogyha azt szeretnénk, hogy látszódjon a látogató a Google Analytics-ban, akkor analytics_storage flag-re van szükségünk, hogyha eredményes hirdetésekre szeretnénk használni, akkor az ad_ kezdetű flag-ek elfogadására is szükség van.

De milyen esetben van erre szükség?

Igazából minden esetben. Ha hirdetsz Google-ben, akkor feltétlenül kell, de érdemes akkor is használni, hogyha csak az Analytics-ot használod. Ez egyébként a weboldaladra és a mobilappodra is igaz. Az appot ugyanúgy el kell látni consent bar-ral és ugyanúgy meg kell valósítanod a Consent Mode-ot mint weben.

A Consent Mode használata nélkül a Google sok-sok hátrányban részesít téged: lehetetlenné válik a remarketing, rosszabb lesz a kampányaid eredményessége és végső soron elmaradsz versenytársaid eredményeitől.

Sajnos a Google előszeretettel használja az ilyen büntetés eszközét abban az esetben, ha nem megfelelően van adaptálva az oldaladba/appodba a consent megoldása. Vannak persze kiskapuk is, például azt jelezni a Google felé, hogy a látogató megadta a maximális hozzájárulást. De higgyen nekem a kedves olvasó,

Egyszerűen nem éri meg.

Ha a Google egyszer büntet, utána már igen nehéz jó eredményeket elérni vele. Ha egy site bekerül egy büntetési körbe, akkor módosítani kell a működést, majd fellebbezni egy form-on. Ezután elindítják az újjabb ellenőrzést, de akkor már nagyon szúrós szemmel harapnak minden egyes hibára és ez utána így is marad. Ezek a fellebbezés utáni ellenőrzések sajnos nem is túl gyors lefolyásúak, egy nagyobb cégnél akár több millió forintos kárt is okozhat egy ilyen eset.

Egyébként nem a Consent Mode bevezetés az egyetlen kritériuma a Google-nek az eredményes hirdetésekhez. Létezik egy checklist is, ami felsorolja, hogy pontosan milyen pontok teljesítésére van szükség ahhoz, hogy a Google megfelelőnek mondja az oldaladat/appodat.

Sajnos láttunk már olyat, hogy a Consent Mode tökéletesen rendben működött egy weboldalon, de a Google kiszúrta, hogy nem tartalmaz az ő privacy aloldalára vezető linket a weboldal, ezért bűntette az ügyfelünket rosszabb eredményekkel. Tehát nagyon fontos a hollisztikus megközelítés: legyen rendben a consent bar, működjön a látogató által beállított preferenciái szerint a Consent Mode, és használjuk a Google checklist-jét.

Advanced VS Basic implementáció

Ha eldöntöttük, hogy a Consent Mode-ot bevezetjük, utána is sok döntést kell meghoznunk. Jogilag a legbiztosabb az a megközelítés, hogy egyáltalán ne menjen a Google felé semmilyen adat, amíg a látogató valamilyen consent-et nem ad. Ezt hívjük basic implementációnak. Habár ez jogilag alighanem a legbiztosabb megoldás, az adatok szempontjából kevésbé az. Ezzel semmi adatunk nem lesz a látogatóinkról amíg nem ad „megfelelő” hozzájárulást.

Az advanced implementáció viszont átad adatokat a Google-nek consent elfogadás előtt és consent elutasítás mellett is. Ezek az adatok az úgynevezett cookieless ping-ek. Személyes adatokat természetesen ezek nem tartalmaznak, viszont segítik a rendszert a nem elfogadók konverzióinak modellezésében.

Összehasonlítva a két implementációs módot, a modellezés a fő különbség: míg a basic módnál gyakorlatilag csak azok a konverziók fognak látszani a rendszerekben amik ténylegesen mértek, az advanced módban igyekszik a Google modellezni a consent-et el nem fogadók bizonyos metrikáit. Ez nagyon hasznos funkció, mert ha rendelkezésre áll a modellezés, akkor egész pontos „tippjei” szoktak lenni a rendszereknek.

Fontos azonban látni, hogy ez nem mért, hanem modellezett adat. Semmiképpen sem egy pontos szám amit láthatunk az Analyticsban vagy Ads-ben. Viszont ahhoz, hogy a modellezés működjön igen sok adatra van szükség. Magyarországi viszonylatban csak a közepes cégmérettől felfelé szokott rendelkezésre állni annyi el nem fogadott consent, amennyi kell a modellezéshez. Ezalatt a méret alatt semmilyen hozzáadott értéke nincs az advanced Consent Mode-nak az Analytics-ban.

Ha viszont nyers adatokkal is dolgozunk, Analytics adatainkat a BigQuery-be exportálva, akkor nagyon jól jöhet az advanced Consent Mode, mert ott megjelennek az analytics_storage consent-et el nem fogadók adatai is, persze anonimizált pseudo id-kkal.

Consent bar

Melyik cookie tool-t válasszam?

Ha eldöntöttük, hogy milyen implementációs módot választunk, ki kell választani egy megfelelő consent tool-t – avagy CMP-t – amin a látogató consent-et tud adni. Azt gondolnánk, hogy mi sem egyszerűbb ennél, de sajnos nem ez a helyzet. Érdemes Google Certified CMP-t választanunk, ezek kvázi dobozos consent tool-ok amit támogatják a Consent Mode-ot.

Nem szeretnénk reklámozni egyik megoldást sem. Fontos figyelni arra, hogy lehetőleg ne blokkoljon semmit sem automatikusan, hanem ki lehessen alakítani manuálisan a megfelelően a blokkolási logikát. Ez azért fontos, mert elképzelhető olyan helyzet amikor a cégünk jogásza engedne egyfajta működést, de az automatikus blokkolás miatt ez ellehetetlenedik. A manuális kialakítás egy sokkal rugalmasabb megoldás tud lenni.

Továbbá fontos, hogy a választott tool megfelelően testreszabható legyen, mert a technikai részletek nagyon fontosak, de akkor lesz magas az elfogadási ráta, ha a kinézet rendben van, azaz magas a consent bar-on a maximális hozzájárulást adók aránya.

Cookie consent bar kinézete

A kinézet, azaz a layout nagyon fontos kérdés. Ha megfelelően járunk el, bevezetjük a Consent Mode-ot, adaptálunk minden pontot a Google checklist-jéről és az egészet megfojtjuk egy rosszul konvertáló consent bar-ral, azzal egy combos öngólt rúgunk: nem lesz adat a hirdetési rendszereinkben, hiába leszünk nagyon GDPR compliant-ek.

Consent layout-ban három fontos szempont van:

• A landoló oldalon adjon consent-et a látogató
• Minél nagyobb részt foglaljon el az oldalból a consent bar
• Tereljük a látogatót a nekünk legmegfelelőbb választás felé

Nézzük meg ezeket a szempontokat sorban!

Landoló oldali consent

Nagyon fontos, hogy a landoló oldalon adjon consent-et a látogató. Miért? Mert ha nem így tesz, akkor elveszhetnek a kampányparaméterei és végül a látogató direct forrásúként jelenhet meg az analitikánkban.

Képzeljük csak el azt, hogy a látogató XYZ utm paraméterekkel érkezik a weboldalunkra. A landoló oldalon egy icipici consent bar van, figyelmen kívül hagyja, de megtetszik neki termékünk és elindul a vásárlási folyamatban. Az első oldalon még megvoltak az utm paraméterei az url-ben, a következő oldalon viszont már nincsenek meg. Ha itt fogadja el a consent-et, akkor a látogatónk hiába megy végig a funnel-en, már csak direct forrású látogató lesz, mert a consent elfogadásakor már nem volt az url-ben kampányparaméter.

Van egyébként lehetőség arra a Consent Mode mellett, hogy az oldalon belüli linkeken továbbítsuk a kampányparamétereket, azaz kezeljük azt a problémát, hogy nem a landoló oldalon consent-el a userünk. Viszont ez sok oldalt egyszerűen használhatatlanná tesz, komoly tesztelés kell hogy megelőzze ennek bevezetését. Másrészt manapság nem kizárólag linkekkel történik egy weboldalon a navigáció, ez a kampányparaméter átadás viszont csak linkeknél működik.

Mindent kitakaró consent bar

Azok a jól konvertáló consent bar-ok, amik landoláskor az egész oldalt kitakarják és rákényszerítik a látogatót a választásra. UX szempontból ez zavarónak tűnhet, de sajnos ez a best practise. Ennek oka elsősorban az előző pont, hiszen az a jó nekünk hogyha az oldalra kerülés első touchpoint-jától kezdve meg van minden adat az analitikában.

Sokan ódzkodnak egy teljes oldalt kitakaró consent bar-tól, de manapság már ez annyira elfogadott, hogy a látogató reflexből kattint a legszimpatikusabb gombra. Persze van olyan weboldal ahol ez nehezen adaptálható, de igyekezzünk törekedni rá.

Látogató terelése a legmegfelelőbb választás felé

Ez bizony már CRO tudomány. El kell érnünk, hogy a látogató a legmagasabb hozzájárulást adja. Ez megtehetjünk előre kiválasztott hozzájárulási szintekkel – amennyiban a jogi team erre lehetőséget ad. Kiemelt színű, formájú mindent elfogadó gombot is használhatunk, vagy akár emoji-t is tehetünk a „kedvező” választással kecsegtető gombra. Határ a csillagos ég! Akár hőtérképes elemzéseket vagy A/B teszteket is igénybe lehet venni a tökéletes layout kialakításához.

Nézzük meg például ezt a consent bar-t:

Itt körülbelül minden el van rontva amit el lehet rontani:

• Fehér alapú oldalon fehét consent bar, ami nagyjából nem takar ki semmit
• A szövegezés nem felel meg a Google checklist-jének
• Default off állapotban vannak a radiogombok, tehát ha a mentés gombra nyomunk ugyancsak nem fogadunk el semmit, mintha nem választanánk vagy az ‘Összes elutasítása’ gombot választjuk. Tehát a három gombból kettővel nem ad consent-et a látogató
• Középen van a mindent elfogadó gomb, nem legfelül
• A gombok túl közel vannak egymáshoz. Ha valaki nagyon consent-et szeretne adni, még akkor is lehet hogy félrenyom és végül nem ad.

Összehasonlításként nézzük meg ezt a consent ablakot:

Jól látható, hogy milyen viselkedést szeretnénk elérni a user-től.

Az első consent tool-nál 16%-os elfogadási rátát mértünk, a másodiknál 94% fölötti rátát, ami hatalmas különbség. Mindezt úgy, hogy közben megadjuk a jogot a user-nek, hogy ne adjon hozzájárulást.

Többi hirdetési rendszer

Nem szeretnénk azt az érzést kelteni látogatónkban, hogy csak a Google-nek van szüksége a consent-re a működéshez. Fontos figyelni arra, hogy minden hirdetési rendszer követőkódja a megkapott (vagy meg nem kapott) hozzájárulás szerint fusson (vagy ne fusson) le. A cikkben kiemelten foglalkoztunk a Google-féle Consent Mode-dal, ennek oka az volt, hogy ez a legkiterjedtebb ökoszisztéma, illetve a Google Analytics és Ads kvázi megkerülhetetlen eszközök.

Ettől függetlenük természetesen sok más hirdetési rendszernek meg van a maga consent megoldása. Általában a többi rendszert hasonlóan szoktuk futtatni mint a basic Consent Mode-ot: Ha ad a látogató consent-et akkor fut, ha nem akkor nem. Például a Meta Pixel-t marketing hozzájárulás mellett szokás futtatni, de még egyszer: a pontos működést a jogi team elvárásai szerint kell kialakítani. Megemlítendő még a Bing Ads, ott hasonló Consent Mode kialakításra van szükség mint a Google esetében, hogy jól tudjon működni a hirdetési rendszer.

Monetizáljuk a cookie kérdést!

Ha nem foglalkozunk a consent-tel és mindent mérünk hozzájárulás nélkül az bizony jogi problémákat okozhat. A GDPR-t bizony be kell tartani, mert ha nem megfelelően kezeljük látogatóink vagy ügyfeleink adatait, akkor akár a cégcsoport árbevételének a 2%-át is kifizethetjük bírságként. Ez egy nagyobb nemzetközi vállalat esetén több millió euró is lehet, ezért nem érdemes kockáztatni. Főleg úgy, hogy láttuk, hogy egy jó megoldással gyakorlatilag nem kell lemondanunk az adatokról sem.

Az, hogy mennyi adatról kell lemondanunk – mondjuk úgy „jogi költségként” – az a jelenlegi állapottól függ. Ha még nincs figyelembe véve a consent a weboldalunkon vagy mobilappunkban akkor szembe kell néznünk azzal, hogy bevezetés után kevesebb adatunk lesz. Másrészt viszont el lehet úgy járni, hogy ez a legkevésbé legyen fájdalmas.

Ha már figyelembe van véve a consent jelenleg, akkor keresni kell azokat az elemeket amik segíthetik a fejlődést, azaz a több maximális hozzájárulás megszerzését. Egy biztos: minél több adathoz jutnak hirdetési rendszereink annál jobban tudnak dolgozni és ezt több bevétellel fogják meghálálni nekünk.

A dobozos CMP-k nagy hátránya, hogy előfizetéses modellel működnek és bizony borsos az áruk. Nekünk van egy saját megoldásunk, amit egyszeri díj mellett be tudunk vezetni a weboldalra, így nincs visszatérő költsége. 100%-ban consent mode kompatibilis, teljes oldalt kitakaró design-nal rendelkezik. Teljesen reszponzív, így mobilon is jól néz ki. Nagy előnye még a dobozos tool-okkal szemben, hogy nem tölt be külső script-et, minden kódot az oldal forrása tartalmaz, így villámgyorsan tölt be ami SEO szempontból is jó lépés. Ha érdekelne a CMP megoldásunk, kérj ajánlatot a weboldalunkon.

The post Minden a cookie consent-ről first appeared on DataCrew Blog.

Szakmánkról

Tudjuk, hogy a szakmánk sokaknak száraz technikai sportnak tűnhet, de mi másképp gondolunk rá: kihívásokkal teli, napról-napra fejlődő (és nehezedő) szakmaként tekintünk az analitikára. Nincs két egyforma analitika szaki, nincs két egyforma setup. Vannak – általában a Google által diktált – iparági standard-ek, de a megvalósításig vezető út minden szakinál egyedi. Egész biztosak vagyunk benne, hogy egy adott feladatot mindenki máshogyan oldana meg, így nem garantálható az sem, hogy mindig a Te gondolatmeneted szerint épül fel egy mérés. Amit igazán szeretünk a szakmában az, hogy a mérési cél mindig egzakt. Ha mérhetővé tettünk valamit, akkor készen vagyunk. Egy mérés beállítása mindig project, nem on-going. Emiatt tervezhető az eleje és a vége is.

Hisszük, hogy az analitika menő.

Nem túl technikai ez nekem?

Tudjuk, hogy a mély technikai részletek elsősorban a szakiknak érdekesek, nem elvárható senkitől, hogy annyira elmélyüljön a digitális analitika rejtelmeiben, mint mi tesszük nap mint nap. A tartalom elsősorban analitikával is foglalkozó ügynökségeknek és freelancer analitikai szakiknak íródik akikből igen kevés van ma Magyarországon. Nem árulok el nagy titkot azzal, hogy alapvetően mi is egy digitális analitikai ügynökség vagyunk, akik megrendelésekből élnek. Bátran kérj ajánlatot a weboldalunkon és segítünk az itt bemutatott vagy még nem bemutatott megoldásokat adaptálni a céged weboldalán, mobilappotokban.

Sok sikert kívánunk a közös munkánkhoz akár ügyfelünkként, akár érdeklődőként, vagy csak lelkes amatőrként szeretnéd jobbá tenni méréseidet, ne aggódj, segítünk!

Tarts velünk, kövess minket LinkedIn-en és GitHub-on is.

The post Hello world! first appeared on DataCrew Blog.