La versión corta

TCF v2.3 es una evolución de v2.2, no una re‑arquitectura. El formato de la TC String es compatible, los fines y funcionalidades existentes se conservan y la mayoría de los requisitos de la interfaz de usuario de cara al editor se mantienen sin cambios. Los cambios significativos se concentran en cuatro áreas:

• Normas más claras sobre cómo las CMPs deben presentar la información de los proveedores y los periodos de conservación.
• Nuevos requisitos para controles granulares en la segunda capa que los reguladores vienen exigiendo desde la decisión de la DPA belga de 2022.
• Refuerzo del cumplimiento de las Policies en torno a dark patterns, igualdad de prominencia y opciones preseleccionadas.
• Ajustes en el esquema de la Global Vendor List (GVL) y en el flujo de información sobre proveedores.

Por qué existe v2.3

Cada versión de TCF es una negociación entre tres audiencias: editores que necesitan seguir monetizando, proveedores que necesitan una interfaz técnica estable y reguladores que siguen detectando brechas concretas de cumplimiento. v2.3 es una respuesta directa a tres presiones:

1. Acciones de cumplimiento contra el uso excesivo del "interés legítimo" bajo v2.2. Varias DPAs europeas sostuvieron que demasiados proveedores reclamaban LI para fines en los que el único fundamento lícito era en realidad el consentimiento. v2.3 endurece las declaraciones de base jurídica que hacen los proveedores y las hace más visibles desde el principio en la interfaz de consentimiento.
2. Quejas continuas sobre dark patterns. Las Policies actualizadas hacen que la regla de igualdad de prominencia sea más explícita y cierran vacíos legales en torno a los toggles preseleccionados en la segunda capa.
3. Comentarios operativos de grandes CMPs y editores. v2.2 introdujo varias obligaciones de información que era difícil implementar de forma limpia en móvil y CTV. v2.3 simplifica el conjunto de avisos obligatorios y permite que una mayor parte viva en una vista por capas.

Compatibilidad de la TC String

La propia TC String sigue siendo retrocompatible. Una CMP v2.3 produce cadenas que los proveedores v2.2 pueden leer, y un proveedor v2.3 puede consumir cadenas v2.2 durante el periodo de transición. El indicador de versión en el segmento central de la cadena identifica con qué versión de las Policies la CMP afirma cumplir, y el puntero a la versión de la GVL avanza de forma independiente.

Qué significa esto en la práctica: no es necesario actualizar a todos los proveedores a la vez, y no es necesario forzar un nuevo evento de consentimiento para cada usuario el día que se implemente v2.3. Se admite explícitamente un despliegue por fases.

Principales cambios técnicos

1. Información de proveedores y conservación

v2.3 exige que las CMPs muestren el periodo de conservación de datos declarado por cada proveedor en la interfaz por capas, y no solo en una lista de proveedores separada. El valor de conservación siempre ha formado parte de la GVL, pero v2.2 no obligaba a que los usuarios lo vieran junto con los fines. v2.3 cierra esa brecha porque los reguladores argumentaron que los usuarios no podían tomar una decisión informada sin saber durante cuánto tiempo persistirían sus datos.

2. Controles más estrictos en la segunda capa

En la segunda capa —la vista de "gestionar preferencias"— v2.3 establece de forma explícita que los toggles para fines y proveedores no esenciales deben estar por defecto en off. Las casillas pre‑marcadas o los deslizadores preactivados constituyen una infracción de las Policies incluso si el usuario nunca hace clic explícito en "aceptar". Las CMPs que hasta ahora se basaban en un patrón de "soft opt‑in" tendrán que volver a renderizar la segunda capa.

3. Refuerzo de la igualdad de prominencia

La regla de igualdad de prominencia existe desde v2.1, pero v2.3 la define con menos margen de interpretación: el control de "rechazar todo" debe estar en la misma capa, tener el mismo peso visual, la misma clase de contraste de color y la misma distancia de interacción que "aceptar todo". Ocultar el rechazo detrás de un enlace, un botón más pequeño o una pantalla secundaria pasa a ser un fallo de cumplimiento explícito en lugar de una cuestión de criterio.

4. Señalización del interés legítimo

Los proveedores que declaren el interés legítimo como base jurídica en v2.3 deben indicar ahora también qué fines han evaluado y para cuáles han completado una Legitimate Interests Assessment. Las CMPs están obligadas a trasladar esta declaración a la interfaz de usuario para que los usuarios puedan oponerse con información completa. En la práctica, esto significa que el flujo de "oposición" ahora muestra el estado de LIA específico de cada proveedor en lugar de un toggle genérico.

5. Actualizaciones del esquema de la GVL

El esquema de la Global Vendor List añade campos para granularidad de conservación, estado de LIA y un enlace legible por máquina a la sección de la política de privacidad de cada proveedor relativa a los fines declarados. Las CMPs que almacenan en caché la GVL deben actualizar su analizador de esquema para entender los nuevos campos antes de apuntar a una GVL v2.3.

Cambios de Policies que afectan a la UX

El TCF es a la vez una especificación técnica y un conjunto de Policies. Varios de los cambios de Policies en v2.3 impactan directamente en la interfaz de consentimiento:

• Se acabó el "continuar sin aceptar" como equivalente al rechazo salvo que visualmente coincida con el botón de aceptación y genere la misma TC String que un rechazo total.
• Paridad de idioma: el aviso de consentimiento debe estar disponible en todos los idiomas en los que esté disponible el propio sitio, no solo en el idioma del navegador del usuario. Las CMPs deben permitir la selección manual de la configuración regional.
• Acceso persistente: los usuarios deben poder acceder al centro de preferencias desde cada página del sitio, no solo desde la página de entrada, y el enlace de acceso debe etiquetarse de forma que un usuario no experto lo reconozca como relacionado con el consentimiento.

Qué deben hacer los editores

1. Confirmar la compatibilidad con v2.3 de su proveedor de CMP. Pida la fecha exacta en la que estará disponible su versión certificada v2.3 y la cadena de versión que reportará.
2. Actualizar la lógica de caché de la GVL. Si aloja usted mismo algún mirror de la GVL, actualice el analizador de esquema antes de que se publique la GVL v2.3, o su CMP no podrá validar a los nuevos proveedores.
3. Reescribir su interfaz de segunda capa de modo que todos los toggles estén por defecto en off, la igualdad de prominencia se cumpla visualmente y los periodos de conservación se muestren junto a los fines.
4. Volver a ejecutar su auditoría de cumplimiento. Las infracciones más sencillas de detectar para los reguladores son los dark patterns que v2.3 ahora señala de forma explícita. Corríjalos antes de su próxima revisión de cumplimiento.
5. Planificar una estrategia de re‑solicitud de consentimiento. Aunque la TC String es retrocompatible, las Policies animan a los editores a volver a recabar el consentimiento cuando el alcance o la información sobre el tratamiento cambian de forma sustancial. Decida si su despliegue de v2.3 entra en la categoría de cambio "sustancial" para su audiencia.

Qué deben hacer los proveedores

1. Completar una Legitimate Interests Assessment para cada fin en el que declaren LI y enviar el resultado a la GVL.
2. Actualizar su entrada en la GVL con los campos del esquema v2.3: granularidad de conservación, declaración de LIA y deep link a la política de privacidad.
3. Validar su analizador de TC String frente a las cadenas de referencia v2.3 proporcionadas por IAB Europe.
4. Coordinarse con sus socios CMP en una fecha común de cambio, para que la primera petición de compra que lleve una cadena v2.3 no llegue a un proveedor que solo soporte v2.2.

Errores habituales en la migración

• Tratar v2.3 como una oportunidad de rediseño de la interfaz. Es tentador agrupar actualizaciones de marca con el despliegue de v2.3, pero hacerlo complica las pruebas de cumplimiento. Publique primero una versión de v2.3 centrada solo en cumplimiento y después itere en diseño.
• Pasar por alto el requisito de mostrar la conservación. Los equipos suelen actualizar la vista de lista de proveedores pero olvidan que ahora la conservación también debe aparecer en la vista por capas, fin por fin.
• Suponer que la TC String es suficiente. Una cadena conforme producida por una interfaz no conforme sigue siendo no conforme. Los reguladores han sancionado repetidamente a operadores cuyas cadenas parecían correctas pero cuyos banners ocultaban el botón de rechazo.
• Dejar fuera de alcance CTV y móvil. v2.3 se aplica a cualquier superficie en la que se produzcan señales TCF. Los editores que publican una actualización web e ignoran sus apps de CTV o móvil crean un entorno híbrido no conforme.

Conclusión

TCF v2.3 no es una ruptura disruptiva con v2.2, pero sí un endurecimiento significativo de las normas que mantienen unido el ecosistema programático europeo. La dirección es clara: más transparencia, menos dark patterns, un control de usuario más granular y menos tolerancia a los casos límite que antes se colaban. Las CMPs y los editores que traten v2.3 como un simple parche rápido acabarán de nuevo ante el regulador. Quienes aprovechen la migración para limpiar la UX de la segunda capa, abandonar atajos basados en interés legítimo y reconstruir un flujo de consentimiento con verdadera igualdad de prominencia saldrán de esta etapa con un inventario que realmente se transa en la era v2.3 y con una postura de consentimiento capaz de resistir lo que traiga v2.4.