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

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

この提案は、プライバシーサンドボックスの登録プロセスの対象であり、構築できます。証明書の詳細については、提供された証明書リンクに接続します。この提案の今後の更新ではこのシステムにアクセスするための要件が記載されています。

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

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

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

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

Protected App Signals API: ユーザーの潜在的関心を表す、広告テクノロジーによりエンジニアリングされた特徴量の保存と作成に重点を置いています。広告テクノロジーが、アプリごとのイベントシグナルを独自に定義して保存し、インストール数、初回起動、ユーザーアクション（ゲーム内レベル、実績）、購入アクティビティ、アプリ内滞在時間などですシグナルは Cloud Storage、BigQuery、デバイスに提供され、データ漏洩を防止する目的で Protected Auction 中に特定のシグナルを保存した広告テクノロジーロジック安全な環境で実行する必要があります。
Ad Selection API: この API は、高信頼実行環境（TEE）で実行される Protected Auction 広告テクノロジーは広告候補の取得、推論の実行、入札単価の計算、「勝利」を選出します。Protected App Signals とニュースメディアが提供するリアルタイムのコンテキスト情報を使用します

で確認できます。 <ph type="x-smartling-placeholder">

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

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

シグナルのキュレーション: ユーザーがモバイルアプリを使用する際に、広告テクノロジーがシグナルをキュレートします。広告テクノロジーが定義したアプリイベントを保存し、 Protected App Signals API。これらのイベントは、保護されたデバイス上のカスタムオーディエンスと同様、保存前に暗号化され、入札とオークションサービスのみが実行中の適切なセキュリティと保護機能を備えた高信頼実行環境内で、プライバシー管理で復号し、広告の入札やスコア付けに使用できます。
シグナルのエンコード: カスタム広告テクノロジーロジックによって、スケジュールされた頻度でシグナルが準備されます。Android のバックグラウンドジョブがこのロジックを実行して、オンデバイスのエンコードを実行して Protected App Signals のペイロードを生成する後で Protected 環境の適用時に広告選択にリアルタイムで使用できる。ペイロードは、次の宛先に送信されるまで、デバイスに安全に保存されます。決定します
広告の選択: ユーザーとの関連性が高い広告を選択するため、販売者 SDK Protected App Signals の暗号化されたペイロードを送信し、 Protected Auctionオークションでは、購入者のカスタムロジックが Protected アプリシグナルと、パブリッシャー提供のコンテキストデータ（ Open-RTB 広告リクエストで共有される）をエンジニアリングチームに広告選択（広告の取得、推論、入札）を目的とした機能です。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	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 は、広告テクノロジーによって定義された Protected App Signals を保存または削除できるアプリの起動、実績、購入アクティビティ、表示されます。Protected App Signals は、デバイス上に安全に保存され、デバイスに送信する前に暗号化されるため、入札とオークションのみが適切なセキュリティを備えた高信頼実行環境内で実行されるプライバシー管理で復号し、広告の入札やスコアリングを行います。類似の Custom Audience API: デバイスに保存されているシグナルの読み取りや検査ができない使用したり、シグナル値を読み取るための 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）で実行します。

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

広告テクノロジーは、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: 値がまだ保存されていない場合に、指定されたキーにスカラー値を挿入します。このオプションは、たとえばすでに存在する場合はオーバーライドしないようにします設定されます。
add: 指定されたキーに関連付けられた時系列に要素を追加します。 maxSignals パラメータは、時間あたりのシグナルの最大数を指定しますシリーズとして提供されますサイズを超えると、古い要素が削除されます。鍵が自動的に時系列に変換されるスカラー値が含まれます。
remove: 指定したキーに関連付けられているコンテンツを削除します。

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

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

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

保存されたシグナルは、処理を実行するアプリケーションと取得リクエスト、リクエストの応答者（サイトの「site」または「origin」）登録されている広告テクノロジーなど）と、リクエストの作成時間が含まれます。すべてのシグナルは、プライバシーサンドボックスに登録済みの広告テクノロジーに代わって保存されます。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 Auction に送信されるようにします。これは、リマーケティングワークフローで使われるものと同じ 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 を実行します。この 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() の場合、プラットフォームは販売者や購入者のレポートの送信など）が含まれます。

バイサイドレポートの一般的なユースケースの一つは、トレーニングデータの取得です。使用されるモデルを定義します。このプラットフォームでは、既存の API に加え、イベント単位のデータを BigQuery から広告テクノロジーサーバーに送信しますこれらの下り（外向き）ペイロードには、分析できます

長期的には、プライバシー保護のソリューションを検討し、 Protected Auction で使用されるデータを使用したモデルのトレーニング（イベントレベルの送信は行わない）ユーザーデータを保護する責任を負っています。詳細はトレーニングと説明します。

短期的には、ノイズのあるデータをネットワークから generateBid()。当初の提案は以下のとおり。今後さらに発展させる予定（下位互換性のない変更を含む）できます。

技術的には次のような仕組みになっています。

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

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

進化するプライバシー要件をプラットフォームが適用するためには、下り（外向き）ペイロードにプラットフォームが理解できる方法で構造化する必要があります。広告テクノロジーは下り（外向き）ペイロードの構造を定義する必要があります。スキーマプラットフォームによって処理され、入札では機密情報として扱われる他の広告テクノロジーリソースと同じメカニズムを使用するオークションサービス 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() に変更。それぞれにトレードオフがある業界からのフィードバックを受け、この決定を最終的に決定します。

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

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

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

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

validate(payload, schema)

この JavaScript API は完全に、呼び出し元が特定のペイロードをプラットフォーム検証に合格します。実際の検証をプラットフォームで実施して、悪意のある generateBid() UDF から保護します。

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

プラットフォームは、落札レポートに含める前に下り（外向き）ペイロードをノイズにします。最初のノイズしきい値は 1% ですが、この値は時間の経過とともに変化する可能性があります。「プラットフォームは、特定の下り（外向き）ペイロードがノイズが入りました。

ノイズ除去方法は以下のとおりです。

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

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

ノイズが付加された検証済みの下り（外向き）ペイロードが、 reportWin()、プライバシー外で購入者の広告テクノロジーサーバーに送信されます境界内に限定されます。下り（外向き）ペイロードは転送形式になります。

すべての機能タイプと下り（外向き）ペイロードの送信形式に関する詳細 GitHub で入手できます。

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

下り（外向き）ペイロードのサイズ（ビット単位）により、ユーティリティとデータの最小化のバランスが取れています。業界と協力して適切な規模を必要があります。テストの実施中は一時的に下り（外向き）データのトラフィックを許可します。下り（外向き）データはテストが完了すると、サイズ制限は解除されます。

サイズの決定方法:

まず、generateBid() で 2 つの下り（外向き）ペイロードをサポートします。 <ph type="x-smartling-placeholder">
1. egressPayload: これまでに説明したサイズ制限のある下り（外向き）ペイロード説明します。最初は、この下り（外向き）ペイロードのサイズは 0 ビットです。（つまり、検証中に常に削除されます）。
2. temporaryUnlimitedEgressPayload: サイズが無制限の一時的な下り（外向き）ペイロードを使用できます。フォーマット、作成、処理この下り（外向き）ペイロードでは、egressPayload と同じメカニズムが使用されています。
これらの下り（外向き）ペイロードには、それぞれ独自のスキーマ JSON ファイルがあります。 egress_payload_schema.json と temporary_egress_payload_schema.json。
モデルを決定するための実験プロトコルと一連の指標を提供さまざまな下り（外向き）ペイロードサイズ（5、10、... ビットなど）で利用できます。
テストの結果に基づいて、外向きのペイロードサイズを実用性とプライバシーの適切なトレードオフを見極める必要があります
egressPayload のサイズを 0 ビットから新しいサイズに設定します。
設定された移行期間が経過すると、temporaryUnlimitedEgressPayload は削除されます。 egressPayload だけが新しいサイズで残ります。

Google では、この変更を管理するための追加の技術的なガードレールを調査しています。（たとえば、サイズを 0 ビットから増やしたときに egressPayload を暗号化します）。テストの実施時期や temporaryUnlimitedEgressPayload -- 今後のアップデートに含まれます。

次に、キャンペーンの規模を確定するための、考えられるテストプロトコルについて説明します。 egressPayload。Google の目標は業界と連携して、ユーティリティとデータの最小化ですこれらのテストで生成されるアーティファクトは、 X 軸はトレーニングペイロードのサイズ（ビット単位）で、 y 軸は、そのサイズのモデルで生み出された収益の割合サイズ無制限のベースラインにスケーリングできます

pInstall モデルとトレーニングデータのソースをトレーニングするとします。ログと temporaryUnlimitedegressPayload の内容です。表示されるはずです広告テクノロジー向けのプロトコルは、まずオフラインテスト:

Protected App で使用するモデルのアーキテクチャを決定するシグナル。たとえば、Google Workspace の導入をモデル分解を使用する。
モデルの品質を測定するための指標を定義する。推奨される指標は AUC 減少ですログ損失です
モデルのトレーニング中に使用する特徴のセットを定義する。
そのモデルアーキテクチャ、品質指標、一連のトレーニング特徴を使用して、アブレーションスタディを実行し、各ビットごとに寄与する有用性を選択することもできますアブレーション研究に推奨されるプロトコル次のとおりです。 <ph type="x-smartling-placeholder">
1. すべての特徴でモデルをトレーニングし、ユーティリティを測定する。ここが基準値と比較します。
2. ベースラインの生成に使用した特徴量ごとに、すべての項目で利用できます。
3. 結果の有用性を測定する。デルタを特徴のサイズで割るビット単位、これは、その特徴で想定される 1 ビットあたりのユーティリティです。
テスト対象となるトレーニングペイロードのサイズを決定する。水提案 [5, 10, 15, ..., size_of_all_training_features_for_baseline] ビット。これらは、それぞれが egressPayload で許容されるサイズを表します。テストが評価されます
可能なサイズごとに、それ以下の特徴のセットを選択するアブレーションスタディの結果を使用して、1 ビットあたりの有用性を最大化するサイズを定めます。
可能なサイズごとにモデルをトレーニングし、すべての特徴でトレーニングされたベースラインモデルの有用性の割合。
X 軸をトレーニングのサイズ、グラフに結果をプロットするで表示され、Y 軸は Google Cloud で生み出されるそのモデルをベースラインと比較します

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

テストの実施スケジュールと規模設定のスケジュール egressPayload の変換結果の値への変換は、このドキュメントでは扱いません。今後のアップデートで対応する予定です

データ保護対策

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

egressPayload と temporaryUnlimitedEgressPayload の両方がノイズになります。
データの最小化と保護のため、temporaryUnlimitedEgressPayload では次のことが行われます。サイズテスト期間中のみ利用可能で egressPayload の正しいサイズを判断します。

権限

ユーザーコントロール

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

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