Fehlerbehebung bei der TCF-Implementierung 2.0

Kulanzzeiträume und Vorschläge zur Fehlerbehebung

IAB Europe hat die mit dem IAB Tech Lab und gemeinsamen Partnerunternehmen entwickelte Version 2.0 seines Transparency and Consent Framework jetzt fertiggestellt. Das TCF 2.0 ist nun auch komplett in Google integriert.

Damit Publisher genügend Zeit haben, Fehler und Fehlkonfigurationen zu bearbeiten, die im Zusammenhang mit der Einführung des Transparency & Consent Framework 2.0 des IAB Europe stehen, erstellt Google Publishern einen Bericht mit von uns festgestellten Fehlern. Darüber hinaus wird ein Kulanzzeitraum von 90 Tagen für die Fehlerbehebung eingeräumt, der ab der Verfügbarkeit unserer Integration des IAB TCF 2.0 gilt.


In diesem Artikel finden Sie weitere Informationen, wie Sie Fehler bei der Implementierung des TCF 2.0 beheben können. Dazu gehören:


Aktualisierte Anleitung

Aktualisierungen

  • CMP-Antwortzeit von 500 ms: Seit dem 9. November 2020 müssen Content Management Provider mit Einbindung von TCF 2.0 nicht mehr innerhalb von 500 ms auf Ad Manager-, AdSense- oder AdMob-Anfragen reagieren. Ad Manager, AdSense und AdMob warten jetzt auf unbestimmte Zeit, bis eine Antwort vom CMP eingeht, den Sie implementiert haben.

Häufige Fehler beheben

Wenn Sie diese Handlungsempfehlungen beachten, können Sie einige der häufigsten Fehler in Ad Manager, AdSense und AdMob beheben: 

Die Einwilligung von Nutzern mit TC-Strings, über die keine Einnahmen erzielt werden, erneuern
(Fehler 1.1, 3.1, 4.1, 5.1, 5.2 und 6.1)

Ähnliche Fehler

Fehler 1.1. Diese Anleitung kann auch auf die Fehler 3.1, 4.1, 5.1, 5.2 und 6.1 angewendet werden.

Aktualisierte Anleitung

Es könnte hilfreich sein, die Einwilligung der Nutzer neu einzuholen.

Publisher profitieren von einer Erneuerung der Einwilligung, wenn sie zuvor Strings mit globalem oder Out-of-Band-Geltungsbereich, ungültige CMP-IDs (von Tests) oder ungültige GVL-IDs (von Tests) verwendet haben oder für Google als Anbieter während der Implementierung bisher keine rechtmäßige Einwilligung eingeholt hatten.

Begründung

Publisher profitieren von einer Erneuerung der Einwilligung, wenn sie zuvor Strings mit globalem oder Out-of-Band-Geltungsbereich, ungültige CMP-IDs (von Tests) oder ungültige GVL-IDs (von Tests) verwendet haben oder für Google als Anbieter während der Implementierung bisher keine rechtmäßige Einwilligung eingeholt hatten.

Fehler 1.1, 1.2, 1.3: Sie sollten unbedingt prüfen, ob diese Fehler erhebliche Auswirkungen auf die Anzahl der Zugriffe haben. Wenn diese Fehler einen großen Einfluss auf die Zugriffe haben, sollten Sie ein Problem auf CMP-Seite ausschließen und dafür sorgen, dass Google für die erforderlichen Zwecke eine Berechtigung erteilt wird und damit als Anbieter mit Einwilligung UND berechtigtem Interesse (Anbieter-ID 755) gilt.

IAB-Spezifikation

Gemäß IAB-Spezifikationen dürfen Consent-Strings von CMPs 13 Monate lang im Cache gespeichert werden.

Einige CMPs haben in der Vergangenheit das Datum der erstmaligen Einwilligung beibehalten und diese einfach verlängert, was nicht den Vorgaben entspricht. Als Einwilligungsdatum sollte jedes Mal das neue Datum des betreffenden Consent-Strings gelten.
Ihr CMP muss Aufrufe von AddEventHandler innerhalb von 500 ms beantworten
(Fehler 2.1a, 2.1b, 2.2a, 2.2b und 2.2c)

Ähnliche Fehler

Fehler 2.1a. Diese Anleitung kann auch auf die Fehler 2.1b, 2.2a, 2.2b und 2.2c angewendet werden.

Aktualisierte Anleitung

Es kann zwar nicht mehr zu einer Zeitüberschreitung kommen, aber wir empfehlen, dass CMPs ihre Implementierungen genau beobachten, um sofort auf Aufrufe an AddEventListener getTCData reagieren zu können

Wenn ein CMP nicht antwortet, wird die Anfrage möglicherweise nicht monetarisiert.

Begründung

Google hält sich an die IAB-Spezifikation, die festlegt, dass ein CMP sofort auf die Funktion „AddEventListener“ antworten sollte. Wenn ein CMP nicht sofort reagiert, wird die Anfrage möglicherweise nicht monetarisiert.

CMP-Antworten sind außerdem Teil der Ereigniskette, die sich darauf auswirkt, wie schnell eine Anzeigenanfrage gestellt werden kann. Bei einer kürzeren Zeitspanne zwischen dem Laden der Seite und Anzeigenanfragen gehen weniger Impressionen für den Publisher verloren. 

IAB-Spezifikation

Anwendbare IAB-Spezifikation: IAB AddEventListener specification (auf GitHub)

Der AddEventListener-Callback sollte unmittelbar nach der Registrierung mit den aktuellen TC-Daten aufgerufen werden, auch wenn der CMP-Status noch geladen wird und dem CMP unvollständige TC-Daten vorliegen. Dadurch kann das aufrufende Skript auf die registrierte ListenerId zugreifen. Außerdem sollte der Callback bei jeder Änderung eines TC-Strings aufgerufen werden, sofern er nicht mit RemoveEventListener entfernt wird.

Fehlerbericht

Sollte bei einer oder mehreren Websites oder Apps ein Problem mit dem TC-String festgestellt werden, benachrichtigen wir die Publisher über die Benutzeroberfläche des jeweiligen Produkts. Publisher können in ihrem Konto auf der Seite „EU-Nutzereinwilligung“ auf TCF-Fehlerbericht herunterladen klicken, um einen detaillierten Bericht zu den Fehlern herunterzuladen, die in den letzten sieben Tagen festgestellt wurden.

Dieser Bericht ist nur verfügbar, wenn in den letzten sieben Tagen Fehler festgestellt wurden.
So greifen Sie auf die Seite „EU-Nutzereinwilligung“ und auf den TCF-Fehlerbericht zu: 
  • Ad Manager: Klicken Sie auf Administrator und dann EU-Nutzereinwilligung.
  • AdMob und AdSense: Klicken Sie auf Blockierungen und dann EU-Nutzereinwilligung.

Der Bericht enthält zu jedem festgestellten Fehler folgende Informationen: 

  • Domain/MobileAppIDMobileAppID: Die Website oder App, die falsch konfiguriert ist.
  • Anzeigenblockpfad: Der Anzeigenblock, der mit dem Fehler in Verbindung steht.
  • Fehlercode: Der Code, der dem Fehler zugewiesen ist. 
  • Fehleranzahl: Die Anzahl der Abfragen mit dem Fehler, die in der vorherigen Woche beobachtet wurden.
  • Zuletzt gefunden am: Das Datum, an dem der Fehler das letzte Mal festgestellt wurde. 

Anhand der Fehlercodes im Bericht können Publisher die empfohlenen Maßnahmen in den folgenden Tabellen zur Fehlerbehebung finden und die Fehler beheben.

Kulanzzeitraum

Der Kulanzzeitraum kann je nach Fehlertyp geringfügig voneinander abweichen. In der folgenden Tabelle werden die verschiedenen Kulanzzeiträume mit ihren jeweiligen Anwendungsbedingungen definiert.

Der Kulanzzeitraum wurde um weitere 60 Tage verlängert und endet jetzt Mitte Januar 2021.
Festlegung des Kulanzzeitraums Übersicht
Kulanzzeitraum 0: Fehlkonfiguration

Zeitraum für die Behebung des Fehlers, der auftritt, wenn Publisher ihre CMPs (Consent Management Provider) falsch konfiguriert und keinen gültigen TC-String gesendet haben. Google räumt Publishern einen Zeitraum von 60 Tagen ein, um mithilfe der DSGVO-Einstellungen für Anzeigentechnologie-Anbieter Fehlkonfigurationen zu korrigieren. In diesem Zeitraum ist die Monetarisierung nicht beeinträchtigt. Nach 60 Tagen liefert Google für den Rest des Kulanzzeitraums nicht personalisierte Anzeigen aus.

Diese Fehler haben immer Vorrang vor anderen Fehlertypen, auch wenn eine konkrete Anfrage mehrere Fehler enthält.

Anwendung des Kulanzzeitraums 0:

  • In den ersten 60 Tagen des Kulanzzeitraums können Publisher Fehlkonfigurationen beheben, ohne dass die Monetarisierung beeinträchtigt wird.
  • Für den Rest des Kulanzzeitraums werden nicht personalisierte Anzeigen unabhängig von den Einstellungen für personalisierte und nicht personalisierte Anzeigen ausgeliefert.

Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr ausgeführt.

Kulanzzeitraum 1: Probleme mit TC-Strings

Zeitraum für die Behebung schwerwiegender Fehler im TC-String. Während des Kulanzzeitraums liefert Google nur nicht personalisierte Anzeigen aus.

Der Kulanzzeitraum 1 wird auf Fehler in dieser Kategorie angewendet, wenn Probleme mit dem mit einer Anzeigenanfrage verknüpften TC-String auftreten. Anzeigenanfragen werden während des Kulanzzeitraums mit nicht personalisierten Anzeigen ausgeführt. Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr ausgeführt.

Kulanzzeitraum 2: Einwilligung muss neu eingeholt werden

Für Publisher, die TCF 2.0 einbinden, bevor Google in die Global Vendor List (GVL) des IAB aufgenommen wurde. Publisher haben die Nutzereinwilligung für Google von Nutzern außerhalb des TCF 2.0 vor der Integration von Google eingeholt. Da Google die Integration jetzt offiziell implementiert hat, muss die Einwilligung der Nutzer, die TCF 2.0 verwenden, neu eingeholt werden. Innerhalb des Kulanzzeitraums können die Publisher aber selbst festlegen, wann dies geschehen soll.

Der Kulanzzeitraum 2 wird angewendet, wenn die Einwilligung des Nutzers eingeholt werden muss. Wenn die letzte Einwilligung eines Nutzers vor mehr als 13 Monaten eingeholt wurde, sollten Sie den Kulanzzeitraum nutzen, um die Einwilligung neu einzuholen.

In diesem Kulanzzeitraum werden personalisierte und nicht personalisierte Anzeigen ohne Beeinträchtigung der Monetarisierung anhand der vorhandenen Einstellungen ausgeliefert, einschließlich der Einstellungen für Anzeigentechnologie-Anbieter für personalisierte Anzeigen. Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr ausgeführt.

Kulanzzeitraum 3: Globaler oder Out-of-Band-Geltungsbereich

Für TC-Strings mit globalem und Out-of-Band-Geltungsbereich (Ad Manager, AdMob, AdSense). Google liefert Anzeigen für diese Anzeigenanfragen gemäß dem TC-String und unter Einhaltung der Richtlinien von Google aus. Das Problem sollte aber innerhalb des Kulanzzeitraums behoben werden.

In diesem Kulanzzeitraum liefern wir Anzeigen für diese Anzeigenanfragen gemäß dem TC-String und unter Einhaltung der Richtlinien von Google aus. Nach Ablauf des 90-tägigen Kulanzzeitraums wird eine Anzeige nicht mehr ausgeliefert, wenn der TC-String den Wert „Out-of-Band“ oder „Globaler Geltungsbereich“ enthält.

 

Fehlerbehebung

Damit Publisher falsch konfigurierte Integrationen des IAB TCF 2.0 korrigieren können, haben wir die folgenden Tabellen mit den häufigsten Fehlertypen in TC-Strings und entsprechenden Empfehlungen zur Fehlerbehebung zusammengestellt. Sie können den Tabellen auch entnehmen, welcher Kulanzzeitraum gegebenenfalls für einen Fehler gilt.

In den folgenden Tabellen sehen Sie, welche Probleme bei Anzeigenanfragen auftreten können und welches Systemverhalten diese jeweils zur Folge haben.

Kein Kulanzzeitraum, keine Anzeigenauslieferung

Diese Szenarios führen immer zu abgelehnten und nicht ausgeführten Anzeigenanfragen und es gibt keinen Kulanzzeitraum zur Behebung. Deshalb haben sie immer Vorrang vor anderen Fehlertypen, auch wenn eine bestimmte Anfrage mehrere Fehler enthält.

Szenario Beschreibung Empfohlene Maßnahme
1.1 Im Hinblick auf Einwilligung oder berechtigtes Interesse ist Google als Anbieter nicht zulässig. Finden Sie heraus, ob der Nutzer Google absichtlich als Anbieter abgelehnt hat, ob CMP-Implementierungsfehler aufgetreten sind oder ob Einschränkungen für Publisher vorliegen.
1.2 Keine Einwilligung für Zweck 1 für Länder des EWR und das Vereinigte Königreich.

Finden Sie heraus, ob der Nutzer Zweck 1 absichtlich abgelehnt hat oder ob dies auf CMP-Implementierungsfehler zurückzuführen ist.

Deutsche Publisher sollten gewährleisten, dass sie die Felder PublisherCC und PurposeOneTreatment korrekt festlegen, wenn sie Nutzer nicht um ihre Einwilligung bitten.
1.3 Die Einwilligung für Zweck 1 ist vorhanden, aber es liegt keine rechtliche Basis für grundlegende Anzeigen vor.

Finden Sie heraus, ob der Nutzer die berechtigten Interessen der anderen Zwecke absichtlich abgelehnt hat oder ob dies auf CMP-Implementierungsfehler zurückzuführen ist.

Kulanzzeitraum 0: Fehlkonfiguration

Bei Anwendung des Kulanzzeitraums 0 gilt Folgendes:

  • In den ersten 60 Tagen des Kulanzzeitraums können Publisher Fehlkonfigurationen beheben, ohne dass die Monetarisierung beeinträchtigt wird.
  • Für den Rest des Kulanzzeitraums werden nicht personalisierte Anzeigen unabhängig von den Einstellungen für personalisierte und nicht personalisierte Anzeigen ausgeliefert.

Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr ausgeführt.

Fehler Beschreibung Empfohlene Maßnahme
2.1a Tag oder SDK empfängt einen TC-String nicht, weil der CMP-Status stub (Stub), loading (Wird geladen) oder error (Fehler) lautet.

Wenn Sie die Funktion zum Anfordern von Anzeigen manuell aufrufen, sollten Sie folgende Antworten erhalten: getTCData TCData.eventStatus = 'tcloaded' ODER 'cmpuishown' + 'useractioncomplete'. Diese zeigen an, dass der CMP dem Nutzer eine Auswahlmöglichkeit hinsichtlich der Einwilligung bieten kann.

Wenn Sie die Funktion zum Anfordern von Anzeigen nicht manuell aufrufen, arbeiten Sie mit Ihrem Consent Management Provider zusammen, um sicherzustellen, dass der Support für getTCData implementiert wird. Die Antwort sollte so aussehen: TCData.eventStatus = 'tcloaded' ODER 'cmpuishown' + 'useractioncomplete'. Dies zeigt an, dass die Nutzereinwilligung über die API verwendet werden kann.

2.1b

Beide Bedingungen werden erfüllt:

  • Consent Management Provider legen &gdpr=1 fest.
  • &gdpr_consent= ist in der Anfrage enthalten, aber der TC-String ist leer.
Bitten Sie Ihren Consent Management Provider, zu prüfen, ob seine APIs gemäß den technischen Spezifikationen des IAB TCF implementiert sind.
2.2a

Der TC-String kann nicht geparst werden, weil er nicht mit Base64 codiert ist.

Beispiel: "2"

Consent Management Provider (oder Publisher) sollten nur mit Base64 codierte Daten in gdpr_consent=-Parametern senden.
2.2b

Der TC-String kann aufgrund eines Decodierungsfehlers nicht geparst werden.

Beispiel: Enthält eine falsche Anzahl von Bits

Der Consent Management Provider sollte die TC-String-Implementierungsfehler beheben.
2.2c

Der TC-String kann aufgrund eines Datenfehlers nicht geparst werden.

Beispiel: Falscher Zeitstempel, Anbieter-ID ist zu lang
 

Der Consent Management Provider sollte die TC-String-Implementierungsfehler beheben.

Kulanzzeitraum 1: Probleme mit TC-Strings

Der Kulanzzeitraum 1 wird auf Fehler in dieser Kategorie angewendet, wenn Probleme mit dem mit einer Anzeigenanfrage verknüpften TC-String auftreten. Anzeigenanfragen werden während des Kulanzzeitraums weiterhin anhand der vorhandenen Einstellungen mit nicht personalisierten Anzeigen ausgeführt. Nach Ablauf des 90-tägigen Kulanzzeitraums werden Anzeigenanfragen verworfen und nicht mehr ausgeführt.

Fehler Beschreibung Empfohlene Maßnahme
3.1 Die CMP-ID ist ungültig.

Es muss ein IAB-validierter Consent Management Provider verwendet werden, dessen ID in den TC-Strings korrekt angegeben ist.

Wenn ein Consent Management Provider gültig war, als ein TC-String generiert wurde, aber der CMP später vom IAB gelöscht wurde, müssen Sie die Einwilligung mithilfe eines gültigen CMP neu einholen.

3.2 Das Erstellungsdatum des TC-Strings liegt mehr als 13 Monate zurück. Der Consent Management Provider sollte den alten TC-String löschen und die Einwilligung neu einholen.
3.3 Das Datum der letzten Aktualisierung des TC-Strings liegt mehr als 13 Monate zurück. Der Consent Management Provider sollte den alten TC-String löschen und die Einwilligung neu einholen.

Kulanzzeitraum 2: Einwilligung muss neu eingeholt werden

Der Kulanzzeitraum 2 wird angewendet, wenn die Einwilligung des Nutzers eingeholt werden muss. Wenn die letzte Einwilligung eines Nutzers vor mehr als 13 Monaten oder vor der Aufnahme von Google in die GVL eingeholt wurde, sollten Sie diesen Kulanzzeitraum nutzen, um die Einwilligung neu einzuholen.

In diesem Kulanzzeitraum werden personalisierte und nicht personalisierte Anzeigen ohne Beeinträchtigung der Monetarisierung anhand der vorhandenen Einstellungen ausgeliefert, einschließlich der Einstellungen für Anzeigentechnologie-Anbieter für personalisierte Anzeigen. Nach Ablauf des 90-tägigen Kulanzzeitraums werden Anzeigenanfragen verworfen und nicht mehr ausgeführt.

Fehler Beschreibung Empfohlene Maßnahme
4.1 Der TC-String wurde mit einer Version der GVL generiert, in der Google noch nicht aufgeführt war. Nutzen Sie die aktualisierte Version der GVL, in der Google enthalten ist, und holen Sie die Einwilligung neu ein.

Kulanzzeitraum 3: Globaler und Out-of-Band-Geltungsbereich

Der Kulanzzeitraum 3 wird angewendet, wenn Probleme mit dem globalen und dem Out-of-Band-Geltungsbereich auftreten (Ad Manager, AdMob und AdSense).

In diesem Kulanzzeitraum liefern wir Anzeigen für diese Anzeigenanfragen gemäß dem TC-String und unter Einhaltung der Richtlinien von Google aus. Nach Ablauf des 90-tägigen Kulanzzeitraums wird eine Anzeige nicht mehr ausgeliefert, wenn der TC-String den Wert „Out-of-Band“ oder „Globaler Geltungsbereich“ enthält.

Fehler Beschreibung Empfohlene Maßnahme
5.1 Der TC-String ermöglicht die Out-of-Band-Einwilligung. Weisen Sie Ihren Consent Management Provider an, Out-of-Band-Signale aus den TC-Strings zu entfernen.
5.2 Der TC-String hat einen globalen Geltungsbereich. Weisen Sie Ihren Consent Management Provider an, den Geltungsbereich der TC-Strings in „dienstspezifisch“ zu ändern.

Kein Kulanzzeitraum, Anzeigen werden ausgeliefert

Es wird kein Kulanzzeitraum angewendet. Personalisierte und nicht personalisierte Anzeigen werden weiterhin ohne Beeinträchtigung der Monetarisierung anhand der vorhandenen Einstellungen ausgeliefert.

Fehler Beschreibung Empfohlene Maßnahme
6.1 Die Version des TC-Strings lautet 1 oder 1.1 (1.0-String). Der Consent Management Provider sollte TCF 2.0-Strings senden.

Kein Kulanzzeitraum, Problembehebung durch Google

Wenn diese Probleme auftreten, werden die Behebung und die weitere Bearbeitung gemäß TCF von Google durchgeführt.

Fehler Beschreibung Empfohlene Maßnahme
7.1 gdprApplies ist nicht definiert oder auf einen ungültigen oder unlesbaren Wert festgelegt, aber es ist ein gültiger TC-String vorhanden.
7.2 Der TC-String wurde mit einer GVL-Version generiert, die neuer als die aktuelle Version ist, die der Ad Serving-Technologie von Google bekannt ist.
7.3 Einige Zwecke, Funktionen und/oder Anbieter befinden sich außerhalb des zulässigen Bereichs (unbekannt).
7.4 Der TC-String hat eine ältere tcf_policy_version als die neueste GVL. Der Consent Management Provider sollte den älteren TC-String löschen und die Einwilligung mit der aktuellen GVL neu einholen.
7.5

Eine Anfrage enthält &gdpr=1, aber in der Anfrage-URL fehlt der Parameter &gdpr_consent.

7.6 Ungültiger Publisher-Ländercode. Eine Einwilligung für Zweck 1 ist aber vorhanden.  Der Consent Management Provider sollte die TC-String-Implementierungsfehler beheben.
7.7 Der Sprachcode ist ungültig. Der Consent Management Provider sollte die TC-String-Implementierungsfehler beheben.
7.8 Die Version des TC-Strings lautet weder 1 noch 2. Der Consent Management Provider sollte TCF 2.0-Strings senden.
7.9 Die Version des AC-Strings lautet nicht 1. Der Consent Management Provider sollte die Version des AC-Strings auf 1 setzen.

Kein Kulanzzeitraum, Probleme mit AC-Strings

Wenn diese Probleme auftreten, behandelt Google den Additional Consent-String (AC-String) als ungültig. Keine weiteren Anbieter werden berücksichtigt und nur der TC-String wird verwendet.

Fehler Beschreibung Empfohlene Maßnahme
8.1 AC-String verwendet nicht das Versionstrennzeichen (~). Der Consent Management Provider sollte "~" als zweites Zeichen des AC-Strings verwenden, um die Versionsnummer von der Liste der Anbieter, für die die Einwilligung erteilt wurde, zu unterscheiden.
8.2 AC-String enthält eine Anbieterliste, die nicht der erwarteten Formatierung entspricht (int64-Liste mit Trennzeichen "."). Der Consent Management Provider sollte die AC-String-Implementierungsfehler beheben.

 

War das hilfreich?
Wie können wir die Seite verbessern?