Что на самом деле заменяет Privacy Sandbox

Сторонние файлы cookie несли четыре отдельные рекламные функции: таргетинг по интересам, ретаргетинг, измерение конверсий и ограничение частоты. Privacy Sandbox разделяет их на отдельные API, каждый со своим профилем согласия.

Topics API — таргетинг по интересам

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

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

Protected Audience, ранее FLEDGE, сохраняет ретаргетинг живым без общего межсайтового идентификатора. Рекламодатели добавляют пользователя в группу интересов на своём сайте; когда пользователь посещает участвующего издателя, аукцион на устройстве запускается в Fenced Frame и выбирает креатив. Выигравшая реклама отображается без того, чтобы издатель узнал, какая группа интересов совпала.

Attribution Reporting API — измерение конверсий

Attribution Reporting заменяет пиксели конверсий для подмножества сценариев измерения. Он поддерживает отчёты на уровне событий (зашумлённые, с потерями, на конверсию) и агрегированные сводные отчёты (статистически выровненные сводки). В отличие от устаревшего пикселя, он не раскрывает индивидуальную связь пользователя с конверсией.

Shared Storage и Fenced Frames

Shared Storage — это хранилище ключ-значение «пиши-где-угодно, читай-в-песочнице» для межсайтовых сценариев, таких как ограничение частоты и согласованность A/B-экспериментов. Fenced Frames — это изолированные iframe, которые не позволяют окружающей странице читать отображённую рекламу или данные о взаимодействии с ней.

Требует ли Privacy Sandbox согласия?

Это самый неправильно понимаемый вопрос в ландшафте ad tech 2026 года, и ответ зависит от юрисдикции.

Согласно GDPR и ePrivacy

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

Позиция Google более либеральна — они утверждают, что API сохраняют конфиденциальность по дизайну и что требования согласия могут не применяться во всех контекстах. Это не позиция регулятора. Рассматривать Privacy Sandbox как освобождённый от согласия в Европе — это высокорискованная позиция.

Согласно CCPA, CPRA и законам штатов США

В Соединённых Штатах потоки Privacy Sandbox обычно рассматриваются как совместное использование (sharing) персональной информации для межконтекстной поведенческой рекламы согласно CPRA. Это означает, что они активируют право на отказ и должны соблюдаться через сигналы Global Privacy Control и другие универсальные механизмы отказа. Тот факт, что данные Topics получены из браузера, а не проданы сторонним брокером, не освобождает их.

Собственный контроль Chrome

Chrome предоставляет пользовательские переключатели в chrome://settings/adPrivacy для Topics, Protected Audience и Attribution Reporting. Эти пользовательские выборы сосуществуют с состоянием согласия вашей CMP, а не заменяют его. Пользователь, который сказал «нет» рекламным cookie в вашем баннере, но «да» Topics в глобальных настройках Chrome, всё равно сказал вам «нет» через баннер. Ваш стек должен соблюдать более строгий из двух сигналов.

Слой согласия, который вам действительно нужен

Производственный стек согласия 2026 года рассматривает API Privacy Sandbox как отдельные виды обработки, каждый из которых ограничен целями IAB TCF или эквивалентными категориями закона штата.

Сопоставление API Sandbox с целями 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

Prebid.js и другие обёртки header bidding теперь поддерживают модули Privacy Sandbox. Обёртка читает сигнал согласия, настраивает поведение вызова Topics и пересылает результат аукциона через Protected Audience, когда разрешено. Этот подход легче развернуть, но он переносит больше логики в клиент и усиливает вашу зависимость от частоты релизов обёртки.

Что аудировать

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

Чего Privacy Sandbox не делает

Несколько распространённых заблуждений должны умереть, прежде чем вы заложите бюджет под них.

Это не обходной путь для согласия

API снижают объём персональных данных, раскрываемых рекламодателям, но не делают лежащую в основе обработку освобождённой от согласия согласно европейскому праву. Теория соответствия, что принятие Sandbox позволяет пропустить CMP, неверна в каждой юрисдикции ЕС/ЕЭЗ.

Это не полная замена cookie сегодня

Topics доставляет грубый сигнал таргетинга с потерями, который обычно слабее аудиторий на основе cookie. Масштабы ретаргетинга Protected Audience всё ещё развиваются. У Attribution Reporting есть нижние пороги шума измерения, которые могут скрывать небольшие приросты конверсий. Издатель, переносящий всю монетизацию на Sandbox сегодня, должен ожидать снижения RPM на 10–30 процентов относительно стека на основе cookie на типичном инвентаре.

Это не постоянно в своей текущей форме

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

Правильная позиция на 2026 год

Privacy Sandbox лучше всего понимать как один слой более широкой стратегии без cookie, наряду с данными первой стороны, аудиториями, определёнными продавцом, контекстным таргетингом и серверным header bidding. Издатели, которые выиграют в 2026 году, будут теми, кто рассматривает согласие как арбитра, а не препятствие — питая API Sandbox только там, где закон и выбор пользователя позволяют, чисто откатываясь к контексту везде и измеряя результаты по обоим путям с инструментарием, который не предполагает идентичность.

Худшая позиция — выжидательная. Регуляторы уже пишут следующую волну правил — обязательства Sandbox от британского Управления по конкуренции и рынкам, продолжающиеся рекомендации CNIL и положения о профилировании Закона ЕС об ИИ — все касаются этой почвы. Издатели, которые встроят Privacy Sandbox в правильно ограниченный стек согласия в 2026 году, будут готовы к этим правилам. Те, кто прикрутит его как замену cookie в последнюю минуту, окажутся переписывающими под давлением.