GDPR, TCF y consent strings: lo que un DSP debe gestionar en Europa

Todo anuncio programmatic que se compra en Europa empieza con una pregunta que la mayoría de los compradores nunca ve: ¿aceptó esta persona que sus datos se usen con fines publicitarios? ¿Y por parte de quién? La respuesta viaja dentro de la bid request como un breve texto codificado llamado cadena de consentimiento. Si una DSP no puede leerla, está adivinando.

Adivinar sale caro. Una DSP que puja con datos personales sin una base legal válida se expone, junto con sus clientes y sus partners de supply, a riesgos regulatorios bajo el RGPD. Una DSP que ignora las señales de consentimiento en el sentido contrario, y simplemente deja de pujar en Europa, renuncia a parte del inventario más valioso del mundo. La respuesta correcta está en un punto intermedio, y es sobre todo un problema de ingeniería.

Esta guía explica cómo se aplica el RGPD a la compra programmatic, qué es el Transparency and Consent Framework (TCF) de IAB Europe, qué contiene una cadena de consentimiento TCF, cómo llega esa cadena a una DSP dentro de una bid request de OpenRTB y qué comprobaciones debe hacer una DSP antes de pujar. Es una guía práctica, no asesoramiento legal.

Por qué el RGPD importa a los compradores programmatic

El Reglamento General de Protección de Datos entró en vigor el 25 de mayo de 2018. Se aplica siempre que una empresa trata datos personales de personas de la Unión Europea, y en el mundo programmatic casi todo cuenta como dato personal: los IDs de cookies, los IDs de publicidad móvil, las direcciones IP y la ubicación precisa son identificadores que permiten singularizar a una persona o a un dispositivo.

Junto a él existe una segunda norma. La Directiva ePrivacy regula el almacenamiento o la lectura de información en el dispositivo del usuario, que es exactamente lo que hace una cookie o una consulta de ID de dispositivo. En la práctica, esto significa que una DSP normalmente necesita consentimiento antes de poder leer o instalar su propia cookie en el navegador de un usuario europeo, incluso antes de hacer cualquier otra cosa con los datos.

Para un comprador, esto plantea tres preguntas prácticas en cada impresión europea:

• ¿Se aplica el RGPD a esta solicitud?
• ¿Ha aceptado el usuario los usos concretos que la DSP quiere hacer, como crear perfiles o medir resultados?
• ¿Ha aceptado el usuario que esta empresa en concreto, la propia DSP, trate sus datos?

¿Qué es el Transparency and Consent Framework de IAB Europe?

El Transparency and Consent Framework es un estándar voluntario gestionado por IAB Europe. Ofrece a publishers, proveedores tecnológicos y herramientas de consentimiento una forma común de describir para qué se usan los datos, quién los usa y qué dijo el usuario al respecto. IAB Europe distingue tres grupos de participantes:

• Publishers: los propietarios de los sitios web y las apps donde se recogen los datos.
• Vendors: empresas terceras como ad servers, proveedores de medición, agencias, SSPs y DSPs.
• Plataformas de gestión del consentimiento (CMPs): las herramientas que muestran el banner de consentimiento, registran las elecciones del usuario y las convierten en una cadena de consentimiento.

Los vendors se registran en la Global Vendor List (GVL), una lista pública mantenida por IAB Europe. Cada vendor registrado recibe un ID numérico y declara para qué finalidades trata datos y con qué base legal. A noviembre de 2026, la lista oficial incluye más de 1.200 vendors registrados. Cuando un usuario toma una decisión en un banner de consentimiento, la CMP la registra asociada a esos IDs de vendor.

TCF v2.2 se lanzó el 16 de mayo de 2023. En abril de 2025, IAB Europe lanzó TCF v2.3, que hace obligatoria la sección Disclosed Vendors de la cadena de consentimiento para resolver una ambigüedad en torno al interés legítimo. Los participantes tenían hasta el 28 de febrero de 2026 para adoptar la v2.3, así que cualquier DSP que compre inventario europeo hoy debería esperar cadenas v2.3.

Las finalidades del TCF que una DSP debe conocer

El TCF no le hace al usuario una única pregunta de sí o no. Divide el uso de datos en finalidades estándar, cada una con un número y un nombre fijos. Una DSP declara cuáles necesita, y la cadena de consentimiento registra la respuesta del usuario para cada una. Estas son las once finalidades de la Global Vendor List oficial:

Además de estas, el TCF define finalidades especiales que no requieren consentimiento, como garantizar la seguridad y prevenir el fraude, o entregar y mostrar anuncios. También define características especiales que requieren una aceptación expresa por separado; la más relevante es el uso de datos de geolocalización precisa.

Cada finalidad se apoya en una base legal: el consentimiento o el interés legítimo. Desde TCF v2.2, las finalidades 3 a 6, las de elaboración de perfiles, solo pueden basarse en el consentimiento. Para una DSP que hace segmentación por audiencias o retargeting, esta es la regla más importante de todas: sin consentimiento para las finalidades 3 y 4, no hay puja personalizada.

¿Qué contiene una cadena de consentimiento TCF?

La cadena de consentimiento TCF, también llamada TC string, es un texto codificado y compacto que la CMP genera después de que el usuario toma su decisión. Una vez decodificada, la parte principal de la cadena contiene:

• Metadatos: la versión del TCF, cuándo se creó y se actualizó por última vez la cadena, el ID de la CMP, el idioma del consentimiento y la versión de la Global Vendor List utilizada.
• Consentimientos por finalidad: un sí o un no para cada finalidad sobre la que se preguntó al usuario.
• Intereses legítimos por finalidad: si al usuario se le informó del tratamiento basado en interés legítimo para cada finalidad aplicable y no se opuso.
• Aceptaciones de características especiales: por ejemplo, si se puede usar la geolocalización precisa.
• Consentimientos e intereses legítimos por vendor: un sí o un no para cada ID de vendor de la lista.
• Restricciones del publisher: reglas que el publisher ha fijado para vendors concretos, como exigir consentimiento cuando un vendor usaría normalmente el interés legítimo, o bloquear una finalidad por completo.

Con TCF v2.3, la cadena incluye además un segmento Disclosed Vendors, que enumera los vendors que realmente se mostraron al usuario en el aviso de consentimiento. Así, un vendor puede distinguir entre «el usuario se opuso a mí» y «al usuario nunca se le informó sobre mí».

La clave para los compradores: una cadena de consentimiento es bidimensional. Una DSP necesita que la finalidad esté permitida y que su propio ID de vendor esté permitido. Un usuario puede aceptar la publicidad personalizada en general pero rechazar una DSP concreta, y la cadena registra ambas respuestas.

Cómo llega la cadena de consentimiento a la DSP

La cadena de consentimiento recorre la cadena de suministro junto con la solicitud de anuncio. El recorrido habitual es este:

1. El usuario visita un sitio web o abre una app, y la CMP muestra un aviso de consentimiento.
2. El usuario toma su decisión, y la CMP la guarda como TC string, normalmente en una cookie first-party o en el almacenamiento de la app.
3. Cuando se carga un espacio publicitario, el stack publicitario del publisher lee la cadena y la pasa a la SSP.
4. La SSP la añade a la bid request de OpenRTB que envía a todas las DSPs conectadas.
5. La DSP decodifica la cadena, comprueba sus propios permisos y decide cómo pujar, o si pujar.

En la bid request de OpenRTB, la señal viaja en dos campos. OpenRTB 2.6 tiene un campo nativo regs.gdpr, con valor 1 cuando se aplica el RGPD y 0 cuando no, y un campo nativo user.consent que contiene la propia TC string. Las integraciones más antiguas con OpenRTB 2.5 colocan los mismos valores en extensiones, como regs.ext.gdpr y user.ext.consent, así que una DSP conectada a muchos partners de supply debería leer ambas ubicaciones. Nuestra guía sobre la anatomía de una bid request muestra dónde se sitúan estos objetos dentro de la solicitud completa.

Algunos partners también envían una cadena de Global Privacy Platform (GPP) en regs.gpp y regs.gpp_sid. GPP es un contenedor de IAB Tech Lab que puede incluir la cadena TCF junto con otras señales regionales, por lo que una DSP debería extraer la sección TCF y aplicar la misma lógica.

La cadena no se detiene en la DSP. Los ad tags y los píxeles de seguimiento pueden recibirla mediante macros estándar, como ${GDPR} para el indicador de aplicación y ${GDPR_CONSENT_XXX} para la cadena, donde XXX es el ID de vendor de la empresa a la que se llama.

Las comprobaciones que una DSP debe hacer antes de pujar

Todo esto ocurre dentro de la ventana de puja, que suele ir de unas pocas decenas a unos pocos cientos de milisegundos, como se explica en nuestra guía sobre cómo funciona el real-time bidding. La lógica de consentimiento debe ser rápida, predecible e igual para todas las solicitudes. Una DSP bien diseñada realiza estas comprobaciones en este orden:

1. ¿Se aplica el RGPD? Lee el indicador gdpr. Si vale 1, se aplican las reglas de consentimiento. Si falta en tráfico procedente de un país de la UE, trata la solicitud como si se aplicara el RGPD.
2. ¿Está presente la cadena y es válida? Una cadena ausente, vacía o corrupta equivale a no tener consentimiento. No uses datos personales.
3. ¿Está permitido el ID de vendor de la DSP? Revisa las secciones de consentimiento e interés legítimo del vendor para tu propio ID.
4. ¿Están permitidas las finalidades necesarias? Comprueba la finalidad 1 antes de leer la cookie o el ID de dispositivo del usuario, las finalidades 3 y 4 antes de usar segmentos de audiencia y la finalidad 7 antes de medir.
5. ¿Cambian algo las restricciones del publisher? Aplica cualquier restricción que el publisher haya fijado para tu ID de vendor antes de actuar según las respuestas sobre vendor y finalidades.
6. ¿Se necesita una característica especial? Usa la geolocalización precisa solo si está activada esa aceptación de característica especial.

El resultado no debería ser un simple pujar o no pujar. Una DSP bien construida elige uno de estos modos para cada solicitud:

Vale la pena construir bien el modo contextual. Muchos usuarios europeos rechazan la publicidad personalizada, y los compradores que aún pueden pujar por contexto y formato siguen llegando a ese inventario. Nuestro artículo sobre publicidad cookieless repasa las opciones de segmentación que siguen funcionando sin datos a nivel de usuario.

Errores de consentimiento habituales en las DSPs

La mayoría de los problemas de consentimiento son pequeños atajos de ingeniería, no malentendidos legales. Los más comunes:

• Comprobar las finalidades pero no el vendor. El usuario dijo que sí a los anuncios personalizados, pero no a tu empresa. Usar los datos sigue sin estar permitido.
• Sincronizar IDs de usuario sin la finalidad 1. Los cookie syncs y las consultas de ID cuentan como acceso al dispositivo. Primero necesitan la finalidad 1 y el consentimiento del vendor.
• Tratar una cadena ausente como consentimiento. Cuando se aplica el RGPD y no llega ninguna cadena, lo seguro por defecto es no usar datos personales.
• Leer solo una ubicación de OpenRTB. Algunos partners envían regs.gdpr, otros regs.ext.gdpr y otros GPP. Léelas todas.
• Usar una lista de vendors desactualizada. Actualiza tu copia de la Global Vendor List de forma periódica.
• Perder la cadena aguas abajo. Si las creatividades y los trackers no reciben la cadena mediante macros, no pueden tomar su propia decisión, y es el comprador quien asume ese riesgo.
• No registrar la decisión. Si un regulador o un partner pregunta por qué se usaron los datos de un usuario, necesitas el estado de consentimiento que se aplicaba en el momento de la impresión.

La misma disciplina se aplica a los datos que incorporas a la plataforma. Si conectas una DMP a tu DSP, los segmentos de audiencia solo deberían activarse en solicitudes cuya cadena de consentimiento permita el perfilado para tu ID de vendor.

La postura de reguladores y tribunales

El TCF es un estándar de autorregulación, no una ley, y los reguladores lo han examinado con detenimiento. En marzo de 2024, el Tribunal de Justicia de la Unión Europea dictaminó, en un caso relacionado con IAB Europe, que una TC string puede constituir un dato personal cuando puede vincularse a un identificador como una dirección IP. Por tanto, la propia cadena merece el mismo cuidado que cualquier otro dato de usuario.

Para el propietario de una DSP, la lección práctica es sencilla. El TCF te da un lenguaje compartido, no un escudo legal. Define tu papel en cada flujo de datos con asesoramiento legal cualificado, documenta tu lógica de consentimiento y asegúrate de que la plataforma se comporta tal como está documentado.

Qué cambia cuando la DSP es tuya

Cuando compras a través de la plataforma de otro, su lógica de consentimiento decide cómo se comportan tus campañas en Europa, y a menudo no puedes ver por qué el alcance europeo es menor de lo esperado.

Cuando la plataforma es tuya, el consentimiento pasa a ser algo que puedes configurar y auditar:

• Decides lo estricto que es el comportamiento por defecto sin consentimiento, y si se hace puja contextual en solicitudes sin consentimiento para perfilado.
• Puedes informar del alcance europeo por estado de consentimiento, para que los clientes entiendan por qué una campaña de audiencias escala de forma distinta en Francia que en Brasil.
• Controlas durante cuánto tiempo se conservan los registros de consentimiento y los logs, y quién puede acceder a ellos.
• Eliges qué partners de supply conectar según lo bien que transmitan los indicadores gdpr y las cadenas de consentimiento.

La DSP de AdTech Europe incluye un módulo de Gestión del Consentimiento y TCF que se integra con el IAB Transparency and Consent Framework para gestionar las señales de consentimiento en las regiones sujetas al RGPD, de modo que la segmentación y la medición respeten los permisos tanto del anunciante como del publisher.

¿Listo para hacer compras preparadas para el consentimiento en tu propia DSP?

AdTech Europe ofrece tecnología de demand-side platform a agencias, ad networks, equipos de compra de medios y emprendedores adtech que quieren ser dueños de su stack de compra en lugar de alquilarlo. La plataforma funciona con tu propia marca y dominio, lee las señales de consentimiento del supply conectado y deja las reglas de puja en tus manos.

A noviembre de 2026, puedes alquilar la DSP por $500 al mes (los planes mensuales incluyen una tarifa única de configuración equivalente a un mes) o $5,000 al año, obtener una licencia por $25,000 en un solo pago o en 12 pagos, o adquirir el código fuente completo por $50,000. Las cifras actualizadas en todas las divisas disponibles están en la página de precios, y la página de White Label DSP muestra la opción con tu marca. Para planificar una configuración europea adaptada a tus clientes y a tu supply, agenda una reunión de estrategia programmatic con nuestro equipo.

Preguntas frecuentes

¿Qué es una cadena de consentimiento TCF?

Una cadena de consentimiento TCF, o TC string, es un texto codificado que genera una plataforma de gestión del consentimiento después de que un usuario toma una decisión sobre su privacidad. Registra qué finalidades y qué vendors permitió el usuario, y viaja con las solicitudes de anuncios para que todas las empresas de la cadena puedan comprobarla.

¿Dónde está la cadena de consentimiento en una bid request de OpenRTB?

En OpenRTB 2.6 está en el campo user.consent, con el campo regs.gdpr en 1 cuando se aplica el RGPD. Las integraciones más antiguas con OpenRTB 2.5 usan user.ext.consent y regs.ext.gdpr. Algunos partners también la envían dentro de una cadena GPP en regs.gpp.

¿Qué debe hacer una DSP si no hay cadena de consentimiento?

Si se aplica el RGPD y no llega ninguna cadena válida, la DSP no debe usar datos personales. Eso significa nada de IDs de usuario, nada de segmentos de audiencia y nada de cookie syncs. Según su asesoramiento legal, puede descartar la solicitud o pujar solo con señales no personales.

¿Qué finalidades del TCF necesita una DSP para hacer retargeting?

El retargeting utiliza perfiles, así que necesita consentimiento para la finalidad 3, crear perfiles para publicidad personalizada, y la finalidad 4, utilizar perfiles para seleccionar publicidad personalizada. También necesita la finalidad 1 para leer la cookie o el ID de dispositivo del usuario, además del consentimiento para el propio ID de vendor de la DSP.

¿Cuál es la versión actual del TCF?

La versión actual es TCF v2.3, lanzada por IAB Europe en abril de 2025. Hace obligatoria la sección Disclosed Vendors de la cadena de consentimiento. Los participantes tenían hasta el 28 de febrero de 2026 para adoptarla.

¿Es el TCF obligatorio por ley?

No. El TCF es un estándar voluntario del sector gestionado por IAB Europe. Las leyes son el RGPD y la Directiva ePrivacy. El TCF es una forma compartida de que las empresas recojan, transmitan y respeten el consentimiento para poder cumplir esas leyes a la velocidad de una subasta.

¿Puede una DSP seguir pujando sin consentimiento para publicidad personalizada?

A menudo, sí. Si el ID de vendor de la DSP está permitido pero se rechazan las finalidades de perfilado, puede pujar con datos limitados como el sitio web, la app, el formato del anuncio y la ubicación aproximada. Esta puja contextual mantiene el alcance europeo respetando a la vez la decisión del usuario.