アトリビューション レポートのデバッグに関する 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 つの利点は、レポートを再度処理できることです。そのため、レポートを複数回処理するには、デバッグ レポートが有効になっていることを確認してください。レポートを再処理する必要があるのは、次のような場合です。
- 集計サービスをデバッグしようとしている。
- さまざまなバッチ処理戦略を試します。
- さまざまなエプシロン値を試します。
データ復旧
広告テクノロジーでデバッグモードを有効にしてデバッグ レポートを受信し、レポートデータを復元することをおすすめします。これは、集計サービスに関する問題（サービスが利用できない、サービスが応答しないなど）が原因で概要レポートの生成に失敗する可能性がある場合に役立ちます。