Што насамрэч замяняе 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 ў апошнюю хвіліну, апынуцца перапісваючымі пад ціскам.