AdMob- und AdSense-Programmrichtlinien

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 & Consent Framework (TCF) fertiggestellt. Das TCF 2.0 ist nun auch komplett in Google eingebunden.

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 einen Bericht mit festgestellten Fehlern. Darüber hinaus wird ein Kulanzzeitraum von 150 Tagen für die Fehlerbehebung eingeräumt.


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-Reaktionszeit von 500 ms: Seit dem 9. November 2020 muss eine Plattform zur Einwilligungsverwaltung (Consent Management Platform, CMP) 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 ohne zeitliche Beschränkung, bis die Plattform reagiert, die Sie verwenden.

Häufige Fehler beheben

Wenn Sie diese Handlungsempfehlungen umsetzen, 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.

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 dies der Fall ist, 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. Das Einwilligungsdatum muss jedes Mal das neue Datum des betreffenden Strings für die Einwilligung sein.
Empfohlene Maßnahme: Ihre CMP sollte 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 eine CMP nicht sofort reagiert, wird die Anfrage möglicherweise nicht monetarisiert.

Begründung

Google hält sich an die IAB-Spezifikation, die festlegt, dass eine CMP sofort auf die Funktion „AddEventListener“ reagieren sollte. Geschieht dies nicht, wird die Anfrage möglicherweise nicht monetarisiert.

Eine Reaktion ist 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 der 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/MobileAppID: 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 Anfragen mit dem Fehler, die in der vorherigen Woche ermittelt 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 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 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 verbleibenden Kulanzzeitraum 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 verbleibenden Kulanzzeitraum 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 berücksichtigt.

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. Bei Anzeigenanfragen werden während des Kulanzzeitraums nicht personalisierte Anzeigen berücksichtigt. Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr berücksichtigt.

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 jetzt offiziell eingebunden ist, muss die Einwilligung der Nutzer, die TCF 2.0 verwenden, neu eingeholt werden. Innerhalb des Kulanzzeitraums können die Publisher den Zeitpunkt aber selbst festlegen.

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.

Im Kulanzzeitraum werden personalisierte und nicht personalisierte Anzeigen ohne Beeinträchtigung der Monetarisierung unter Berücksichtigung der jeweiligen Einstellungen ausgeliefert, einschließlich der Einstellungen für Anzeigentechnologie-Anbieter für personalisierte Anzeigen. Nach Ablauf des Kulanzzeitraums werden keine Anzeigenanfragen mehr berücksichtigt.

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.

Im Kulanzzeitraum liefert Google Anzeigen für diese Anzeigenanfragen gemäß dem TC-String und unter Einhaltung der Richtlinien von Google aus. Nach Ablauf des 150-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 müssen darauf achten, die Felder PublisherCC und PurposeOneTreatment richtig festzulegen, 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 das berechtigte Interesse bei den anderen Zwecken 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 verbleibenden Kulanzzeitraum 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 berücksichtigt.

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

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

Wenn Sie die Funktion für Anzeigenanfragen nicht manuell aufrufen, arbeiten Sie mit Ihrer CMP zusammen, um sicherzustellen, dass getTCData berücksichtigt 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:

  • CMP legt &gdpr=1 fest.
  • &gdpr_consent= ist in der Anfrage enthalten, aber der TC-String ist leer.
Bitten Sie Ihre CMP, zu prüfen, ob ihre 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”

CMPs (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

Die CMP muss 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
 

Die CMP muss 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. Bei Anzeigenanfragen werden während des Kulanzzeitraums weiterhin unter Berücksichtigung der jeweiligen Einstellungen nicht personalisierte Anzeigen ausgeliefert. Nach Ablauf des 150-tägigen Kulanzzeitraums werden Anzeigenanfragen verworfen und nicht mehr berücksichtigt.

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

Es muss eine vom IAB bestätigte CMP verwendet werden, deren ID in den TC-Strings richtig angegeben ist.

Wenn eine CMP gültig war, als ein TC-String generiert wurde, und wenn die CMP später von der IAB gelöscht wurde, müssen Sie die Einwilligung mithilfe einer gültigen CMP neu einholen.

3.2 Das Erstellungsdatum des TC-Strings liegt mehr als 13 Monate zurück. Die CMP 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. Die CMP 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.

Im Kulanzzeitraum werden personalisierte und nicht personalisierte Anzeigen ohne Beeinträchtigung der Monetarisierung unter Berücksichtigung der jeweiligen Einstellungen ausgeliefert, einschließlich der Einstellungen für Anzeigentechnologie-Anbieter für personalisierte Anzeigen. Nach Ablauf des 150-tägigen Kulanzzeitraums werden Anzeigenanfragen verworfen und nicht mehr berücksichtigt.

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

Im Kulanzzeitraum liefert Google Anzeigen für diese Anzeigenanfragen gemäß dem TC-String und unter Einhaltung der Richtlinien von Google aus. Nach Ablauf des 150-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 Ihre CMP an, Out-of-Band-Signale aus den TC-Strings zu entfernen.
5.2 Der TC-String hat einen globalen Geltungsbereich. Weisen Sie Ihre CMP 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 unter Berücksichtigung der jeweiligen Einstellungen ausgeliefert.

Fehler Beschreibung Empfohlene Maßnahme
6.1 Die Version des TC-Strings lautet 1 oder 1.1 (1.0-String). Die CMP muss 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. Die CMP 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.  Die CMP muss die TC-String-Implementierungsfehler beheben.
7.7 Der Sprachcode ist ungültig. Die CMP muss die TC-String-Implementierungsfehler beheben.
7.8 Die Version des TC-Strings lautet weder 1 noch 2. Die CMP muss TCF 2.0-Strings senden.
7.9 Die Version des AC-Strings lautet nicht 1. Die CMP muss die Version des AC-Strings auf 1 setzen.

Kein Kulanzzeitraum, Probleme mit Strings für die zusätzliche Einwilligung

Wenn diese Probleme auftreten, behandelt Google den String für die zusätzliche Einwilligung als ungültig. Weitere Anbieter werden nicht berücksichtigt und nur der TC-String wird verwendet.

Fehler Beschreibung Empfohlene Maßnahme
8.1 Beim String für die zusätzliche Einwilligung fehlt das Versionstrennzeichen (~). Die CMP muss ~ als zweites Zeichen des Strings für die zusätzliche Einwilligung verwenden, um die Versionsnummer von der Liste der Anbieter zu unterscheiden, für die die Einwilligung erteilt wurde.
8.2 Der String für die zusätzliche Einwilligung enthält eine Anbieterliste, die nicht der erwarteten Formatierung entspricht (int64-Liste mit Trennzeichen ' . ') Die CMP muss die Implementierungsfehler beim String für die zusätzliche Einwilligung beheben.

 

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

Benötigen Sie weitere Hilfe?

Anmelden, um weitere Supportoptionen zu erhalten und das Problem schnell zu beheben