Какво всъщност замества Privacy Sandbox

Бисквитките на трети страни изпълняваха четири отделни рекламни функции: таргетиране на базата на интереси, ретаргетиране, измерване на реализации и ограничаване на честотата. Privacy Sandbox разделя тези функции на отделни API-та, всяко от тях с собствен профил за съгласие.

Topics API — Таргетиране на базата на интереси

Topics API присвоява на всеки браузър малък набор от широки теми за интереси — около пет теми на седмица, изтеглени от курирана таксономия от няколко стотин категории. Когато издателят извика document.browsingTopics(), браузърът връща до три теми, които рекламната технологична екосистема може да използва за контекстуална персонализация без никакъв идентификатор между сайтовете. Темите се изчисляват локално, съхраняват се на устройството, ротират се седмично и подлежат на потребителски контрол в chrome://settings/adPrivacy.

Protected Audience API — Ретаргетиране и ремаркетинг

Protected Audience, по-рано FLEDGE, поддържа ретаргетирането живо без споделен идентификатор между сайтовете. Рекламодателите включват потребителя в група по интереси на собствения си сайт; когато потребителят посети участващ издател, на устройството се провежда търг в Fenced Frame и се избира рекламен материал. Печелившата реклама се показва, без издателят да знае коя група по интереси е съвпаднала.

Attribution Reporting API — Измерване на реализации

Attribution Reporting замества пикселите за реализации за подмножество от случаи на използване за измерване. Поддържа отчети на ниво събитие (шумни, с пропуски, на реализация) и обобщени отчети (статистически безпристрастни обобщения). За разлика от наследения пиксел, той не разкрива индивидуалната връзка потребител-реализация.

Shared Storage и Fenced Frames

Shared Storage е хранилище с ключ-стойност, с право на запис от всякъде и четене в sandboxed среда, за случаи на употреба между сайтове като ограничаване на честотата и последователност на A/B експерименти. Fenced Frames са изолирани iframe-ове, предотвратяващи заобикалящата страница да чете показаната реклама или данните от нейните взаимодействия.

Изисква ли Privacy Sandbox съгласие?

Това е единственият най-неразбран въпрос в рекламно-технологичния пейзаж на 2026 г. и отговорът е специфичен за юрисдикцията.

Под GDPR и ePrivacy

Европейският комитет по защита на данните EDPB не е издал общо становище, но националните органи са били по-изрични. UK ICO, италианският Garante и CNIL на Франция са заели позицията, че Topics и Protected Audience изискват предварително съгласие opt-in, когато обработват лични данни, включително всяка обработка, която записва или чете от устройството на потребителя. Логиката: браузърът все още съхранява локално теми за интереси и групи по интереси, а извикването на document.browsingTopics() предава изведени лични данни на трета страна. Това е регулирано по член 5(3) от Директивата за ePrivacy, която изисква съгласие за всеки достъп до или съхранение на крайното оборудване на потребителя извън строго необходимото за исканата услуга.

Позицията на Google е по-разрешителна — те твърдят, че API-тата са проектирани да защитават поверителността и че изискванията за съгласие може да не се прилагат във всички контексти. Това не е позиция на регулатор. Третирането на Privacy Sandbox като освободен от съгласие в Европа е рискована позиция.

Под CCPA, CPRA и Законите на щатите на САЩ

В Съединените щати потоците на Privacy Sandbox обикновено се третират като споделяне на лична информация за поведенческо рекламиране в различен контекст съгласно CPRA. Това означава, че те задействат правото на отказ и трябва да бъдат спазвани чрез сигнали на Global Privacy Control и други универсални механизми за отказ. Фактът, че данните от Topics са получени от браузъра, а не продадени от брокер трета страна, не ги освобождава.

Собствените контроли на Chrome

Chrome предоставя превключватели за потребителя в chrome://settings/adPrivacy за Topics, Protected Audience и Attribution Reporting. Тези потребителски избори стоят наред с — не вместо — статуса на съгласие на вашия CMP. Потребител, казал не на рекламните бисквитки в банера ви, но да на Topics в глобалните настройки на Chrome, все още ви е казал не чрез банера. Вашата система трябва да спазва по-строгия от двата сигнала.

Слоят за съгласие, от който реално се нуждаете

Набор от инструменти за съгласие от производствен клас за 2026 г. третира API-тата на Privacy Sandbox като отделни дейности по обработка, всяка от тях преминаваща през цели на IAB TCF или еквивалентни категории на законите на щатите.

Съпоставяне на Sandbox API-та с целите на TCF

• Topics API — IAB TCF Цел 2 (Избор на основни реклами) и Цел 3 (Създаване на персонализиран рекламен профил) като минимум; Цел 4 (Избор на персонализирани реклами), ако темите захранват таргетирането.
• Protected Audience — Цел 3 и 4, плюс Цел 7 (Измерване на ефективността на рекламата), ако търгът използва данни за резултатите.
• Attribution Reporting — Цел 7 (Измерване на ефективността на рекламата) и Цел 9 (Разбиране на аудиторията чрез статистики).
• Shared Storage за ограничаване на честотата — Цел 3, където захранва персонализацията, или основание за законен интерес, където е чисто контрол на честотата.

Съпоставяне с Google Consent Mode v2

Сигналите на Google Consent Mode v2 се съпоставят с поведението на Privacy Sandbox:

• ad_storage отказано — напълно деактивирайте извикванията към Topics и Protected Audience API
• ad_user_data отказано — блокирайте Attribution Reporting да изпраща данни в обхвата на потребителя
• ad_personalization отказано — пропуснете въвеждането на Topics в логиката на таргетиране

Обработка на сигналите на щатите на САЩ

За трафик от САЩ, вашият слой за съгласие трябва да инспектира Global Privacy Control и приложимите сигнали за отказ на щатите. Когато потребител от САЩ се е отказал от споделяне, потиснете document.browsingTopics(), не извиквайте joinAdInterestGroup и премахнете хедърите за регистрация на Attribution Reporting.

Практически модели за изпълнение

Издателите, вече внедрили Privacy Sandbox, обикновено следват един от два архитектурни модела.

Модел 1: Оркестрация от страна на сървъра

Мениджър на тагове от първа страна на вашия произход събира статуса на съгласие, юрисдикцията на потребителя и всякакви заменяния на сигнали, след което условно рендерира куките на Privacy Sandbox на страницата. Рекламният сървър и SSP получават флаговете за съгласие чрез заявката за наддаване и те решават дали да извикат Topics, Protected Audience или нито едно. Този модел централизира логиката и поддържа статуса на съгласие авторитетен.

Модел 2: Интеграция с Header Bidding Wrapper

Prebid.js и другите wrapper-и за header bidding вече поддържат модули за Privacy Sandbox. Wrapper-ът чете сигнала за съгласие, конфигурира поведението на извикване на Topics и препраща резултата от търга чрез Protected Audience при разрешение. Този подход е по-лесен за внедряване, но прехвърля повече логика на клиента и затяга зависимостта ви от ритъма на версиите на wrapper-а.

Какво да одитирате

• Потвърдете, че document.browsingTopics() не се извиква, освен ако рекламното съгласие на CMP не е потвърдително и не е налице сигнал за отказ
• Потвърдете, че joinAdInterestGroup и runAdAuction са ограничени от същите условия
• Потвърдете, че хедърите за регистрация на Attribution Reporting се изпращат само при отговори за потребители, чийто статус на съгласие позволява измерване
• Потвърдете, че вашият списък с доставчици в TCF низа все още съответства на SSP-тата и DSP-тата, използващи Sandbox API-та в инвентара ви
• Потвърдете, че вашата политика за поверителност описва Topics, Protected Audience и Attribution Reporting като отделни дейности по обработка, с правно основание и срок на съхранение

Какво не прави Privacy Sandbox

Няколко разпространени погрешни схващания трябва да изчезнат, преди да планирате бюджета си срещу тях.

Не е заобиколен път за съгласие

API-тата намаляват личните данни, разкривани пред рекламодателите, но не правят основната обработка освободена от съгласие по европейско право. Теорията за съответствие, че приемането на Sandbox ви позволява да пропуснете CMP, е неправилна в каждата юрисдикция EU/EEA.

Днес не е пълна замяна на бисквитките

Topics предоставя груб, с пропуски таргетиращ сигнал, който обикновено е по-слаб от аудиторите, базирани на бисквитки. Мащабите на ретаргетиране с Protected Audience все още се развиват. Attribution Reporting има нива на шум при измерване, които могат да скрият малкото повишения на реализациите. Издател, прехвърлящ цялата монетизация в Sandbox днес, трябва да очаква спад на RPM с 10-30 процента спрямо стек, базиран на бисквитки при типичен инвентар.

Не е постоянен в сегашния си вид

Спецификацията на Privacy Sandbox все още се развива. Таксономията на Topics се разширява, ограниченията за групи по интереси на Protected Audience са под ревизия, а регулаторният отговор продължава. Проектирайте вашия слой за съгласие да бъде управляван от конфигурация, а не твърдо кодиран спрямо текущата спецификация.

Правилната позиция за 2026 г.

Privacy Sandbox най-добре се разбира като един слой от по-широка стратегия без бисквитки, наред с данни от първа страна, аудитории, дефинирани от продавача, контекстуално таргетиране и сървърно-странен header bidding. Издателите, които ще спечелят през 2026 г., ще бъдат тези, които третират съгласието като арбитър, а не пречка — захранват Sandbox API-тата само там, където законът и изборът на потребителя го позволяват, попадат обратно в контекстуалното навсякъде другаде и измерват резултатите по двата пътя с инструменти, които не приемат идентичност.

Най-лошата позиция е тази на изчакване. Регулаторите вече пишат следващата вълна правила — ангажиментите на Sandbox на UK Competition and Markets Authority, текущите насоки на CNIL и разпоредбите за профилиране на EU AI Act всички засягат тази тема. Издателите, изграждащи Privacy Sandbox в правилно ограничен стек за съгласие през 2026 г., ще бъдат готови за тези правила. Тези, добавящи го като заместване на бисквитките в последния момент, ще се окажат пренаписващи под натиск.