入札およびオークション サービス

Protected Audience の最初のプロポーザルでは、リマーケティング広告デマンドの入札とオークションはローカル デバイス上で実行されることになっています。そのため、処理能力が限られているローカル デバイスで実行するには現実的でないコンピューティング能力が必要となったり、ネットワーク レイテンシによって広告の選択とレンダリングに時間がかかりすぎたりする可能性があります

入札とオークション サービス（B&A）プロポーザルでは、Protected Audience の処理がユーザーのローカル デバイスではなく、高信頼実行環境（TEE）のクラウド サーバーで行われるようにする方法を提案しています。B&A プロポーザルは、コンテキスト広告とリマーケティング広告デマンドに関する一元化されたフローをサポートすることを目的としています。処理をサーバーに移行することにより、デバイスのコンピューティング サイクルとネットワーク帯域幅を解放し、Protected Audience のオークションを最適化できます。

Google は、B&A のコンポーネントを提供して、オープンソースとして利用できるようにする予定です。利用する広告テクノロジーは、サポート対象のパブリック クラウド プロバイダを使用して独自のインスタンスをホストできます。B&A プロポーザルについて詳しくは、GitHub をご覧ください。GitHub のドキュメントに記載されている日付は Chrome での実装に基づいています。Android との統合については今後詳細を発表します。このドキュメントでは、B&A の概要と、B&A を利用するために Android が提供する新しい API について説明します。この新しい API の使用方法に関する技術的な情報については、今後のアップデートで投稿します。

B&A サービスに適した領域

B&A は、広告テクノロジーが所有する信頼できるサーバー内で Google が提供するオープンソース バイナリを実行し、オークションを実施するための新たなオプションです。ユーザーデータは引き続きローカル デバイス上にあり、Google はそのデータを TEE に安全に渡すための API を提供します。詳しくは以下の暗号化戦略をご覧ください。

つまり、オークション プロセスの一部はローカル デバイス上で行われ、それ以外はクラウドで行われるということです。DSP の観点からは、カスタム オーディエンス（リマーケティング キャンペーンの広告候補を含む）は、ローカル デバイス上でオークションが実施される場合と同じカスタム オーディエンス管理 API によって、引き続きローカル デバイスで管理されます。SSP の観点からは、リクエストは引き続きローカル デバイス上でトリガーされます。このドキュメントでは、使用する新しい API について説明します。どちらの場合も、オークションの結果の報告は、B&A 呼び出し完了後にこれまでどおりローカル デバイスから開始されます。

主な違いは、入札、スコアリング、レポート URL 生成ロジックが実行される場所です。ローカル デバイス上で入札、オークション、レポート ロジックが実行されるのではなく、generateBid()、scoreAd()、reportResult()、reportWin() ロジックは TEE で実行されます。購入者の入札ロジックと販売者のスコアリング ロジックは、Protected Audience オークション フローの最中に独自の B&A 環境で実行されます。

Protected Audience のオークション フローと、入札とオークションが実施される領域を示した図。
Protected Audience のオークション フロー

データ暗号化

B&A では、カスタム オーディエンスや入札単価などの Protected Audience 情報は、ローカル デバイスから販売者の広告テクノロジー サーバーを経由して購入者の広告テクノロジー サーバーに流れ、その後デバイスに戻ってきます。このため、B&A プラットフォームは、Protected Audience サービスに送信するデータを暗号化し、証明されたサービスのみが復号できるようにしています。暗号化戦略について詳しくは GitHub をご覧ください。

アーキテクチャとオークション フロー

このプロポーザルでは、デバイスから B&A へのデータフローなど、GitHub に詳細が記載されているいくつかの新しいコンポーネントが必要となります。

以下で説明する、コンテキストに応じた Protected Audience オークションの統合フローを示す図。
入札とオークションのサービスで、コンテキストに応じた Protected Audience オークション フローを統合。

データフローの概要は以下のとおりです。

  1. ローカル デバイス上で、販売者が getAdSelectionData API を使用して、Protected Audience から情報を収集します。
  2. オンデバイス SDK が販売者の広告サービスにリクエストを送信します。このリクエストには、コンテキストに応じたペイロードと暗号化された ProtectedAudienceInput が含まれています。
  3. 販売者の広告サービスは、TEE 外で実行されている購入者のリアルタイム ビッダー（RTB）サービスにリクエストを送信してコンテキスト広告候補を取得し、スコアリングして落札するコンテキスト広告を選択します。
  4. 販売者の広告サービスが、TEE で実行されている SellerFrontEnd サービスにリクエストを送信します。
  5. SellerFrontEnd サービスは、購入者固有のデータを含むリクエストを BuyerFrontEnd サービスに送信します。
  6. 購入者は独自の Key-Value サービスと入札サービスを使用して、リマーケティングの対象となるすべてのカスタム オーディエンスについて、ローカル デバイスから取得した広告候補に対する入札を生成します。
  7. SellerFrontEnd サービスは Key-Value サービスから広告候補を読み込み、スコアを付けます。結果は暗号化され、販売者の広告サービスに返されます。
  8. 販売者の広告サービスは、暗号化された落札結果と、必要に応じてコンテキストに基づく結果をオンデバイス SDK に返します。
  9. ローカル デバイス上で販売者が processAdSelectionResult API を使用して落札広告を取得すると、販売者の広告サービスからのレスポンスが復号されます。

各ステップとデータの暗号化方法について詳しくは、GitHub をご覧ください。これらのコンポーネントのコードは、オープンソースから入手できるようになります。入手できるコードでは、SellerFrontEnd サービスから BuyerFrontEnd サービスへのリクエストのフェデレーションを処理します。

クラウドへのデプロイ

広告テクノロジーが、サポート対象のパブリック クラウド プラットフォームに B&A サービスをデプロイします。このデプロイは、可用性のサービスレベル目標を定義する広告テクノロジーが管理します。

オークションを実行する

B&A オークションの実行における最初のステップは、ローカル デバイス上のカスタム オーディエンスからデータを収集し、暗号化してサーバーサイドのオークションに送信することです。そのために getAdSelectionData API を使用します。

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData メソッドは、BuyerInput や ProtectedAudienceInput などの B&A コンポーネントで必要とされる入力を生成し、データを暗号化してから結果を呼び出し元に提供します。アプリ間でのデータ漏洩を防ぐため、このデータにはローカル デバイス上のすべての購入者の情報が含まれています。この決定について詳しくは、プライバシーに関する考慮事項セクションをご覧ください。

この API は AdSelectionData オブジェクトを返します。

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

オンデバイス SDK はこの AdSelectionData を使用し、POST または PUT リクエストにデータを含めることで、販売者の広告サービスにリクエストを送信できます。

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

オンデバイス SDK がこのデータのエンコードを行います。販売者の広告サービスに multipart/form-data としてリクエストを送信するなど、スペース効率の高いソリューションの使用をおすすめします。

リクエストが開始されると、販売者の広告サービスは TEE で実行されている SellerFrontEnd サービスにリクエストを転送します。販売者は、SellerFrontEnd サービスを設定する際に、連携している購入者が実行している BuyerFrontEnd サービスに対応したドメイン アドレスのリストを指定します。リクエストは販売者が指定したさまざまな BuyerFrontEnd サービスにフェデレーションされ、購入者は選択した広告候補の入札を生成できるようになります。特定の購入者には、購入者が所有するカスタム オーディエンスに関する情報のみが B&A によって送信されるため、購入者間でデータ漏洩が生じることはありません。入札の生成後、広告候補のリストは SellerFrontEnd サービスに戻り、そこで落札者が選ばれます。最後に SellerFrontEnd サービスが、暗号化された落札広告をローカル デバイスに返します。

販売者の広告サービスへのリクエストからレスポンスがローカル デバイスに返されると、プラットフォームで 2 つ目の新しい API によって結果が復号され、AdSelectionOutcome を取得できるようになります。これは、今のオンデバイス オークションから返されるものと同じオブジェクトです。

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

レポート

レポート URL は B&A サービスで生成されます。オークションのインプレッションとインタラクションを報告する URL への ping は、引き続きローカル デバイス上でトリガーする必要があります。オンデバイス SDK は、B&A フローで生成された AdSelectionId を使用して、reportImpression() API と reportInteraction() API を今と同じように呼び出す必要があります。インタラクション レポート用に生成されたビーコンと、対応する URL は暗号化されたレスポンスに含まれるため、レスポンスを復号したときに、イベントと URL のマッピングがローカル デバイスに保存されます。

プライバシーに関する考慮事項

GitHub の Browser Bidding & Auction API プロポーザルでは、どのようにプライバシーが考慮されるかについて記載されています。このプロポーザルでは Chrome の用語が使用されていますが、Android にも同じ原則が適用されます。

adSelectionData は暗号化され、転送中のデータには PPAPI と信頼できるサーバーのみがアクセスできるようになります。adSelectionData のサイズ変更によるデータ漏洩のリスクを軽減するため、すべての getAdSelectionData API 呼び出しで同じ adSelectionData を生成する予定です。つまり、ローカル デバイス上のすべての CustomAudience が adSelectionData の作成に使用されるということです。また、生成される adSelectionData に対する GetAdSelectionData 入力パラメータによる影響も制限する予定です。

オンデバイス オークション データをすべて使用して全広告テクノロジーで同じ adSelectionData を生成すると、広告テクノロジー サーバーを呼び出すたびに転送する必要があるペイロードが大きくなると同時に、エコシステムが開放され、悪意のある第三者に不正使用される可能性があります。このような懸念については、以下のサイズに関する考慮事項と不正使用対策に関する考慮事項で説明します。

サイズに関する考慮事項

広告テクノロジー クライアント SDK は、暗号化された adSelectionData のバイトを、販売者のサーバーに対するコンテキスト広告の呼び出しにパッケージ化する必要があります。最適なパフォーマンスを実現するには、機能を損なうことなく adSelectionData のサイズを最適化することが重要です。ペイロードの最適化に関する説明にあるとおり、adSelectionData のサイズを削減する最適化手法を導入する予定です。そのような最適化には次のものがあります。

  1. ad_render_id を CustomAudience に追加して、広告レンダリング URI とメタデータを使用する代わりに、adSelectionData を使用して送信できるようにします。広告テクノロジーは、adSelectionData の広告データを送信しないようにすれば、さらに最適化が可能です。このオプションは、今後のリリースの CustomAudience API でサポートされる予定です。
  2. adSelectionData で user_bidding_signals が送信されないようにします。代わりに広告テクノロジーは、Key-Value サーバーから user_bidding_signals を取得できます。
  3. 購入者が CustomAudience の優先度を設定できるようにします。
  4. 購入者が販売者の優先度を指定できるようにします。
  5. adSelectionData を生成するバケットをいくつかに固定することで、ビット漏洩のリスクを軽減しながらペイロード サイズを削減します。

サイズの最適化は、プライバシーに関する考慮事項で挙げた懸念事項に配慮して行われます。

不正使用対策に関する考慮事項

プライバシーに関する考慮事項で説明したとおり、adSelectionData はローカル デバイス上のすべての購入者データを使用して生成されます。

これにより、エコシステムが悪意のある第三者に開放され、パフォーマンスの低下やペイロードの肥大化によるコスト増などにつながる、不正な購入者データが追加される可能性があります。

adSelectionData の不正使用を防止するために、以下の対策を導入します。

  • CustomAudience が承認済みの販売者と販売者の優先度を明示的に指定できるようにします。
  • 生成されたペイロードの購入者、購入者の優先度、購入者ごとの割り当てを SSP で明示的に指定できるようにします。
  • 呼び出しあたりの最大購入者数または購入者ごとの最大サイズを定義できるメカニズムを SSP に提供します。

これらの対策は、広告テクノロジーが、連携する他の広告テクノロジーを定義し、処理する必要がある adSelectionData ペイロードに許容可能な上限を設定できるようにすることが目的です。Google では、販売者がこの購入者リストと優先度を個別の呼び出しで指定できるようにすることを提案します。この仕様は一定期間変えず、繰り返し呼び出すことでユーザーに関する余分なデータが公開されないようにします。

上記の軽減策は検討中であり、今後変更される可能性があります。前述のとおり、不正使用とサイズ制限のための対策は、すべてプライバシーに関する考慮事項に沿って行う必要があります。