Teil 1 von 3: Fehlerbehebung bei Attributionsberichten Hier erfahren Sie, warum das Debugging wichtig ist und wann Sie Debug-Berichte bei Tests verwenden sollten.
Warum Sie Debug-Berichte benötigen
Wenn Sie die Attribution Reporting API testen, sollten Sie prüfen, ob Ihre Einbindung richtig funktioniert, Lücken in den Analyseergebnissen zwischen Ihrer cookiebasierten Implementierung und Ihrer Attribution Reporting-Implementierung ermitteln und Probleme mit Ihrer Einbindung beheben.
Für diese Aufgaben sind Debug-Berichte erforderlich. Wir empfehlen Ihnen daher dringend, sie einzurichten.
Glossar
.Wichtige Aspekte von Protokollen zur Fehlerbehebung
Zwei Arten von Debugberichten
Es gibt zwei Arten von Debug-Berichten. Verwenden Sie beide, da sie unterschiedliche Anwendungsfälle erfüllen.
Berichte zur Fehlerbehebung bei erfolgreichen Abläufen
In Erfolgs-Fehlerbehebungsberichten wird die erfolgreiche Generierung eines Attributionsberichts erfasst. Sie beziehen sich direkt auf einen Attributionsbericht.
Berichte zur erfolgreichen Fehlerbehebung sind seit Chrome 101 (April 2022) verfügbar.
Ausführliche Debugberichte
Ausführliche Debug-Berichte geben Ihnen mehr Einblick in die Quell- und Triggerereignisse. So können Sie entweder prüfen, ob Quellen erfolgreich registriert wurden, oder fehlende Berichte verfolgen und ermitteln, warum sie fehlen (Fehler bei Quell- oder Triggerereignissen, Fehler beim Senden oder Generieren des Berichts). Detaillierte Debugberichte enthalten folgende Informationen:
- Fälle, in denen der Browser eine Quelle erfolgreich registriert hat.
- Fälle, in denen der Browser eine Quelle oder ein Triggerereignis nicht erfolgreich registriert hat. In diesem Fall wird kein Attributionsbericht generiert.
- Fälle, in denen ein Attributionsbericht aus irgendeinem Grund nicht generiert oder gesendet werden kann
Detaillierte Debug-Berichte enthalten das Feld type, das entweder eine erfolgreiche Quellenregistrierung oder den Grund beschreibt, warum kein Bericht zu einer Quelle, einem Trigger oder einer Attribution generiert wurde.
Ausführliche Debug-Berichte sind seit Chrome 109 (Januar 2023) verfügbar, mit Ausnahme der ausführlichen Debug-Berichte zur erfolgreichen Registrierung von Quellen, die erst später in Chrome 112 hinzugefügt wurden.
Beispielberichte finden Sie unter Teil 2: Debugberichte einrichten.
Debug-Berichte sind cookiebasiert
Wenn Sie Debugberichte verwenden möchten, muss die Herkunft der Berichte ein Cookie setzen.
Wenn der für den Empfang von Berichten konfigurierte Ursprung ein Drittanbieter ist, ist dieses Cookie ein Drittanbieter-Cookie. Das bedeutet, dass Debug-Berichte nur generiert werden, wenn Drittanbieter-Cookies im Browser des Nutzers zugelassen sind.
Debug-Berichte werden sofort gesendet
Debug-Berichte werden vom Browser sofort an die Berichtsquelle gesendet. Das ist anders als bei Attributionsberichten, die mit einer Verzögerung gesendet werden.
Berichte zur Fehlerbehebung nach einem erfolgreichen Vorgang werden generiert und gesendet, sobald der entsprechende Attributionsbericht generiert wird, also bei der Triggerregistrierung.
Detaillierte Debug-Berichte werden sofort nach der Registrierung der Quelle oder des Auslösers gesendet.
Debugberichte haben unterschiedliche Endpunktpfade
Wie Attributionsberichte werden alle Debug-Berichte an die Berichtsquelle gesendet. Debugberichte werden an drei separate Endpunkte der Berichtsquelle gesendet:
- Endpunkt für Debugging-Berichte zum Erfolg, Ereignisebene
- Endpunkt für Erfolgs-Fehlerbehebungsberichte, aggregierbar
- Endpunkt für ausführliche Debugging-Berichte auf Ereignisebene, die aggregiert werden können.
Weitere Informationen finden Sie unter Teil 2: Debug-Berichte einrichten.
Anwendungsfälle
Grundlegende Echtzeit-Integrationsprüfung
Im Gegensatz zu Attributionsberichten, die aus Datenschutzgründen verzögert gesendet werden, werden Debug-Berichte sofort an Ihren Endpunkt gesendet. Verwenden Sie Debugberichte als Echtzeitsignal, dass Ihre Integration mit der Attribution Reporting API funktioniert.
Wie das geht, erfahren Sie in Teil 3: Rezeptbuch zur Fehlerbehebung.
Verlustanalyse
Im Gegensatz zu Drittanbieter-Cookies bietet die Attribution Reporting API integrierte Datenschutzmaßnahmen, die ein Gleichgewicht zwischen Nutzen und Datenschutz schaffen sollen. Das bedeutet, dass Sie mit der Attribution Reporting API möglicherweise nicht alle Messdaten erheben können, die Sie mithilfe von Cookies erheben könnten. Nicht für alle Conversions, die Sie mit Drittanbieter-Cookies erfassen können, wird ein Attributionsbericht erstellt.
Beispiel: In Berichten auf Ereignisebene können Sie pro Impression höchstens eine Conversion 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 Debug-Berichten können Sie die Unterschiede zwischen den cookiebasierten Messergebnissen und den Ergebnissen der Attribution Reporting API nachvollziehen. Sie können ermitteln, welche Conversions erfasst werden, wie viele Conversions nicht erfasst werden und warum.
Informationen zum Ausführen einer Verlustanalyse finden Sie unter Teil 3: Cookbook zur Fehlerbehebung.
Fehlerbehebung
Verluste, die durch den Datenschutz oder den Schutz von Ressourcen verursacht werden, sind zwar zu erwarten, andere Verluste können jedoch unbeabsichtigt sein. Falsch konfigurierte Implementierungen oder Fehler im Browser selbst können dazu führen, dass Berichte fehlen.
Mithilfe von Debug-Berichten können Sie Implementierungsprobleme auf Ihrer Seite erkennen und beheben oder Browserteams einen potenziellen Fehler melden. Wie das geht, erfahren Sie in Teil 3: Rezeptbuch zur Fehlerbehebung.
Erweiterte Konfigurationsprüfung
Mit einigen Funktionen der Attribution Reporting API können Sie das Verhalten der API anpassen. Beispiele hierfür sind Filterregeln, Deduplizierungsregeln und Prioritätsregeln.
Wenn Sie diese Funktionen verwenden, können Sie mithilfe von Debug-Berichten prüfen, ob Ihre Logik in der Produktion zum gewünschten Verhalten führt, ohne auf Attributionsberichte warten zu müssen. Weitere Informationen dazu finden Sie unter Teil 3: Rezeptbuch zur Fehlerbehebung.
Lokale Tests mit aggregierten Berichten
Im Gegensatz zu aggregierten Attributionsberichten, die verschlüsselt sind, enthalten aggregierte Debugberichte die unverschlüsselte Nutzlast.
Mit aggregierbaren Debugberichten können Sie den Inhalt aggregierbarer Berichte prüfen und mit dem lokalen Aggregationstool Zusammenfassungsberichte für Tests generieren.
Berichte des Aggregationsdiensts noch einmal verarbeiten
Ein weiterer Vorteil des Debug-Modus ist, dass Sie Berichte noch einmal verarbeiten können. Wenn Sie Berichte also mehrmals verarbeiten möchten, müssen Sie Debugberichte aktivieren. In folgenden Fällen kann es sinnvoll sein, Berichte noch einmal zu verarbeiten:
- versuchen, den Aggregationsdienst zu debuggen.
- mit verschiedenen Batching-Strategien experimentieren.
- mit verschiedenen Epsilonwerten experimentieren.
Datenwiederherstellung
Wir empfehlen Anbietern von Anzeigentechnologien, den Debug-Modus zu aktivieren, um Debug-Berichte zu erhalten und so ihre Berichtsdaten wiederherzustellen. Das ist nützlich bei Problemen mit dem Aggregationsdienst, z. B. bei nicht verfügbaren oder nicht reagierenden Diensten, die die Erstellung von Zusammenfassungsberichten verhindern können.