デバッグレポートの概要

# デバッグレポートが必要な理由

Attribution Reporting API のテストを行う場合、統合が正しく機能しているかどうかを確認し、Cookie ベースの実装とアトリビューションレポートを用いた実装との間の測定結果の誤差について理解し、統合に関連するすべての問題についてのトラブルシューティングを行う必要があります。

これらの作業を完了するには、デバッグレポートが必要となります。したがって、オリジントライアルに参加する場合にはデバッグレポートのセットアップを強くお勧めさせていただきます。

# 用語集

# デバッグレポートの主なポイント

# 2 種類のデバッグレポート

2 種類のデバッグレポートが使用可能となっています。様々なユースケースに対応するために両方を使用してください。

# 成功デバッグレポート

成功デバッグレポートはアトリビューションレポートの生成の成功を追跡します。これらのレポートは、アトリビューションレポートに直接関係しています。

成功デバッグレポートは、Chrome 101（2022 年 4 月）以降で提供されています。

# 詳細デバッグレポート

詳細デバッグレポートでは、ソースイベントとトリガーイベントをより詳細に把握できます。そのため、ソースが正常に登録されたことを確認するか、不足しているレポートを追跡して、不足している理由（ソースイベントまたはトリガーイベントの失敗、イベントの送信または生成時の失敗）を特定することが可能です。詳細デバッグレポートには、以下の内容が示されます。

• ブラウザがソースを正常に登録したケース。
• ブラウザがソースイベントまたはトリガーイベントを正常に登録しなかったケース。つまり、アトリビューション レポートは生成されません。ないことを意味します。
• 何らかの理由でアトリビューション レポートを生成または送信できないケース。

詳細デバッグレポートには、ソース登録の成功、またはソース、トリガー、またはアトリビューション レポートが生成されなかった理由を説明する type フィールドが含まれます。

後の Chrome 112 で追加されたソース登録成功の詳細デバッグレポートを除き、詳細デバッグレポートは、Chrome 109（2023 年 1 月）以降で提供されています。

「パート 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 回の広告インプレッションについてはユーザーが何度コンバージョンしてもアトリビューションレポートは 1 つしか得られないことになります。

デバッグレポートを使用して、Cookie ベースの測定結果と Attribution Reporting API で得られた結果との違いを可視化します。どのコンバージョンについてレポートが生成されたか、どれだけのコンバージョンについてレポートが生成されなかったか、そして具体的にどのコンバージョンについてなぜレポートが生成されたのかについてピンポイントに把握することができます。

損失分析を行う方法の詳細については、「第 3 回: デバッグのクックブック」を参照してください。

# トラブルシューティング

プライバシーの保護やリソースの保護による損失は想定内であると言えますが、それ以外の損失については意図しないものである可能性があります。実装における構成ミスやブラウザー自体のバグによりレポートが失われてしまう場合もあるのです。

デバッグレポートを使用すれば、自分で実装に関する問題を検出して修正したり、ブラウザーの開発チームに潜在的なバグを報告したりすることができます。これを行う方法については、「第 3 回: デバッグのクックブック」を参照してください。

# 高度な構成チェック

Attribution Reporting API の一部の機能を使えば、API の動作をカスタマイズできるようになります。フィルタリングルール、重複排除ルール、優先順位ルールなどがその例として挙げられます。

これらの機能を使用する際は、アトリビューションレポートを待つのではなくデバッグレポートを使用してロジックが実際の運用中に意図した動作につながっているかどうかを確認します。これを行う方法については、「第 3 回: デバッグのクックブック」を参照してください。

# 集計可能なレポートを使用したローカルテスト

暗号化されている集計可能なアトリビューションレポートとは異なり、集計可能なデバッグレポートには暗号化されていないペイロードが含まれています。

集計可能なデバッグレポートを使用して集計可能なレポートの内容を検証し、テストを行うためにローカルの集計ツールを使用してサマリーレポートを生成します。

# 次へ

第 2 回: デバッグレポートのセットアップ