Temas en este artículo
- Componentes del Consentimiento adicional
- El formato de la cadena de "Consentimiento adicional" (AC)
- CMP que admiten el Consentimiento adicional
- Extensión de la API de la CMP
- ¿Cómo debe almacenarse una cadena de AC?
- Cómo pasar la cadena de AC 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 se destina únicamente a usarse junto con el Marco de trabajo de transparencia y consentimiento (TCF) v2 de IAB Europe para enviar indicadores de transparencia o consentimiento a los proveedores que aún no están registrados en la Lista de proveedores globales (GVL) de IAB Europe. Con esta especificación, los publicadores, las plataformas de administración de consentimiento (CMP) y los socios pueden recopilar y propagar el consentimiento adicional (junto con su implementación del TCF) para las empresas que todavía no están registradas en la Lista de proveedores globales de IAB Europe, pero que sí se encuentran en la lista de socios de tecnología publicitaria (ATP) de Google.
Componentes del Consentimiento adicional
El consentimiento adicional consiste en una cadena addtl_consent (cadena de AC) sencilla, que contiene una lista de socios de tecnología publicitaria (ATP) de Google divulgados o que cuentan con el consentimiento de los usuarios y que no están registrados en la Lista de proveedores globales (GVL) de IAB.
Cómo generar una cadena de "Consentimiento adicional" versión 2 (ACv2)
¿Qué información se almacena en una cadena de AC?
La cadena de AC contiene los siguientes componentes:
-
Parte 1: Es el número de versión de la especificación. La versión actual es "
2". -
Parte 2: Es el símbolo separador "
~". -
Parte 3: Es una lista separada por puntos de los IDs de los socios de tecnología publicitaria (ATP) de Google que cuentan con el consentimiento de los usuarios, por ejemplo: "
1.35.41.101" -
Parte 4: Un símbolo separador "
~" -
Parte 5: "dv." seguido de una lista separada por puntos de IDs de socios de tecnología publicitaria (ATP) de Google divulgados. Ejemplo: "
dv.9.21.81"Para reducir la longitud de la cadena, los proveedores incluidos en la Parte 3 no se deben incluir en la Parte 5.
Ejemplos de cadenas de AC
Si los proveedores de ATP con los IDs 1, 2, 3, 4 y 10 se divulgan al usuario:
- … y el usuario vio el mensaje de la CMP que divulga estos proveedores, pero aún no tomó una decisión sobre si dar su consentimiento: La cadena de ACv2 correspondiente sería
2~~dv.1.2.3.4.10. -
… y el usuario brindó su consentimiento a todos los proveedores: La cadena de ACv2 correspondiente sería
2~1.2.3.4.10~dv.. Ten en cuenta que "." después de dv es opcional solo en este caso, por lo que2~1.2.3.4.10~dvtambién es una cadena de ACv2 aceptada. - … y el usuario rechazó el consentimiento para todos los proveedores, la cadena de ACv2 correspondiente debe indicar que se divulgaron todos los proveedores, pero no se dio el consentimiento para ninguno. La cadena de ACv2 correspondiente sería
2~~dv.1.2.3.4.10. - … y el usuario brindó su consentimiento para los proveedores
1y10, pero rechazó el consentimiento para todos los demás proveedores, la cadena de ACv2 correspondiente sería2~1.10~dv.2.3.4.
¿Quiénes deben crear una cadena de AC?
Solo las CMP registradas en el TCF de IAB Europe pueden crear una cadena de AC con su número de ID de CMP asignado y de acuerdo con las Políticas de IAB. Ni los proveedores ni otros proveedores de servicios externos tienen permitido crear cadenas de AC por su cuenta.
¿Dónde se publicarán los ATP de Google?
Google mantiene una lista de los socios de tecnología publicitaria que no están registrados en IAB y sus IDs en la siguiente ubicación:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
¿Cuándo debería crearse una cadena de AC?
En todos los casos, las cadenas de AC solo deben crearse cuando el publicador cumpla con la Política de Consentimiento de los Usuarios de la UE de Google.
Se deben incluir los proveedores con consentimiento solo cuando el usuario haya otorgado un consentimiento con validez legal para lo siguiente:
-
usar cookies o algún otro tipo de almacenamiento local cuando la ley lo requiera
-
recopilar, compartir y utilizar datos personales para la personalización de anuncios por parte de un ATP, así como para el cumplimiento de todas las demás condiciones de la Política de Consentimiento de los Usuarios de la UE de Google
Cuando se proporcione la transparencia adecuada a los usuarios sobre la identidad de cada ATP, incluida la vinculación a la política de privacidad del ATP tal como se indica en la lista de ATP de Google, solo deben incluirse los proveedores divulgados. No es necesario que los que se incluyan en la lista de proveedores con consentimiento también se agreguen a la lista de proveedores divulgados.
Solo se puede crear una cadena de AC como complemento de la cadena de TC, no para sustituirla. En caso de recibir solicitudes que no incluyan también una cadena de TC, Google no las procesará y descartará las cadenas de AC relacionadas.
Los CMP que implementen esta especificación deben asegurarse de que la cadena de AC que creen contenga únicamente los IDs del archivo de ATP de Google publicado (es decir, de los proveedores que no están en la GVL). Cuando Google reciba una cadena de TC, revisará la versión de la GVL que aparece allí y, si esa versión contiene el registro de un proveedor, se ignorarán los controles de la cadena de TC y las entradas de la cadena de AC de ese proveedor. En estas circunstancias, Google se reserva el derecho de quitar esas entradas "duplicadas" de la cadena de AC y pasar la cadena de AC modificada en consecuencia junto con la de TC. A excepción de Google, los proveedores no pueden modificar la cadena de AC.
¿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 desde diciembre de 2023. Se seguirán admitiendo las cadenas de consentimiento adicional generadas en función de la versión 1 de la especificación. Sin embargo, esas cadenas no pueden indicar si se estableció la transparencia para un ATP. Para admitir casos de uso que no requieran consentimiento, las CMP deben migrar a la versión 2 de la especificación.
CMP certificadas que admiten el Consentimiento adicional
En esta lista, se incluyen las CMP certificadas que son compatibles con la especificación técnica del Consentimiento adicional de Google, así como la versión del Consentimiento adicional que admiten.
Si tienes una CMP compatible con el Consentimiento adicional y (1) no apareces en esta lista o (2) se muestra la versión incorrecta del Consentimiento adicional, ve al formulario de admisión de CMP y selecciona el tipo de solicitud "Me gustaría hacer una pregunta o actualizar mi estado". Haremos todo lo posible por actualizar la ficha para que refleje tu 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: Es el nombre de la CMP certificada.
- ID de la CMP del MTC: Es el identificador único que la IAB asigna a una CMP validada según el MTC.
- Consentimiento adicional: Es la versión del Consentimiento adicional que admite la CMP.
Lista de CMP certificadas que admiten el Consentimiento adicional
Extensión de la API de la CMP
Las CMPs que admiten el Consentimiento adicional deben devolver la cadena de Consentimiento adicional como parte de los objetos JSON existentes 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 debe almacenarse una cadena de AC?
En la Web
El mecanismo de almacenamiento depende de la elección de la CMP.
En la app
Se utilizan NSUserDefaults (iOS) o SharedPreferences (Android) para almacenar la cadena de AC generada por un SDK de CMP, de manera similar a la API integrada en la app para la versión 2 del TCF. Este mecanismo permite lo siguiente:
-
Que los proveedores puedan acceder fácilmente a la cadena de AC
-
Que la cadena de AC persista a lo largo de las sesiones de la app
-
Que la cadena de AC sea portátil si un publicador cambia su CMP
Nota: Si un publicador decide quitar un SDK de CMP de su app, será responsable de borrar los valores de AddtlConsent de los usuarios para que los proveedores no sigan utilizando la cadena de AC incluida.
| Clave de almacenamiento y búsqueda en NSUserDefaults y SharedPreferences | Valor |
IABTCF_AddtlConsent |
Cadena: cadena de AC con la versión de la especificación y los IDs de los socios de tecnología publicitaria que cuentan con el consentimiento de los usuarios |
Cómo pasar la cadena de AC a través de la cadena de publicidad digital
Solicitudes de oferta
Las solicitudes de oferta usarán ConsentedProvidersSettings para propagar posteriormente los proveedores que no se incluyen en la GVL.
- En protocolo de extensiones de OpenRTB
- En la versión heredada 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 las etiquetas <img>, por ejemplo, <img src="http://vendor-a.com/key1=val1&key2=val2">, que envía una solicitud HTTP GET del navegador al dominio del proveedor.
Como el píxel está en una etiqueta <img> incapaz de ejecutar JavaScript, no se puede utilizar la API de CMP para obtener la cadena de TC. De manera similar a lo que ocurre con la compatibilidad con la cadena de TC, proporcionamos un parámetro de URL estándar y una macro en las URLs de píxel donde debería insertarse la cadena de AC.
| Parámetro de URL | Macro correspondiente | Representación en la URL |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Ejemplo 1
Para que un proveedor A reciba una cadena de AC, la URL de imagen debe incluir un par clave-valor con el parámetro de URL y la macro &addtl_consent=${ADDTL_CONSENT}. La URL resultante es la siguiente:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Ejemplo 2
En una solicitud, si la cadena de AC es 2~1.35.41.101~dv., ocurrirá lo siguiente:
El llamador o el renderizador de la creatividad reemplazará la macro de la URL con la cadena de AC real, de modo que el píxel que contiene la macro y que se colocó originalmente se modifica de la siguiente manera cuando se llama al servidor especificado:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.