¿Qué es el IAB TCF?

El IAB TCF es un formato técnico estándar, desarrollado conjuntamente por IAB Europe y IAB Tech Lab, para que los sitios web y las aplicaciones muestren de forma uniforme qué consentimiento ha dado un usuario y lo transmitan a los socios de publicidad programática que participan en la entrega de un anuncio. No es una ley ni una certificación oficial de ningún regulador. Es un acuerdo de la industria publicitaria sobre cómo codificar y compartir esa información entre todas las partes que intervienen en una subasta publicitaria.

Conviene separarlo de una CMP (plataforma de gestión del consentimiento). La CMP es el software instalado en la web, el banner que el usuario ve y con el que acepta o rechaza categorías de tratamiento de sus datos. El TCF es el estándar que define cómo esa CMP debe generar y estructurar la señal de consentimiento para que sea legible por cualquier proveedor publicitario del ecosistema. Una web puede tener una CMP instalada sin cumplir el TCF, y de hecho muchas CMP del mercado ofrecen ambos modos de funcionamiento al mismo tiempo.

La especificación oficial del TCF solo existe en inglés. IAB Europe no publica una versión traducida al español ni al alemán, así que cualquier consulta técnica directa sobre el estándar termina remitiendo a la documentación en inglés.

El elemento central del TCF es el TC String (Transparency & Consent String), una cadena de caracteres codificada que registra, para un usuario concreto, a qué finalidades de tratamiento y a qué proveedores concretos ha dado su consentimiento o ha manifestado su oposición legítima. Esa cadena no es legible a simple vista: sigue un formato binario comprimido que solo se decodifica con herramientas específicas.

Para que el TC String tenga sentido en todo el ecosistema, el TCF mantiene la Global Vendor List (GVL), un registro público con todos los proveedores publicitarios inscritos, cada uno con un identificador numérico fijo. Cuando la CMP construye el TC String, marca los identificadores de la GVL que corresponden a los proveedores que el usuario ha aceptado.

El recorrido del string sigue tres pasos. Primero, la CMP lo genera en el navegador o la app cuando el usuario interactúa con el banner de consentimiento. Segundo, el publisher, el sitio web o la app, lo almacena, normalmente en una cookie o en local storage, y lo expone a través del framework técnico del TCF para que cualquier script de la página pueda leerlo. Tercero, cada proveedor de tecnología publicitaria que participa en la subasta programática, ya sea un SSP, un DSP o un exchange, consulta ese string antes de decidir si puede pujar por mostrar un anuncio personalizado a ese usuario concreto, y con qué finalidades.

Si un proveedor no encuentra su identificador entre los aceptados dentro del TC String, la especificación le exige tratar a ese usuario, para ese proveedor en concreto, como si no hubiera dado consentimiento, aunque haya aceptado a otros proveedores del mismo string.

El TC String decide algo muy concreto: si un proveedor de publicidad programática puede dirigirse a ese usuario con anuncios personalizados, medir su comportamiento o compartir sus datos con terceros. Sin una señal válida, la especificación obliga a tratarlo como un usuario sin consentimiento, lo que reduce directamente el inventario de demanda disponible para ese publisher.

Esto se ha vuelto más exigente con la versión 2.3. IAB Europe publicó el TCF v2.3 el 19 de junio de 2025, con un periodo de transición que concluyó el 28 de febrero de 2026. Desde el 1 de marzo de 2026, cualquier TC String generado sin el segmento obligatorio disclosedVendors se considera inválido. Los strings conformes generados antes de esa fecha siguen siendo válidos hasta que el propio usuario modifique su elección.

La diferencia importa porque el segmento disclosedVendors no describe cómo funciona el proceso de consentimiento, sino que aporta una prueba técnica legible por máquina de qué proveedores concretos mostró realmente la CMP al usuario en el momento de pedir su consentimiento. Antes bastaba con explicar el proceso. Ahora el propio TC String tiene que demostrarlo.

• Comprobar que la CMP instalada declara ya la versión 2.3 del TCF y genera el segmento disclosedVendors en cada TC String nuevo que emite, sin excepciones por tipo de dispositivo.
• Decodificar una muestra de TC Strings generados después del 1 de marzo de 2026 y verificar que el segmento disclosedVendors aparece y contiene los proveedores que realmente se mostraron en el banner.
• Contrastar la lista de proveedores configurada en la CMP con la Global Vendor List vigente, porque IAB Europe la actualiza con cierta frecuencia y un proveedor eliminado o renombrado puede romper la señal sin que salte ninguna alerta visible.
• Confirmar con cada socio publicitario, SSP, DSP o exchange, que su integración lee el TC String actual y no una versión anterior del framework que ya no reconoce el nuevo segmento.
• Pedir al proveedor de la CMP una confirmación por escrito de que su implementación concreta cumple la versión 2.3 del TCF, y guardar esa confirmación como evidencia de cumplimiento.
• Revisar el cumplimiento de forma periódica, porque IAB Europe sigue publicando actualizaciones de la especificación y una CMP conforme hoy puede dejar de estarlo con la siguiente revisión.

• Asumir que hay que volver a pedir el consentimiento de todos los usuarios el 1 de marzo de 2026. Los TC Strings válidos generados antes de esa fecha siguen siendo válidos hasta que el usuario cambie su elección.
• Confundir la CMP con el TCF y dar por hecho que instalar cualquier banner de consentimiento ya cumple el estándar, sin comprobar qué versión del framework implementa realmente.
• No comprobar si los socios publicitarios de la cadena leen y respetan realmente el TC String, y seguir tratando al usuario como si no hubiera dado consentimiento aunque sí lo diera.
• Tratar la explicación del proceso de consentimiento como si fuera equivalente a la prueba técnica que exige el segmento disclosedVendors, cuando son dos cosas distintas.
• Trabajar con una Global Vendor List desactualizada y dejar proveedores activos sin declarar en el TC String, lo que invalida la señal para esos proveedores concretos.