Das Transparency & Consent Framework 2.0 ist eine überarbeitete Version des Original Frameworks, das 2018 gelauncht wurde. Sein Zweck ist eine Standardisierung, wie Publisher, Ad Tech Vendors und Agenturen Programmatic Advertising auf GDPR-konforme Weise betreiben können. Im Vergleich zu TCF 1.1 ändern sich mit TCF 2.0 die folgenden Punkte:

  • Überarbeitete Purposes, Special Purposes, Features and Special Features
  • Stacks als vordefinierte Kombinationen von Purposes
  • Neue Global Vendor List 2.0
  • Neuer Consent String TC String 2.0
  • Berechtigtes Interesse explizit berücksichtigt
  • OOB (out-of-band) Rechtsgrundlage im TC String 2.0 möglich

TCF 2.0 ist nicht rückwärtskompatibel und erfordert darum Anpassungen von allen Vendoren und Publishern.

Wann wird Yieldlab das TCF 2.0 unterstützen?

Yieldlab unterstützt schon seit Juni das Transparency & Consent Framework 2.0 und ist in der Global Vendor List 2.0 offiziell als operational aufgeführt.

Gibt es einen Parallelbetrieb des TCF 1.1 und TCF 2.0?

Ja, gemäß der vom IAB definierten Timeline wird Yieldlab bis zur endgültigen Abkündigung des TCF 1.1 sowohl TCF 1.1 als auch TCF 2.0 unterstützen.

Wie sieht die Timeline zum TCF 2.0 aus?

Die im Mai aktualisierte Timeline des IAB sieht derzeit wie folgt aus:

  • March 31: TCF v2.0 beta production support
    • All vendors signed up to TCF v2.0
    • Code completed for full feature support, deployed in a limited capacity in production environments to monitor and test and fix issues. Objective to meet success criteria for general availability readiness
  • April 30: CMPs start to deploy in Publisher environment
  • May 31: All vendors expected to support TCF v2.0 with minimal bugs
  • August 15: GVL & CMP list TCF v1.1 no longer supported
  • September 30: v1.1 Consent Strings no longer valid

Für welche Purposes hat Yieldlab sich registriert?

Yieldlab hat sich für die folgenden Purposes, Special Purposes, Features und Special Features registriert:

  • P1: Store/Access information on a device
  • P2: Select Basic Ads
  • P3: Create personalized ad profile
  • P4: Use personalized ad profile
  • P7: Measure Ad Performance
  • SF1: Use precise geo-location data
  • SP1: Ensure Security, prevent fraud
  • SP2: Deliver ads or content
  • F2: Link different devices
  • F3: Use device characteristics for identification

Kann ich weiter mit Berechtigtem Interesse arbeiten?

Nach heutigem Stand unterstützt das TCF 2.0 Berechtigtes Interesse und bildet dieses explizit im TC String 2.0 ab.

Was muss ich als Publisher beachten, wenn ich das TCF2.0 einsetzen will?

  • Die CMP (Consent Management Platform) des Publishers muss den Nutzer-Consent (oder Berechtigtes Interesse) gemäß TCF 2.0 abfragen, empfangen
    und speichern.
  • Der Publisher entscheidet, was auf seinen Seiten und Apps erlaubt ist, welche Purposes und Vendoren abgefragt werden.
  • Die für Yieldlab relevanten Purposes und Special Features sollten auf den Seiten und Apps des Publishers beim Nutzer abgefragt werden.
  • Der TC String 2.0 muss nach aktueller IAB Timeline spätestens ab dem 30.06.2020 beim Aufruf von Yieldlab gesendet werden.
  • Sofern bereits Consent-Informationen an Yieldlab übergeben werden, ist keine Änderung an der Integration notwendig. Der TC String 2.0 wird wie bisher auch über den Parameter “consent” übergeben.
  • Sofern noch keine Consent-Informationen übermittelt werden, sollte der TC-String 2.0 am Adtag oder an der Yieldprobe über den Parameter “consent” an
    Yieldlab übergeben werden.

Wie verarbeitet Yieldlab die Consent Informationen?

Yieldlab wertet die Infos aus dem TC String aus und prüft, ob Yieldlab sowohl als Vendor als auch für die einzelnen Purposes Consent (oder Berechtigtes Interesse, falls anwendbar) vom Nutzer erhalten hat. Für die Weitergabe der Nutzerdaten an den nachfolgenden Vendor prüfen wir, ob auch für die DSP als Vendor Consent vorliegt.

Welche Prozesse von Yieldlab sind vom TCF2.0 betroffen?

Wir haben zwei verschiedene Use Cases im Auktionsprozess, für die wir Consent (oder Berechtigtes Interesse, falls anwendbar) benötigen:

  • User Matching
  • Versand von Nutzerdaten im Bid Request

Für das User Matching durch Yieldlab sind die Purposes P1, P3 und P4 relevant. Falls Consent (oder Berechtigtes Interesse, falls anwendbar) für mindestens einen dieser Purposes vom Nutzer nicht vorliegt, führt Yieldlab kein Matching durch.

Für den Versand von Bid Requests durch Yieldlab sind die Purposes P1, P2, P3, P4 und P7 relevant. Falls Consent (oder Berechtigtes Interesse, falls anwendbar) für mindestens einen dieser Purposes vom Nutzer nicht vorliegt, versendet Yieldlab keine Nutzerdaten im Bid Request bzw. versendet keinen Bid Request, wenn Yieldlab im Yieldprobe-Aufruf keine nutzbare ID hat.

Google Additional Consent Mode

Google unterhält eine eigene Registrierung mit Providern für die Google Plattform,die noch nicht in der GVL registriert sind. Die Liste der erlaubten Provider kann in YRD gepflegt und muss separat im CMP für Consent abgefragt werden. Über den Parameter “gp” (Google Provider) wird die Weitergabe dieser Liste von Yieldlab an Google gesteuert.

Siehe auch: https://support.google.com/displayvideo/answer/9681920

Integration

Die CMP muss Consent für die Provider abfragen, die in YRD unter “Google DV360 Provider List” angehakt sind. Wenn der User Consent für diese Provider gegeben hat, muss der Yieldprobe Parameter gp=true sein, damit Yieldlab die “Additional Consented Provider” im Bid Request an DV360 übergibt.

  • Parameter: “gp”
  • Value: true / false (boolean)

Example: https://ad.yieldlab.net/yp/$%7Badslots%7D?gp=true

PreBid

Seit Prebid 3.24.0 Release unterstützt der Yieldlab Adapter “customParams” in den Bid Params. “customParams” ist eine generische Möglichkeit Parameter an die Yieldprobe zu hängen und kann genutzt werden, um den “gp” Parameter dynamisch zu setzen.

Weiterführende Links

https://iabeurope.eu/tcf-2-0/
https://iabeurope.eu/vendor-list-tcf-v2-0/
https://iabeurope.eu/tcf-for-publishers/