IAB TCF v2.4: Hva CMP-er må endre innen oktober 2026

IAB TCF v2.4 har nå en bekreftet utrullingsplan. IAB Europe planlegger å publisere de endelige tekniske spesifikasjonene og oppdatert Global Vendor List (GVL) 23. juli 2026. CMP-er har deretter frist til 23. oktober 2026 for webimplementeringer og 23. februar 2027 for mobile apper og tilkoblede TV-miljøer. Hvis din samtykkestabel deltar i TCF, er dette et implementeringsprosjekt—ikke bare en oppdatering av bannertekst.

Endringene gjelder TCF Policy v5.0.b og tekniske spesifikasjoner v2.4. De påvirker hvordan CMP-er forklarer funksjoner, avslører omfanget av et valg, støtter samtykke på flere enheter, og koder for et smalt leverandørsignal. For bakgrunn om det nåværende rammeverket, se Conzents oversikt over IAB TCF-samsvar.

Viktige punkter

De bekreftede datoene gir CMP-er og utgivere en kort, men gjennomførbar sekvens: inspiser den endelige pakken i juli, fullfør webendringer i oktober, og hold mobil og CTV på en separat plan for februar. De viktigste punktene er:

• 23. juli 2026: IAB Europe planlegger å publisere tekniske spesifikasjoner v2.4 og den tilsvarende GVL-oppdateringen.
• 23. oktober 2026: CMP-er må implementere de nye avsløringene i webmiljøer.
• 23. februar 2027: den tilsvarende fristen gjelder for mobile apper og CTV-miljøer.
• Grensesnittene til CMP-er trenger klarere standardforklaringer og illustrasjoner for funksjoner.
• Det første laget må fortelle brukerne om et valg er spesifikt for tjenesten, spesifikt for gruppen, eller fler-enhets.
• Den tekniske forhåndsvisningen fjerner en foreldet legitime-interesse-løsning for leverandører som kun erklærer spesielle formål; team bør verifisere den endelige teksten 23. juli.
• TCF-deltakelse støtter samsvarsarbeid, men erstatter ikke en utgivers eller leverandørs egen juridiske vurdering.

De tre datoene å sette i din leveringsplan

IAB Europas bekreftelse datert 16. juli 2026 etablerer tre separate milepæler. Å behandle dem som en frist ville komprimere oppdagelse, implementering, oversettelse og QA inn i det samme utgivelsesvinduet.

Den praktiske sekvensen er:

1. 23. juli 2026 — spesifikasjon og GVL-publisering. Last ned de endelige filene, sammenlign dem med materialet for offentlig kommentar, og gjør hver bekreftet forskjell til en oppgave du eier.
2. 23. oktober 2026 — webfrist. Produksjonsweb-CMP-er bør avsløre de nye avsløringene og følge de endelige v2.4 signaleringskravene.
3. 23. februar 2027 — app- og CTV-frist. Native SDK-er, ledetider for utgivelsesbutikker, TV-grensesnitt og enhetsspesifikke tilgjengelighetstester får en senere dato, ikke et unntak.

Gapet mellom publisering og webfristen er tre måneder. Det er nok for en kontrollert oppdatering hvis teamene starter med en spesifikasjonsdifferens og en testmatrise. Det er stramt hvis arbeidet begynner med en sen banner redesign.

Den bekreftede sekvensen skiller kilde materialet, webimplementeringen, og app/CTV utrullingen. Planlegg og test dem som tre milepæler i stedet for én lansering.

Hvem må handle—og hvem bør fortsatt være oppmerksom

Fristene gjelder for aktive TCF-implementeringer og CMP-ene som er ansvarlige for dem. De offisielle TCF-policyene dekker både kommersielle CMP-er som betjener kunder og private CMP-er drevet av en utgiver for sine egne eiendommer. Utgivere forblir ansvarlige for rammeverkets UI presentert på deres digitale eiendommer, selv når en tredjepart leverer CMP-en.

Du bør sette dette arbeidet på en leveringsplan hvis du:

• bygger eller driver en registrert TCF CMP;
• bruker en kommersiell CMP på en nettside finansiert av programmatisk annonsering;
• vedlikeholder en privat utgiver CMP;
• leverer den samme samtykkeopplevelsen på web, app, og CTV;
• er avhengig av TCF-signaler for leverandører, budgivning, måling, eller personlige annonser.

En nettside som ikke deltar i TCF er ikke automatisk pålagt å implementere TCF v2.4. Den kan fortsatt trenge en gyldig samtykkemekanisme under gjeldende lov eller plattformregler. Rammeverksversjonen og den juridiske plikten til å innhente samtykke er relaterte spørsmål, ikke det samme spørsmålet.

Denne distinksjonen er viktig for Google-utgiverprodukter. Google krever en sertifisert CMP integrert med TCF for personlige annonser som serveres gjennom AdSense, Ad Manager, eller AdMob til brukere i EØS, Storbritannia, og Sveits. Google uttaler også at deres sertifiseringsgjennomgang ikke sjekker full samsvar med TCF eller gjeldende personvernlov.

Hva brukere vil se annerledes i en CMP

Den mest synlige endringen er et forsøk på å forklare funksjoner tydeligere. I TCF beskriver et formål hvorfor data behandles og gir brukeren et samtykke- eller innvending valg der det er aktuelt. En funksjon beskriver en behandlingsmetode brukt i jakten på ett eller flere formål; den har ikke en separat bruker kontroll på samme måte.

Under Policy v5.0.b og den bekreftede GVL-oppdateringen, må CMP-er ta hensyn til:

• et nytt standardTexts felt som inneholder standardforklaringen for funksjoner;
• illustrasjoner for hver funksjon i den oppdaterte GVL;
• den standard funksjonsforklaringen vist med det standard navnet og full brukervennlig tekst;
• funksjonsinformasjon som ikke er visuelt assosiert med kontroller som faktisk ikke kan deaktivere funksjonen;
• et nytt navn og veiledning for Spesiell Funksjon 2.

Det oppdaterte navnet for Spesiell Funksjon 2 er “Identifisere enheter basert på informasjon aktivt forespurt.” Policyveiledningen dekker eksplisitt egenskaper samlet inn gjennom JavaScript eller API-er—som skrifttyper, skjermoppløsning, og plugins—og informasjon aktivt forespurt gjennom User-Agent Client Hints. Brukere må gi sitt samtykke før en leverandør bruker denne spesielle funksjonen.

Hvorfor dette er mer enn en tekstoppdatering

En CMP som hardkoder etiketter eller antar den gamle GVL-strukturen kan feile selv om banneret fortsatt ser normalt ut. Produktteam må spore de nye dataene fra innhenting til hvert UI-lag, oversettelse, tilgjengelighetsmerkelapp, bufret leverandørpost, og regresjonstest. Den sikre designprinsippet er enkel: gjengi den offisielle betydningen nøyaktig, gjør tilstedeværelsen eller fraværet av et brukervalg uomtvistelig, og ikke gjør en forklarende funksjon til en falsk bryter.

Samtykke på flere enheter trenger et eksplisitt omfang

Policy v5.0.b legger til fler-enhetsomfang til rammeverkets definisjoner. Et juridisk grunnlag kan gjelde på tvers av tilgangspunkter for den samme tjenesten eller gruppen—for eksempel en nettside og mobilapp brukt av en autentisert konto—når implementeringen støtter det omfanget. Det første laget av rammeverkets UI må fortelle brukeren om samtykkevalget er spesifikt for tjenesten, spesifikt for gruppen, og/eller fler-enhets.

Den bekvemmeligheten skaper et produktansvar. En CMP trenger en definert måte å løse et valg gjort på en enhet før innlogging mot preferanser som allerede er lagret på kontoen. Den må også holde avvisning og tilbaketrekking like brukbare som aksept på tvers av det samme omfanget.

CNILs anbefaling for tverr-enhetssamtykke fra januar 2026 er fransk reguleringsveiledning snarere enn en EU-omfattende TCF-regel, men det er et nyttig implementeringsmål. CNIL anbefaler at:

• aksept, avvisning, og tilbaketrekking har samme fler-enhets rekkevidde;
• brukere blir informert før de velger at preferansen vil gjelde for enheter koblet til kontoen deres;
• en kort påminnelse vises når brukeren logger inn på en ny enhet;
• konflikter håndteres åpent, enten ved å prioritere det nyeste valget før innlogging eller kontopreferansen.

Dokumenter den valgte konfliktregelen og test begge retninger. Et teknisk konsistent preferanselager kan fortsatt skape en misvisende opplevelse hvis brukerne ikke blir informert om hvilket valg som vinner.

Hva som endres under panseret

Det tekniske pakken er planlagt for 23. juli, så implementeringsteam bør bruke det nåværende materialet til å forberede seg—ikke til å late som den endelige differansen allerede er verifisert. IAB Tech Labs offentlig kommentaroppsummering identifiserer to konkrete ingeniørområder.

For det første, GVL får standardTexts objektet brukt for funksjonsforklaringer. Parsere, typer, cacher, API-er, og gjengivelseskode må akseptere og bevare det nye feltet. En elegant fallback er nyttig for operasjonell motstandskraft, men den må ikke stille stille utelukke en avsløring som kreves etter fristen.

For det andre, forhåndsvisningen fjerner en løsning for leverandører som kun erklærer spesielle formål. Siden TCF v2.3 gjorde disclosedVendors segmentet obligatorisk, kan disse leverandørene bestemme om de ble avslørt fra det segmentet. Forhåndsvisningen fjerner derfor kravet om å plassere spesielle formål- kun leverandører i seksjonen for leverandørens legitime interesse i TC-strengen.

En forsiktig implementeringsregel

Forbered tester nå, bind deretter produksjonsatferd til den endelige v2.4 teksten publisert 23. juli. Sammenlign spesielt den endelige TC-streng spesifikasjonen, CMP API-materialet, GVL-skjemaet, oversettelser, og eksempler med forhåndsvisningen. Registrer versjonen du testet. “Vi fulgte juni-artikkelen” er ikke en nyttig revisjonsspor når en endelig spesifikasjon eksisterer.

En syv-punkts TCF v2.4 beredskapsliste

Fristen er lettere å håndtere når hvert krav har en eier og en observerbar aksepttest. Start med denne sjekklisten og utvid den for din arkitektur.

1. Inventar hver TCF-overflate. List opp web-eiendommer, innebygde opplevelser, mobile apper, CTV-apper, samtykkinnstillinger, kontopreferansesentre, SDK-er, og bufrede GVL-forbrukere. Merk hver som web, app, eller CTV for fristplanlegging.
2. Diff den 23. juli utgivelsen. Sammenlign den endelige spesifikasjonen, GVL-skjemaet, oversettelsene, illustrasjonene, og policyreferansene med din nåværende v2.3 implementering og offentlig kommentar forhåndsvisning.
3. Oppdater GVL-innhenting. Verifiser at standardTexts, illustrasjoner, den omdøpte spesielle funksjonen 2, og fremtidige ukjente felt overlever parsing, lagring, API-er, og caching.
4. Test brukergrensesnittet. Sjekk at funksjonsforklaringene vises ved siden av riktig informasjon, ikke ser ut som kontroller, forblir lesbare med zoom og hjelpemidler, og fungerer på hvert støttet språk. Gå gjennom cookie-banneropplevelsen som en komplett flyt snarere enn et enkelt første lag.
5. Test signalering. Opprett festemidler for spesielle formål-kun leverandører og verifiser den endelige v2.4 kodings- og dekodingsreglene på tvers av CMP-en, nedstrømsleverandører, og eventuell server-side samtykkehåndtering.
6. Definer fler-enhetsatferd. Dokumenter omfang, identitetskrav, lagring, spredning, tilbaketrekking, og regelen som brukes når enhets- og kontovalgene er i konflikt. Test aksept, avvisning, endring, utlogging, ny enhet, og kontoslettingsveier.
7. Lever og observer. Utgiv webendringer før 23. oktober med overvåking for GVL-feil, samtykkestrengfeil, manglende avsløringer, og uvanlige endringer i valgprosentene. Hold app- og CTV-utgivelser på en separat eid plan for 23. februar 2027.

Selvhosting fjerner ikke disse ansvarsområdene. Hvis du driver OCI på din egen infrastruktur, kontrollerer du oppgraderingsvinduet og kan inspisere implementeringen, men du eier også den endelige spesifikasjonsgjennomgangen, distribusjonen, og verifiseringen.

Hva utgivere bør spørre sin CMP-leverandør

Utgivere trenger ikke å implementere hver parserendring selv, men de bør ikke akseptere “TCF-klar” som et fullstendig svar. Be om bevis knyttet til dine faktiske miljøer og datoer.

Nyttige spørsmål inkluderer:

• Hvilke TCF-policyer og tekniske spesifikasjonsversjoner kjører i produksjon i dag?
• Når vil webstøtte for v2.4 være generelt tilgjengelig, og hvilken kundeadferd kreves?
• Hvordan blir de nye funksjonsforklaringene, illustrasjonene, og teksten for Spesiell Funksjon 2 gjengitt og oversatt?
• Støtter produktet fler-enhetsomfang, og hvordan løses konflikter mellom valg?
• Hvilke web-, app- og CTV-SDK-versjoner inneholder endringene?
• Hvilke automatiserte og manuelle tester dekker den endelige v2.4 TC-streng atferden?
• Må brukere se rammeverkets UI igjen, og hva er kilden til den beslutningen?

Be leverandøren om å skille mellom rammeverks-samsvar, Google-sertifisering, og generell personvernlovstøtte. De overlapper, men ingen er bevis på den andre. Dine egne kontroller, utgiver, og leverandørforpliktelser trenger fortsatt en GDPR-samsvars vurdering som er passende for behandlingen du utfører.

Hva TCF v2.4 ikke betyr

TCF v2.4 er en oppdatering av bransjerammeverket, ikke en ny lov og ikke et universelt mandat for hver nettside. IAB Europas egen policy beskriver deltakelse som frivillig og sier at rammeverket ikke er en erstatning for individuelle deltakere som tar ansvar for sine juridiske forpliktelser.

Hold disse grensene synlige i intern og kundekommunikasjon:

• å møte TCF-fristen gjør ikke i seg selv en samtykkeflyt lovlig;
• Google CMP-sertifisering er ikke lik full TCF eller personvernlov-samsvar;
• en teknisk gyldig TC-streng beviser ikke at brukeren mottok klar informasjon eller gjorde et gyldig valg;
• fler-enhets bekvemmelighet rettferdiggjør ikke skjult omfang eller enveis spredning;
• en ny standardetikett fikser ikke et misvisende grensesnitt rundt det.

Bruk juridisk rådgivning for jurisdiksjonsspesifikke konklusjoner. Bruk spesifikasjonen, policyen, og regulatorveiledningen som separate innganger til produktkravene i stedet for å blande dem inn i en vag “samsvars”-billett.

Ofte stilte spørsmål

Hva betyr IAB TCF?

IAB TCF betyr IAB Europas Transparens- og Samtykkerammeverk. Det standardiserer hvordan deltakende utgivere, CMP-er, og leverandører avslører databehandling, fanger relevante valg, og kommuniserer samtykke, innvending, og transparenssignaler i det digitale annonseøkosystemet.

Hva er IAB TCF v2.3?

TCF v2.3 er den tekniske versjonen umiddelbart før v2.4. Blant andre endringer gjorde den disclosedVendors segmentet obligatorisk. Det er viktig for v2.4 fordi utkastet til offentlig kommentar bruker det obligatoriske segmentet for å fjerne den eldre legitime-interesse-løsningen for spesielle formål-kun leverandører.

Hva er TCF-listen?

Begrepet refererer vanligvis til Global Vendor List, eller GVL. IAB Europa opprettholder den for registrerte TCF-leverandører, og CMP-er bruker dens erklæringer, standardtekst, og relaterte data for å presentere informasjon og produsere rammeverkssignaler. Utrullingen av v2.4 inkluderer en tilsvarende GVL-oppdatering planlagt for 23. juli 2026.

Må hver CMP implementere TCF v2.4?

Nei. Fristene gjelder CMP-er og aktive installasjoner som deltar i IAB Europas TCF. Et ikke-TCF samtykkeverktøy kan fortsatt ha forpliktelser under personvernlov eller plattformpolicy, men disse forpliktelsene gjør det ikke automatisk til en TCF-deltaker.

Når er TCF v2.4 fristen for CMP-er?

Den bekreftede fristen er 23. oktober 2026 for webmiljøer og 23. februar 2027 for mobile apper og CTV-miljøer. Spesifikasjonene og den tilsvarende GVL-oppdateringen er planlagt publisert 23. juli 2026.

Konklusjon

TCF v2.4 er ikke en grunn til å redesigne hver samtykkeflyt. Det er en grunn til å verifisere delene brukere og leverandører er avhengige av: klare funksjonsforklaringer, ærlig omfang, reversible fler-enhetsvalg, og nøyaktige signaler. Start med filene fra 23. juli, test web før 23. oktober, og hold mobil og CTV på planen for februar 2027. En dokumentert, bevisbasert utrulling vil overgå en hastet banner-oppdatering.