Az utóbbi hónapokban egyre nehezebb úgy szakmai beszélgetést folytatni a digitális marketing piacon, hogy ne kerüljön elő a Meta Conversion API. Egy fokmérővé vált: aki használja, naprakész szakember, aki nem, lemaradt. Sok kollégánál ez már nem érv, hanem dogma.
Én ezt nem így látom. Pontosabban azt látom, hogy a CAPI hozzáad valamit a méréshez, csak közel sem annyit, mint amit a marketingje ígér. Ha pedig nem rakod össze pontosan, lehet, hogy a végén ugyanazt méred, csak drágábban és bonyolultabban. Az EU-n belül pedig még egy plusz réteg jön: a hozzájárulás megkerülhetetlen jogi alapfeltétel, és ezt a CAPI sem írja felül.
Próbáljuk darabokra szedni, mit jelent a CAPI az egyes setupokban, és mire jó valójában.
Szükséges, de nem mindegy, hogyan
Természetesen én is tudom, hogy az olyan megoldások, mint a Meta Conversion API vagy a Google Tag Gateway jelentik a jövőállóságot. Ebbe az irányba megy a szakma, ezekkel érdemes fejleszteni az adatgyűjtést. Látok viszont több helyen egy olyan tálalást ezekhez, amivel kapcsolatban régóta motoszkál a fejemben, hogy összeszedjem az ellenérveim.
Mit csinál a Meta Pixel, és mit nem?
A Meta Pixel egy kis JavaScript kód, ami a böngészőben fut le és ott próbál meg adatot gyűjteni. Az adatküldés cím jellemzően a connect.facebook.net és a facebook.com/tr. Az első probléma jellemzően ebből fakad: a legtöbb ad blocker tiltja ezeket a domaineket. Emellett Safari féle Intelligent Tracking Prevention is korlátozza a böngészőben létrehozott, mérési és hirdetési célú cookie-k élettartamát. Mindennek a tetejében a consent banner blokkolja, ha nincs marketing engedély.
Ezek miatt a Pixel sok esetben nem mér: vagy mert blokkolva van, vagy mert nincs jogalap. A CAPI ígérete: „majd a szerver megoldja, amit a böngészőben elveszítünk.”
Ezzel az ígérettel az a baj, hogy minden attól függ, hogyan implementálod.
Hogyan mér a Meta Conversion API server side Google Tag Manager (sGTM) használatakor?
Ez a leggyakoribb setup akkor, amikor valaki server oldali méréseket szeretne kialakítani. Sokan azt hiszik, ezzel megérkeztek a komoly server-side trackinghez, pedig az adat, ami az sGTM-be érkezik, ugyanonnan jön, ahonnan a Meta Pixel is indulna. A böngészőben futó GTM container a forrás. Ha azt egy ad blocker megöli, az sGTM nem kap eseményt, tehát Meta felé sem küld.
A cikk írásakor megnéztük a két legnépszerűbb, Chrome böngészőben is használható ad blockert:
- A uBlock Origin alap beállítása olyan blokkolást használ, ami a Meta Pixel adatküldése mellett a server side GTM felé küldött adatokat is blokkolja, így a Meta CAPI sem tud helyreállítani adatot
- Az AdBlock Plus ezzel szemben olyan alapbeállítással rendelkezik, ami a Meta Pixel méréseit tiltja, ugyanakkor a server side GTM felé küldött Google Analyitcs adatot nem, így ott lehetséges plusz adatokhoz jutni.
Ahol a server side GTM nincs tiltva, ott vélhetően a Google Tag Gateway is működni fog.
Hogy mennyi lehet ez a többlet, az tehát annak a függvénye, egy adott weboldal látogatóinak mekkora része használ hirdetés blokkolót és azok beállításai mennyire vannak agresszívre állítva.
Akkor mi más értelme lehet még?
Tisztán esemény-darabszámra tehát esetleges a nyereség, de három dolgot azért tényleg hoz ez a setup:
- Az egyik a first-party adatgyűjtés. Ha a server side GTM-et a jelenlegi best practice alapján Google Tag Gateway-el egy alkönyvtárba rakod (pl.
jabjab.hu/sgtm), nem biztos, hogy minden ad blocker le fogja tiltani az adatküldést. A content-alapú blokkolók (pattern matching) így is kiszúrják, így fontos kiemelni, hogy sok más esetben, úgy itt sem a hirdetésblokkolók megkerülése az elsődleges nyereség. - A másik a cookie élettartam. A Meta Pixel által létrehozott
_fbcés_fbpcookie-k Safarin maximum legfeljebb hét napig élnek. Ha ugyanezt a cookie-t az sGTM hozza létre, az ITP korlát eltűnhet. Ez darabra nem több esemény, de több olyan mérés, ami párosítható a Meta saját adataival. - A harmadik az ún. server-side enrichment. Ehhez már komplexebb infrastruktúra kellhet, mert ha az ügyfél háttérendszerében van hashelt e-mail cím, telefonszám, akkor ezeket a server-side Google Tag Manager hozzáteheti az eseményhez, miközben a Pixel ezeket nem biztos, hogy ismeri. De ehhez olyan hozzáférésekre van szükség az ügyfél vevő adatbázisához, ami eddigi tapasztalataink szerint ritkán elérhető. Ha viszont működik, akkor ez emeli az ún. Event Match Quality pontszámot.
Fontos tehát kiemelni, hogy ezekkel a javításokkal lényegesen magasabb eseményszám nem várható, ahol ez mégis előáll, ott vélhetően a böngészőben futó Meta Pixel működése volt eleve problémás. Javíthatja viszont a matching minőségét, feltéve hogy van honnan minőséget hozzátenni. Ha nincs, akkor ez sem lesz valós lehetőség.
Mi a helyzet a Conversion API Gateway használatával?
A Meta CAPI Gateway egy köztes szerver, ami a Meta Pixel adatokat fogadja és továbbítja a Meta felé, egyszerre Pixel és CAPI csatornán.
Innen logikus következtetés: ha valami blokkolja a böngészőben futó Pixelt, a Gateway-t is blokkolja. Igaz?
Részben. A valóság picit árnyaltabb.
A CAPI Gateway pont azért éri meg a pénzt, mert megfelelő implementáció esetében a Pixel hívás nem a connect.facebook.net-re megy, hanem a saját first-party aldomainedre (pl. meta.azenweboldalam.hu). A domain-alapú blokkolólisták ezt tehát nem feltétlenül fogják meg. De a legtöbb elterjedt hirdetésblokkoló látni fogja az adatküldés beltartalmát is, így az ilyen irányú védelem várhatóan minimális lesz.
Emellett a Safari most már 3rd party-ként kezeli azokat az aldomaineket, amelynek IP címe meglehetősen távol esik a fődomain IP címétől, így itt sem várható érdemi nyereség, mivel a Meta cookie-k élettartama továbbra is 7 napban lesz limitálva.
A Gateway tehát tényleg termel valamennyi extra adatot a Pixelhez képest. Csak közel sem annyit, mint amennyit sok marketing landing oldal ígér.
A Meta CAPI is csak hozzájárulással gyűjthet adatot
Ez az a pont, amit a piac egy része még mindig kifizetődőnek hiszi, ha szőnyeg alá söpörheti. Csak hát az EU-ban ezt nem lehet.
A személyes adat kezelésének jogalapja független a technikai csatornától. A user IP-címe személyes adat. Az fbp, fbc cookie személyes adat. A hashelt e-mail személyes adat. Mindegyikre marketing célú felhasználáshoz GDPR-os hozzájárulás kell, akár a böngészőből, akár a szerverről megy az adat Meta felé.
Ha a felhasználótól nincs marketing consent:
- a Pixelnek nem szabad működnie
- a CAPI-nak nem szabad eseményt küldenie
- a Gateway-nek sem szabad aktiválódnia
Ha mégis küld bármelyik, az nem trükközés, hanem jogszerűtlen adatkezelés.
Egy apróság: a Meta dokumentációjában szereplő Limited Data Use / Data Processing Options flag inkább CCPA-ra (Kalifornia) megoldás, nem GDPR-os mentsvár. Aki ezzel próbálja meg legitimálni a consent nélküli CAPI-t, félreérti.
Ahol nincs is más lehetőség: offline mérések és CRM integráció
Ahogy a Google Analytics esetében is a Measurement Protocol segít beemelni azokat az adatokat, amelyeket más módon nem is lehetne mérni, úgy a Meta esetében a Conversion API az eszköz erre a feladatra.
Ha vannak fizikai boltjaink és szeretnénk például egy törzsvásárlói kártya segítségével felhasználóhoz köthetően beemelni az offline értékesítést a Meta által látott és használt adatokba, akkor a Conversion API ebben sokat segíthet.
De B2B közegben is fontos, hogy nem csak a leadek számát lássuk, hanem azt is, mi történt ezekkel a leadekkel a későbbiek során. Segíthet a kampányokat, az elérést a jobb minőségű leadek felé terelni. Ehhez is elengedhetetlenül szükséges a Meta CAPI.
Deduplikált webes és szerver oldali mérések Meta CAPI-n
Hibás számokat és teljesen félrevezető értelmezéseket kaphatunk, ha a Meta Pixel és a Conversion API egyszerre működik és ennek során nem biztosítjuk, hogy a Meta rendszere képes legyen azonosítani, mely adatküldés hordozza ugyanazt a duplikált információt.
Ha ugyanis nincs semmi, ami blokkolja a webes méréseket, akkor minden PageView esemény, minden Lead mérés, minden Purchase esemény két irányból érkezik meg: a Meta Pixel segítségével és a CAPI felől is. Egy kattintás a weboldalon, két adat a Meta rendszerében.
A Meta ezt igyekszik az időbélyegek és az fbp cookie segítségével deduplikálni, de ha biztosra akarunk menni, akkor minden eseményhez be kell állítani az ún. event_id paramétert. Ez egy olyan egyedi azonosítót ad minden eseményhez, ami azonos módon érkezik meg a pixel és a CAPI irányából is, így a Meta egyszerűen képes elvégezni a deduplikációt. Ha ez nem működik megfelelően, akár jelentősen több konverziós és bevételt is mérhetnek a kampányok, teljesen hibás következtetéseket mutatva a felületen.
Az etikai kérdés, amit a szakma ritkán tesz fel
Tegyük fel, hogy egy felhasználó feltelepít egy ad blockert. Megnyit egy weboldalt, ahol a consent banneren rákattint az „Elfogadom” gombra (már ha az ad blocker nem blokkolja magát a consent bannert is). A hirdetésblokkoló miatt a Meta Pixel adatküldése nem lesz sikeres, de a CAPI Gateway például egy kellően “rejtjelezett” server side GTM használata esetén még akár küldhet is adatot.
Jogi értelemben ez rendben van. A felhasználó megadta a hozzájárulást. Az EDPB Guidelines 5/2020 (113-114. paragrafus) szerint a visszavonás helye az a felület, ahol a consent megadásra került: tipikusan maga a consent banner. Egy utólag telepített böngészőkiterjesztés nem ilyen mechanizmus, és egyetlen EU regulator sem ismerte el formálisan az ad blockert a hozzájárulás visszavonásáért felelős eszköznek.
Etikailag bizonytalanabb a kép. Az ad blocker telepítése elég egyértelmű felhasználói preferencia-jelzés a mérés/követés ellen. Ha valaki ezt rendszeresen kerüli meg server-side megoldásokkal, abban van egy megkérdőjelezhető attitűd a saját látogatójával szemben. Amikor egy eszköz egyik fontos egyedi ajánlata az ad blocker megkerülése, az olyan területre téved a gondolataival, ami nem biztos, hogy előnyére válhat hosszú távon.
Nem hiszem, hogy ennek a kérdésnek lenne tiszta válasza. De érdemes feltenni, mielőtt valaki büszkén elmondja, hogy a Gateway-jével „visszanyerte a blokkolt eseményeket”.
