Mitä Privacy Sandbox oikeastaan korvaa

Kolmannen osapuolen evästeet kantoivat neljä erillistä mainostoimintoa: kiinnostuspohjaisen kohdentamisen, uudelleenkohdentamisen, konversiomittauksen ja taajuusrajoituksen. Privacy Sandbox jakaa nämä erillisiin sovellusliittymiin, joilla kullakin on oma suostumusprofiilinsä.

Topics API — Kiinnostuspohjainen kohdentaminen

Topics API määrittää jokaiselle selaimelle pienen joukon karkean tason kiinnostusaiheita — noin viisi aihetta viikossa, poimittuina kuratoituun taksonomiaan kuuluvista muutamasta sadasta kategoriasta. Kun julkaisija kutsuu document.browsingTopics(), selain palauttaa enintään kolme aihetta, joita mainosteknologian ekosysteemi voi käyttää kontekstuaaliseen personointiin ilman sivustojen välistä tunnistetta. Aiheet lasketaan paikallisesti, tallennetaan laitteelle, vaihtuvat viikoittain ja ovat käyttäjän hallinnan alaisia chrome://settings/adPrivacy-sivulla.

Protected Audience API — Uudelleenkohdentaminen ja remarketing

Protected Audience, entinen FLEDGE, pitää uudelleenkohdentamisen elossa ilman jaettua sivustojen välistä tunnistetta. Mainostajat liittävät käyttäjän kiinnostusryhmään omalla sivustollaan; kun käyttäjä vierailee osallistuvalla julkaisijalla, laitekohtainen huutokauppa suoritetaan Fenced Frame -kehyksessä ja valitaan luova sisältö. Voittava mainos renderöidään ilman, että julkaisija tietää, mikä kiinnostusryhmä osui.

Attribution Reporting API — Konversiomittaus

Attribution Reporting korvaa konversiopikselit mittauksen käyttötapausten osajoukon osalta. Se tukee tapahtumatasoisia raportteja (meluisia, häviöllisiä, per konversio) ja yhteenvetoraportteja (tilastollisesti poistettuja koottuja raportteja). Toisin kuin perinteinen pikseli, se ei paljasta yksittäistä käyttäjä-konversio-linkkiä.

Shared Storage ja Fenced Frames

Shared Storage on kirjoita mihin tahansa, lue hiekkalaatikossa -avain-arvo-varasto sivustojen välisiin käyttötapauksiin, kuten taajuusrajoitukseen ja A/B-kokeiden johdonmukaisuuteen. Fenced Frames ovat eristettyjä iframeja, jotka estävät ympäröivää sivua lukemasta renderöityä mainosta tai sen vuorovaikutustietoja.

Vaatiiko Privacy Sandbox suostumuksen?

Tämä on vuoden 2026 mainosteknologiamaiseman eniten väärinymmärretty kysymys, ja vastaus on lainkäyttöaluekohtainen.

GDPR:n ja ePrivacyn alla

Euroopan tietosuojaneuvosto ei ole antanut yleistä kantaa, mutta kansalliset viranomaiset ovat olleet selvempiä. UK ICO, Italian Garante ja Ranskan CNIL ovat kaikki ottaneet kannan, että Topics ja Protected Audience vaativat etukäteissuostumuksen siellä, missä ne käsittelevät henkilötietoja, mukaan lukien käsittely, joka kirjoittaa tai lukee tilaa käyttäjän laitteella. Logiikka: selain tallentaa edelleen kiinnostusaiheet ja kiinnostusryhmät paikallisesti, ja document.browsingTopics()-kutsu välittää johdettuja henkilötietoja kolmannelle osapuolelle. Tätä säädellään ePrivacy-direktiivin 5(3) artiklan nojalla, joka edellyttää suostumusta mihin tahansa käyttäjän päätelaitteelle pääsyyn tai sinne tallentamiseen, mikä ei ole ehdottoman välttämätöntä pyydetyn palvelun kannalta.

Googlen kanta on sallivampi — he väittävät, että sovellusliittymät on suunniteltu yksityisyyttä suojeleviksi ja suostumusvaatimukset eivät välttämättä koske kaikkia konteksteja. Tämä ei ole sääntelyviranomaisen kanta. Privacy Sandboxin kohteleminen suostumuksesta vapaana Euroopassa on korkean riskin asenne.

CCPA:n, CPRA:n ja Yhdysvaltain osavaltion lakien alla

Yhdysvalloissa Privacy Sandbox -virrat luokitellaan yleensä henkilötietojen jakamiseksi kontekstien väliseen käyttäytymispohjaiseen mainontaan CPRA:n nojalla. Tämä tarkoittaa, että ne laukaisevat kieltäytymisoikeuden ja niitä on noudatettava Global Privacy Control -signaalien ja muiden universaalien kieltäytymismekanismien kautta. Se, että Topics-data on johdettu selaimesta eikä myyty kolmannen osapuolen välittäjältä, ei vapauta sitä.

Chromen omat kontrollit

Chrome tarjoaa käyttäjälle näkyviä kytkimiä chrome://settings/adPrivacy-sivulla Topicsia, Protected Audienceta ja Attribution Reportingia varten. Nämä käyttäjän valinnat sijaitsevat rinnalla — eivät korvaten — CMP:n suostumustilaa. Käyttäjä, joka on sanonut ei mainosevästeille bannerissasi, mutta kyllä Topicsille Chromen globaaleissa asetuksissa, on silti sanonut sinulle ei bannerin kautta. Pinosi on noudatettava kahdesta signaalista tiukempaa.

Suostumustaso, jota todella tarvitset

Tuotantotason 2026-suostumuspino kohtelee Privacy Sandbox -sovellusliittymiä erillisinä käsittelytoimintoina, joista kukin on portattu IAB TCF -tarkoitusten tai vastaavien osavaltion lakikategorioiden kautta.

Sandbox-sovellusliittymien yhdistäminen TCF-tarkoituksiin

• Topics API — IAB TCF Tarkoitus 2 (Valitse perusmainokset) ja Tarkoitus 3 (Luo personoitu mainnosprofiili) vähintään; Tarkoitus 4 (Valitse personoidut mainokset), jos aiheet ruokkivat kohdentamista.
• Protected Audience — Tarkoitus 3 ja 4, sekä Tarkoitus 7 (Mittaa mainosten tehokkuutta), jos huutokauppa käyttää tulosdataa.
• Attribution Reporting — Tarkoitus 7 (Mittaa mainosten tehokkuutta) ja Tarkoitus 9 (Ymmärrä yleisöjä tilastojen kautta).
• Shared Storage taajuusrajoitukseen — Tarkoitus 3, jos se ruokkii personointia, tai oikeutettu etu -perusta, jos se on puhtaasti taajuuden hallintaa.

Yhdistäminen Google Consent Mode v2:een

Googlen Consent Mode v2 -signaalit yhdistyvät Privacy Sandbox -toimintaan:

• ad_storage kielletty — poista Topics- ja Protected Audience -sovellusliittymäkutsut kokonaan käytöstä
• ad_user_data kielletty — estä Attribution Reportingia lähettämästä käyttäjälaajuista dataa
• ad_personalization kielletty — ohita Topics-syötteet kohdentamislogiikassa

Yhdysvaltain osavaltion signaalin käsittely

Yhdysvaltain liikenteelle suostumustasosi tulee tarkistaa Global Privacy Control ja sovellettavat osavaltion kieltäytymissignaalit. Kun yhdysvaltalainen käyttäjä on kieltäytynyt jakamisesta, estä document.browsingTopics(), älä kutsu joinAdInterestGroup, ja poista Attribution Reporting -rekisteröintiotsikot.

Käytännön toteutusmallit

Julkaisijat, jotka ovat jo ottaneet Privacy Sandboxin käyttöön, noudattavat yleensä yhtä kahdesta arkkitehtuurimallista.

Malli 1: Palvelinpuolen orkestrointi

Alkuperäisessäsi oleva ensimmäisen osapuolen tunnistehallinta kerää suostumustilan, käyttäjän lainkäyttöalueen ja mahdolliset signaalin ohitukset, sitten renderöi ehdollisesti Privacy Sandbox -koukut sivulle. Mainospalvelin ja SSP saavat suostumusliput tarjouspyynnön kautta, ja ne päättävät, kutsutaanko Topics, Protected Audience vai ei kumpaakaan. Tämä malli keskittää logiikan ja pitää suostumustilan auktoritatiivisena.

Malli 2: Header Bidding Wrapper -integraatio

Prebid.js ja muut header bidding -käärijät tukevat nyt Privacy Sandbox -moduuleja. Käärijä lukee suostumussignaalin, konfiguroi Topics-kutsun toiminnan ja välittää huutokaupan tuloksen Protected Audiencen kautta, kun se on sallittu. Tämä lähestymistapa on kevyempi käyttöönottaa, mutta siirtää enemmän logiikkaa asiakkaalle ja tiukentaa riippuvuutesi käärijän julkaisutahtiin.

Mitä tarkistaa

• Varmista, että document.browsingTopics()-kutsua ei tehdä, ellei CMP:n mainontasuostumus ole myönteinen ja kieltäytymissignaalia ei ole läsnä
• Varmista, että joinAdInterestGroup ja runAdAuction on portattu samoilla ehdoilla
• Varmista, että Attribution Reporting -rekisteröintiotsikot lähetetään vain vastauksissa käyttäjille, joiden suostumustila sallii mittauksen
• Varmista, että toimittajaluettelosi TCF-merkkijonossa vastaa edelleen SSP:itä ja DSP:itä, jotka käyttävät Sandbox-sovellusliittymiä varastossasi
• Varmista, että tietosuojakäytäntösi kuvaa Topics, Protected Audience ja Attribution Reporting erillisinä käsittelytoimintoina oikeudellisen perustan ja säilytyksen kanssa

Mitä Privacy Sandbox ei tee

Useita yleisiä väärinkäsityksiä on haudattava ennen kuin budjetoitua niitä vastaan.

Se ei ole suostumuksen kiertotapa

Sovellusliittymät vähentävät mainostajille paljastettuja henkilötietoja, mutta ne eivät tee taustalla olevasta käsittelystä suostumuksesta vapaata Euroopan lain nojalla. Vaatimustenmukaisuusteoria siitä, että Sandbox-käyttöönotto antaa sinun ohittaa CMP:n, on väärä jokaisessa EU/EEA-lainkäyttöalueessa.

Se ei ole tänään täydellinen evästeiden korvike

Topics toimittaa karkean, häviöllisen kohdentamissignaalin, joka on tyypillisesti heikompi kuin evästepohjainen yleisö. Protected Audience -uudelleenkohdentamisen skaala on vielä kypsymässä. Attribution Reportingilla on mittaushälytysalat, jotka voivat piilottaa pienet konversiokasvut. Julkaisija, joka siirtää kaiken monetisoinnin tänään Sandboxiin, tulisi odottaa RPM-laskua 10–30 prosenttia suhteessa evästepohjaiseen pinoon tyypillisellä varastolla.

Se ei ole pysyvä nykyisessä muodossaan

Privacy Sandbox -spesifikaatio kehittyy edelleen. Topics-taksonomia laajenee, Protected Audience -kiinnostusryhmärajoituksia tarkistetaan, ja sääntelyreaktio on käynnissä. Suunnittele suostumustasosi konfiguraatiopohjaiseksi, ei hardkoodatuksi nykyiseen spesifikaatioon.

Oikea asenne vuodelle 2026

Privacy Sandbox ymmärretään parhaiten yhtenä kerroksena laajemmassa evästeettömässä strategiassa, ensimmäisen osapuolen datan, myyjän määrittelemien yleisöjen, kontekstuaalisen kohdentamisen ja palvelinpuolen header biddingin rinnalla. Vuonna 2026 voittavat julkaisijat ovat niitä, jotka kohtelevat suostumusta välimiehenä, ei esteenä — ruokkien Sandbox-sovellusliittymiä vain siellä, missä laki ja käyttäjän valinta sen sallivat, vetäytyen siististi kontekstuaaliseen kaikkialla muualla, ja mitaten tuloksia molemmilla poluilla työkaluilla, jotka eivät oleta identiteettiä.

Huonoin asenne on odota-ja-katso. Sääntelyviranomaiset kirjoittavat jo seuraavaa sääntöaaltoa — UK Competition and Markets Authorityn Sandbox-sitoumukset, jatkuva CNIL-ohjaus ja EU AI Actin profiloinnin määräykset koskevat kaikki tätä aluetta. Julkaisijat, jotka rakentavat Privacy Sandboxin asianmukaisesti portattuun suostumuspinoon vuonna 2026, ovat valmiita näihin sääntöihin. Ne, jotka ruuvaavat sen viime hetken evästeen korvikeena, löytävät itsensä uudelleenkirjoittamasta paineen alla.