Chrome Privacy Sandbox és a Topics API: A 2026-os kiadói útmutató a beleegyezéshez, célzáshoz és méréshez

Az elmúlt évtized nagy részében a digitális reklámozás egy egyszerű feltételezésen alapult: a harmadik féltől származó sütik mindig ott lesznek, csendesen hordozva a felhasználói azonosítókat a weben keresztül. Ez a feltételezés most megdőlt. A Chrome leértékelési útja többször megváltozott, de az irány nem: a harmadik féltől származó sütin keresztüli webhelyek közötti nyomon követés véget ér, és a Google Privacy Sandboxja az a csere, amelyet a Chrome kiadóktól és hirdetőktől elvár. A Sandbox nem egyetlen termék. Ez egy böngésző API-k készlete — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage és egyebek —, amelyek mindegyike egy adott felhasználási esetet vált fel, amelyet korábban a sütik fedtek le. Egy kiadó számára a nehéz rész nem az API-k egyenkénti megértése. Az a nehézség, hogy olyan beleegyezési réteget és monetizációs útvonalat kell kiépíteni, amely egyszerre tartja összhangban a Privacy Sandbox folyamatokat, a GDPR-megfelelést és az állami adatvédelmi törvényt. Ez az útmutató végigvezeti a 2026-ban mozgó részeken, és bemutatja, hogyan kell kinéznie a beleegyezési veremnek.

Mit vált fel valójában a Privacy Sandbox

A harmadik féltől származó sütik négy különálló reklámfunkciót hordoztak: érdeklődésen alapuló célzás, retargetálás, konverzió mérés és frekvenciakorlátozás. A Privacy Sandbox ezeket különálló API-kra bontja, mindegyiknek saját beleegyezési profilja van.

Topics API — Érdeklődésen alapuló célzás

A Topics API minden böngészőhöz egy kis készlet durva szemcsés érdeklődési témát rendel — körülbelül öt témát hetente, amelyeket néhány száz kategória kurált taxonómiájából merít. Amikor egy kiadó meghívja a document.browsingTopics() funkciót, a böngésző legfeljebb három témát ad vissza, amelyeket az ad tech ökoszisztéma kontextuális személyre szabáshoz használhat bármilyen webhelyek közötti azonosító nélkül. A témák helyileg kerülnek kiszámításra, eszközön tárolódnak, hetente forognak, és a felhasználói vezérlőknek vannak kitéve a chrome://settings/adPrivacy helyen.

Protected Audience API — Retargetálás és remarketing

A Protected Audience, korábban FLEDGE, megosztott webhelyek közötti azonosító nélkül tartja életben a retargetálást. A hirdetők a saját webhelyükön csatlakoztatják a felhasználót egy érdeklődési csoporthoz; amikor a felhasználó egy részt vevő kiadó oldalát látogatja, egy eszközön futó aukció egy Fenced Frame-ben fut le és kiválaszt egy alkotást. A nyertes hirdetés megjelenik anélkül, hogy a kiadó megtudná, melyik érdeklődési csoport illeszkedett.

Attribution Reporting API — Konverzió mérés

Az Attribution Reporting a konverziós pixelek helyére lép a mérési felhasználási esetek egy részhalmazánál. Eseményszintű jelentéseket (zajos, veszteséges, konverzióonként) és összesített összefoglaló jelentéseket (statisztikailag mentesített összesítők) is támogat. A régi pixellel ellentétben nem teszi ki az egyéni felhasználó-konverzió kapcsolatot.

Shared Storage és Fenced Frames

A Shared Storage egy mindenhol írható, sandbox-ban olvasható kulcs-érték tároló webhelyek közötti felhasználási esetekhez, mint például a frekvenciakorlátozás és az A/B kísérlet konzisztenciája. A Fenced Frames izolált iframek, amelyek megakadályozzák, hogy a körülvevő oldal olvassa a megjelenített hirdetést vagy annak interakciós adatait.

Szükséges-e beleegyezés a Privacy Sandboxhoz?

Ez a 2026-os ad tech táj egyetlen leginkább félreértett kérdése, és a válasz joghatóság-specifikus.

GDPR és ePrivacy alapján

Az Európai Adatvédelmi Testület nem adott ki blanket álláspontot, de a nemzeti hatóságok explicitebb álláspontot foglaltak el. Az Egyesült Királyság ICO-ja, az olasz Garante és Franciaország CNIL-je mind azt az álláspontot foglalta el, hogy a Topics és a Protected Audience előzetes opt-in beleegyezést igényel, ahol személyes adatokat kezelnek, beleértve minden olyan kezelést, amely a felhasználó eszközén állapotot ír vagy olvas. A logika: a böngésző továbbra is helyben tárolja az érdeklődési témákat és csoportokat, és a document.browsingTopics() hívás következtetett személyes adatokat továbbít harmadik félnek. Ez az ePrivacy Irányelv 5(3) cikke szerint szabályozott, amely beleegyezést ír elő a felhasználó végberendezésén való hozzáféréshez vagy tároláshoz, kivéve, ha az a kért szolgáltatáshoz szigorúan szükséges.

A Google álláspontja megengedőbb — azt állítják, hogy az API-k tervezésüknél fogva adatvédelmiek, és hogy a beleegyezési követelmények nem feltétlenül alkalmazandók minden kontextusban. Ez nem egy szabályozói álláspont. A Privacy Sandbox beleegyezés-mentes kezelése Európában nagy kockázatú helyzet.

CCPA, CPRA és az USA állami törvényei alapján

Az Egyesült Államokban a Privacy Sandbox folyamatok általában a személyes adatok megosztásaként kezelendők a CPRA szerinti kontextusközi viselkedési reklámozáshoz. Ez azt jelenti, hogy kiváltják az opt-out jogot, és azt tiszteletben kell tartani a Global Privacy Control jelek és más univerzális opt-out mechanizmusokon keresztül. Az a tény, hogy a Topics adatok a böngészőből származnak, nem pedig harmadik fél brókerétől kerülnek értékesítésre, nem mentesíti azokat.

A Chrome saját vezérlői

A Chrome felhasználói kapcsolókat biztosít a chrome://settings/adPrivacy helyen a Topics, Protected Audience és Attribution Reporting számára. Ezek a felhasználói választások a CMP beleegyezési állapota mellé esnek — nem helyette. Egy felhasználó, aki nem adott hozzájárulást a reklám sütikhez a bannerben, de igen a Topics-hoz a Chrome globális beállításaiban, még mindig nemet mondott Önnek a banneren keresztül. A veremnek a két jel közül a szigorúbbat kell tiszteletben tartania.

A valójában szükséges beleegyezési réteg

Egy gyártásra kész 2026-os beleegyezési verem a Privacy Sandbox API-kat különálló feldolgozási tevékenységekként kezeli, amelyek mindegyike IAB TCF célokon vagy azzal egyenértékű állami jogi kategóriákon keresztül van kapuzva.

Sandbox API-k leképezése TCF célokra

Leképezés a Google Consent Mode v2-re

A Google Consent Mode v2 jelek leképeződnek a Privacy Sandbox viselkedésre:

USA állami jelkezelés

Az USA-beli forgalom esetén a beleegyezési rétegnek vizsgálnia kell a Global Privacy Control-t és az alkalmazandó állami opt-out jeleket. Amikor egy USA-beli felhasználó lemondott a megosztásról, tiltsa le a document.browsingTopics()-t, ne hívja meg a joinAdInterestGroup-ot, és törölje az Attribution Reporting regisztrációs fejléceket.

Gyakorlati megvalósítási minták

Azok a kiadók, akik már bevezették a Privacy Sandboxot, általában két architektúraminta egyikét követik.

1. minta: Szerver oldali vezénylés

Az eredetén lévő first-party tag manager összegyűjti a beleegyezési állapotot, a felhasználói joghatóságot és bármely jel felülírást, majd feltételesen rendereli a Privacy Sandbox hookokat az oldalba. A hirdetéskiszolgáló és az SSP beleegyezési jelzőket kap az ajánlatkérésen keresztül, és eldöntik, hogy meghívják-e a Topics-t, a Protected Audience-t vagy egyiket sem. Ez a minta centralizálja a logikát és tartja a beleegyezési állapotot hiteles forrásként.

2. minta: Header Bidding Wrapper integráció

A Prebid.js és más header bidding wrapperek mostantól támogatják a Privacy Sandbox modulokat. A wrapper olvassa a beleegyezési jelet, konfigurálja a Topics hívás viselkedését, és engedélyezés esetén továbbítja az aukció eredményét a Protected Audience-n keresztül. Ez a megközelítés könnyebben bevezethető, de több logikát tol az ügyfélre és szorosabb függőséget teremt a wrapper kiadási ütemtervétől.

Mit kell auditálni

Mit nem tesz a Privacy Sandbox

Több általános tévhitet kell megdönteni, mielőtt ezekre tervez.

Nem kerülő megoldás a beleegyezéshez

Az API-k csökkentik a hirdetőknek feltárt személyes adatokat, de az európai jog alatt nem teszik a mögöttes feldolgozást beleegyezéstől mentes. Az a megfelelési elmélet, hogy a Sandbox bevezetése lehetővé teszi egy CMP kihagyását, minden EU/EEA joghatóságban helytelen.

Ma nem teljes helyettesítője a sütiknek

A Topics durva, veszteséges célzási jelet nyújt, amely általában gyengébb a sütialapú közönségeknél. A Protected Audience retargetálás méretei még érlelőben vannak. Az Attribution Reporting mérési zajszinttel rendelkezik, amely elrejtheti a kis konverzió növekedéseket. Egy kiadónak, aki ma az összes monetizációt Sandboxra mozgatja, 10-30 százalékos RPM csökkenésre kell számítania a tipikus készleten lévő sütialapú veremhez képest.

Jelenlegi formájában nem állandó

A Privacy Sandbox specifikáció még fejlődik. A Topics taxonómia bővül, a Protected Audience érdeklődési csoport korlátai felülvizsgálat alatt állnak, és a szabályozói válasz folyamatban van. Tervezze meg a beleegyezési réteget konfigurációvezéreltként, nem az aktuális specifikációhoz hardkódolva.

A helyes hozzáállás 2026-ra

A Privacy Sandbox legjobban egy tágabb süti nélküli stratégia egyik rétegeként érthető meg, a first-party adatok, eladó által definiált közönségek, kontextuális célzás és szerver oldali header bidding mellett. A 2026-ban nyerő kiadók azok lesznek, akik a beleegyezést döntőbíróként kezelik, nem akadályként — a Sandbox API-kat csak ott táplálva, ahol a törvény és a felhasználói választás megengedi, máshol tisztán kontextuálisra visszaesve, és mindkét útvonalon mérik az eredményeket olyan eszközökkel, amelyek nem feltételeznek identitást.

A legrosszabb hozzáállás a kivárós. A szabályozók már írják a szabályok következő hullámát — az Egyesült Királyság Verseny- és Piacfelügyeleti Hatóságának Sandbox kötelezettségvállalásai, a folyamatban lévő CNIL útmutatás és az EU AI Act profilozási rendelkezései mind érintik ezt a területet. Azok a kiadók, akik 2026-ban megfelelően kapuzott beleegyezési verembe építik a Privacy Sandboxot, készen állnak majd ezekre a szabályokra. Akik utólag ragasztják rá utolsó pillanatban süti pótlóként, azok nyomás alatt fogják átírni.

← Blog Összes olvasása →