INFOnline Consent String Notation¶

1.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 etc.) in einer wesentlich kompakteren Zeichenkette mit einer auf einer Bitfeld-Arithmetik bestehenden Notation abzulegen.

1.2 Darstellung der Notation¶

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

_{Tabelle 1: INFOnline Consent String Format}

1.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 10 Zeichen. Diese Länge kann die INFOnline in Zukunft beliebig erhöhen und somit um weitere Vendoren erweitern. Für Apps gelten ergänzende Regeln, siehe Abschnitt 5.

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): Zusätzlicher 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.

1.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:

Umrechnungstabelle

*Special Feature Options

2. Automatische Verarbeitung von TCF 2.0 konformen Consent¶

2.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.

2.2 Ü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.

2.3 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.

2.4 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.

3. Manuelle Übermittlung des Consents durch den Publisher, nur gültig pseudonyme Standalone Messung¶

3.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 keine CMP oder eine nicht TCF 2.0 konforme CMP für die Einholung der Rechtsgrundlage nutzt.

3.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)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

Variante 2: Übermittlung im Messaufruf (lange Form)

1
2
3
4
5
6
7
8
9

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

1
2
3
4
5
6
7
8
9

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

4. Hinweise zur Consent-Verarbeitung¶

4.1 IAB Vendor 730 (INFOnline) Purpose 1 und 8¶

4.1.1 Legitimes Interesse¶

Demgemäß haben wir die technischen Voraussetzungen unseres Messverfahrens so mit dem Measurement Manager erweitert, dass eine Verarbeitung von Nutzerdaten, abhängig von der Erteilung einer Einwilligung des Webseitenbesuchers, erfolgt.

4.1.2 Consent unter Standalone Lösung pseudonyme Messung¶

Setzen Sie aktuell die Standalone Lösung der pseudonymen Messung ein, ist es erforderlich, den Request seit dem 1. Dezember 2021 nur unter Consent zu stellen. 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.

5. Consent String in Apps (IOLib)¶

Dieser Abschnitt gilt für die pseudonyme App-Library (IOLib) unter iOS und Android, sowohl für die Messung in Deutschland (Session-Typ SZM) als auch in Österreich (Session-Typ OEWA).

5.1 Automatische oder manuelle Verarbeitung¶

Legt eine CMP die TCF-Daten im nativen Speicher der App ab (UserDefaults bzw. SharedPreferences, Schlüssel IABTCF_*), erzeugt die IOLib den Consent String selbst. Andernfalls übergeben Sie ihn mit der Methode setCustomConsent (iOS, Android).

5.2 Aufbau¶

Verwenden Sie in Deutschland und Österreich 10 Zeichen. Die IOLib prüft nur, ob der String aus Hex-Zeichen besteht, 2 Zeichen plus ein Vielfaches von 4 lang ist und mindestens einen 4-stelligen Block je Vendor der App-Konfiguration enthält. Ein 10-stelliger String erfüllt das in beiden Märkten.

Das Bitfeld für Vendor 730 setzt sich aus den Purposes 1 bis 10 zusammen (Umrechnungstabelle in Abschnitt 1.4). Ein Purpose wird gesetzt, wenn

• Vendor 730 Consent hat und der Purpose Consent hat, oder
• Vendor 730 Legitimate Interest hat und der Purpose Legitimate Interest hat.

Beispiele (Deutschland und Österreich):

5.3 Wirkung auf die Messung¶

Vor dem Versand verwirft die IOLib alle Messdaten, bei denen das Bitfeld für Vendor 730 nicht mindestens Purpose 1 und Purpose 8 enthält (0081). Das gilt nicht, wenn die CMP IABTCF_gdprApplies auf 0 gesetzt hat. Fehlt dieser Wert, geht die IOLib davon aus, dass die DSGVO gilt.

Die IOLib übernimmt den Consent beim Erfassen in jedes Ereignis. Ereignisse, die erfasst werden, bevor der Consent gesetzt ist, tragen den Default-Consent und werden verworfen.

Für Österreich (ÖWA) prüft die IOLib den Consent ab iOS 2.5.0 bzw. Android 2.4.0.

5.4 Hybride Apps mit CMP in der WebView¶

Läuft die CMP nur in der WebView, gelangen keine TCF-Daten in den nativen Speicher der App. Die IOLib kann den Consent dann nicht automatisch ermitteln. Rechnen Sie ihn in der WebView um und übergeben Sie ihn an die App:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

function toIoConsent(tcData) {
  let bits = 0;
  const add = m => Object.keys(m || {}).forEach(p => {
    if (m[p] && p >= 1 && p <= 10) bits |= 1 << (p - 1);
  });
  if (tcData.vendor.consents[730]) add(tcData.purpose.consents);
  if (tcData.vendor.legitimateInterests[730]) add(tcData.purpose.legitimateInterests);
  return '01' + bits.toString(16).padStart(4, '0') + '0000';
}

__tcfapi('addEventListener', 2, (tcData, ok) => {
  if (ok && ['tcloaded', 'useractioncomplete'].includes(tcData.eventStatus)) {
    const consent = toIoConsent(tcData);
    if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.ioConsent) {
      window.webkit.messageHandlers.ioConsent.postMessage(consent); // iOS: WKScriptMessageHandler "ioConsent"
    } else if (window.IOConsent) {
      window.IOConsent.setConsent(consent); // Android: addJavascriptInterface(..., "IOConsent")
    }
  }
});

Das Beispiel gilt für Deutschland und Österreich: Die letzten vier Zeichen sind immer 0000.

In der App:

1. Den empfangenen String speichern und mit setCustomConsent setzen. Unter iOS empfängt ihn ein WKScriptMessageHandler mit dem Namen ioConsent, unter Android ein per addJavascriptInterface unter dem Namen IOConsent registriertes Objekt mit einer Methode setConsent(String) (annotiert mit @JavascriptInterface).
2. Nach jedem Start der Session, vor dem ersten Ereignis, den gespeicherten String erneut setzen. Ohne diesen Schritt gehen alle Ereignisse verloren, die entstehen, bevor die WebView geladen ist.

Alternativ setzen Sie eine CMP im nativen Teil der App ein, die die TCF-Daten in den nativen Speicher schreibt. Dann ermittelt die IOLib den Consent automatisch.

5.5 Prüfen¶

Prüfen Sie die Umsetzung vor der Veröffentlichung mit aktiviertem Debug-Modus: unter iOS mit IOLDebugLevelTrace, unter Android mit IOLSession.setDebugModeEnabled(true). Nur dann zeigt die IOLib an, ob Messdaten verworfen werden.

• Richtig: consent (iOS) bzw. getConsent() (Android) liefert den erwarteten String, und im Log steht „Keeping N consent filtered events out of N total enqueued events“ mit zwei gleichen Zahlen.
• Fehler: „Not a valid IO TCF consent“ (falsches Format), „did not pass the consent validation and will be deleted“ oder „Removed N events“ mit N größer 0 (Zustimmung fehlt oder ist unvollständig), unter iOS „Consent could not be set because the session is not active“ (Consent vor dem Start der Session gesetzt). Unter Android löst setCustomConsent vor initIOLSession eine Exception aus.

Deaktivieren Sie den Debug-Modus vor der Veröffentlichung der App.