Teil 1 von 3 zum Debugging in Attributionsberichten. Hier erfahren Sie, warum die Fehlerbehebung wichtig ist und wann Sie Berichte zur Fehlerbehebung beim Testen verwenden sollten.
Warum Sie Berichte zur Fehlerbehebung benötigen
Wenn Sie die Attribution Reporting API testen, sollten Sie prüfen, ob die Integration ordnungsgemäß funktioniert. Außerdem sollten Sie die Lücken in den Messergebnissen zwischen der auf Cookies basierenden Implementierung und der Attribution Reporting-Implementierung untersuchen und etwaige Probleme bei der Integration beheben.
Für diese Aufgaben sind Fehlerbehebungsberichte erforderlich. Daher empfehlen wir Ihnen dringend, diese einzurichten.
Glossar
Wichtige Aspekte von Debug-Berichten
Zwei Arten von Debug-Berichten
Es sind zwei Arten von Debug-Berichten verfügbar. Verwenden Sie beide, da sie unterschiedliche Anwendungsfälle erfüllen.
Berichte zur erfolgreichen Fehlerbehebung
Mit Berichten zur Fehlerbehebung wird die erfolgreiche Erstellung eines Attributionsberichts erfasst. Sie beziehen sich direkt auf einen Attributionsbericht.
Berichte zur Fehlerbehebung sind seit Chrome 101 (April 2022) verfügbar.
Ausführliche Fehlerbehebungsberichte
Ausführliche Berichte zur Fehlerbehebung geben Ihnen einen besseren Einblick in die Quelle und die Triggerereignisse. So können Sie entweder feststellen, ob Quellen erfolgreich registriert wurden, oder fehlende Berichte verfolgen und ermitteln, warum sie fehlen (Fehler in Quell- oder Trigger-Ereignissen, Fehler beim Senden oder Generieren des Berichts). Ausführliche Fehlerbehebungsberichte enthalten folgende Informationen:
- Fälle, bei denen der Browser eine Quelle erfolgreich registriert hat.
- Fälle, in denen der Browser eine Quelle nicht registriert oder ein Ereignis ausgelöst hat, was bedeutet, dass kein Attributionsbericht generiert wird.
- Fälle, in denen ein Attributionsbericht aus irgendeinem Grund nicht erstellt oder gesendet werden kann.
Ausführliche Debug-Berichte enthalten das Feld type, das entweder eine erfolgreiche Registrierung der Quelle oder den Grund beschreibt, warum ein Quell-, Trigger- oder Attributionsbericht nicht erstellt wurde.
Ausführliche Debug-Berichte sind seit Chrome 109 (Januar 2023) verfügbar. Ausgenommen hiervon sind ausführliche Debug-Berichte zur erfolgreichen Quellregistrierung, die später in Chrome 112 hinzugefügt wurden.
Sehen Sie sich Beispielberichte in Teil 2: Berichte zur Fehlerbehebung einrichten an.
Debugging-Berichte basieren auf Cookies
Wenn Sie Debug-Berichte verwenden möchten, muss der Berichterstellungsherkunft ein Cookie setzen.
Wenn der für den Empfang von Berichten konfigurierte Ursprung ein Drittanbieter ist, ist dieses Cookie ein Drittanbieter-Cookie. Dies hat einige wesentliche Auswirkungen:
- Fehlerbehebungsberichte werden nur generiert, wenn Drittanbieter-Cookies im Browser des Nutzers zugelassen sind.
- Debugging-Berichte sind nach der Einstellung von Drittanbieter-Cookies nicht mehr verfügbar.
Fehlerbehebungsberichte werden sofort gesendet
Debug-Berichte werden sofort vom Browser an die Herkunft der Berichterstellung gesendet. Dies unterscheidet sich von Attributionsberichten, die mit Verzögerung gesendet werden.
Berichte zur erfolgreichen Fehlerbehebung werden generiert und gesendet, sobald der entsprechende Attributionsbericht generiert wird, also bei der Trigger-Registrierung.
Ausführliche Fehlerbehebungsberichte werden sofort nach der Registrierung der Quelle oder des Triggers gesendet.
Fehlerbehebungsberichte haben unterschiedliche Endpunktpfade
Wie bei Attributionsberichten werden auch alle Debug-Berichte an den Ursprung der Berichterstellung gesendet. Debug-Berichte werden an drei separate Endpunkte des Berichtsherkunftsorts gesendet:
- Endpunkt für Erfolgsberichte zur Fehlerbehebung auf Ereignisebene
- Endpunkt für Erfolgs-Fehlerbehebungsberichte, aggregierbar
- Endpunkt für ausführliche Fehlerbehebungsberichte auf Ereignisebene und aggregierbar.
Weitere Informationen finden Sie in Teil 2: Berichte zur Fehlerbehebung einrichten.
Anwendungsfälle
Einfache Prüfung der Echtzeitintegration
Im Gegensatz zu Attributionsberichten, die aus Datenschutzgründen verzögert werden, werden Debug-Berichte sofort an Ihren Endpunkt gesendet. Mit Berichten zur Fehlerbehebung können Sie in Echtzeit signalisieren, dass die Verknüpfung mit der Attribution Reporting API funktioniert.
Weitere Informationen dazu finden Sie in Teil 3: Debugging-Cookbook.
Verlustanalyse
Anders als Drittanbieter-Cookies enthält die Attribution Reporting API integrierte Datenschutzfunktionen, durch die ein ausgewogenes Verhältnis zwischen Nutzen und Datenschutz gewährleistet wird. Daher können Sie mit der Attribution Reporting API möglicherweise nicht alle Messdaten erfassen, die Sie derzeit mit Cookies erfassen. Nicht alle Conversions, die Sie mit Drittanbieter-Cookies erfassen, generieren einen Attributionsbericht.
Ein Beispiel: Bei Berichten auf Ereignisebene können Sie höchstens eine Conversion pro Impression registrieren. Das bedeutet, dass Sie für eine bestimmte Anzeigenimpression nur einen Attributionsbericht erhalten, unabhängig davon, wie oft der Nutzer eine Conversion ausführt.
Mithilfe von Debug-Berichten können Sie sich einen Überblick über die Unterschiede zwischen den auf Cookies basierenden Messergebnissen und den Ergebnissen der Attribution Reporting API verschaffen. Ermitteln Sie, welche Conversions erfasst werden, wie viele Conversions nicht erfasst werden und insbesondere welche und warum.
Weitere Informationen zum Ausführen einer Verlustanalyse in Teil 3: Debugging-Cookbook
Fehlerbehebung
Während durch Datenschutz- oder Ressourcenschutz verursachte Verluste zu erwarten sind, können andere Verluste unbeabsichtigt sein. Fehlkonfigurationen in der Implementierung oder Fehler im Browser selbst können dazu führen, dass Berichte fehlen.
Mithilfe von Debug-Berichten können Sie ein Implementierungsproblem auf Ihrer Seite erkennen und beheben oder einen potenziellen Fehler an die Browserteams melden. Weitere Informationen dazu finden Sie in Teil 3: Debugging-Cookbook.
Erweiterte Konfigurationsprüfung
Mit einigen Funktionen der Attribution Reporting API lässt sich das Verhalten der API anpassen. Beispiele hierfür sind Filter-, Deduplizierungsregeln und Prioritätsregeln.
Wenn Sie diese Funktionen verwenden, können Sie mit Debug-Berichten prüfen, ob Ihre Logik zum gewünschten Verhalten in der Produktion führt, ohne auf Attributionsberichte warten zu müssen. Weitere Informationen dazu finden Sie in Teil 3: Debugging-Cookbook.
Lokale Tests mit aggregierten Berichten
Im Gegensatz zu aggregierten Attributionsberichten, die verschlüsselt sind, enthalten aggregierte Debug-Berichte die unverschlüsselte Nutzlast.
Mit aggregierbaren Debug-Berichten können Sie deren Inhalte validieren und mit dem lokalen Aggregationstool zu Testzwecken zusammenfassende Berichte erstellen.
Berichte zum Aggregationsdienst noch einmal verarbeiten
Ein weiterer Vorteil des Debug-Modus besteht darin, dass Sie Berichte erneut verarbeiten können. Wenn Sie Berichte mehrmals verarbeiten möchten, müssen Sie daher Debug-Berichte aktivieren. Sie sollten Berichte in folgenden Fällen erneut verarbeiten:
- versucht, Fehler im Aggregationsdienst zu beheben.
- verschiedene Batch-Strategien ausprobieren.
- mit verschiedenen Epsilon-Werten experimentieren.
Datenwiederherstellung
Wir empfehlen, dass Anzeigentechnologie-Anbieter den Debug-Modus aktivieren, um Debug-Berichte zu erhalten, damit sie ihre Berichtsdaten wiederherstellen können. Das ist bei Problemen mit dem Zusammenfassungsdienst nützlich, z. B. bei nicht verfügbaren oder nicht reagierenden Diensten, die dazu führen können, dass zusammenfassende Berichte nicht erstellt werden können.