De korte versie

TCF v2.3 is een evolutie van v2.2, geen heropzet. Het TC String-formaat is compatibel, bestaande doeleinden en functies blijven behouden, en de meeste UI-vereisten voor uitgevers blijven ongewijzigd. De betekenisvolle wijzigingen concentreren zich op vier gebieden:

• Duidelijkere regels over hoe CMP's leveranciersinformatie en bewaartermijnen moeten presenteren.
• Nieuwe eisen voor granulaire tweede-laagsbedieningen die toezichthouders al eisen sinds het Belgische DPA-besluit van 2022.
• Strengere handhaving van het beleid rond dark patterns, gelijke prominentie en vooraf aangevinkte opties.
• Aanpassingen aan het schema van de Global Vendor List (GVL) en de vendor-disclosure-flow.

Waarom v2.3 bestaat

Elke TCF-versie is een onderhandeling tussen drie doelgroepen: uitgevers die moeten blijven monetiseren, leveranciers die een stabiele technische interface nodig hebben, en toezichthouders die steeds specifieke compliancehiaten blijven vinden. v2.3 is een direct antwoord op drie druklijnen:

1. Handhavingsacties tegen overmatig gebruik van “gerechtvaardigd belang” onder v2.2. Meerdere Europese DPA's oordeelden dat te veel leveranciers LI claimden voor doeleinden waarvoor alleen toestemming werkelijk rechtmatig was. v2.3 scherpt de door de leverancier opgegeven verklaringen over de rechtsgrondslag aan en toont deze eerder in de consent-UI.
2. Aanhoudende klachten over dark patterns. Het bijgewerkte beleid maakt de regel van gelijke prominentie explicieter en sluit mazen rond vooraf aangevinkte togglebuttons op de tweede laag.
3. Operationele feedback van grote CMP's en uitgevers. v2.2 introduceerde verschillende verplichte openbaarmakingen die moeilijk netjes te implementeren waren op mobiel en CTV. v2.3 stroomlijnt de verplichte openbaarmakingsset en staat toe dat meer ervan in een gelaagde weergave bestaat.

TC String-compatibiliteit

De TC String zelf blijft achterwaarts compatibel. Een v2.3-CMP produceert strings die v2.2-leveranciers kunnen lezen, en een v2.3-leverancier kan v2.2-strings verwerken tijdens de overgangsperiode. De versie-indicator in het kernsegment van de string identificeert met welke beleidsversie de CMP beweert te voldoen, en de GVL-versie-aanwijzer beweegt onafhankelijk vooruit.

Wat dit praktisch betekent: je hoeft niet elke leverancier tegelijkertijd bij te werken, en je hoeft geen nieuwe toestemmingsgebeurtenis af te dwingen bij elke gebruiker op de dag dat je v2.3 uitrolt. Een gefaseerde uitrol wordt expliciet ondersteund.

Belangrijkste technische wijzigingen

1. Openbaarmaking en bewaring van leveranciers

v2.3 vereist dat CMP's de door elke leverancier opgegeven bewaartermijn voor gegevens in de gelaagde UI tonen, niet alleen in een afzonderlijke leverancierslijst. De bewaarwaarde maakte altijd deel uit van de GVL, maar v2.2 schreef niet voor dat gebruikers deze naast de doeleinden te zien kregen. v2.3 dicht dat gat omdat toezichthouders stelden dat gebruikers geen geïnformeerde keuze konden maken zonder te weten hoe lang hun gegevens zouden blijven bestaan.

2. Strengere bedieningen op de tweede laag

Op de tweede laag — de weergave “voorkeuren beheren” — is v2.3 expliciet dat toggles voor niet-essentiële doeleinden en leveranciers standaard uit moeten staan. Vooraf aangevinkte vakjes of vooraf ingeschakelde schuifregelaars zijn een beleidsovertreding, zelfs als de gebruiker nooit expliciet op “accepteren” klikt. CMP's die eerder vertrouwden op een “soft opt-in”-patroon zullen de tweede laag opnieuw moeten weergeven.

3. Handhaving van gelijke prominentie

De regel van gelijke prominentie bestaat sinds v2.1, maar v2.3 definieert hem met minder interpretatieruimte: de “alles afwijzen”-bediening moet zich op dezelfde laag bevinden, met hetzelfde visuele gewicht, dezelfde kleurcontrastklasse en dezelfde interactie-afstand als “alles accepteren”. Afwijzen verbergen achter een link, een kleinere knop of een secundair scherm is nu een expliciete compliance-fout in plaats van een oordeel.

4. Signalering van gerechtvaardigd belang

Leveranciers die onder v2.3 gerechtvaardigd belang als rechtsgrondslag verklaren, moeten nu ook verklaren welke doeleinden ze hebben beoordeeld en voor welke ze een Legitimate Interests Assessment hebben afgerond. CMP's moeten deze verklaring doorgeven aan de gebruikersinterface zodat gebruikers met volledige informatie bezwaar kunnen maken. In de praktijk betekent dit dat de “bezwaar”-flow nu een leverancier-specifieke LIA-status toont in plaats van een generieke toggle.

5. Updates van het GVL-schema

Het schema van de Global Vendor List voegt velden toe voor bewaargranulariteit, LIA-status en een machineleesbare link naar de sectie van het privacybeleid van elke leverancier voor de opgegeven doeleinden. CMP's die de GVL cachen, moeten hun schema-parser vernieuwen om de nieuwe velden te begrijpen voordat ze naar een v2.3-GVL wijzen.

Beleidswijzigingen die de UX beïnvloeden

Het TCF is zowel een technische specificatie als een set van Policies. Verschillende v2.3-beleidswijzigingen landen direct op de consent-UI:

• Geen “doorgaan zonder te accepteren” meer als afwijzingsequivalent tenzij het visueel overeenkomt met de acceptatieknop en dezelfde TC String produceert als een volledige afwijzing zou doen.
• Taalpariteit — de toestemmingsmelding moet beschikbaar zijn in elke taal waarin de site zelf beschikbaar is, niet alleen in de browsertaal van de gebruiker. CMP's moeten locale-override ondersteunen.
• Permanente toegang — gebruikers moeten het voorkeurcentrum kunnen bereiken vanaf elke pagina van de site, niet alleen de landingspagina, en de toegangslink moet zodanig gelabeld zijn dat een niet-deskundige gebruiker hem herkent als toestemmingsgerelateerd.

Wat uitgevers moeten doen

1. Bevestig de v2.3-ondersteuning van je CMP-leverancier. Vraag om de exacte datum waarop hun v2.3-gecertificeerde build beschikbaar zal zijn en de versiestring die hij zal rapporteren.
2. Ververs je GVL-cachelogica. Als je zelf een GVL-mirror host, werk dan de schema-parser bij voordat de v2.3-GVL wordt uitgerold, anders zal je CMP er niet in slagen nieuwe leveranciers te valideren.
3. Herschrijf je tweede-laags-UI zodat elke toggle standaard uit staat, gelijke prominentie visueel wordt afgedwongen, en bewaartermijnen naast doeleinden worden getoond.
4. Voer je compliance-audit opnieuw uit. De gemakkelijkste regelgevende overwinningen zijn dark-pattern-overtredingen die v2.3 nu expliciet benoemt. Los ze op vóór je volgende handhavingsbeoordeling.
5. Plan een herprompt-strategie. Hoewel de TC String achterwaarts compatibel is, moedigen de Policies uitgevers aan om opnieuw toestemming te vragen wanneer de scope of openbaarmaking van de verwerking materieel verandert. Beslis of jouw v2.3-uitrol voor jouw publiek als “materieel” kwalificeert.

Wat leveranciers moeten doen

1. Voltooi een Legitimate Interests Assessment voor elk doeleinde waarvoor je LI verklaart, en dien het resultaat in bij de GVL.
2. Werk je GVL-vermelding bij met de v2.3-schemavelden: bewaargranulariteit, LIA-verklaring en de privacybeleid-deeplink.
3. Valideer je TC String-parser tegen de v2.3-referentiestrings die door IAB Europe worden verstrekt.
4. Coördineer met je CMP-partners over een gedeelde cutover-datum, zodat het eerste koperverzoek met een v2.3-string niet bij een enkel-v2.2-leverancier landt.

Veelvoorkomende migratievalkuilen

• v2.3 behandelen als een kans om de UI opnieuw te ontwerpen. Het is verleidelijk om merkupdates te bundelen met de v2.3-uitrol, maar dat bemoeilijkt compliancetests. Lever eerst een v2.3-release die zich uitsluitend op compliance richt, en itereer daarna op het ontwerp.
• De weergave-eis voor bewaring missen. Teams werken vaak de leverancierslijstweergave bij, maar vergeten dat bewaring nu ook moet verschijnen in de gelaagde weergave per doeleinde.
• Aannemen dat de TC String genoeg is. Een conforme string geproduceerd door een niet-conforme UI is nog steeds niet-conform. Toezichthouders hebben herhaaldelijk operators beboet wier strings er prima uitzagen maar wier banners de afwijsknop verborgen.
• CTV en mobiel buiten scope laten. v2.3 is van toepassing op elk oppervlak waar TCF-signalen worden geproduceerd. Uitgevers die een web-update uitbrengen en hun CTV- of mobiele apps negeren, creëren een hybride niet-conforme omgeving.

Conclusie

TCF v2.3 is geen disruptieve breuk met v2.2, maar het is een betekenisvolle aanscherping van de regels die het Europese programmatische ecosysteem bijeenhouden. De reisrichting is duidelijk: meer transparantie, minder dark patterns, meer granulaire gebruikerscontrole en minder tolerantie voor de randgevallen die er vroeger doorheen glipten. CMP's en uitgevers die v2.3 behandelen als een snelle patch zullen zich weer voor de toezichthouder bevinden. Degenen die de migratie gebruiken om de tweede-laags-UX op te schonen, snelkoppelingen van gerechtvaardigd belang af te schaffen en een echte consent-flow met gelijke prominentie opnieuw op te bouwen, komen er aan de andere kant uit met inventaris die daadwerkelijk afloopt in het v2.3-tijdperk — en met een consent-houding die zal overleven wat v2.4 hierna ook brengt.