Consentimento Adicional do Google: especificação técnica

Neste artigo

 
Os publishers que quiserem trabalhar com provedores de tecnologia de publicidade (ATPs) que não fazem parte da TCF devem trabalhar diretamente com as CMPs deles.

Este documento define uma especificação técnica (Consentimento Adicional) para uso exclusivo com a Estrutura de Transparência e Consentimento (TCF) v2 do IAB Europa 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 Europa. Essa especificação permite que os publishers, plataformas de gestão de consentimento (CMPs) e parceiros coletem e ampliem o Consentimento Adicional, assim como a implementação da TCF, para empresas que ainda não estão registradas na lista de fornecedores globais do IAB Europa, mas que estão na lista de provedores de adtech (ATPs) do Google.

Componentes do Consentimento Adicional

Esse consentimento está de acordo com:

  • A string de transparência e consentimento (string de TC) definida pela especificação da 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) do IAB.
  • Uma string addtl_consent (string de Consentimento Adicional), que contém uma lista dos provedores de tecnologia de publicidade do Google autorizados e/ou divulgados que não estão registrados no IAB.

Essa especificação define o seguinte:

  1. O formato da string de Consentimento Adicional.

  2. A extensão da API CMP da TCF v2.2 para compatibilidade com os controles e a string de Consentimento Adicional quando a TCF e o modo de consentimento do anunciante estiverem presentes.

  3. Como essa string deve ser armazenada.

  4. 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 tem 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 de IDs, separados por pontos, de provedores de tecnologia de anúncio (ATP) do Google que tenham recebido consentimento dos usuários. Exemplo: 1.35.41.101

  • Parte 4: um símbolo separador ~

  • Parte 5: "dv." seguida de uma lista com IDs, separados por pontos, de provedores de tecnologia de publicidade (ATPs) do Google divulgados. Exemplo: dv.9.21.81

    Os 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 foi criada usando o formato definido na especificação v2.

Quem deve criar uma string de Consentimento Adicional?

Uma string de Consentimento Adicional pode ser criada somente por uma CMP com registro no TCF do IAB Europa, usando seu número de identificação de CMP atribuído e de acordo com as políticas do IAB. Os fornecedores ou qualquer provedor de serviços de terceiros não podem criar strings de Consentimento Adicional.

Onde os provedores de tecnologia do Google serão publicados?

O Google publicará a lista dos provedores de tecnologia de publicidade 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, essa string só pode ser criada quando o publisher obedece à nossa Política de consentimento de usuários da União Europeia.

Os fornecedores consentidos só podem ser incluídos quando o usuário dá permissão legalmente válida para as seguintes opções:

  1. O uso de cookies ou outro armazenamento local, quando exigido por lei.

  2. A coleta, o compartilhamento e o uso de dados pessoais para personalização de anúncios por um ATP, além do cumprimento de todos os outros termos da Política de consentimento de usuários da União Europeia do Google.

Os fornecedores divulgados 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. Os fornecedores incluídos na lista de consentimento não precisam também ser incluídos na lista de fornecedores divulgados.

Uma string de consentimento adicional pode ser criada somente como complemento à string de TC, e não para substituição. O Google não processará a solicitação e 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 provedor de tecnologia de anúncios 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 provedores que não sejam o Google não podem modificar a string de Consentimento Adicional.

Mudanças no Consentimento Adicional v2

Desde dezembro de 2023, o Google aceita a v2 da especificação de Consentimento Adicional. As principais mudanças são:

  • Atualização da string de Consentimento Adicional (AC) para ter compatibilidade com os fornecedores divulgados na CMP.
  • Atualização da API CMP para permitir a interoperabilidade entre CMPs compatíveis com a TCF e com o modo de consentimento do anunciante.
Observação: as strings de Consentimento Adicional geradas com base na v1 da especificação vão continuar sendo compatíveis. No entanto, essas strings não podem indicar se a transparência foi estabelecida para um ATP. Para ser compatíveis com casos de uso que não exigem consentimento, as CMPs precisam migrar para a especificação v2.

CMPs certificadas que oferecem Consentimento Adicional

Esta lista inclui CMPs certificadas que oferecem a especificação técnica Consentimento Adicional do Google. Ela também mostra quais versões cada uma delas aceita.

Se você é responsável por uma CMP que oferece Consentimento Adicional e (1) não está nesta lista ou (2) a versão errada do Consentimento Adicional está listada, acesse o formulário de admissão de CMPs e selecione "I'd like to ask a question or update my status" (Quero fazer uma pergunta ou atualizar meu status). Vamos fazer o possível para atualizar em tempo hábil a ficha de acordo com seu status.

Extensão para a API CMP

Propomos ampliar a API CMP JavaScript da 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’
}

 

InAppTCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

Como armazenar uma string de Consentimento Adicional?

Web

O mecanismo de armazenamento depende da escolha da CMP.

No app

NSUserDefaults (iOS) 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;

  • a string de Consentimento Adicional persista entre uma sessão e outra do app;

  • a string de Consentimento Adicional possa ser passada de uma CMP a outra para dar a um editor a flexibilidade de trocar um SDK da CMP por outro.

Se um publisher 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 provedores 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 publicidade consentidos

Como passar a string de Consentimento Adicional pela cadeia de publicidade digital

Solicitação de lance

Reutilize ConsentedProvidersSettings para propagar o downstream de provedores que não estão presentes na GVL.

message ConsentedProvidersSettings {
 // Conjunto de IDs correspondentes aos provedores que, conforme informado pelo publisher
 // ao Google, receberam consentimento legalmente válido dos usuários do EEE para: 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 de acordo com a Política de consentimento de usuários da União Europeia do Google.
 // Uma correlação entre ID e nome do provedor é publicada em providers.csv.
 repeated int64 consented_providers = 2 [packed = true];
}

 // Detalhes sobre os provedores que, conforme informado pelo publisher ao Google,
 // receberam consentimento dos usuários do EEE para o uso de seus dados pessoais para
 // a personalização de anúncios de acordo com a Política de consentimento de usuários da União Europeia do Google.
 // Este campo somente será preenchido quando regs_gdpr for verdadeiro.
 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 provedor.

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. Similar ao suporte à string de TC, 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 Provedor 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

Considere que, em uma solicitação, 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 real, fazendo com que o pixel que originalmente continha a macro seja modificado da seguinte maneira ao chamar o servidor específico:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Recursos relacionados

Isso foi útil?

Como podemos melhorá-lo?

Precisa de mais ajuda?

Siga as próximas etapas:

Fale conosco Conte mais sobre o problema para podermos ajudar você
true
Guia de preparação para a privacidade em 2024

Prepare-se para um mundo sem cookies de terceiros e aproveite a oportunidade de
usar a IA adotando as soluções de medição e público-alvo duráveis
mais adequadas.
Comece hoje mesmo

Pesquisa
Limpar pesquisa
Fechar pesquisa
Menu principal
2553864630386051746
true
Pesquisar na Central de Ajuda
true
true
true
true
true
69621
false
false
false
false