Qué es realmente la TC string

El IAB Transparency & Consent Framework produce un único token compacto — la TC string — que viaja con cada solicitud de anuncio y le dice a los proveedores exactamente con qué ha aceptado y con qué no ha aceptado un usuario. Está codificada en Base64-URL y empaquetada a nivel de bits, por lo que parece un galimatías (CPxy...AAA) pero codifica un registro preciso y auditable.

Los segmentos

Una TC string completa son varios segmentos separados por puntos. El primero es la cadena central; los demás son opcionales:

• Central — ID del CMP, versión del CMP, las marcas de tiempo del consentimiento, la versión de la política y, fundamentalmente, los campos de bits de consentimientos de propósito y consentimientos de proveedor.
• Proveedores divulgados — qué proveedores se mostraron al usuario.
• TC del publisher — consentimientos específicos para ti, el publisher.

Los campos de bits son el núcleo: el bit N puesto a 1 significa consentimiento para el propósito N o el proveedor N. El propósito 1 es “almacenar/acceder a información en un dispositivo,” los propósitos 3 y 4 cubren los anuncios personalizados, y así sucesivamente.

Decodificar una en la práctica

Rara vez decodificas bits a mano. Usa las bibliotecas proporcionadas por IAB o un decodificador público:

• Divide por . y decodifica en Base64-URL el segmento central.
• Lee los campos de cabecera de ancho fijo (version, created, lastUpdated, cmpId, cmpVersion).
• Recorre los campos de bits de propósito y proveedor para ver exactamente cuáles están concedidos.

En JavaScript, la llamada __tcfapi('getTCData', 2, cb) devuelve el objeto ya analizado — tcData.purpose.consents y tcData.vendor.consents son mapas de id → booleano. Esa es tu verdad de referencia en tiempo de ejecución.

Los errores que matan los ingresos

Cuando la demanda personalizada desaparece silenciosamente, la TC string suele ser el motivo:

• Cadena ausente — la solicitud de anuncio no lleva gdprApplies/TC string, así que los SSP que cumplen bajan a no personalizado.
• Proveedor sin consentimiento — el bit del ID de proveedor de tu socio de demanda es 0, así que no puede pujar con personalización.
• Cadena caducada u obsoleta — una marca de tiempo antigua hace que las plataformas posteriores desconfíen de ella.
• ID de CMP incorrecto — un ID de CMP no registrado o de prueba invalida toda la cadena.

Un flujo de depuración

Reproduce el consentimiento del usuario, captura la TC string en vivo desde __tcfapi o la solicitud de anuncio, pásala por un validador y compara los propósitos/proveedores decodificados con lo que requieren tus socios. Nueve de cada diez veces la brecha es un único bit de proveedor o un propósito 1 ausente.

Dónde encaja FlexyConsent

FlexyConsent genera TC strings válidas según la especificación con un ID de CMP registrado, las mantiene frescas, expone el estado decodificado para depuración e informa de qué propósitos y proveedores están realmente concedidos en todo tu tráfico — para que puedas ver, no adivinar, dónde se está fugando el consentimiento (y los ingresos).

Puntos clave

• La TC string es un registro auditable y empaquetado en bits de cada elección de consentimiento.
• Los campos de bits de propósito y proveedor deciden si los socios pueden servir anuncios personalizados.
• La mayoría de las caídas de ingresos se deben a una cadena ausente, un proveedor sin consentimiento o un ID de CMP obsoleto/inválido.
• Decodifica la cadena en vivo con __tcfapi y valídala contra los requisitos de los socios al depurar.