このページは Cloud Translation API によって翻訳されました。

関連性の高いアプリインストール広告をサポートする Protected App Signals

この提案には、プライバシーサンドボックスの登録プロセスと証明書が適用されます。証明書の詳細については、提供される証明書のリンクをご覧ください。この提案の今後の更新で、このシステムへのアクセス権を取得するための要件を説明します。

モバイルアプリインストール広告（ユーザー獲得広告とも呼ばれます）は、モバイル広告の一種で、ユーザーにモバイルアプリのダウンロードを促します。通常、これらの広告はユーザーの興味や属性に基づいて配信され、ゲーム、ソーシャルメディア、ニュースアプリなどの他のモバイルアプリによく表示されます。ユーザーがアプリインストール広告をクリックすると、アプリストアに直接移動し、アプリをダウンロードできます。

たとえば、米国で新しいモバイルフードデリバリーアプリの新規インストールを促進しようとしている広告主は、以前に他のフードデリバリーアプリを利用したことのある米国在住のユーザーを広告のターゲットとします。

これは通常、広告テクノロジー間にコンテキストシグナル、ファーストパーティシグナル、サードパーティシグナルを組み込んで、広告 ID に基づいてユーザープロファイルを作成することで実装されます。広告テクノロジーの機械学習モデルは、この情報を入力として使用し、ユーザーとの関連性が高く、コンバージョンにつながる可能性が最も高い広告を選択します。

クロスパーティのユーザー ID への依存をなくすことでユーザーのプライバシーを向上させる効果的なアプリインストール広告をサポートするために、次の API が提案されています。

Protected App Signals API: ユーザーの潜在的関心を表す、広告テクノロジーによりエンジニアリングされた特徴量の保存と作成に重点を置いています。広告テクノロジーは、アプリのインストール、初回起動、ユーザーアクション（ゲーム内のレベリング、実績）、購入アクティビティ、アプリでの時間など、自己定義のアプリごとのイベントシグナルを保存します。シグナルは、データ漏洩を防ぐためにデバイスに書き込まれ、保存されます。シグナルは、安全な環境で実行されている保護オークション中に特定のシグナルを保存した広告テクノロジーロジックでのみ使用できます。
Ad Selection API: Trusted Execution Environment（TEE）で実行する Protected オークションを設定して実行するための API を提供します。広告テクノロジーは、Protected App シグナルとパブリッシャーが提供するリアルタイムのコンテキスト情報の両方を使用して、広告候補の取得、推論の実行、入札単価の計算、「落札」広告を選択するためのスコアリングを行います。

保護されたシグナルを使用したアプリのインストールフローを示す図 — Android 版プライバシーサンドボックスにおける保護されたアプリシグナルと広告選択のワークフローを示すフローチャート。

ここでは、Protected App Signals が関連するアプリインストール広告をサポートする仕組みの概要を説明します。以降のセクションでは、これらの各ステップについて詳しく説明します。

シグナルのキュレーション: ユーザーがモバイルアプリを使用すると、広告テクノロジーが広告テクノロジーで定義されたアプリイベントを保存し、Protected App Signals API を使用して関連広告を配信できるようにシグナルをキュレートします。これらのイベントは、カスタムオーディエンスと同様に、保護されたデバイス上のストレージに保存され、デバイスに送信される前に暗号化されます。適切なセキュリティ管理とプライバシー管理を備えた信頼できる実行環境内で実行される入札とオークションサービスのみが、入札とスコアリング用に広告を復号できます。
シグナルのエンコード: カスタム広告テクノロジーロジックによって、スケジュールされた頻度でシグナルが準備されます。Android バックグラウンドジョブがこのロジックを実行してオンデバイスでエンコードを行い、保護されたアプリシグナルのペイロードを生成します。このペイロードは、後で Protected オークション中の広告選択にリアルタイムで使用されます。ペイロードは、オークションに送信されるまでデバイスに安全に保存されます。
広告選択: ユーザーにとって関連性の高い広告を選択するために、販売者 SDK は、保護されたアプリシグナルの暗号化されたペイロードを送信し、保護されたオークションを構成します。オークションでは、購入者のカスタムロジックが、パブリッシャー提供のコンテキストデータ（通常は Open-RTB 広告リクエストで共有されるデータ）とともに Protected App シグナルを準備し、広告選択（広告の取得、推論、入札生成）向けの機能を設計します。Protected Audience と同様に、購入者は Protected オークションで最終的なスコアを販売者に広告を送信します。
- 広告の取得: 購入者は、保護されたアプリシグナルとパブリッシャー提供のコンテキストデータを使用して、ユーザーの興味 / 関心に合った機能を構築します。これらの機能は、ターゲティング条件に一致する広告をマッチングするために使用されます。予算内に収まらない広告は除外されます。上位 k 個の広告が入札用に選択されます。
- 入札: 購入者のカスタム入札ロジックが、パブリッシャー提供のコンテキストデータと Protected App Signals を準備し、特徴量のエンジニアリングを行います。特徴量は、信頼できるプライバシー保護境界内で広告候補を推論し、入札するための購入者の機械学習モデルへの入力として使用されます。次に、購入者は、選択した広告を販売者に返します。
- 販売者のスコア: 販売者のカスタムスコアリングロジックで、参加している購入者が送信した広告をスコアリングし、落札広告を選択してレンダリングします。
レポート: オークションの参加者は、該当する落札レポートと落札失敗レポートを受け取ります。Google では、落札レポートにモデルトレーニングのデータを含めるためのプライバシー保護メカニズムを検討しています。

タイムライン

	デベロッパープレビュー			ベータ版
特徴	2023 Q4	2024 Q1	2024 Q2	2024 Q3
Signal Curation API	デバイス上のストレージの API	デバイス上の保存容量ロジックデバイス上のカスタムロジックの日次更新	なし	T 以降のデバイスの 1% が対象
TEE 内の広告取得サーバー	MVP	GCP で利用可能 Top-K のサポート UDF の本番環境への移行	AWS で利用可能同意を得たデバッグ、指標、モニタリング
TEE の推論サービス TEE での ML モデルの実行および入札での使用をサポート	開発中	GCP で利用可能 Tensorflow と PyTorch を使用した静的 ML モデルのデプロイとプロトタイプ作成が可能	AWS で利用可能本番稼働モデルのデプロイ（Tensorflow と PyTorch のモデル向け）テレメトリー、同意を得たデバッグ、モニタリング
TEE での入札とオークションのサポート	GCP で利用可能	PAS-B&A と TEE 広告検索の統合（gRPC と TEE<>TEE 暗号化を使用）コンテキストパスによる広告取得のサポート（TEE での B&A<>K/V のサポートを含む）	AWS で利用可能デバッグレポート同意を得たデバッグ、指標、モニタリング

Protected App Signals をキュレートする

シグナルは、関連する広告の配信に有用であると広告テクノロジーによって判断される、アプリでのさまざまなユーザーインタラクションを表します。アプリまたは統合 SDK は、ユーザーのアクティビティ（アプリの起動、実績、購入アクティビティ、アプリ内時間など）に基づいて広告テクノロジーで定義された保護アプリシグナルを保存または削除できます。保護されたアプリシグナルは、デバイス上で安全に保存され、デバイスから送信される前に暗号化されます。適切なセキュリティとプライバシー管理を備えた信頼できる実行環境内で実行されている入札とオークションサービスのみが、入札とプライバシー管理のために復号できます。Custom Audience API と同様に、デバイスに保存されているシグナルをアプリや SDK が読み取ったり検査したりすることはできません。シグナル値を読み取るための API はなく、API はシグナルの存在が漏洩することを回避するように設計されています。広告テクノロジーのカスタムロジックは、Protected Auction の広告の選択のベースとなる特徴量をエンジニアリングするために、キュレートされたシグナルに保護されたアクセスを行えます。

Protected App Signals API

Protected App Signals API は、カスタムオーディエンスに使用されるのと同様の委任メカニズムを使用したシグナルの管理をサポートしています。Protected App Signals API を使用すると、単一のスカラー値または時系列の形式でシグナルを保存できます。時系列シグナルは、ユーザーセッション継続時間などを保存するために使用できます。時系列シグナルを使用すると、先入れ先出しのエビクションルールを使用して特定の長さを強制できます。スカラーシグナルのデータ型、または時系列シグナルの各要素は、バイト配列です。各値は、シグナルを保存したアプリのパッケージ名と、ストアシグナルの API 呼び出しの作成タイムスタンプで強化できます。この追加情報には、シグナルエンコード JavaScript を使用できます。次の例は、特定の広告テクノロジーが所有するシグナルの構造を示しています。

次の例は、adtech1.com に関連付けられたスカラーシグナルと時系列シグナルを示しています。

Base64 値のキー「A1c」と値「c12Z」のスカラーシグナル。2023 年 6 月 1 日に、com.google.android.game_app によってシグナルストアがトリガーされました。
2 つの異なるアプリによって作成された、キー「dDE」を持つシグナルのリスト。

広告テクノロジーには、デバイスにシグナルを保存するための一定のスペースが割り当てられます。シグナルには最大 TTL があります。この TTL は未定です。

生成されたアプリがアンインストールされた場合、Protected App Signals API の使用がブロックされた場合、またはアプリデータがユーザーによって消去された場合、Protected App Signals はストレージから削除されます。

Protected App Signals API は、次の要素で構成されています。

シグナルを追加、更新、削除する Java と JavaScript API。
JavaScript API。永続的なシグナルを処理して、信頼できる実行環境（TEE）で実行中の Protected オークション中に、リアルタイムでの特徴量エンジニアリングの準備を行います。

シグナルを追加、更新、削除する

広告テクノロジーは、fetchSignalUpdates() API を使用してシグナルを追加、更新、削除できます。この API は、Protected Audience のカスタムオーディエンスの委任と同様の委任をサポートしています。

アプリに SDK がない購入者の広告テクノロジーがシグナルを追加するには、モバイル測定パートナー（MMP）やサプライサイドプラットフォーム（SSP）などのデバイス上のプレゼンスがある広告テクノロジーと連携する必要があります。Protected App Signals API は、Protected App Signals の管理に柔軟なソリューションを提供することで、こうした広告テクノロジーをサポートすることを目的としています。この API は、デバイス上の呼び出し元が購入者に代わって Protected App Signals の作成を呼び出せるようにします。委任と呼ばれるこのプロセスは、fetchSignalUpdates() API を利用します。fetchSignalUpdates() は、URI を受け取ってシグナルの更新のリストを取得します。たとえば、fetchSignalUpdates() は指定された URI に GET リクエストを発行し、ローカルシグナルストレージに適用する更新のリストを取得します。購入者が所有する URL エンドポイントは、コマンドの JSON リストを返します。

サポートされている JSON コマンドは次のとおりです。

put: 指定されたキーのスカラー値を挿入またはオーバーライドします。
put_if_not_present: 値がまだ保存されていない場合に、指定されたキーにスカラー値を挿入します。このオプションは、たとえば特定のユーザーにテスト ID を設定し、すでに別のアプリケーションで設定されている場合に ID をオーバーライドしないようにする場合に便利です。
add: 指定されたキーに関連付けられた時系列に要素を追加します。maxSignals パラメータは、時系列のシグナルの最大数を指定します。サイズを超えると、古い要素が削除されます。キーにスカラー値が含まれている場合、キーは自動的に時系列に変換されます。
remove: 指定したキーに関連付けられているコンテンツを削除します。

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

すべてのキーと値は Base64 で表されます。

上記のコマンドは、スカラーシグナルのセマンティクスを挿入、上書き、削除し、時系列シグナルの挿入、追加、完全なシリーズの上書きを行うことを目的としています。時系列シグナルの特定の要素に対する削除と上書きのセマンティクスは、エンコードと圧縮の処理中に管理する必要があります。たとえば、エンコード中に、より新しいものによって置き換えまたは修正された時系列の値を無視し、それらを圧縮プロセス中に削除します。

保存されたシグナルは、フェッチリクエストを実行するアプリケーションと、リクエストのレスポンダ（登録された広告テクノロジーの「サイト」または「送信元」）、およびリクエストの作成時間に自動的に関連付けられます。すべてのシグナルは、プライバシーサンドボックスに登録済みの広告テクノロジーに代わって保存されます。URI「site」/「origin」は登録済みの広告テクノロジーのデータと一致する必要があります。リクエスト元の広告テクノロジーが登録されていない場合、リクエストは拒否されます。

保存容量の割り当てとエビクション

各広告テクノロジーには、シグナルを保存するためのユーザーデバイス上のスペースが限られています。この割り当ては広告テクノロジーごとに定義されるため、さまざまなアプリからキュレートされたシグナルが割り当てを共有します。割り当てを超えた場合、システムは先入れ先出しで古いシグナル値を削除することで空き容量を増やします。エビクションが頻繁に実行されないように、システムにはバッチ処理ロジックが実装されています。このロジックでは、割り当てから限定量の超過引き出しを許容して、エビクションロジックのトリガー時に追加のスペースを解放します。

データ送信用のオンデバイスエンコード

広告選択用のシグナルを準備するため、購入者ごとのカスタムロジックは、保存されたアプリごとのシグナルとイベントに保護されたアクセスを行えます。Android システムのバックグラウンドジョブは 1 時間ごとに実行され、デバイスにダウンロードされた購入者ごとのカスタムエンコードロジックを実行します。購入者ごとのカスタムエンコードロジックは、アプリごとの信号をエンコードし、購入者ごとの割り当てに準拠するペイロードにアプリごとの信号を圧縮します。ペイロードは、保護されたデバイスストレージの境界内で暗号化され、入札およびオークションサービスに送信されます。

広告テクノロジーは、独自のカスタムロジックによって処理されるシグナル処理のレベルを定義します。たとえば、ソリューションをインストルメント化して以前のシグナルを破棄し、異なるアプリケーションからの類似または強化シグナルを集約して、より少ないスペースを使用する新しいシグナルにできます。

購入者がシグナルエンコーダを登録していない場合、シグナルは準備されず、デバイス上でキュレートされたシグナルは入札およびオークションサービスに送信されません。

ストレージ、ペイロード、リクエストの割り当ての詳細については、今後のアップデートでお知らせします。また、カスタム関数を提供する方法についても詳しく説明します。

広告選択ワークフロー

このプロポーザルでは、広告テクノロジーのカスタムコードは、TEE で実行されている Protected Auction（Ad Selection API）内の Protected App Signals にのみアクセスできます。アプリインストールのユースケースのニーズをさらにサポートするため、Protected Auction で広告候補がリアルタイムでフェッチされます。これは、オークション前に候補広告を把握しているリマーケティングのユースケースとは対照的です。

このプロポーザルでは、Protected Audience のプロポーザルと同様の広告選択ワークフローが使用され、アプリインストールのユースケースに対応するための更新が行われています。特徴量エンジニアリングとリアルタイムの広告選択のコンピューティング要件をサポートするには、TEE で実行される入札サービスおよびオークションサービスでアプリインストール広告のオークションを実施する必要があります。Protected Auction 中の Protected App Signals へのアクセスは、デバイス上のオークションではサポートされていません。

広告選択ワークフローの説明図。 — Android 版プライバシーサンドボックスの広告選択ワークフロー

広告選択ワークフローは次のとおりです。

販売者の SDK が、Protected App Signals のデバイス上で暗号化されたペイロードを送信します。
販売者のサーバーがオークション構成を作成し、それを暗号化されたペイロードとともに販売者の信頼できる入札およびオークションサービスに送信し、広告選択ワークフローを開始します。
販売者の入札およびオークションサービスは、参加している信頼できる購入者のフロントエンドサーバーにペイロードを渡します。
購入者の入札サービスがバイサイド広告選択ロジックを実行します。
1. バイサイド広告取得ロジックの実行。
2. バイサイド入札ロジックの実行。
セルサイドスコアリングロジックが実行されます。
広告がレンダリングされ、レポートが開始されます。

広告選択ワークフローを開始する

アプリで広告を表示する準備が整うと、広告テクノロジー SDK（通常は SSP）は広告選択ワークフローを開始します。具体的には、パブリッシャーからの関連するコンテキストデータと、購入者ごとの暗号化されたペイロードを送信し、getAdSelectionData 呼び出しを使用して Protected オークションに送信するリクエストに追加します。これは、リマーケティングワークフローで使用される API と同じであり、Android 向けの入札とオークションの統合の提案で説明されているものと同じです。

広告選択を開始するために、販売者は参加している購入者のリストとデバイス上の Protected App Signals の暗号化されたペイロードを渡します。この情報を使用して、セルサイド広告サーバーは信頼できる SellerFrontEnd サービス用に SelectAdRequest を準備します。

販売者は以下を設定します。

getAdSelectionData から受信したペイロード。Protected App Signals が含まれます。
コンテキストシグナルには以下を使用:
- auction_config.auction_signals（オークションに関する情報）
- auction_config.seller_signals（販売者のシグナル用）
- auction_config.per_buyer_config["buyer"].buyer_signals（購入者のシグナルの場合）
buyer_list フィールドを使用してオークションに加えられた購入者のリスト。

バイサイド広告選択ロジックの実行

大まかに言うと、購入者のカスタムロジックは、パブリッシャーから提供されたコンテキストデータと Protected App Signals を使用して、広告リクエストに関連する広告を選択し、入札単価を適用します。このプラットフォームでは、購入者は多数の広告の選択肢の中から、最も関連性の高い広告（上位 k 件）に絞り込めます。それらの入札単価が計算されてから、最終的な選択のために広告が販売者に返されます。

バイサイド広告選択実行ロジックの説明図。 — Android 版プライバシーサンドボックスにおけるバイサイド広告選択の実行ロジック

入札前に、購入者は多数の広告の選択肢からスタートします。広告ごとに入札単価を計算するには時間がかかりすぎるため、購入者はまず多数の選択肢から上位 k 個の候補を選択する必要があります。次に、購入者は上位 k 個の候補ごとに入札単価を計算する必要があります。その後、最終的な選択のために、それらの広告と入札単価が販売者に返されます。

BuyerFrontEnd サービスが広告リクエストを受信します。
BuyerFrontEnd サービスが、購入者の入札サービスにリクエストを送信します。購入者の入札サービスが prepareDataForAdRetrieval() という UDF を実行します。これにより、広告取得サービスから上位 k 個の候補を取得するリクエストが作成されます。入札サービスは、構成された取得サーバーエンドポイントにこのリクエストを送信します。
広告取得サービスが getCandidateAds() UDF を実行します。これにより、上位 k 個の広告候補に絞り込まれ、購入者の入札サービスに送信されます。
購入者の入札サービスが generateBid() UDF を実行し、最適な候補を選択し、入札単価を計算して、BuyerFrontEnd サービスに返します。
BuyerFrontEnd サービスが、広告と入札単価を販売者に返します。

このフローにはいくつかの重要な詳細があります。特に、各部分が相互に通信する方法と、上位 k 個の広告を取得し、入札単価の計算を行うための機械学習予測能力などの機能がプラットフォームでどのように提供されるかに関してです。

詳細を説明する前に、上の図の TEE に関するアーキテクチャ上の重要な注意事項をいくつか示します。

購入者の入札サービスには、内部的に推論サービスが含まれています。広告テクノロジーは、購入者の入札サービスに機械学習モデルをアップロードできます。購入者の入札サービスで実行されている UDF 内から、広告テクノロジーが予測を行ったり、これらのモデルからエンベディングを生成したりするための JavaScript API が提供されます。広告取得サービスとは異なり、購入者の入札サービスには、広告メタデータを保存する Key-Value サービスがありません。

広告取得サービスには、内部に Key-Value サービスが含まれています。広告テクノロジーは、プライバシー境界の外側にある独自のサーバーから、このサービスに Key-Value ペアを実体化できます。広告取得サービスで実行されている UDF 内から、広告テクノロジーがこの Key-Value サービスを読み取るための JavaScript API が提供されます。購入者の入札サービスとは異なり、広告取得サービスには推論サービスは含まれません。

この設計で対処する重要な問題の一つは、取得時間と入札時間の予測をどのように行うかです。どちらについても、モデル分解と呼ばれるソリューションで解決できます。

モデル分解

モデル分解は、1 つのモデルを複数の部分に分割し、それらの部分を予測に組み合わせることができる手法です。アプリインストールのユースケースでは、多くの場合、モデルはユーザーデータ、コンテキストデータ、広告データの 3 種類のデータを利用します。

非分解の場合、1 つのモデルが 3 種類のデータすべてでトレーニングされます。分解の場合、モデルは複数の部分に分割され、ユーザーデータが含まれる部分のみが機密となります。つまり、購入者の入札サービスの推論サービスでは、信頼境界内で実行する必要があるのは、ユーザー部分を含むモデルだけです。

これにより、次のような設計が可能になります。

モデルを非公開な部分（ユーザーデータ）と 1 つ以上の非公開ではない部分（コンテキストと広告データ）に分割します。
必要に応じて、非公開ではない部分の一部またはすべてを、予測を行う必要がある UDF に引数として渡します。たとえば、コンテキストエンベディングは per_buyer_signals の UDF に渡されます。
必要に応じて、広告テクノロジーは非公開ではない部分のモデルを作成し、それらのモデルのエンベディングを広告取得サービスの Key-Value ストアに実体化できます。広告取得サービスの UDF は、実行時にこれらのエンベディングをフェッチできます。
UDF の実行中に予測を行うには、推論サービスからの非公開エンベディングを、UDF 関数の引数または Key-Value ストアの非公開ではないエンベディングと、ドット積などの演算で組み合わせます。これが最終的な予測です。

それを踏まえて、各 UDF を詳しく見ていきましょう。その機能、統合方法、上位 k 個の広告の選択と入札単価の計算に必要な予測方法について説明します。

`prepareDataForAdRetrieval()` UDF

購入者の入札サービスで実行される prepareDataForAdRetrieval() は、上位 k 個の広告候補をフェッチするために広告取得サービスに送信されるリクエストペイロードを作成します。

prepareDataForAdRetrieval() は次の情報を取得します。

getAdSelectionData から受信した購入者ごとのペイロード。このペイロードには、Protected App Signals が含まれています。
コンテキストシグナルの auction_signals（オークションに関する情報）と buyer_signals（購入者のシグナルフィールド）。

prepareDataForAdRetrieval() は次の 2 つの処理を行います。

特徴量化: 取得時間の推論が必要な場合、受信シグナルを特徴量に変換します。この特徴量は、推論サービスの呼び出し時に使用し、取得用のプライベートエンベディングを入手します。
取得用のプライベートエンベディングを計算する: 取得予測が必要な場合は、上記の機能を使用して推論サービスを呼び出し、取得時間予測用のプライベートエンベディングを取得します。

prepareDataForAdRetrieval() の戻り値:

Protected App Signals: 広告テクノロジーによってキュレートされたシグナルのペイロード。
オークション固有のシグナル: プラットフォーム固有のセルサイドシグナルと、SelectAdRequest からの auction_signals や per_buyer_signals（コンテキストエンベディングを含む）などのコンテキスト情報。これは、Protected Audience と同様です。
追加のシグナル: 推論サービスから取得した非公開エンベディングのような追加情報。

このリクエストは広告取得サービスに送信されます。広告取得サービスは候補のマッチングを行ってから、getCandidateAds() UDF を実行します。

`getCandidateAds()` UDF

getCandidateAds() は広告取得サービスで実行されます。購入者の入札サービスで prepareDataForAdRetrieval() によって作成されたリクエストを受け取ります。このサービスは getCandidateAds() を実行します。これは、リクエストを一連のクエリに変換し、データをフェッチし、カスタムビジネスロジックとその他のカスタム取得ロジックを実行することで、入札の上位 k 個の候補をフェッチします。

getCandidateAds() は次の情報を取得します。

Protected App Signals: 広告テクノロジーによってキュレートされたシグナルのペイロード。
オークション固有のシグナル: プラットフォーム固有のセルサイドシグナルと、SelectAdRequest からの auction_signals や per_buyer_signals（コンテキストエンベディングを含む）などのコンテキスト情報。これは、Protected Audience と同様です。
追加のシグナル: 推論サービスから取得した非公開エンベディングのような追加情報。

getCandidateAds() によって、次の処理が行われます。

広告候補の初期セットのフェッチ: 言語、地域、広告タイプ、広告サイズ、予算などのターゲティング条件を使用してフェッチし、広告候補をフィルタします。
取得用エンベディングのフェッチ: 上位 k 個の選択の取得時間を予測するために Key-Value サービスからのエンベディングが必要な場合は、Key-Value サービスから取得する必要があります。
上位 k 個の候補の選択: Key-Value ストアからフェッチした広告メタデータと、購入者の入札サービスから送信された情報に基づいて、フィルタされた広告候補セットの軽量スコアを計算します。そのスコアに基づいて上位 k 個の候補が選ばれます。スコアの例には、広告に表示されたアプリをインストールする確率があります。
入札エンベディングの取得: 入札時の予測を行うために、Key-Value サービスからのエンベディングが入札コードに必要な場合は、Key-Value サービスから取得できます。

広告のスコアは、たとえば、ユーザーがアプリをインストールする確率を予測する予測モデルの出力である場合があります。この種のスコア生成には、一種のモデル分解が含まれます。getCandidateAds() は広告取得サービスで実行されるため、また広告取得サービスには推論サービスがないため、予測は以下を組み合わせて生成されます。

オークション固有のシグナル入力を使用して渡されるコンテキストエンベディング。
追加のシグナル入力を使用して渡される非公開エンベディング。
非限定公開以外のエンベディング広告テクノロジーは、サーバーから広告取得サービスの Key-Value サービスに実体化されています。

なお、購入者の入札サービスで実行される generateBid() UDF は、独自のモデル分解を適用して入札の予測を行うこともできます。これを行うために Key-Value サービスからのエンベディングを必要とする場合は、この時点でフェッチする必要があります。

getCandidateAds() の戻り値:

広告候補: generateBid() に渡される上位 k 個の広告。各広告は以下で構成されます。
- レンダリング URL: 広告クリエイティブをレンダリングするためのエンドポイント。
- メタデータ: バイサイド広告テクノロジー固有の広告メタデータ。たとえば、広告キャンペーンに関する情報や、地域や言語などのターゲティング条件が含まれる場合があります。メタデータには、入札時に推論を行うためにモデル分解が必要な場合に使用される、オプションのエンベディングを含めることができます。
追加のシグナル: 広告取得サービスは、必要に応じて、generateBid() で使用する追加のエンベディングやスパムシグナルなどの追加情報を含めることができます。

Google では、SelectAdRequest 呼び出しの一部として提供するなど、スコアリング対象の広告を提供する他の方法を検討しています。これらの広告は、RTB 入札リクエストを使用して取得できます。そのような場合は、Protected App Signals を使用せずに広告を取得する必要があります。広告テクノロジーは、最適なオプションを選択する前に、レスポンスペイロードサイズ、レイテンシ、費用、シグナルの可用性などのトレードオフを評価することが予想されます。

`generateBid()` UDF

取得時に候補広告とエンベディングのセットを取得したら、購入者の入札サービスで実行される入札に進むことができます。このサービスは、購入者提供の generateBid() UDF を実行して、入札する広告を上位 k 個から選択し、その広告の入札単価を返します。

generateBid() は次の情報を取得します。

候補広告: 取得広告の取得サービスから返された上位 k 個の広告。
オークション固有のシグナル: プラットフォーム固有のセルサイドシグナルと、SelectAdRequest からの auction_signals や per_buyer_signals（コンテキストエンベディングを含む）などのコンテキスト情報。
その他のシグナル: 入札時に使用する追加情報。

購入者の generateBid() の実装では、次の 3 つの処理が行われます。

特徴化: 信号を、推論で使用するための特徴に変換します。
推論: 機械学習モデルを使用して予測を生成し、予測されるクリックスルー率やコンバージョン率などの値を計算します。
入札: 推定される値を他の入力と組み合わせて、広告候補の入札単価を計算します。

generateBid() の戻り値:

広告候補。
算出された入札単価。

アプリインストール広告で使用される generateBid() とリマーケティング広告で使用されるものは異なります。

以降のセクションでは、特徴量化、推論、入札について詳しく説明します。

特徴量化

オークションシグナルは、generateBid() で特徴量に準備できます。これらの機能は、推定時に使用して、クリック率やコンバージョン率などを予測できます。また、モデルトレーニングで使用するために、落札レポートでその一部を転送するためのプライバシー保護メカニズムも検討しています。

推論

入札単価を計算する際は、1 つ以上の機械学習モデルに対して推論を行うのが一般的です。たとえば、有効 eCPM の計算では多くの場合、モデルを使用してクリックスルー率やコンバージョン率を予測します。

クライアントは、generateBid() 実装とともに複数の機械学習モデルを提供できます。また、クライアントが実行時に推論を実行できるように、generateBid() 内で JavaScript API を提供します。

推論は購入者の入札サービスで実行されます。これは、特に TEE でアクセラレータがまだ利用できないため、推論のレイテンシとコストに影響する可能性があります。クライアントによっては、購入者の入札サービスで実行される個々のモデルでニーズが満たされる場合もあります。たとえば、非常に大規模なモデルを扱うクライアントなど、一部のクライアントは、入札時の推論コストとレイテンシを最小限に抑えるためにモデル分解などのオプションを検討する場合があります。

サポートされているモデル形式や最大サイズなどの推論機能の詳細については、今後のアップデートでお知らせします。

モデル分解を実装する

モデル分解の説明は上記をご覧ください。入札時の具体的なアプローチは次のとおりです。

単一のモデルを非公開部分（ユーザーデータ）と 1 つ以上の非公開ではない部分（コンテキストと広告データ）に分割します。
非公開ではない部分を generateBid() に渡します。これらは、per_buyer_signals から取得するか、広告テクノロジーが外部で計算し、取得サービスの Key-Value ストアに実体化し、取得時にフェッチし、追加シグナルの一部として返すエンベディングから取得することもできます。非公開エンベディングはプライバシー境界の外部から提供できないため、これには含まれません。
generateBid() で以下を実行します。
1. モデルに対して推論を行い、非公開のユーザーエンベディングを取得します。
2. ドット積などのオペレーションを使用して、非公開のユーザーエンベディングを、per_buyer_signals または非公開ではない広告からのコンテキストエンベディング、および取得サービスからのコンテキストエンベディングと組み合わせます。これは、入札単価の計算に使用できる最終的な予測です。

このアプローチを使用すると、通常は購入者の入札サービスで実行するには大きすぎるモデルや遅いモデルに対して、入札時に推論を実行できます。

セルサイドスコアリングロジック

この段階で、参加しているすべての購入者による入札を受けた広告のスコアリングが行われます。generateBid() の出力は販売者のオークションサービスに渡されて scoreAd() が実行されます。この scoreAd() では一度に 1 つの広告のみが考慮されます。販売者はスコアに基づいて落札広告を選択し、レンダリングのためにデバイスに返します。

スコアリングロジックは Protected Audience のリマーケティングフローで使用されたものと同じで、リマーケティングとアプリインストールの候補から落札者を選択できます。この関数は、Protected Auction で送信された広告候補ごとに 1 回呼び出されます。詳しくは、入札とオークションの説明をご覧ください。

広告選択コードランタイム

このプロポーザルでは、アプリインストールの広告選択コードは Protected Audience リマーケティングフローと同じ方法で指定されます。詳しくは、入札とオークションの設定をご覧ください。入札コードは、リマーケティングに使用するのと同じ Cloud Storage のロケーションで利用できます。

レポート

このプロポーザルでは、Protected Audience レポートの提案と同じレポート API（例: reportImpression() はプラットフォームに対して販売者と購入者のレポートの送信をトリガーします）を使用します。

バイサイドのレポートの一般的なユースケースの 1 つは、広告選択中に使用されるモデルのトレーニングデータを取得することです。既存の API に加えて、プラットフォームには、プラットフォームから広告テクノロジーサーバーにイベントレベルのデータを送信するための特別なメカニズムが用意されています。これらの下り（外向き）ペイロードには、特定のユーザーデータが含まれる場合があります。

長期的には、TEE で実行されているサービスの外部でイベントレベルのユーザーデータを送信せずに、保護されたオークションで使用されるデータによるモデルトレーニングに対処するためのプライバシー保護ソリューションを調査しています。詳細については、今後のアップデートで説明します。

短期的には、generateBid() からノイズのあるデータを出力する一時的な方法が提供されます。これに対する Google の最初の提案は以下のとおりです。Google では、業界からのフィードバックに応じて改良していきます（下位互換性のない変更が行われる可能性もあります）。

厳密に言えば、この仕組みは次のようになります。

広告テクノロジーは、送信するデータのスキーマを定義します。
generateBid() で、目的の下り（外向き）ペイロードを構築します。
プラットフォームは、スキーマに照らして下り（外向き）ペイロードを検証し、サイズの上限を適用します。
プラットフォームは、下り（外向き）ペイロードにノイズを追加します。
下り（外向き）ペイロードは配信形式で落札レポートに含まれ、広告テクノロジーサーバーで受信され、デコードされてモデルのトレーニングに使用されます。

下り（外向き）ペイロードのスキーマの定義

プラットフォームが進化するプライバシー要件を適用するには、プラットフォームが理解できるように下り（外向き）ペイロードを構造化する必要があります。広告テクノロジーは、スキーマ JSON ファイルを提供して下り（外向き）ペイロードの構造を定義します。このスキーマはプラットフォームによって処理され、UDF やモデルなどの他の広告テクノロジーリソースと同じメカニズムを使用して、入札サービスとオークションサービスによって機密情報として扱われます。

その JSON の構造を定義する CDDL ファイルを用意します。CDDL ファイルには、サポートされている一連の特徴タイプ（ブール値、整数、バケットなどの特徴）が含まれます。CDDL ファイルと指定されたスキーマの両方がバージョニングされます。

たとえば、単一のブール値特徴と、その後にサイズ 2 のバケット特徴で構成される下り（外向き）ペイロードは次のようになります。

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

サポートされている一連の機能タイプの詳細については、GitHub をご覧ください。

`generateBid()` に下り（外向き）ペイロードをビルドする

特定の購入者のすべての保護されたアプリシグナルを generateBid() UDF で使用できます。これらの機能が機能化されたら、広告テクノロジーは JSON 形式でペイロードを作成します。この下り（外向き）ペイロードは、広告テクノロジーサーバーへの送信のために購入者の落札レポートに含まれます。

この設計の代わりに、下り（外向き）ベクトルの計算を generateBid() ではなく reportWin() で行うこともできます。各アプローチにはトレードオフがあるため、業界のフィードバックに基づいてこの決定を最終決定します。

下り（外向き）ペイロードを検証する

プラットフォームは、広告テクノロジーによって作成された下り（外向き）ペイロードを検証します。検証では、特徴値がそのタイプに対して有効であること、サイズの制約を満たしていること、悪意のある行為者が下り（外向き）ペイロードに追加情報を詰めることでプライバシー管理を破ろうとしていないことを確認します。

下り（外向き）ペイロードが無効な場合、落札レポートに送信される入力から通知なく破棄されます。これは、検証を無効にしようとする不正な行為者にデバッグ情報を提供したくないためです。

広告テクノロジー向けに JavaScript API を用意し、generateBid() で作成した下り（外向き）ペイロードがプラットフォームの検証に合格するようにします。

validate(payload, schema)

この JavaScript API は、特定のペイロードがプラットフォームの検証に合格するかどうかを呼び出し元が判断するためのものです。悪意のある generateBid() UDF から保護するために、実際の検証はプラットフォームで行う必要があります。

下り（外向き）ペイロードをノイズとする

プラットフォームは、成約レポートに含める前に下り（外向き）ペイロードをノイズとして扱います。初期ノイズしきい値は 1% ですが、この値は時間の経過とともに変化する可能性があります。プラットフォームは、特定の下り（外向き）ペイロードにノイズが検知されたかどうかを表示しません。

ノイズ方式は次のとおりです。

プラットフォームが、下り（外向き）ペイロードのスキーマ定義を読み込みます。
下り（外向き）ペイロードの 1% がノイズ用に選択されます。
下り（外向き）ペイロードが選択されていない場合は、元の値全体が保持されます。
下り（外向き）ペイロードが選択されると、各特徴の値が、その機能タイプに対して有効なランダムな値に置き換えられます（たとえば、ブール値特徴の場合は 0 または 1）。

モデルトレーニング用の下り（外向き）ペイロードの送信、受信、デコード

検証済みのノイズを含む下り（外向き）ペイロードは、reportWin() の引数に含まれ、モデルトレーニングのプライバシー境界の外側にある購入者の広告テクノロジーサーバーに送信されます。下り（外向き）ペイロードは送信形式になります。

すべての機能タイプと下り（外向き）ペイロード自体の詳細については、GitHub をご覧ください。

下り（外向き）ペイロードのサイズを確認する

下り（外向き）ペイロードのサイズ（ビット単位）は、ユーティリティとデータの最小化のバランスを取ります。Google は業界と協力して、テストによって適切なサイズを決定します。テスト中は、一時的にビットサイズの制限なく下り（外向き）データが送信されます。ビットサイズの制限のない下り（外向き）データは、テストが完了すると削除されます。

サイズを決定する方法は、次のとおりです。

まず、generateBid() で 2 つの下り（外向き）ペイロードをサポートします。
1. egressPayload: このドキュメントでこれまでに説明したサイズ制限された下り（外向き）ペイロード。最初、この下り（外向き）ペイロードのサイズは 0 ビットです（つまり、検証中に常に削除されます）。
2. temporaryUnlimitedEgressPayload: サイズテスト向けの一時的なサイズ無制限の下り（外向き）ペイロード。この下り（外向き）ペイロードのフォーマット、作成、処理には、egressPayload と同じメカニズムが使用されます。
これらの下り（外向き）ペイロードには、それぞれ独自のスキーマ JSON ファイル（egress_payload_schema.json と temporary_egress_payload_schema.json）があります。
さまざまな下り（外向き）ペイロードサイズ（5、10、... ビットなど）でのモデルユーティリティを決定するためのテストプロトコルと一連の指標が用意されています。
テスト結果に基づき、ユーティリティとプライバシーの適切なトレードオフを考慮して下り（外向き）ペイロードサイズを決定しています。
egressPayload のサイズを 0 ビットから新しいサイズに設定します。
設定された移行期間が終了すると、temporaryUnlimitedEgressPayload が削除され、egressPayload のみが新しいサイズで残ります。

この変更を管理するための技術的なガードレールについても調査中です（たとえば、サイズを 0 ビットから増やすときに egressPayload を暗号化するなど）。これらの詳細情報（テストプロトコル、テストのタイミング、temporaryUnlimitedEgressPayload の削除のタイミングなどの追加情報とともに）は、今後のアップデートに含まれます。

データ保護対策

下り（外向き）データには、次のようなさまざまな保護が適用されます。

egressPayload と temporaryUnlimitedEgressPayload の両方でノイズが発生します。
データの最小化と保護のため、temporaryUnlimitedEgressPayload はサイズテストの期間にのみ使用できます。Google が egressPayload の適切なサイズを決定します。

権限

ユーザーコントロール

このプロポーザルの目的は、Protected App Signals またはカスタムオーディエンスを 1 つ以上保存しているインストール済みアプリのリストをユーザーが確認できるようにすることです。
ユーザーはこのリストからアプリをブロックしたり削除したりできます。ブロックと削除では、次の処理が行われます。
- アプリに関連付けられているすべての保護されたアプリシグナルとカスタムオーディエンスを消去します。
- アプリが新しい Protected App Signals とカスタムオーディエンスを保存しないようにします。
ユーザーは Protected App Signals と Protected Audience API を完全にリセットできます。この場合、デバイス上の既存の Protected App シグナルとカスタムオーディエンスはすべて消去されます。
ユーザーは、Android 版プライバシーサンドボックス（Protected App Signals API と Protected Audience API を含む）を完全にオプトアウトできます。この場合、Protected Audience API と Protected App Signals API は標準の例外メッセージ SECURITY_EXCEPTION を返します。

アプリの権限とコントロール

このプロポーザルは、アプリが Protected App Signals を管理できるようにすることを目的としています。

アプリは、Protected App Signals との関連付けを管理できます。
アプリは、サードパーティ広告テクノロジープラットフォームに、保護されたアプリのシグナルを管理する権限をアプリに代わって付与できます。

広告テクノロジープラットフォームによるコントロール

このプロポーザルでは、広告テクノロジーが Protected App Signals を制御する方法の概要を説明します。

すべての広告テクノロジーは、プライバシーサンドボックスに登録し、Protected App Signals のすべての URL と一致する「site」または「origin」ドメインを指定する必要があります。
広告テクノロジーはアプリまたは SDK と連携し、保護されたアプリシグナルの作成の検証に使用される確認トークンを提供できます。このプロセスがパートナーに委任された場合、Protected App Signals の作成は、広告テクノロジーによる承認を必要とするように構成できます。