この提案には、プライバシー サンドボックスの登録プロセスと証明書が適用されます。証明書の詳細については、提供される証明書のリンクをご覧ください。この提案の今後の更新で、このシステムへのアクセス権を取得するための要件を説明します。
モバイルアプリ インストール広告(ユーザー獲得広告とも呼ばれます)は、モバイル広告の一種で、ユーザーにモバイルアプリのダウンロードを促します。通常、これらの広告はユーザーの興味や属性に基づいて配信され、ゲーム、ソーシャル メディア、ニュースアプリなどの他のモバイルアプリによく表示されます。ユーザーがアプリ インストール広告をクリックすると、アプリストアに直接移動し、アプリをダウンロードできます。
たとえば、米国で新しいモバイル フード デリバリー アプリの新規インストールを促進しようとしている広告主は、以前に他のフード デリバリー アプリを利用したことのある米国在住のユーザーを広告のターゲットとします。
これは通常、広告テクノロジー間にコンテキスト シグナル、ファースト パーティ シグナル、サードパーティ シグナルを組み込んで、広告 ID に基づいてユーザー プロファイルを作成することで実装されます。広告テクノロジーの機械学習モデルは、この情報を入力として使用し、ユーザーとの関連性が高く、コンバージョンにつながる可能性が最も高い広告を選択します。
クロスパーティのユーザー ID への依存をなくすことでユーザーのプライバシーを向上させる効果的なアプリ インストール広告をサポートするために、次の API が提案されています。
- Protected App Signals API: ユーザーの潜在的関心を表す、広告テクノロジーによりエンジニアリングされた特徴量の保存と作成に重点を置いています。広告テクノロジーは、アプリのインストール、初回起動、ユーザー アクション(ゲーム内のレベリング、実績)、購入アクティビティ、アプリでの時間など、自己定義のアプリごとのイベント シグナルを保存します。シグナルは、データ漏洩を防ぐためにデバイスに書き込まれ、保存されます。シグナルは、安全な環境で実行されている保護オークション中に特定のシグナルを保存した広告テクノロジー ロジックでのみ使用できます。
- Ad Selection API: Trusted Execution Environment(TEE)で実行する Protected オークションを設定して実行するための API を提供します。広告テクノロジーは、Protected App シグナルとパブリッシャーが提供するリアルタイムのコンテキスト情報の両方を使用して、広告候補の取得、推論の実行、入札単価の計算、「落札」広告を選択するためのスコアリングを行います。
ここでは、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 へのアクセスは、デバイス上のオークションではサポートされていません。
広告選択ワークフローは次のとおりです。
- 販売者の SDK が、Protected App Signals のデバイス上で暗号化されたペイロードを送信します。
- 販売者のサーバーがオークション構成を作成し、それを暗号化されたペイロードとともに販売者の信頼できる入札およびオークション サービスに送信し、広告選択ワークフローを開始します。
- 販売者の入札およびオークション サービスは、参加している信頼できる購入者のフロントエンド サーバーにペイロードを渡します。
- 購入者の入札サービスがバイサイド広告選択ロジックを実行します。
- セルサイド スコアリング ロジックが実行されます。
- 広告がレンダリングされ、レポートが開始されます。
広告選択ワークフローを開始する
アプリで広告を表示する準備が整うと、広告テクノロジー 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 件)に絞り込めます。それらの入札単価が計算されてから、最終的な選択のために広告が販売者に返されます。
入札前に、購入者は多数の広告の選択肢からスタートします。広告ごとに入札単価を計算するには時間がかかりすぎるため、購入者はまず多数の選択肢から上位 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()
で以下を実行します。- モデルに対して推論を行い、非公開のユーザー エンベディングを取得します。
- ドット積などのオペレーションを使用して、非公開のユーザー エンベディングを、
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 つの下り(外向き)ペイロードをサポートします。egressPayload
: このドキュメントでこれまでに説明したサイズ制限された下り(外向き)ペイロード。最初、この下り(外向き)ペイロードのサイズは 0 ビットです(つまり、検証中に常に削除されます)。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 の作成は、広告テクノロジーによる承認を必要とするように構成できます。