アトリビューション レポートのデバッグに関する 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.exampleas 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
typefield 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.
手順: 統合をリアルタイムで確認する
- 成功のデバッグ レポートを生成するようにシステムを設定します。詳しくは、パート 2: デバッグ レポートを設定するをご覧ください。
- アトリビューション レポート コードをデプロイするたびに、エンドポイントで成功のデバッグ レポートを受信しているかどうかをリアルタイムで確認します。その場合は、Attribution Reporting の設定は機能しています。
- 成功のデバッグ レポートは、コンバージョンが発生した場合にのみ送信されます。代わりに、コンバージョンに関係なく統合が適切に設定されていること、つまりソースが正常に登録されていることを確認したい場合があります。これを実現するには、ソース登録成功 詳細デバッグ レポートを利用できます。設定方法については、パート 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 タイプの詳細なデバッグ レポートを受信した場合、これはソース登録が成功したことを意味します。トリガー登録が後で成功するかどうかによって、そのコンバージョンのレポートが届く場合と届かない場合があります。
ただし、次の点に注意してください。
その他のタイプの詳細なデバッグ レポート
特定の Cookie コンバージョンについて、他のタイプの詳細デバッグ レポートを受信した場合、成功デバッグ レポートは受信されません。したがって、後でアトリビューション レポートも受信されません。これは、詳細レポートが報告可能な失敗が発生したことを意味するためです。ソース登録、トリガー登録、レポート生成、レポート送信のいずれかが妨げられました。考えられる原因:
- プライバシー制限
- ストレージ制限
- カスタムルール
- コードの実装に関する問題
- ブラウザのバグ
これらのうちのいくつかは想定内です。取るべきアクションは、各詳細レポートの type によって異なります。詳細レポートのリファレンスを確認します。
デバッグ レポートなし
特定の Cookie コンバージョンについて、アトリビューション レポートのみを受信した場合（成功デバッグ レポートも詳細デバッグ レポートも受信していない場合）、これはデバッグ レポートの生成を妨げる何らかの要因があったことを意味します。考えられる原因:
- ユーザー設定（ユーザーがサードパーティ Cookie を無効にしている）
- 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 件のコンバージョンをトラッキングしたとします。
Cookie ベースのコンバージョンを記録するたびに、この Cookie ベースのコンバージョンと同じ <source_debug_key, trigger_debug_key> ペアを含む成功デバッグ レポート（すぐに送信されます）を探します。
これらの Cookie コンバージョンのうち 70 件で成功のデバッグ レポートを受け取ったとします。
- 成功レポートはアトリビューションが正常に記録されたことを意味します。そのため、一部の例外を除き、各成功レポートに対応するアトリビューション レポートが届くと想定して問題ありません。
- これらの例外をモニタリングするかどうかを決定できます。そのためには、アトリビューション レポートが数日または数週間（有効期限によって異なります）にわたってエンドポイントに送信される際に、各成功デバッグ レポートと同じデバッグキーのペアを持つアトリビューション レポートを探します。レポートは各ウィンドウの終了時にすぐに送信されない場合があるため、しばらくお待ちください。アトリビューション レポートが 60 件しか見つからなかったとします。アトリビューション レポートが 10 件欠落しているのは、ユーザーの行動が原因である可能性があります。
ステップ 3: 損失の簡単な評価
100 - 70 = 30 件の成功したデバッグ レポートがありません。つまり、これらの 30 件のコンバージョン（Cookie ベースの実装でトラッキングされたもの）は、アトリビューション レポートで記録されませんでした。これらのアトリビューション レポートは届かなくなります。
Cookie ベースのコンバージョンが 100 件、アトリビューション ベースのコンバージョンが 70 件の場合、損失は 30% になります。これで、損失の簡単な評価が完了しました。
ステップ 4: 原因を分析する
これらのレポートが欠落している理由を調査するには、コンバージョン（トリガー登録）時またはソース登録時以前に受け取った対応する詳細なデバッグ レポートを探します。Cookie ベースのコンバージョンのキーを使用して、詳細なデバッグ レポートにマッピングします。
- 詳細なデバッグ レポートがないキーが 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は、ブラウザのバグまたはネットワーク エラーの兆候である可能性があります。この問題が繰り返し発生する場合は、ブラウザ デベロッパーにバグを報告してください。