IAB TCF v2.4: Vad CMP:er måste ändra senast oktober 2026

IAB TCF v2.4 har nu ett bekräftat lanseringsschema. IAB Europe planerar att publicera de slutliga tekniska specifikationerna och den uppdaterade globala leverantörslistan (GVL) den 23 juli 2026. CMP:er har sedan fram till den 23 oktober 2026 för webbimplementationer och 23 februari 2027 för mobilappar och anslutna TV-miljöer. Om din samtyckesstack deltar i TCF, är detta ett implementationsprojekt—inte bara en uppdatering av texten i bannern.

Ändringarna omfattar TCF Policy v5.0.b och tekniska specifikationer v2.4. De påverkar hur CMP:er förklarar funktioner, avslöjar omfattningen av ett val, stöder samtycke för flera enheter och kodar ett snävt leverantörssignaleringsfall. För bakgrund om det nuvarande ramverket, se Conzents översikt över IAB TCF-efterlevnad.

Viktiga punkter

De bekräftade datumen ger CMP:er och publicister en kort men genomförbar sekvens: inspektera det slutliga paketet i juli, avsluta webbändringar i oktober och hålla mobil och CTV på en separat plan för februari. De viktigaste punkterna är:

• 23 juli 2026: IAB Europe planerar att publicera tekniska specifikationer v2.4 och den motsvarande GVL-uppdateringen.
• 23 oktober 2026: CMP:er måste implementera de nya avslöjandena i webbmiljöer.
• 23 februari 2027: den motsvarande tidsfristen gäller för mobilappar och CTV-miljöer.
• Gränssnitt för CMP:er behöver tydligare standardförklaringar och illustrationer för funktioner.
• Den första nivån måste informera användarna om huruvida ett val är tjänstespecifikt, gruppspecifikt eller för flera enheter.
• Den tekniska förhandsvisningen tar bort en föråldrad lösning för legitima intressen för leverantörer som endast deklarerar särskilda syften; team bör verifiera den slutliga formuleringen den 23 juli.
• TCF-deltagande stöder efterlevnadsarbete, men ersätter inte en publicists eller leverantörs egen juridiska bedömning.

De tre datumen att sätta i din leveransplan

IAB Europas bekräftelse daterad 16 juli 2026 fastställer tre separata milstolpar. Att behandla dem som en deadline skulle komprimera upptäckten, implementeringen, översättningen och QA till samma lanseringsfönster.

Den praktiska sekvensen är:

1. 23 juli 2026 — specifikation och GVL-publicering. Ladda ner de slutliga filerna, jämför dem med materialet för offentlig kommentar och gör varje bekräftad skillnad till en ägd uppgift.
2. 23 oktober 2026 — webbdeadline. Produktionswebb-CMP:er bör avslöja de nya avslöjandena och följa de slutliga v2.4-signaleringskraven.
3. 23 februari 2027 — app- och CTV-deadline. Inbyggda SDK:er, ledtider för releasebutiker, TV-gränssnitt och enhetsspecifik tillgänglighetstestning får ett senare datum, inte ett undantag.

Gapet mellan publicering och webbdeadline är tre månader. Det är tillräckligt för en kontrollerad uppdatering om teamen börjar med en specifikationsdiff och en testmatris. Det är tight om arbetet börjar med en sen bannerdesign.

Den bekräftade sekvensen separerar källmaterialet, webbimplementationen och app/CTV-lanseringen. Planera och testa dem som tre milstolpar snarare än en lansering.

Vem måste agera—och vem bör fortfarande vara uppmärksam

Deadlines gäller för aktiva TCF-implementationer och de CMP:er som ansvarar för dem. De officiella TCF-policyerna omfattar både kommersiella CMP:er som betjänar kunder och privata CMP:er som drivs av en publicist för sina egna egenskaper. Publicister förblir ansvariga för ramverkets UI som presenteras på deras digitala egenskaper, även när en tredje part tillhandahåller CMP:n.

Du bör lägga detta arbete på en leveransplan om du:

• bygger eller driver en registrerad TCF CMP;
• använder en kommersiell CMP på en webbplats som finansieras av programmatisk annonsering;
• underhåller en privat publicist-CMP;
• skickar samma samtyckesupplevelse över webb, app och CTV;
• beroende av TCF-signaler för leverantörer, budgivning, mätning eller personliga annonser.

En webbplats som inte deltar i TCF är inte automatiskt skyldig att implementera TCF v2.4. Den kan fortfarande behöva en giltig samtyckesmekanism enligt tillämplig lag eller plattformsregler. Ramverksversionen och den juridiska skyldigheten att erhålla samtycke är relaterade frågor, inte samma fråga.

Denna distinktion är viktig för Googles publicistprodukter. Google kräver en certifierad CMP integrerad med TCF för personliga annonser som serveras genom AdSense, Ad Manager eller AdMob till användare i EES, Storbritannien och Schweiz. Google anger också att dess certifieringsgranskning inte kontrollerar fullständig efterlevnad av TCF eller tillämplig integritetslag.

Vad användare kommer att se annorlunda i en CMP

Den mest synliga förändringen är en strävan att förklara funktioner tydligare. I TCF beskriver ett syfte varför data behandlas och ger användaren ett samtycke eller invändningsval där det är tillämpligt. En funktion beskriver en behandlingsmetod som används i syfte att uppnå ett eller flera syften; den har inte en separat användarkontroll på samma sätt.

Under Policy v5.0.b och den bekräftade GVL-uppdateringen behöver CMP:er ta hänsyn till:

• ett nytt standardTexts-fält som innehåller standardförklaringen för funktioner;
• illustrationer för varje funktion i den uppdaterade GVL;
• den standardfunktionförklaring som visas med det standardnamn och full användarvänlig text;
• funktionsinformation som inte visuellt är kopplad till kontroller som faktiskt inte kan inaktivera funktionen;
• ett nytt namn och vägledning för särskild funktion 2.

Det uppdaterade namnet för särskild funktion 2 är “Identifiera enheter baserat på information som aktivt begärs.” Policyns vägledning omfattar uttryckligen egenskaper som samlas in genom JavaScript eller API:er—såsom typsnitt, skärmupplösning och plugins—och information som aktivt begärs genom User-Agent Client Hints. Användare måste ge sitt samtycke innan en leverantör använder denna särskilda funktion.

Varför detta är mer än en kopieringsuppdatering

En CMP som hårdkodar etiketter eller antar den gamla GVL-strukturen kan misslyckas även om bannern fortfarande ser normal ut. Produktteam behöver spåra de nya uppgifterna från inhämtning till varje UI-lager, översättning, tillgänglighetsetikett, cachad leverantörsrekord och regressionstest. Den säkra designprincipen är enkel: återge den officiella betydelsen korrekt, gör närvaron eller frånvaron av ett användarval tydlig, och gör inte en förklarande funktion till en falsk växel.

Samtycke för flera enheter behöver en tydlig omfattning

Policy v5.0.b lägger till omfattning för flera enheter i ramverkets definitioner. En juridisk grund kan gälla över åtkomstpunkter för samma tjänst eller grupp—till exempel en webbplats och mobilapp som används av ett autentiserat konto—när implementationen stöder den omfattningen. Den första nivån av ramverkets UI måste informera användaren om huruvida samtyckesvalet är tjänstespecifikt, gruppspecifikt och/eller för flera enheter.

Denna bekvämlighet skapar ett produktansvar. En CMP behöver ett definierat sätt att lösa ett val som gjorts på en enhet före inloggning mot preferenser som redan lagrats på kontot. Den måste också hålla avslag och återkallelse lika användbara som acceptans över samma omfattning.

CNIL:s rekommendation för flera enheter från januari 2026 är fransk regleringsvägledning snarare än en EU-omfattande TCF-regel, men det är en användbar implementationsreferens. CNIL rekommenderar att:

• acceptans, avslag och återkallelse har samma räckvidd för flera enheter;
• användare informeras innan de väljer att preferensen kommer att gälla för enheter kopplade till deras konto;
• en kort påminnelse visas när användaren loggar in på en ny enhet;
• konflikter hanteras transparent, antingen genom att prioritera det senaste valet före inloggning eller kontopreferensen.

Dokumentera den valda konfliktregeln och testa båda riktningarna. En tekniskt konsekvent preferenslagring kan fortfarande skapa en missvisande upplevelse om användarna inte informeras om vilket val som vinner.

Vad som förändras under huven

Det tekniska paketet är planerat till den 23 juli, så implementeringsteamen bör använda det aktuella materialet för att förbereda sig—inte för att låtsas att den slutliga diffen redan har verifierats. IAB Tech Labs sammanfattning av offentlig kommentar identifierar två konkreta ingenjörsområden.

För det första får GVL objektet standardTexts som används för funktionsförklaringar. Parsers, typer, cachar, API:er och renderingskod behöver acceptera och bevara det nya fältet. En smidig fallback är användbar för operationell motståndskraft, men den får inte tyst utelämna ett avslöjande som krävs efter deadline.

För det andra tar förhandsvisningen bort en lösning för leverantörer som endast deklarerar särskilda syften. Eftersom TCF v2.3 gjorde segmentet disclosedVendors obligatoriskt, kan dessa leverantörer avgöra om de avslöjades från det segmentet. Förhandsvisningen tar därför bort kravet att placera leverantörer med endast särskilda syften i avsnittet för legitima intressen i TC-strängen.

En försiktig implementationsregel

Förbered tester nu, bind sedan produktionsbeteendet till den slutliga v2.4-texten som publiceras den 23 juli. Jämför särskilt den slutliga TC-strängens specifikation, CMP API-material, GVL-schema, översättningar och exempel med förhandsvisningen. Dokumentera den version du testade. “Vi följde juniartikeln” är inte en användbar revisionsspår när en slutlig specifikation finns.

En sju punkters TCF v2.4 beredskapschecklista

Deadlinen är lättare att hantera när varje krav har en ägare och ett observerbart acceptanstest. Börja med denna checklista och utöka den för din arkitektur.

1. Inventera varje TCF-yta. Lista webbplatser, inbäddade upplevelser, mobilappar, CTV-appar, samtyckesinställningar, kontopreferenscenter, SDK:er och cachade GVL-konsumenter. Markera varje som webb, app eller CTV för deadlineplanering.
2. Diffa den 23 juli-releasen. Jämför den slutliga specifikationen, GVL-schemat, översättningarna, illustrationerna och policyreferenserna med din nuvarande v2.3-implementation och den offentliga kommentarsförhandsvisningen.
3. Uppdatera GVL-inhämtning. Verifiera att standardTexts, illustrationer, den omdöpta särskilda funktionen 2 och framtida okända fält överlever parsning, lagring, API:er och caching.
4. Testa användargränssnittet. Kontrollera att funktionsförklaringar visas bredvid korrekt information, inte ser ut som kontroller, förblir läsbara med zoom och hjälpmedelsteknik och fungerar på alla stödda språk. Granska cookie-bannersupplevelsen som ett komplett flöde snarare än ett enda första lager.
5. Testa signalering. Skapa fixtures för leverantörer med endast särskilda syften och verifiera de slutliga v2.4 kodnings- och avkodningsreglerna över CMP:n, nedströmsleverantörer och eventuell serverbaserad samtyckeshantering.
6. Definiera beteende för flera enheter. Dokumentera omfattning, identitetskrav, lagring, spridning, återkallelse och regeln som används när enhets- och kontoval krockar. Testa acceptans, avslag, ändring, utloggning, ny enhet och kontoborttagningsvägar.
7. Skicka och observera. Släpp webbändringar före den 23 oktober med övervakning för GVL-fel, samtyckessträngfel, saknade avslöjanden och ovanliga förändringar i valfrekvenser. Håll app- och CTV-releaser på en separat ägd plan för den 23 februari 2027.

Att självhosta tar inte bort dessa ansvar. Om du driver OCI på din egen infrastruktur, kontrollerar du uppgraderingsfönstret och kan inspektera implementationen, men du äger också den slutliga specifikationsgranskningen, distributionen och verifieringen.

Vad publicister bör fråga sin CMP-leverantör

Publicister behöver inte implementera varje parserändring själva, men de bör inte acceptera “TCF-klar” som ett fullständigt svar. Be om bevis kopplade till dina faktiska miljöer och datum.

Användbara frågor inkluderar:

• Vilka TCF-policy- och tekniska specifikationsversioner körs i produktion idag?
• När kommer webbstödet för v2.4 att vara allmänt tillgängligt, och vilken kundåtgärd krävs?
• Hur renderas och översätts de nya funktionsförklaringarna, illustrationerna och texten för särskild funktion 2?
• Stöder produkten omfattning för flera enheter, och hur löses konflikter exakt?
• Vilka webb-, app- och CTV-SDK-versioner innehåller ändringarna?
• Vilka automatiserade och manuella tester täcker den slutliga v2.4 TC-strängens beteende?
• Kommer användare behöva se ramverkets UI igen, och vad är källan till det beslutet?

Be leverantören att separera ramverkets efterlevnad, Googles certifiering och allmän efterlevnad av integritetslagar. De överlappar, men ingen är bevis på den andra. Dina egna kontroller, publicist- och leverantörsskyldigheter behöver fortfarande en GDPR-efterlevnadsbedömning som är lämplig för den behandling du utför.

Vad TCF v2.4 inte betyder

TCF v2.4 är en uppdatering av branschramverket, inte en ny lag och inte ett universellt mandat för varje webbplats. IAB Europas egen policy beskriver deltagande som frivilligt och säger att ramverket inte är en ersättning för individuella deltagare som tar ansvar för sina juridiska skyldigheter.

Håll dessa gränser synliga i intern och kundkommunikation:

• att uppfylla TCF-deadlinen gör inte i sig en samtyckesflöde laglig;
• Googles CMP-certifiering är inte lika med fullständig TCF- eller integritetslagsefterlevnad;
• en tekniskt giltig TC-sträng bevisar inte att användaren fick tydlig information eller gjorde ett giltigt val;
• bekvämlighet för flera enheter rättfärdigar inte dold omfattning eller ensidig spridning;
• en ny standardetikett fixar inte ett missvisande gränssnitt runt den.

Använd juridisk rådgivning för jurisdiktionsspecifika slutsatser. Använd specifikationen, policyn och regleringsvägledning som separata ingångar till produktkrav snarare än att blanda dem till en vag “efterlevnad”-biljett.

Vanliga frågor

Vad betyder IAB TCF?

IAB TCF betyder IAB Europas Transparens- och Samtyckesramverk. Det standardiserar hur deltagande publicister, CMP:er och leverantörer avslöjar databehandling, fångar relevanta val och kommunicerar samtycke, invändning och transparenssignaler i det digitala annonseringssystemet.

Vad är IAB TCF v2 3?

TCF v2.3 är den tekniska versionen omedelbart före v2.4. Bland andra förändringar gjorde den segmentet disclosedVendors obligatoriskt. Det är viktigt för v2.4 eftersom utkastet för offentlig kommentar använder det obligatoriska segmentet för att ta bort den äldre lösningen för legitima intressen för leverantörer med endast särskilda syften.

Vad är TCF-listan?

Termen hänvisar vanligtvis till den globala leverantörslistan, eller GVL. IAB Europa underhåller den för registrerade TCF-leverantörer, och CMP:er använder dess deklarationer, standardtext och relaterad data för att presentera information och producera ramverkssignaler. Utrullningen av v2.4 inkluderar en motsvarande GVL-uppdatering planerad till den 23 juli 2026.

Behöver varje CMP implementera TCF v2.4?

Nej. Deadlines gäller CMP:er och aktiva installationer som deltar i IAB Europas TCF. Ett icke-TCF samtyckesverktyg kan fortfarande ha skyldigheter enligt integritetslagar eller plattformsregler, men dessa skyldigheter gör det inte automatiskt till en TCF-deltagare.

När är TCF v2.4-deadlinen för CMP:er?

Den bekräftade deadlinen är den 23 oktober 2026 för webbmiljöer och den 23 februari 2027 för mobilappar och CTV-miljöer. Specifikationerna och den motsvarande GVL-uppdateringen är planerade för publicering den 23 juli 2026.

Slutsats

TCF v2.4 är inte en anledning att redesigna varje samtyckesflöde. Det är en anledning att verifiera de delar som användare och leverantörer förlitar sig på: tydliga funktionsförklaringar, ärlig omfattning, reversibla val för flera enheter och korrekta signaler. Börja med filerna från den 23 juli, testa webb innan den 23 oktober och håll mobil och CTV på planen för februari 2027. En dokumenterad, evidensbaserad utrullning kommer att överträffa en stressad banner-uppdatering.