Resumo rápido

TCF v2.3 é unha evolución de v2.2, non unha re-arquitectura. O formato da TC String segue a ser compatible, mantéñense os propósitos e funcionalidades existentes e a maior parte dos requisitos de interface cara ao editor permanecen practicamente iguais. Os cambios relevantes concéntranse en catro áreas:

• Normas máis claras sobre como as CMPs deben presentar a información dos vendors e os períodos de retención.
• Novos requisitos para controles granulares na segunda capa que as autoridades veñen reclamando desde a decisión da DPA belga de 2022.
• Un enforcement de política máis estrito arredor dos dark patterns, a igualdade de prominencia e as opcións pre-marcadas.
• Axustes no esquema da Global Vendor List (GVL) e no fluxo de información ao usuario sobre os vendors.

Por que existe v2.3

Cada versión do TCF é unha negociación entre tres públicos: editores que necesitan seguir monetizando, vendors que precisan unha interface técnica estable e autoridades que van identificando lagoas concretas de cumprimento. v2.3 é unha resposta directa a tres tipos de presión:

1. Accións de enforcement contra o abuso de "lexítimo interese" baixo v2.2. Varias DPAs europeas concluíron que demasiados vendors se acollían ao LI para propósitos nos que en realidade só o consentimento era lícito. v2.3 endurece as obrigas de transparencia sobre a base xurídica que declaran os vendors e dálle máis visibilidade na interface de consentimento.
2. Reclamacións continuadas sobre dark patterns. As Policies actualizadas fan moito máis explícita a regra de igual prominencia e pechan lagoas arredor de toggles pre-marcados na segunda capa.
3. Feedback operativo de grandes CMPs e editores. v2.2 introduciu varias mencións obrigatorias difíciles de implementar de forma limpa en mobile e CTV. v2.3 simplifica o conxunto mínimo de información obrigatoria e permite que máis desa información viva nunha vista en capas.

Compatibilidade da TC String

A propia TC String mantense retrocompatible. Unha CMP v2.3 produce cadeas que os vendors v2.2 poden ler, e un vendor v2.3 pode consumir cadeas v2.2 durante o período de transición. O indicador de versión no segmento central da cadea identifica con que versión de Policies afirma cumprir a CMP, e o punteiro á versión da GVL avanza de forma independente.

Na práctica, isto significa que non é necesario actualizar todos os vendors ao mesmo tempo, nin obrigar a un novo evento de consentimento para cada usuario o día que se desprega v2.3. Un despregamento gradual está explicitamente soportado.

Cambios t��cnicos clave

1. Información de vendors e retención

v2.3 obriga as CMPs a mostrar o período de retención de datos que declara cada vendor na interface en capas, non só nunha lista de vendors separada. O valor de retención xa formaba parte da GVL, pero v2.2 non esixía que o usuario o vise xunto cos propósitos. v2.3 pecha esa lagoa porque as autoridades argumentaron que os usuarios non podían decidir de forma informada sen saber canto tempo se conservan os seus datos.

2. Controis máis estritos na segunda capa

Na segunda capa — a vista de "xestionar preferencias" — v2.3 establece de forma explícita que os toggles para propósitos e vendors non esenciais deben estar por defecto en off. As caixas pre-marcadas ou os deslizadores activados de orixe constitúen unha infracción das Policies aínda que o usuario nunca faga clic expresamente en "aceptar". As CMPs que se apoiaban nun patrón de "soft opt-in" terán que reconfigurar a segunda capa.

3. Enforcement da igualdade de prominencia

A regra de igualdade de prominencia existe desde v2.1, pero v2.3 defínea con moita menos marxe de interpretación: o control de "rexectar todo" debe estar na mesma capa, ter o mesmo peso visual, a mesma clase de contraste de cor e a mesma distancia de interacción que "aceptar todo". Agochar o rexeitamento detrás dunha ligazón, dun botón máis pequeno ou dunha pantalla secundaria pasa a ser explicitamente un incumprimento, non unha cuestión de criterio.

4. Sinalización do lexítimo interese

Os vendors que declaran o lexítimo interese como base xurídica baixo v2.3 deben indicar tamén que propósitos foron obxecto de avaliación e para cales completaron unha Legitimate Interests Assessment. As CMPs teñen a obriga de trasladar esta información á interface de usuario para que as persoas poidan opoñerse con toda a información relevante. Na práctica isto significa que o fluxo de "oposición" amosa agora o estado de LIA específico por vendor en lugar dun simple toggle xenérico.

5. Actualizacións do esquema da GVL

O esquema da Global Vendor List incorpora campos para a granularidade da retención, o estado de LIA e unha ligazón lexible por máquina á sección da política de privacidade de cada vendor relativa aos propósitos declarados. As CMPs que fan caché da GVL deben actualizar o seu parser de esquema para entender estes novos campos antes de apuntar a unha GVL v2.3.

Cambios de política que afectan á UX

O TCF é á vez unha especificación técnica e un conxunto de Policies. Varias das cambios de Policy en v2.3 impactan directamente na interface de consentimento:

• Fin de "continuar sen aceptar" como equivalente a rexeitar, salvo que sexa visualmente idéntico ao botón de aceptar e xere a mesma TC String que un rexeitamento total.
• Paridade lingüística: o aviso de consentimento debe estar dispoñible en todos os idiomas nos que estea dispoñible o propio sitio, non só no idioma do navegador do usuario. As CMPs deben permitir sobrescribir o locale.
• Acceso persistente: os usuarios deben poder acceder ao centro de preferencias desde calquera páxina do sitio, non só desde a páxina de entrada, e a ligazón de acceso debe estar etiquetada de forma que unha persoa non experta a recoñeza como relacionada co consentimento.

Que deben facer os editores

1. Confirmar o soporte de v2.3 do teu provedor de CMP. Pregunta pola data exacta na que estará dispoñible a build certificada para v2.3 e pola version string que reportará.
2. Actualizar a lóxica de caché da GVL. Se auto-aloxas algún espello da GVL, adapta o parser de esquema antes de que se publique a GVL de v2.3, ou a túa CMP non poderá validar vendors novos.
3. Reescribir a interface da segunda capa para que todos os toggles estean por defecto en off, a igualdade de prominencia se cumpra visualmente e os períodos de retención se mostren xunto cos propósitos.
4. Repetir a túa auditoría de cumprimento. As infraccións máis doadas de detectar para as autoridades son os dark patterns que v2.3 agora menciona expresamente. Arránxaos antes da túa próxima revisión de enforcement.
5. Planificar unha estratexia de re-prompt. Aínda que a TC String é retrocompatible, as Policies animan os editores a volver solicitar o consentimento cando o alcance ou a transparencia do tratamento cambien de maneira substancial. Decide se o teu despregamento de v2.3 constitúe un cambio "material" para a túa audiencia.

Que deben facer os vendors

1. Completar unha Legitimate Interests Assessment para cada propósito no que declares LI, e presentar o resultado na GVL.
2. Actualizar a túa entrada na GVL cos campos do esquema de v2.3: granularidade da retención, declaración de LIA e deep link á política de privacidade.
3. Validar o teu parser de TC String fronte ás cadeas de referencia de v2.3 fornecidas por IAB Europe.
4. Coordinar coas túas CMP partners unha data de cambio conxunta, para que a primeira petición de compra que leve unha cadea v2.3 non chegue a un vendor que só entenda v2.2.

Erros habituais na migración

• Tratar v2.3 como unha oportunidade para redeseñar a UI. É tentador mesturar cambios de marca co despregamento de v2.3, pero iso complica as probas de cumprimento. Lanza primeiro unha versión de v2.3 centrada só en compliance e, a partir de aí, itera no deseño.
• Esquecer o requisito de mostrar a retención. Os equipos adoitan actualizar a vista de lista de vendors pero esquecen que a retención agora tamén debe aparecer na vista en capas por propósito.
• Dar por feito que abonda coa TC String. Unha cadea formalmente correcta xerada por unha interface non conforme segue a ser non conforme. As autoridades xa impuxeron multas a operadores cuxas cadeas parecían válidas pero cuxas banners agochaban o botón de rexeitar.
• Deixar CTV e mobile fóra de ámbito. v2.3 aplícase a calquera superficie na que se xeren sinais TCF. Os editores que actualizan a web pero ignoran as súas apps de CTV ou mobile acaban cun entorno híbrido non conforme.

Conclusión

TCF v2.3 non é unha ruptura disruptiva con v2.2, pero si supón un endurecemento relevante das regras que manteñen unido o ecosistema programático europeo. A dirección é clara: máis transparencia, menos dark patterns, máis control granular para o usuario e menos tolerancia cos casos límite que antes pasaban desapercibidos. As CMPs e editores que traten v2.3 como un simple parche volverán axiña fronte ao regulador. Quen aproveite a migración para limpar a UX da segunda capa, abandonar atallos baseados en lexítimo interese e reconstruír un fluxo de consentimento con verdadeira igualdade de prominencia sairá desta etapa cun inventario que realmente funcionará na era v2.3 — e cunha postura de consentimento preparada para sobrevivir ao que veña despois con v2.4.