La versió breu

TCF v2.3 és una evolució de v2.2, no una rearquitectura. El format de la TC String és compatible, les finalitats i funcionalitats existents es mantenen, i la majoria dels requisits d’UI de cara a l’editor continuen sense canvis. Els canvis significatius se centren en quatre àrees:

• Normes més clares sobre com les CMPs han de presentar la informació dels venedors i els períodes de retenció.
• Nous requisits per a controls granulars a la segona capa que les autoritats reguladores demanen des de la decisió de l’Autoritat belga de protecció de dades (DPA) del 2022.
• Un enduriment de l’aplicació de les Policies respecte als dark patterns, la igual prominència i les opcions pre-marcades.
• Ajustos a l’esquema de la Global Vendor List (GVL) i al flux de divulgació dels venedors.

Per què existeix la v2.3

Cada versió del TCF és una negociació entre tres audiències: editors que necessiten continuar monetitzant, venedors que necessiten una interfície tècnica estable i reguladors que continuen trobant buits concrets de compliment. La v2.3 és una resposta directa a tres pressions:

1. Actuacions d’execució contra l’abús de la “legitimate interest” sota v2.2. Diverses DPAs europees van considerar que massa venedors invocaven LI per a finalitats en què, en realitat, només el consentiment era lícit. La v2.3 endurix les exigències de transparència sobre la base jurídica que declara cada venedor i la fa aparèixer abans a la interfície de consentiment.
2. Queixes constants sobre dark patterns. Les Policies actualitzades fan que la norma de igual prominència sigui més explícita i tanquen escletxes al voltant de commutadors pre-marcats a la segona capa.
3. Feedback operatiu de grans CMPs i editors. La v2.2 va introduir diverses obligacions de divulgació difícils d’implementar de manera neta en entorns mòbils i CTV. La v2.3 optimitza el conjunt de divulgacions obligatòries i permet que una part més gran visqui en una vista en capes.

Compatibilitat de la TC String

La TC String en si continua sent compatible cap enrere. Una CMP v2.3 produeix cadenes que els venedors v2.2 poden llegir, i un venedor v2.3 pot consumir cadenes v2.2 durant el període de transició. L’indicador de versió al segment central de la cadena identifica amb quina versió de Policies afirma complir la CMP, i el punter de versió de la GVL avança de manera independent.

En la pràctica, això significa que no cal actualitzar tots els venedors al mateix temps, ni forçar un nou esdeveniment de consentiment a tots els usuaris el dia que desplegueu la v2.3. Un desplegament esglaonat està explícitament suportat.

Canvis tècnics clau

1. Divulgació dels venedors i retenció

La v2.3 requereix que les CMPs mostrin el període de retenció de dades declarat per cada venedor a la interfície en capes, no només en una llista de venedors separada. El valor de retenció sempre ha format part de la GVL, però la v2.2 no obligava a mostrar-lo als usuaris al costat de les finalitats. La v2.3 tanca aquesta bretxa perquè els reguladors van argumentar que els usuaris no podien prendre una decisió informada sense saber durant quant de temps es conservarien les seves dades.

2. Controls més estrictes a la segona capa

A la segona capa — la vista de "gestiona les preferències" — la v2.3 és explícita: els commutadors per a finalitats i venedors no essencials han d’estar per defecte en posició off. Les caselles pre-marcades o els lliscadors pre-activats constitueixen una infracció de les Policies encara que l’usuari no faci clic explícitament a "accepta". Les CMPs que fins ara es basaven en un patró de "soft opt-in" hauran de tornar a representar la segona capa.

3. Execució de la igual prominència

La norma de igual prominència existeix des de la v2.1, però la v2.3 la defineix amb menys marge d’interpretació: el control de "rebutja-ho tot" ha d’estar en la mateixa capa, amb el mateix pes visual, la mateixa classe de contrast de color i la mateixa distància d’interacció que "accepta-ho tot". Amagar el rebuig darrere d’un enllaç, un botó més petit o una pantalla secundària ara és clarament un incompliment, no una qüestió de criteri.

4. Senyalització de la legitimate interest

Els venedors que declarin la legitimate interest com a base jurídica sota la v2.3 han d’indicar també per a quines finalitats han fet l’avaluació i per a quines han completat una Legitimate Interests Assessment. Les CMPs estan obligades a traslladar aquesta informació a la interfície d’usuari perquè els usuaris puguin oposar-s’hi amb tota la informació disponible. En la pràctica, això significa que el flux d’"oposició" ara mostra l’estat de LIA específic de cada venedor, en lloc d’un commutador genèric.

5. Actualitzacions de l’esquema de la GVL

L’esquema de la Global Vendor List afegeix camps per a la granularitat de retenció, l’estat de LIA i un enllaç llegible per màquina a la secció de la política de privacitat de cada venedor relativa a les finalitats declarades. Les CMPs que facin caché de la GVL han d’actualitzar el seu analitzador d’esquemes per entendre els nous camps abans d’apuntar a una GVL v2.3.

Canvis de Policies que afecten l’UX

El TCF és alhora una especificació tècnica i un conjunt de Policies. Diversos canvis de Policies a la v2.3 incideixen directament en la interfície de consentiment:

• Fi de "continua sense acceptar" com a equivalent de rebuig tret que visualment coincideixi amb el botó d’acceptació i generi la mateixa TC String que un rebuig complet.
• Paritat lingüística — l’avís de consentiment ha d’estar disponible en totes les llengües en què estigui disponible el lloc, no només en la llengua del navegador de l’usuari. Les CMPs han de permetre la substitució manual de la configuració regional.
• Accés persistent — els usuaris han de poder accedir al centre de preferències des de qualsevol pàgina del lloc, no només des de la pàgina d’aterratge, i l’enllaç d’accés s’ha d’etiquetar de manera que un usuari no expert el reconegui com relacionat amb el consentiment.

Què han de fer els editors

1. Confirmar el suport v2.3 del vostre proveïdor de CMP. Demaneu la data exacta en què estarà disponible la seva versió certificada v2.3 i quina versió indicarà.
2. Actualitzar la lògica de caché de la GVL. Si allotgeu vosaltres mateixos algun mirall de la GVL, actualitzeu l’analitzador d’esquemes abans que es desplegui la GVL v2.3, o la vostra CMP no podrà validar els venedors nous.
3. Reescriure la vostra UI de segona capa de manera que tots els commutadors estiguin per defecte apagats, la igual prominència sigui visualment evident i els períodes de retenció es mostrin al costat de les finalitats.
4. Tornar a passar l’auditoria de compliment. Les infraccions més fàcilment detectables per les autoritats són els dark patterns que la v2.3 ara assenyala explícitament. Corregiu-los abans de la propera revisió d’execució.
5. Planificar una estratègia de re-prompt. Tot i que la TC String és compatible cap enrere, les Policies encoratgen els editors a tornar a sol·licitar consentiment quan l’abast o la divulgació del tractament canviïn de manera substancial. Decidiu si el vostre desplegament de v2.3 qualifica com a "substancial" per a la vostra audiència.

Què han de fer els venedors

1. Completar una Legitimate Interests Assessment per a cada finalitat on declareu LI, i enviar-ne el resultat a la GVL.
2. Actualitzar la vostra entrada a la GVL amb els camps de l’esquema v2.3: granularitat de retenció, declaració de LIA i deep link a la política de privacitat.
3. Validar el vostre analitzador de TC String amb les cadenes de referència v2.3 proporcionades per IAB Europe.
4. Coordinar-vos amb els vostres socis CMP en una data de canvi compartida, de manera que la primera petició de compra que porti una cadena v2.3 no arribi a un venedor que només entén v2.2.

Error comuns en la migració

• Tractar la v2.3 com una oportunitat de redisseny d’UI. És temptador agrupar actualitzacions de marca amb el desplegament de la v2.3, però això complica les proves de compliment. Publiqueu primer una versió v2.3 només de compliment i, després, itereu en el disseny.
• Passar per alt el requisit de mostrar la retenció. Sovint els equips actualitzen la vista de llista de venedors però obliden que la retenció ara també ha d’aparèixer a la vista en capes per finalitat.
• Assumir que la TC String és suficient. Una cadena conforme produïda per una UI no conforme continua sent no conforme. Les autoritats han multat reiteradament operadors amb cadenes aparentment correctes però amb banners que amagaven el botó de rebuig.
• Deixar la CTV i el mòbil fora de l’abast. La v2.3 s’aplica a qualsevol superfície on es produeixin senyals TCF. Els editors que actualitzen el web però ignoren les aplicacions CTV o mòbils creen un entorn híbrid no conforme.

Conclusió

TCF v2.3 no és una ruptura disruptiva amb v2.2, però sí un enduriment significatiu de les normes que sostenen l’ecosistema programàtic europeu. La direcció és clara: més transparència, menys dark patterns, més control granular per a l’usuari i menys tolerància cap als casos límit que abans passaven desapercebuts. Les CMPs i els editors que tractin la v2.3 com un simple pedaç es tornaran a trobar davant del regulador. Aquells que aprofitin la migració per netejar la UX de la segona capa, retirar dreceres basades en legitimate interest i reconstruir un flux de consentiment amb una igual prominència real sortiran de l’altra banda amb inventari que realment es podrà negociar a l’era v2.3 — i amb una posició de consentiment que sobreviurà al que sigui que porti la v2.4.