Що насправді замінює Privacy Sandbox

Сторонні файли cookie виконували чотири різні рекламні функції: таргетинг за інтересами, ретаргетинг, вимірювання конверсій та обмеження частоти. 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 — це сховище ключ-значення «записати будь-де, читати в sandbox» для міжсайтових сценаріїв використання, таких як обмеження частоти та узгодженість A/B-експериментів. Fenced Frames — це ізольовані iframe, які не дають навколишній сторінці читати відрендерену рекламу або дані її взаємодії.

Чи потребує Privacy Sandbox згоди?

Це єдине найбільш неправильно зрозуміле питання в ландшафті рекламних технологій 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 загалом розглядаються як обмін персональними даними для поведінкової реклами між контекстами відповідно до 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 заборонено — повністю вимкніть виклики API Topics і Protected Audience
• 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, є помилковою в кожній юрисдикції EU/EEA.

Це не повна заміна файлів 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 UK Competition and Markets Authority, поточні вказівки CNIL і положення про профілювання EU AI Act — усі вони торкаються цього питання. Видавці, які включать Privacy Sandbox у належним чином закритий стек згоди у 2026 році, будуть готові до цих правил. Ті, хто підключить його як заміну cookie в останній момент, виявлять, що переписують усе під тиском.