Especificación técnica del Modo de Consentimiento Adicional de Google

En este documento se define una especificación técnica (denominada "Modo de Consentimiento Adicional") que está destinada únicamente para usarse con la versión 2.0 del Marco de Transparencia y Consentimiento (TCF) de IAB Europe y que servirá como solución provisional para los proveedores que aún no están registrados para aparecer en la Lista global de proveedores (GVL) de IAB Europe. Esta especificación, junto con la versión 2.0 del TCF de IAB, permite a editores, proveedores de soluciones de gestión del consentimiento (CMPs) y partners obtener y propagar el consentimiento adicional cuando las empresas aún no figuran en la GVL de IAB Europe, pero sí en la Lista de Proveedores de Tecnología Publicitaria de Google.

Recursos relacionados

• Cadena de Transparencia y Consentimiento con la versión 2.0 del formato de la GVL
• Versión 2.0 de la API de Plataforma de Gestión del Consentimiento
• Políticas del Marco de Transparencia y Consentimiento de IAB Europe
• Política de Consentimiento de Usuarios de la Unión Europea de Google

Componentes del Modo de Consentimiento Adicional

El "Modo de Consentimiento Adicional" es compatible con:

• La cadena de Transparencia y Consentimiento (cadena de TC) definida por la especificación de la versión 2.0 del TCF de IAB, que contiene información sobre la transparencia y el consentimiento establecida para los proveedores de la GVL de IAB.
• Una cadena ligera de Consentimiento Adicional, addtl_consent, que contiene una lista con Proveedores de Tecnología Publicitaria de Google autorizados que no están registrados en IAB.

Esta especificación define los siguientes elementos:

1. El formato de la cadena de Consentimiento Adicional
2. La extensión de la API del CMP de la versión 2.0 del TCF compatible con la cadena de Consentimiento Adicional
3. Cómo se debe almacenar una cadena de Consentimiento Adicional
4. Cómo enviar la cadena de Consentimiento Adicional a través de la cadena de publicidad digital

El formato de la cadena de Consentimiento Adicional

¿Qué información se almacena en una cadena de Consentimiento Adicional?

Una cadena de Consentimiento Adicional contiene los siguientes tres componentes:

• Parte 1: un número de versión de especificación, como "1".
• Parte 2: un símbolo de separación "~".
• Parte 3: una lista separada por puntos con los IDs de los Proveedores de Tecnología Publicitaria de Google que tienen el consentimiento de los usuarios. Ejemplo: "1.35.41.101".

Por ejemplo, si se incluye la cadena de Consentimiento Adicional 1~1.35.41.101, el usuario ha dado su consentimiento a los proveedores de tecnología publicitaria cuyos IDs son 1, 35, 41 y 101, y la cadena se crea utilizando el formato definido en la especificación de la versión 1.0.

¿Quién debe crear una cadena de Consentimiento Adicional?

Solo un CMP registrado en el TCF de IAB Europe puede crear una cadena de Consentimiento Adicional, para lo que debe usar su número de ID de CMP asignado de acuerdo con las políticas de IAB. Ni los proveedores ni ningún otro proveedor de servicios externo deben crear cadenas de Consentimiento Adicional.

¿Dónde se publicarán los Proveedores de Tecnología Publicitaria de Google?

Google publicará la lista con los proveedores de tecnología publicitaria no registrados en IAB y sus IDs en la siguiente ruta:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

¿Cuándo se debe crear una cadena de Consentimiento Adicional?

Solo se puede crear una cadena de Consentimiento Adicional si el editor cumple con la Política de Consentimiento de Usuarios de la Unión Europea de Google. En concreto, no se debe crear una cadena de Consentimiento Adicional antes de que el usuario haya dado un consentimiento legal válido 1) al uso de cookies o de otro almacenamiento local donde sea requisito legal, y 2) a la recogida, el intercambio y el uso de datos personales para que un Proveedor de Tecnología Publicitaria lo use en la personalización de anuncios de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google.

Las cadenas de Consentimiento Adicional solo se pueden crear como complementos de las cadenas de TC, no para sustituirlas. Si se recibe una solicitud en la que no hay disponible ninguna cadena de TC, Google no la procesará y descartará la cadena de Consentimiento Adicional.

Los CMPs que implementen esta especificación deben verificar que la cadena de Consentimiento Adicional que crean contiene solo los IDs del archivo publicado de Proveedores de Tecnología Publicitaria de Google (es decir, los proveedores que no pertenecen a la GVL). Cuando Google reciba una cadena de TC, comprobará la versión de la GVL que figura en ella. Si en esa versión figura el registro del proveedor, se ignorarán los controles de la cadena de TC y las entradas de la cadena de Consentimiento Adicional relativos a él. En este caso, Google se reserva el derecho de quitar las entradas "duplicadas" de la cadena de Consentimiento Adicional y de transferir la cadena modificada junto con la cadena de TC. Los proveedores externos a Google no pueden modificar la cadena de Consentimiento Adicional.

Extensión a la API de CMP

Proponemos extender la API de JavaScript de la CMP de la versión 2.0 del TCF para permitir que se devuelva la cadena de Consentimiento Adicional. En concreto, proponemos extender los objetos JSON TCData e InAppTCData para devolver estos datos.

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

¿Cómo se debe almacenar una cadena de Consentimiento Adicional?

Sitios web

El mecanismo de almacenamiento depende de la elección del CMP.

Aplicaciones

Se utilizará NSUserDefaults (iOS) o SharedPreferences (Android) para almacenar la cadena de Consentimiento Adicional mediante el SDK de un CMP, lo que permitirá lo siguiente:

• Los proveedores accederán fácilmente a la cadena de Consentimiento Adicional
• La cadena de Consentimiento Adicional se podrá conservar en las sesiones de la aplicación
• La cadena de Consentimiento Adicional será portátil entre los CMPs, de modo que los editores tengan flexibilidad para intercambiar el SDK de un CMP por el de otra

Si un editor elige quitar el SDK de un CMP de su aplicación, es responsable de borrar los valores AddtlConsent de los usuarios para que los proveedores no sigan utilizando la cadena de Consentimiento Adicional incluida.

Clave de almacenamiento y búsqueda en NSUserDefaults y SharedPreferences	Valor
IABTCF_AddtlConsent	Cadena: cadena de Consentimiento Adicional que incluye la versión de la especificación y el ID del Proveedor de Tecnología Publicitaria que tiene el consentimiento

Cómo enviar la cadena de Consentimiento Adicional a través de la cadena de publicidad digital

Solicitud de puja

Reutilizaremos ConsentedProvidersSettings para propagar los proveedores que no pertenecen a la GVL más adelante en el proceso.

• Protocolo de extensiones de OpenRTB
• Versión antigua de Protobuf

message ConsentedProvidersSettings {
 // Conjunto de IDs correspondientes a los proveedores que, según el editor ha informado a
 // Google, han obtenido el consentimiento legal válido de sus usuarios del EEE para 1) el uso de cookies o de otro  
 // almacenamiento local donde sea requisito legal, y 2) la recogida, el intercambio y el uso de datos personales para 
 // que un Proveedor de Tecnología Publicitaria lo use en la personalización de anuncios de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google.
 // Se publica una asignación del ID y el nombre del proveedor en providers.csv.
 repeated int64 consented_providers = 2 [packed = true];
}

 // Información sobre los proveedores que, según el editor ha informado a Google,
 // han obtenido el consentimiento de sus usuarios del EEE para usar sus datos personales
 // en la personalización de anuncios de acuerdo con la Política de Consentimiento de Usuarios de la Unión Europea de Google.
 // Este campo solo se rellenará cuando el valor de regs_gdpr sea true.
 optional ConsentedProvidersSettings consented_providers_settings = 42;

Servicios basados en URLs

Cuando se renderiza una creatividad, puede contener varios píxeles en etiquetas <img>. Por ejemplo, <img src="http://vendor-a.com/key1=val1&key2=val2">, que envía una solicitud HTTP GET desde el navegador al dominio del proveedor.

Dado que el píxel está en una etiqueta <img> sin capacidad de ejecutar JavaScript, no se puede utilizar la API del CMP para obtener la cadena de TC. De manera similar a la compatibilidad con la cadena de TC, proporcionamos un parámetro de URL estándar y una macro en las URLs de píxel en las que se debe insertar la cadena de Consentimiento Adicional.

Parámetros de URL	Macro correspondiente	Representación en URL
addtl_consent	ADDTL_CONSENT	&addtl_consent=${ADDTL_CONSENT}

Ejemplo 1

Para que el proveedor A reciba una cadena de Consentimiento Adicional, la URL de una imagen debe incluir un par clave-valor con el parámetro de URL y la macro &addtl_consent=${ADDTL_CONSENT}. La URL resultante es:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

Ejemplo 2

En una solicitud dada, supongamos que la cadena de Consentimiento Adicional es 1~1.35.41.101.

El objeto que llama o renderiza la creatividad reemplaza la macro incluida en la URL con la cadena de Consentimiento Adicional real para que el píxel original que contiene la macro se modifique de la siguiente manera al hacer la llamada al servidor especificado:

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