Attribution Reporting のデバッグ クックブック

アトリビューション レポートのデバッグに関する 3 部構成のパート 3。デバッグ レポートの使用方法の手順を確認する。

このクックブックでは、パート 1: デバッグ レポートの概要で説明されているさまざまなユースケースでデバッグ レポートを使用する方法について説明します。

用語集

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

方法: 統合をリアルタイムで確認する

1. 成功デバッグ レポートを生成するようにシステムを設定します。詳しくは、パート 2: デバッグ レポートを設定するをご覧ください。
2. アトリビューション レポート コードをデプロイするたびに、エンドポイントで成功したデバッグ レポートを受信しているかどうかをリアルタイムで確認します。表示された場合は、アトリビューション レポートの設定が機能しています。
3. 成功デバッグ レポートは、コンバージョンが発生したときにのみ送信されます。代わりに、コンバージョンに関係なく統合が適切に設定されていることを確認することをおすすめします。つまり、ソースが正常に登録されていることを確認します。これを実現するには、ソース登録の成功に関する詳細なデバッグ レポートを使用します。設定方法については、パート 2: デバッグ レポートを設定するをご覧ください。

方法: 損失を分析して統合のトラブルシューティングを行う

Cookie ベースのコンバージョン測定結果をアトリビューション レポートと比較するには、デバッグキーを使用して、Cookie コンバージョンをデバッグ レポートにマッピングします。デバッグ レポートはエンドポイントにすぐに送信されます。

概要

デバッグキー（<source_debug_key, trigger_debug_key> ペア）を使用して、Cookie コンバージョンを成功デバッグ レポートにマッピングします。Cookie コンバージョンごとに、コンバージョン時に対応する成功デバッグ レポートを受信しましたか？

「はい」の場合: これらの成功デバッグ レポートはすべて、後日アトリビューション レポートが届きます（例外はいくつかあります）。詳しくは、成功のデバッグ レポートのシナリオをご覧ください。

登録されていない場合: アトリビューション レポートにコンバージョンが登録されていないことを意味します。<source_debug_key, trigger_debug_key> ペア（またはトリガーのデバッグキーがない場合はソースのデバッグキー）を使用して、Cookie コンバージョンを詳細なデバッグ レポートにマッピングします。これらのコンバージョンのそれぞれについて、ある時点で（ソースまたはトリガー時）対応する詳細なデバッグ レポートを受信しましたか？

• 詳細なデバッグ レポートが届かない場合は、ユーザーの操作や統合の問題が原因である可能性があります。詳しくは、デバッグ レポートがないシナリオをご覧ください。

• 詳細なデバッグ レポートが届いた場合は、その type フィールドを確認します。

  • type が source-success の場合: ソースは正常に登録されたが、トリガーは登録されなかったことを意味します。成功デバッグ レポートがない理由を絞り込むには、他のタイプの対応する詳細デバッグ レポートを探します。このレポートには、トリガー側の問題が示されます。

  • type がそれ以外の場合: ソースまたはトリガーが登録されていません。type にその理由が表示されます。対応するアトリビューション レポート（および成功デバッグ レポート）は表示されなくなります。詳細なデバッグ レポートの type に応じて、この情報を損失分析のデータポイントとしてのみ使用するか（つまり、対応しない）、バグを報告するか、実装のトラブルシューティングを行うかを判断します。詳しくは、詳細なデバッグ レポートのシナリオをご覧ください。

考えられるシナリオ

成功デバッグ レポート

特定の Cookie コンバージョンについて成功のデバッグ レポートを受信した場合、このコンバージョンはアトリビューション レポートに正常に登録されたことを意味します。

このコンバージョンのアトリビューション レポートは後日届きます。ただし、次のような例外があります。

• ユーザーの行動: コンバージョン後にアトリビューション レポートが送信される前にデータを消去したり、ブラウザを閉じたりした場合。コンバージョン後にユーザーがブラウザを閉じて 1 週間ブラウザを開かなかった場合、レポートは 1 週間以上送信されません。この遅延は損失と見なされる場合があります。
• イベントレベルにのみ適用: イベントレベル レポートが、優先度の高い別のレポートに置き換えられます。
• ネットワークに関する問題の可能性。

source-success タイプの詳細なデバッグ レポート

特定の Cookie コンバージョンの参照元について、source-success タイプの詳細なデバッグ レポートを受信した場合、参照元の登録が正常に完了したことを意味します。トリガーの登録が後で成功したかどうかに応じて、そのコンバージョンのレポートが届く場合と届かない場合があります。

ただし、1 つ注意点があります。

他のタイプの詳細なデバッグ レポート

特定の Cookie コンバージョンについて、他のタイプの詳細レポートを受信した場合、成功デバッグ レポートは受信されません。そのため、後でアトリビューション レポートも受信されません。これは、詳細レポートは報告可能なエラーが発生したことを意味するためです。なんらかの理由により、ソースの登録、トリガーの登録、レポートの生成、レポートの送信が妨げられました。考えられる原因:

• プライバシーに関する制限
• ストレージ制限
• カスタムルール
• コードの実装に関する問題
• ブラウザのバグ

これらの中には、どのアクションを実行するかは、各詳細レポートの type によって異なります。詳細レポートのリファレンスを確認します。

デバッグ レポートなし

特定の Cookie コンバージョンについて、アトリビューション レポートのみが届き（成功デバッグ レポートも詳細デバッグ レポートも届かない）、その理由が不明な場合は、何らかの原因でデバッグ レポートが生成されなかったことを意味します。考えられる原因:

• ユーザーの設定（ユーザーがサードパーティ Cookie を無効にしている）
• クッキーがない、またはデバッグキーがない（クッキーがないためデバッグキーが消去されている）。chrome://attribution-internals で [ログ] タブを開き、問題がないか確認します。
• アトリビューション レポートの送信時ではなく、参照元またはトリガー時に発生したネットワークの問題。

アトリビューション レポートは届いていますか？

これは、デバッグ レポートが届かないケースのサブケースです。特定の Cookie コンバージョンについて、いかなる種類のレポートも受信しなかった場合（いかなる種類のデバッグ レポートも受信しなかった場合、アトリビューション レポートも受信しなかった場合）、レポートに含められないエラーが発生したことを意味します。考えられる原因:

• 基本的な統合に関する問題。これらの問題のトラブルシューティング方法については、基本的な統合の問題を解決するをご覧ください。
• ネットワークに関する問題の可能性。
• ブラウザの設定でプライバシー サンドボックスなどのユーザー設定がオフになっている。

詳細なデバッグ レポートの参照

各詳細なデバッグ レポートには、対応するアトリビューション レポートが破棄された理由をキャプチャする type フィールドがあります。リファレンスを使用して、詳細レポートの type ごとに必要な対応を把握します。

ソースの登録が完了しました

ソースが正常に登録されました。

source-success

詳細とレポート本文

プライバシーに関する制限レポート

これらの報告は想定内です。クロスサイトのユーザー ID 漏洩を減らすためのプライバシーの制限を示します。

source-destination-limit

詳細と報告本文

source-noised

詳細と報告本文

trigger-attributions-per-source-destination-limit

詳細と報告本文

trigger-reporting-origin-limit

詳細と報告本文

trigger-event-noise

詳細と報告本文

trigger-event-excessive-reports

レポート数が上限を超えた場合に生成されます。表示回数に対しては最大 1 件、クリックに対しては最大 3 件のコンバージョンを登録できます。受け取るレポートは、優先度を設定することで構成できます。詳細と報告本文

保存容量に関する制限レポート

これらの報告は想定内です。リソースの過剰な使用を防ぐために、保存容量の上限を示します。

source-storage-limit

詳細と報告本文

trigger-event-storage-limit

詳細と報告本文

trigger-aggregate-storage-limit

詳細と報告本文

カスタムルール レポート

これらのレポートは、フィルタリング、重複除去、優先度、ウィンドウベースのフィルタリングを使用している場合に発生します。念のため、対応するカスタムルールを再確認し、その詳細レポートに対応するレポートが本当に削除するレポートであることを確認します。これに間違いがなければ、お客様側で必要なご対応はありません。

trigger-no-matching-filter-data

詳細と報告本文

trigger-event-no-matching-configuration

詳細と報告本文

trigger-event-deduplicated

詳細と報告本文

trigger-aggregate-deduplicated

詳細と報告本文

trigger-event-low-priority

詳細と報告本文

trigger-event-report-window-passed

詳細と報告本文

trigger-aggregate-report-window-passed

詳細と報告本文

その他の詳細レポート

これらのレポートは、コードの実装に関する問題を示している可能性があります。

trigger-no-matching-source

これは実装の問題である可能性があります。<reporting origin, destination> の設定に誤りがないことを確認します。これは API の想定どおりの動作である可能性もあります。たとえば、ユーザーが広告を操作した後、コンバージョンを達成する前にデータを消去した場合や、関連する広告を表示することなくコンバージョンを達成した場合などです。詳細と報告本文

trigger-aggregate-no-contributions

これは、コードで意図する動作ではない可能性があります。トリガー登録コードのトラブルシューティングを行い、コントリビューションの構成が正しいことを確認します。詳細と報告本文

trigger-aggregate-insufficient-budget

これは、コードで意図する動作ではない可能性があります。トリガー登録コードを再確認し、すべての拠出の合計が拠出予算を超えていないことを確認します。詳細と報告本文

予期しないエラー（ブラウザのバグが原因の可能性）

これらの報告は想定外です。ブラウザのバグが原因である可能性があります。バグを報告し、説明に再現手順を指定します。

source-unknown-error

詳細と報告本文

trigger-unknown-error

詳細と報告本文

損失分析の例

ステップ 1: 設定と Cookie を使用したマッピング

パート 2: デバッグ レポートを設定するの手順に沿って、成功デバッグ レポートと詳細デバッグ レポートを生成するようにシステムを設定します。

これにより、Cookie ベースのコンバージョン情報を使用して、対応するデバッグレポートまたはアトリビューション レポートを検索できます。

ステップ 2: 正常に登録されたレポートと見つからないレポートを特定する

この例では、Cookie ベースのシステムで 100 件のコンバージョンをトラッキングしたとします。

クッキーベースのコンバージョンを記録するたびに、このクッキーベースのコンバージョンと同じ <source_debug_key, trigger_debug_key> ペアを含む成功デバッグ レポート（すぐに送信されます）を探します。

これらの Cookie コンバージョンのうち 70 件について、正常なデバッグ レポートが届いたとします。

• 成功レポートは、アトリビューションが正常に記録されたことを意味します。そのため、一部の例外を除き、各成功レポートに対応するアトリビューション レポートが生成されることを前提とできます。
• これらの例外をモニタリングすることもできます。そのためには、アトリビューション レポートが（有効期限に応じて）今後数日または数週間にわたってエンドポイントに送信されるので、各成功デバッグ レポートと同じデバッグキーのペアを持つアトリビューション レポートを探します。各期間の終了時にレポートがすぐに送信されない場合がありますので、しばらくお待ちください。アトリビューション レポートが 60 件しかないとします。アトリビューション レポートが 10 件欠落しているのは、ユーザーの行動が原因である可能性があります。

ステップ 3: 損害の簡単な評価

100 - 70 = 30 件の成功したデバッグ レポートが欠落しています。つまり、これらの 30 件のコンバージョン（Cookie ベースの実装でトラッキングされたもの）は、アトリビューション レポートでは記録されませんでした。これらのトラフィックについては、アトリビューション レポートは配信されません。

Cookie ベースのコンバージョンが 100 件、アトリビューション ベースのコンバージョンが 70 件なので、損失は 30% です。これで、損害の簡単な評価ができました。

ステップ 4: 原因を分析する

これらのレポートが見つからない場合の原因を調査するには、コンバージョン（トリガー登録）時またはそれより前のソース登録時に受信した、対応する詳細なデバッグ レポートを探します。クッキーベースのコンバージョンのキーを使用して、詳細なデバッグ レポートにマッピングします。

• 詳細なデバッグ レポートがないキーが 10 個あるとします。統合に問題がないかどうかを確認します。そうでない場合は、ユーザーの操作が原因である可能性があります。
• 詳細なデバッグ レポートが 20 件あります。これで損失分析を絞り込むことができます。各詳細レポートの type フィールドを分析します。たとえば、次のようなことがわかります。
  • pending destination limit が原因で 10 件（この例では 10%）のレポートが欠落している
  • trigger-aggregate-no-contributions が原因で 5 件（5%）のレポートが欠落しています。
  • unknown-error が原因で 5 件（5%）のレポートが欠落しています。

ステップ 5: 対応してトラブルシューティングを行う

レポートが届かない理由を把握できたので、これらの分析情報に基づいて対応できます。

どのアクションを実行するかは、各詳細レポートの type によって異なります。詳細については、詳細レポートのリファレンスをご覧ください。次に例を示します。

• pending-destination-limit はプライバシー保護です。対応の必要はありません。この数値は、可視化とモニタリングのためにデータポイントとして使用してください。
• trigger-aggregate-no-contributions は、お客様側の実装に問題がある可能性があります。これをさらに分析します。詳細レポートの本文にある詳細情報を使用して、トラブルシューティングを行い、必要に応じて修正します。
• unknown-error は、ブラウザのバグやネットワーク エラーを示している可能性があります。この問題が繰り返し発生する場合は、ブラウザ デベロッパーにバグを報告してください。