Android 版プライバシー サンドボックス デベロッパー プレビューがリリースされました。ご利用方法についてご確認のうえ、引き続きフィードバックをお寄せください

アトリビューション レポート

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

フィードバックを送信

現在、モバイル アトリビューションと測定ソリューションでは、広告 ID などのクロスパーティ ID を使用することが一般的です。Attribution Reporting API は、クロスパーティ ユーザー ID への依存をなくすことでユーザーのプライバシーを向上させ、アプリとウェブを対象としたアトリビューションとコンバージョン測定の主要なユースケースをサポートするように設計されています。

この API には、プライバシーを向上させるためのフレームワークを提供する、次のような構造メカニズムが用意されています。詳細については、このドキュメント内で別途説明します。

こうしたメカニズムにより、2 つの異なるアプリ間またはドメイン間でユーザー ID をリンクする機能が制限されます。

Attribution Reporting API では、次のユースケースがサポートされます。

  • コンバージョン レポート: キャンペーン別、広告グループ別、広告クリエイティブ別など、さまざまなディメンションでコンバージョン(トリガー)数やコンバージョン(トリガー)値を表示して、広告主がキャンペーンのパフォーマンスを測定できるようにします。
  • 最適化: ML モデルのトレーニングに使用できるインプレッションごとのアトリビューション データを提供することで、広告費の最適化をサポートするイベントレベルのレポートを提供します。
  • 無効なアクティビティの検出: 無効なトラフィックと広告の不正行為の検出と分析に使用できるレポートを提供します。

Attribution Reporting API の動作の概要は次のとおりです。詳細についてはこのドキュメント内で別途説明します。

  1. 広告テクノロジー プラットフォームが、Attribution Reporting API を使用するための登録プロセスを完了する
  2. 広告テクノロジー プラットフォームが、Attribution Reporting API にアトリビューション ソースを登録する(広告クリックまたは広告ビュー)。
  3. 広告テクノロジー プラットフォームが、Attribution Reporting API にトリガーを登録する(広告主のアプリまたはウェブサイトのユーザー コンバージョン)。
  4. Attribution Reporting API が、トリガーをアトリビューション ソース(コンバージョン アトリビューション)と照合し、1 つ以上のトリガーがイベントレベル レポートと集計可能レポートを通じてデバイスから広告テクノロジー プラットフォームに送信される。

広告テクノロジー プラットフォームを登録する

Attribution Reporting API にアクセスするために、また、プライバシー メカニズムを意図したとおりに機能させるために、広告テクノロジー プラットフォーム(Google のものを含む)はすべて、簡単な登録プロセスを完了する必要があります。このプロセスの詳細は開発中です。フィードバックをお待ちしております。

登録プロセスを用意することで、ユーザーのサイトとアプリのアクティビティに関する詳細情報を得るために、広告テクノロジー プラットフォームが不必要に重複しないで済むようになります。たとえば、Attribution Reporting API により、特定のアトリビューション ソースとトリガーについて、広告テクノロジー プラットフォームが表示できるトラッキングと情報の量を制限します。制限の詳細については、このドキュメントで後述するアトリビューション レポートで測定データを表示するをご覧ください。

企業は、正当なビジネス上の必要性(複数の独立したプロダクト ラインの運営など)があれば複数回登録することが可能です。プライバシーの制限を回避するために複数の登録データを組み合わせることはありません。

登録の際、広告テクノロジー プラットフォームから次のような情報が提供されます。

  • 連絡先とビジネス情報
  • アトリビューションのソースとトリガーの登録に使用する URL
  • イベントレベル レポートと集計可能レポートの受信に使用するポストバック URL
  • Attribution Reporting API のユースケース

アトリビューション ソース(クリックまたはビュー)を登録する

Attribution Reporting API では、広告クリックと広告ビューを「アトリビューション ソース」と呼称します。広告クリックまたは広告ビューを登録するには、registerSource() を呼び出します。この API には次のパラメータが必要です。

  • アトリビューション ソース URI: プラットフォームでは、アトリビューション ソースに関連付けられたメタデータを取得するために、この URI に対してリクエストを実行します。
  • 入力イベント: InputEvent オブジェクト(クリック イベントの場合)または null(ビューイベントの場合)のいずれか。

API がアトリビューション ソース URI にリクエストを行うと、広告テクノロジー プラットフォームは、次のフィールドを持つ新しい HTTP ヘッダー Attribution-Reporting-Register-Source でアトリビューション ソースのメタデータを返します。

  • ソースイベント ID: 64 ビット符号なし整数をエンコードする DOMString。この値は、このアトリビューション ソース(広告クリックまたは広告ビュー)に関連付けられているイベントレベル データを表します。
  • デスティネーション: トリガー イベントが発生する eTLD+1 またはアプリ パッケージ名の元。
  • 期限(省略可): デバイスからソースを削除する必要がある期限(秒単位)。デフォルトは 30 日であり、最小値は 2 日、最大値は 30 日です。最も近い日の概数となります。
  • ソース優先度(省略可): 64 ビット符号付き整数。複数のアトリビューション ソースが特定のトリガーに関連付けられる場合に、そのトリガーをどのアトリビューション ソースに関連付ける必要があるかを選択するために使用されます。

    トリガーを受信すると、API は最も高いソース優先度値に一致するアトリビューション ソースを見つけて、レポートを生成します。各広告テクノロジー プラットフォームが、独自の優先度設定戦略を定義できます。優先度がアトリビューションに及ぼす影響について詳しくは、優先度設定の例をご覧ください。

    値が大きいほど優先度が高くなります。

  • インストールとインストール後のアトリビューション期間(省略可): このドキュメントで後述するインストール後のイベントのアトリビューションを決定するために使用します。

  • データのフィルタ(省略可): 一部のトリガーを選択的にフィルタし、事実上無視するために使用します。詳細については、このページのコンバージョン フィルタをご覧ください。

アトリビューション ソースのメタデータ レスポンスでは、次の個別ヘッダーに追加データが含まれる場合があります。

次のスニペットは、アトリビューション ソースデータの現在の設計を示しています。

// Metadata associated with attribution source.
Attribution-Reporting-Register-Source: {
  "destination": "[app package name]",
  "source_event_id": "[64 bit unsigned integer]",
  "expiry": "[64 bit signed integer]",
  "source_priority": "[64 bit signed integer]"
}
// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Aggregatable-Source:
[{
  "id": "[key name]",
  "key_piece": "[key piece value]",
 },
 ..
]
// Specify additional Adtech URLs to register this source with.
Attribution-Reporting-Redirects: <Ad tech partner URIs; comma-separated>

ワークフローの例は次のとおりです。

  1. 広告テクノロジー SDK が API を呼び出してアトリビューション ソースの登録を開始し、API で呼び出す URI を指定します。

    registerSource(
        Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
        myClickEvent);
    
  2. API が次のいずれかのヘッダーを使用して、https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA にリクエストを行います。

    <!-- For click events -->
    Attribution-Reporting-Source-Info: navigation
    
    <!-- For view events -->
    Attribution-Reporting-Source-Info: event
    
  3. この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "234",
        "expiry": "60000",
        "source_priority": "5"
    }
    Attribution-Reporting-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    https://adtechpartner2.example?their_ad_click_id=890
    
  4. API が、Attribution-Reporting-Redirects で指定された各 URL にリクエストを行います。この例では、広告テクノロジー パートナー URL が 2 つ指定されているため、API は https://adtechpartner1.example?their_ad_click_id=567https://adtechpartner2.example?their_ad_click_id=890 のそれぞれにリクエストを行います。

  5. この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。

    Attribution-Reporting-Register-Source: {
        "destination": "android-app://com.advertiser.example",
        "source_event_id": "789",
        "expiry": "120000",
        "source_priority": "2"
    }
    

ここまでのステップで示したリクエストに基づいて、3 つのナビゲーション(クリック)アトリビューション ソースが登録されます。

トリガー(コンバージョン)を登録する

広告テクノロジー プラットフォームは registerTrigger() メソッドを使用してトリガー(インストールまたはインストール後のイベントなどのコンバージョン)を登録できます。

registerTrigger() メソッドにはトリガー URI パラメータが必要です。API は、トリガーに関連付けられたメタデータを取得するために、この URI に対してリクエストを実行します。

API はリダイレクトに従います。広告テクノロジー サーバーのレスポンスには、1 つ以上の登録済みトリガーの情報を表す、Attribution-Reporting-Register-Event-Trigger という HTTP ヘッダーが含まれている必要があります。ヘッダーの内容は JSON でエンコードされ、次のフィールドを含む必要があります。

  • トリガーデータ: トリガー イベントを特定するためのデータ(クリックは 3 ビット、ビューは 1 ビット)
  • トリガー優先度(省略可): 同じアトリビューション ソースの他のトリガーと比較した、このトリガーの優先度を表す 64 ビット符号付き整数優先度がレポートに及ぼす影響について詳しくは、優先度設定の例をご覧ください。
  • 重複除去キー(省略可): 同じアトリビューション ソースについて、同じ広告テクノロジー プラットフォームによって同じトリガーが複数回登録されているケースを特定するために使用される 64 ビット符号付き整数

広告テクノロジー サーバーのレスポンスでは、次のヘッダーに追加データが含まれる場合があります。

複数の広告テクノロジー プラットフォームが、Attribution-Reporting-Redirects フィールドでリダイレクトを使用するか、registerTrigger() メソッドを複数回呼び出して、同じトリガー イベントを登録できます。同じ広告テクノロジー プラットフォームが同じトリガー イベントに対して複数のレスポンスを提供する場合、レポートに重複するトリガーが含まれないように、重複除去キー フィールドの使用をおすすめします。

次のスニペットは、トリガーデータの現在の設計を示しています。

// Metadata associated with trigger.
Attribution-Reporting-Register-Event-Trigger:
[{
    // trigger_data returned in event reports is truncated to the last 1 or 3 bits,
    // based on conversion type
    "trigger_data": "[unsigned 64-bit integer]",
    "trigger_priority": "[signed 64-bit integer]",
    "deduplication_key": "[signed 64-bit integer]"
}]
// This is where the Attribution-Reporting-Register-Aggregatable-Trigger-Data
// and Attribution-Reporting-Register-Aggregatable-Values objects appear when
// an ad tech platform registers an aggregatable conversion trigger.
// Specify additional Adtech URLs to register this trigger with.
Attribution-Reporting-Redirects: 

ワークフローの例は次のとおりです。

  1. 登録した URI で、広告テクノロジー SDK が API を呼び出してトリガーの登録を開始します。

    triggerAttribution(
        Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
    
  2. API が https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA にリクエストを行います。

  3. この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "1122",
        // This returns 010 for click-through conversions (CTCs) and 0 for
        // view-through conversions (VTCs) in reports
        "trigger_priority": "3",
        "deduplication_key": "3344",
    }
    Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567
    
  4. API が、Attribution-Reporting-Redirects で指定された各 URL にリクエストを行います。この例では URL が 1 つしか指定されていないため、API は https://adtechpartner.example?app_install=567 にリクエストを行います。

  5. この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。

    Attribution-Reporting-Register-Event-Trigger: {
        "trigger_data": "5566",
        "trigger_priority": "3",
        "deduplication_key": "3344"
    }
    

    ここまでのステップのリクエストに基づいて、2 つのトリガーが登録されます。

アトリビューションの機能

次のセクションでは、Attribution Reporting API がコンバージョン トリガーとアトリビューション ソースを照合する仕組みについて説明します。

ソース優先アトリビューション アルゴリズムの適用

Attribution Reporting API は、トリガー(コンバージョン)をアトリビューション ソースに一致させるためにソース優先アトリビューション アルゴリズムを適用します。

優先度パラメータは、トリガーのアトリビューションをソースにカスタマイズする方法を提供します。

  • トリガーを他のものよりも特定の広告イベントに強く関連付けることができます。たとえば、ビューよりもクリックを重視する場合や、特定のキャンペーンのイベントを重視する場合が考えられます。
  • アトリビューション ソースとトリガーは、レート制限に達した場合に、より重要性の高いレポートが届く可能性が高くなるように設定できます。たとえば、入札可能なコンバージョンや価値の高いコンバージョンがレポートに現れる可能性を高めることができます。

このドキュメントで後述するように、複数の広告テクノロジー プラットフォームがアトリビューション ソースを登録する場合、このアトリビューションは広告テクノロジー プラットフォームごとに独立して行われます。広告テクノロジー プラットフォームごとに、優先度が最も高いアトリビューション ソースがトリガー イベントに関連付けられます。同じ優先度のアトリビューション ソースが複数ある場合、API は最後に登録されたアトリビューション ソースを選択します。選択されなかった他のアトリビューション ソースは破棄され、今後のトリガー アトリビューションの対象ではなくなります。

コンバージョン フィルタ

ソースとトリガーの登録には、次を行うためのオプション機能も含まれています。

  • 一部のトリガーを選択的にフィルタし、事実上無視する。
  • ソースデータに基づいてイベントレベル レポートのトリガーデータを選択する。
  • トリガーをイベントレベル レポートから除外する。

広告テクノロジー プラットフォームでトリガーを選択的にフィルタするには、ソースとトリガーの登録時に、キーと値で構成されるフィルタデータを指定します。ソースとトリガーの両方に同じキーが指定されている場合、共通部分が空であればトリガーが無視されます。たとえば、ソースに "product": ["1234"] を指定した場合、product がフィルタキーで、1234 が値です。トリガー フィルタが "product": ["1111"] に設定されている場合、このトリガーは無視されます。product に一致するトリガー フィルタ キーがない場合、フィルタは無視されます。

広告テクノロジー プラットフォームでは、ソース イベント データに基づいてトリガーデータを選択することもできます。たとえば、source_type は API が navigation または event として自動的に生成します。トリガーの登録時、trigger_data で、ある値を "source_type": ["navigation"] に設定し、別の値を "source_type": ["event"] に設定することができます。

次のいずれかに該当する場合、トリガーはイベントレベル レポートから除外されます。

  • trigger_data が指定されていない。
  • ソースとトリガーで同じフィルタキーが指定されているが、値が一致しない。この場合、イベントレベル レポートと集約可能レポートのどちらでも、トリガーは無視されます。

インストール後のアトリビューション

場合によっては、最近発生した他の有効なアトリビューション ソースがあったとしても、インストール後のトリガーを、インストールにつながった同じアトリビューション ソースに帰属させる必要があります。

API では、広告テクノロジー プラットフォームがインストール後のアトリビューション期間を設定できるようにすることで、このユースケースをサポートできます。

  • アトリビューション ソースを登録する際、インストールが予想される、インストールのアトリビューション期間を指定します(許容範囲は 2~30 日間、通常は 2~7 日間)。
  • アトリビューション ソースを登録する際、インストール後のアトリビューション除外期間を指定します(許容範囲は 0~30 日間、通常は 7~30 日間)。この期間については、インストール後のトリガー イベントをインストールにつながったアトリビューション ソースに関連付ける必要があります。
  • Attribution Reporting API は、アプリのインストールがいつ行われたかを検証し、内部的にインストールをソース優先アトリビューション ソースに帰属させます。ただし、このインストールは広告テクノロジー プラットフォームには送信されず、プラットフォームのそれぞれのレート制限にカウントされません。
  • アプリのインストールの検証は、ダウンロードしたすべてのアプリで可能です。
  • インストール後のアトリビューション期間内に発生する今後のトリガーは、そのアトリビューション ソースが有効である限り、検証済みのインストールと同じアトリビューション ソースに帰属します。

    Google は、ユーザーがアプリをアンインストールしてから再インストールするユースケースをサポートする方法を検討中です。

将来的には、より高度なアトリビューション モデルをサポートするために設計の拡張を検討する可能性があります。

次の表に、広告テクノロジー プラットフォームでインストール後のアトリビューションを使用する例を示します。すべてのアトリビューション ソースとトリガーが同じ広告テクノロジー ネットワークによって登録されていて、すべての優先度が同じであるとします。

イベント イベントが発生する日 備考
クリック 1 1 install_attribution_window2 に設定し、post_install_exclusivity_window10 に設定します。
検証済みインストール 2 この API は、検証済みのインストールを内部的に関連付けますが、トリガーとはみなされません。したがって、この時点でレポートは送信されません。
トリガー 1(初回起動) 2 広告テクノロジーによって最初に登録されたトリガー。この例では、初回起動を表していますが、任意のトリガータイプを指定できます。
クリック 1 に関連付けされます(検証済みインストールのアトリビューションに一致)。
クリック 2 4 install_attribution_windowpost_install_exclusivity_window には、クリック 1 と同じ値を使用します。
トリガー 2(インストール後) 5 広告テクノロジーによって登録された 2 つ目のトリガー。この例では、購入などのインストール後コンバージョンを表しています。
クリック 1 に関連付けされます(検証済みインストールのアトリビューションに一致)。
クリック 2 は破棄され、将来のアトリビューションの対象外となります。

インストール後のアトリビューションに関するその他の注意事項は次のとおりです。

  • 検証済みインストールが install_attribution_window で指定された日数以内に発生しない場合、インストール後アトリビューションは適用されません。
  • 検証済みのインストールは、広告テクノロジー プラットフォームでは登録されず、レポートにも送信されません。広告テクノロジー プラットフォームのレート制限にはカウントされません。検証済みインストールは、そのインストールに貢献しているアトリビューション ソースの識別にのみ使用されます。
  • 上の表の例では、トリガー 1 とトリガー 2 がそれぞれ初回起動とインストール後コンバージョンを表しています。ただし、広告テクノロジー プラットフォームは任意の種類のトリガーを登録できます。つまり、最初のトリガーが初回起動である必要はありません。
  • post_install_exclusivity_window の期限が切れた後にトリガーがさらに登録された場合でも、期限内かつレート制限に達していないことを前提として、クリック 1 はアトリビューションの対象となります。
    • それでも、優先度の高いアトリビューション ソースが登録されている場合には、クリック 1 が失われるか、破棄される可能性があります。
  • 広告主のアプリがアンインストールされ、再インストールされた場合、再インストールは新しい検証済みインストールとしてカウントされます。
  • 一方、クリック 1 がビューイベントだった場合、「初回起動」トリガーとインストール後トリガーの両方が関連付けられます。この API では、アトリビューションが、ビューごとに 1 つのトリガーに制限されます。ただし、インストール後アトリビューションの場合は、ビューごとに 2 つまでのトリガーが許容されます。インストール後アトリビューションの場合、広告テクノロジーで 2 つの異なるレポート期間を受け取ることができます。

アプリベースとウェブベースのトリガーパスのすべての組み合わせをサポート

Attribution Reporting API を使用すると、1 台の Android デバイスで次のトリガーパスのアトリビューションが可能になります。

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

ウェブブラウザでは、新しいウェブ公開機能をサポートすることが可能です。ウェブの Attribution Reporting API 用のプライバシー サンドボックスと同様の機能などで、Android API を呼び出してアプリとウェブを対象にアトリビューションを有効にできます。

アプリとウェブにわたる測定のトリガーパスをサポートするために、広告テクノロジー プラットフォームとアプリで行う必要がある変更について説明します。

1 つのアトリビューション ソースに対する複数のトリガーに優先度を設定する

1 つのアトリビューション ソースが複数のトリガーにつながることがあります。たとえば、1 つの購入フローに、1 つの「アプリのインストール」トリガー、1 つ以上の「カートに追加」トリガー、1 つの「購入」トリガーが含まれる場合があります。各トリガーは、このドキュメントで後述するソース優先アトリビューション アルゴリズムに従って、1 つ以上のアトリビューション ソースに帰属します。

1 つのアトリビューション ソースに帰属させることができるトリガーの数には制限があります。詳しくは、このドキュメントで後述するアトリビューション レポートで測定データを表示するをご覧ください。この上限を超える複数のトリガーがある場合は、最も価値のあるトリガーを得るために、優先度設定ロジックを導入することをおすすめします。たとえば、広告テクノロジー プラットフォームのデベロッパーが、「カートに追加」トリガーよりも「購入」トリガーの方を優先させる場合などです。

このロジックをサポートするには、トリガーに個別の優先度フィールドを設定します。特定のレポート期間内で、制限が適用される前に最も優先度の高いトリガーが選択されます。

複数の広告テクノロジー プラットフォームがアトリビューション ソースまたはトリガーを登録できるようにする

複数の広告テクノロジー プラットフォームがアトリビューション レポートを受け取ることは一般であり、通常はクロスネットワークの重複排除を行います。そのため、この API を使用すると、複数の広告テクノロジー プラットフォームが同じアトリビューション ソースまたはトリガーを登録できます。広告テクノロジー プラットフォームは、API からポストバックを受け取るために、アトリビューション ソースとトリガーの両方を登録する必要があり、アトリビューションは、広告テクノロジー プラットフォームが API に登録したアトリビューション ソースとトリガーの間で行われます。

サードパーティを使用してクロスネットワーク重複排除を実行する広告主は、次のような手法で引き続き実行できます。

  • レポートの登録と API から受信を行うための社内サーバーをセットアップする。
  • 既存のモバイル測定パートナーを引き続き使用する。

アトリビューション ソース

アトリビューション ソースのリダイレクトは、registerSource() メソッドでサポートされています。

  1. registerSource() メソッドを呼び出す広告テクノロジー プラットフォームは、パートナー広告テクノロジーのリダイレクト URL のセットを表す Attribution-Reporting-Redirects フィールドをレスポンスに追加できます。
  2. API がリダイレクト URL を呼び出し、パートナー広告テクノロジー プラットフォームでアトリビューション ソースを登録できるようにします。

Attribution-Reporting-Redirects フィールドには、複数のパートナー広告テクノロジー プラットフォームの URL のリストを指定できます。パートナー広告テクノロジー プラットフォームが独自の Attribution-Reporting-Redirects フィールドを指定することはできません。

この API では、registerSource() の呼び出しごとに異なる広告テクノロジー プラットフォームを使用することもできます。

トリガー

トリガーの登録については、サードパーティも同様の方法でサポートされています。広告テクノロジー プラットフォームは、追加の Attribution-Reporting-Redirects フィールドを使用するか、registerTrigger() メソッドをそれぞれで呼び出すことができます。

広告主が複数の広告テクノロジー プラットフォームを使用して同じトリガー イベントを登録する場合は、重複除去キーを使用する必要があります。重複除去キーは、同じ広告テクノロジー プラットフォームで登録された同じイベントのレポートが繰り返される場合の曖昧さを取り除くために使用します。たとえば、ある広告テクノロジー プラットフォームが、自身の SDK で直接この API を呼び出してトリガーを登録し、自身の URL を別の広告テクノロジー プラットフォームの呼び出しでリダイレクト フィールドに指定するということができます。重複除去キーが指定されていない場合、重複するトリガーが一意なものとして各広告テクノロジー プラットフォームにレポートされる可能性があります。

クロスネットワーク アトリビューションの例

このセクションの例では、広告主は 2 つの配信広告テクノロジー プラットフォーム(アドテック A とアドテック B)と、1 つの測定パートナー(MMP)を使用しています。

まず、アドテック A、アドテック B、MMP のそれぞれが、Attribution Reporting API を使用するための登録を完了する必要があります。

次のリストは、それぞれ 1 日おきに発生する一連のユーザー アクションを仮定し、アドテック A、アドテック B、MMP に関して、Attribution Reporting API がそうしたアクションをどのように処理するかを示しています。

1 日目: アドテック A によって配信された広告をユーザーがクリックする

アドテック A が、URI を指定して registerSource() を呼び出します。API が URI にリクエストを行うと、アドテック A のサーバー レスポンスのメタデータにクリックが登録されます。

また、アドテック A の Attribution-Reporting-Redirects ヘッダーに MMP の URI が記載されます。API が MMP の URI にリクエストを行い、MMP のサーバー レスポンスのメタデータにクリックが登録されます。

2 日目: アドテック B によって配信された広告をユーザーがクリックする

アドテック B が、URI を指定して registerSource() を呼び出します。API が URI にリクエストを行い、アドテック B のサーバー レスポンスのメタデータにクリックが登録されます。

アドテック A と同様に、アドテック B の Attribution-Reporting-Redirects ヘッダーに MMP の URI が記載されます。API が MMP の URI にリクエストを行い、MMP のサーバー レスポンスのメタデータにクリックが登録されます。

3 日目: アドテック A によって配信された広告をユーザーが表示する

API は 1 日目と同様に応答します。ただし今回は、アドテック A と MMP にビューが登録されます。

4 日目: コンバージョンの測定に MMP を使用するアプリをユーザーがインストールする

MMP が、URI を指定して registerTrigger() を呼び出します。API が URL にリクエストを行い、MMP のサーバー レスポンスのメタデータにコンバージョンが登録されます。

また、MMP の Attribution-Reporting-Redirects ヘッダーにアドテック A とアドテック B の URI が記載されます。API がアドテック A とアドテック B のサーバーにリクエストを行い、それに応じてサーバー レスポンスのメタデータにコンバージョンが登録されます。

上のリストで説明したプロセスを図 1 に示します。

図 1. 一連のユーザー アクションに対する Attribution Reporting API の応答例。

アトリビューションは次のように機能します。

  • アドテック A は、クリックの優先度をビューより高く設定しているため、インストールを 1 日目のクリックに関連付けます。
  • アドテック B は、インストールを 2 日目に関連付けます。
  • MMP は、クリックの優先度をビューより高く設定しているため、インストールを 2 日目のクリックに関連付けます。2 日目のクリックは、優先度が最も高い最新の広告イベントです。

アトリビューション レポートで測定データを表示する

Attribution Reporting API では、次の種類のレポートが可能です。詳細についてはこのドキュメント内で別途説明します。

  • イベントレベル レポートは、特定のアトリビューション ソース(クリックまたはビュー)を、限られたビットの忠実度の高いトリガーデータに関連付けます。
  • 集計可能レポートは、必ずしも特定のアトリビューション ソースに関連付けられるわけではありません。イベントレベル レポートよりも豊富な、忠実度の高いトリガーデータが提供されますが、このデータは集計形式でしか利用できません。

これら 2 種類のレポートは相互に補完し合うものであり、同時に使用できます。

イベントレベル レポート

トリガーがアトリビューション ソースに帰属するとイベントレベル レポートが生成され、いずれかのレポート送信期間の間に各広告テクノロジー プラットフォームのポストバック URL に送信できるようになるまで、デバイスに保存されます。詳細についてはこのドキュメント内で別途説明します。

イベントレベル レポートは、トリガーについて情報がほとんど必要ない場合に便利です。イベントレベルのトリガーデータは、クリックについては 3 ビットに制限され(つまり、トリガーが 8 つのカテゴリのいずれかに割り当てられます)、ビューについては 1 ビットに制限されます。また、イベントレベル レポートでは、特定の価格やトリガー時間など、忠実度の高いトリガー側データのエンコードはサポートされていません。アトリビューションはデバイスで行われるため、イベントレベルのレポートではクロスデバイス分析がサポートされません。

イベントレベル レポートには次のようなデータが含まれます。

  • デスティネーション: トリガーが発生する広告主アプリのパッケージ名または eTLD+1
  • アトリビューション ソース ID: アトリビューション ソースの登録に使用したものと同じアトリビューション ソース ID
  • トリガータイプ: アトリビューション ソースのタイプに応じた、1 ビットまたは 3 ビットの低忠実度トリガーデータ

すべてのレポートに適用されるプライバシー保護メカニズム

アトリビューション ソースあたりの広告テクノロジー プラットフォームの数の制限

1 つのアトリビューション ソースに関連付けることのできる広告テクノロジー プラットフォームの数には制限があり、現在の提案では次のようになっています。

  • {ソースアプリ、デスティネーション アプリ、30 日} ごとに、アトリビューション ソースがある広告テクノロジー プラットフォームが 100 個。
  • {ソースアプリ、デスティネーション アプリ、30 日} ごとに、関連付けられたトリガーがある広告テクノロジー プラットフォームが 10 個。

こうした制限は、アトリビューション ソースとトリガーに関する優先度を考慮して適用されます。

クールダウンとレート制限

(ソース、デスティネーション)ペア間のユーザー ID の漏洩量を制限するために、API は各ユーザーに関して一定の期間に送信される総情報量のスロットリングを行います。

現在の提案では、各広告テクノロジー プラットフォームが関連付けるトリガーが {ソースアプリ、デスティネーション アプリ、30 日} あたり 100 個に制限されています。

一意のデスティネーションの数

この API では、広告テクノロジー プラットフォームで測定可能なデスティネーションの数が制限されます。上限を低く設定するほど、広告テクノロジー プラットフォームがこの API を使用して、表示されている広告に関連付けられていないユーザーの閲覧アクティビティを測定することが困難になります。

現在の提案では、各広告テクノロジー プラットフォームで、ソースごとに 100 個の別々のデスティネーションに制限されています。

イベントレベル レポートに適用されるプライバシー保護メカニズム

トリガーデータの忠実度の制限

API は、ビュースルー トリガーに 1 ビット、クリックスルー トリガーに 3 ビットを提供します。アトリビューション ソースは、引き続き 64 ビットのメタデータを完全にサポートします。

イベントレベル レポートで利用可能な限られたビット数で機能するように、トリガーで表現される情報を減らすかどうかを検討する必要があります。減らす場合の方法についても評価する必要があります。

差分プライバシー ノイズのフレームワーク

この API の目標は、k ランダム化レスポンスを使用して各ソースイベントに対しノイズのある出力を生成することで、イベントレベルの測定がローカルの差分プライバシー要件を満たすようにすることです。

ノイズの適用は、アトリビューション ソース イベントが正しくレポートされるかどうかに応じて行われます。アトリビューション ソースがデバイスに登録される際には、アトリビューション ソースが通常どおりに登録される確率 $ p $ と、可能性のあるすべての API 出力状態(一切レポートが行われない場合や、複数の偽のレポートを行われる場合を含む)の中からデバイスがランダムに選択する確率 $ 1-p $ がもちいられます。

k ランダム化レスポンスは、次の式が成立する場合に、イプシロン差分プライバシーを満たすアルゴリズムです。

\[ p = \frac{k}{k + e^ε - 1} \]

ε の値が低い場合、真の出力は k ランダム化レスポンス メカニズムによって保護されます。正確なノイズ パラメータは現在開発中であり、フィードバックに基づいて変更される可能性があります。

利用可能なトリガー(コンバージョン)の制限

アトリビューション ソースごとのトリガーの数には制限があり、現在の提案では次のようになっています。

  • 広告ビューのアトリビューション ソース: トリガー 1~2 個
  • 広告クリックのアトリビューション ソース: トリガー 3 個

こうした制限は、アトリビューション ソースとトリガーに関する優先度を考慮して適用されます。

特定のレポート送信期間

広告ビューのアトリビューション ソースのレポートは、ソースの期限が切れた 1 時間後に送信されます。この期限は設定できますが、2 日未満または 30 日を超える長さにすることはできません。

広告クリックのアトリビューション ソースのレポートは設定できません。ソースの期限が切れる前に、ソースの登録時点を基準とした特定の時点で送信されます。アトリビューション ソースから期限までの時間は、複数のレポート期間に分割されます。各レポート期間に(アトリビューション ソースの時間からの)期限があります。各レポート期間の最後に、デバイスは前回のレポート期間以降に発生したすべてのトリガーを収集し、スケジュール設定したレポートを送信します。この API は、次のレポート期間をサポートしています。

  • 2 日間: デバイスは、アトリビューション ソースの登録から 2 日後までに発生したトリガーをすべて収集します。レポートは、アトリビューション ソースの登録から 2 日と 1 時間後に送信されます。
  • 7 日間: デバイスは、アトリビューション ソースの登録から 2 日を超え、かつ 7 日以内に発生したトリガーをすべて収集します。レポートは、アトリビューション ソースの登録から 7 日と 1 時間後に送信されます。
  • カスタム期間: アトリビューション ソースの「expiry」属性で定義します。レポートは、指定した期限の 1 時間後に送信されます。この値は、2 日未満または 30 日を超える長さにすることはできません。

集計可能レポート

集計可能レポートは、イベントレベル レポートより忠実度の高いトリガーデータを、より迅速にデバイスから提供します。忠実度の高いデータは集計でしか学習できず、特定のトリガーまたはユーザーと関連付けられることはありません。集計キーは最大 128 ビットであり、集計可能レポートは次のようなレポートのユースケースをサポートできます。

  • 収益などのトリガー値のレポート
  • より多くのトリガータイプの処理

また、集約可能レポートはイベントレベル レポートと同じソース優先アトリビューション ロジックを使用しますが、クリックまたはビューに帰属する、より多くのコンバージョンをサポートします。

Attribution Reporting API で集計可能レポートを準備して送信する方法の全体的な設計を、図 2 に示します。

  1. デバイスが、暗号化された集計可能レポートを広告テクノロジー プラットフォームに送信します。本番環境では、広告テクノロジー プラットフォームがこれらのレポートを直接使用することはできません。
  2. 広告テクノロジー プラットフォームが、集計可能レポートのバッチを集計サービスに送信します。
  3. 集計サービスが、集計可能レポートのバッチを読み取り、復号して集計します。
  4. 最終的な集計結果がサマリー レポートで広告テクノロジー プラットフォームに返されます。
図 2. Attribution Reporting API が集計可能レポートを準備し送信する際のプロセス。

集計可能レポートには、アトリビューション ソースに関連する次のデータが含まれます。

  • ソース: 広告が配信されたアプリのパッケージ名または eTLD+1 ウェブ URL。
  • デスティネーション: トリガーが発生したアプリのパッケージ名または eTLD+1 ウェブ URL。
  • 日付: アトリビューション ソースで表されるイベントが発生した日付。
  • ペイロード: 暗号化された Key-Value ペアとして収集されるトリガー値。信頼できる集計サービスで集計の計算に使用されます。

集計サービス

次のサービスは集計機能を提供し、集計データに対する不適切なアクセスから保護します。

これらのサービスは異なる当事者によって管理されています。詳細についてはこのドキュメント内別途説明します。

  • 集計サービスは、広告テクノロジー プラットフォームでデプロイが想定される唯一のサービスです。
  • 鍵管理サービスとプライバシー バジェット サービスは、検証者という信頼できる当事者によって実行されます。検証者は、集計サービスを実行するコードが Google によって提供された一般公開のコードであることと、すべての集計サービス ユーザーに同じ鍵とバジェット サービスが適用されていることを証明します。
集計サービス

広告テクノロジー プラットフォームでは、Google によって提供されたバイナリに基づく集計サービスを事前にデプロイしておく必要があります。

この集計サービスは、クラウドでホストされた高信頼実行環境(TEE)で動作します。TEE には、次のようなセキュリティ上のメリットがあります。

  • TEE で動作するコードが、Google によって提供された特定のバイナリであることが保証されます。この条件が満たされない限り、集計サービスはオペレーションに必要な復号鍵にアクセスできません。
  • 実行中のプロセスにセキュリティを提供し、外部の監視や改ざんから隔離します。

こうしたセキュリティ上のメリットにより、集計サービスは、暗号化されたデータへのアクセスなどの機密性の高いオペレーションを安全に実施できるようになります。

集計サービスの設計、ワークフロー、セキュリティ上の考慮事項の詳細については、GitHub の集計サービスのドキュメントをご覧ください。

鍵管理サービス

このサービスは、集計サービスが承認済みのバージョンのバイナリを実行していることを確認してから、広告テクノロジー プラットフォームの集計サービスとトリガーデータの正しい復号鍵を提供します。

プライバシー バジェット サービス

このサービスは、広告テクノロジー プラットフォームの集計サービスが特定のトリガー(複数の集計キーを含む場合があります)にアクセスする頻度を追跡し、アクセス時の復号回数を適切な範囲に制限します。1 つのトリガーにつき 1 回の復号が許可されます。

Aggregatable Reports API

集計可能レポートへの投稿を用意するための API は、イベントレベル レポートにアトリビューション ソースを登録するときと同じベース API を使用します。以降のセクションでは、API の拡張機能について説明します。

集計可能ソースデータを登録する

API がアトリビューション ソース URI にリクエストを行うと、広告テクノロジー プラットフォームは、リスト内の各集計キーについて次のフィールドを持つ新しい HTTP ヘッダー histogram_contributions で応答することにより、Attribution-Reporting-Register-Aggregate-Source という集計キーのリストを登録できます。

  • ソースイベント ID: キーの名前用文字列。結合キーとして使用され、トリガー側のキーと組み合わせて最終的なキーを形成します。
  • キーピース: キーのビット文字列値。

最終的なヒストグラム バケット キーは、これらのピースとトリガー側ピースにバイナリ OR 演算を実行することにより、トリガー時に完全に定義されます。

最終的なキーは最大 128 ビットに制限されます。それより長いキーは切り捨てられます。つまり、JSON 内の 16 進文字列は、32 桁以下に制限されます。

次の例では、広告テクノロジー プラットフォームが API を使用して以下を収集しています。

  • キャンペーン レベルでのコンバージョン数の集計
  • 地域レベルでの購入額の集計
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech platform registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Aggregatable-Source:
[{
// Generates a "0x159" key piece named (low order bits of the key) for the key
// named "campaignCounts".
  "id": "campaignCounts",
// User saw an ad from campaign 345 (out of 511).
  "key_piece": "0x159",
},
{
// Generates a "0x5" key piece (low order bits of the key) for the key named "geoValue"
  "id": "geoValue",
// Source-side geo region = 5 (US), out of a possible ~100 regions.
  "key_piece": "0x5",
}]

集計可能トリガーを登録する

トリガーの登録では、ヘッダーがさらに 2 つ追加されます。

1 つ目のヘッダーは、トリガー側の集計キーのリストを登録するために使用されます。広告テクノロジー プラットフォームは、リスト内の各集計キーについて次のフィールドを持つ HTTP ヘッダー Attribution-Reporting-Register-Aggregatable-Trigger-Data で応答する必要があります。

  • キーピース: キーのビット文字列値。
  • ソースキー: 最終的なキーを形成するために、トリガーキーを組み合わせる必要があるアトリビューション ソース側のキーの名前を含んだ文字列のリスト。

2 つ目のヘッダーは、各キーに寄与する値のリストを登録するために使用されます。広告テクノロジー プラットフォームは HTTP ヘッダー Attribution-Reporting-Register-Aggregatable-Values で応答する必要があります。

2 つ目のヘッダーは、各キーに寄与する値のリストを登録するために使用されます。これは $ [1, 2^{16}] $ の範囲の整数です。広告テクノロジー プラットフォームは HTTP ヘッダー Attribution-Reporting-Register-Aggregatable-Values で応答する必要があります。

各トリガーは、集計可能レポートに複数のコントリビューションを設定できます。任意のソースイベントへのコントリビューションの総量は、$ L1 $ パラメータによって制約されます。これは、任意のソースのすべての集計キーにわたるコントリビューション(値)を合計したものの最大値です。$ L1 $ は、L1 感度、すなわちソースイベントあたりのヒストグラム コントリビューションのノルムを表します。この制限を超えると、以降のコントリビューションは通知なしに破棄されます。最初の提案では、$ L1 $ が $ 2^{16} $ (65536) に設定されます。

集計サービスのノイズは、このパラメータに比例して調整されます。そのため、特定の集計キーについてレポートされる値は、割り当てられた $ L1 $ のバジェット部分に基づいて適切に調整することをおすすめします。このアプローチでは、ノイズが適用されたときに、集計レポートの忠実度を最も高く保てます。このメカニズムは柔軟性が高く、多くの集計戦略をサポートできます。

次の例では、$ L1 $ の寄与分をそれぞれに分割することで、プライバシー バジェットが campaignCountsgeoValue の間で均等に分割されます。

// This is where the Attribution-Reporting-Register-Event-Trigger object appears
// when an ad tech platform registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Aggregatable-Trigger-Data:
[
  // Each dictionary independently adds pieces to multiple source keys.
  {
  // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
  // A 9-bit offset is needed because there are 511 possible campaigns, which
  // will take up 9 bits in the resulting key.
    "key_piece": "0x400",// Conversion type purchase = 2
    // Apply this key piece to:
    "source_keys": ["campaignCounts"]
  },
  {
  // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
  // A 7-bit offset is needed because there are ~100 regions for the geo key,
  // which will take up 7 bits of space in the resulting key.
  "key_piece": "0xA80",
  // Apply this key piece to:
  "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
  }
]

// Specify an amount of an abstract value which can be integers in [1, 2^16] to
// contribute to each key that is attached to aggregation keys in the order that
// they're generated.
Attribution-Reporting-Register-Aggregatable-Values:
[
  {
  // Privacy budget for each key is L1 / 2 = 2^15 (32768).
  // Conversion count was 1.
  // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
     "campaignCounts": 32768,

  // Purchase price was $52.
  // Purchase values for the app range from $1 to $1,024 (integers only).
  // Scaling factor applied is 32768 / 1024 = 32.
  // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
    "geoValue": 1664
  }
]

上記の例では、次のヒストグラム コントリビューションが生成されます。

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

正しい値(適用されるモジュロノイズ)が得られるように、スケーリング ファクタを反転できます。

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

差分プライバシー

この API の目標は、差分プライバシーを満たす集計結果の測定をサポートできるフレームワークを用意することです。これは、次のような分布のノイズを選ぶなどして、$ L1 $ のバジェットに比例するノイズを追加することで実現できます

\[ Laplace(\frac{ε}{L1}) \]

登録優先度、アトリビューション、レポートの例

この例では、一連のユーザー インタラクションのほか、広告テクノロジーでアトリビューション ソースとトリガーの優先度がアトリビューション レポートにどのように影響するかを説明します。この例では、次のことを仮定します。

  • アトリビューション ソースとトリガーはすべて、同じ広告主の同じ広告テクノロジー プラットフォームによって登録されます。
  • アトリビューション ソースとトリガーはすべて、最初のイベント レポート期間(広告がパブリッシャー アプリに最初に表示されてから 2 日以内)に発生します。

ユーザーが次を行う場合を考えます。

  1. ユーザーに広告が表示されます。広告テクノロジーが優先度 0 のアトリビューション ソースを API で登録します(ビュー #1)。
  2. 優先度 0 で登録された広告がユーザーに表示されます(ビュー #2)。
  3. ユーザーが優先度 1 で登録された広告をクリックします(クリック #1)。
  4. 広告主のアプリでユーザーによるコンバージョン(ランディング ページへのアクセス)が発生します。広告テクノロジー プラットフォームが優先度 0 のトリガーを API で登録します(コンバージョン #1)。
    • トリガーが登録されるため、レポートを生成する前に、まず API でアトリビューションが行われます。
    • 使用可能なアトリビューション ソースは、ビュー #1、ビュー #2、クリック #1 の 3 つです。このトリガーは、優先度が最も高く、最新のものであるため、API がクリック #1 に関連付けます。
    • ビュー #1 とビュー #2 は破棄され、今後のアトリビューションの対象ではなくなります。
  5. ユーザーが広告主のアプリで商品をカートに追加し、優先度 1 で登録されます(コンバージョン #2)。
    • 対象となるアトリビューション ソースは、クリック #1 のみです。API は、このトリガーをクリック #1 に関連付けます。
  6. ユーザーが広告主のアプリで商品をカートに追加し、優先度 1 で登録されます(コンバージョン #3)。
    • 対象となるアトリビューション ソースは、クリック #1 のみです。API は、このトリガーをクリック #1 に関連付けます。
  7. ユーザーが広告主のアプリで商品をカートに追加し、優先度 1 で登録されます(コンバージョン #4)。
    • 対象となるアトリビューション ソースは、クリック #1 のみです。API は、このトリガーをクリック #1 に関連付けます。
  8. ユーザーが広告主アプリで購入を行い、優先度 2 で登録されます(コンバージョン #5)。
    • 対象となるアトリビューション ソースは、クリック #1 のみです。API は、このトリガーをクリック #1 に関連付けます。

イベントレベル レポートには次のような特性があります。

  • デフォルトで、クリックに関連付けられた最初の 3 つのトリガーと、ビューに関連付けられた最初のトリガーが、該当するレポート期間の後で送信されます。
  • レポート期間により高い優先度で登録されたトリガーがある場合は、それらが優先され、最新のトリガーを置き換えます。
  • 上記の例では、広告テクノロジーは、2 日間のレポート期間の後で、コンバージョン #2、コンバージョン #3、コンバージョン #5 に関する 3 つのイベント レポートを受け取ります。
    • これら 5 つのトリガーはすべて、クリック #1 に関連付けられます。API はデフォルトで、最初の 3 つのトリガー(コンバージョン #1、コンバージョン #2、コンバージョン #3)に関するレポートを送信します。
    • ただし、コンバージョン #4 の優先度(1)はコンバージョン #1 の優先度(0)より高くなっています。コンバージョン #4 のイベント レポートは、コンバージョン #1 のイベント レポートを置き換え、送信候補となります。
    • また、コンバージョン #5 の優先度(2)は他のトリガーよりも高くなっています。コンバージョン #5 のイベント レポートがコンバージョン #4 のレポートを置き換え、送信候補となります。

集約可能レポートには次のような特性があります。

  • 暗号化された集計可能レポートは、処理後すぐ(トリガーの登録から数時間後)に広告テクノロジーに送信されます。

    広告テクノロジー プラットフォームである場合は、集約可能レポートに暗号化されない状態で届く情報に基づいてバッチを作成します。この情報は、集約可能レポートの shared_info フィールドに含まれ、タイムスタンプとレポート送信元を含んでいます。集約 Key-Value ペアの中の暗号化された情報に基づいてバッチ処理することはできません。簡単な戦略としては、レポートを毎日または毎週バッチ処理する方法があります。理想的には、バッチには少なくとも 100 レポートを含める必要があります。

  • 集約可能レポートをバッチ処理して集計サービスに送信するタイミングと方法は、広告テクノロジーで判断します。

  • イベントレベル レポートと比較すると、暗号化された集約可能レポートでは、より多くのトリガーをソースに関連付けることができます。

  • 上記の例では、登録されたトリガーごとに 1 つずつ、合計 5 つのレポートが送信されます。

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

Attribution Reporting API は現在開発中です。また、ラストクリック アトリビューション以外のモデルやクロスデバイス測定のユースケースなど、将来的な機能についても検討しています。

いくつかの問題点について、コミュニティからのフィードバックもお待ちしております。

  1. 複数の広告テクノロジー プラットフォームでアトリビューション ソースとトリガーを登録できるようにし、サードパーティによる測定を可能にする予定です。現在の提案では、API 呼び出しを行う広告テクノロジー プラットフォームのみがサードパーティの広告テクノロジー プラットフォームのリストを指定できます。API の設計を簡素化するため、その次の広告テクノロジー プラットフォームのみを指定することで広告テクノロジー プラットフォームにデイジー チェーン リダイレクトを許可することもできます。
  2. 同じトリガーのイベントレベル レポートと集約可能レポートが重複しないように、広告テクノロジー プラットフォームが同じトリガーを複数回登録する場合は、重複除去キーを使用することをおすすめします。これは、広告テクノロジー プラットフォームがトリガーを登録するための API 呼び出しを開始し、同じトリガーを登録する別の広告テクノロジー プラットフォームのリダイレクト パスに含まれている場合に発生する可能性があります。アプリは、この重複除去キーを使用しているすべての広告テクノロジー プラットフォームに渡すか、それらの広告テクノロジー プラットフォームでコンバージョンの種類の用語に合わせる必要があります。これは実現可能でしょうか。
  3. アトリビューション ソースの登録については、セルフ アトリビューション ネットワークを含め、サードパーティとリダイレクトの設計案が実現可能かどうかについて評価中です。特に、リダイレクト パス内の全員を確認する透明性は必要でしょうか。
  4. アトリビューション ソースを登録する際、広告テクノロジー プラットフォームはアプリのデスティネーションを 1 つだけ指定できます。お客様のユースケースで機能するでしょうか。
  5. アトリビューション ソースを登録する際、有効期限を設定できます(これはルックバック ウィンドウに相当します)。指定できる最小有効期間は、アトリビューション ソースが発生してから 2 日間です。このワークフローが破綻するユースケースがあるでしょうか。
  6. 検証済みインストールのレポートを API で送信するようなユースケースはあるでしょうか。そうしたレポートは、広告テクノロジー プラットフォームのレート制限にカウントされます。