Hva Privacy Sandbox Egentlig Erstatter

Tredjeparts informasjonskapsler bar fire distinkte reklamefunksjoner: interessebasert målretting, retargeting, konverteringsmåling og frekvensgrensing. Privacy Sandbox deler disse inn i separate API-er, hver med sin egen samtykkeprofil.

Topics API — Interessebasert Målretting

Topics API tildeler hver nettleser et lite sett med grovkornede interessetemaer — rundt fem temaer per uke, hentet fra en kuratert taksonomi med noen hundre kategorier. Når en utgiver kaller document.browsingTopics(), returnerer nettleseren opptil tre temaer som annonseteknikk-økosystemet kan bruke til kontekstuell personalisering uten noen kryssside-identifikator. Temaer beregnes lokalt, lagres på enheten, roterer ukentlig og er underlagt brukerkontroller i chrome://settings/adPrivacy.

Protected Audience API — Retargeting og Remarketing

Protected Audience, tidligere FLEDGE, holder retargeting i live uten en delt kryssside-identifikator. Annonsører legger til en bruker i en interessegruppe på sitt eget nettsted; når brukeren besøker en deltakende utgiver, kjøres en auksjon på enheten i en Fenced Frame og velger et kreativt element. Den vinnende annonsen gjengis uten at utgiveren vet hvilken interessegruppe som matchet.

Attribution Reporting API — Konverteringsmåling

Attribution Reporting erstatter konverteringspikslene for en undergruppe av målebrukstilfeller. Det støtter hendelsesnivårapporter (støyete, tapsgivende, per konvertering) og aggregerte sammendragsrapporter (statistisk debiaserte sammendrag). I motsetning til den gamle pikselen, eksponerer den ikke den individuelle bruker-til-konvertering-koblingen.

Shared Storage og Fenced Frames

Shared Storage er en skriv-overalt, les-i-sandbox nøkkel-verdi-lagring for kryss-nettstedsbrukstilfeller som frekvensgrensing og A/B-eksperimentkonsistens. Fenced Frames er isolerte iframes som hindrer den omgivende siden fra å lese den gjengitte annonsen eller interaksjonsdataene.

Krever Privacy Sandbox Samtykke?

Dette er det enkelt spørsmålet som misforstås mest i annonseteknikklandskapet i 2026, og svaret er jurisdiksjons­spesifikt.

Under GDPR og ePrivacy

Det europeiske personvernrådet har ikke gitt en helhetlig posisjon, men nasjonale myndigheter har vært mer eksplisitte. UK ICO, den italienske Garante og Frankrikes CNIL har alle inntatt standpunktet om at Topics og Protected Audience krever forhåndssamtykke der de behandler personopplysninger, inkludert all behandling som skriver eller leser tilstand på brukerens enhet. Logikken: nettleseren lagrer fortsatt interessetemaer og interessegrupper lokalt, og document.browsingTopics()-kallet overfører utledet personlig data til en tredjepart. Det er regulert under Artikkel 5(3) i ePrivacy-direktivet, som krever samtykke for enhver tilgang til eller lagring på brukerens terminalutstyr utover det som er strengt nødvendig for den forespurte tjenesten.

Googles posisjon er mer permissiv — de hevder at API-ene er personvernbevarende av design og at samtykkekrav kanskje ikke gjelder i alle sammenhenger. Dette er ikke en regulatørposisjon. Å behandle Privacy Sandbox som samtykke­fri i Europa er en høyrisikoposisjon.

Under CCPA, CPRA og Amerikanske Statslover

I USA behandles Privacy Sandbox-flyter generelt som deling av personlig informasjon for atferdsreklame på tvers av kontekster under CPRA. Det betyr at de utløser fravalgsretten og må respekteres gjennom Global Privacy Control-signaler og andre universelle fravalgsmekhanismer. Det faktum at Topics-data er avledet fra nettleseren i stedet for solgt fra en tredjeparts megler, fritar den ikke.

Chromes Egne Kontroller

Chrome tilbyr brukervennlige brytere i chrome://settings/adPrivacy for Topics, Protected Audience og Attribution Reporting. Disse brukervalgende valgene sitter ved siden av — ikke i stedet for — CMP-ens samtykkestatus. En bruker som har sagt nei til reklameinformasjonskapsler i banneret ditt, men ja til Topics i Chromes globale innstillinger, har fortsatt fortalt deg nei gjennom banneret. Stakken din må respektere det strengeste av de to signalene.

Samtykklag som du Faktisk Trenger

En produksjons­klar samtykkestakk for 2026 behandler Privacy Sandbox-API-er som distinkte behandlingsaktiviteter, hver kontrollert gjennom IAB TCF-formål eller tilsvarende statlige lovkategorier.

Kartlegge Sandbox-API-er til TCF-formål

• Topics API — IAB TCF Formål 2 (Velg grunnleggende annonser) og Formål 3 (Opprett en personalisert annonseprofil) som minimum; Formål 4 (Velg personaliserte annonser) hvis temaene mater målretting.
• Protected Audience — Formål 3 og 4, pluss Formål 7 (Mål annonseyteevne) hvis auksjonen bruker utfallsdata.
• Attribution Reporting — Formål 7 (Mål annonseyteevne) og Formål 9 (Forstå publikum gjennom statistikk).
• Shared Storage for frekvensgrensing — Formål 3 der det mater personalisering, eller et grunnlag for berettiget interesse der det er rent frekvensstyring.

Kartlegge til Google Consent Mode v2

Googles Consent Mode v2-signaler kartlegges til Privacy Sandbox-atferd:

• ad_storage nektet — deaktiver Topics og Protected Audience API-kall helt
• ad_user_data nektet — blokker Attribution Reporting fra å sende bruker­scoped data
• ad_personalization nektet — hopp over Topics-inndata i målrettingslogikk

Håndtering av Amerikanske Statssignaler

For amerikansk trafikk bør samtykkemellomvaren din inspisere Global Privacy Control og gjeldende statlige fravalgs­signaler. Når en amerikansk bruker har meldt seg ut av deling, undertrykk document.browsingTopics(), ikke kall joinAdInterestGroup, og fjern Attribution Reporting-registreringshoder.

Praktiske Implementeringsmønstre

Utgivere som allerede har rullet ut Privacy Sandbox følger generelt ett av to arkitekturmønstre.

Mønster 1: Serversideorkestrering

En førstepartstagbehandler på origin­en din samler inn samtykkestatus, bruker­jurisdiksjon og eventuelle signaloverstyringer, og gjengir deretter betinget Privacy Sandbox-kroker på siden. Annonseserveren og SSP mottar samtykke­flagg gjennom budrequesten, og de bestemmer om de skal kalle Topics, Protected Audience eller ingen av delene. Dette mønsteret sentraliserer logikken og holder samtykkestatus autoritativ.

Mønster 2: Header Bidding Wrapper-integrering

Prebid.js og andre header bidding-wrappers støtter nå Privacy Sandbox-moduler. Wrapperen leser samtykkesignalet, konfigurerer Topics-kallatferden og videresender auksjonsresultatet gjennom Protected Audience når det er tillatt. Denne tilnærmingen er lettere å distribuere, men skyver mer logikk inn i klienten og stramme avhengigheten din til wrapper-utgivelseskadansen.

Hva som Skal Revideres

• Bekreft at document.browsingTopics() ikke kalles med mindre CMP-ens reklamekontekst er bekreftende og ingen fravalgs­signal er til stede
• Bekreft at joinAdInterestGroup og runAdAuction er kontrollert av de samme betingelsene
• Bekreft at Attribution Reporting-registreringshoder bare sendes på svar for brukere hvis samtykkestatus tillater måling
• Bekreft at leverandørlisten din i TCF-strengen fortsatt samsvarer med SSP-ene og DSP-ene som bruker Sandbox-API-er på beholdningen din
• Bekreft at personvernerklæringen din beskriver Topics, Protected Audience og Attribution Reporting som distinkte behandlingsaktiviteter, med rettslig grunnlag og oppbevaring

Hva Privacy Sandbox Ikke Gjør

Flere vanlige misforståelser må dø før du budsjetterer mot dem.

Det Er Ikke en Samtykkeomvei

API-ene reduserer personopplysningene som vises til annonsørene, men de gjør ikke den underliggende behandlingen samtykke­fri under europeisk lov. Overholdelses­teorien om at Sandbox-adopsjon lar deg hoppe over en CMP er feil i enhver EU/EEA-jurisdiksjon.

Det Er Ikke en Full Erstatning for Informasjonskapsler i Dag

Topics leverer et grovkornet, tapsgivende målrettingssignal som typisk er svakere enn informasjonskapsel­baserte målgrupper. Protected Audience-retargetingsskalaer modnes fortsatt. Attribution Reporting har støynivåer for måling som kan skjule små konverteringsøkninger. En utgiver som i dag flytter all monetisering til Sandbox bør forvente RPM-nedgang på 10–30 prosent i forhold til en informasjonskapsel­basert stakk på typisk beholdning.

Det Er Ikke Permanent i Sin Nåværende Form

Privacy Sandbox-spesifikasjonen er fortsatt under utvikling. Topics-taksonomien utvides, interessegruppeøkningene for Protected Audience er under revisjon, og det regelverks­messige svaret pågår. Design samtykkemellomvaren din til å være konfigurasjonsstyrt, ikke hardkodet til den nåværende spesifikasjonen.

Riktig Posisjon for 2026

Privacy Sandbox forstås best som ett lag i en bredere informasjonskapsel­fri strategi, ved siden av førsteparts data, selger­definerte målgrupper, kontekstuell målretting og server­side header bidding. Utgiverne som vinner i 2026 vil være de som behandler samtykke som voldgiftsmannen, ikke hinderet — mater Sandbox-API-er bare der lov og brukervalg tillater, faller rent tilbake til kontekstuell overalt ellers og måler resultater på tvers av begge veier med verktøy som ikke antar identitet.

Den verste posisjonen er vent-og-se. Regulatorer skriver allerede neste bølge med regler — UK Competition and Markets Authoritys Sandbox-forpliktelser, pågående CNIL-veiledning og EU AI Acts profileringsbestemmelser berører alle dette området. Utgiverne som bygger Privacy Sandbox inn i en ordentlig kontrollert samtykkestakk i 2026, vil være klare for disse reglene. De som bolter det på som en siste­minutts informasjons­kapsel­erstatning, vil finne seg i å omskrive under press.