アトリビューション レポートのデバッグに関するパート 1/3。デバッグが重要な理由と、テストでデバッグ レポートを使用するタイミングについて学びます。
デバッグ レポートが必要な理由
Attribution Reporting API をテストする場合は、統合が適切に機能していることを確認し、Cookie ベースの実装と Attribution Reporting の実装における測定結果の差異を把握して、統合に関する問題のトラブルシューティングを行ってください。
これらのタスクを完了するには、デバッグ レポートが必要です。そのため、これらを設定することを強くおすすめします。
用語集
デバッグ レポートの重要な側面
2 種類のデバッグ レポート
2 種類のデバッグ レポートを使用できます。それぞれ用途が異なるため、両方を使用してください。
成功デバッグ レポート
成功デバッグ レポートでは、アトリビューション レポートの正常な生成を追跡できます。アトリビューション レポートと直接関連しています。
成功デバッグ レポートは、Chrome 101（2022 年 4 月）からご利用いただけます。
詳細なデバッグ レポート
詳細なデバッグ レポートでは、ソースとトリガー イベントの詳細を確認できます。これにより、ソースが正常に登録されたことを確認することも、欠落しているレポートを追跡して欠落している理由（ソースイベントまたはトリガー イベントの失敗、レポートの送信または生成時のエラー）を特定することもできます。詳細なデバッグ レポートには次の情報が表示されます。
- ブラウザでソースが正常に登録されたケース。
- ブラウザでソースイベントまたはトリガー イベントが正常に登録されなかったケース（つまり、アトリビューション レポートが生成されないケース）。
- なんらかの理由でアトリビューション レポートを生成または送信できないケース。
詳細なデバッグ レポートには、ソースの登録が成功したか、ソース、トリガー、アトリビューション レポートが生成されなかった理由を示す type フィールドが含まれます。
詳細デバッグ レポートは Chrome 109（2023 年 1 月）からご利用いただけます。ただし、Chrome 112 で追加されたソース登録成功の詳細デバッグ レポートは除きます。
パート 2: デバッグ レポートを設定するで、レポートの例を確認します。
デバッグ レポートは Cookie ベースです
デバッグ レポートを使用するには、レポート送信元が Cookie を設定する必要があります。
レポートを受信するように設定されているオリジンがサードパーティである場合、この Cookie はサードパーティ Cookie になります。これには、次のような影響があります。
- デバッグ レポートは、ユーザーのブラウザでサードパーティ Cookie が許可されている場合にのみ生成されます。
- サードパーティ Cookie の段階的廃止後は、デバッグ レポートは利用できなくなります。
デバッグ レポートがすぐに送信されます
デバッグ レポートは、ブラウザからレポート送信元に直ちに送信されます。これは、遅れて送信されるアトリビューション レポートとは異なります。
対応するアトリビューション レポートが生成されるとすぐに（つまりトリガーの登録時に）、成功デバッグ レポートが生成されて送信されます。
詳細なデバッグ レポートは、ソースまたはトリガーの登録後すぐに送信されます。
デバッグ レポートのエンドポイント パスが異なる
アトリビューション レポートと同様に、すべてのデバッグ レポートはレポート元に送信されます。デバッグ レポートは、レポート送信元の 3 つの個別のエンドポイントに送信されます。
- 成功デバッグ レポートのエンドポイント（イベントレベル）
- 成功デバッグ レポートのエンドポイント（集計可能）
- 詳細デバッグ レポート（イベントレベルおよび集計可能）のエンドポイント。
詳細については、パート 2: デバッグ レポートを設定するをご覧ください。
ユースケース
基本的なリアルタイム統合チェック
デバッグ レポートはすぐにエンドポイントに送信されます。これは、ユーザーのプライバシーを保護するために遅延するアトリビューション レポートとは異なります。デバッグ レポートを、Attribution Reporting API との統合が機能していることのリアルタイム シグナルとして使用する。
この方法については、パート 3: デバッグ クックブックをご覧ください。
損失の分析
サードパーティ Cookie とは異なり、Attribution Reporting API には、実用性とプライバシーのバランスを取るように設計されたプライバシー保護が組み込まれています。つまり、Attribution Reporting API では、現在 Cookie を使って収集している測定データの一部を収集できない可能性があります。サードパーティ Cookie でトラッキングできるコンバージョンでも、アトリビューション レポートが生成されないことがあります。
たとえば、イベントレベル レポートでは、1 回のインプレッションで登録できるコンバージョンは 1 件までです。つまり、特定の広告インプレッションについて、ユーザーが何回コンバージョンを達成しても、アトリビューション レポートは 1 つしか取得できません。
デバッグ レポートを使用すると、Cookie ベースの測定結果と Attribution Reporting API で得られる結果の違いを確認できます。レポートされるコンバージョン、レポートされていないコンバージョンの数、特にレポートされるコンバージョンとその理由を特定できる。
損失分析の実行方法については、パート 3: デバッグ クックブックをご覧ください。
トラブルシューティング
プライバシーやリソースの保護に起因する損失は想定されますが、それ以外の損失は意図しない可能性があります。実装の構成ミスやブラウザ自体のバグが原因で、レポートが欠落する場合があります。
デバッグ レポートは、お客様側で実装の問題を検出して修正する場合や、潜在的なバグをブラウザチームに報告する場合に使用できます。この方法については、パート 3: デバッグ クックブックをご覧ください。
高度な構成チェック
Attribution Reporting API の一部の機能を使用すると、API の動作をカスタマイズできます。たとえば、フィルタリング ルール、重複除去ルール、優先度ルールなどがこれに該当します。
これらの機能を使用する場合は、デバッグ レポートを使用することで、アトリビューション レポートを待つことなく、ロジックが本番環境で意図した動作につながるかどうかを確認できます。この方法については、パート 3: デバッグ クックブックをご覧ください。
集計可能レポートを使用したローカルテスト
暗号化された集計可能アトリビューション レポートとは異なり、集計可能デバッグ レポートには暗号化されていないペイロードが含まれます。
集計可能デバッグ レポートを使用して、集計可能レポートの内容を検証し、テスト用のローカル集計ツールで概要レポートを生成します。
集計サービス レポートの再処理
デバッグモードを使用するもう一つの利点は、レポートを再度処理できることです。そのため、レポートを複数回処理するには、デバッグ レポートを有効にする必要があります。レポートの再処理が推奨されるのは次のような場合です。
- デバッグに使用するサンプル データです。
- さまざまなバッチ処理戦略を試すことができます。
- さまざまなイプシロン値でテストします。
データ復旧
広告テクノロジーがレポートデータを復元できるように、デバッグ レポートを受信できるようにデバッグモードを有効にすることをおすすめします。これは、集計サービスの問題（サービスが使用できない、または応答しないなど）によって概要レポートの生成が失敗する場合に役立ちます。