Neste artigo
- Componentes do consentimento adicional
- Formato da string de consentimento adicional
- CMPs compatíveis com o consentimento adicional
- Extensão para a API CMP
- Como armazenar uma string de consentimento adicional?
- Como transmitir a string de consentimento adicional pela cadeia de publicidade digital
- Recursos relacionados
Este documento descreve a especificação técnica de consentimento adicional do Google, que se destina somente ao uso com a Estrutura de Transparência e Consentimento (TCF) v2 do IAB Europa para enviar sinais de transparência e/ou consentimento àqueles que ainda não estão registrados na lista de fornecedores globais (GVL, na sigla em inglês) do IAB Europa. Essa especificação permite que os publishers, as plataformas de gestão de consentimento (CMPs) e os 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 parceiros de tecnologia de publicidade (ATPs) do Google.
Componentes do consentimento adicional
O consentimento adicional consiste em uma string addtl_consent (string de consentimento adicional) leve, que contém uma lista dos parceiros de tecnologia de publicidade (ATPs) do Google autorizados e/ou divulgados que não estão registrados na lista de fornecedores globais (GVL) do IAB.
Como gerar uma string de consentimento adicional versão 2 (ACv2)
Quais informações são armazenadas nela?
A string de consentimento adicional tem os seguintes componentes:
-
Parte 1: o número da versão da especificação. A versão atual é
2 -
Parte 2: um símbolo separador
~ -
Parte 3: uma lista separada por pontos com os IDs dos parceiros de tecnologia de publicidade (ATPs) 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 parceiros de tecnologia de publicidade (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.
Exemplos de string de consentimento adicional
Se os fornecedores de ATPs com IDs 1, 2, 3, 4 e 10 forem divulgados ao usuário:
- … E o usuário vir a mensagem da CMP divulgando esses fornecedores, mas ainda não tiver decidido se vai dar consentimento, a string ACv2 correspondente será
2~~dv.1.2.3.4.10. -
… E o usuário der consentimento a todos os fornecedores, a string ACv2 correspondente será
2~1.2.3.4.10~dv.. O.depois de dv é opcional apenas nesse caso. Portanto,2~1.2.3.4.10~dvtambém é uma string ACv2 aceita. - … E o usuário recusar o consentimento para todos os fornecedores, a string ACv2 correspondente deverá indicar que todos os fornecedores foram divulgados, mas nenhum deles recebeu consentimento. A string de consentimento adicional v2 correspondente será
2~~dv.1.2.3.4.10. - … E o usuário der consentimento para os fornecedores
1e10, mas recusar o consentimento para todos os outros fornecedores, a string ACv2 correspondente será2~1.10~dv.2.3.4.
Quem deve criar uma string de consentimento adicional?
Ela só pode ser criada por uma CMP com registro na TCF do IAB Europa usando o ID da CMP 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 são publicados?
O Google mantém uma lista dos parceiros 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:
-
o uso de cookies ou outro armazenamento local, quando exigido por lei; e
-
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 substituí-la. O Google não vai processar a solicitação recebida e vai descartar a string de consentimento adicional relacionada 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 as 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 a string modificada correspondente com a string de TC. Outros provedores que não sejam o Google não podem modificar a string de consentimento adicional.
As strings de consentimento adicional v1 ainda são aceitas?
A v2 do consentimento adicional é a versão padrão desde dezembro de 2023. 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 serem 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.
Guia para as informações desta 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 exclusivo atribuído pelo IAB a uma CMP validada na TCF.
- Consentimento Adicional: a versão do Consentimento Adicional aceita pela CMP.
Lista de CMPs certificadas que oferecem Consentimento Adicional
Extensão para a API CMP
As CMPs que oferecem suporte ao consentimento adicional precisam retornar a string de consentimento adicional como parte dos objetos JSON da API JavaScript da CMP TCF v2, TCData e InAppTCData.
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 armazenar uma string de consentimento adicional?
Web
O mecanismo de armazenamento depende da escolha da CMP.
No app
NSUserDefaults (iOS) ou SharedPreferences (Android) são usados para armazenar a string de consentimento adicional gerada por um SDK da CMP, semelhante à API no app para a TCFv2. Esse mecanismo permite que:
-
Os fornecedores acessem facilmente a string de consentimento adicional
-
Essa string persista entre uma sessão e outra do app
-
A string de consentimento adicional seja portátil caso um publisher mude a CMP
Observação: 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. Assim, os fornecedores não poderão continuar usando a string de consentimento adicional incluída.
| Chave de busca e armazenamento em NSUserDefaults e SharedPreferences | Valor |
IABTCF_AddtlConsent |
String de consentimento adicional com versão da especificação e IDs dos parceiros de tecnologia de publicidade que receberam autorização |
Como transmitir a string de consentimento adicional pela cadeia de publicidade digital
Solicitações de lance
As solicitações de lance vão usar ConsentedProvidersSettings para propagar o downstream de fornecedores que não estão presentes na GVL.
- No protocolo de extensões do OpenRTB
- Legacy Protobuf version
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 executa JavaScript, a API CMP não pode ser usada para buscar a string de TC. Semelhante à compatibilidade com a string de TC (link em inglês), oferecemos um parâmetro de URL padrão e uma macro nos URLs de pixel em que a string de consentimento 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
Considere que, em uma solicitação, a string de consentimento adicional é 2~1.35.41.101~dv.
O autor da chamada ou renderizador do criativo substitui a macro no URL pela string de consentimento real, fazendo com que o pixel que continha a macro seja modificado da seguinte maneira ao chamar o servidor especificado:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.
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 da Estrutura de Transparência e Consentimento do IAB Europa (link em inglês)
-
Política de Consentimento de Usuários da União Europeia do Google