Teil 2 von 3 zur Fehlerbehebung bei Attributionsberichten Richten Sie Ihre Fehlerbehebungsberichte ein.
Glossar
- The reporting origin is the origin
that sets the Attribution Reporting source and trigger headers.
All reports generated by the browser are sent to this origin. In this guidance,
we use
https://adtech.example
as the example reporting origin. - An attribution report (report for short) is the final report (event-level or aggregatable) that contains the measurement data you've requested.
- A debug report contains additional data about an attribution report, or about a source or trigger event. Receiving a debug report does not necessarily mean that something is working incorrectly! There are two types of debug reports
- A transitional debug report is a debug report that requires a cookie to be set in order to be generated and sent. Transitional debug reports will be unavailable if a cookie is not set, and once third-party cookies are deprecated. All debug reports described in this guide are transitional debug reports.
- Success debug reports track successful generation of an attribution report. They relate directly to an attribution report. Success debug reports have been available since Chrome 101 (April 2022).
- Verbose debug reports can track missing reports and help you determine why
they're missing. They indicate cases where the browser did not record a source
or trigger event, (which means it will not generate an attribution report), and
cases where an attribution report can't be generated or sent for some reason.
Verbose debug reports include a
type
field that describes the reason why a source event, trigger event or attribution report was not generated. Verbose debug reports are available starting in Chrome 109 (Stable in January 2023). - Debug keys are unique identifiers you can set on both the source side and the trigger side. Debug keys enable you to map cookie-based conversions and attribution-based conversions. When you've set up your system to generate debug reports and set debug keys, the browser will include these debug keys in all attribution reports and debug reports.
For more concepts and key terms used throughout our documentation, refer to the Privacy Sandbox glossary.
Fragen zur Implementierung?
Wenn bei der Einrichtung von Fehlerbehebungsberichten ein Problem auftritt, erstellen Sie ein Problem auf unseren Entwicklersupport Repository und wir helfen Ihnen bei der Fehlerbehebung.
Einrichtung von Fehlerbehebungsberichten vorbereiten
Führen Sie die folgenden Schritte aus, bevor Sie Fehlerbehebungsberichte einrichten:
Überprüfen Sie, ob Sie die Best Practices für die API-Integration angewendet haben
Prüfen Sie, ob sich Ihr Code hinter der Funktionserkennung verbirgt. Um sicherzustellen, dass die API nicht von der Berechtigungsrichtlinie blockiert wird, führen Sie den folgenden Code aus:
if (document.featurePolicy.allowsFeature('attribution-reporting')) { // the Attribution Reporting API is enabled }
Wenn die Prüfung der Merkmalserkennung den Wert „true“ zurückgibt, ist die API im Kontext (Seite), in dem die Prüfung ausgeführt wird.
(Während der Testphase nicht erforderlich: Stellen Sie sicher, dass Sie Permissions-Policy)
Grundlegende Integrationsprobleme beheben
Debugging-Berichte sind nützlich, um Verluste in großem Umfang zu erkennen und zu analysieren, können einige Integrationsprobleme lokal erkannt werden. Quelle und Trigger-Header Fehlkonfigurationsprobleme, JSON-Parsing-Probleme, unsicherer Kontext (Nicht-HTTPS) und Andere Probleme, die die Funktionalität der API verhindern, werden in der DevTools Issues (Probleme):
Es gibt verschiedene Arten von Problemen in den Entwicklertools. Wenn ein invalid header
angezeigt wird
kopieren Sie die Kopfzeile in den Header Validator.
. Dieses
können Sie das problematische Feld ermitteln und korrigieren.
![Screenshot: Header-Validierungstool](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/screenshot-header-valida-6fe8347784caf.png?authuser=19&hl=de)
Debugging-Berichte einrichten: gängige Schritte für Erfolgs- und ausführliche Berichte
Legen Sie das folgende Cookie für die Ursprung der Berichte fest:
Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly
Der Browser prüft das Vorhandensein dieses Cookies sowohl in der Quelle als auch in der die Registrierung auslösen. Der Bericht zur erfolgreichen Fehlerbehebung wird nur erstellt, wenn ob das Cookie jeweils vorhanden ist.
Fehlerbehebungsberichte können für Browser im Modus B, wobei Drittanbieter-Cookies deaktiviert, um das Testen und die Vorbereitung auf Einstellung von Drittanbieter-Cookies. Für Browser im Modus B müssen Sie nicht um Debugging-Berichte zu aktivieren. Fahren Sie mit Schritt 2 fort, um Fehlerbehebungsschlüssel einzurichten für erfolgreiche Debugging-Berichte.
Schritt 2: Fehlerbehebungsschlüssel festlegen
Jeder Schlüssel zur Fehlerbehebung muss eine vorzeichenlose 64-Bit-Ganzzahl sein, die als Basis-10-String formatiert ist. Legen Sie für jeden Schlüssel zur Fehlerbehebung eine eindeutige ID fest. Der Bericht zur erfolgreichen Fehlerbehebung wird nur Debug-Schlüssel festgelegt sind.
- Ordnen Sie den quellseitigen Fehlerbehebungsschlüssel zusätzlichen Informationen zur Quellenzeit zu die für Sie zur Fehlerbehebung relevant sind.
- Ordnen Sie den auslöserseitigen Fehlerbehebungsschlüssel zusätzlichen Informationen zur Triggerzeit zu die für Sie zur Fehlerbehebung relevant sind.
Sie könnten beispielsweise die folgenden Fehlerbehebungsschlüssel festlegen:
- Cookie-ID + Zeitstempel der Quelle als Debug-Schlüssel der Quelle (und erfassen denselben Zeitstempel in Ihrem Cookie-basierten System)
- Cookie-ID und Triggerzeitstempel als Debug-Schlüssel für den Trigger (und erfassen denselben Zeitstempel in Ihrem Cookie-basierten System)
So können Sie anhand von Cookie-basierten Conversion-Informationen entsprechenden Fehlerbehebungs- oder Attributionsberichten. Weitere Informationen erhalten Sie in Teil 3: Cookbook
Unterscheiden Sie sich zwischen dem quellseitigen Fehlerbehebungsschlüssel und source_event_id
, damit Sie Folgendes tun können:
zwischen einzelnen Berichten mit derselben Quellereignis-ID unterscheiden zu können.
Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"647775351539539"
}
Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743"
}
Democode: Quellcodefehler beheben Schlüssel Democode: Fehlerbehebung auslösen Schlüssel
Berichte zur Fehlerbehebung einrichten
Mit dem Beispielcode in diesem Abschnitt werden Berichte zur Fehlerbehebung für beide Berichte auf Ereignisebene und aggregierbare Berichte. Für Berichte auf Ereignisebene und dieselben Schlüssel zur Fehlerbehebung.
Schritt 3: Endpunkt zum Erfassen von Berichten zur erfolgreichen Fehlerbehebung einrichten
Richten Sie einen Endpunkt zum Erfassen der Fehlerbehebungsberichte ein. Dieser Endpunkt sollte ähnlich sein
zum primären Attributionsendpunkt mit einem zusätzlichen debug
-String im Pfad:
- Endpunkt für Erfolgsberichte zur Fehlerbehebung auf Ereignisebene:
https://adtech.example/.well-known/attribution-reporting/debug/report-event-attribution
<ph type="x-smartling-placeholder">- </ph>
- Endpunkt für aggregatable Erfolgsberichte zur Fehlerbehebung:
https://adtech.example/.well-known/attribution-reporting/debug/report-aggregate-attribution
- Endpunkt für aggregatable Erfolgsberichte zur Fehlerbehebung:
Wenn eine Attribution ausgelöst wird, sendet der Browser sofort eine Fehlerbehebung
mit einer POST
-Anfrage an diesen Endpunkt melden. Dein Servercode, der verarbeitet werden soll
Eingehende Berichte zur Fehlerbehebung können so aussehen (hier auf einem Knotenendpunkt):
// Handle incoming event-Level Success Debug reports
adtech.post(
'/.well-known/attribution-reporting/debug/report-event-attribution',
async (req, res) => {
// Debug report is in req.body
res.sendStatus(200);
}
);
// Handle incoming aggregatable Success Debug reports
adtech.post(
'/.well-known/attribution-reporting/debug/report-aggregate-attribution',
async (req, res) => {
// Debug report is in req.body
res.sendStatus(200);
}
);
Democode: Berichte zur Fehlerbehebung auf Ereignisebene Endpunkt
Democode: aggregierte Debugging-Berichte Endpunkt
Schritt 4: Prüfen, ob bei der Einrichtung Berichte zur Fehlerbehebung erstellt werden
- Öffnen Sie
chrome://attribution-internals
in Ihrem Browser. - Das Kästchen Show Debug Reports (Fehlerbehebungsberichte anzeigen) muss sowohl im Drop-down-Menü Die Tabs Berichte auf Ereignisebene und Zusammenfassende Berichte
- Öffnen Sie die Websites, auf denen Sie Attribution Reporting implementiert haben. Abgeschlossen Schritte zur Erstellung von Attributionsberichten werden dieselben Schritte Berichte zur Fehlerbehebung erstellen.
- In
chrome://attribution-internals
: <ph type="x-smartling-placeholder">- </ph>
- Prüfen Sie, ob die Attributionsberichte korrekt generiert wurden.
- Auf den Tabs Berichte auf Ereignisebene und Zusammengefasste Berichte
Prüfen Sie, ob auch die Berichte zur Fehlerbehebung erstellt werden. Erkenne sie/ihn
in der Liste durch den blauen Pfad
debug
.
![Screenshot: Interne Daten von Attribution](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/screenshot-attribution-i-e7d3e5d9e396.png?authuser=19&hl=de)
- Prüfen Sie auf Ihrem Server, ob Ihr Endpunkt diese Erfolgsdaten sofort erhält. Debug-Berichten verwendet werden. Achten Sie darauf, sowohl auf Ereignisebene als auch auf aggregierte Werte zu prüfen. zur Fehlerbehebung.
![Screenshot: Ursprungsserverprotokolle melden](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/screenshot-reporting-ori-89d44854473d7.png?authuser=19&hl=de)
Schritt 5: Debug-Erfolgsberichte beobachten
Ein Bericht zur Fehlerbehebung ist mit einem Attributionsbericht identisch und enthält sowohl die quellseitigen und die triggerseitigen Fehlerbehebungsschlüssel an.
{
"attribution_destination": "https://advertiser.example",
"randomized_trigger_rate": 0.0000025,
"report_id": "7d76ef29-d59e-4954-9fff-d97a743b4715",
"source_debug_key": "647775351539539",
"source_event_id": "760938763735530",
"source_type": "event",
"trigger_data": "0",
"trigger_debug_key": "156477391437535"
}
{
"aggregation_service_payloads": [
{
"debug_cleartext_payload": "omRkYXRhgqJldmFsdWVEAACAAGZidWNrZXRQPPhnkD+7c+wm1RjAlowp3KJldmFsdWVEAAARMGZidWNrZXRQJFJl9DLxbnMm1RjAlowp3GlvcGVyYXRpb25paGlzdG9ncmFt",
"key_id": "d5f32b96-abd5-4ee5-ae23-26490d834012",
"payload": "0s9mYVIuznK4WRV/t7uHKquHPYCpAN9mZHsUGNiYd2G/9cg87Y0IjlmZkEtiJghMT7rmg3GtWVPWTJU5MvtScK3HK3qR2W8CVDmKRAhqqlz1kPZfdGUB4NsXGyVCy2UWapklE/r7pmRDDP48b4sQTyDMFExQGUTE56M/8WFVQ0qkc7UMoLI/uwh2KeIweQCEKTzw"
}
],
"shared_info": "{\"api\":\"attribution-reporting\",\"attribution_destination\":\"https://advertiser.example\",\"debug_mode\":\"enabled\",\"report_id\":\"4a04f0ff-91e7-4ef6-9fcc-07d000c20495\",\"reporting_origin\":\"https://adtech.example\",\"scheduled_report_time\":\"1669888617\",\"source_registration_time\":\"1669852800\",\"version\":\"0.1\"}",
"source_debug_key": "647775351539539",
"trigger_debug_key": "156477391437535"
}
Ausführliche Fehlerbehebungsberichte einrichten
Schritt 3: Ausführliche Fehlerbehebung in den Quell- und Trigger-Headern aktivieren
debug_reporting
in beiden Attribution-Reporting-Register-Source
auf true
festlegen
und Attribution-Reporting-Register-Trigger
.
Attribution-Reporting-Register-Source:
{
// … Usual fields for Attribution-Reporting-Register-Source
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}
Attribution-Reporting-Register-Trigger:
{
// … Usual fields for Attribution-Reporting-Register-Trigger
"debug_key":"938321351539743",
"debug_reporting": true // defaults to false if not present
}
Schritt 4: Endpunkt zum Erfassen ausführlicher Fehlerbehebungsberichte einrichten
Richten Sie einen Endpunkt zum Erfassen der Fehlerbehebungsberichte ein. Dieser Endpunkt sollte ähnlich sein
zum primären Attributionsendpunkt mit einem zusätzlichen debug/verbose
-String in
Pfad:
https://adtech.example/.well-known/attribution-reporting/debug/verbose
Wenn ausführliche Debugging-Berichte erstellt werden,
registriert, sendet der Browser sofort einen ausführlichen Debug-Bericht
POST
-Anfrage an diesen Endpunkt. Dein Servercode zur Verarbeitung ausführlicher eingehender Nachrichten
Debug-Berichte können wie folgt aussehen (hier auf einem Knotenendpunkt):
// Handle incoming verbose debug reports
adtech.post(
'/.well-known/attribution-reporting/debug/verbose',
async (req, res) => {
// List of verbose debug reports is in req.body
res.sendStatus(200);
}
);
Anders als bei Berichten zur Fehlerbehebung gibt es für ausführliche Berichte nur einen Endpunkt. Ausführliche Berichte, die sich auf Berichte auf Ereignisebene und zusammengefasste Berichte beziehen, an denselben Endpunkt gesendet wird.
Democode: ausführliche Debugging-Berichte Endpunkt
Schritt 5: Prüfen, ob bei der Einrichtung ausführliche Debugging-Berichte erstellt werden
Es gibt zahlreiche Arten von ausführlichen Debugging-Berichten, doch es reicht aus, Einrichtung der ausführlichen Fehlerbehebung nur mit einem Typ ausführlicher Fehlerbehebung überprüfen Bericht. Wenn diese Art von ausführlichem Debug-Bericht erhalten, bedeutet dies, dass alle Arten von ausführlichen Debugging-Berichten generiert und empfangen werden, da alle ausführlichen Fehlerbehebungsberichte dieselben Konfiguration und werden an denselben Endpunkt gesendet.
- Öffnen Sie
chrome://attribution-internals
in Ihrem Browser. - Auf Ihrer Website, die mit Attribution eingerichtet wurde, eine Attribution (Conversion) auslösen
Berichterstellung Da keine Interaktion mit der Anzeige (Impression oder Klick) erfolgte
erhalten Sie einen ausführlichen Debugging-Bericht des Typs
trigger-no-matching-source
wird generiert. - Öffnen Sie in
chrome://attribution-internals
den Tab Ausführliche Fehlerbehebungsberichte. und prüfe, ob ein ausführlicher Debug-Bericht vom Typtrigger-no-matching-source
wurde generiert. - Prüfen Sie auf Ihrem Server, ob der Endpunkt diese Nachricht sofort erhalten hat. ausführlichen Debug-Bericht.
Schritt 6: Ausführliche Fehlerbehebungsberichte beobachten
Ausführliche Debugging-Berichte, die zum Zeitpunkt der Auslösung generiert werden, enthalten sowohl quell- als auch den Debug-Schlüssel auf Triggerseite (wenn eine übereinstimmende Quelle für den Trigger vorhanden ist) Ausführliche Debug-Berichte, die zum Zeitpunkt der Quelle generiert werden, enthalten das quellseitige Debugging .
Beispiel für eine Anfrage mit ausführlichen Debugging-Berichten, die vom Browser gesendet wurde:
[
{
"body": {
"attribution_destination": "http://arapi-advertiser.localhost",
"randomized_trigger_rate": 0.0000025,
"report_id": "92b7f4fd-b157-4925-999e-aad6361de759",
"source_debug_key": "282273499788483",
"source_event_id": "480041649210491",
"source_type": "event",
"trigger_data": "1",
"trigger_debug_key": "282273499788483"
},
"type": "trigger-event-low-priority"
},
{
"body": {
"attribution_destination": "http://arapi-advertiser.localhost",
"limit": "65536",
"source_debug_key": "282273499788483",
"source_event_id": "480041649210491",
"source_site": "http://arapi-publisher.localhost",
"trigger_debug_key": "282273499788483"
},
"type": "trigger-aggregate-insufficient-budget"
}
]
Jeder ausführliche Bericht enthält die folgenden Felder:
Type
- Grund für die Berichtserstellung. Um mehr über alle ausführlichen Berichtstypen und welche Maßnahmen Sie für die einzelnen Typen ergreifen müssen, finden Sie in den Referenz zu ausführlichen Berichten in Teil 3: Fehlerbehebung Kochbuch.
Body
- Text des Berichts Das hängt vom Typ ab. Lesen Sie die ausführliche Berichtsreferenz in Teil 3: Fehlerbehebung Kochbuch.
Der Text einer Anfrage enthält mindestens einen und höchstens zwei ausführliche Berichte:
- Einen ausführlichen Bericht, wenn der Fehler nur Berichte auf Ereignisebene betrifft (oder betrifft nur aggregierte Berichte). Fehler bei der Registrierung einer Quelle oder eines Triggers hat nur einen Grund: Daher kann pro Fehler ein ausführlicher Bericht erstellt werden. und pro Berichtstyp (auf Ereignisebene oder aggregierbar).
- Zwei ausführliche Berichte, wenn sich der Fehler sowohl auf Ereignisebene als auch auf aggregierbare Berichte auswirkt
mit Ausnahme: wenn die Fehlerursache auf Ereignisebene identisch ist
und aggregierten Berichten wird nur ein ausführlicher Bericht generiert (Beispiel:
trigger-no-matching-source
)