Обзор GDPR и рекомендации по его соблюдению

Разработанная Google техническая спецификация "Дополнительное согласие"

Далее: Как устранять неполадки с реализацией спецификации IAB EU TCF v2.2

Издателям, которые хотят работать с поставщиками рекламных технологий (ATP), не внедрившими спецификацию TCF, следует работать напрямую с поставщиками CMP.

Эта техническая спецификация под названием "Дополнительное согласие" может быть использована только со спецификацией Transparency & Consent Framework (TCF) версии 2, разработанной IAB Europe, для отправки данных о прозрачности рекламы и/или согласии. Она предназначена для компаний, которые ещё не зарегистрировались в глобальном списке поставщиков рекламных технологий (GVL) IAB Europe. Эта спецификация позволяет издателям, партнерам и платформам CMP запрашивать и получать дополнительное согласие – в рамках реализации TCF – для организаций, не зарегистрированных в GVL, но включенных в список поставщиков рекламных технологий (ATP) Google.

Изменения в версии 2 спецификации "Дополнительное согласие"

С декабря 2023 г. Google поддерживает версию 2 спецификации "Дополнительное согласие". Самые важные изменения:

Обновлена строка дополнительного согласия (AC), чтобы обеспечить поддержку поставщиков, указанных на платформе предоставления согласия (CMP).
В CMP API добавлена совместимость с CMP, которые поддерживают и TCF, и режим согласия рекламодателя.

Строки дополнительного согласия, основанные на версии 1 спецификации, по-прежнему будут поддерживаться.

Компоненты дополнительного согласия

В спецификации "Дополнительное согласие" поддерживаются:

строка TC (в том виде, как она определена в спецификации TCF версии 2.2 от IAB), которая содержит информацию о прозрачности и согласии для компаний из списка GVL;
упрощенная строка addtl_consent (строка дополнительного согласия), которая содержит список разрешенных и/или раскрытых поставщиков рекламных технологий Google (ATP), не зарегистрированных в IAB.

Эта спецификация определяет:

Формат строки дополнительного согласия.
Расширение спецификации CMP API с TCF версии 2.2, поддерживающее строку дополнительного согласия, и параметры для случаев, когда используется и TCF, и режим согласия рекламодателя.
Как должна храниться строка дополнительного согласия.
Как передавать строку дополнительного согласия по цепочке цифровой рекламы.

Формат строки дополнительного согласия

Какая информация хранится в строке дополнительного согласия?

Строка дополнительного согласия состоит из следующих частей:

1. Версия спецификации (например, 2).
2. Разделитель (~).
3. Разделенный точками список идентификаторов поставщиков рекламных технологий Google, одобренных пользователем (например, 1.35.41.101).
4. Разделитель (~).
5. "dv." и разделенный точками список идентификаторов поставщиков рекламных технологий (ATP) Google. Пример: dv.9.21.81

Поставщиков, указанных в части 3, не следует включать в часть 5, чтобы уменьшить длину строки.

Пример строки дополнительного согласия

Строка дополнительного согласия 2~1.35.41.101~dv.9.21.81 означает, что пользователь дал согласие для поставщиков с идентификаторами 1, 35, 41 и 101, поставщики с идентификаторами 9, 21, и 81 были раскрыты пользователю, а строка была создана на основе формата, определенного в спецификации версии 2.

Кто должен создавать строку дополнительного согласия?

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

Где можно найти список поставщиков рекламных технологий Google?

Список поставщиков рекламных технологий Google, которые ещё не зарегистрировались в организации IAB, а также их идентификаторы доступны здесь:

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

Когда нужно создавать строку дополнительного согласия?

Строку AC можно создавать только в том случае, если издатель соответствует правилам в отношении согласия пользователей из ЕС.

Разрешенных поставщиков следует включать только в том случае, если пользователь дал юридически действительное согласие на:

использование файлов cookie или других локальных хранилищ в случаях, предусмотренных законом;
сбор, распространение и использование ATP персональных данных с целью персонализации объявлений, а также соблюдение всех прочих правил Google в отношении согласия пользователей из ЕС.

Раскрытых поставщиков, у которых нет согласия на:

использование файлов cookie или других локальных хранилищ в случаях, предусмотренных законом;
сбор, распространение и использование персональных данных с целью персонализации рекламы, следует включать только в том случае, если пользователям предоставляется соответствующая прозрачность в отношении личности каждого ATP, включая ссылку на его Политику конфиденциальности согласно списку ATP от Google.

Строка дополнительного согласия должна создаваться только как дополнение к строке TC и не может заменять ее. Google не будет обрабатывать запросы, в которых есть строка AC, но нет строки TC.

CMP, соответствующие этой спецификации, должны создавать строки AC, в которых указаны только идентификаторы поставщиков из опубликованного файла Google (см. выше), а не поставщики из списка GVL. Когда Google получает строку TC, он проверяет, какая версия списка GVL в ней указана. Если тот или иной поставщик зарегистрирован в этой версии, то элементы строки TC и любые поля строки АС, содержащие данные об этом поставщике, будут игнорироваться. В этом случае Google оставляет за собой право удалять такие повторяющиеся поля из строки дополнительного согласия, прежде чем передать ее дальше вместе со строкой TC. Ни один поставщик, кроме Google, не может изменять строку дополнительного согласия.

Информация по теме

Расширение для CMP API

Мы предлагаем расширить существующий CMP JavaScript API для спецификации TCF версии 2.2, добавив в него возможность возвращать строку дополнительного согласия. Для этого будут использоваться объекты JSON TCData и InAppTCData.

TCData = {
tcString: 'закодированная в Base64URL строка TC с сегментами',
...
addtlConsent: 'строка AC с указанием версии спецификации и идентификаторами поставщиков рекламных технологий, одобренных пользователем',
}

InAppTCData = {
tcString: 'закодированная в Base64URL строка TC с сегментами',
...
addtlConsent: 'строка AC с указанием версии спецификации и идентификаторами поставщиков рекламных технологий, одобренных пользователем',
}

Как должна храниться строка дополнительного согласия?

Сайты

Механизм хранения определяется CMP.

Приложения

CMP SDK сохраняет строку AC в локальном хранилище устройства (NSUserDefaults для iOS и SharedPreferences для Android). Это дает следующие преимущества:

Поставщики могут быстро получить доступ к строке AC.
Строка AC остается доступной для любых сеансов приложений.
Переносимость строки AC между платформами для запросов согласия позволяет издателю заменять один CMP SDK другим.

Если издатель удаляет CMP SDK из своего приложения, он должен удалить значения AddtlConsent, чтобы поставщики не пользовались включенной строкой AC.

Ключ запроса в хранилищах NSUserDefaults и SharedPreferences	Значение
`IABTCF_AddtlConsent`	Строка: строка AC с версией спецификации и идентификаторами поставщиков рекламных технологий, одобренных пользователем.

Как передавать строку AC по цепочке цифровой рекламы?

Запрос ставки

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

в расширениях протокола OpenRTB;
в устаревшей версии Protocol Buffers.

message ConsentedProvidersSettings { // Множество идентификаторов поставщиков, для которых, как издатель сообщил Google, // пользователи из ЕЭЗ дали юридически действительное согласие на: 1) использование файлов cookie или других локальных хранилищ // в случаях, предусмотренных законом; 2) сбор, использование и передачу личных данных // для персонализации объявлений поставщиком рекламных технологий в соответствии с Правилами Google в отношении согласия пользователей из ЕС. // Словарь, сопоставляющий идентификаторы поставщиков и их названия, отправляется в файле providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Информация о поставщиках, для которых, как издатель сообщил Google, пользователи // из ЕЭЗ дали согласие на использование их личных данных с целью // персонализации рекламы согласно Правилам в отношении согласия пользователей из ЕС. // Это поле заполняется, только если параметр regs_gdpr имеет значение True. optional ConsentedProvidersSettings consented_providers_settings = 42;

Сервисы на основе URL

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

Поскольку пиксель находится в теге <img> и код JavaScript не может быть выполнен, получить строку TC с помощью CMP API нельзя. Если вам нужно вставить строку AC, можно использовать стандартный параметр и макрос в URL пикселя, как и в случае со строкой TC.

Параметр URL	Соответствующий макрос	Представление в URL
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Пример 1

Чтобы Поставщик А получил строку AC, в URL изображения необходимо добавить пару "ключ-значение" с параметром и макросом &addtl_consent=${ADDTL_CONSENT}:

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

Эта информация оказалась полезной?

Как можно улучшить эту статью?