Teil 1 von 3 zur Fehlerbehebung bei Attribution Reporting. Hier erfahren Sie, warum das Debugging wichtig ist und wann Sie Debugging-Berichte beim Testen verwenden sollten.
Warum Sie Debug-Berichte benötigen
Wenn Sie die Attribution Reporting API testen, sollten Sie prüfen, ob Ihre Integration richtig funktioniert, Lücken in den Messergebnissen zwischen Ihrer cookiebasierten Implementierung und Ihrer Attribution Reporting-Implementierung nachvollziehen und alle Probleme mit Ihrer Integration beheben.
Für diese Aufgaben sind Debug-Berichte erforderlich. Wir empfehlen Ihnen daher dringend, sie einzurichten.
Glossar
Wichtige Aspekte von Debug-Berichten
Zwei Arten von Debug-Berichten
Es gibt zwei Arten von Debug-Berichten. Verwenden Sie beide, da sie unterschiedliche Anwendungsfälle abdecken.
Berichte zur Fehlerbehebung bei erfolgreichen Vorgängen
In Erfolgs-Debug-Berichten wird die erfolgreiche Generierung eines Attributionsberichts erfasst. Sie beziehen sich direkt auf einen Attributionsbericht.
Erfolgs-Debug-Berichte sind seit Chrome 101 (April 2022) verfügbar.
Ausführliche Debug-Berichte
Ausführliche Debug-Berichte bieten mehr Einblick in die Quell- und Triggerereignisse. So können Sie prüfen, ob Quellen erfolgreich registriert wurden, oder fehlende Berichte nachverfolgen und feststellen, warum sie fehlen (Fehler bei Quell- oder Triggerereignissen, Fehler beim Senden oder Generieren des Berichts). Ausführliche Debug-Berichte enthalten folgende Informationen:
- Fälle, in denen der Browser eine Quelle erfolgreich registriert hat.
- Fälle, in denen der Browser eine Quelle oder ein Trigger-Ereignis nicht erfolgreich registriert hat. In diesem Fall wird kein Attributionsbericht generiert.
- Fälle, in denen aus irgendeinem Grund kein Attributionsbericht generiert oder gesendet werden kann.
Ausführliche Debug-Berichte enthalten das Feld type, in dem entweder eine erfolgreiche Quellenregistrierung oder der Grund dafür beschrieben wird, warum keine Quelle, kein Trigger oder kein Attributionsbericht generiert wurde.
Ausführliche Fehlerbehebungsberichte sind seit Chrome 109 (Januar 2023) verfügbar. Die ausführlichen Fehlerbehebungsberichte zum Erfolg der Quellregistrierung wurden später in Chrome 112 hinzugefügt.
Beispielberichte finden Sie unter Teil 2: Debug-Berichte einrichten.
Fehlerbehebungsberichte basieren auf Cookies
Damit Debug-Berichte verwendet werden können, muss der Berichtursprung ein Cookie festlegen.
Wenn der Ursprung, der für den Empfang von Berichten konfiguriert ist, 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 sofort vom Browser an den Berichtursprung gesendet. Im Gegensatz zu Attributionsberichten werden sie mit einer Verzögerung gesendet.
Erfolgreiche Debug-Berichte werden generiert und gesendet, sobald der entsprechende Attributionsbericht generiert wird, d. h. bei der Triggerregistrierung.
Ausführliche Debug-Berichte werden sofort nach der Registrierung der Quelle oder des Triggers gesendet.
Debug-Berichte haben unterschiedliche Endpunktpfade
Wie Attributionsberichte werden alle Debug-Berichte an den Berichtursprung gesendet. Debug-Berichte werden an drei separate Endpunkte des Berichtursprungs gesendet:
- Endpunkt für Erfolgsberichte auf Ereignisebene
- Endpunkt für aggregierbare Erfolgsberichte zur Fehlerbehebung
- Endpunkt für ausführliche Debugging-Berichte auf Ereignisebene und aggregierbar.
Anwendungsfälle
Einfache Echtzeit-Integrationsprüfung
Debug-Berichte werden sofort an Ihren Endpunkt gesendet. Im Gegensatz dazu werden Attributionsberichte verzögert, um die Daten der Nutzer besser zu schützen. Fehlerberichte als Echtzeitsignal dafür verwenden, dass Ihre Integration in die Attribution Reporting API funktioniert.
Teil 3: Cookbook zur Fehlerbehebung
Analyse von Verlusten
Im Gegensatz zu Drittanbieter-Cookies bietet die Attribution Reporting API integrierte Datenschutzfunktionen, die ein Gleichgewicht zwischen Nützlichkeit und Datenschutz schaffen sollen. Das bedeutet, dass Sie mit der Attribution Reporting API möglicherweise nicht alle Messdaten erfassen können, die Sie mit Cookies erfassen könnten. Nicht für alle Conversions, die Sie mit Drittanbieter-Cookies erfassen können, wird ein Attributionsbericht erstellt.
Ein Beispiel: In Berichten auf Ereignisebene kann maximal eine Conversion pro Impression erfasst werden. 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 Ihren cookiebasierten Analyseergebnissen und den Ergebnissen, die Sie mit der Attribution Reporting API erhalten, nachvollziehen. Sie können genau nachvollziehen, welche Conversions erfasst werden, wie viele Conversions nicht erfasst werden und welche das sind und warum.
Informationen zum Ausführen einer Verlustanalyse finden Sie in Teil 3: Cookbook zur Fehlerbehebung.
Fehlerbehebung
Verluste aufgrund von Datenschutz- oder Ressourcenschutzmaßnahmen sind zu erwarten, andere Verluste sind möglicherweise unbeabsichtigt. Fehlkonfigurationen in Ihrer Implementierung 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. Teil 3: Cookbook 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, Regeln zur Deduplizierung und Prioritätsregeln.
Wenn Sie diese Funktionen verwenden, sollten Sie mit Debug-Berichten prüfen, ob Ihre Logik im Produktionsmodus zum gewünschten Verhalten führt, ohne auf Attributionsberichte warten zu müssen. Teil 3: Cookbook zur Fehlerbehebung
Lokale Tests mit aggregierbaren Berichten
Im Gegensatz zu aggregierbaren Attributionsberichten, die verschlüsselt sind, enthalten aggregierbare Debug-Berichte die unverschlüsselte Nutzlast.
Mit aggregierbaren Debug-Berichten können Sie den Inhalt aggregierbarer Berichte validieren und Zusammenfassungsberichte mit dem lokalen Aggregationstool für Tests erstellen.
Berichte des Aggregationsdienstes noch einmal verarbeiten
Ein weiterer Vorteil des Debug-Modus ist, dass Sie Berichte noch einmal verarbeiten können. Wenn Sie Berichte mehrmals verarbeiten möchten, müssen Sie daher Debug-Berichte aktivieren. Sie sollten Berichte neu verarbeiten, wenn:
- Sie versuchen, den Aggregationsdienst zu debuggen.
- mit verschiedenen Batching-Strategien experimentieren.
- mit verschiedenen Epsilon-Werten experimentieren.
Datenwiederherstellung
Wir empfehlen Ad-Tech-Unternehmen, den Debug-Modus zu aktivieren, um Debug-Berichte zu erhalten und so ihre Berichtsdaten wiederherstellen zu können. Das ist nützlich bei Problemen mit dem Aggregationsdienst, z. B. wenn Dienste nicht verfügbar sind oder nicht reagieren und dadurch die Erstellung von Zusammenfassungsberichten fehlschlägt.