Neste artigo
- Componentes do Consentimento Adicional
- O formato da string de "Consentimento Adicional" (CA)
- CMPs compatíveis com o Consentimento Adicional
- Extensão da API CMP
- Como deve ser armazenada uma string de CA?
- Como transmitir a string de CA através da cadeia de publicidade digital
- Recursos relacionados
Este documento descreve a especificação técnica do Consentimento Adicional da Google, que se destina a ser usado apenas em conjunto com a Estrutura de Transparência e Consentimento (TCF) v2 do IAB Europe para enviar sinais de transparência e/ou consentimento a fornecedores que ainda não estão registados na Lista global de fornecedores (GVL) do IAB Europe. Esta especificação permite que os publicadores, as Plataformas de gestão de consentimento (CMPs) e os parceiros reúnam e propaguem o Consentimento Adicional (em conjunto com a respetiva implementação da TCF) para empresas que ainda não estão registadas na Lista global de fornecedores do IAB Europe, mas estão na lista de prestadores tecnológicos para anúncios (PTAs) da Google.
Componentes do Consentimento Adicional
O Consentimento Adicional consiste numa string addtl_consent (string de CA) simples que contém uma lista de prestadores tecnológicos para anúncios (PTAs) da Google que receberam consentimento e/ou são divulgados e que não estão registados na Lista global de fornecedores (GVL) do IAB.
Como gerar uma string de "Consentimento Adicional" versão 2 (CAv2)
Que informações são armazenadas numa string de CA?
Uma string de CA contém os seguintes componentes:
-
Parte 1: o número da versão da especificação. A versão atual é "
2" -
Parte 2: o símbolo separador "
~" -
Parte 3: uma lista separada por pontos dos IDs de prestadores tecnológicos para anúncios (PTAs) da Google que receberam consentimento dos utilizadores. Exemplo: "
1.35.41.101" -
Parte 4: um símbolo separador "
~" -
Parte 5: "dv." seguido de uma lista separada por pontos dos IDs de prestadores tecnológicos para anúncios (PTAs) da Google divulgados. Exemplo: "
dv.9.21.81"Os fornecedores incluídos na Parte 3 não devem ser incluídos na Parte 5 a fim de reduzir o comprimento da string.
Exemplos de strings de CA
Se os fornecedores PTA com os IDs 1, 2, 3, 4 e 10 forem divulgados ao utilizador:
- …e o utilizador tiver visto a mensagem da CMP a divulgar estes fornecedores, mas ainda não tiver decidido se quer consentir: a string ACv2 correspondente seria
2~~dv.1.2.3.4.10. -
…e o utilizador tiver dado consentimento para todos os fornecedores: a string de ACv2 correspondente seria
2~1.2.3.4.10~dv.. Tenha em atenção que o "." após dv é opcional apenas neste caso, pelo que2~1.2.3.4.10~dvtambém é uma string ACv2 aceite. - …e o utilizador tiver rejeitado o consentimento para todos os fornecedores, a string de ACv2 correspondente deve indicar que todos os fornecedores foram divulgados, mas nenhum tem consentimento. A string de ACv2 correspondente seria
2~~dv.1.2.3.4.10. - …e o utilizador tiver dado consentimento para os fornecedores
1e10, mas tiver rejeitado o consentimento para todos os outros fornecedores, a string de ACv2 correspondente seria2~1.10~dv.2.3.4.
Quem deve criar uma string de CA?
Uma string de CA só pode ser criada por uma CMP registada na TCF do IAB Europe com o respetivo número de ID de CMP atribuído, de acordo com as Políticas do IAB. Os fornecedores ou quaisquer outros fornecedores de serviços terceiros não devem criar strings de CA.
Onde são publicados os PTAs da Google?
A Google mantém uma lista de prestadores tecnológicos para anúncios não registados no IAB e os respetivos IDs na seguinte localização:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Quando deve ser criada uma string de CA?
Em todos os casos, uma string de CA só pode ser criada quando o publicador estiver em conformidade com a Política de Consentimento de Utilizadores da UE da Google.
Os fornecedores que receberam consentimento apenas devem ser incluídos quando o utilizador tiver dado um consentimento legalmente válido para:
-
A utilização de cookies ou outro armazenamento local, sempre que seja legalmente exigido; e
-
A recolha, a partilha e a utilização de dados pessoais para personalização de anúncios por um PTA, bem como a conformidade com todos os outros termos da Política de Consentimento de Utilizadores da UE da Google.
Os fornecedores divulgados apenas devem ser incluídos quando for fornecida aos utilizadores a transparência adequada sobre a identidade de cada PTA, incluindo um link para a Política de Privacidade do PTA, conforme indicado na lista de PTAs da Google. Os fornecedores incluídos na lista de fornecedores com consentimento não têm de ser incluídos também na lista de fornecedores divulgados.
Uma string de CA só deve ser criada como uma string suplementar à string de TC e não no lugar da string de TC. A Google não processará o pedido e rejeitará a string de CA de um pedido recebido pela Google se não estiver disponível uma string de TC para o mesmo pedido.
As CMPs que implementam esta especificação têm de se certificar de que a string de CA que criam contém apenas os IDs do ficheiro de PTAs da Google publicado (ou seja, fornecedores não incluídos na GVL). Quando a Google recebe uma string de TC, verifica a versão da GVL que está indicada nessa string de TC. Se essa versão da GVL tiver um registo para um fornecedor, os controlos da string de TC para esse fornecedor e eventuais entradas da string de CA para o mesmo são ignorados. Nestas circunstâncias, a Google reserva-se o direito de remover essas entradas "duplicadas" da string de CA e de transmitir essa string de CA modificada juntamente com a string de TC. Com exceção da Google, os fornecedores não podem modificar a string de CA.
As strings de Consentimento Adicional v1 ainda são compatíveis?
O Consentimento Adicional v2 é a versão padrão do Consentimento Adicional desde dezembro de 2023. As strings de Consentimento Adicional geradas com base na especificação v1 continuam a ser compatíveis. No entanto, essas strings não podem indicar se a transparência está estabelecida para um PTA. Para serem compatíveis com exemplos de utilização que não requerem consentimento, as CMPs devem migrar para a especificação v2.
CMPs certificadas compatíveis com o Consentimento Adicional
Esta lista inclui CMPs certificadas que oferecem apoio técnico para a especificação técnica do Consentimento Adicional da Google, bem como a versão do Consentimento Adicional que é compatível.
Se for uma CMP que oferece apoio técnico para o Consentimento Adicional e (1) não estiver incluída nesta lista ou (2) estiver indicada a versão errada do Consentimento Adicional, aceda ao formulário de admissão da CMP e selecione o tipo de pedido "Gostaria de fazer uma pergunta ou atualizar o meu estado". Faremos o nosso melhor para atualizar a lista de modo a refletir o seu estado de forma atempada.
Guia das informações nesta lista
Esta lista inclui as seguintes informações sobre cada CMP certificada:
- CMP certificada: o nome da CMP certificada.
- ID da CMP da TCF: o identificador único atribuído a uma CMP validada pela TCF pelo IAB.
- Consentimento Adicional: a versão do Consentimento Adicional compatível com a CMP.
Lista de CMPs certificadas compatíveis com o Consentimento Adicional
Extensão da API CMP
As CMPs compatíveis com o Consentimento Adicional devem devolver a string de Consentimento Adicional como parte dos objetos JSON da API JavaScript, da TCData e da InAppTCData existentes da CMP da TCF v2.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
Como deve ser armazenada uma string de CA?
Web
O mecanismo de armazenamento fica ao critério da CMP.
Na app
Um SDK da CMP usa NSUserDefaults (iOS) ou SharedPreferences (Android) para armazenar a string de CA, da mesma forma que a API in-app para a TCFv2. Este mecanismo permite:
-
Que os fornecedores acedam facilmente à string de CA
-
Que a string de CA persista entre as sessões da app
-
A portabilidade da string de CA se um publicador mudar de CMP
Nota: se um publicador optar por remover o SDK de uma CMP da respetiva app, é responsável por limpar os valores AddtlConsent dos utilizadores para que os fornecedores não continuem a usar a string de CA incluída.
| Chave de pesquisa e armazenamento em NSUserDefaults e SharedPreferences | Valor |
IABTCF_AddtlConsent |
String: string de CA com a versão da especificação e os IDs dos prestadores tecnológicos para anúncios com consentimento |
Como transmitir a string de CA através da cadeia de publicidade digital
Pedidos de lances
Os pedidos de lances vão usar as ConsentedProvidersSettings para propagar os fornecedores não incluídos na GVL a jusante.
- No protocolo das extensões de OpenRTB
- Versão antiga 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 no URL
Quando um criativo é renderizado, pode conter um número de píxeis nas etiquetas <img>. Por exemplo, <img src="http://vendor-a.com/key1=val1&key2=val2">, que envia um pedido HTTP GET do navegador para o domínio do fornecedor.
Uma vez que o píxel está numa etiqueta <img> sem a capacidade de executar JavaScript, a API CMP não pode ser usada para obter a string de TC. À semelhança do suporte para a string de TC, fornecemos um parâmetro de URL padrão e uma macro nos URLs de píxeis onde a string de CA deve ser inserida.
| Parâmetro de URL | Macro correspondente | Representação no URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Exemplo 1
Para que o Fornecedor A receba uma string de CA, um URL da imagem tem de 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
Num determinado pedido, se a string de CA for: 2~1.35.41.101~dv.
O caller ou o renderizador do criativo substitui a macro no URL pela string de CA real para que o píxel originalmente colocado que contém a macro seja modificado como se segue ao fazer a chamada para o servidor especificado:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.