Hvad Privacy Sandbox faktisk erstatter

Tredjeparts cookies bar fire distinkte reklamefunktioner: interessebaseret målretning, retargeting, konverteringsmåling og frekvensbegrænsning. Privacy Sandbox deler disse op i separate API'er, der hver har sin egen samtykkeprofil.

Topics API — Interessebaseret målretning

Topics API tildeler hver browser et lille sæt grovkornede interesseemner — omkring fem emner om ugen, hentet fra en kureret taksonomi på et par hundrede kategorier. Når en udgiver kalder document.browsingTopics(), returnerer browseren op til tre emner, som ad tech-økosystemet kan bruge til kontekstuel personalisering uden nogen cross-site identifikator. Emner beregnes lokalt, gemmes på enheden, roterer ugentligt og er underlagt brugerkontrol i chrome://settings/adPrivacy.

Protected Audience API — Retargeting og Remarketing

Protected Audience, tidligere FLEDGE, holder retargeting i live uden en delt cross-site identifikator. Annoncører tilmelder en bruger til en interessegruppe på deres eget websted; når brugeren besøger en deltagende udgiver, kører en on-device auktion i en Fenced Frame og vælger et kreativt. Den vindende annonce gengives uden at udgiveren lærer, hvilken interessegruppe der matchede.

Attribution Reporting API — Konverteringsmåling

Attribution Reporting erstatter konverteringspixels for en delmængde af målebrugstilfælde. Det understøtter begivenheds-niveau-rapporter (støjende, lossende, per-konvertering) og aggregerede oversigtsrapporter (statistisk afvigelsekorrigerede sammenfatninger). I modsætning til den ældre pixel afslører den ikke det individuelle bruger-til-konvertering-link.

Shared Storage og Fenced Frames

Shared Storage er et nøgle-værdi-lager, der kan skrives overalt og læses i sandbox, til cross-site brugstilfælde som frekvensbegrænsning og A/B-eksperimentkonsistens. Fenced Frames er isolerede iframes, der forhindrer den omgivende side i at læse den renderede annonce eller dens interaktionsdata.

Kræver Privacy Sandbox samtykke?

Dette er det mest misforståede spørgsmål i 2026 ad tech-landskabet, og svaret er jurisdiktionsspecifikt.

Under GDPR og ePrivacy

Det Europæiske Databeskyttelsesråd EDPB har ikke udstedt en overordnet holdning, men nationale myndigheder har været mere eksplicitte. UK ICO, det italienske Garante og Frankrigs CNIL har alle taget det synspunkt, at Topics og Protected Audience kræver forudgående opt-in samtykke, hvor de behandler personoplysninger, herunder enhver behandling, der skriver til eller læser tilstand på brugerens enhed. Logikken: browseren gemmer stadig interesseemner og interessegrupper lokalt, og document.browsingTopics()-kaldet transmitterer udledte personoplysninger til en tredjepart. Det er reguleret under artikel 5(3) i ePrivacy-direktivet, som kræver samtykke til enhver adgang til eller lagring på brugerens terminaludstyr ud over hvad der er strengt nødvendigt for den anmodede tjeneste.

Googles holdning er mere tillader — de argumenterer for, at API'erne er privatlivsbevarende af design, og at samtykkekrav muligvis ikke gælder i alle sammenhænge. Dette er ikke en regulatørposition. At behandle Privacy Sandbox som samtykkefritaget i Europa er en høj-risiko holdning.

Under CCPA, CPRA og amerikanske statslige love

I USA behandles Privacy Sandbox-flows generelt som deling af personoplysninger til cross-context adfærdsmæssig annoncering under CPRA. Det betyder, at de udløser fravalgsretten og skal overholdes via Global Privacy Control-signaler og andre universelle fravalgsmekanismer. Det faktum, at Topics-data er afledt af browseren snarere end solgt fra en tredjeparts mægler, fritager det ikke.

Chromes egne kontroller

Chrome tilbyder brugervendte knapper i chrome://settings/adPrivacy for Topics, Protected Audience og Attribution Reporting. Disse brugervalg ligger ved siden af — ikke i stedet for — din CMP's samtykkestatus. En bruger, der har sagt nej til reklamecookies i dit banner, men ja til Topics i Chromes globale indstillinger, har stadig sagt nej til dig via banneret. Din stak skal respektere det strengeste af de to signaler.

Det samtykklag du faktisk har brug for

En produktionsklasse 2026-samtykkestak behandler Privacy Sandbox API'er som distinkte behandlingsaktiviteter, der hver er gated via IAB TCF-formål eller tilsvarende statslovsategorier.

Kortlægning af Sandbox API'er til TCF-formål

• Topics API — IAB TCF Formål 2 (Vælg grundlæggende annoncer) og Formål 3 (Opret en personaliseret annonceprofil) som minimum; Formål 4 (Vælg personaliserede annoncer) hvis emnerne fodrer målretning.
• Protected Audience — Formål 3 og 4, plus Formål 7 (Mål annoncepræstation) hvis auktionen bruger resultatdata.
• Attribution Reporting — Formål 7 (Mål annoncepræstation) og Formål 9 (Forstå målgrupper via statistik).
• Shared Storage til frekvensbegrænsning — Formål 3, hvor det fodrer personalisering, eller et legitimt-interesse grundlag, hvor det er ren frekvenskontrol.

Kortlægning til Google Consent Mode v2

Google Consent Mode v2-signaler kortlægges til Privacy Sandbox-adfærd:

• ad_storage nægtet — deaktivér Topics og Protected Audience API-kald fuldstændigt
• ad_user_data nægtet — blokér Attribution Reporting fra at sende brugeromfangsdata
• ad_personalization nægtet — spring Topics-input i målretningslogikken over

Håndtering af amerikanske statslige signaler

For amerikansk trafik bør dit samtykklag inspicere Global Privacy Control og gældende statslige fravalssignaler. Når en amerikansk bruger har fravalgt deling, undertryk document.browsingTopics(), kald ikke joinAdInterestGroup, og fjern Attribution Reporting registreringhoveder.

Praktiske implementationsmønstre

Udgivere, der allerede har rullet Privacy Sandbox ud, følger generelt et af to arkitektoniske mønstre.

Mønster 1: Serverside-orkestrering

En førstepartstagmanager på dit origin indsamler samtykkestatus, brugerjurisdiktion og eventuelle signal-overrides, og renderer derefter betinget Privacy Sandbox-hooks ind i siden. Annonceserveren og SSP modtager samtykke-flag via budrequesten, og de beslutter, om de skal kalde Topics, Protected Audience eller ingen. Dette mønster centraliserer logikken og holder samtykkestatus autoritativ.

Mønster 2: Header Bidding Wrapper-integration

Prebid.js og andre header bidding-wrappere understøtter nu Privacy Sandbox-moduler. Wrapperen læser samtykke-signalet, konfigurerer Topics-kaldadfærden og videresender auktionsresultatet via Protected Audience, når det er tilladt. Denne tilgang er lettere at implementere, men skubber mere logik ind i klienten og strammer din afhængighed af wrapper-udgivelsesrytmen.

Hvad der skal auditeres

• Bekræft, at document.browsingTopics() ikke kaldes, medmindre CMP's reklamesamtykke er bekræftende og intet fravalssignal er til stede
• Bekræft, at joinAdInterestGroup og runAdAuction er gated af de samme betingelser
• Bekræft, at Attribution Reporting registreringhoveder kun sendes på svar for brugere, hvis samtykkestatus tillader måling
• Bekræft, at din sælgerliste i TCF-strengen stadig matcher de SSP'er og DSP'er, der bruger Sandbox API'er på dit inventar
• Bekræft, at din privatlivspolitik beskriver Topics, Protected Audience og Attribution Reporting som distinkte behandlingsaktiviteter med retsgrundlag og opbevaring

Hvad Privacy Sandbox ikke gør

Flere almindelige misforståelser skal dø, inden du budgetterer imod dem.

Det er ikke en omvej til samtykke

API'erne reducerer de personoplysninger, der afsløres for annoncørerne, men de gør ikke den underliggende behandling samtykkefritaget under europæisk ret. Overholdelses-teorien om, at Sandbox-adoption giver dig mulighed for at springe en CMP over, er forkert i enhver EU/EEA-jurisdiktion.

Det er ikke en fuld erstatning for cookies i dag

Topics leverer et grovkornet, lossende målretningssignal, der typisk er svagere end cookie-baserede målgrupper. Protected Audience retargeting-skalaer modner stadig. Attribution Reporting har målenoisegulve, der kan skjule små konverteringsløft. En udgiver, der flytter al monetisering til Sandbox i dag, bør forvente RPM-fald på 10-30 procent i forhold til en cookie-baseret stak på typisk inventar.

Det er ikke permanent i sin nuværende form

Privacy Sandbox-specifikationen udvikler sig stadig. Topics-taksonomien udvides, Protected Audience-interessegruppegrænser er under revision, og den lovgivningsmæssige reaktion pågår. Design dit samtykklag til at være konfigurationsdrevet, ikke hardkodet til den nuværende spec.

Den rigtige holdning for 2026

Privacy Sandbox forstås bedst som ét lag i en bredere cookiefri strategi, ved siden af førstepartsdata, sælgerdefinerede målgrupper, kontekstuel målretning og serverside header bidding. De udgivere, der vinder i 2026, vil være dem, der behandler samtykke som dommer, ikke hindringen — fodrer Sandbox API'er kun, hvor lov og brugervalg tillader det, falder rent tilbage til kontekstuel overalt ellers og måler resultater på tværs af begge stier med værktøjer, der ikke antager identitet.

Den værste holdning er afvent-og-se. Regulatorer skriver allerede næste bølge af regler — UK Competition and Markets Authority's Sandbox-forpligtelser, løbende CNIL-vejledning og EU AI Act's profileringsprovision rører alle dette område. De udgivere, der bygger Privacy Sandbox ind i en ordentligt gated samtykkestak i 2026, vil være klar til disse regler. De, der sætter det på som en last-minute-cookie-erstatning, vil finde sig selv i at omskrive under pres.