Este documento define uma especificação técnica (chamada "consentimento adicional") destinada somente para uso com o Transparency & Consent Framework (TCF) v2 do IAB Europe para enviar indicadores de transparência e/ou consentimento aos fornecedores que ainda não estão registrados na lista de fornecedores globais (GVL) do IAB Europe. Essa especificação permite que os editores, plataformas de gestão de consentimento (CMPs) e parceiros coletem e ampliem o consentimento adicional, assim como a implementação do TCF, em empresas que ainda não estão registradas na lista de fornecedores globais do IAB Europe, mas que estão na lista de provedores de adtech (ATPs) do Google.
Mudanças no consentimento adicional v2
A partir de 6 de dezembro de 2023, o Google vai oferecer suporte à v2 da especificação de consentimento adicional. As principais mudanças são:
- Atualização da string de consentimento adicional (AC, na sigla em inglês) para oferecer suporte aos fornecedores divulgados na CMP.
- Atualização da API CMP para permitir a interoperabilidade entre CMPs compatíveis com o TCF e o modo de consentimento do anunciante.
Componentes do consentimento adicional
Esse consentimento é compatível com:
- A string de transparência e consentimento (string de TC) definida pela especificação do TCF v2.2 do IAB (em inglês), que contém a transparência e o consentimento estabelecidos para os fornecedores na lista de fornecedores globais (GVL).
- Uma string
addtl_consent(string de consentimento adicional), que contém uma lista dos provedores de tecnologia de anúncio do Google autorizados e/ou divulgados que não estão registrados no IAB.
Essa especificação define o seguinte:
- O formato da string de consentimento adicional.
- A extensão para a API CMP do TCF v2.2 para compatibilidade com a string de consentimento adicional e controles quando o TCF e o modo de consentimento do anunciante estiverem presentes.
- Como essa string deve ser armazenada.
- Como transmitir a string de consentimento adicional pela cadeia de publicidade digital.
Formato da string de consentimento adicional
Quais informações são armazenadas nela?
A string de consentimento adicional contém os seguintes componentes:
- Parte 1: um número de versão da especificação, como
2 - Parte 2: um símbolo separador
~ - Parte 3: uma lista separada por pontos com os IDs de provedores de tecnologia de anúncio (ATPs, na sigla em inglês) do Google que receberam consentimento dos usuários Exemplo:
1.35.41.101 - Parte 4: um símbolo separador
~ - Parte 5: "dv." seguida de uma lista separada por pontos com IDs de provedores de tecnologia de anúncio (ATPs) do Google divulgados. Exemplo:
dv.9.21.81Os fornecedores incluídos na Parte 3 não devem ser incluídos na Parte 5 para reduzir o comprimento da string.
Exemplo de string de consentimento adicional
A string 2~1.35.41.101~dv.9.21.81 significa que o usuário deu seu consentimento para ATPs com IDs 1, 35, 41 e 101. Os ATPs com IDs 9, 21 e 81 foram divulgados ao usuário e a string é criada usando o formato definido da especificação v2.
Quem deve criar uma string de consentimento adicional?
Ela só pode ser criada por uma CMP com registro no TCF do IAB Europe usando o ID do CPM e de acordo com as políticas do IAB (link em inglês). Os fornecedores ou qualquer provedor terceirizado de serviços não podem criar strings de consentimento adicional.
Onde os ATPs do Google serão publicados?
O Google vai publicar a lista dos provedores de tecnologia de anúncio não registrados no IAB e os IDs deles no seguinte local:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Quando uma string de consentimento adicional pode ser criada?
Em todos os casos, uma string de consentimento adicional só pode ser criada quando o editor obedece à nossa Política de consentimento de usuários da União Europeia.
Os fornecedores com consentimento só devem ser incluídos quando o usuário consentir legalmente com: 1) o uso de cookies ou outro armazenamento local, quando exigido por lei; e 2) a coleta, o compartilhamento e o uso de dados pessoais para personalização de anúncios por um ATP, além de obedecer todos os outros termos da Política de consentimento de usuários da União Europeia do Google.
Fornecedores divulgados que não têm consentimento para 1) usar cookies ou outro armazenamento local, quando exigido por lei; e 2) a coleta, o compartilhamento e o uso de dados pessoais para personalização de anúncios só podem ser incluídos quando os usuários têm a transparência adequada sobre a identidade de cada ATP, incluindo o vínculo com a Política de Privacidade do ATP, conforme consta na lista de ATPs do Google.
Uma string de consentimento adicional pode ser criada somente como complemento à string de TC, e não para substituí-la. O Google não vai processar a solicitação e vai descartar a string de consentimento adicional de uma solicitação recebida se não houver uma string de TC disponível para a mesma solicitação.
As CMPs que implementarem essa especificação precisam garantir que a string de consentimento adicional criada por elas contenha somente os IDs do arquivo de ATPs do Google (ou seja, fornecedores que não estejam na GVL). Quando o Google recebe uma string de TC, ele verifica a versão da GVL listada nessa string. Se essa versão da GVL tiver o registro de um fornecedor, os controles da string de TC e quaisquer entradas da string de consentimento adicional desse fornecedor serão ignorados. Nessas circunstâncias, o Google reserva o direito de remover essas entradas "duplicadas" da string de consentimento adicional e transmitir essa string modificada com a string de TC. Outros fornecedores externos ao Google não podem modificar a string de consentimento adicional.
Recursos relacionados
- String de transparência e consentimento com formato da lista de fornecedores globais v2.2 (link em inglês)
- API Consent Management Platform v2.2 (link em inglês)
- Políticas do Transparency & Consent Framework do IAB Europe (link em inglês)
- Política de consentimento de usuários da União Europeia do Google
Extensão para a API CMP
Propomos ampliar a API CMP JavaScript do TCF v2.2 para que seja possível retornar a string de consentimento adicional. Mais especificamente, propomos ampliar os objetos JSON TCData e InAppTCData (links em inglês) para retornar esses dados.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
enableAdvertiserConsentMode: ‘a boolean to indicate whether TCF integration should be enabled when both TCF and Advertiser Consent Mode are present.’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
enableAdvertiserConsentMode: ‘a boolean to indicate whether TCF integration should be enabled when both TCF and Advertiser Consent Mode are present.’
}
Como uma string de consentimento adicional deve ser armazenada?
Web
O mecanismo de armazenamento depende da escolha da CMP.
No app
NSUserDefaults (iOS; link em inglês) e SharedPreferences (Android) serão usados para armazenar a string de consentimento adicional por um SDK da CMP. Isso permite que:
- Os provedores acessem facilmente a string de consentimento adicional
- Essa string persista entre uma sessão e outra do app
- A string possa ser transmitida de uma CMP a outra para dar ao editor a flexibilidade de trocar um SDK da CMP por outro
Se um editor decidir remover um SDK da CMP do app, ele será responsável por limpar os valores de AddtlConsent para os usuários, para que os fornecedores não continuem usando a string de consentimento adicional incluída.
| Armazenamento e chave de busca em NSUserDefaults e SharedPreferences | Valor |
IABTCF_AddtlConsent |
String: string de consentimento adicional com versão das especificações e IDs dos provedores de tecnologia de anúncio consentidos |
Como transmitir a string de consentimento adicional pela cadeia de publicidade digital
Solicitação de lance
Vamos reutilizar ConsentedProvidersSettings para propagar posteriormente os fornecedores que não estão na GVL.
- No protocolo de extensões do OpenRTB
- Versão legada do 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;
Serviços baseados em URL
Quando um criativo é renderizado, ele pode conter uma série de pixels nas tags <img>. Por exemplo, <img src="http://vendor-a.com/key1=val1&key2=val2">, que envia uma solicitação HTTP GET do navegador ao domínio do fornecedor.
Como o pixel está em uma tag <img> que não pode ser executada em JavaScript, a API CMP não pode ser usada para conseguir a string de TC. Semelhante ao suporte à string de TC (link em inglês), oferecemos um parâmetro de URL padrão e uma macro em URLs de pixel em que a string de consentimento adicional deve ser inserida.
| Parâmetro de URL | Macro correspondente | Representação em URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Exemplo 1
Para que o Fornecedor A receba uma string de consentimento adicional, o URL da imagem precisa incluir um par de chave-valor com o parâmetro de URL e a macro &addtl_consent=${ADDTL_CONSENT}. O URL resultante é:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Exemplo 2
Em uma solicitação, se a string de consentimento adicional é: 1~1.35.41.101
O autor da chamada ou renderizador do criativo substitui a macro no URL pela string de consentimento adicional, fazendo com que o pixel que continha a macro fosse modificado da seguinte maneira ao chamar o servidor especificado:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101