このページは Cloud Translation API によって翻訳されました。

Attribution Reporting のデバッグレポートを設定する

アトリビューションレポートのデバッグに関する 3 部構成のパート 2。デバッグレポートを設定します。

用語集

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.

実装に関する質問

デバッグレポートの設定中に問題が発生した場合は、デベロッパーサポートリポジトリでイシューを作成してください。トラブルシューティングの支援をさせていただきます。

デバッグレポートの設定の準備

デバッグレポートを設定する前に、次の手順を行います。

API 統合のベストプラクティスが適用されていることを確認する

コードが機能検出の背後にゲートされていることを確認します。Permissions-Policy によって API がブロックされないようにするには、次のコードを実行します。
```
if (document.featurePolicy.allowsFeature('attribution-reporting')) {
// the Attribution Reporting API is enabled
}
```
この機能検出チェックが true を返した場合、チェックが実行されるコンテキスト（ページ）で API が許可されます。
（テストフェーズでは不要: Permissions-Policy が設定されていることを確認します）。

統合に関する基本的な問題を解決する

デバッグレポートは大規模な損失の検出と分析に役立ちますが、統合の問題の中にはローカルで検出できるものもあります。ソースとトリガーヘッダーの構成ミス、JSON 解析の問題、安全でないコンテキスト（HTTPS 以外）、API の機能の妨げとなるその他の問題は、DevTools の [問題] タブに表示されます。

DevTools の問題にはさまざまなタイプがあります。invalid header の問題が発生した場合は、ヘッダーをヘッダー検証ツールにコピーします。これにより、問題の原因となっているフィールドを特定して修正できます。

アトリビューションレポートのヘッダーを検証する

ヘッダー検証ツールを使用して、Attribution Reporting API に関連するヘッダーを検証できます。ブラウザから発生した検証エラーをモニタリングして、API のデバッグを容易にできます。

デバッグレポートの受信を有効にするには、Attribution-Reporting-Info レスポンスヘッダーの一部として report-header-errors を返します。

Attribution-Reporting-Info: report-header-errors

Attribution-Reporting-Info は辞書構造のヘッダー Attribution-Reporting-Info であるため、ブール値 report-header-errors キーを指定すると、true 値が暗黙的に指定されます。

デバッグレポートはレポートエンドポイントにすぐに送信されます。

https://<reporting origin>/.well-known/attribution-reporting/debug/verbose

レポートデータは、次の形式のオブジェクトの JSON リストとしてリクエスト本文に含まれます。

[{
  "type": "header-parsing-error",
  "body": {
    "context_site": "https://source.example",
    "header": "Attribution-Reporting-Register-Source",
    "value": "!!!", // header value received in the response
    "error": "invalid JSON" // optional error details that may vary across browsers or different versions of the same browser
  }
}]

デバッグレポートを設定する: 成功レポートと詳細レポートに共通の手順

レポート元に次の Cookie を設定します。

Set-Cookie: ar_debug=1; SameSite=None; Secure; Path=/; HttpOnly

ブラウザは、ソースとトリガーの登録の両方でこの Cookie の存在を確認します。成功デバッグレポートは、両方のタイミングで Cookie が存在する場合にのみ生成されます。

デモコード: デバッグクッキー

デバッグレポートは、モード B のブラウザで有効にできます。モード B では、サードパーティ Cookie のサポート終了に向けたテストと準備を容易にするために、サードパーティ Cookie が無効になっています。モード B のブラウザでは、デバッグレポートを有効にするためにデバッグ Cookie を設定する必要はありません。ステップ 2 に進んで、成功デバッグレポートのデバッグキーを設定します。

ステップ 2: デバッグキーを設定する

各デバッグキーは、10 進文字列としてフォーマットされた 64 ビット符号なし整数である必要があります。各デバッグキーを一意の ID にします。成功デバッグレポートは、デバッグキーが設定されている場合にのみ生成されます。

ソース側のデバッグキーを、デバッグに関連すると思われる追加のソース時間情報にマッピングします。
トリガー側のデバッグキーを、デバッグに関連すると思われる追加のトリガー時間情報にマッピングします。

たとえば、次のようなデバッグキーを設定できます。

Cookie ID + ソースタイムスタンプをソースのデバッグキーとして使用（Cookie ベースのシステムで同じタイムスタンプをキャプチャ）
Cookie ID + トリガーデバッグキーとしてのトリガータイムスタンプ（同じタイムスタンプを Cookie ベースのシステムで取得）

これにより、Cookie ベースのコンバージョン情報を使用して、対応するデバッグレポートやアトリビューションレポートを検索できます。詳細については、パート 3: クックブックをご覧ください。

ソースサイドのデバッグキーを source_event_id と異なるものにして、同じソースイベント ID を持つ個々のレポートを区別できるようにします。

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"
}

デモコード: ソースのデバッグキー デモコード: トリガーのデバッグキー

成功デバッグレポートを設定する

このセクションのコード例では、イベントレベルレポートと集計可能レポートの両方で成功デバッグレポートを生成します。イベントレベルのレポートと集計可能レポートでは、同じデバッグキーが使用されます。

ステップ 3: 成功デバッグレポートを収集するエンドポイントを設定する

デバッグレポートを収集するエンドポイントを設定します。このエンドポイントは、メインのアトリビューションエンドポイントと同様に、パスに debug 文字列を追加します。

イベントレベルの成功デバッグレポートのエンドポイント: https://adtech.example/.well-known/attribution-reporting/debug/report-event-attribution
- 集計可能な成功デバッグレポートのエンドポイント: https://adtech.example/.well-known/attribution-reporting/debug/report-aggregate-attribution

アトリビューションがトリガーされると、ブラウザは POST リクエストを介してデバッグレポートをこのエンドポイントにすぐに送信します。受信した成功デバッグレポートを処理するサーバーコードは、次のように記述できます（ここではノードエンドポイントを使用しています）。

// 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);
  }
);

デモコード: イベントレベルのデバッグレポートエンドポイント

デモコード: 集計可能なデバッグレポートエンドポイント

ステップ 4: 設定で成功デバッグレポートが生成されることを確認する

ブラウザで chrome://attribution-internals を開きます。
[イベントレベルレポート] タブと [集計可能レポート] タブの両方で、[デバッグレポートを表示] チェックボックスがオンになっていることを確認します。
アトリビューションレポートを実装したサイトを開きます。アトリビューションレポートの生成手順を完了します。同じ手順で成功デバッグレポートを生成できます。
chrome://attribution-internals で以下を実行します。
- アトリビューションレポートが正しく生成されていることを確認する。
- [Event-Level Reports] タブと [Aggregatable Reports] タブで、成功デバッグレポートも生成されていることを確認します。リスト内では、青色の debug パスで確認してください。

サーバー上で、エンドポイントがこれらの成功デバッグレポートを直ちに受信することを確認します。イベントレベルと集計可能な成功デバッグレポートの両方を確認してください。

ステップ 5: 成功のデバッグレポートを確認する

成功デバッグレポートはアトリビューションレポートと同じで、ソースサイドとトリガーサイドのデバッグキーの両方が含まれます。

{
  "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"
}

詳細なデバッグレポートを設定する

ステップ 3: ソースヘッダーとトリガーヘッダーで詳細デバッグを有効にする

Attribution-Reporting-Register-Source と Attribution-Reporting-Register-Trigger の両方で debug_reporting を true に設定します。

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
}

デモコード: ソースヘッダー

デモコード: トリガーヘッダー

ステップ 4: 詳細なデバッグレポートを収集するエンドポイントを設定する

デバッグレポートを収集するエンドポイントを設定します。このエンドポイントは、メインのアトリビューションエンドポイントに似ていますが、パスに debug/verbose 文字列が追加されています。

https://adtech.example/.well-known/attribution-reporting/debug/verbose

詳細デバッグレポートが生成された場合（ソースまたはトリガーが登録されていない場合）、ブラウザは POST リクエストを介してこのエンドポイントに詳細デバッグレポートをすぐに送信します。受信した詳細なデバッグレポートを処理するサーバーコードは、次のようになります（ここではノードエンドポイント）。

// 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);
  }
);

成功デバッグレポートとは異なり、詳細レポート用のエンドポイントは 1 つだけです。イベントレベルレポートと集計レポートに関連する詳細レポートはすべて同じエンドポイントに送信されます。

デモコード: 詳細なデバッグレポートエンドポイント

ステップ 5: 設定で詳細なデバッグレポートが生成されることを確認する

詳細デバッグレポートには多くの種類がありますが、詳細デバッグレポートの1 種類だけで詳細デバッグ設定を確認できます。このような詳細デバッグレポートが正しく生成され、受信されると、すべての詳細デバッグレポートも同じ構成を使用し、同じエンドポイントに送信されるため、すべてのタイプの詳細デバッグレポートも正しく生成され、受信されます。

重要なポイント: テストしやすい詳細なデバッグレポートを選択してください。変換することで生成できるため、trigger-no-matching-source が有力な候補です。トリガーイベントに関連する詳細レポートは、より適切な候補になる傾向があります。ソースイベントに関連する詳細レポートタイプは、意図的に生成するのは面倒です。

ブラウザで chrome://attribution-internals を開きます。
アトリビューションレポートで設定されているサイトでアトリビューション（コンバージョン）をトリガーします。このコンバージョンが発生する前に広告のエンゲージメント（インプレッションまたはクリック）が発生しなかったため、trigger-no-matching-source タイプの詳細なデバッグレポートが生成されます。
chrome://attribution-internals で [詳細なデバッグレポート] タブを開き、trigger-no-matching-source 型の詳細なデバッグレポートが生成されていることを確認します。
サーバーで、エンドポイントがこの詳細なデバッグレポートをすぐに受け取ったことを確認します。

ステップ 6: 詳細なデバッグレポートを確認する

トリガー時に生成された詳細なデバッグレポートには、ソース側とトリガー側の両方のデバッグキーが含まれます（トリガーに一致するソースがある場合）。ソース時に生成された詳細なデバッグレポートには、ソース側のデバッグキーが含まれます。

ブラウザから送信される、詳細なデバッグレポートを含むリクエストの例:

[
  {
    "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"
  }
]

各詳細レポートには次のフィールドがあります。

Type: レポートが生成された原因。すべての詳細レポートタイプと、各タイプで必要なアクションについては、パート 3: デバッグクックブックで詳細レポートのリファレンスをご覧ください。
Body: レポートの本文。その種類によって異なります。パート 3: デバッグクックブックの詳細レポートリファレンスを確認する。

リクエストの本文には、少なくとも 1 つ、最大 2 つの詳細レポートが含まれます。

障害がイベントレベルレポートにのみ影響する場合（または集計可能レポートにのみ影響する場合）は、詳細レポートが 1 つ生成されます。ソースまたはトリガーの登録エラーの原因は 1 つだけであるため、エラーとレポートタイプ（イベントレベルまたは集計可能）ごとに詳細レポートを 1 つ生成できます。
障害がイベントレベルレポートと集計可能レポートの両方に影響する場合は、2 つの詳細レポート。例外: イベントレベルレポートと集計可能レポートで失敗理由が同じ場合、詳細レポートは 1 つだけ生成されます（例: trigger-no-matching-source）。

次の動画

パート 3: デバッグクックブック

Attribution Reporting のデバッグ レポートを設定する

用語集

実装に関する質問

デバッグ レポートの設定の準備

アトリビューション レポートのヘッダーを検証する

デバッグ レポートを設定する: 成功レポートと詳細レポートに共通の手順

成功デバッグ レポートを設定する

詳細なデバッグ レポートを設定する