2024 márciusától, aki továbbra is szeretne közönségeket használni a Google termékeiben, annak kötelezően használnia kell a Consent Mode nevű technikai megoldást. A Consent Mode segítségével tudjuk a Google rendszereinek tudomására hozni, milyen hozzájárulásokat adott a felhasználó weboldalunkon és mobil applikációnkban.
Egy újabb cunami, ami elől nincs menekvés
Az utóbbi években több olyan technikai fejlesztést is végre kellett hajtani, ami elől nem tudunk elugrani. Ilyen volt a GDPR megjelenésével a különféle hozzájárulás bekérő bannerek elterjedése, de szintén elég sok feladatot adott nekünk az átállás az új Google Analytics 4 rendszerére.
A mostani cunami talán kisebb hullám lesz és lesznek olyan cégek, akik számára igazából nem is nagyon lesz új teendő. Na, de miről is van szó, nézzük meg egy nem túl rövid cikkben:
Digital Markets Act – az új EU-s szabályozás
Csak erről lehetne külön egy hosszas cikket írni, de legyen most itt annyi elég, hogy az EU méretük, hatásuk és elérésük alapján egyes cégekre, cégcsoportokra a „kapuőr”, avagy „gatekeeper” cimkét teszi. Akit ez részletesen érdekel, annak javasoljuk a vonatkozó Európai Bizottság oldalt tanulmányozni.
Nem meglepő módon a Google is ilyen kapuőr címkét kapott, aminek fontos implikációi vannak a Google szolgáltatásait használó hirdetőkre nézve is. Pusztán a GDPR alapján elég markánsan elkülönült, mely funkciók és szolgáltatások kapcsán van szüksége a Google-nek saját maga által gyűjtött hozzájárulásra és hol lehet elég annyit mondania, hogy a szolgáltatást használó cég feladata a megfelelő hozzájárulás beszerzése. A Google ebben az esetben jóhiszeműen úgy járt el, hogy feltételezte a cégről, hogy ezt megfelelő keretek között begyűjtötte.
De ez most részben változik.
Szeretnél elemezhető és célozható közönségeket?
Ha a fenti kérdésre a válaszod „igen”, akkor bizony van teendőd, attól függően, mennyire adaptáltad eddig a Google ajánlásait, a kevéstől a nagyon sok teendőig változatos feladat cunami omlik a cégek nyakába. Ezzel a cikkel és akár a kapcsolódó szolgáltatásunkkal szeretnénk segíteni a cégeknek megfelelő módon beállítani az adatgyűjtést.
A legelső fontos információ: ez most nem csak a Google Analytics 4-ről szól. Amiről most beszélünk, az érinti a Google Ads kódját és a Floodlight kódot is, kérlek, mindig ezzel a szemüveggel olvasd az alábbiakat.
Mi az a Consent Mode?
A Consent Mode a Google technikai eszköze, nem egy vizuálisan is látható admin felület, hanem olyan kódok, amelyek segítségével módosítani tudjuk az egyes Google szolgáltatások adatgyűjtését és felhasználását. Például, egyetlen ún. kapcsoló segítségével arra utasíthatjuk a Google Analytics 4, a Google Ads vagy épp a Display & Video 360-hoz kapcsolódó Floodlight kódokat, hogy ne tároljanak és ne aktiváljanak olyan adatot, amely a hirdetésekkel kapcsolatos.
Igazából 2 ilyen kapcsolót (hivatalos nevén flag-et) definiált eddig a Consent Mode:
- analytics_storage
- ad_storage
Ez a két kapcsoló alapvetően jól összepasszolt a legtöbb hozzájárulás kérő felület „Statisztika” és „Hirdetés/Marketing” pipáival azzal a fontos megjegyzéssel, hogy ha ezen pipák valamelyikét a felhasználó nem adta meg, attól még a Google továbbra is kapott adatokat, de ún. cookie mentes formában, amire én jobban szeretem azt a fogalmat használni, hogy azonosító mentes formában. Erről máris írok picit bővebben.
Mi változik? Mi is az a Consent Mode v2?
A fentebb említett „kapuőr” szerep miatt a Google-nek innentől nagyon pontosan tudnia kell arról, hogy a kapott adathoz tartozik-e hozzájárulás a hirdető cég weboldalán, illetve mobil applikációjában.
Emiatt fontos változás, hogy innentől a Consent Mode használata nem csak opciós, de kötelező.
Hogy egészen pontosak legyünk: 2024. márciusától az a hirdető, aki nem használ Consent Mode-ot az adatgyűjtése során, az minden Google termékben elveszíti a lehetőséget, hogy ezen adatok alapján célozható közönségeket hozzon létre. Még rövidebben: a remarketingnek annyi.
Ez érinti azon Google Analytics 360 előfizetőket is, akik a robosztusabb folyamatok miatt még mindig Universal Analytics-et használnak elsődleges eszközként. UA esetében a közönség funkció teljesen elveszik, így minden GA360 ügyfélnek alapvető fontosságú lezárni a GA4-re történő átállást jövő év márciusáig.
A Consent Mode v2 azzal egészíti ki az eddigi működést, hogy 2 további kapcsolót (flag-et) tesz hozzá a fenti kettőhöz:
- ad_user_data: küldhető-e bármilyen felhasználói adat hirdetési célból a Google felé?
- ad_personalization: használható-e a felhasználónál az ún. testre szabott hirdetési mód, így például a remarketing?
Az előző két kapcsoló működése pedig szigorúan arra korlátozódik majd, hogy a statisztikai, illetve hirdetési célú sütik tárolása és kiolvasása engedélyezett-e.
A Google a napokban frissíti fejlesztői dokumentációit, így nem teljesen világos még, hogy az eddigi működésben pontosan hol és milyen változás érkezik, de amint ezek teljesen ismertek lesznek, írni fogunk róla.
Egyetlen alternatíva van, de ez tapasztalatom szerint csak kevés cégnél valóban az: ahol már az IAB féle Transparency & Consent Framework (TCF) van használatban, az helyettesíti a Consent Mode használatát. Ha most nem tudod, miről van szó, akkor ez azt jelenti, hogy Neked leginkább a Consent Mode marad.
Az azonosító mentes (ún. cookieless) adatküldésekről
Ez az azonosító mentes adatküldés megtagadott felhasználói hozzájárulásnál valóban az, ahogy írom: nincs benne semmilyen olyan azonosító, ami akár közvetve is azonosíthatná a felhasználót. Tehát, ha van is esetleg eltárolva a felhasználó böngészőjében egy Google Analytics cookie azonosító (az ún. client ID), azt nem olvassa ki, hanem egy véletlenszerű azonosítóval helyettesíti, így minden oldalon más és más azonosítót kapnak az adatküldések, amivel így nem lehet őket egy hosszú munkamenetté fűzni a feldolgozás során.
De ettől még van adatküldés akkor is, amikor a felhasználó nem pipálta ki a statisztika pipát a hozzájárulás kérő felületen.
Arról magunknak kell gondoskodnunk, hogy ilyen esetekben például egyéni dimenziókban ne küldjünk olyan másodlagos azonosítót, amit ilyenkor magától nem gyűjt a rendszer (például egy rendelés azonosítót).
Fontos még, hogy ezek az azonosító mentes adatküldések is elvégzik a IP cím => Geo adat (ország, régió, város) konverziót.
Ezeknek az adatküldéseknek más a célállomása is: ezek ilyenkor egy gépi tanulással dolgozó algoritmus előszobájába kerülnek, ahol a rendszer adatmodellezéssel igyekszik kipótolni például a konverziós adatokat annak érdekében, hogy minél több konverziót lássunk a rendszerekben a helyes döntések meghozatalához.
Ezeket az ún. modellezett konverziókat a rendszer akkor is hozzáteszi a megfigyelt, valós adatokhoz, ha mi nem engedélyezzük ezeket az azonosító mentes adatküldéseket, viszont ebben az esetben kevesebb eredménye lesz, mivel igazán komoly plusz adatot csak a saját azonosító mentes adatküldéseinkből tudnak helyreállítani.
Kell akkor ez most nekünk?
Ahogy írtam, az azonosító mentes adatküldéseknek a beltartalma tényleg mentes mindenféle használható másodlagos azonosítótól és a feldolgozás is teljesen más, mint amikor normál adatküldéssel van dolgunk. A személyes, nem jogi véleményem az, hogy ezek az adatküldések már nem kéne, hogy problémásak legyenek.
De… 🙂
Jellemzően két ellenérvet szoktak felhozni adatvédelmi szakemberek a fenti gondolatmenettel kapcsolatban:
- „Lehet, hogy nincs bennük azonosító, de van bennünk elég rész információ (pl. böngésző neve, verziója, képernyőfelbontás, stb), amivel akár lehetne is azonosítani 1 konkrét állampolgárt.”
Ezt az érvet nehezen tudom cáfolni, a lehetőség erre akár adott is lehet, de nincs arról információnk, hogy a Google saját célra ilyet végezne. Ha mégis és ez kiderülne, az szinte biztos, hogy instant egy giga bírságot jelentene az EU-tól. - „Maga a tény, hogy valakiről adatot (különösen konverziós adatot) küldünk, máris információt ad a Google-nek, hogy kik az én ügyfeleim.”
Ez viszont részemről mindenképpen az urban legend kategória, de megértem, hogy vannak iparágak, ahol a legkisebb esélyt is esélynek kell tekinteni és ennek megfelelően kezelni, nincsenek árnyalatok.
Összességében szerintem ezeknek az azonosító mentes adatküldéseknek a megítélése részben attól függ, hogy a céged adatvédelmi szakértője milyen véleménnyel van ezek működéséről, részben pedig egyfajta kockázat elemzés is dönteni arról, mit tekintesz urban legend-nek és mit valós, lehetséges problémának.
Basic VS Advanced – a Consent Mode két arca
Érezhetően a Google-nél is látják, hogy az azonosító mentes adatküldéseknek nem minden cégnél örülnek, ezért – bár felsorolható több érv is mellette – maga is kétféle beállításról beszél.
A „Basic” verziónál ezeket az azonosító mentes adatküldéseket teljesen leállítjuk, nem engedélyezzük azáltal, hogy minden kapcsolódó Google mérőkódot inaktívan tartunk addig, amíg a felhasználó megfelelő hozzájárulást nem adott azok működéséhez.
Ennek fontos előnye, hogy nagyon a biztonságos oldalra állhat a céged, mert akárhogy is értékeli egy hatósági vizsgálat a fenti azonosító mentes adatküldést, nálad ilyen nincs, tehát emiatt nem kell félned. Hátránya ugyanakkor, hogy modellezett adatokat csak nagyon korlátozottan kaphatsz, ami érinteni fogja a kampányaid eredményességét és hatékonyságát is, végső soron a cég bevételét.
Az „Advanced” verziónál minden Google mérőkódnak engedélyezzük az adatküldést, de mindig abban a formában, amihez a felhasználó épp hozzájárult. Amikor például frissen érkezik meg újként weboldalunkra valaki, még nem nyilatkozott, tehát a mérések az azonosító mentes adatküldést fogják használni. Amint megtörtént a nyilatkozat és hozzájárulást kaptunk mindenféle adatkezelésre, ugyanezek a kódok igazodni fognak és átállnak a normál adatküldésre.
Előny tehát ebben az esetben, hogy a lehető legtöbb információt fogjuk megkapni, a rendszer ezzel tudja a legtöbb kieső adatot, különösen konverziós adatot helyreállítani nekünk. Hátrány ugyanakkor, hogy ezek az azonosító mentes adatküldések érzésem szerint vékony jég és változó módon fogják különféle szakemberek értékelni ezek jogosságát.
Mit jelentenek ezek a modellezett adatok és modellezett konverziók?
Amikor modellezett adatokról és modellezett konverziókról beszélünk, akkor azokra az adatokra támaszkodik a rendszer, amit ezekből az azonosító mentes adatküldésekből kap. Ezeket egy kalapba teszi és gépi tanulással igyekszik megállapítani, hol, kinél történt még például konverzió olyan esetekben, amikor ezek közvetlen mérésére nem kaptunk hozzájárulást a felhasználótól.
Tegyük fel, hogy van egy fizikai boltunk, ahol a pénztár mellé odaállítunk egy „manót”, hogy valahányszor csörög a kassza, húzzon be egy strigulát. Napjainkban a manó csak akkor húzhat strigulát, ha előzetesen megkérdezi a vásárlót, hogy odanézhet-e, amikor a kasszánál áll és fizet. Modellezett adatok nélkül a manó kizárólag annyi strigulát húz, ahányszor odanézhetett a kasszára, mivel volt hozzájárulása. Tegyük fel, hogy 100-ból 80 ilyen alkalommal volt erre lehetősége.
Az adatmodellezés ehhez fog hozzátenni mindenféle számolással például további 9 esetet, így 80 helyett 89 konverziót fogunk látni a riportokban, ami továbbra sem 100, de mégis csak közelebb van a valósághoz.
Az algoritmusokat pedig úgy találták ki és úgy tesztelték, hogy ne mérjenek többet a valóságnál, tehát ne mutathasson a rendszer 100 helyett 110 konverziót.
Ezeknek a modellezett adatoknak a számosságán tud jelentősen javítani, ha a Consent Mode „Advanced” változatát használja egy weboldal, illetve mobil applikáció.
Customer Match – amikor email cím listát töltesz fel
Ezek a változások érinteni fogják várhatóan a Google Ads és a DV360 Customer Match funkcióját. Ennek során Te magad töltesz fel egy email cím listát a hirdetési rendszerbe, amely alapján adott téma köré szeretnél egy célcsoportot meghatározni.
Arra eddig is a hirdető cégnek kellett hozzájárulást szereznie, hogy ezt a feltöltést megtehessék, azonban várhatóan itt is meg kell majd adni az adatfájlban, mihez is kaptunk hozzájárulást (ad_user_data és ad_personalization).
A kapcsolódó technikai dokumentációt itt is a napokban frissíti a Google mind a kézi feltöltős részhez, mind a Google Ads API-t használó esetekhez.
Teendők, next steppek
1. lépés
Saját fejlesztésű hozzájárulás bekérő felületet (ún. consent bannert) használsz vagy dobozos megoldást?
- Dobozos megoldás: GO TO 2. lépés
- Saját fejlesztés: GO TO 4. lépés
2. lépés
Olyan dobozos megoldást használsz, amelyet a Google is minősített?
- Igen: GO TO 3. lépés
- Nem: GO TO 4. lépés
3. lépés
Ellenőrizd, hogy be van-e kapcsolva az eszközben a Consent Mode, ez ugyanis ezekben a toolokban bár ott van integráltan, de kikapcsolható.
GO TO 5. lépés
4. lépés
Ha saját fejlesztésű megoldásod van vagy olyan dobozos megoldásotok, amelyet a Google még nem minősített, ellenőrizzétek, hogy ebben integrálva van-e már a Consent Mode
- Igen: ki kell majd egészíteni a két új kapcsolóval, ehhez a technikai leírásokat a napokban frissíti a Google
- Nem: létre kell hozni az integrációt a Consent Mode-al, annak minden kapcsolójával, amihez a friss leírásokat pár nap múlva lehet elolvasni jelen cikk publikálásától számítva
5. lépés
Ezen a ponton a Consent Mode így vagy úgy, de teljes pompájában működik, egy dolog van még hátra: eldönteni, hogy a Basic vagy az Advanced üzemmódot szeretnétek használni.
A döntés után fontos tudni, hogy a mérőkódok Google Tag Manager-el vannak-e az oldalban (javasolt) vagy közvetlenül kerültek be a forráskódba GTM nélkül?
- van GTM: ez esetben minden címke rendelkezik egy Consent Settings beállítással, ahol a Basic esetben be lehet állítani, hogy adott hozzájárulás nélkül nem is aktiválódhat az adott címke
- nincs GTM: a Basic verziónál ilyenkor kézzel kell létrehozni olyan JavaScript kódokat, amelyek kiolvassák a felhasználó aktuális hozzájárulásait és a különféle mérőkódokat csak azon esetekben aktiválják, amikor erre hozzájárulásunk van
Mindkét esetben ha Advanced Consent Mode-ot szeretnénk használni, akkor nincs szükség további mérőkód korlátozásra.
„Tovább is van, mondjam még?”
Ezek most a legégetőbb változások, amiken végig kell mennie minden cégnek, ahogy írtam, legkésőbb 2024. márciusáig. De ez a teendő lista még koránt sem teljes, többek között olyan lehetőségekről is érdemes gondoskodni, mint az ún. Enhanced Conversions bevezetése Google Ads felé, de erről inkább egy külön cikkben emlékezünk majd meg 🙂
