Search Knowledge Base by Keyword
TCF 2.0 Integration in SZMnG
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 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.
| Anwendung | ID | Verarbeitungszweck | Rechtsgrundlage |
|---|---|---|---|
| Cookies setzen | 01 | Informationen auf einem Gerät speichern und/oder abrufen | Zustimmung oder nicht verwendet |
| Technisches Targeting | 02 | Auswahl einfacher Anzeigen | Zustimmung, berechtigtes Interesse oder nicht verwendet |
| Profile Targeting | 03 | Ein personalisiertes Anzeigen-Profil erstellen | „ |
| „ | 04 | Personalisierte Anzeigen auswählen | „ |
| „ | 05 | Ein personalisiertes Inhalts-Profil erstellen | „ |
| „ | 06 | Personalisierte Inhalte auswählen | „ |
| Tracking und Marktforschung | 07 | Anzeigen-Leistung messen | „ |
| „ | 08 | Inhalte-Leistung messen | „ |
| „ | 09 | Marktforschung einsetzen, um Erkenntnisse über Zielgruppen zu gewinnen | „ |
| Produktentwicklung | 10 | Produkte entwickeln und verbessern | „ |
Tabelle 1: Übersicht der Purposes
| Anwendung | ID | Verarbeitungszweck | Rechtsgrundlage |
|---|---|---|---|
| Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation | 01 | Genaue Standortdaten verwenden | Zustimmung oder nicht verwendet |
| „ | 02 | Gerä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 Consent
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. Zusätzlich zur ddf werden auch Messdaten für die daily campaign facts (kurz: dcf) verarbeitet. Damit muss der Consent für zwei 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 -> TCF 2.0 Purposes 1, 7 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
0080für Purpose 8. Da die INFOnline nur Purpose 8 benötigt stellt dieser Wert auch das hexadezimal kodierte Bitfeld dar. - Für die agof ergeben sich die Hex-Werte
0001(für Purpose 1),0040(für Purpose 7) und0100(für Purpose 9). Die Werte werden wieder addiert und man erhält das hexadezimal kodierte Bitfeld0141.
Nun muss die drei Bitfelder nur noch zusammenfügen und erhält somit für die INFOnline und agof die Zeichenkette 0000800141. 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 01008000141. Dieser Consent String stellt auch das Minimum der möglichen Informationen für eine rechtliche Grundlage zur Verarbeitung der Messdaten für alle zwei 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.
Hinweis
Seitens INFOnline wird empfohlen folgende Einbau-Reihenfolge einzuhalten. Zunächst soll im Seitenquelltext das CMP-Script geladen werden und im Anschluss daran der SZM-Tag.
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 0000000000 ü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 von 4 Wochen.
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('0000800141');
// 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('0000800141');
// 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: '0000800141' // 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: '0000800141' // Consent
});
</script>
5. Hinweise zur Consent-Verarbeitung
5.1 INFOnline/IVW Vendor 730 „flexible purpose 8“ (Legitimes Interesse vs. Consent)
5.1.1 Legitimes Interesse
Bislang gehen wir davon aus, dass die Verwendung unseres pseudonymen Messverfahrens (ehemals SZMnG) weiterhin von dem überwiegenden berechtigten Interesse (gem. Art. 6 Abs. 1 f) DSGVO) des Webseitenbetreibers erfasst wird und das pseudonyme Messverfahren damit ohne Einwilligung des Webseitenbesuchers verwendet werden kann.
Demgemäß haben wir die technischen Voraussetzungen unseres Messverfahrens so eingerichtet, dass eine Verarbeitung von Nutzerdaten, unabhängig von der Erteilung einer konkreten Einwilligung des Webseitenbesuchers, erfolgt.
5.1.2 Consent
Sollten Sie sich gegen das berechtigte Interesse (gem. Art. 6 Abs. 1 f) DSGVO) im Rahmen der Datenerhebung für INFOnline (Vendor 730) entscheiden, müssen Sie aktiv programmatische Maßnahmen ergreifen, um die Ausspielung des SZM-Tags zu unterbinden. Die Ausspielung des SZM-Tags darf dann erst nach gegebenem Consent durch den Nutzer erfolgen.
Die Umsetzung der Abfrage (programmatische Maßnahme) ist durch das Digital-Angebot eigenständig zu realisieren. Aufgrund der unterschiedlichen Systeme – sowohl im Bereich CMS als auch CMP – ist es nicht möglich, hierfür eine Standardvorlage zur Verfügung zu stellen.
Hinweis
Erfolgt keine programmatische Maßnahme, wird die Datenerhebung/-verarbeitung unter dem legitimen Interesse im INFOnline/IVW-Kontext standardmäßig verarbeitet.
5.2 agof studies Vendor 785 „Purposes 1,7,9“ (Consent)
Die Verarbeitung erfolgt gemäß Weisung der agof.