Fehlerbehebungsberichte für Attribution Reporting einrichten

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

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.

Demo code: debug

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

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
  • 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

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
}

Democode: Quelle Überschrift

Democode: Trigger Überschrift

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.

  1. Öffnen Sie chrome://attribution-internals in Ihrem Browser.
  2. 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.
  3. Öffnen Sie in chrome://attribution-internals den Tab Ausführliche Fehlerbehebungsberichte. und prüfe, ob ein ausführlicher Debug-Bericht vom Typ trigger-no-matching-source wurde generiert.
  4. 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)

Nächstes Video

Teil 3: Fehlerbehebung im Cookbook