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

Este documento define uma especificação técnica (denominada "Modo de Consentimento Adicional") destinada a ser utilizada apenas com a Estrutura de Transparência e Consentimento (TCF) v2.0 do IAB Europe para servir de ponte para os fornecedores que ainda não estão registados na Lista global de fornecedores (GVL) do IAB Europe. Esta especificação permite que os publicadores, os fornecedores de gestão do consentimento (CMPs) e os parceiros reúnam e propaguem um consentimento adicional — em conjunto com a implementação da TCF v2.0 — 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 (ATP) da Google.

Recursos relacionados

Componentes do Modo de Consentimento Adicional

No "Modo de Consentimento Adicional", suportamos:

A string de transparência e consentimento (string de TC), conforme definida pela especificação da TCF v2.0 do IAB, que contém a transparência e o consentimento estabelecidos para os fornecedores na GVL do IAB e
Uma string addtl_consent simples (string de CA), que contém uma lista de fornecedores de tecnologia de anúncios da Google que receberam consentimento 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.0 para suportar a string de CA
Como uma string de CA deve ser armazenada
Como passar 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 três seguintes componentes:

Parte 1: um número da versão da especificação, como "1"
Parte 2: um símbolo separador "~"
Parte 3: uma lista separada por pontos dos IDs de ATP da Google que receberam consentimento dos utilizadores. Exemplo: "1.35.41.101"

Por exemplo, a string de CA 1~1.35.41.101 significa que o utilizador deu o seu consentimento aos ATPs com os IDs 1, 35, 41 e 101 e que a string é criada através do formato definido na especificação v1.0.

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 ATPs 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. Em particular, uma string de CA não deve ser criada antes de o utilizador ter dado o respetivo consentimento legalmente válido para: 1) a utilização de cookies ou outro armazenamento local sempre que seja legalmente exigido; e 2) a recolha, a partilha e a utilização de dados pessoais para a personalização de anúncios por um ATP, de acordo com a Política de Consentimento de Utilizadores da UE 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 ATPs 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 passar 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.

Extensão da API CMP

Propomos a extensão da API JavaScript CMP da TCF v2.0 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?