Visão geral e orientação do GDPR

Especificação técnica do Consentimento Adicional da Google

Os publicadores que pretendam trabalhar com fornecedores de tecnologia de anúncios (FTAs) que não sejam da TCF devem trabalhar diretamente com os respetivos CMPs.

Este documento define uma especificação técnica (denominada "Consentimento Adicional") destinada a ser utilizada apenas 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 fornecedores de tecnologia de anúncios (FTA) da Google.

Alterações à especificação do Consentimento Adicional v2

Desde dezembro de 2023 que a Google suporta a v2 da especificação do Consentimento Adicional. As principais alterações são:

Atualização da string de Consentimento Adicional (CA) para suportar os fornecedores divulgados nas Plataformas de gestão de consentimento (CMP).
Atualize para a API CMP para permitir a interoperabilidade das CMPs que suportam a TCF e o modo de consentimento de anunciantes.

As strings de CA geradas com base na especificação v1 continuam a ser suportadas.

Componentes do Consentimento Adicional

No "Consentimento Adicional", suportamos:

A string de transparência e consentimento (string de TC), conforme definida pela especificação da TCF v2.2 do IAB, que contém a transparência e o consentimento estabelecidos para os fornecedores na Lista global de fornecedores (GVL) do IAB. E
Uma string addtl_consent simples (string de CA), que contém uma lista de fornecedores de tecnologia de anúncios (FTA) da Google que receberam consentimento e/ou são divulgados e que não estão registados no IAB.

Esta especificação define o seguinte:

O formato da string de CA.
A extensão para a API CMP da TCF v2.2 para suportar a string de CA e os controlos para quando a TCF e o modo de consentimento de anunciantes estão presentes.
Como uma string de CA deve ser armazenada.
Como transmitir a string de CA através da cadeia de publicidade digital.

O formato da string de "Consentimento Adicional" (CA)

Que informações são armazenadas numa string de CA?

Uma string de CA contém os seguintes componentes:

Parte 1: um número da versão da especificação, como "2"
Parte 2: um símbolo separador "~"
Parte 3: uma lista separada por pontos dos IDs de fornecedores de tecnologia de anúncios (FTA) 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 fornecedores de tecnologia de anúncios (FTA) 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.

Exemplo de string de CA

A string de CA 2~1.35.41.101~dv.9.21.81 significa que o utilizador deu o seu consentimento aos FTAs com os IDs 1, 35, 41 e 101, que os FTAs com os IDs 9, 21 e 81 foram divulgados ao utilizador e que a string é criada com o formato definido na especificação v2.

Quem deve criar uma string de CA?

Uma string de CA só pode ser criada por uma CMP registada na TCF do IAB Europe através do respetivo número de ID da 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 FTAs da Google?

A Google publica a lista de fornecedores de tecnologia de 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 FTA, bem como a conformidade com todos os outros termos da Política de Consentimento de Utilizadores da UE da Google.

O fornecedores divulgados que não tenham recebido consentimento 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 só devem ser incluídas quando for fornecida transparência adequada aos utilizadores sobre a identidade de cada FTA, incluindo links para a política de privacidade de cada FTA, conforme indicado na lista de FTA da Google.

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 num pedido recebido pela Google se uma string de TC não estiver disponível 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 FTAs 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 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.

Recursos relacionados

Extensão da API CMP

Propomos a extensão da API JavaScript CMP da TCF v2.2 existente para permitir a devolução da string de CA. Mais especificamente, propomos a extensão dos objetos JSON TCData e InAppTCData para devolver estes dados.

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’
}

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 utiliza as NSUserDefaults (iOS) ou as SharedPreferences (Android) para armazenar a string de CA. Permite:

Que os fornecedores acedam facilmente à string de CA
Que a string de CA persista entre as sessões da app
Que a string de CA seja portátil entre as CMPs para proporcionar flexibilidade aos publicadores para trocarem um SDK da CMP por outro

Se um publicador optar por remover um SDK da CMP da respetiva app, ele é responsável por limpar os valores AddtlConsent dos utilizadores para que os fornecedores não continuem a utilizar 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 fornecedores de tecnologia de anúncios com consentimento

Como passar a string de CA através da cadeia de publicidade digital

Pedido de lance

Vamos reutilizar 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 utilizada 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: 1~1.35.41.101

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=1~1.35.41.101

A informação foi útil?

Como podemos melhorá-la?