Attribution Reporting のデバッグに関するパート 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 には、実用性とプライバシーのバランスを取るよう設計されたプライバシー保護機能が組み込まれています。つまり、現在 Cookie で収集している測定データをすべて Attribution Reporting API で収集できない場合があります。サードパーティ Cookie でトラッキングできるすべてのコンバージョンで、アトリビューション レポートが生成されない場合があります。
たとえば、イベントレベル レポートの場合、インプレッションごとに登録できるコンバージョンは 1 つまでです。つまり、ユーザーがコンバージョンを何回達成しても、1 回の広告インプレッションで生成されるアトリビューション レポートは 1 つのみです。
デバッグ レポートを使用すると、Cookie ベースの測定結果と Attribution Reporting API で得られた結果の違いを可視化できます。レポートされるコンバージョンと レポートされないコンバージョンの数のほか
損失分析を実行する方法については、パート 3: デバッグ クックブックをご覧ください。
トラブルシューティング
プライバシーまたはリソースの保護による損失は想定内ですが、その他の損失は意図しない場合があります。実装の構成ミスやブラウザ自体のバグが原因で、レポートが表示されない場合があります。
デバッグ レポートを使用して、実装の問題を検出して修正したり、潜在的なバグをブラウザチームに報告したりできます。その方法については、パート 3: クックブックのデバッグをご覧ください。
高度な構成のチェック
Attribution Reporting API の一部の機能では、API の動作をカスタマイズできます。たとえば、フィルタリング ルール、重複除去ルール、優先度ルールなどです。
これらの機能を使用する場合は、デバッグ レポートを使用して、アトリビューション レポートを待たずに、ロジックが本番環境で目的の動作につながることを確認します。その方法については、「パート 3: クックブックのデバッグ」をご覧ください。
集計可能レポートを使用したローカルテスト
暗号化された集計可能アトリビューション レポートとは異なり、集計可能デバッグ レポートには暗号化されていないペイロードが含まれます。
集計可能デバッグ レポートを使用して、集計可能レポートの内容を検証し、テスト用のローカルの集計ツールを使用してサマリー レポートを生成します。
再処理集計サービス レポート
デバッグモードを使用するもう 1 つの利点は、レポートを再度処理できることです。このため、レポートを複数回処理する場合は、デバッグ レポートを必ず有効にしてください。次のような場合は、レポートを再処理することをおすすめします。
- 再度試行されます。
- さまざまなバッチ処理戦略を試すことができます。
- イプシロン値を変えてみます。
データ復旧
広告テクノロジーでデバッグモードを有効にして、デバッグ レポートを受信し、レポートデータを復元できるようにすることをおすすめします。これは、サービスが利用できない場合や応答しないなど、サマリー レポートの生成が失敗する可能性があるなど、集計サービスに問題が発生した場合に役立ちます。