アトリビューション レポートのデバッグに関する 3 部構成のパート 1。デバッグが重要な理由と、テストでデバッグ レポートを使用するタイミングについて説明します。
デバッグ レポートが必要な理由
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 が許可されている場合にのみ生成されます。
デバッグ レポートはすぐに送信されます
デバッグ レポートは、ブラウザからレポート作成元に直ちに送信されます。これは、遅延して送信されるアトリビューション レポートとは異なります。
成功デバッグ レポートは、対応するアトリビューション レポートが生成されるとすぐに（トリガー登録時）、生成されて送信されます。
詳細なデバッグ レポートは、ソースまたはトリガーの登録時にすぐに送信されます。
デバッグ レポートのエンドポイント パスが異なる
アトリビューション レポートと同様に、すべてのデバッグ レポートはレポート作成元に送信されます。デバッグ レポートは、レポート オリジンの 3 つの別々のエンドポイントに送信されます。
- イベントレベルの成功デバッグ レポートのエンドポイント
- 成功デバッグ レポートのエンドポイント（集計可能）
- 詳細デバッグ レポート（イベントレベルと集計可能）のエンドポイント。
詳しくは、パート 2: デバッグ レポートを設定するをご覧ください。
ユースケース
基本的なリアルタイム統合チェック
デバッグ レポートは、ユーザーのプライバシーを保護するために遅延されるアトリビューション レポートとは異なり、エンドポイントに直ちに送信されます。デバッグ レポートを、Attribution Reporting API との統合が機能していることを示すリアルタイム シグナルとして使用します。
この方法については、パート 3: デバッグ クックブックをご覧ください。
損失分析
サードパーティ Cookie とは異なり、Attribution Reporting API にはプライバシー保護機能が組み込まれており、有用性とプライバシーのバランスを取るように設計されています。つまり、Attribution Reporting API では、Cookie で収集できるすべての測定データを収集できない可能性があります。サードパーティの Cookie でトラッキングできるすべてのコンバージョンでアトリビューション レポートが生成されるわけではありません。
たとえば、イベントレベル レポートでは、インプレッションごとに登録できるコンバージョンは 1 つだけです。つまり、ユーザーがコンバージョンを達成した回数に関係なく、特定の広告のインプレッションに対して 1 つのアトリビューション レポートのみが生成されます。
デバッグ レポートを使用すると、Cookie ベースの測定結果と Attribution Reporting API で得られる結果の違いを把握できます。どのコンバージョンがレポートされるか、レポートされないコンバージョンがいくつあるか、具体的にどのコンバージョンがレポートされないか、その理由を特定します。
損失分析を実行する方法については、パート 3: デバッグ クックブックをご覧ください。
トラブルシューティング
プライバシー保護やリソース保護によって発生する損失は想定内ですが、それ以外の損失は想定外である可能性があります。実装の構成ミスやブラウザ自体のバグが原因で、レポートが欠落することがあります。
デバッグ レポートを使用すると、実装の問題を検出して修正したり、潜在的なバグをブラウザ チームに報告したりできます。この方法については、パート 3: デバッグのクックブックをご覧ください。
高度な構成チェック
Attribution Reporting API の一部の機能では、API の動作をカスタマイズできます。フィルタリング ルール、重複除去ルール、優先度ルールなどがその例です。
これらの機能を使用する際は、デバッグ レポートを使用して、アトリビューション レポートを待たずに、ロジックが本番環境で意図した動作につながることを確認してください。この方法については、パート 3: デバッグ クックブックをご覧ください。
集計可能レポートを使用したローカル テスト
暗号化された集計可能アトリビューション レポートとは異なり、集計可能デバッグ レポートには暗号化されていないペイロードが含まれます。
集計可能デバッグ レポートを使用して、集計可能レポートの内容を検証し、ローカルの集計ツールでテスト用の概要レポートを生成します。
集計サービス レポートを再処理する
デバッグモードを使用するもう 1 つのメリットは、レポートを再度処理できることです。そのため、レポートを複数回処理するには、デバッグ レポートが有効になっていることを確認してください。次のような場合は、レポートの再処理が必要になることがあります。
- Aggregation Service のデバッグを試みている。
- さまざまなバッチ処理戦略を試す。
- さまざまなイプシロン値を試す。
データ復旧
広告テクノロジー プロバイダは、デバッグ レポートを受信してレポートデータを復元できるように、デバッグモードを有効にすることをおすすめします。これは、集計サービスの問題（サービスが利用できない、応答しないなど）が原因で概要レポートの生成が失敗する可能性がある場合に役立ちます。