Migrasjonsguide fra IAB TCF v2.2 til v2.3: Hva som endret seg og hvordan CMP-er bør oppgradere

IAB Europe Transparency and Consent Framework (TCF) er det mest utbredte samtykkesignalet innen europeisk programmatisk annonsering. Versjoner av rammeverket er aldri bare kosmetiske oppdateringer — hver av dem reflekterer regulatorisk tilbakemelding, håndhevingstiltak og lærdommer fra hvordan ekte utgivere og leverandører faktisk opererer. Overgangen fra TCF v2.2 til v2.3 er ikke noe unntak.

Denne guiden går gjennom hva v2.3 faktisk endrer, hvorfor disse endringene eksisterer, og hvordan man migrerer en produksjons-CMP uten å miste samtykket inventar eller bryte Policies i løpet av overgangsvinduet.

Kortversjonen

TCF v2.3 er en videreutvikling av v2.2, ikke en ny arkitektur. TC String-formatet er kompatibelt, eksisterende formål og funksjoner er bevart, og de fleste UI-kravene som rammer utgivere er uendret. De meningsfulle endringene konsentrerer seg om fire områder:

Hvorfor v2.3 eksisterer

Hver TCF-versjon er en forhandling mellom tre målgrupper: utgivere som må fortsette å tjene penger, leverandører som trenger et stabilt teknisk grensesnitt, og regulatorer som stadig finner spesifikke samsvarshull. v2.3 er et direkte svar på tre press:

  1. Håndhevingstiltak mot overforbruk av “berettiget interesse” under v2.2. Flere europeiske DPA-er slo fast at for mange leverandører hevdet LI for formål der kun samtykke egentlig var lovlig. v2.3 strammer opp de leverandørerklærte rettslige grunnlagsavsløringene og viser dem tidligere i samtykke-UI-en.
  2. Pågående klager om mørke mønstre. De oppdaterte Policies gjør regelen om likeverdig fremtreden mer eksplisitt og tetter smutthull rundt forhåndskryssede brytere i andre lag.
  3. Operasjonell tilbakemelding fra store CMP-er og utgivere. v2.2 innførte flere påkrevde avsløringer som var vanskelige å implementere rent på mobil og CTV. v2.3 strømlinjeformer det obligatoriske avsløringssettet og lar mer av det leve i en lagdelt visning.

TC String-kompatibilitet

Selve TC String forblir bakoverkompatibel. En v2.3-CMP produserer strenger som v2.2-leverandører kan lese, og en v2.3-leverandør kan konsumere v2.2-strenger i overgangsperioden. Versjonsindikatoren i strengens kjernesegment identifiserer hvilken retningslinjeversjon CMP-en hevder samsvar med, og GVL-versjonspekeren beveger seg fremover uavhengig.

Hva dette betyr i praksis: du trenger ikke å oppdatere hver leverandør samtidig, og du trenger ikke å tvinge en ny samtykkehendelse på hver bruker den dagen du ruller ut v2.3. En faset utrulling støttes eksplisitt.

Viktige tekniske endringer

1. Leverandøravsløring og oppbevaring

v2.3 krever at CMP-er viser hver leverandørs oppgitte oppbevaringsperiode for data i den lagdelte UI-en, ikke bare i en separat leverandørliste. Oppbevaringsverdien har alltid vært en del av GVL, men v2.2 påla ikke at brukerne skulle se den sammen med formålene. v2.3 lukker dette gapet fordi regulatorer hevdet at brukerne ikke kunne ta et informert valg uten å vite hvor lenge dataene deres ville bestå.

2. Strengere kontroller i andre lag

På andre lag — “administrer preferanser”-visningen — er v2.3 eksplisitt om at brytere for ikke-essensielle formål og leverandører må være av som standard. Forhåndskryssede avmerkingsbokser eller forhåndsaktiverte skyvebrytere er et brudd på retningslinjene selv om brukeren aldri eksplisitt klikker “godta”. CMP-er som tidligere baserte seg på et “soft opt-in”-mønster må tegne andre lag på nytt.

3. Håndhevelse av likeverdig fremtreden

Regelen om likeverdig fremtreden har eksistert siden v2.1, men v2.3 definerer den med mindre rom for tolkning: “avvis alle”-kontrollen må være på samme lag, samme visuelle vekt, samme fargekontrastklasse og samme interaksjonsavstand som “godta alle”. Å skjule avvis bak en lenke, en mindre knapp eller et sekundært skjermbilde er nå et eksplisitt samsvarsfeil snarere enn en skjønnsmessig vurdering.

4. Signalering av berettiget interesse

Leverandører som erklærer berettiget interesse som rettslig grunnlag under v2.3 må nå også erklære hvilke formål de har vurdert og for hvilke de har fullført en Legitimate Interests Assessment. CMP-er er pålagt å føre denne erklæringen videre til brukergrensesnittet slik at brukerne kan protestere med full informasjon. I praksis betyr dette at “protester”-flyten nå viser leverandørspesifikk LIA-status i stedet for en generell bryter.

5. Oppdateringer av GVL-skjemaet

Global Vendor List-skjemaet legger til felt for oppbevaringsgranularitet, LIA-status og en maskinlesbar lenke til hver leverandørs personvernpolicyseksjon for de erklærte formålene. CMP-er som cacher GVL må oppdatere skjema-parseren sin for å forstå de nye feltene før de peker mot en v2.3-GVL.

Policyendringer som påvirker UX-en

TCF er både en teknisk spesifikasjon og et sett med Policies. Flere av v2.3-policyendringene lander direkte på samtykke-UI-en:

Hva utgivere må gjøre

  1. Bekreft CMP-leverandørens v2.3-støtte. Be om nøyaktig dato når deres v2.3-sertifiserte bygg vil være tilgjengelig og versjonsstrengen den vil rapportere.
  2. Frisk opp GVL-cachelogikken din. Hvis du selv er vert for en GVL-speiling, oppdater skjema-parseren før v2.3-GVL rulles ut, ellers vil CMP-en din mislykkes i å validere nye leverandører.
  3. Skriv om UI-en i andre lag slik at hver bryter er av som standard, likeverdig fremtreden håndheves visuelt, og oppbevaringsperioder vises sammen med formålene.
  4. Kjør compliance-revisjonen din på nytt. De enkleste regulatoriske seierne er brudd på mørke mønstre som v2.3 nå eksplisitt påpeker. Fiks dem før din neste håndhevingsgjennomgang.
  5. Planlegg en strategi for ny melding. Selv om TC String er bakoverkompatibel, oppfordrer Policies utgivere til å be om samtykke på nytt når omfanget eller avsløringen av behandlingen endres vesentlig. Bestem om v2.3-utrullingen din kvalifiserer som “vesentlig” for publikum ditt.

Hva leverandører må gjøre

  1. Fullfør en Legitimate Interests Assessment for hvert formål der du erklærer LI, og send inn resultatet til GVL.
  2. Oppdater GVL-oppføringen din med v2.3-skjemafeltene: oppbevaringsgranularitet, LIA-erklæring og personvernpolicyens dyplenke.
  3. Valider TC String-parseren din mot v2.3-referansestrengene som IAB Europe har levert.
  4. Koordiner med CMP-partnerne dine om en felles overgangsdato, slik at den første kjøperforespørselen som bærer en v2.3-streng ikke lander på en leverandør som kun støtter v2.2.

Vanlige migrasjonsfeller

Konklusjon

TCF v2.3 er ikke et disruptivt brudd med v2.2, men det er en meningsfull innstramming av reglene som holder det europeiske programmatiske økosystemet sammen. Retningen er klar: mer åpenhet, færre mørke mønstre, mer granulær brukerkontroll og mindre toleranse for kanttilfellene som før slapp gjennom. CMP-er og utgivere som behandler v2.3 som en rask lapp, vil finne seg selv rett foran regulatoren igjen. De som bruker migreringen til å rydde opp i UX-en i andre lag, pensjonere snarveier basert på berettiget interesse, og bygge opp en reell samtykkeflyt med likeverdig fremtreden, vil komme ut på den andre siden med inventar som faktisk klareres i v2.3-æraen — og med en samtykkeposisjon som vil overleve alt v2.4 bringer videre.

← Blogg Les alt →