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

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

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

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

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

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

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

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

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

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

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

タイムライン

	デベロッパープレビュー			ベータ版
機能	2023 Q4	2024 Q1	2024 Q2	2024 Q3
Signal Curation API	デバイス上のストレージの API	デバイス上の保存容量ロジックデバイス上のカスタムロジックの日次更新	なし	T 以降のデバイスの 1% が対象
TEE 内の広告取得サーバー	最小実装製品（MVP）	Google Cloud で利用可能 Top-K のサポート UDF の本番環境への移行	AWS で利用可能同意を得たデバッグ、指標、モニタリング
TEE の推論サービス TEE での ML モデルの実行および入札での使用をサポート	開発中	Google Cloud で利用可能 Tensorflow と PyTorch を使用した静的 ML モデルのデプロイとプロトタイプ作成が可能	AWS で利用可能本番稼働モデルのデプロイ（Tensorflow と PyTorch のモデル向け）テレメトリー、同意を得たデバッグ、モニタリング
TEE での入札とオークションのサポート	Google Cloud で利用可能	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。
高信頼実行環境（TEE）で行われる Protected Auction 中に、永続的なシグナルを処理して、その後の特徴量エンジニアリングのためにリアルタイムで準備する JavaScript API。

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

広告テクノロジーは、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 が設定されている場合にはその ID をオーバーライドしないために役立ちます。
append: 指定されたキーに関連付けられた時系列に要素を追加します。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）は、パブリッシャーからの関連するコンテキストデータと購入者ごとの暗号化されたペイロードを、Protected Auction に送信されるリクエストに含めて getAdSelectionData 呼び出しを使用して送信することにより、広告選択ワークフローを開始します。この API はリマーケティングワークフローで使用されるものと同じ 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 のリマーケティングフローと同じ方法で指定されます。詳しくは、入札とオークションの設定をご覧ください。入札コードは、リマーケティングに使用するのと同じクラウドストレージのロケーションで利用できます。

レポート

このプロポーザルでは、Protected Audience レポートのプロポーザルと同じ Reporting API（たとえば、プラットフォームが販売者と購入者のレポートを送信するようトリガーする reportImpression() など）を使用します。

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

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

短期的には、generateBid() からノイズが追加されたデータを出力する一時的な方法を提供します。この提案の初期案を以下に示します。業界からのフィードバックに応じて、この提案を進化させていきます（下位互換性のない変更も含まれる可能性があります）。

技術的には、次のように機能します。

広告テクノロジーは、送信するデータのスキーマを定義します。
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()` で下り（外向き）ペイロードを構築する

特定の購入者のすべての Protected App Signals は、その購入者の generateBid() UDF で利用できます。これらの特徴量が抽出されると、アドテク企業は JSON 形式でペイロードを作成します。この下り（外向き）ペイロードは、広告テクノロジーサーバーに送信される購入者の落札レポートに含まれます。

この設計の代替案として、下り（外向き）ベクトルの計算を generateBid() ではなく reportWin() で行う方法があります。各アプローチにはトレードオフがあり、業界からのフィードバックを踏まえて最終決定を行います。

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

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

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

広告テクノロジーが generateBid() で作成した下り（外向き）ペイロードがプラットフォームの検証に合格するかどうかを確認するための JavaScript API が提供されます。

validate(payload, schema)

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

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

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

ノイズ付加方法は次のとおりです。

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

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

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

すべてのフィーチャータイプと下り（外向き）ペイロード自体のワイヤーフォーマットの詳細については、GitHub をご覧ください。

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

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

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

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

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

次に、egressPayload のサイズを最終決定するためのテストプロトコルについて説明します。Google の目標は、業界と協力して、有用性とデータ最小化のバランスが取れたサイズを見つけることです。これらのテストで生成されるアーティファクトは、x 軸がトレーニングペイロードのサイズ（ビット単位）、y 軸がそのサイズのモデルで生成された収益の割合（サイズ無制限のベースラインと比較）を示すグラフです。

ここでは、pInstall モデルをトレーニングすると仮定します。トレーニングデータのソースは、ログとオークションで落札したときに受け取る temporaryUnlimitedegressPayload のコンテンツです。広告テクノロジーのプロトコルでは、まずオフラインテストを行います。

Protected App Signals で使用するモデルのアーキテクチャを決定します。たとえば、モデルの因数分解を使用するかどうかを判断する必要があります。
モデルの品質を測定する指標を定義します。推奨される指標は、AUC 損失とログ損失です。
モデルのトレーニング中に使用する特徴のセットを定義します。
そのモデルアーキテクチャ、品質指標、トレーニング特徴のセットを使用して、アブレーションスタディを実行し、PAS で使用する各モデルのビットあたりのユーティリティを決定します。アブレーションスタディの推奨プロトコルは次のとおりです。
1. すべての特徴量を使用してモデルをトレーニングし、ユーティリティを測定します。これが比較のベースラインになります。
2. ベースラインの生成に使用される各特徴について、その特徴以外のすべての特徴を使用してモデルをトレーニングします。
3. 結果として得られたユーティリティを測定します。デルタを特徴量のサイズ（ビット単位）で割ります。これが、その特徴量のビットあたりの期待効用です。
テスト対象のトレーニングペイロードサイズを決定します。[5, 10, 15, ..., size_of_all_training_features_for_baseline] ビットをおすすめします。それぞれが、テストで評価される egressPayload のサイズを表します。
可能なサイズごとに、アブレーションスタディの結果を使用して、ビットあたりのユーティリティを最大化するそのサイズ以下の特徴のセットを選択します。
可能なサイズごとにモデルをトレーニングし、すべての特徴でトレーニングされたベースラインモデルの有用性の割合として有用性を評価します。
結果をグラフにプロットします。x 軸はトレーニングペイロードのサイズ（ビット単位）、y 軸はベースラインと比較したモデルで生成された収益の割合です。

次に、広告テクノロジーは、temporaryUnlimitedEgressPayload 経由で送信された特徴データを使用して、ライブトラフィックテストでステップ 5 ～ 8 を繰り返すことができます。広告テクノロジー企業は、オフライントラフィックとライブトラフィックのテスト結果をプライバシーサンドボックスと共有して、egressPayload のサイズに関する決定に役立てることができます。

これらのテストのスケジュールと、egressPayload のサイズを結果の値に設定するスケジュールは、このドキュメントの範囲外であり、今後のアップデートで提供されます。

データ保護対策

エグレスされたデータには、次のような保護対策が適用されます。

egressPayload と temporaryUnlimitedEgressPayload の両方がノイズ処理されます。
データの最小化と保護のため、temporaryUnlimitedEgressPayload はサイズテストの期間中のみ使用できます。このテストでは、egressPayload の正しいサイズを決定します。

権限

ユーザーコントロール

このプロポーザルの目的は、Protected App Signals またはカスタムオーディエンスを 1 つ以上保存しているインストール済みアプリのリストをユーザーが確認できるようにすることです。
ユーザーはこのリストからアプリをブロックしたり削除したりできます。ブロックと削除では、次の処理が行われます。
- アプリに関連付けられているすべての Protected App Signals とカスタムオーディエンスを消去します。
- アプリが新しい Protected App Signals とカスタムオーディエンスを保存しないようにします。
ユーザーは Protected App Signals と Protected Audience API を完全にリセットできます。リセットを行うと、デバイス上の既存の Protected App Signals とカスタムオーディエンスはすべて消去されます。
ユーザーは、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 を制御する方法の概要を説明します。

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