Secciones de este artículo
- Componentes del Consentimiento Adicional
- El formato de la cadena de Consentimiento Adicional
- CMPs que admiten el Consentimiento Adicional
- Extensión a la API de la CMP
- ¿Cómo se debe almacenar una cadena de Consentimiento Adicional?
- Cómo enviar la cadena de Consentimiento Adicional a través de la cadena de publicidad digital
- Recursos relacionados
En este documento se describe la especificación técnica del Consentimiento Adicional de Google, que solo se puede usar junto con la versión 2 del Marco de Transparencia y Consentimiento (TCF) de IAB Europe para enviar señales de transparencia y/o consentimiento a los proveedores que aún no están registrados en la Lista global de proveedores (GVL) de IAB Europe. Esta especificación permite a editores, plataformas de gestión del consentimiento (CMPs) y partners obtener y propagar el Consentimiento Adicional, junto con su implementación del TCF, cuando las empresas aún no figuran en la GVL de IAB Europe, pero sí en la lista de partners de tecnología publicitaria (ATPs) de Google.
Componentes del Consentimiento Adicional
El Consentimiento Adicional consiste en una cadena ligera addtl_consent (llamada "cadena de Consentimiento Adicional"), que contiene una lista de ATPs de Google que han recibido consentimiento y/o se han declarado y que no están registrados en la GVL de IAB.
Cómo generar una cadena de la versión 2 del Consentimiento Adicional (ACv2)
¿Qué información se almacena en una cadena de Consentimiento Adicional?
Una cadena de Consentimiento Adicional contiene los siguientes componentes:
-
Parte 1: el número de versión de la especificación. La versión actual es "
2". -
Parte 2: el símbolo de separación "
~". -
Parte 3: una lista separada por puntos con los IDs de los ATPs de Google que tienen el consentimiento de los usuarios. Ejemplo: "
1.35.41.101". -
Parte 4: un símbolo de separación "
~". -
Parte 5: "dv." seguido de una lista separada por puntos con los IDs de los ATPs de Google declarados. Ejemplo: "
dv.9.21.81".Los proveedores incluidos en la Parte 3 no deben añadirse en la Parte 5 para reducir la longitud de las cadenas.
Ejemplos de cadenas de Consentimiento Adicional
Si se declaran al usuario los ATPs con los IDs 1, 2, 3, 4 y 10:
- …y el usuario ha visto el mensaje de la CMP que revela estos proveedores, pero aún no ha decidido si quiere dar su consentimiento: la cadena ACv2 correspondiente sería
2~~dv.1.2.3.4.10. -
…y el usuario ha dado su consentimiento a todos los proveedores: la cadena ACv2 correspondiente sería
2~1.2.3.4.10~dv.. Ten en cuenta que el punto (".") después de "dv" es opcional solo en este caso, por lo que2~1.2.3.4.10~dvtambién es una cadena ACv2 válida. - …y el usuario ha rechazado dar el consentimiento a todos los proveedores, la cadena ACv2 correspondiente debe indicar que se ha informado a todos los proveedores, pero que ninguno ha obtenido el consentimiento. La cadena ACv2 correspondiente sería
2~~dv.1.2.3.4.10. - …y el usuario ha dado su consentimiento a los proveedores
1y10, pero no al resto, la cadena de ACv2 correspondiente sería2~1.10~dv.2.3.4.
¿Quién debe crear una cadena de Consentimiento Adicional?
Solo una CMP registrada 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 publican los ATPs de Google?
Google mantiene una lista con los ATPs no registrados en IAB y sus IDs en la siguiente ubicación:
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 la Política de Consentimiento de Usuarios de la Unión Europea de Google.
Los proveedores que han obtenido el consentimiento solo se deben incluir cuando el usuario ha dado un consentimiento legalmente válido para lo siguiente:
-
Usar cookies u otro método de almacenamiento local cuando lo exija la ley.
-
Recoger, compartir y usar datos personales para personalizar anuncios por parte de un ATP, así como cumplir el resto de los términos de la Política de Consentimiento de Usuarios de la Unión Europea de Google.
Cuando se proporcione la transparencia adecuada a los usuarios sobre la identidad de cada ATP, lo que incluye enlazar a la política de privacidad del ATP que aparece en la lista de ATPs de Google, solo deben incluirse los proveedores declarados. Los proveedores incluidos en la lista de proveedores que han obtenido el consentimiento no tienen que estar también en la de proveedores declarados.
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.
Las CMPs que implementen esta especificación deben verificar que la cadena de Consentimiento Adicional que crean contiene solo los IDs del archivo publicado de ATPs 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 de la GVL figura el registro de un 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.
¿Se siguen admitiendo las cadenas de la versión 1 del Consentimiento Adicional?
La versión 2 del Consentimiento Adicional es la versión estándar de Consentimiento Adicional desde diciembre del 2023. Las cadenas de Consentimiento Adicional generadas según la especificación de la versión 1 se seguirán admitiendo. Sin embargo, estas cadenas no pueden indicar si se ha establecido la transparencia para un ATP. Para admitir casos prácticos que no requieran el consentimiento, las CMPs deben migrar a la especificación de la versión 2.
CMPs certificadas que admiten el Modo de Consentimiento Adicional
Esta lista incluye CMPs certificadas que ofrecen compatibilidad con la especificación técnica de Consentimiento Adicional de Google, así como la versión de Consentimiento Adicional que admiten.
Si usted es una CMP que ofrece compatibilidad con el Consentimiento Adicional y (1) no aparece en esta lista o (2) se muestra la versión incorrecta del Consentimiento Adicional, vaya al formulario de admisión de CMPs y seleccione el tipo de solicitud "Quiero hacer una pregunta o actualizar mi estado". Haremos todo lo posible por actualizar la ficha para reflejar su estado de forma oportuna.
Guía sobre la información de esta lista
Esta lista incluye la siguiente información sobre cada CMP certificada:
- CMP certificada: el nombre de la CMP certificada.
- ID de CMP del TCF: el identificador único asignado a la CMP validada por el TCF del IAB.
- Consentimiento Adicional: la versión del Modo de Consentimiento Adicional que admite la CMP.
Lista de CMPs certificadas que admiten el Modo de Consentimiento Adicional
Extensión a la API de la CMP
Las CMPs que admitan el Consentimiento Adicional deben devolver la cadena de Consentimiento Adicional como parte de los objetos JSON de la API de JavaScript de la CMP de la versión 2 del TCF, TCData y 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’
}
¿Cómo se debe almacenar una cadena de Consentimiento Adicional?
Sitios web
El mecanismo de almacenamiento depende de la elección de la CMP.
Aplicaciones
Se utilizará NSUserDefaults (iOS) o SharedPreferences (Android) para almacenar la cadena de Consentimiento Adicional generada por un SDK de la CMP, de forma similar a la API de la aplicación para la versión 2 del TCF. Este mecanismo permite 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
-
Para la portabilidad de la cadena de Consentimiento Adicional si un editor cambia su CMP
Nota: Si un editor elige quitar el SDK de la 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 de los partners de tecnología publicitaria que tienen el consentimiento |
Cómo enviar la cadena de Consentimiento Adicional a través de la cadena de publicidad digital
Solicitudes de puja
Las solicitudes de puja usarán 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 {
// 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;
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 de la 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ámetro 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, si la cadena de Consentimiento Adicional es 2~1.35.41.101~dv..
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=2~1.35.41.101~dv.
