Kontakt zur INFOnline

Service Center im Überblick

Sie erreichen uns montags bis freitags zwischen 09:00 Uhr – 18:00 Uhr

Customer Service | e-Mail | 0228 / 41 0 29 77

Service Center IVW digital | e-Mail | 0800 / 58 91 788 

agof service center | e-Mail | 0800 / 41 0 29 77

MMC Service Center Webradio | e-Mail | 0800 / 41 0 29 29

Usercentrics | e-Mail

TCF 2.0 Integration in SZMnG

Sie sind hier:

1. Allgemeines

1.1 Problemstellung

agof, IVW und ÖWA haben als nachgelagerte Datenverarbeiter der INFOnline GmbH, auch Downstream Vendoren genannt, keine Zugriffsmöglichkeit auf die Consent Entscheidung eines Users im TCF 2.0 Framework. Hieraus ergibt sich für die INFOnline GmbH die Notwendigkeit, die Consent Entscheidung des Users aus dem TCF 2.0 Framework im Messskript über die TCF 2.0 API abzufragen und an das Messsystem zu übermitteln.

Zusätzlich darf im Falle einer negativen Consent Entscheidung des Users in Bezug auf die agof ddf oder den Purpose 9 keine Befragung ausgeliefert werden.

Für den Fall, dass der User ein eigenes Framework nutzt, oder aus anderen Gründen keine automatische Ermittlung des TCF 2.0 Consents erfolgt, kann der Publisher über die Nutzung des ct-Parameters einen Consent String übermitteln.

1.2 Kurzbeschreibung TCF 2.0

Durch die europäische Datenschutzgrundverordnung (DSGVO) werden nahezu alle Profildaten, die über Cookies oder mobile Ad Identifier erhoben werden, als personenbezogen definiert. Wer auf seiner Webseite Besucherdaten erhebt, muss den User über dessen Verwendung informieren. Gerade bei modernen Advertising Mechanismen wie RTB/RTA (Real Time Bidding/Advertising) entsteht eine hochkomplexe Kette verschiedener Dienstleister, die in die Verarbeitung und Anreicherung von Userdaten involviert sind. Dabei muss an jeder Stelle und zu jedem Zeitpunkt bekannt sein, welche Tracking- und Targeting-Vorgänge eines Users erlaubt sind – und welche unterlassen werden müssen. Zur Gewährleistung der technischen Sicherstellung, hat der Branchenverband IAB Europe das „Transparency and Consent Framework“ entwickelt. Im September 2019 wurde die ergänzte Version 2.0 veröffentlicht. Am 15.08.2020 erfolgte der Rollout dieser.

Neben dem User definiert das TCF drei weitere Kategorien von Akteuren: Vendoren, Publisher und Consent Management-Plattformen (CMPs).

  • Vendoren sind alle Dienstleister der Auslieferungskette die Daten verarbeiten wollen. Da-runter fallen beispielsweise Websitetrackingsysteme, Adserver und Adverification-Anbieter, Demand- und Sell Side-Plattformen (DSPs und SSPs) sowie Data Management-Plattformen (DMPs). Vendoren müssen beim TCF registriert sein und erklären, zu welchen Zwecken sie Daten verarbeiten wollen. Mit dieser Information sind sie über die sogenannte Global Vendor List (GVL) einsehbar.

  • Publisher stellen Content bereit und stehen in direktem Kontakt mit den Konsumenten.

  • Consent Management-Plattformen (CMPs) sind Spezialdienstleister, die für Publisher und Werbetreibende die Privacy Center und Consent Screens auf den Webseiten betreiben und dort dem User Gelegenheit zur Zustimmung oder Widerspruch geben. Im Rahmen des TCF sind sie für das Bereitstellen des Consent-Status der User an die Auslieferungskette zuständig.

Für die Kommunikation zwischen den verschiedenen Parteien, das sogenannte Signalling, legt das TCF eine standardisierte Nomenklatur fest. Dabei wird für jeden, von einem Publisher oder Werbetreibenden auf den Seiten integrierten, Vendor zu den einzelnen Verarbeitungszwecken übertragen, ob die Datenverarbeitung erlaubt ist und ob der User ein explizites Opt-out vorgenommen hat.

In der Version 2.0 unterscheidet das TCF zehn unterschiedliche Zwecke (Purposes) für die Verarbeitung der Tracking-Daten. Diese werden ergänzt durch insgesamt sieben weitere Verarbeitungsmöglichkeiten und -zwecke, die spezielle Anwendungsfälle und deren Rechtsgrundlagen regeln.

AnwendungIDVerarbeitungszweckRechtsgrundlage
Cookies setzen01Informationen auf einem Gerät speichern und/oder abrufenZustimmung oder nicht verwendet
Technisches Targeting02Auswahl einfacher AnzeigenZustimmung, berechtigtes Interesse oder nicht verwendet
Profile Targeting03Ein personalisiertes Anzeigen-Profil erstellen
04Personalisierte Anzeigen auswählen
05Ein personalisiertes Inhalts-Profil erstellen
06Personalisierte Inhalte auswählen
Tracking und Marktforschung07Anzeigen-Leistung messen
08Inhalte-Leistung messen
09Marktforschung einsetzen, um Erkenntnisse über Zielgruppen zu gewinnen
Produktentwicklung10Produkte entwickeln und verbessern

Tabelle 1: Übersicht der Purposes

AnwendungIDVerarbeitungszweckRechtsgrundlage
Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation01Genaue Standortdaten verwendenZustimmung oder nicht verwendet
02Geräteeigenschaften zur Identifikation aktiv abfragen

Tabelle 2: Übersicht der Special Features

2. INFOnline Consent String Notation

2.1 Warum eine eigene Notation

Das TCF 2.0 Framework sieht für die Speicherung und Übermittlung des Consents eine eigene Notation vor, die am Ende eine Zeichenkette mit dynamischer Länge vorsieht. Diese wird schlussendlich lokal im Browser abgespeichert (LocalStorage oder Cookies). Für die INFOnline ist diese Zeichenkette für die Verarbeitung der Messdaten denkbar ungeeignet, da sie zum einen zu viele unnötige Informationen enthält und zum anderen eine schnelle Abfrage des Consents für einen bestimmten Vendor ohne vorheriges Parsen nicht zulässt.

Aus diesem Grund hat sich die INFOnline dazu entschlossen den Consent für die in der Messung nachgelagerten Vendoren (IVW, agof, etc.) in einer wesentlich kompakteren Zeichenkette mit einer auf einer Bitfeld-Arithmetik bestehenden Notation abzulegen.

2.2 Darstellung der Notation

Unten finden sie eine Abbildung zur INFOnline Notation des Consent Strings:

Abbildung 1: INFOnline Consent String Format

2.3 Erläuterung

Der Consent String der INFOnline hat wie der tc-string im TCF 2.0 Framework eine dynamische Länge, die allerdings von der INFOnline vorgegeben wird. Im Gegensatz zum tc-string ist der Consent string der INFOnline in der Summe wesentlich kürzer. Aktuell hat die Zeichenkette eine definierte Länge von 14 Zeichen. Diese Länge kann die INFOnline in Zukunft beliebig erhöhen und somit um weitere Vendoren erweitern.

Die Zeichenkette verfügt über einzelne reservierte Felder mit einer definierten Start- und Endposition. Gestartet wird an Position 0 und die Felder haben folgende Bedeutung:

  • 1. Feld(0-1): Die verwendete CMP
  • 2. Feld(2-5): INFOnline Consent
  • 3. Feld(6-9): agof ddf Consent
  • 4. Feld(10-13): Platzhalter für weitere Consent-Parameter
     

Jedes Feld ist hexadezimal kodiert und kann entsprechend die Zahlenbereiche 00-FF für einen 2-stelligen Bereich und 0000-FFFF für einen 4-stelligen Bereich aufnehmen. Bis auf das erste Feld (einfache nummerische Aufzählung) handelt es sich bei den übrigen Feldern um Bitfelder. Diese speichern über eine Bitfeld-Arithmetik den Consent des entsprechenden Vendors

2.4 Umrechnungstabelle für Purposes in Bitfeld

Für die Ermittlung des Consents für einen Vendor kann die unten dargestellte Umrechnungstabelle genutzt und das daneben skizzierte Beispiel genutzt werden:

Abbildung 2: Umrechnungstabelle

Hinweis

Das Bitfeld is hexadezimal kodiert!

2.5 Praxisbeispiel für einen INFOnline Consent String

Hier ein Praxisbeispiel für einen INFOnline Consent String, um die Berechnungsgrundlage und Notation zu veranschaulichen:

Angenommen ein Publisher nutzt die INFOnline Messung, ist Mitglied in der agof und es werden Messdaten für die daily digital facts (kurz: ddf) erfasst und verarbeitet. Damit muss der Consent für 3 Vendoren ermittelt und übertragen werden. Nun muss man natürlich wissen, welche Purposes für diese Vendoren als minimale Voraussetzung gelten, damit eine rechtliche Grundlage besteht die Messdaten für eben diese drei Vendoren zu verarbeiten:

  • INFOnline -> TCF 2.0 Purpose 8
  • agof ddf -> TCF 2.0 Purposes 1 und 9

 
Hinweis:
Grundsätzlich lassen sich die Purposes der Globalen Vendor Liste des IAB für TCF 2.0 entnehmen.

Nun kann man anhand der Umrechnungstabelle für die einzelnen Purposes den entsprechenden Wert ermitteln:

  • Für die INFOnline ergibt sich der 4-stellige Hex-Wert 0080 für Purpose 8. Da die INFOnline nur Purpose 8 benötigt stellt dieser Wert auch das hexadezimal kodierte Bitfeld dar.
  • Für die agof ddf ergeben sich die Hex-Werte 0001 (für Purpose 1) und 0100 (für Purpose 9). Die beiden Werte werden nun einfach addiert und als Ergebnis erhält man 0101 für das hexadezimal kodierte Bitfeld.
  • Für das Platzhalter-Bitfeld wird standardmäßig die 0000 gesetzt.
     

Nun muss die drei Bitfelder nur noch zusammenfügen und erhält somit für die INFOnline und die agof ddf die Zeichenkette 008001010000. Anschließend stellt man noch das Bitfeld für die verwendete CMP voran. Hierbei gilt es zu unterscheiden, ob der Consent über eine TCF 2.0 konforme CMP, keine CMP oder eine andere CMP ermittelt wurde. Bei der automatischen Verarbeitung des Consents über eine TCF 2.0 konforme CMP steht im ersten Feld des INFOnline Consent Strings immer 01. Falls Sie den Consent nicht über eine TCF 2.0 konforme CMP ermittelt haben würde hier der Wert FF stehen. Haben Sie keine CMP für die Ermittlung des Consents genutzt muss im ersten Feld der Wert 00 stehen.

Angenommen die Verarbeitung des Consents geschieht automatisch, so ergibt sich somit ein INFOnline Consent String mit der Ausprägung 01008001010141. Dieser Consent String stellt auch das Minimum der möglichen Informationen für eine rechtliche Grundlage zur Verarbeitung der Messdaten für alle 3 Vendoren dar.

3. Automatische Verarbeitung von TCF 2.0 konformen Consent

3.1 Voraussetzungen

Damit eine automatisierte Verarbeitung eines TCF 2.0 konformen Consents innerhalb der Messung stattfinden kann, muss ein Publisher eine TCF 2.0 konforme CMP nutzen. Dafür muss die CMP das IAB TCF 2.0 Toolkit über eine Stub-Funktion zur Laufzeit im Browser zur Verfügung stellen. Erst wenn diese Voraussetzungen erfüllt sind, kann eine automatisierte Verarbeitung und Übermittlung stattfinden. Wenn Sie nicht sicher sind, ob sie die Voraussetzung erfüllen dann wenden sie sich bitte an Ihren CMP Anbieter. In der Regel arbeiten alle TCF 2.0 konformen CMPs nach dieser Vorgabe.

3.2 Ermittlung

Hier finden sie einen Ablaufplan, der die automatische Ermittlung, Verarbeitung und Übertragung der Consent Information im Messskript darstellt:

Hier ein Ablaufplan wie die INFOnline den Consent über die TCF 2.0 API extrahiert und verarbeitet:

3.3 Übertragung

Die Übermittlung des Consents erfolgt im Request Parameter ct und wird bei jeden Messaufruf, mit dem automatisch ermittelten oder manuell gesetzten Consent mitgeschickt. Falls ein Publisher weder über eine TCF 2.0 kompatible CMP verfügt noch den Consent manuell setzt, wird ein Standard Consent Wert von 00000000000000 übermittelt.

3.4 Zwischenspeicherung

Der ermittelte Consent wird in Form eines First-Party Cookies im Browser des Nutzers abgespeichert. Der Cookie hat dabei ein maximales Ablaufdatum. Der Cookie läuft somit auf Grund des Jahr 2038 Problems am Tue, 19 Jan 2038 03:14:07 GMT regulär ab.

Zusätzlich zum Consent wird auch das Datum der Consent Entscheidung im Cookie als Unix-Epoch-Timestamp abgelegt. Ändert der Nutzer im Laufe der Zeit seine Consent Entscheidung über die CMP ab, aktualisiert das Messskript automatisch den Wert und das Datum im Cookie.

3.5 Auswirkungen auf die Implementierung beim Publisher

Bei einer automatischen Verarbeitung des Consents über eine TCF 2.0 konforme CMP gibt es keine Auswirkungen auf die Implementierung. Sie müssen keine Änderung vornehmen.

4. Manuelle Übermittlung des Consents durch den Publisher

4.1 Voraussetzungen

Eine manuelle Übermittlung des Consents durch einen Publisher ist dann nötig, wenn:

  • das Angebot Daten, die der DSVGO unterliegen, verarbeitet und eine Rechtsgrundlage vom Nutzer hierzu eingeholt werden muss.
  • das Angebot Mitglied der agof ist und an der daily digital fact und/oder an der digital campaign facts partizipiert.
  • das Angebot keine CMP oder eine nicht TCF 2.0 konforme CMP für die Einholung der Rechtsgrundlage nutzt.

4.2 Übermittlung durch den Publisher

Für eine manuelle Übermittlung des Consents ohne TCF 2.0 stehen dem Publisher über das Messskript der INFOnline 2 Varianten zur Verfügung:

Variante 1: Übermittlung durch eine öffentliche Methode (lange Form)

<script type="text/javascript">
// Manuelle Übermittlung des Consent
iom.consent('00008001010000');
// Messaufruf
iom.count({
  st: 'angebotskennung', // Site
  cp: 'seitencode', // Seitencode
  co: 'kommentar' // Kommentar
});
</script>

Variante 1: Übermittlung durch eine öffentliche Methode (kurze Form)

<script type="text/javascript">
// Manuelle Übermittlung des Consent
iom.ct('00008001010000');
// Messaufruf
iom.c({
  st: 'angebotskennung', // Site
  cp: 'seitencode', // Seitencode
  co: 'kommentar' // Kommentar
});
</script>

Variante 2: Übermittlung im Messaufruf (lange Form)

<script type="text/javascript">
// Messaufruf
iom.count({
  st: 'angebotskennung', // Site
  cp: 'seitencode', // Seitencode
  co: 'kommentar' // Kommentar
  ct: '00008001010000' // Consent
});
</script>

Variante 2: Übermittlung im Messaufruf (kurze Form)

<script type="text/javascript">
// Messaufruf
iom.c({
  st: 'angebotskennung', // Site
  cp: 'seitencode', // Seitencode
  co: 'kommentar' // Kommentar
  ct: '00008001010000' // Consent
});
</script>