Den korte version

TCF v2.3 er en videreudvikling af v2.2, ikke en re-arkitektur. TC String-formatet er kompatibelt, eksisterende formål og funktioner er bevaret, og de fleste UI-krav rettet mod udgivere videreføres uændret. De væsentlige ændringer er koncentreret om fire områder:

• Tydeligere regler for, hvordan CMPs skal præsentere leverandøroplysninger og opbevaringsperioder.
• Nye krav til granulære kontroller i andet lag, som tilsynsmyndigheder har krævet siden den belgiske DPA-afgørelse i 2022.
• Strammere policy-håndhævelse omkring dark patterns, lige fremhævelse og forudafkrydsede valg.
• Justeringer af Global Vendor List (GVL)-skemaet og flowet for leverandørinformation.

Hvorfor v2.3 findes

Hver TCF-version er et kompromis mellem tre målgrupper: udgivere, som skal kunne blive ved med at tjene penge, leverandører, som har brug for et stabilt teknisk interface, og tilsynsmyndigheder, som vedvarende finder konkrete compliance-huller. v2.3 er et direkte svar på tre presfaktorer:

1. Håndhævelsessager mod overforbrug af "legitimate interest" under v2.2. Flere europæiske DPAs mente, at alt for mange leverandører gjorde krav på LI til formål, hvor kun samtykke faktisk var lovligt. v2.3 skærper leverandørernes forpligtelse til at oplyse retsgrundlag og løfter disse oplysninger tydeligere frem i samtykke-UI'et.
2. Vedvarende klager over dark patterns. De opdaterede Policies gør reglen om lige fremhævelse mere eksplicit og lukker smuthuller omkring forudafkrydsede toggles på andet lag.
3. Driftserfaringer fra store CMPs og udgivere. v2.2 introducerede flere obligatoriske oplysninger, som var svære at implementere elegant på mobile enheder og CTV. v2.3 strømliner sættet af obligatoriske oplysninger og tillader, at mere af det placeres i et lagdelt view.

TC String-kompatibilitet

Selve TC String forbliver bagudkompatibel. En v2.3 CMP producerer strenge, som v2.2-leverandører kan læse, og en v2.3-leverandør kan fortolke v2.2-strenge i overgangsperioden. Versionsindikatoren i strengens kernesegment angiver, hvilken policy-version CMP'en hævder at overholde, og GVL-versionsmarkøren bevæger sig uafhængigt fremad.

Praktisk betyder det: du behøver ikke opgradere alle leverandører på samme tid, og du behøver ikke tvinge en ny samtykkehandling igennem for hver bruger den dag, du implementerer v2.3. En trinvis udrulning er eksplicit understøttet.

Vigtige tekniske ændringer

1. Leverandøroplysning og opbevaring

v2.3 kræver, at CMPs viser hver enkelt leverandørs angivne opbevaringsperiode for data i det lagdelte UI, ikke kun i en separat leverandørliste. Opbevaringsværdien har altid været en del af GVL, men v2.2 krævede ikke, at brugere så den side om side med formålene. v2.3 lukker dette hul, fordi tilsynsmyndigheder argumenterede for, at brugere ikke kunne træffe et informeret valg uden at vide, hvor længe deres data vil blive opbevaret.

2. Strengere kontroller i andet lag

På andet lag — "administrér præferencer"-viewet — er v2.3 tydelig om, at toggles for ikke-essentielle formål og leverandører som udgangspunkt skal være slukket. Forudafkrydsede felter eller forudaktiverede sliders er en policy-overtrædelse, selv hvis brugeren aldrig eksplicit klikker på "acceptér". CMPs, der tidligere har anvendt et "soft opt-in"-mønster, skal gentegne andet lag.

3. Håndhævelse af lige fremhævelse

Reglen om lige fremhævelse har eksisteret siden v2.1, men v2.3 definerer den med mindre fortolkningsrum: Kontrollen "afvis alle" skal være på samme lag, have samme visuelle tyngde, samme farvekontrastklasse og samme interaktionsafstand som "acceptér alle". At gemme afvisning bag et link, en mindre knap eller en sekundær skærm er nu en eksplicit compliance-fejl snarere end et skønsspørgsmål.

4. Signallering af legitimate interest

Leverandører, der angiver legitimate interest som retsgrundlag under v2.3, skal nu også angive, hvilke formål de har foretaget en vurdering af, og for hvilke de har gennemført en Legitimate Interests Assessment. CMPs er forpligtet til at videreføre denne erklæring til brugergrænsefladen, så brugerne kan gøre indsigelse på et oplyst grundlag. I praksis betyder det, at "gør indsigelse"-flowet nu viser leverandørspecifik LIA-status i stedet for en generisk toggle.

5. Opdateringer af GVL-skemaet

Global Vendor List-skemaet tilføjer felter for granularitet af opbevaring, LIA-status og et maskinlæsbart link til den del af hver leverandørs privatlivspolitik, der vedrører de angivne formål. CMPs, der cacher GVL, skal opdatere deres skemaparser, så den forstår de nye felter, før der peges på en v2.3 GVL.

Policy-ændringer, der påvirker UX

TCF er både en teknisk specifikation og et sæt Policies. Flere af policy-ændringerne i v2.3 rammer direkte ned i samtykke-UI'et:

• Ikke mere "fortsæt uden at acceptere" som ækvivalent til afvis, medmindre det visuelt matcher accept-knappen og producerer den samme TC String, som et fuldt afslag ville gøre.
• Sproglig paritet — samtykkemeddelelsen skal være tilgængelig på alle de sprog, som selve sitet er tilgængeligt på, ikke kun brugerens browsersprog. CMPs skal understøtte tilsidesættelse af lokalitet.
• Vedvarende adgang — brugere skal kunne tilgå præferencecenteret fra alle sider på sitet, ikke kun landingssiden, og adgangslinket skal være mærket på en måde, som en ikke-ekspert vil genkende som samtykkerelateret.

Hvad udgivere skal gøre

1. Bekræft din CMP-leverandørs v2.3-understøttelse. Bed om den præcise dato, hvor deres v2.3-certificerede build vil være tilgængelig, og hvilken versionsstreng den vil rapportere.
2. Frisk din GVL-cachelogik op. Hvis du selv hoster et GVL-spejl, skal du opdatere skemaparseren, inden v2.3 GVL'en rulles ud, ellers vil din CMP ikke kunne validere nye leverandører.
3. Omskriv dit UI i andet lag, så alle toggles som standard er slukket, lige fremhævelse håndhæves visuelt, og opbevaringsperioder vises side om side med formål.
4. Gennemfør en ny compliance-gennemgang. De letteste regulatoriske "sejre" er dark-pattern-overtrædelser, som v2.3 nu udpeger eksplicit. Ret dem, inden din næste håndhævelsesgennemgang.
5. Planlæg en strategi for genanmodning om samtykke. Selvom TC String er bagudkompatibel, opfordrer Policies udgivere til at indhente samtykke på ny, når omfanget eller oplysningen om behandlingen ændrer sig væsentligt. Afgør, om din v2.3-udrulning er "væsentlig" for din målgruppe.

Hvad leverandører skal gøre

1. Gennemfør en Legitimate Interests Assessment for hvert formål, hvor du angiver LI, og indsend resultatet til GVL.
2. Opdater din GVL-post med v2.3-skemaets felter: granularitet af opbevaring, LIA-erklæring og deep link til privatlivspolitikken.
3. Validér din TC String-parser mod v2.3-referencetrengene leveret af IAB Europe.
4. Koordiner med dine CMP-partnere om en fælles overgangsdato, så den første købsanmodning med en v2.3-streng ikke lander hos en leverandør, der kun understøtter v2.2.

Typiske faldgruber ved migration

• At behandle v2.3 som en mulighed for UI-redesign. Det er fristende at pakke brand-opdateringer ind i v2.3-udrulningen, men det gør compliance-test mere kompliceret. Udgiv først en v2.3-release med fokus alene på compliance, og iterér derefter på designet.
• At overse kravet om visning af opbevaring. Teams opdaterer ofte visningen af leverandørliste, men glemmer, at opbevaring nu også skal vises i det lagdelte view for hvert enkelt formål.
• At antage, at TC String er nok. En compliant streng, produceret af et ikke-compliant UI, er stadig ikke-compliant. Tilsynsmyndigheder har gentagne gange givet bøder til aktører, hvis strenge så fine ud, men hvis bannere skjulte afvis-knappen.
• At udelade CTV og mobile fra omfanget. v2.3 gælder alle flader, hvor TCF-signaler produceres. Udgivere, der udsender en webopdatering og ignorerer deres CTV- eller mobilapps, skaber et hybridt, ikke-compliant miljø.

Konklusion

TCF v2.3 er ikke et disruptivt brud med v2.2, men det er en reel stramning af de regler, der holder det europæiske programmatic-økosystem sammen. Retningen er tydelig: mere gennemsigtighed, færre dark patterns, mere granulær bruger-kontrol og mindre tolerance for gråzonetilfælde, der tidligere kunne glide igennem. CMPs og udgivere, der behandler v2.3 som en hurtig patch, vil hurtigt stå over for tilsynsmyndigheden igen. Dem, der bruger migrationen til at rydde op i UX i andet lag, udfase genveje via legitimate interest og genopbygge et reelt flow med lige fremhævelse for samtykke, vil stå tilbage med inventory, der faktisk kan handles i v2.3-æraen — og en samtykkeprofil, der kan holde til, hvad end v2.4 fører med sig.