Vad Privacy Sandbox faktiskt ersätter

Tredjepartscookies utförde fyra distinkta annonseringsfunktioner: intressebaserad targeting, retargeting, konverteringsmätning och frekvensbegränsning. Privacy Sandbox delar upp dessa i separata API:er, var och en med sin egen samtyckesprofil.

Topics API — Intressebaserad targeting

Topics API tilldelar varje webbläsare en liten uppsättning grovkorniga intresseteman — ungefär fem ämnen per vecka, hämtade från en kurerad taxonomi med ett par hundra kategorier. När en utgivare anropar document.browsingTopics() returnerar webbläsaren upp till tre ämnen som annonsteknikekosystemet kan använda för kontextuell personalisering utan någon identifierare över sajter. Ämnen beräknas lokalt, lagras på enheten, roterar varje vecka och omfattas av användarkontroller i chrome://settings/adPrivacy.

Protected Audience API — Retargeting och remarketing

Protected Audience, tidigare FLEDGE, håller retargeting vid liv utan en delad identifierare över sajter. Annonsörer lägger till en användare i en intressegrupp på sin egen sajt; när användaren besöker en deltagande utgivare körs en auktion på enheten i en Fenced Frame och väljer en kreativ. Den vinnande annonsen renderas utan att utgivaren får veta vilken intressegrupp som matchade.

Attribution Reporting API — Konverteringsmätning

Attribution Reporting ersätter konverteringspixlar för en delmängd av mätningsanvändningsfall. Det stöder händelsenivårapporter (brusiga, förluststämda, per konvertering) och aggregerade sammanfattningsrapporter (statistiskt avbiasade sammanräkningar). Till skillnad från den äldre pixeln exponerar det inte den individuella användar-till-konverteringslänken.

Shared Storage och Fenced Frames

Shared Storage är ett nyckel-värde-lager som kan skrivas var som helst men läsas i sandbox för användningsfall över sajter som frekvensbegränsning och A/B-experimentkonsistens. Fenced Frames är isolerade iframes som förhindrar den omgivande sidan från att läsa den renderade annonsen eller dess interaktionsdata.

Kräver Privacy Sandbox samtycke?

Detta är den enda mest missförstådda frågan i annonstekniklandskapet 2026, och svaret är jurisdiktionsspecifikt.

Under GDPR och ePrivacy

Europeiska dataskyddsstyrelsen har inte utfärdat en allmän ståndpunkt, men nationella myndigheter har varit mer explicita. Brittiska ICO, italienska Garante och franska CNIL har alla intagit ståndpunkten att Topics och Protected Audience kräver föregående opt-in-samtycke där de behandlar personuppgifter, inklusive all behandling som skriver eller läser tillstånd på användarens enhet. Logiken: webbläsaren lagrar fortfarande intresseämnen och intressegrupper lokalt, och anropet document.browsingTopics() överför härledda personuppgifter till en tredje part. Det regleras under artikel 5(3) i ePrivacy-direktivet, som kräver samtycke för all tillgång till eller lagring på användarens terminalutrustning utöver vad som är strikt nödvändigt för den begärda tjänsten.

Googles ståndpunkt är mer tillåtande — de hävdar att API:erna är integritetsskyddande av design och att samtyckeskrav kanske inte gäller i alla sammanhang. Detta är inte en regulatorisk ståndpunkt. Att behandla Privacy Sandbox som samtyckesbefriat i Europa är en högriskattityd.

Under CCPA, CPRA och delstatliga lagar i USA

I USA behandlas Privacy Sandbox-flöden i allmänhet som delning av personuppgifter för beteendebaserad annonsering i olika sammanhang under CPRA. Det innebär att de utlöser rätten till opt-out och måste respekteras genom Global Privacy Control-signaler och andra universella opt-out-mekanismer. Det faktum att Topics-data härrör från webbläsaren snarare än säljs från en tredjepartsmäklare undantar det inte.

Chromes egna kontroller

Chrome tillhandahåller användarvänliga reglage i chrome://settings/adPrivacy för Topics, Protected Audience och Attribution Reporting. Dessa användarval finns vid sidan om — inte i stället för — din CMPs samtyckestillstånd. En användare som har sagt nej till annonscookies i din banner men ja till Topics i Chromes globala inställningar har ändå sagt nej till dig via bannern. Din stack måste respektera den striktare av de två signalerna.

Det samtyckeslager du faktiskt behöver

En produktionsklar samtyckesstack för 2026 behandlar Privacy Sandbox API:er som distinkta behandlingsaktiviteter, var och en portad genom IAB TCF-syften eller motsvarande delstatliga lagkategorier.

Kartläggning av Sandbox API:er till TCF-syften

• Topics API — IAB TCF Syfte 2 (Välj grundläggande annonser) och Syfte 3 (Skapa en personaliserad annonsprofil) som minimum; Syfte 4 (Välj personaliserade annonser) om ämnen matar targeting.
• Protected Audience — Syfte 3 och 4, plus Syfte 7 (Mät annonsprestation) om auktionen använder utfallsdata.
• Attribution Reporting — Syfte 7 (Mät annonsprestation) och Syfte 9 (Förstå målgrupper genom statistik).
• Shared Storage för frekvensbegränsning — Syfte 3 där det matar personalisering, eller grund för berättigat intresse där det enbart är frekvensstyrning.

Kartläggning till Google Consent Mode v2

Googles Consent Mode v2-signaler kartläggs till Privacy Sandbox-beteende:

• ad_storage nekad — inaktivera Topics och Protected Audience API-anrop helt
• ad_user_data nekad — blockera Attribution Reporting från att skicka användaromfattade data
• ad_personalization nekad — hoppa över Topics-indata i targeting-logiken

Hantering av delstatssignaler i USA

För US-trafik bör ditt samtyckeslager inspektera Global Privacy Control och tillämpliga delstatliga opt-out-signaler. När en amerikansk användare har opt-out från delning, undertrycka document.browsingTopics(), anropa inte joinAdInterestGroup och ta bort Attribution Reporting-registreringshuvuden.

Praktiska implementationsmönster

Utgivare som redan har lanserat Privacy Sandbox följer i allmänhet ett av två arkitekturmönster.

Mönster 1: Serversidig orkestrering

En förstapartstagghanterar på ditt ursprung samlar in samtyckestillståndet, användares jurisdiktion och eventuella signalavvikelser och renderar sedan villkorligt Privacy Sandbox-krokarna till sidan. Annonsservern och SSP tar emot samtyckeflaggor via budförfrågan och de bestämmer om de ska anropa Topics, Protected Audience eller ingen av dem. Det här mönstret centraliserar logiken och håller samtyckestillståndet auktoritativt.

Mönster 2: Header bidding-omslutningsintegration

Prebid.js och andra header bidding-omslutningar stöder nu Privacy Sandbox-moduler. Omslutningen läser samtyckessignalen, konfigurerar Topics-anropsbeteendet och vidarebefordrar auktionsresultatet via Protected Audience när det är tillåtet. Det här tillvägagångssättet är lättare att driftsätta men skjuter mer logik till klienten och ökar ditt beroende av omslutningens lanseringshastighet.

Vad du bör granska

• Bekräfta att document.browsingTopics() inte anropas om inte CMPs annonseringssamtycke är bekräftande och ingen opt-out-signal finns
• Bekräfta att joinAdInterestGroup och runAdAuction är portade av samma villkor
• Bekräfta att Attribution Reporting-registreringshuvuden endast skickas på svar för användare vars samtyckestillstånd tillåter mätning
• Bekräfta att din leverantörslista i TCF-strängen fortfarande matchar de SSP:er och DSP:er som använder Sandbox API:er på ditt inventarie
• Bekräfta att din integritetspolicy beskriver Topics, Protected Audience och Attribution Reporting som distinkta behandlingsaktiviteter med rättslig grund och lagring

Vad Privacy Sandbox inte gör

Flera vanliga missuppfattningar måste dö innan du budgeterar mot dem.

Det är inte ett sätt att kringgå samtycke

API:erna minskar de personuppgifter som exponeras för annonsörer, men de gör inte den underliggande behandlingen samtyckesbefriad under europeisk lag. Efterlevnadsteorin att Sandbox-adoption låter dig hoppa över en CMP är felaktig i varje EU/EEA-jurisdiktion.

Det är inte en fullständig ersättning för cookies idag

Topics levererar en grovkornig, förluststämd targeting-signal som vanligtvis är svagare än cookiebaserade målgrupper. Protected Audience retargeting-skalor mognar fortfarande. Attribution Reporting har mätningsbrus-golv som kan dölja små konverteringslyft. En utgivare som flyttar all monetisering till Sandbox idag bör förvänta sig RPM-minskningar på 10–30 procent i förhållande till en cookiebaserad stack på typiskt inventarie.

Det är inte permanent i sin nuvarande form

Privacy Sandbox-specifikationen utvecklas fortfarande. Topics-taxonomin expanderar, Protected Audiences intressegruppsgränser är under revision och det regulatoriska svaret pågår. Utforma ditt samtyckeslager så att det är konfigurationsdrivet, inte hårdkodat till den aktuella specifikationen.

Rätt inställning för 2026

Privacy Sandbox förstås bäst som ett lager i en bredare cookielös strategi, tillsammans med förstapartsdata, säljardefinierade målgrupper, kontextuell targeting och serversidig header bidding. De utgivare som vinner 2026 är de som behandlar samtycke som skiljedomaren, inte hindret — matar Sandbox API:er bara där lag och användarval tillåter, faller tillbaka rent till kontextuell annonsering överallt annars och mäter utfall på båda vägarna med verktyg som inte förutsätter identitet.

Den sämsta inställningen är att vänta och se. Regulatorer skriver redan nästa våg av regler — UK Competition and Markets Authoritys Sandbox-åtaganden, pågående CNIL-vägledning och EU AI Acts profileringsparagrafer berör alla denna mark. De utgivare som bygger in Privacy Sandbox i en korrekt portad samtyckesstack 2026 kommer att vara redo för dessa regler. De som bultar på det som en sista-minuten-cookie-ersättning kommer att finna sig tvungna att skriva om under press.