Teil 1 von 3 zur Fehlerbehebung bei Attributionsberichten Hier erfahren Sie, warum das Debugging wichtig ist und wann Sie Debugging-Berichte beim Testen verwenden sollten.
Warum Sie Debugging-Berichte benötigen
Wenn Sie die Attribution Reporting API testen, sollten Sie prüfen, ob die Integration korrekt funktioniert, Lücken in den Messergebnissen zwischen der Cookie-basierten Implementierung und der Attribution Reporting-Implementierung verstehen und Probleme mit der Integration beheben.
Für diese Aufgaben sind Debugging-Berichte erforderlich. Daher empfehlen wir Ihnen dringend, sie einzurichten.
Glossar
Wichtige Aspekte von Fehlerbehebungsberichten
Zwei Arten von Fehlerbehebungsberichten
Es stehen zwei Arten von Fehlerbehebungsberichten zur Verfügung. Sie sollten beide verwenden, da sie unterschiedliche Anwendungsfälle erfüllen.
Berichte zur Fehlerbehebung
In 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 Debugging-Berichte
Ausführliche Debugging-Berichte bieten einen besseren Einblick in die Quelle und die auslösenden Ereignisse. So können Sie entweder prüfen, ob Quellen erfolgreich registriert wurden, oder fehlende Berichte verfolgen und feststellen, warum sie fehlen (Fehler in Quelle oder Trigger-Ereignisse, Fehler beim Senden oder Erstellen des Berichts). Ausführliche Debug-Berichte enthalten folgende Informationen:
- Fälle, in denen der Browser eine Quelle erfolgreich registriert hat.
- Fälle, in denen vom Browser eine Quelle nicht erfolgreich registriert oder ein Ereignis ausgelöst wurde, d. h., es wird kein Attributionsbericht erstellt.
- Fälle, in denen ein Attributionsbericht aus irgendeinem Grund nicht erstellt oder gesendet werden kann.
Ausführliche Fehlerbehebungsberichte enthalten ein type-Feld, das entweder eine erfolgreiche Quellenregistrierung oder den Grund beschreibt, warum ein Quellen-, Trigger- oder Attributionsbericht nicht generiert wurde.
Berichte zur ausführlichen Fehlerbehebung sind seit Chrome 109 (Januar 2023) verfügbar – mit Ausnahme von ausführlichen Debug-Berichten zur erfolgreichen Quellregistrierung, die später in Chrome 112 hinzugefügt werden.
Sehen Sie sich Beispielberichte in Teil 2: Berichte zur Fehlerbehebung einrichten an.
Fehlerbehebungsberichte basieren auf Cookies
Wenn Sie Debugging-Berichte verwenden möchten, muss die Quelle der Berichterstellung 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:
- Debug-Berichte werden nur erstellt, wenn Drittanbieter-Cookies im Browser des Nutzers zugelassen sind.
- Debug-Berichte sind nach der Einstellung von Drittanbieter-Cookies nicht mehr verfügbar.
Debug-Berichte werden sofort gesendet
Debug-Berichte werden vom Browser sofort an den Ursprung der Berichterstellung gesendet. Das unterscheidet sich von Attributionsberichten, die mit Verzögerung gesendet werden.
Berichte zur Fehlerbehebung werden generiert und gesendet, sobald der entsprechende Attributionsbericht generiert wurde, also bei der Registrierung des Triggers.
Ausführliche Debugging-Berichte werden sofort nach der Registrierung der Quelle oder des Triggers gesendet.
Debugging-Berichte haben unterschiedliche Endpunktpfade
Wie bei den Attributionsberichten werden auch alle Fehlerbehebungsberichte an den Ursprung der Berichterstellung gesendet. Debugging-Berichte werden an drei separate Endpunkte des Ursprungs der Berichterstellung gesendet:
- Endpunkt für Erfolgs-Debug-Berichte, Ereignisebene
- Endpunkt für Erfolgs-Debug-Berichte, 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 Integration in Echtzeit
Debug-Berichte werden sofort an Ihren Endpunkt gesendet, im Gegensatz zu Attributionsberichten, die aus Datenschutzgründen verzögert werden. Mit Debug-Berichten in Echtzeit signalisieren, dass die Einbindung in die Attribution Reporting API funktioniert
Weitere Informationen hierzu finden Sie in Teil 3: Fehlerbehebung im Cookbook.
Verlustanalyse
Im Gegensatz zu Drittanbieter-Cookies verfügt die Attribution Reporting API über integrierte Datenschutzfunktionen, die darauf abzielen, ein Gleichgewicht zwischen Nutzen und Datenschutz zu finden. Das bedeutet, dass Sie mit der Attribution Reporting API möglicherweise nicht alle Messdaten erfassen können, die Sie derzeit mit Cookies erfassen. Nicht für alle Conversions, die Sie mit Drittanbieter-Cookies erfassen können, wird ein Attributionsbericht erstellt.
Ein Beispiel: Bei Berichten auf Ereignisebene können Sie höchstens eine Conversion pro Impression erfassen. 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 Debugging-Berichten können Sie sich ein Bild von den Unterschieden zwischen Ihren auf Cookies basierenden Messergebnissen und den Ergebnissen der Attribution Reporting API machen. Ermitteln Sie, welche Conversions erfasst werden, wie viele Conversions nicht erfasst werden und welche vor allem aus welchem Grund.
Informationen zum Ausführen einer Verlustanalyse finden Sie in Teil 3: Fehlerbehebung im Cookbook.
Fehlerbehebung
Verluste durch Datenschutz- oder Ressourcenschutz sind zu erwarten, andere Verluste können jedoch unbeabsichtigt sein. Fehlkonfigurationen in der Implementierung oder Programmfehler im Browser selbst können dazu führen, dass Berichte verloren gehen.
Mithilfe von Debug-Berichten können Sie Implementierungsprobleme auf Ihrer Seite erkennen und beheben oder Browserteams einen potenziellen Fehler melden. Weitere Informationen dazu finden Sie in Teil 3: Cookbook zur Fehlerbehebung.
Erweiterte Konfigurationsprüfung
Mit einigen Funktionen der Attribution Reporting API lässt sich das Verhalten der API anpassen. Beispiele hierfür sind Filterregeln, Deduplizierungsregeln und Prioritätsregeln.
Wenn Sie diese Funktionen verwenden, können Sie mithilfe von Fehlerbehebungsberichten prüfen, ob Ihre Logik zum gewünschten Verhalten in der Produktion führt, ohne auf Attributionsberichte warten zu müssen. Weitere Informationen hierzu finden Sie in Teil 3: Fehlerbehebung im Cookbook.
Lokale Tests mit aggregierbaren Berichten
Im Gegensatz zu aggregierten Attributionsberichten, die verschlüsselt sind, enthalten aggregierte Fehlerbehebungsberichte die unverschlüsselte Nutzlast.
Verwenden Sie aggregierte Fehlerbehebungsberichte, um den Inhalt aggregierter Berichte zu validieren und mit dem lokalen Aggregationstool zu Testzwecken zusammenfassende Berichte zu generieren.
Aggregationsdienst-Berichte noch einmal verarbeiten
Ein weiterer Vorteil des Debug-Modus besteht darin, dass Sie Berichte noch einmal verarbeiten können. Wenn Sie Berichte mehrmals verarbeiten möchten, müssen Sie also Debug-Berichte aktivieren. Sie können Berichte in folgenden Fällen erneut verarbeiten:
- wenn Sie versuchen, den Aggregationsdienst zu debuggen.
- verschiedene Batch-Strategien auszuprobieren.
- mit verschiedenen Epsilon-Werten.
Datenwiederherstellung
Wir empfehlen Anzeigentechnologie-Anbietern, den Debug-Modus zu aktivieren, um entsprechende Berichte zu erhalten. So können sie ihre Berichtsdaten wiederherstellen. Dies ist bei Problemen mit dem Aggregationsdienst nützlich, z. B. bei nicht verfügbaren oder nicht reagierenden Diensten, die dazu führen können, dass der Zusammenfassungsbericht nicht erstellt werden kann.