アトリビューション レポート: アプリとウェブにわたる測定

フィードバックを送信

Attribution Reporting API の設計案に記載されているように、この API を使用すると、1 台の Android デバイスで次のトリガーパスのアトリビューションが可能になります。

  • アプリからアプリ: アプリでユーザーに広告が表示されてから、そのアプリまたは別のインストール済みアプリでコンバージョンを実行します。
  • アプリからウェブ: アプリでユーザーに広告が表示されてから、モバイルまたはアプリのブラウザでコンバージョンを実行します。
  • ウェブからアプリ: モバイルまたはアプリのブラウザでユーザーに広告が表示されてから、アプリでコンバージョンを実行します。
  • ウェブからウェブ: モバイルまたはアプリのブラウザでユーザーに広告が表示されてから、同じブラウザまたは同じデバイス上の別のブラウザでコンバージョンを実行します。

ここでいうウェブとは、アプリで表示されるウェブ コンテンツのことです。ウェブ コンテンツは、モバイル ブラウザ アプリのコンテキストで表示されることもあれば、ブラウザ以外のアプリで表示される埋め込みウェブサイトとして表示されることもあります。

上記のトリガーパスは、以下の要件となります。

  • アドテック: アプリからウェブのパスを有効にするための、API 呼び出しとレポートの更新
  • アプリとブラウザ: ウェブ アトリビューション ソースとウェブトリガーの登録を Android に渡す機能

このドキュメントでは、アプリからウェブ、ウェブからアプリ、ウェブからウェブのトリガーパスをサポートするために、Attribution Reporting API がどのように拡張されるかについて説明します。また、これらのトリガーパスのサポート要件を満たすために、アドテックとアプリで必要となる変更についても説明します。

Attribution Reporting API にアクセスする

Attribution Reporting API にアクセスするには、アドテック プラットフォームの登録が必要です。詳しくは、プライバシー サンドボックス アカウントの登録をご覧ください。

登録プロセスが終了すると、未登録の登録呼び出しを受け取った場合、API はその登録を破棄します。

登録の際、アトリビューション ソースとトリガーを登録するためにアプリとウェブ全体で使用される可能性のあるすべてのサーバー URL に関して、アドテック プラットフォームを登録しなければなりません。複数のサーバー登録 URL がサポートされていますが、サポートされているレポート元は 1 つのみです。いずれかのサーバー登録 URL のドメインが、このレポート元になります。

アドテックの変更

登録とアトリビューションの変更点

アトリビューション ソースを登録する際、アドテックは現在、トリガー イベントが発生するアプリのパッケージ名をデスティネーション フィールドに指定しています。アプリからウェブの測定を可能にするために、アプリのデスティネーション フィールド（アプリのパッケージ名）とウェブのデスティネーション フィールド（eTLD+1）を 1 つずつサポートする予定です。

ウェブ アトリビューションのソースまたはトリガーを登録する場合、ウェブ コンテンツをホストするアプリには独自の権限モデルが存在することがあるため、この API でリダイレクトはサポートされません。各アプリは、リダイレクトをたどり（サポートされている場合）、リダイレクト ホップごとにウェブ コンテキスト API を呼び出します。

また、この統合でアドテックは、ウェブ アトリビューション ソースでアプリ固有のアトリビューション ロジックを使用できるようになります。たとえば、ウェブ アトリビューション ソースでインストール後のアトリビューション期間を指定できるようになりました。

アプリとウェブのレポートの受信

Android Attribution Reporting API は、アプリとウェブの両方のコンバージョンに関するレポートを送信できます。アドテックがウェブとアプリのサーフェス間でトリガーデータと集計 Key-Value を揃えない場合、ウェブとアプリのコンバージョンを区別できます。

  • イベントレベル レポートでは、トリガーがウェブ（デスティネーションは eTLD+1）、アプリ（デスティネーションはアプリのパッケージ名）のどちらで発生したのかを指定するデスティネーション フィールドをサポートします。
  • 集計可能レポートでは、デスティネーションはクリアテキストで送信されます。

ウェブからウェブの測定の影響

Attribution Reporting API に登録を渡すタイミングは、アプリが選択します。考慮事項は次のとおりです。

  • そのデバイスで Attribution Reporting API を利用できるか？デバイスで Attribution Reporting API を利用できるかどうかを返す新しいシグナルが、アプリに公開されます。アプリが Attribution Reporting API に登録を渡す方法の詳細については、アプリの変更に関するセクションをご覧ください。
  • アトリビューション ソースとトリガーのどの部分を API に渡す必要があるか？これは、各アプリ（アプリが許可している場合はアドテック）が決定します。アプリに独自の測定ソリューションがある場合は、それを代わりに使用することを検討できます。最終的には、すべてのソースとトリガーの登録を Android Attribution Reporting API に渡すことで、アプリとウェブにわたる非常に正確なアトリビューションが可能となります。

次の例は、ブラウザアプリと Attribution Reporting API を連携させて、ユーザーがブラウザアプリとブラウザ以外のアプリの両方で広告をクリックした場合に正確な測定を行う方法を示しています。

3 日間のユーザー クリックとコンバージョンの例
図 1. ブラウザとアプリにわたるソースとトリガーの登録の例
  • 1 日目、ユーザーがブラウザアプリで広告をクリックします。
    • ブラウザアプリは独自の測定ソリューションを使用するか、ウェブ広告のクリックの登録を Attribution Reporting API に渡すかを選択できます。
  • 2 日目、ユーザーがブラウザ以外のアプリで広告をクリックします。
    • クリックがアトリビューション ソースとして API に登録されます。イベントは別のアプリ内で発生したため、ブラウザアプリはこのクリックを確認できません。
  • 3 日目、ユーザーがブラウザアプリでコンバージョンを実行します。
    • ブラウザアプリが独自の測定ソリューションを使用してクリックとコンバージョンの両方を登録し、その情報を Attribution Reporting API に渡す場合、アドテックが測定ソリューション間におけるコンバージョン レポートの重複を排除できる可能性はあまりありません。さらにアドテックは、ブラウザアプリのレート制限と Attribution Reporting API のレート制限の両方を消費する可能性があります。そのため、API を利用できる場合、API に登録するすべての広告イベントとコンバージョンをアプリで渡すことをおすすめします。

アプリの変更点

新しいウェブ コンテキスト API 呼び出しのセットを使用して、アプリがウェブ アトリビューション ソースとウェブトリガーの登録を Android の Attribution Reporting API に渡せるようにすることで、アプリとウェブのサーフェスにわたるアトリビューションをサポートします。

以降のセクションの登録手順を完了すると、アプリとウェブのアトリビューション ソースとトリガーがデバイスに保存され、Attribution Reporting API がアプリとウェブのサーフェスにわたってソース優先ラストタッチ アトリビューションを実施できるようになります。

ブラウザと Android の Attribution Reporting API を統合してアプリとウェブをまたいだ測定を可能にする方法の例については、ウェブのプライバシー サンドボックスの提案をご覧ください。この提案では、ブラウザが次のリクエスト ヘッダーを追加します。

  • Attribution-Reporting-Eligible は、アトリビューションの OS レベルのサポートが使用可能かどうかをブロードキャストします。この例では、Android の Attribution Reporting API が使用可能かどうかを示しています。
  • アドテックはオプションで Attribution-Reporting-Register-OS-Source を使用して応答できます（使用可能な場合）。これにより、ブラウザアプリから registerWebSource() への二次 API 呼び出しが開始されます。
  • アドテックは、Attribution-Reporting-Register-OS-Trigger ヘッダーを使用してトリガー登録に応答することもできます。これにより、ブラウザアプリから registerWebTrigger() への二次 API 呼び出しが開始されます。

アトリビューション ソースの登録

アトリビューション ソースを登録する際、アプリは registerWebSource() を呼び出すことができます。想定されるパラメータは次のとおりです。

  • アトリビューション ソース URI: プラットフォームは、アトリビューション ソースに関連付けられたメタデータを取得するために、このリストの各 URI に対してリクエストを発行します。

    各 URI には、アドテックが提供するデバッグキーをレポートに含めるかどうかを示す、ブール値の Debug フラグを付ける必要があります。

  • 入力イベント: InputEvent オブジェクト（クリック イベントの場合）または null（ビューイベントの場合）のいずれか。

  • ソースオリジン: ソースが発生したオリジン（パブリッシャーのウェブサイト）。

  • OS デスティネーション: トリガー イベントが発生するアプリのパッケージ名。

  • ウェブ デスティネーション: トリガー イベントが発生する eTLD+1。

  • 確認済みデスティネーション: ユーザーがクリックしたときの移動に使用された OS またはウェブのデスティネーション URI / インテント。

API がアトリビューション ソース URI にリクエストを行うと、アドテックは HTTP ヘッダー Attribution-Reporting-Register-Source でアトリビューション ソースのメタデータを返します。このヘッダーは、アプリからアプリのアトリビューション ソースの登録と同じフィールドを使用しますが、違いがいくつかあります。

  • この API は、アドテックで指定されたデスティネーションと、アプリで指定されたデスティネーションを検証します。デスティネーションが異なる場合、API はアトリビューション ソースの登録を破棄します。

    アプリは、ウェブ コンテキスト API を呼び出す前に、ウェブ デスティネーションを検証することが期待されます。クリックの場合、アプリは、指定されたデスティネーションがユーザーの移動先と一致することを確認する必要があります。

  • API は、Attribution-Reporting-Redirects で指定されたリダイレクト URI を無視します。アプリは独自にリダイレクトをたどり、リダイレクトごとに registerWebSource() を呼び出し、必要に応じて独自の権限ポリシーを適用できるようにする必要があります。

トリガー（コンバージョン）の登録

トリガーを登録する際、アプリは registerWebTrigger() を呼び出すことができます。想定されるパラメータは次のとおりです。

  • トリガー URI: プラットフォームは、トリガーに関連付けられたメタデータを取得するために、このリストの各 URI に対してリクエストを発行します。
  • デスティネーション オリジン: トリガーが発生したオリジン（広告主のウェブサイト）。

プライバシーとセキュリティに関する考慮事項

レポートに適用されるプライバシー保護メカニズムへの影響

メインの設計案で説明されているように、API はプライバシー保護のレート制限をレポートに適用します。一部の制限は、ソースアプリとデスティネーション アプリに分割されます。ウェブ アトリビューションのソースまたはトリガーが登録されると、レート制限はアプリではなくソースまたはデスティネーション サイトによって分割されます。

アプリが個別のレート制限を維持する場合、敵対者は API のレート制限に加えて、アプリ固有のレート制限を消費する可能性があります。これを軽減するために、アプリは、特定のアトリビューション ソースがアプリの測定ソリューションと Android Attribution Reporting API の両方に登録されていないことを確認する必要があります。

ウェブ コンテキストに対する信頼の確立

ウェブ コンテキスト API の呼び出しで、API はアプリを信頼して、ソースオリジンとデスティネーション オリジンを検出し、指定します。これにより、プライバシーとセキュリティに関する考慮事項が生じる可能性があります。

  • 敵対者は、任意のソースが転送できる情報量のレート制限を回避するために、自身の所有するウェブサイトをホストしていると主張する可能性があります。
  • 複数の敵対者が共謀して別々のアトリビューション ソースを登録し、同じソースサイトを主張する可能性があります。これによりソースサイトが広告テクノロジー プラットフォームのレート制限に達し、実際のソースサイトが正規のアトリビューション ソースを登録できなくなるおそれがあります。

Google は、このような状況の軽減策を検討しています。その方法として、registerWebSource() を呼び出せるブラウザまたはアプリを、登録に使用されたソースサイトがユーザーに表示される実際のサイトを表すことを証明するブラウザまたはアプリに制限することが挙げられます。また、ウェブ コンテンツを検証するための技術的なソリューションも検討しています。ユースケースや、registerWebSource() を呼び出す必要があるアプリの種類についてフィードバックをお寄せください。

このトリガー側のプライバシーとセキュリティに関する考慮事項はソース側の共謀がないと該当しないため、どのアプリでも registerWebTrigger() を呼び出すことができます。

ユーザー コントロール

登録時に定義できる限り、アプリはユーザー コントロール ポリシーまたは権限ポリシーを引き続きサポートできます。たとえば、アプリがサイトレベルまたはユーザーレベルの権限を許可する場合、アプリはその権限を評価し、ウェブ コンテキスト API を呼び出すかどうかを決定する必要があります。

また、デバイス上でアプリ用に保存されたアトリビューション ソース、トリガー、保留中のレポートを削除するための、アプリからの新しい API 呼び出しがサポートされます。たとえば、アプリでユーザーの閲覧履歴を消去できるようにした場合、そのアプリは API を呼び出して、ユーザーのデバイスに保存されているアトリビューション ソース、トリガー、保留中のレポートを削除できます。

今後の検討事項と未解決の問題

Attribution Reporting API のアプリからウェブの相互運用性は現在開発中です。いくつかのアイデアについて、コミュニティからのフィードバックをお待ちしております。

  1. Android 版プライバシー サンドボックス対応デバイスで、Android Attribution Reporting API によるブラウザの測定ソリューションをどのように使用しますか？すべてを Android に渡す方がよいですか？
  2. 提案されているレート制限は、アプリとウェブのトラフィックに対して妥当ですか？
  3. アトリビューション ソースとトリガーごとに 2 つの ping（ブラウザ / アプリから 1 つ、Attribution Reporting API から 1 つ）を受け取る可能性があることに懸念はありますか？
  4. ブラウザ / アプリの API の登録とは異なり、Android API の登録のために別のサーバー エンドポイントを提供しますか？
  5. さまざまな API でデバッグが簡単になるようにするために、どのような支援が必要ですか？
  6. この提案には現在のところ、アプリとウェブのデスティネーションが提携していることの検証が含まれていません。今後、デジタル アセット リンクを使用して関連付けを確認することで、これらのデスティネーションを検証できるようになる可能性があります。その場合、ユースケースの妨げになりますか？デジタル アセット リンクを使用してこの検証を行うことは理にかなっていますか？
  7. ブラウザやアプリについて、ウェブ インプレッションの登録や、Android 版プライバシー サンドボックスの Attribution Reporting API とのその他の統合に興味をお持ちの場合は、ご連絡ください。
  8. アトリビューション ソースを登録する際は、デスティネーションを指定する必要があります。ウェブからアプリのケースで、アプリリンクを指定したい場合、どの形式を使用して指定するのでしょうか？
  9. アプリからウェブのアトリビューション ソースを登録する場合、そのソースイベントを Android Attribution Reporting API でアプリから登録する必要があります。たとえば、ユーザーが広告をクリックして、そのクリックによってブラウザまたはブラウザのカスタムタブが開いた場合でも、そのクリック（ソースイベント）はブラウザのコンテキストではなく、アプリから登録されるべきです。この点に関して懸念がある場合、または、サポートされているフローについてのこちらのドキュメントで挙げられているどのカテゴリにも該当しないユースケースがある場合は、お問い合わせください。