В този документ е определена техническа спецификация (т.нар. „Допълнително съгласие“), предназначена за употреба само заедно с версия 2 на Рамката за прозрачност и съгласие (TCF) на Бюрото за интерактивна реклама (IAB) за Европа, за да се изпращат сигнали за прозрачност и/или съгласие до доставчиците, които все още не са регистрирани в глобалния списък с доставчици (GVL) на IAB за Европа. Тази спецификация дава възможност на издателите, платформите за управление на получаването на съгласие и партньорите да получават и разпространяват допълнително съгласие – заедно с реализацията си на TCF – към компании, които още не са регистрирани в глобалния списък с доставчици (GVL) на IAB за Европа, но са част от списъка на Google с доставчици на рекламни технологии.
Промени във версия 2 на допълнителното съгласие
От декември 2023 г. Google поддържа версия 2 на спецификацията за допълнително съгласие. Основните промени са:
- Актуализиране на низа за допълнително съгласие (AC), така че да се поддържат доставчиците, посочени в CMP.
- Актуализиране на API на CMP, за да се позволи съвместимост със CMP, които поддържат както TCF, така и режима на получаване на съгласие чрез рекламодателите.
Компоненти на допълнителното съгласие
При допълнителното съгласие поддържаме:
- низа за прозрачност и съгласие (низ за ПС), дефиниран във версия 2.2 на спецификацията на TCF на IAB, която съдържа прозрачността и съгласието, установени за доставчиците в глобалния списък с доставчици (GVL) на IAB; и
- Олекотен низ
addtl_consent(низ за допълнително съгласие), който съдържа списък с получили съгласие и/или разкрити доставчици на рекламни технологии за Google, които не са регистрирани в IAB.
Тази спецификация определя следното:
-
Формата на низа за допълнително съгласие.
-
Разширението на API на CMP за версия 2.2 на TCF за поддръжка на низа за допълнително съгласие и контролите за случаите, когато са налице както TCF, така и режимът на получаване на съгласие чрез рекламодателите.
-
Как да се съхранява низът за допълнително съгласие.
-
Как да подадете низа за допълнително съгласие през веригата за дигитално рекламиране.
Форматът на низа за допълнително съгласие
Каква информация се съхранява в един низ за допълнително съгласие?
Низът за допълнително съгласие съдържа следните компоненти:
-
Част 1: номер на версията на спецификацията, като например „
2“. -
Част 2: разделителен символ „
~“. -
Част 3: списък, разделен с точки, на идентификаторите на доставчиците на рекламни технологии на Google, получили съгласие от потребителя. Пример:
1.35.41.101. -
Част 4: разделителен символ „
~“. -
Част 5: „dv.“, последван от разделен с точки списък с идентификаторите на разкритите доставчици на рекламни технологии за Google. Пример:
dv.9.21.81.Доставчиците, включени в част 3, не трябва да бъдат включвани в част 5, за да се намали дължината на низа.
Пример за низ за допълнително съгласие
Низът за допълнително съгласие 2~1.35.41.101~dv.9.21.81 означава, че потребителят е дал съгласието си за доставчици на рекламни технологии с идентификатори 1, 35, 41 и 101, доставчиците на рекламни технологии с идентификатори 9, 21 и 81 са разкрити пред потребителя и низът е създаден във формата на спецификацията за версия 2.
Кой трябва да създаде низ за допълнително съгласие?
Низът за допълнително съгласие може да бъде създаден само от CMP в регистрирана версия на TCF на IAB за Европа, като се използва зададеният идентификационен номер на CMP в съответствие с правилата на IAB. Доставчиците или други доставчици на услуги трети страни не трябва да създават сами низове за допълнително съгласие.
Къде ще бъдат публикувани доставчиците на рекламни технологии на Google?
Google ще публикува списъка с доставчици на рекламни технологии, които не са регистрирани в IAB, и идентификационните им номера на следното местоположение:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Кога трябва да бъде създаден низ за допълнително съгласие?
Във всички случаи низът за допълнително съгласие може да се създаде само когато издателят спазва Правилата на Google за съгласие на потребителите в ЕС.
Доставчиците, предоставили съгласие, трябва да се включват само когато потребителят е дал валидно по закон съгласие за:
-
използването на „бисквитки“ или друго локално хранилище, където това се изисква по закон; и
-
събирането, споделянето и използването на лични данни за персонализиране на реклами от доставчици на рекламни технологии, както и за спазването на всички други условия на Правилата на Google за съгласие на потребителите в ЕС.
Доставчиците, посочени в разкриване на информация, за които няма получено съгласие за
-
използването на „бисквитки“ или друго локално хранилище, където това се изисква по закон; и
-
събирането, споделянето и използването на лични данни за персонализиране на реклами, трябва да се включват само когато на потребителите е предоставена подходяща прозрачност относно самоличността на всеки доставчик на рекламни технологии, включително предоставяне на връзки към декларацията за поверителност на доставчика, както е посочена в списъка на Google с доставчици на рекламни технологии.
Низът за допълнително съгласие трябва да се създава само като допълнителен низ към низа за прозрачност и съгласие, а не вместо него. Google няма да обработи заявката и ще отхвърли низа за допълнително съгласие по получена заявка, ако за същата заявка не е налице низ за прозрачност и съгласие.
Платформите за управление на съгласието (CMP), които внедряват тази спецификация, трябва да се уверяват, че низът за допълнително съгласие, който създават, съдържа само идентификационните номера от публикувания файл с доставчици на рекламни технологии на Google (т.е. доставчици, които не са от глобалния списък с доставчици (GVL). Когато Google получи низ за прозрачност и съгласие, проверява версията на GVL, посочена в този низ. Ако тази версия на глобалния списък с доставчици (GVL) съдържа регистрация за даден доставчик, контролите за низа за прозрачност и съгласие и записите в низа за допълнително съгласие за този доставчик ще бъдат игнорирани. В този случай Google си запазва правото да премахва такива дублирани записи от низа за допълнително съгласие и да предава така променения низ заедно с низа за прозрачност и съгласие. Доставчиците, различни от Google, нямат право да променят низа за допълнително съгласие.
Сродни ресурси
-
Низ за прозрачност и съгласие с версия 2.2 на формата на глобалния списък с доставчици
-
Версия 2.2 на API на платформата за управление на получаването на съгласие
-
Правила за Рамката за прозрачност и съгласие на Бюрото за интерактивна реклама (IAB) за Европа
Сертифицирани CMP, които поддържат допълнително съгласие
Този списък включва сертифицирани CMP, които предлагат поддръжка за техническата спецификация на Google за допълнително съгласие, както и за версията на режима за получаване на допълнително съгласие (AC), която поддържат.
Ако сте платформа за управление на получаването на съгласие, която предлага поддръжка на режима за получаване на допълнително съгласие, и (1) не сте включени в този списък или (2) е посочена грешна версия на допълнителното съгласие, моля, отворете формуляра за приемане на CMP и изберете типа заявка „Искам да задам въпрос или да актуализирам състоянието си“. Ще направим всичко възможно да актуализираме своевременно списъка така, че да отразява състоянието Ви.
Насоки за тълкуване на информацията в този списък
Този списък включва следната информация за всяка сертифицирана CMP:
- Сертифицирана CMP: Името на сертифицираната платформа за управление на съгласието.
- ID на CMP за TCF: Уникалният идентификатор, присвоен от Бюрото за интерактивна реклама (IAB) на платформа за управление на съгласието, потвърдена от Рамката за прозрачност и съгласие (TCF).
- Допълнително съгласие: Версията на режима за получаване на допълнително съгласие, поддържана от CMP.
Списък със сертифицирани CMP, поддържащи допълнително съгласие (AC)
Разширение за API на CMP
Предлагаме разширяване на съществуващия API на JavaScript за CMP за версия 2.2 на TCF, така че да е възможно връщането на низа за допълнително съгласие. По-конкретно, предлагаме разширяване на обектите във формат 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’
}
Как да се съхранява низът за допълнително съгласие?
Мрежата
Механизмът за съхранение зависи от избора на CMP.
В приложението
NSUserDefaults (iOS) или SharedPreferences (Android) трябва да се използват за съхраняване на низа за допълнително съгласие от SDK на CMP. Това позволява:
-
лесен достъп за доставчиците до низа за допълнително съгласие;
-
низът за допълнително съгласие да се запази през сесиите на приложението;
-
низът за допълнително съгласие да може да се пренася между CMP, за да се предостави гъвкавост на издателите с цел замяна на един SDK на CMP с друг.
Ако даден издател реши да премахне комплект за разработване на софтуер (SDK) на CMP от приложението си, той носи отговорност за изчистването на стойностите AddtlConsent за потребителите, така че доставчиците да не продължат да използват включения низ за допълнително съгласие.
| Хранилище и ключ за търсене в NSUserDefaults и SharedPreferences | Стойност |
IABTCF_AddtlConsent |
Низ: низ за допълнително съгласие с версия на спецификацията и идентификатори на доставчици на рекламни технологии, получили съгласие |
Как да подадете низа за допълнително съгласие през веригата за дигитално рекламиране
Заявка за оферта
Ще използваме повторно ConsentedProvidersSettings, за да разпространяваме надолу по веригата доставчиците, които не са включени в глобалния списък с доставчици (GVL):
- в протокол на разширения на OpenRTB;
- наследена версия на Protobuf.
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, API на CMP не може да се използва за получаване на низа за прозрачност и съгласие. Подобно на поддръжката за низа за ПС предоставяме стандартен параметър на URL адреса и макрос в URL адресите на пикселите, където трябва да се вмъкне низът за допълнително съгласие.
| Параметър на URL адреса | Съответстващ макрос | Представяне в URL адреса |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Пример 1
За да може доставчик да получи низ за допълнително съгласие, URL адресът на изображението трябва да съдържа двойка ключ – стойност с параметъра на URL адреса и макрос &addtl_consent=${ADDTL_CONSENT}. Полученият URL адрес е:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Пример 2
При определена заявка, ако низът за допълнително съгласие е: 1~1.35.41.101,
обаждащият се или програмата за визуализация на рекламното послание заменя макроса в URL адреса с действителния низ за допълнително съгласие, така че първоначално поставеният пиксел, който съдържа макроса, се променя по следния начин, когато повикването се извършва към посочения сървър:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101