En este documento, se define una especificación técnica (denominada "Consentimiento adicional") destinada a utilizarse únicamente junto con la versión 2 del Marco de trabajo de transparencia y consentimiento (MTC) de IAB Europe, para enviar indicadores de transparencia y consentimiento a los proveedores que todavía 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 MTC) 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 proveedores de tecnología publicitaria (ATP) de Google.
Cambios en la versión 2 de Consentimiento adicional
Desde diciembre de 2023, Google admite la versión 2 de nuestra especificación de Consentimiento adicional. Los cambios principales son los siguientes:
- Se actualizó la cadena de Consentimiento adicional (AC) para admitir a los proveedores divulgados en la CMP.
- Se actualizó la API de CMP para permitir la interoperabilidad de las CMP que admiten tanto el MTC como el Modo de consentimiento del anunciante.
Componentes del Consentimiento adicional
En el "Consentimiento adicional", admitimos los siguientes elementos:
- La cadena de transparencia y consentimiento (cadena de TC), según se define en la especificación de la versión 2.2 del MTC de IAB, que contiene los detalles de transparencia y consentimiento establecidos para los proveedores registrados en la Lista de proveedores globales (GVL) de IAB
- Una cadena
addtl_consent(cadena de AC) sencilla, que contiene una lista de proveedores de tecnología publicitaria (ATP) de Google divulgados o que cuentan con el consentimiento de los usuarios y que no están registrados en IAB
Esta especificación define lo siguiente:
-
El formato de la cadena de AC
-
La extensión necesaria para que la API de CMP de la versión 2.2 del MTC admita la cadena de AC y controles para cuando estén presentes el MTC y el Modo de consentimiento del anunciante
-
Cómo debe almacenarse una cadena de AC
-
Cómo pasar la cadena de AC a través de la cadena de publicidad digital
El formato de la cadena de "Consentimiento adicional" (AC)
¿Qué información se almacena en una cadena de AC?
La cadena de AC contiene los siguientes componentes:
-
Parte 1: Un número de versión de la especificación, como "
2" -
Parte 2: Un símbolo separador "
~" -
Parte 3: Una lista separada por puntos de los IDs de los proveedores 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 proveedores 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.
Ejemplo de cadena de AC
La cadena de AC 2~1.35.41.101~dv.9.21.81 indica que el usuario brindó su consentimiento a los ATP cuyos IDs son 1, 35, 41 y 101, que los ATP cuyos IDs son 9, 21 y 81 se divulgaron al usuario y que la cadena se creó según el formato que se define en la versión 2 de la especificación.
¿Quiénes deben crear una cadena de AC?
Solo las CMP registradas en el MTC 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 publicará la lista de proveedores 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 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 Usuarios de la UE de Google
Los proveedores divulgados que no tienen consentimiento 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 solo deben incluirse 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 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 junto con la de TC. A excepción de Google, los proveedores no pueden modificar la cadena de AC.
Recursos relacionados
-
Cadena de transparencia y consentimiento con el formato de la Lista de proveedores globales v2.2
-
Políticas del Marco de trabajo de transparencia y consentimiento de IAB Europe
Extensión de la API de CMP
Proponemos extender la API de JavaScript de CMP existente de la CMP del MTC v2.2 para permitir que se muestre la cadena de AC. De manera más específica, proponemos extender los objetos JSON InAppTCData y TCData para que devuelvan 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 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 debe utilizar NSUserDefaults (iOS) o SharedPreferences (Android) para almacenar la cadena de AC mediante un SDK de CMP. Esto 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 aplicación
-
Que la cadena de AC sea portátil entre las diferentes CMP para brindar la flexibilidad que se necesita para que los publicadores puedan intercambiar un SDK de CMP por otro
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 proveedores 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
Solicitud de oferta
Se reutilizará 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 dada, si la cadena de AC es 1~1.35.41.101, 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=1~1.35.41.101
