Cookiepocalypse, cookie armageddon – számos néven illették már azt, ami előttünk áll az online hirdetési iparágban, de az az igazság, hogy ezek az elnevezések azért bulvárosan tulzóak, illetve féligazságokat tartalmaznak. Tegyük tisztába, mi vár ránk a következő szűk 1 évben.
Ez megint hosszú tartalom lett, de hidd el, van mit tisztázni…
Nem, a cookie-k nem halnak ki
Talán az első és legfontosabb tisztázni ezt a kérdést. Persze a bejegyzés elolvasása után látni fogja mindenki, hogy a hirdetések szempontjából fontos cookie megoldások bizony hamarosan eltűnnek, mégis, sok zavar van az erőben azzal kapcsolatban, mely szoftvert érinti és melyiket nem az a tény, hogy immár a Google Chrome böngészőben is kivezetésre kerülnek az ún. 3rd party cookie-k.
Spoiler alert: van teendőd, de nem annyira közvetlen a ráhatásod
Csak, hogy ne feszüljön senkiben a válasz iránti igény, gyorsan lelövöm előre, hogy jelenleg hirdetőként nem sokat lehet tenni az ellen vagy azzal együtt, hogy ezek a technológiai változások itt vannak a kapuban. A legtöbb adaptációt a különféle hirdetési rendszerek kell, hogy elvégezzék. Hirdetőként leginkább azzal foglalkozhatunk, hogy gatyába rázzuk saját adatainkat, mert hogy alapvetően ez jelenti a jövőben a biztosat.
Ha valahol az alábbiak valamelyikét olvasod, nos… tévednek:
- Megszűnnek a sütik / cookie-k
- Vége a világnak, jön a cookie armageddon (aka cookiepocalypse)
- Cégünk javaslatokat fog tenni ügyfeleinek a Topics API, illetve a Protected Audience API megfelelő használatára (erről mindjárt kicsit bővebben)
1st party, 3rd party… mi van?
Alapvetően két nagy csoportja van a sütiknek egy böngészőben:
A 1st party cookie, avagy „normál süti”, retro gondolattal élve a hagyományos mosópor kategóriája jelenti a sütikkel kapcsolatos „ősélményeket”, amit óvatosan, de egyre inkább „problematizál” néhány böngésző, hogy „tematizálja” ezzel a szakmai beszédet.
Amikor az internet még maga volt a Vad Nyugat és az online hirdetések kimerültek abban, hogy klasszik 468×60 pixel méretű bannereket tettek ki különféle weboldalakra, ráadásul úgy, hogy ezeket kézzel töltötték fel a webtárhelyekre – komolyan, mint az ááááállatok -, szóval ekkoriban a sütik leginkább arra voltak hivatottak, hogy segítsenek megjegyezni a weboldalnak, hogy épp be vagy jelentkezve rajta, esetleg észlelni lehessen, hogy Te pont ugyanaz az az anonim látogató vagy, aki pár perce kosárba tett egy terméket az Amazonon.
Ezeknek a 1st party cookie-knak ma is fontos szerepük van és fontos megérteni, hogy ezek nem tűnnek el. A Google Chrome alapvetően nem nyúl ezekhez, 1 év múlva, de talán 2 év múlva is itt lesznek velünk. Ezek a sütik más népszerű böngészőkben is működnek, ugyanakkor változatos módon korlátozott lehet a működésük: Safariban például egy gépi tanulást használó algoritmus dönti el, hogy az éppen létrehozandó 1st party cookie részt vesz-e követési, mérési feladatokban. Ha ezt látja, akkor annak a sütinek az érvényességi ideje jelentősen korlátozott lesz, tehát, ha emberünk nem tér vissza weboldalunkra pár napon belül, akkor ugyanazok a mérések jó eséllyel új felhasználóként fogják érzékelni. Nem fogják látni az előzményeket.
Főleg analitikai eszközök, így a Google Analytics is ilyen 1st party cookie-kat használ a mérések során, tehát ennek a működése alapvetően nem lesz blokkolva 2024 végére, bár egyes böngészőkben korlátozottabban tud csak adatot gyűjteni.
Fontos jellemzőjük, hogy egy 1st party cookie-t csak a weboldalban futó programok érik el és az a háttér szerver, amely magát a weboldalt kiszolgálja. Más weboldalak nem tudják közvetlenül kiolvasni ezeket a sütiket.
A 3rd party cookie az, amiről ez az egész történet igazából szól. Na de mitől lesz egy cookie 3rd party?
Cookie-t nem csak egy weboldalba betöltött program tud létrehozni, hanem egy webszerver is. Ezt úgy tudja megtenni, hogy amikor a böngésző csatlakozik egy webszerverhez, hogy betöltsön egy weboldalt, a webszerver a válaszában nem csak a weboldal HTML kódját adja vissza a böngészőnek, hanem számos nem látható ún. meta adatot is. Ezek között van egy olyan parancs, ami arra utasítja a böngészőt, hogy hozzon létre egy sütit. Az így létrehozott süti is ahhoz a domain névhez lesz eltárolva, ahol a webszerver (!) üzemel.
A gyakorlatban tehát ez azt jelenti, hogy amikor betölt a jabjab.hu és ebben elhelyezünk egy Google Ads remarketing kódot, akkor ez a kód be fog tölteni egy ún. mérőpixelt a google.com oldalról. Amikor ez megtörténik, a google.com webszervere arra utasítja a böngészőt, hogy hozzon létre egy sütit, amit a böngésző a google.com domainhez fog tárolni, nem a jabjab.hu domainhez. Ettől lesz ez a süti ún. 3rd party cookie.
Cross site tracking: az aranytojást tojó tyúk, amiből mumus lett
Ez azért volt eddig „nagyszerű”, mert ha ugyanaz az ember elment az oceanchart.hu oldalra és ott is betöltött egy Google Ads remarketing kód, akkor itt a Google szerver már látta, hogy emberünk előzőleg már járt a jabjab.hu oldalon, így szépen fel tudtak mindenkiről építeni egy profilt, amiben ott volt, hogy milyen weboldal témák érdeklik. Ezt hívjuk cross site trackingnek.
Ez a cross site tracking és nagyjából minden, ami ezzel együtt jött, lényegében aranybánya volt az összes hirdetési rendszernek (nem csak a Google-nek!), azonban láthatóan nem igazán vette figyelembe a felhasználók privát szféráját.
Bár a GDPR megjelenésével hozzájárulás nélkül – elvben – nem lehetett már ilyen adatgyűjtést végezni, tapasztalatom szerint a felhasználók elfogadtak mindenféle adatkezelést egy weboldalra érve, jogilag tehát védve volt minden cég és többnyire csak marginális veszteséggel lehetett továbbra is használni ezeket a technológiákat.
És jöttek a böngészők és kezükbe vették az irányítást
Ezen a ponton jöttek be a képbe maguk a böngésző készítő cégek és ahol nem volt ezzel ellentétes érdek, ott elkezdték ezeket a 3rd party cookie-kat blokkolni. A legtöbb kisebb böngésző után az Apple féle Safari volt ennek a blokkolásnak egyik úttörője, aki az Intelligent Tracking Prevention bevezetésével és több körös módosításával lényegében mára kinyírta ezeket a harmadik feles sütiket.
A nyomás azonban ott volt a Google-ön is, ugyanakkor ők nem tehették meg, hogy egyik napról a másikra kihúzzák a konnektorból ezt a technológiát, hiszen elképesztő mennyiségű hirdetési bevétel múlik jelenleg is azon, hogy a 3rd party cookie-k működnek és végzik a dolgukat.
És lőn: Privacy Sandbox
A Privacy Sandbox a Google kezdeményezése arra, hogy kiváltsák a hirdetéseket üzemeltető technológiákat olyan új megoldásokkal, amelyek tiszteletben tartják a felhasználó privát szféráját, de mégis lehetőséget adnak arra, hogy minden felhasználónak a leginkább releváns hirdetést mutassák a hirdetési rendszerek.
Látszólag egyszerű történetről van szó, mert ha vannak új, modern technológiák, amiket minden böngésző támogat, akkor eljön az új aranykor, a felhasználók védelme kipipálva, a hirdetési rendszerek is üzemelnek, win-win, nem igaz?
A bökkenő csak az, hogy a Privacy Sandbox-ot számos kritika érte az elmúlt években, így bár a Google vélhetően nagyon szerette volna, ha ezek új, általános szabványok lesznek, a jelenlegi helyzet úgy áll, hogy a Google Chrome böngészőn kívül nem nagyon lesz olyan elterjedt böngésző, ami támogatni fogja az új megoldásokat. Sőt, tovább bonyolítja a helyzetet, hogy a Privacy Sandbox bizonyos megoldásai elérhetőek lesznek bizonyos böngészőkben, mások pedig egyáltalán nem.
Az elérhető statisztikák szerint Magyarországon, desktop platformon jelenleg nagyjából a felhasználók 2/3-a használ Google Chrome-ot, ennyi felhasználónál lesz tehát elérhető minden új lehetőség a hirdetések kapcsán:
A legtöbb korlátozással rendelkező Safari ~3-4%-on áll.
A mobilok esetében is a Google Chrome az elsődleges, talán még nagyobb aránnyal, a Safari viszont erős második 15-20% közötti részesedéssel:
Nem megnyugtató ez azoknak a vállalkozásoknak, ahol az ilyen értelemben tudatosabb, esetleg zárkózotabb felhasználók jelentik az elsődleges célcsoportot. Vélhetően egy gaming témában operáló cég esetében a fenti statisztikák nagyon másként néznek ki.
Fontos megérteni, hogy a Privacy Sandbox új technológiái alapvetően kétféle szereplőnek adnak nagyobb feladatot: hirdetési rendszereknek és kiadóknak, vagyis olyan weboldalaknak, akik a hirdetések megjelenítésével foglalkoznak, de nekik sem feltétlenül lesz minden esetben teendőjük.
Hirdetőként a Privacy Sandbox lényegében nem ad feladatot közvetlenül!
Topics API – az új érdeklődés alapú hirdetési rendszer
A Privacy Sandbox hirdetői szemmel nézve egyik legfontosabb eleme, amely a jövőben az érdeklődés alapú hirdetések kiszolgálásáért felel és amit jelen állás szerint csak a Google Chrome, a Microsoft Edge és az Opera böngészők támogatnak.
Korábban FLoC-nak hívták, de az még egy másik technológiai megoldás volt, amivel kapcsolatban számos kritika érte a Google-t. Ezen kritikákat feldolgozva hozták létre a Topics API-t, ami az ígéret szerint jobban védi a felhasználókat, mint az elődje.
A Topics API lényegében a böngészőben tárolja azt, hogy épp mely témák érdekelnek minket aktivitásaink alapján egy előre meghatározott szótár segítségével. Nem meglepő módon ez a szótár lényegében azokat az érdeklődési kategóriákat tartalmazza, amiket most is célozhatunk a Google hirdetési rendszereiben.
Egy hirdetési rendszer ebből a hozzánk rendelt érdeklődési kategória listából kérhet le, de csak egy párat és megeshet, hogy ha ugyanazon a weboldalon ugyanaz a hirdetési rendszer egymás után kétszer kérdezi meg a böngészőt, nem pont ugyanazt a listát fogja megkapni. Az alap adatbázis tehát pontos (=ami minket érdekel), de hogy ebből mit láthat egy külső érdeklődő, abban vannak véletlenszerű elemek.
A különféle hirdetési rendszerek számára fontos feladat tehát ezt a Topics API-t elkezdeni aktívan használni. Hirdetőként ugyan mi is lekérdezhetjük az éppen az oldalunkon járó felhasználó érdeklődési kategóriáit, de utána nekünk kell erre külön scriptekkel reagálni, így leginkább oldalon belüli testre szabott felületek létrehozásához lehet hasznos, ami sok hirdetőnél nem valós lehetőség.
Protected Audience API – az új remarketing
A leánykori nevén FLEDGE néven ismert megoldás adja az új lehetőséget remarketingre, tehát arra, hogy külső oldalakon visszacélozzunk olyan felhasználókat, akik korábban már jártak saját weboldalunkon.
A Protected Audience API segítségével a hirdetési rendszerek kérhetik a böngészőt, hogy az éppen a weboldalon járó látogatót jegyezze fel egy egyéni érdeklődési csoportba, amihez meg tudja adni, hogy milyen formában kell majd licit aukciót végrehajtania, amikor egy másik weboldalon hirdetést kell megjeleníteni.
Itt is tehát a hirdetési rendszereknek van feladata azáltal, hogy beépítik működésükbe ennek az API-nak a használatát. De dolga lehet egy kiadónak is, ott viszont a kiadó weboldalain megjelenő hirdetés kiszolgáló rendszer kell, hogy felkészült legyen annak érdekében, hogy a hirdetők felé egyedi érdeklődési célzásokat adhasson például egy programmatic kampányban.
Attribution Reporting – az új konverzió mérés
Végül – de nem utolsó sorban – egy harmadik API megoldás felel a pontos konverzió mérésért. Az Attribution Reporting API segít összekötni egy külső weboldalon történt hirdetés kattintást (például, amikor a Keresőben egy hirdetésre kattintasz) és a hirdető weboldalon történt konverziót.
Ezt az API-t sem támogatja túl sok böngésző a Chrome-on kívül, sőt, a Safari kitart a saját megoldása mellett, amit Private Click Measurement-nek hív. Nagyon leegyszerűsítve mindkét megoldás azért jött létre, hogy sütik nélkül lehessen a hirdetési rendszerekben konverziót mérni úgy, hogy ezek minél jobban védjék az egyes felhasználók privát szféráját.
Teszik ezt úgy, hogy a hirdetésre kattintás során a böngésző meg tud jegyezni egy azonosítót, ami jellemzően egy kampány azonosító és a konverzió mérés pillanatában képes menteni, hogy ehhez az azonosítóhoz történt egy kattintás. A konverziót magát azonban csak némi idő eltolással jelzi a hirdetési rendszernek, hogy ez az időbélyeg se lehessen későbbi azonosítási kísérletek alapja.
Hirdetőként mik a következő lépések?
Pont azért, mert a fenti működés erősen korlátozott és a konverziós információkra nagy szüksége van minden hirdetési rendszernek, a legtöbb helyen találkozhatunk már olyan konverzió mérési technikával, amely süti-k és új API-k helyett a felhasználó email címével azonosítja a konverziók forrását.
Itt jelennek meg azok a teendők, amivel hirdetőként viszont – közvetve ugyan, de – felkészülhetünk az év végével ránk nyitó technológiai váltásra. Ehhez az első teendő listát már összeírtuk, amit hamarosan tovább fogunk bővíteni ezen a blogon.
