Огляд GDPR і рекомендації щодо дотримання

Технічна специфікація Google для режиму додаткової згоди

Далі: Як вирішувати проблеми з упровадженням фреймворку EU TCF 2.2 від IAB

Якщо видавці хочуть співпрацювати з постачальниками рекламних технологій, які не застосовують TCF, вони повинні звертатися безпосередньо до представників платформ керування згодою.

У цьому документі наведено технічну специфікацію "Додаткова згода", яку слід використовувати лише в межах сертифікації Transparency & Consent Framework (TCF) версії 2 від IAB Europe. Її створено для того, щоб компанії, не зареєстровані в списку глобальних постачальників IAB Europe (GVL), отримували сигнали про прозорість і/або згоду. Ця специфікація дає видавцям, платформам керування згодою (CMP) і партнерам змогу запитувати й отримувати додаткову згоду (у межах реалізації TCF) для компаній, які ще не ввійшли до глобального списку постачальників IAB Europe, але представлені в списку постачальників рекламних технологій Google.

Зміни, пов’язані з версією 2 специфікації режиму додаткової згоди

Починаючи з грудня 2023 року, Google підтримує версію 2 специфікації режиму додаткової згоди. Основні зміни наведено нижче.

Оновлено рядок додаткової згоди (AC) для підтримки постачальників, внесених у відповідний список на платформі керування згодою.
Оновлено API платформи керування згодою. Тепер платформи, що підтримують як TCF, так і режим згоди рекламодавця, є сумісними.

Рядки AC, створені на основі специфікації версії 1, підтримуватимуться й надалі.

Компоненти режиму додаткової згоди

У режимі додаткової згоди підтримуються:

рядок Transparency & Consent (рядок TC), як визначено в специфікації TCF версії 2.2 від IAB, що містить дані про прозорість і згоду для постачальників із глобального списку постачальників IAB (GVL);
спрощений рядок addtl_consent (AC), що містить список постачальників рекламних технологій Google, які не зареєстровані в IAB, але були розкриті користувачам і/або отримали від них згоду.

Ця специфікація визначає наведене нижче.

Формат рядка AC.
Розширення для API платформи керування згодою (відповідно до TCF версії 2.2), яке дає цьому API змогу підтримувати рядок AC й відслідковувати, чи використовуються одночасно TCF і режим згоди рекламодавця.
Спосіб зберігання рядка AC.
Спосіб передавання рядка AC в ланцюжку цифрової реклами.

Формат рядка додаткової згоди (AC)

Яка інформація зберігається в рядку AC?

Рядок AC складається з наведених нижче компонентів.

1. Номер версії специфікації (наприклад, "2")
2. Символ розділювача "~"
3. Розділений крапками список ідентифікаторів постачальників рекламних технологій Google, які отримали згоду користувачів (наприклад, "1.35.41.101")
4. Символ розділювача "~"
5. Комбінація символів "dv.", після якої вказано список розкритих ідентифікаторів постачальників рекламних технологій Google (ATP), розділених крапками (наприклад, "dv.9.21.81")

Щоб зменшити довжину рядка, не дублюйте ідентифікатори зі списку 3 у списку 5.

Приклад рядка AC

Рядок AC 2~1.35.41.101~dv.9.21.81 означає, що рядок створено у форматі, який визначено в специфікації версії 2, користувач дав згоду на постачальників з ідентифікаторами 1, 35, 41 і 101, а постачальників з ідентифікаторами 9, 21 і 81 розкрито для користувача.

Хто має створювати рядок AC?

Рядок AC може створюватися лише платформою керування згодою, яка має сертифікацію TCF від IAB Europe, за допомогою призначеного ідентифікатора CMP відповідно до правил IAB. Постачальники послуг, зокрема й сторонні, не повинні створювати рядки AC самостійно.

Де публікуватиметься список постачальників рекламних технологій Google?

Google розмістить список постачальників рекламних технологій, не зареєстрованих в IAB, а також їхні ідентифікатори за цією адресою:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

Коли потрібно створювати рядок AC?

Рядок AC можна створювати, лише якщо видавець відповідає Правилам Google щодо отримання згоди користувачів із ЄС.

Постачальників слід включати в рядки лише за наявності юридично дійсної згоди користувача на таке:

Використання файлів cookie або інших даних у локальному сховищі, якщо це передбачено законодавством.
Збирання, поширення й використання персональних даних для персоналізації оголошень постачальником рекламних технологій, а також дотримання всіх інших положень Правил Google щодо отримання згоди користувачів із ЄС.

Лише за умови надання достатньої інформації можна включати в рядок постачальників, дані про яких розкриваються користувачам, але які не отримали згоди на таке:

Використання файлів cookie або інших даних у локальному сховищі, якщо це передбачено законодавством.
Збирання, поширення й використання персональних даних для персоналізації реклами. Користувачам має надаватися повна інформація щодо того, з якими саме постачальниками рекламних технологій вони взаємодіють, що також має включати посилання на сторінки політики конфіденційності кожного постачальника, зазначеного у відповідному списку.

Рядок AC має створюватися лише як додаток до рядка TC, а не замість нього. Google не оброблятиме запити, де є рядок AC, але немає рядка TC, і відхилятиме такі рядки AC.

Платформи керування згодою, які відповідають цій специфікації, мають створювати рядки AC, у яких міститимуться лише ідентифікатори постачальників рекламних технологій з опублікованого файлу Google, а не постачальників із GVL. Коли система Google отримує рядок TC, вона перевіряє версію GVL, яка в ньому вказана. Якщо постачальник зареєстрований у цій версії GVL, пріоритет матиме рядок TC, а записи для цього постачальника в рядку AC ігноруватимуться. У такому разі Google залишає за собою право вилучати з рядка AC такі повторювані записи й передавати його в зміненому вигляді разом із рядком TC. Жодні інші постачальники, крім Google, не можуть змінювати рядок AC.

Статті за темою

Розширення для API платформи керування згодою

Радимо розширити наявний інтерфейс API JavaScript платформи керування згодою, яка відповідає TCF версії 2.2, щоб додати дозвіл повертати рядок AC. Для цього ми пропонуємо використовувати, зокрема, об’єкти JSON TCData й InAppTCData.

TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

Як має зберігатися рядок AC?

Вебсайти

Механізм зберігання визначається платформою керування згодою.

Додатки

Пакет SDK платформи керування згодою має зберігати рядок AC в сховищах NSUserDefaults (для iOS) або SharedPreferences (для Android). Це дає такі переваги:

постачальники легко отримують доступ до рядка AC;
рядок AC зберігається у всіх сеансах додатка;
можливість переносити рядок AC між платформами керування згодою дає видавцю змогу замінювати пакет SDK, переходячи з однієї платформи на іншу.

Якщо видавець вилучає пакет SDK платформи керування згодою зі свого додатка, він має видалити значення AddtlConsent для користувачів, щоб постачальники більше не застосовували включений рядок AC.

Ключ сховища й пошуку в NSUserDefaults і SharedPreferences	Значення
`IABTCF_AddtlConsent`	Рядок: рядок AC з версією специфікації і ідентифікаторами постачальників рекламних технологій, які отримали згоду користувачів.

Як передавати рядок AC в ланцюжку цифрової реклами

Запит ставки

Ми використовуватимемо ConsentedProvidersSettings повторно, щоб застосовувати список постачальників, які не входять до GVL, у подальшому процесі:

у розширеннях протоколу OpenRTB;
у застарілій версії буфера протоколу.

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

Сервіси на основі URL-адрес

Коли креатив відображається на екрані, він може містити кілька пікселів у тегах <img>. Наприклад, тег <img src="http://vendor-a.com/key1=val1&key2=val2"> надсилає з вебпереглядача в домен постачальника запит HTTP GET.

Оскільки піксель розміщено в тегу <img> і JavaScript не виконується, рядок TC не можна отримати за допомогою інтерфейсу API платформи керування згодою. Щоб вставити рядок AC, можна використати стандартний параметр URL-адреси й макрос у URL-адресах пікселів, як і для підтримки рядка TC.

Параметр URL-адреси	Відповідний макрос	Представлення в URL-адресі
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Приклад 1

Щоб постачальник А отримував рядок AC, до URL-адреси зображення необхідно додати пару "ключ – значення" з параметром URL-адреси й макросом &addtl_consent=${ADDTL_CONSENT}. Кінцева URL-адреса:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

Приклад 2

Запит містить такий рядок AC: 1~1.35.41.101.

Функція, що викликає креатив, або засіб його відображення замінює макрос у URL-адресі на фактичний рядок AC, щоб вихідний піксель, який містить цей макрос, під час виклику вказаного сервера змінювався в такий спосіб:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Чи корисна ця інформація?

Як можна її покращити?