IAB TCF v2.4: Hvad CMPs skal ændre inden oktober 2026

IAB TCF v2.4 har nu en bekræftet udrulningsplan. IAB Europe planlægger at offentliggøre de endelige tekniske specifikationer og den opdaterede Global Vendor List (GVL) den 23. juli 2026. CMPs har herefter frem til den 23. oktober 2026 for webimplementeringer og den 23. februar 2027 for mobilapp- og connected TV-miljøer. Hvis din samtykkestak deltager i TCF, er dette et implementeringsprojekt – ikke blot en opdatering af bannerteksten.

Ændringerne spænder over TCF Policy v5.0.b og Technical Specifications v2.4. De påvirker, hvordan CMPs forklarer Features, oplyser om rækkevidden af et valg, understøtter samtykke på tværs af enheder, og koder en snæver signaleringscase for leverandører. For baggrundsinformation om den nuværende ramme, se Conzents IAB TCF compliance-oversigt.

Vigtigste pointer

De bekræftede datoer giver CMPs og udgivere en kort, men håndterbar rækkefølge: gennemgå den endelige pakke i juli, afslut webændringer i oktober, og hold mobil og CTV på en separat februarplan. De vigtigste punkter er:

• 23. juli 2026: IAB Europe planlægger at offentliggøre Technical Specifications v2.4 og den tilhørende GVL-opdatering.
• 23. oktober 2026: CMPs skal implementere de nye oplysninger i webmiljøer.
• 23. februar 2027: den tilsvarende deadline gælder for mobilapp- og CTV-miljøer.
• CMP-brugerflader skal have klarere standardforklaringer og illustrationer til Features.
• Det første lag skal fortælle brugerne, om et valg er servicespecifikt, gruppespecifikt eller på tværs af enheder.
• Den tekniske forhåndsvisning fjerner en forældet omgåelse af legitim interesse for leverandører, der kun erklærer Særlige Formål; teams bør bekræfte den endelige ordlyd den 23. juli.
• TCF-deltagelse understøtter compliancearbejde, men erstatter ikke en udgivers eller leverandørs egne juridiske vurderinger.

De tre datoer, der skal ind i din leveringsplan

IAB Europes bekræftelse dateret 16. juli 2026 fastsætter tre separate milepæle. At behandle dem som én deadline ville komprimere opdagelse, implementering, oversættelse og QA i det samme udgivelsesvindue.

Den praktiske rækkefølge er:

1. 23. juli 2026 — offentliggørelse af specifikation og GVL. Download de endelige filer, sammenlign dem med det offentligt kommenterede materiale, og gør hver bekræftet forskel til en ejet opgave.
2. 23. oktober 2026 — webdeadline. Produktions-web-CMPs bør vise de nye oplysninger og følge de endelige v2.4-signaleringsregler.
3. 23. februar 2027 — app- og CTV-deadline. Native SDK'er, lanceringsstorenes leveringstider, tv-brugerflader og enhedsspecifik tilgængelighedstestning får en senere dato, ikke en fritagelse.

Perioden mellem offentliggørelse og webdeadlinen er tre måneder. Det er nok til en kontrolleret opdatering, hvis teams starter med en specifikationsdiff og en testmatrix. Det er stramt, hvis arbejdet begynder med et sent bannerredesign.

Den bekræftede rækkefølge adskiller kildematerialet, webimplementeringen og app/CTV-udrulningen. Planlæg og test dem som tre milepæle frem for én lancering.

Hvem skal handle – og hvem bør stadig følge med

Deadlinerne gælder for live TCF-implementeringer og de CMPs, der er ansvarlige for dem. De officielle TCF Policies dækker både kommercielle CMPs, der betjener kunder, og private CMPs, der drives af en udgiver til egne digitale ejendomme. Udgivere er fortsat ansvarlige for den rammebetingede brugerflade, der præsenteres på deres digitale ejendomme, selv når en tredjepart leverer CMP'en.

Du bør sætte dette arbejde på en leveringsplan, hvis du:

• bygger eller driver en registreret TCF-CMP;
• bruger en kommerciel CMP på et website finansieret af programmatisk annoncering;
• vedligeholder en privat udgiver-CMP;
• leverer den samme samtykke­oplevelse på tværs af web, app og CTV;
• er afhængig af TCF-signaler til leverandører, bud, måling eller personaliserede annoncer.

Et website, der ikke deltager i TCF, er ikke automatisk forpligtet til at implementere TCF v2.4. Det kan stadig have brug for en gyldig samtykkemekanisme i henhold til gældende lovgivning eller platformregler. Framework-versionen og den juridiske pligt til at indhente samtykke er relaterede spørgsmål, men ikke det samme spørgsmål.

Denne sondring er vigtig for Googles udgiversprodukter. Google kræver en certificeret CMP integreret med TCF for personaliserede annoncer, der leveres via AdSense, Ad Manager eller AdMob til brugere i EØS, UK og Schweiz. Google anfører desuden, at dens certificeringsgennemgang ikke kontrollerer fuld overholdelse af TCF eller gældende privatlivslovgivning.

Hvad brugerne vil opleve anderledes i en CMP

Den mest synlige ændring er en indsats for at forklare Features mere tydeligt. I TCF beskriver et Formål, hvorfor data behandles, og giver brugeren en samtykke- eller indsigelses­mulighed, hvor det er relevant. En Feature beskriver en behandlingsmetode, der bruges til at forfølge et eller flere Formål; den medfører ikke en separat brugerkontrol på samme måde.

Under Policy v5.0.b og den bekræftede GVL-opdatering skal CMPs tage højde for:

• et nyt standardTexts-felt med standardforklaringen til Features;
• illustrationer til hver Feature i den opdaterede GVL;
• standardforklaringen til Feature vist med standardnavnet og den fulde brugervenlige tekst;
• Feature-information, der ikke er visuelt forbundet med kontroller, som faktisk ikke kan deaktivere Feature'n;
• et nyt navn og vejledning til Special Feature 2.

Det opdaterede navn til Special Feature 2 er "Identificer enheder baseret på aktivt anmodet information." Policyens vejledning dækker eksplicit egenskaber indsamlet via JavaScript eller API'er – såsom skrifttyper, skærmopløsning og plugins – samt information, der aktivt anmodes via User-Agent Client Hints. Brugere skal give samtykke, før en leverandør anvender denne Special Feature.

Hvorfor dette er mere end en tekstopdatering

En CMP, der hardkoder labels eller forudsætter den gamle GVL-struktur, kan fejle, selv om banneret stadig ser normalt ud. Produktteams skal spore de nye data fra indsætning til hvert UI-lag, oversættelse, tilgængeligheds­label, cachet leverandørpost og regressionstest. Det sikre designprincip er enkelt: gengivelse af den officielle betydning præcist, gør tilstedeværelsen eller fraværet af et brugervalg umiskendeligt, og undlad at gøre en forklarende Feature til et falsk skifteknap.

Samtykke på tværs af enheder kræver et eksplicit omfang

Policy v5.0.b tilføjer omfang på tværs af enheder til rammeværkets definitioner. Et retsgrundlag kan gælde på tværs af adgangspunkter for den samme tjeneste eller gruppe – for eksempel et website og en mobilapp brugt af en autentificeret konto – når implementeringen understøtter dette omfang. Det første lag i rammebrugerfladen skal fortælle brugeren, om samtykkvalget er servicespecifikt, gruppespecifikt og/eller gælder på tværs af enheder.

Denne bekvemmelighed medfører et produktansvar. En CMP har brug for en defineret måde at løse et valg truffet på en enhed inden login op imod præferencer, der allerede er gemt på kontoen. Den skal også holde afvisning og tilbagekaldelse lige så tilgængeligt som accept inden for det samme omfang.

CNILs anbefalinger fra januar 2026 om samtykke på tværs af enheder er fransk myndighedsvejledning snarere end en EU-dækkende TCF-regel, men den er et nyttigt implementeringsbenchmark. CNIL anbefaler, at:

• accept, afvisning og tilbagekaldelse har den samme rækkevidde på tværs af enheder;
• brugere informeres inden valget om, at præferencen vil gælde for enheder, der er forbundet til deres konto;
• en kort påmindelse vises, når brugeren logger ind på en ny enhed;
• konflikter håndteres transparent, enten ved at prioritere det seneste valg forud for login eller kontopræferencen.

Dokumentér den valgte konfliktregel og test begge retninger. Et teknisk konsistent præferencelager kan stadig skabe en vildledende oplevelse, hvis brugerne ikke oplyses om, hvilket valg der vinder.

Hvad der ændrer sig under motorhjelmen

Den tekniske pakke er planlagt til den 23. juli, så implementeringsteams bør bruge det nuværende materiale til forberedelse – ikke til at lade, som om den endelige diff allerede er bekræftet. IAB Tech Labs opsummering af den offentlige kommentar identificerer to konkrete teknikerområder.

For det første får GVL det standardTexts-objekt, der bruges til Feature-forklaringer. Parsere, typer, caches, API'er og gengivelseskode skal acceptere og bevare det nye felt. En graceful fallback er nyttig for driftsmæssig robusthed, men må ikke stiltiende udelade en oplysning, der kræves efter deadlinen.

For det andet fjerner forhåndsvisningen en omgåelse for leverandører, der kun erklærer Særlige Formål. Siden TCF v2.3 gjorde disclosedVendors-segmentet obligatorisk, kan disse leverandører fastslå, om de var oplyst fra det segment. Forhåndsvisningen fjerner derfor kravet om at placere leverandører med kun Særlige Formål i afsnittet Vendor Legitimate Interest i TC-strengen.

En forsigtig implementeringsregel

Forbered tests nu, og bind derefter produktionsadfærden til den endelige v2.4-tekst offentliggjort den 23. juli. Sammenlign især den endelige TC-strengspecifikation, CMP API-materiale, GVL-skema, oversættelser og eksempler med forhåndsvisningen. Registrér den version, du testede. "Vi fulgte juni-artiklen" er ikke et brugbart revisionsspor, når der foreligger en endelig specifikation.

En syv-punkts TCF v2.4-parathedstjekliste

Deadlinen er lettere at håndtere, når hvert krav har en ejer og en observerbar accepttest. Start med denne tjekliste og udvid den til din arkitektur.

1. Inventariser alle TCF-overflader. List websteder, indlejrede oplevelser, mobilapps, CTV-apps, samtykkeindstillinger, kontopræferencecentre, SDK'er og cachet GVL-forbrugere. Markér hver som web, app eller CTV til deadlineplanlægning.
2. Diff den 23. juli-udgivelse. Sammenlign den endelige specifikation, GVL-skema, oversættelser, illustrationer og policyreferencer med din nuværende v2.3-implementering og den offentligt kommenterede forhåndsvisning.
3. Opdater GVL-indlæsning. Bekræft, at standardTexts, illustrationer, den omdøbte Special Feature 2 og fremtidige ukendte felter overlever parsing, lagring, API'er og caching.
4. Test brugerfladen. Kontrollér, at Feature-forklaringer vises ved siden af den korrekte information, ikke ligner kontroller, forbliver læsbare ved zoom og hjælpeteknologi, og fungerer på alle understøttede sprog. Gennemgå cookie-banneroplevelsen som et komplet flow snarere end et enkelt første lag.
5. Test signalering. Opret testdata for leverandører med kun Særlige Formål, og bekræft de endelige v2.4-kodnings- og afkodningsregler på tværs af CMP, nedstrøms leverandører og eventuel serversidehåndtering af samtykke.
6. Definer adfærd på tværs af enheder. Dokumentér omfang, identitetskrav, lagring, udbredelse, tilbagekaldelse og reglen, der anvendes, når enhedens og kontoens valg er i konflikt. Test accept, afvisning, ændring, logout, ny enhed og kontosletning.
7. Udrul og overvåg. Udgiv webændringer inden den 23. oktober med overvågning for GVL-fejl, samtykkestrengfejl, manglende oplysninger og usædvanlige ændringer i valgfrekvenser. Hold app- og CTV-udgivelser på en separat ejet plan for den 23. februar 2027.

Selvhosting fjerner ikke disse ansvarsområder. Hvis du driver OCI på din egen infrastruktur, kontrollerer du opgraderingsvinduet og kan inspicere implementeringen, men du ejer også den endelige specifikationsgennemgang, udrulning og bekræftelse.

Hvad udgivere bør spørge deres CMP-udbyder om

Udgivere behøver ikke selv implementere alle parserændringer, men de bør ikke acceptere "TCF-klar" som et fyldestgørende svar. Bed om dokumentation knyttet til dine faktiske miljøer og datoer.

Nyttige spørgsmål inkluderer:

• Hvilke TCF Policy- og Technical Specification-versioner kører i produktion i dag?
• Hvornår vil websupport til v2.4 være generelt tilgængeligt, og hvilken handling kræves af kunden?
• Hvordan gengives og oversættes de nye Feature-forklaringer, illustrationer og Special Feature 2-teksten?
• Understøtter produktet omfang på tværs af enheder, og præcist hvordan løses modstridende valg?
• Hvilke web-, app- og CTV SDK-versioner indeholder ændringerne?
• Hvilke automatiserede og manuelle tests dækker den endelige v2.4 TC-strengadfærd?
• Vil brugere skulle se rammebrugerfladen igen, og hvad er kilden til den beslutning?

Bed udbyderen om at adskille overholdelse af framework, Google-certificering og generel privatlivsjuridisk support. De overlapper, men ingen er bevis for de andre. Dine egne forpligtelser som dataansvarlig, udgiver og leverandør kræver stadig en GDPR-compliancevurdering, der er passende til den behandling, du foretager.

Hvad TCF v2.4 ikke betyder

TCF v2.4 er en opdatering af en brancheramme, ikke en ny lov og ikke et universelt krav for alle websites. IAB Europes egen politik beskriver deltagelse som frivillig og anfører, at rammen ikke erstatter individuelle deltageres ansvar for deres juridiske forpligtelser.

Hold disse grænser synlige i intern og kundekommunikation:

• at overholde TCF-deadlinen gør ikke i sig selv et samtykkeflow lovligt;
• Googles CMP-certificering er ikke lig med fuld TCF- eller privatlivslovgivningscompliance;
• en teknisk gyldig TC-streng beviser ikke, at brugeren modtog klare oplysninger eller traf et gyldigt valg;
• bekvemmelighed på tværs af enheder berettiger ikke skjult omfang eller envejsudbredelse;
• en ny standardlabel retter ikke en vildledende brugerflade omkring den.

Brug juridisk rådgivning til jurisdiktionsspecifikke konklusioner. Brug specifikationen, policyen og myndighedsvejledningen som separate inputs til produktkrav frem for at blande dem i én vag "compliance"-opgave.

Ofte stillede spørgsmål

Hvad betyder IAB TCF?

IAB TCF står for IAB Europe Transparency and Consent Framework. Det standardiserer, hvordan deltagende udgivere, CMPs og leverandører oplyser om databehandling, indfanger relevante valg og kommunikerer samtykke-, indsigelse- og transparenssignaler i det digitale annonceringsøkosystem.

Hvad er IAB TCF v2.3?

TCF v2.3 er den tekniske version umiddelbart før v2.4. Blandt andre ændringer gjorde den disclosedVendors-segmentet obligatorisk. Det er relevant for v2.4, fordi det offentligt kommenterede udkast bruger det obligatoriske segment til at fjerne den ældre omgåelse af legitim interesse for leverandører med kun Særlige Formål.

Hvad er TCF-listen?

Begrebet refererer normalt til Global Vendor List eller GVL. IAB Europe vedligeholder den for registrerede TCF-leverandører, og CMPs bruger dens erklæringer, standardtekst og relaterede data til at præsentere information og producere rammesignaler. v2.4-udrulningen inkluderer en tilsvarende GVL-opdatering planlagt til den 23. juli 2026.

Skal alle CMPs implementere TCF v2.4?

Nej. Deadlinerne vedrører CMPs og live installationer, der deltager i IAB Europe TCF. Et ikke-TCF samtykkeværktøj kan stadig have forpligtelser i henhold til privatlivslovgivning eller platformpolitik, men disse forpligtelser gør det ikke automatisk til en TCF-deltager.

Hvornår er TCF v2.4-deadlinen for CMPs?

Den bekræftede deadline er den 23. oktober 2026 for webmiljøer og den 23. februar 2027 for mobilapp- og CTV-miljøer. Specifikationerne og den tilsvarende GVL-opdatering er planlagt til offentliggørelse den 23. juli 2026.

Konklusion

TCF v2.4 er ikke en grund til at redesigne alle samtykkeflows. Det er en grund til at verificere de dele, brugere og leverandører er afhængige af: klare Feature-forklaringer, ærligt omfang, reversible valg på tværs af enheder og præcise signaler. Start med filerne fra den 23. juli, test web inden den 23. oktober, og hold mobil og CTV på februarplanen for 2027. En dokumenteret, evidensbaseret udrulning vil slå en hastigt udført bannerrendeopdatering.