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

最近の更新

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

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

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

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

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

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

Attribution Reporting API にアクセスする

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

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

登録の際、広告テクノロジー プラットフォームは、アトリビューション ソースとトリガーを登録するためにアプリとウェブにわたって使用する可能性のあるすべてのサーバー URL で登録していることを確認する必要があります。複数のサーバー登録 URL がサポートされていますが、サポートされているレポート元は 1 つのみです。いずれかのサーバー登録 URL のドメインが、このレポート元になります。

広告テクノロジーに関する変更

このセクションでは、Attribution Reporting API を使用する広告テクノロジーの変更について説明します。

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

アトリビューション ソースを登録する際、広告テクノロジーは、トリガー イベントが発生するアプリのパッケージ名をデスティネーション フィールドに指定します。アプリからウェブの測定を可能にするために、アプリのデスティネーション フィールド（アプリのパッケージ名）とウェブのデスティネーション フィールド（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 日目、ユーザーがブラウザアプリで広告をクリックします。
    • ブラウザアプリは独自の測定ソリューションを使用するか、ウェブ広告のクリックの登録を Attribution Reporting API に渡すかを選択できます。
  • 2 日目、ユーザーがブラウザ以外のアプリで広告をクリックします。
    • クリックがアトリビューション ソースとして API に登録されます。イベントは別のアプリ内で発生したため、ブラウザアプリはこのクリックを確認できません。
  • 3 日目、ユーザーがブラウザアプリでコンバージョンを実行します。
    • ブラウザアプリが独自の測定ソリューションを使用してクリックとコンバージョンの両方を登録し、その情報を Attribution Reporting API に渡す場合、広告テクノロジーが測定ソリューション間におけるコンバージョン レポートの重複を排除できる可能性は低くなります。さらに広告テクノロジーは、ブラウザアプリのレート制限と Attribution Reporting API のレート制限の両方を消費する可能性があります。そのため、API を利用できる場合は、API に登録するすべての広告イベントとコンバージョンをアプリで渡すことをおすすめします。

WebView からアトリビューション ソースとトリガーを登録する

アプリが Android 広告ではなく WebView を使用してウェブ コンテンツを表示している場合は、registerWebSource() の許可リストへの登録を申請し、アプリのパッケージ名ではなく、アトリビューション ソースに関連付けるウェブサイトのトップレベルのオリジンを提供できます。

ブラウザと同様に、WebView はトリガー登録の registerWebTrigger() をサポートしています。これにより、トリガーをトップレベルのオリジンに関連付けることができます。WebView でアプリ トリガーを登録することはできません。このユースケースがある場合は、お問い合わせください。WebView でサポートされている組み合わせの一覧については、WebView からのアトリビューション ソースとトリガーの登録をご覧ください。

ブラウザとは異なり、WebView は、Android の Attribution Reporting API が使用可能な場合にのみ、Attribution-Reporting-Eligible ヘッダー内の OS への登録をサポートします。Android の Attribution Reporting API を使用できない場合、WebView は Attribution-Reporting-Eligible ヘッダーを設定しないため、登録は行われません。

OS を使用してアトリビューション ソース / トリガーを登録するには:

  • 広告テクノロジーは、Attribution-Reporting-Register-OS-Source ヘッダーを使用してソース登録に応答する必要があります。これにより、WebView から registerSource() または registerWebSource() への二次 API 呼び出しが開始されます。
  • 広告テクノロジーは、Attribution-Reporting-Register-OS-Trigger ヘッダーを使用してトリガー登録に応答することもできます。これにより、WebView から registerWebTrigger() または registerTrigger() への二次 API 呼び出しが開始されます。

レスポンスに上記のヘッダーが含まれていない場合、またはウェブがサポートされていないにもかかわらず Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger ヘッダーも含まれている場合、登録全体が失敗します。

WebView が registerSource() / registerWebSource() と registerTrigger() / registerWebTrigger() のどちらを使用するか（およびこの動作を変更する方法）については、WebView からのアトリビューション ソースとトリガーの登録をご覧ください。

移行デバッグ レポート

Attribution Reporting API は、移行デバッグ レポートと呼ばれるオプション機能をサポートしています。これにより、広告テクノロジーは、広告 ID がある場合にアトリビューション レポートの詳細情報を確認できます。デバッグ レポートにはアトリビューション成功レポートと詳細レポートの 2 種類があります。これらのレポートは、アプリとウェブにわたるアトリビューションでサポートされており、どちらのレポートタイプも同じ情報を含みます。唯一の違いは、デバッグ レポートの送信時に権限を制御することです。

1 つのアプリ内（同じブラウザアプリ内など）で発生するウェブからウェブのアトリビューションの場合、アトリビューション成功レポートと詳細レポートは、サードパーティ Cookie が使用可能な場合にのみ利用できます。広告 ID を利用できるかどうかには基づきません。

アプリからウェブ、ウェブからアプリ、ウェブからウェブのクロスアプリ アトリビューションの場合、アプリ側で AdID が利用可能であり、広告テクノロジーがウェブ側に同じ（正しい）AdID を渡すことができる場合に、アトリビューション成功レポートと詳細レポートを利用できます。

後述のアプリからウェブの例では、ソースはパブリッシャー アプリで発生しますが、トリガーはブラウザアプリ内の広告主サイトで発生します。

アプリからウェブのアトリビューション成功デバッグ レポートを有効にするには、次の条件を満たす必要があります。

  • ユーザーが広告 ID によるパーソナライズを無効にしていない
  • パブリッシャー アプリで AdID 権限が宣言されている
  • 広告テクノロジーがトリガー登録で（ウェブ コンテキストから）AdID 値を渡す

アプリからウェブの詳細デバッグ レポートを有効にするには:

  • ソース詳細レポートは、パブリッシャー側の権限にのみ依存します。ソース詳細レポートを送信するには、ユーザーが AdID のパーソナライズを無効にしておらず、また、パブリッシャー アプリで AdID 権限が宣言されている必要があります。
  • トリガー詳細レポートは、トリガー側（この例ではウェブ）の権限にのみ依存します。トリガー詳細レポートを送信するには、ブラウザでサードパーティ Cookie が利用できる必要があります。
  • source_debug_key をオプションで含むことができるトリガー詳細レポートでは、パブリッシャー アプリで広告 ID を利用できる場合に source_debug_key が含まれます。

いずれの場合も、広告テクノロジーは、ソースとトリガーの登録ヘッダーの debug_reporting ディクショナリ フィールドを使用して、詳細デバッグ レポートの受信を有効にする必要があります。

アプリの変更点

新しいウェブ コンテキスト 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() を呼び出し、必要に応じて独自の権限ポリシーを適用できるようにする必要があります。

registerWebSource() を呼び出すには、アプリを許可リストに登録する必要があります。許可リストに登録するには、こちらのフォームにご入力ください。許可リストの目的は、ウェブ コンテキストに対する信頼の確立に関するプライバシーの懸念を軽減することです。

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

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

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

WebView からのアトリビューション ソースとトリガーの登録

デフォルトでは、WebView は registerSource() と registerWebTrigger() を使用します。これにより、ソースがアプリに関連付けられ、トリガーが発生したときに WebView のトップレベルのオリジンとトリガーが関連付けられます。

アプリで異なる動作（WebView でウェブ コンテンツをホストする動作など）が必要な場合は、androidx.webkit.WebViewSettingsCompat クラスの setAttributionRegistrationBehavior メソッドを使用する必要があります。このメソッドでは、WebView が registerWebSource() と registerSource() のどちらを呼び出すか、registerWebTrigger() と registerTrigger() のどちらを呼び出すかを指定します。

setAttributionRegistrationBehavior で使用できるオプションは次のとおりです。

値 説明 使用例
APP_SOURCE_AND_WEB_TRIGGER（デフォルト） アプリが WebView からアプリソース（アプリのパッケージ名に関連付けられたソース）とウェブトリガー（eTLD+1 に関連付けられたトリガー）を登録できるようにします。 ウェブ ブラウジングではなく WebView を使用して広告を配信するアプリ
WEB_SOURCE_AND_WEB_TRIGGER アプリが WebView からウェブソースとウェブトリガーを登録できるようにします。
注: このオプションを使用するアプリは、registerWebSource() を使用する許可リストに登録する必要があります。		 WebView ベースのブラウザアプリ: 広告のインプレッションとコンバージョンの両方が WebView 内のウェブサイトで発生する可能性があります。
APP_SOURCE_AND_APP_TRIGGER WebView からアプリソースとアプリトリガーを登録できるようにします。 WebView ベースのアプリ。広告のインプレッションとコンバージョンは、WebView の eTLD+1 ではなく、常にアプリに関連付ける必要があります。
無効 WebView からのソースとトリガーの登録を無効にします。
アトリビューション ソースまたはトリガーの URI への最初のネットワーク呼び出しは引き続き行われますが、レスポンスは破棄され、デバイスに何も保存されません。

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

このセクションでは、Attribution Reporting API を使用するアプリのプライバシーとセキュリティに関する考慮事項について説明します。

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

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

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

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

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

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

このリスクを軽減するため、registerWebSource() を呼び出せるブラウザまたはアプリは、登録に使用されたソースサイトがユーザーに表示される実際のサイトを表すことを証明するブラウザまたはアプリに限定します。registerWebSource() を呼び出すには、ウェブからアプリへのアトリビューション レポートの登録フォームに入力し許可リストに登録してください。

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

ユーザー コントロール

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

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

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

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

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