Ką iš tikrųjų pakeičia Privacy Sandbox

Trečiųjų šalių slapukai vykdė keturias atskiras reklamos funkcijas: palūkanomis pagrįstą taikymą, retaikinimą, konversijų matavimą ir dažnumo ribojimą. Privacy Sandbox suskaido juos į atskiras API, kiekviena su savo sutikimo profiliu.

Topics API — palūkanomis pagrįstas taikymas

Topics API kiekvienai naršyklei priskiria nedidelį šiurkščiai grūdotų palūkanų temų rinkinį — apie penkias temas per savaitę, paimtas iš kuruotos kelių šimtų kategorijų taksonomijos. Kai leidėjas iškviečia document.browsingTopics(), naršyklė grąžina iki trijų temų, kurias reklamos technologijų ekosistema gali naudoti kontekstiniam suasmeninimui be jokio kryžminio svetainių identifikatoriaus. Temos apskaičiuojamos vietoje, saugomos įrenginyje, keičiasi kas savaitę ir priklauso nuo naudotojo valdiklių chrome://settings/adPrivacy.

Protected Audience API — retaikinimas ir pakartotinė rinkodara

Protected Audience, anksčiau FLEDGE, palaiko retaikinimą gyvą be bendro kryžminių svetainių identifikatoriaus. Reklamuotojai savo svetainėje priskiria naudotoją palūkanų grupei; kai naudotojas apsilanko dalyvaujančio leidėjo svetainėje, Fenced Frame vyksta įrenginio aukcionas ir parenka kūrybinį turinį. Laimėjęs skelbimas rodomas neleidžiant leidėjui žinoti, kuri palūkanų grupė atitiko.

Attribution Reporting API — konversijų matavimas

Attribution Reporting pakeičia konversijų pikselius matavimo naudojimo atvejų poaibio atveju. Ji palaiko įvykių lygio ataskaitas (triukšmingas, prarastas, vienai konversijai) ir suvestines apibendrintas ataskaitas (statistiškai šališkumo pašalintos apibendrinamos). Skirtingai nuo senojo pikselio, ji neatskleidžia individualaus naudotojo ir konversijos ryšio.

Shared Storage ir Fenced Frames

Shared Storage yra visur rašomas, smėlio dėžėje skaitomas raktų ir reikšmių saugykla kryžminio svetainių naudojimo atvejais, tokiais kaip dažnumo ribojimas ir A/B eksperimentų nuoseklumas. Fenced Frames yra izoliuoti iframe elementai, kurie neleidžia juos supančiam puslapiui perskaityti pateikto skelbimo ar jo sąveikos duomenų.

Ar Privacy Sandbox reikia sutikimo?

Tai yra vienas labiausiai nesuprastas klausimas 2026 m. reklamos technologijų aplinkoje, o atsakymas priklauso nuo jurisdikcijos.

Pagal GDPR ir ePrivacy

Europos duomenų apsaugos taryba nepaskelbė bendros pozicijos, tačiau nacionalinės institucijos buvo aiškesnės. Jungtinės Karalystės ICO, Italijos Garante ir Prancūzijos CNIL visi laikosi nuomonės, kad Topics ir Protected Audience reikalauja išankstinio opt-in sutikimo ten, kur apdoroja asmens duomenis, įskaitant bet kokį apdorojimą, kuris rašo ar skaito būseną naudotojo įrenginyje. Logika: naršyklė vis dar vietoje saugo palūkanų temas ir palūkanų grupes, o document.browsingTopics() kvietimas perduoda nustatyto pobūdžio asmens duomenis trečiajai šaliai. Tai reglamentuojama ePrivacy direktyvos 5 straipsnio 3 dalimi, kuri reikalauja sutikimo bet kokiai prieigai prie naudotojo terminalo įrenginio ar saugojimui jame, viršijančiam tai, kas griežtai būtina prašomai paslaugai.

Google pozicija yra labiau leidžiamoji — jie teigia, kad API yra sukurtos siekiant apsaugoti privatumą ir kad sutikimo reikalavimai gali būti netaikomi visais kontekstais. Tai nėra reguliavimo institucijos pozicija. Laikyti Privacy Sandbox sutikimo atžvilgiu neapmokestintu Europoje yra didelės rizikos pozicija.

Pagal CCPA, CPRA ir JAV valstijų įstatymus

Jungtinėse Valstijose Privacy Sandbox srautai paprastai laikomi asmens informacijos dalijimusi, skirtu kryžminio konteksto elgsenos reklamai pagal CPRA. Tai reiškia, kad jie suaktyvina teisę nesutikti ir turi būti gerbiami per Global Privacy Control signalus ir kitus universalius nesutikimo mechanizmus. Faktas, kad Topics duomenys gaunami iš naršyklės, o ne parduodami iš trečiosios šalies brokerio, jų neatleidžia.

Paties Chrome valdikliai

Chrome teikia naudotojams skirtus perjungiklius chrome://settings/adPrivacy Topics, Protected Audience ir Attribution Reporting atvejais. Šie naudotojų pasirinkimai yra šalia — ne vietoj — jūsų CMP sutikimo būsenos. Naudotojas, kuris savo reklaminiame juostiniame skelbime pasakė ne reklaminiams slapukams, bet taip — Topics Chrome pasauliniuose nustatymuose, vis tiek per juostinį skelbimą jums pasakė ne. Jūsų dėklas turi gerbti griežtesnį iš dviejų signalų.

Sutikimo sluoksnis, kurio jums iš tikrųjų reikia

Gamybos lygio 2026 m. sutikimo dėklas Privacy Sandbox API laiko atskiromis apdorojimo veiklomis, kiekviena valdoma per IAB TCF tikslus arba lygiavertes valstijų įstatymų kategorijas.

Sandbox API susiejimas su TCF tikslais

• Topics API — IAB TCF 2 tikslas (Pasirinkti pagrindinius skelbimus) ir bent 3 tikslas (Sukurti suasmenintų skelbimų profilį); 4 tikslas (Pasirinkti suasmenintus skelbimus), jei temos tiekia taikymą.
• Protected Audience — 3 ir 4 tikslas, plius 7 tikslas (Matuoti skelbimų efektyvumą), jei aukcione naudojami rezultatų duomenys.
• Attribution Reporting — 7 tikslas (Matuoti skelbimų efektyvumą) ir 9 tikslas (Suprasti auditorijas per statistiką).
• Shared Storage dažnumo ribojimui — 3 tikslas, kai tiekia suasmeninimą, arba teisėtų interesų pagrindas, kai tai yra grynas dažnumo valdymas.

Susiejimas su Google Consent Mode v2

Google Consent Mode v2 signalai susiejami su Privacy Sandbox elgesiu:

• ad_storage atmesta — visiškai išjunkite Topics ir Protected Audience API kvietimus
• ad_user_data atmesta — blokuokite Attribution Reporting nuo naudotojo srities duomenų siuntimo
• ad_personalization atmesta — praleiskite Topics įvestis taikymo logikoje

JAV valstijų signalų apdorojimas

JAV srauto atveju jūsų sutikimo sluoksnis turėtų patikrinti Global Privacy Control ir taikomus valstijų nesutikimo signalus. Kai JAV naudotojas pasirinko nesutikti su dalijimusi, nuslopinkite document.browsingTopics(), nekvieskite joinAdInterestGroup ir pašalinkite Attribution Reporting registracijos antraštes.

Praktiniai įgyvendinimo modeliai

Leidėjai, jau diegę Privacy Sandbox, paprastai laikosi vieno iš dviejų architektūrinių modelių.

1 modelis: serverio pusės orkestracija

Jūsų kilmės puslapio pirmosios šalies žymių tvarkyklė renka sutikimo būseną, naudotojo jurisdikciją ir bet kokius signalų pakeitimus, tada sąlygiškai pateikia Privacy Sandbox kabliukus puslapyje. Reklamos serveris ir SSP gauna sutikimo vėliavėles per kainos siūlymo užklausą ir jie nusprendžia, ar kviesti Topics, Protected Audience, ar nė vieno. Šis modelis centralizuoja logiką ir palaiko sutikimo būseną autoritetinga.

2 modelis: antraščių kainos siūlymo apvalkalo integracija

Prebid.js ir kiti antraščių kainos siūlymo apvalkalai dabar palaiko Privacy Sandbox modulius. Apvalkalas skaito sutikimo signalą, konfigūruoja Topics kvietimo elgesį ir perduoda aukciono rezultatą per Protected Audience, kai leidžiama. Šis metodas yra lengvesnis diegti, tačiau stumia daugiau logikos į klientą ir sugriežtina priklausomybę nuo apvalkalo leidimo kadencijos.

Ką patikrinti

• Patvirtinkite, kad document.browsingTopics() nėra iškviečiamas, nebent CMP reklamos sutikimas yra teigiamas ir nėra jokio nesutikimo signalo
• Patvirtinkite, kad joinAdInterestGroup ir runAdAuction valdomi tomis pačiomis sąlygomis
• Patvirtinkite, kad Attribution Reporting registracijos antraštės siunčiamos tik atsakymuose naudotojams, kurių sutikimo būsena leidžia matavimą
• Patvirtinkite, kad TCF eilutės tiekėjų sąrašas vis dar atitinka SSP ir DSP, naudojančius Sandbox API jūsų inventoriuje
• Patvirtinkite, kad jūsų privatumo politika Topics, Protected Audience ir Attribution Reporting aprašo kaip atskiras apdorojimo veiklas su teisiniu pagrindu ir saugojimu

Ko Privacy Sandbox nedaro

Keli dažni nesusipratimai turi mirti prieš tai, kai planuojate biudžetą jiems.

Tai nėra sutikimo apėjimas

API sumažina reklamuotojams atskleidžiamus asmens duomenis, tačiau dėl to pagrindiniam apdorojimui Europos teisės pagrindu nereikia sutikimo. Atitikties teorija, kad Sandbox priėmimas leidžia praleisti CMP, yra neteisinga kiekvienoje ES/EEE jurisdikcijoje.

Šiandien tai nėra visiškas slapukų pakaitalas

Topics tiekia šiurkštų, prarastos kokybės taikymo signalą, kuris paprastai silpnesnis nei slapukais pagrįstos auditorijos. Protected Audience retaikinimo mastai vis dar bręsta. Attribution Reporting turi matavimo triukšmo grindis, kurios gali slėpti nedidelius konversijų padidėjimus. Leidėjas, šiandien perkeldamas visą monetizaciją į Sandbox, turėtų tikėtis RPM sumažėjimo 10–30 procentų, palyginti su slapukais pagrįstu dėklu tipiniam inventoriui.

Tai nėra nuolatinė dabartinėje formoje

Privacy Sandbox specifikacija vis dar tobulėja. Topics taksonomija plečiasi, Protected Audience palūkanų grupių apribojimai yra peržiūrimi, o reguliavimo atsakas tęsiasi. Sukurkite savo sutikimo sluoksnį konfigūracijos valdomu, o ne koduotu pagal dabartinę specifikaciją.

Tinkama pozicija 2026 m.

Privacy Sandbox geriausiai suprantama kaip vienas platesnės strategijos be slapukų sluoksnis, kartu su pirmosios šalies duomenimis, pardavėjų apibrėžtomis auditorijomis, kontekstiniu taikymu ir serverio pusės antraščių kainos siūlymu. 2026 m. laimės leidėjai, kurie traktuoja sutikimą kaip arbitrą, o ne kliūtį — tiekia Sandbox API tik ten, kur leidžia įstatymas ir naudotojo pasirinkimas, kitur švariai grįžta prie kontekstinio ir matuoja rezultatus abiem keliais su priemonėmis, kurios nenumato tapatybės.

Blogiausia pozicija yra laukiamoji. Reguliavimo institucijos jau rašo kitą taisyklių bangą — Jungtinės Karalystės Konkurencijos ir rinkų tarnybos Sandbox įsipareigojimai, vykstantys CNIL gairiai ir ES dirbtinio intelekto akto profiliavimo nuostatos — visi jie liečia šią sritį. Leidėjai, kurie 2026 m. tinkamai valdoma sutikimo dėklu integruos Privacy Sandbox, bus pasirengę toms taisyklėms. Tie, kurie ją prisegus kaip paskutinės minutės slapukų pakaitalą, ras save perrašančius jį esant spaudimui.