入札とオークション サービスの統合と最適化

Android 向けの入札とオークション サービスの設計案では、信頼できる入札とオークション サーバーを使用して Android でオークションを実施する際の実行とデータフローについて詳細に記載されています。転送中のデータがプライバシー保護 API と信頼できるサーバーによってのみ処理されるように、データは双方向のハイブリッド公開鍵暗号化を使用してクライアントとサーバー間で暗号化されます。

Protected Audience オークション フロー

前述のとおりオークションを実施するには、デバイスの販売者広告テクノロジーが次の手順を行う必要があります。

1. サーバー オークションのためのデータを収集して暗号化する
2. 信頼できない販売者サービスにリクエストを送信する
3. 信頼できない販売者サービスからレスポンスを受け取る
4. Protected Audience のオークション レスポンスを復号してオークション結果を取得する

Protected Audience に、サーバー オークションの実施をサポートする 2 つの新しい API が導入されました。

1. getAdSelectionData API は、サーバー オークションのデータを収集し、オークション データを含む暗号化ペイロードを生成します。入札とオークション サーバーは、このペイロードを使用してオークションを実施し、オークション結果を生成して生成した結果を返します。
2. オンデバイス広告テクノロジー クライアントは、persistAdSelectionResult API を呼び出して、サーバー オークションによって生成された結果を復号し、落札した広告のレンダリング URL を取得できます。

オークションを実施するには、デバイスの販売者広告テクノロジーが以下の対象を統合して構築する必要があります。

1. サーバー オークションの販売者向けデータの収集と暗号化: 広告テクノロジーが getAdSelectionData API を呼び出して暗号化されたペイロードを取得する必要があります。
2. 信頼できない販売者サービスにリクエストを送信する: HTTP POST リクエストまたは PUT リクエストに、getAdSelectionData API によって信頼できない販売者サービスに対して生成された暗号化されたペイロードと、信頼できない販売者サービスが必要とするデータを含め、コンテキストに基づく結果を生成します。
3. 信頼できない販売者サービスからレスポンスを受け取る: 信頼できない販売者サービスからのレスポンスには、暗号化された Protected Audience オークション結果とコンテキストに基づくオークション結果が含まれます。
4. Protected Audience オークションのレスポンスを復号してオークション結果を取得する: Protected Audience オークションの結果を復号するには、販売者の広告テクノロジーが persistAdSelectionResult API を呼び出す必要があります。persistAdSelectionResult によって生成された結果は、広告テクノロジーが、コンテキスト広告または Protected Audience 広告がオークションで落札したかどうか、および落札した Protected Audience 広告の URI（該当する場合）を判断するのに役立ちます。

サーバー オークションでサポートされる機能

Google は、現在オンデバイス オークションで利用できるすべての機能をサポートすることを目指しています。サーバー オークションでこれらの機能をサポートするためのスケジュールは、次のとおりです。

	オンデバイス オークション		サーバー オークション
	デベロッパー プレビュー	ベータ版	デベロッパー プレビュー	ベータ版
イベントレベルの成功レポート	2023 年第 1 四半期	2023 年第 3 四半期	なし	2023 年第 4 四半期
ウォーターフォール メディエーション	2023 年第 1 四半期	2023 年第 4 四半期	なし	2024 年第 1 四半期
フリークエンシー キャップ フィルタリング	2023 年第 2 四半期	2023 年第 3 四半期	なし	2023 年第 4 四半期
コンテキスト広告を広告選択ワークフローに渡してフィルタする	2023 年第 2 四半期	2024 年第 1 四半期	なし	なし
インタラクション レポート	2023 年第 2 四半期	2023 年第 3 四半期	なし	2023 年第 4 四半期
カスタム オーディエンス委任に参加する	2023 年第 3 四半期	2023 年第 4 四半期	なし	2023 年第 4 四半期
CPM 以外の請求	2023 年第 3 四半期	2023 年第 4 四半期
デバッグ レポート	2023 年第 3 四半期	2023 年第 4 四半期	2023 年第 3 四半期	2023 年第 4 四半期
Open Bidding メディエーション	なし	なし	なし	2024 年第 1 四半期
アプリ インストール広告のフィルタリング	2023 年第 2 四半期	2024 年第 1 四半期	なし	2024 年第 1 四半期
通貨の管理	なし	なし	なし	2024 年第 1 四半期
k-匿名性の統合	なし	2024 年第 1 四半期	なし	2024 年第 1 四半期
プライベート アグリゲーションの統合	なし	なし	なし	2024 年第 3 四半期

Protected Audience API を使用してサーバー オークションを実施する

デベロッパー プレビュー トラックでは、AdSelectionManager が 2 つの新しい API（getAdSelectionData と persistAdSelectionResult）を公開しています。これらの API を使用すると、広告テクノロジー SDK を入札とオークション サーバーと統合できます。

サーバー オークションのためのデータを収集して暗号化する

getAdSelectionData API は、BuyerInput や ProtectedAudienceInput などの入札とオークション コンポーネントに必要な入力情報を生成し、呼び出し元で結果を利用できるようにする前にデータを暗号化します。アプリ間でのデータ漏洩を防ぐため、このデータにはデバイス上のすべての購入者の情報が含まれています。この決定事項について詳しくは、プライバシーに関する考慮事項のセクションと、これを最適化する方法についてのサイズに関する考慮事項のセクションをご覧ください。

API にアクセスするには、Protected Audience API へのアクセスを有効にし、ACCESS_ADSERVICES_CUSTOM_AUDIENCE 権限を呼び出し元のマニフェストで定義する必要があります。

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. 呼び出し元は、リクエストに seller フィールドを設定する必要があります。このフィールドは、リクエストを処理する前に登録チェックを実行するために使用します。
2. coordinatorOriginUri フィールドは省略可能です。
   1. 設定する場合は、販売者の B&A サーバーのデプロイ時に構成されたコーディネーター URL のスキーム、ホスト名、ポートと同じにする必要があります。
   2. コーディネーターは、承認済みコーディネーターのリストに属している必要があります。

      プロバイダ	URI	URI オリジン	デフォルト
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	はい
      アマゾン ウェブ サービス（AWS）	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com/	×

   3. コーディネーターのオリジンが指定されていない場合は、デフォルトのコーディネーターが使用されます。
   4. コーディネーター URL が変更される可能性はほとんどありませんが、この URL を動的に管理するメカニズムを実装することを強くおすすめします。これにより、新しい SDK をリリースしなくても、URL が今後変更されても対応できるようになります。

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

リクエストの検証が完了すると、オンデバイスの購入者データは BuyerInput と ProtectedAudienceInput に構成されます。その後、最終的なペイロード オブジェクトは、双方向ハイブリッド公開鍵暗号化を使用して暗号化されます。

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome は、getAdSelectionData API の結果として生成されます。以下の内容が含まれます。

1. adSelectionId: この getAdSelectionData の呼び出しを識別する opaque 型の整数。広告テクノロジー クライアントは、この adSelectionId 値を保持する必要があります。これは、getAdSelectionData の呼び出しへのポインタとして機能するためです。この ID は、persistAdSelectionResult API が入札とオークション サーバーからオークションの結果を復号するために必要であり、reportImpression API と reportEvent API でも必要です。
2. adSelectionData: 暗号化されたオークション データです。入札とオークション サーバーがオークションを実施するために必要なものです。このメソッドには次の対象が含まれます。
   1. カスタム オーディエンスのフリークエンシー キャップ、アプリ インストール フィルタ、サーバー オークション要件に基づいてフィルタされたカスタム オーディエンス データ。
   2. 今後のバージョンでは、アプリ インストールのデータが含まれるようになります。

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

エラー、例外、障害の処理

広告選択データの生成が、無効な引数、タイムアウト、リソースの過剰消費などの理由で正常に完了できない場合、OutcomeReceiver.onError() コールバックは次の動作により AdServicesException を示します。

1. getAdSelectionData が無効な引数を指定して開始された場合は、AdServicesException が原因として IllegalArgumentException を示します。
2. 他のすべてのエラーでは、IllegalStateException が設定された AdServicesException を原因として受け取ります。

信頼できない販売者サービスにリクエストを送信する

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

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

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

信頼できない販売者サービスからレスポンスを受け取る

入札とオークション サーバーに関する説明で詳細に説明しているとおり、信頼できない販売者サービスはリクエストを受け取ると、パートナー購入者に対してコンテキスト広告の呼び出しを行います。

信頼できない販売者サービスは、暗号化された adSelectionData と AuctionConfig を、TEE で実行されている入札とオークション サーバーの SellerFrontEnd サービスに転送します。

Protected Audience オークションが完了すると、SellerFrontEnd サービスはオークションの結果を暗号化し、信頼できない販売者サービスに対するレスポンスとして返します。

信頼できない販売者サービスは、コンテキスト広告 / 暗号化された Protected Audience オークションの結果を含めてデバイスにレスポンスを送信します。

レスポンスを受信すると、デバイス上の販売者広告テクノロジー コードが、レスポンス内でコンテキスト広告のみを使用することを選択できます。または、取得した Protected Audience の結果に増分値が存在するとみられると判断した場合は、PersistAdSelectionResult API を呼び出して、Protected Audience の結果を復号することを選択できます。

PersistAdSelectionResult API

Protected Audience の結果を復号するために、販売者の広告テクノロジーで 2 つ目の Protected Audience API persistAdSelectionResult を呼び出すことができます。この API は結果を復号して AdSelectionOutcome を返します。これは、当日のオンデバイス オークションから返されたものと同じオブジェクトです。

呼び出し元が API にアクセスするには、Protected Audience API へのアクセスを有効にし、ACCESS_ADSERVICES_CUSTOM_AUDIENCE 権限をマニフェストで定義する必要があります。

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

呼び出し元は、リクエストで次の値を設定する必要があります。

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: getAdSelectionData 呼び出しによって生成された不透明な識別子。呼び出し元はこの結果を復号しようとします。
2. seller: リクエストを処理する前に、販売者広告テクノロジー ID が登録チェックを実行するようにリクエストで設定する必要があります。
3. adSelectionResult: 呼び出し元が復号しようとしている入札とオークション サーバーによって生成された、暗号化されたオークションの結果。

AdSelectionOutcome のレスポンス

落札した Protected Audience が存在する場合は、AdSelectionOutcome が落札広告のレンダリング URI を返します。adSelectionResult が復号されると、レポートデータが内部で保持されます。OutcomeReceiver.onResult() コールバックは、次の対象を含む AdSelectionOutcome を返します。

• URI: 落札した Protected Audience 広告が存在する場合は、落札した広告の広告レンダリング URL が返されます。落札した Protected Audience が存在しない場合は、Uri.EMPTY が返されます。
• adSelectionId: このサーバー オークションの実行に関連付けられた adSelectionId。

エラー、例外、障害の処理

広告選択データの生成が、無効な引数、タイムアウト、リソースの過剰消費などの理由で正常に完了できない場合、OutcomeReceiver.onError() コールバックは次の動作により AdServicesException を示します。

1. 無効な引数を指定して getAdSelectionData が開始されると、AdServicesException が IllegalArgumentException を原因として示します。
2. 他のすべてのエラーでは、IllegalStateException が設定された AdServicesException を原因として受け取ります。

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

adSelectionData は暗号化され、転送中のデータには PPAPI と信頼できるサーバーのみがアクセスできるようになります。

暗号化を実施しているにもかかわらず、adSelectionData のサイズが原因でデータ漏えいが発生する可能性があります。adSelectionData のサイズは、次の理由で変動する可能性があります。

1. デバイスに存在する CustomAudience データの変更。
2. CustomAudience フィルタリング ロジックの変更。
3. getAdSelectionData 呼び出しへの入力の変更。

1 ビットの漏えいに関する説明で説明したように、adSelectionData サイズの変更は、アプリ間の識別子の生成に使用できます。1 ビットの漏えいに適用される多くの緩和策もここで適用できます。

これらの漏えいを抑制するために、すべての getAdSelectionData API の呼び出しに対して同じ adSelectionData を生成する予定です。最初のリリースでは、デバイス上のすべての CustomAudiences が adSelectionData の作成に使用され、暗号化されたペイロードがパディングされて、サイズのバリエーションがマスクされます。また、生成される adSelectionData に対する GetAdSelectionData 入力パラメータの影響も制限されます。

ただし、デバイス上のオークション データをすべて使用して、すべての広告テクノロジーで同じ adSelectionData を生成すると、大きなペイロードが作成され、広告テクノロジー サーバーへの呼び出しごとに転送する必要があります。オンデバイスのカスタム オーディエンスをすべて使用してオークション ペイロードを生成すると、エコシステムが悪意のあるエンティティによって悪用される可能性も生じます。これらの懸念事項については、以下のサイズの最適化と不正行為の軽減で説明しています。

サイズの最適化

広告テクノロジー クライアント SDK は、adSelectionData の暗号化されたバイトを、広告テクノロジー サーバーに対する HTTP PUT/POST コンテキスト呼び出しにパッケージ化する必要があります。ラウンドトリップ時間のレイテンシの短縮と費用削減のために、ユーティリティに影響を与えずに adSelectionData サイズを可能な限り縮小する必要があります。

Google は、adSelectionData サイズを縮小するために、今後のリリースで以下の最適化を検討し、導入する可能性があります。

1. パディングありの固定バケットサイズ セットで生成されるペイロード: ペイロードを削減しつつサイズの変更による漏えいを最小限に抑えるため、生成されるペイロードには固定サイズバケットを使用することをおすすめします。たとえば、バケット数を小さな値（例: 7）のままにすると、getAdSelectionData の呼び出しごとに漏えいするエントロピーが 3 ビット未満になります。

   オンデバイスのデータが最大バケットサイズを超える場合、どのデータが破棄されるかは、以下で説明する優先度の値などの戦略を使用して決定されます。

2. 購入者の構成: 購入者が購入者ごとのペイロードの構成を設定できる可能性を評価します。この構成は、購入者がどのオークションに参加するかを特定する際に有用です。可能であれば、登録時に購入者の広告テクノロジーがエンドポイントを登録します。これにより、Protected Audience がペイロード構成を毎日定期的に取得します。または、プライバシー保護 API を使用して、購入者の広告テクノロジーがこのエンドポイントを登録できるようにする API を公開します。

   この構成を使用して、getAdSelectionData リクエストごとに生成される adSelectionData への購入者の貢献度を評価します。

   購入者のペイロード構成では、購入者が以下の内容を指定できます。

   1. 許可された販売者のリスト: 購入者の CustomAudience は、許可リスト内の販売者が getAdSelectionData 呼び出しを開始した場合にのみ、ペイロードに追加されます。ペイロードの構成を毎日取得して、許可リストを最新の状態に保ちます。
   2. 販売者ごとのサイズ上限: 購入者は、販売者ごとのサイズ上限を指定して、特定の販売者がオークションを開始したときにペイロードで送信されるデータサイズを決定できます。これは、購入者が特定の販売者のオークション データの処理により多くのリソースを投入する必要がある場合に有効です。SellerFrontendService は、購入者固有のデータのみを各 BuyerFrontendService に転送します。したがって、販売者ごとのサイズ上限を定義することにより、購入者は、販売者が実施するオークションのために入札とオークション サーバーの BuyerFrontendService によって取り込まれ、処理されるデータの量を明示的に制御できます。

3. 販売者の構成: 販売者がオークション パラメータを定義してペイロードのサイズとオークション参加者を制御できる、販売者ごとのオークション構成の実現可能性を評価します。可能な場合は登録時に、販売者の広告テクノロジーで、Protected Audience が販売者ごとのオークション構成を一定の頻度で取得するエンドポイントを指定できます。この構成を使用して、getAdSelectionData リクエストごとに生成される adSelectionData の構成と上限を決定します。

   購入者の構成と同様に、販売者ごとの構成では、販売者がオークションに参加する予定の購入者群を指定し、ペイロードのサイズに対する購入者ごとの貢献の上限を指定できます。

   販売者オークションの構成では、販売者は次の項目を指定できます。

   1. 許可された購入者のリスト: 特定の販売者が開始したオークションの場合は、許可リスト内の購入者のみがオークションの CustomAudience に貢献できます。オークションは、サーバーサイドの購入者の許可リストで許可リストを最新の状態に保つために、オークション構成を毎日更新する必要があります。
   2. 購入者ごとのサイズ上限: 販売者は、購入者ごとの上限を指定して、SellerFrontendService に送信されるペイロードに各購入者によってアップロードされるデータサイズを規制できます。購入者が購入者ごとのサイズ上限を超えると、購入者のペイロード構成に設定された CustomAudience 優先度を使用して、想定される上限でデータを取得します。
   3. 購入者ごとの優先度: 販売者が購入者ごとの優先度を設定できるようにします。ペイロードのサイズがその上限を超える場合に、どの購入者データをペイロードに保持するかを判断する際には、購入者の優先度が使用されます。
   4. ペイロードのサイズの上限: 販売者ごとにリソースの割り当てが異なり、リクエストごとのオークション ペイロードにサイズの上限を設定することが必要な場合があります。サイズの上限には、Protected Audience API により設定された固定サイズバケットが適用されます。

4. カスタム オーディエンスの変更

   1. カスタム オーディエンスの優先度を指定する: 購入者がカスタム オーディエンスの優先度の値を指定できるようにします。priority フィールドは、購入者のカスタム オーディエンスのセットが販売者ごとまたは購入者ごとのサイズの上限を超える場合に、オークションに参加するカスタム オーディエンスを識別するために使用されます。カスタム オーディエンスで優先度の値が指定されていない場合は、デフォルトで 0.0 に設定されます。

5. ペイロード データの変更

   1. ペイロードで送信されるデータを削減する: 入札とオークション サービスのペイロードの最適化で詳しく説明しているように、カスタム オーディエンスの ads データ、ユーザー入札シグナル、Android シグナルによってペイロードが増加します。ペイロードの増加は、次の方法で軽減できます。
      1. クライアントが、ペイロードで広告オブジェクトではなく広告レンダリング ID を送信するように設定する。
      2. クライアントがペイロードで広告データを送信しないようにする。
      3. クライアント ペイロードでユーザー入札シグナルを送信しない。

上記の戦略では、広告テクノロジーが adSelectionData ペイロードの構成と上限を管理する構成を定義できますが、構成パラメータを変更することで adSelectionData サイズを変更する要因にもなります。これを回避するために、Protected Audience によって、構成済みのエンドポイントから構成が毎日取得されます。

レイテンシの最適化

サーバー オークションで適切なレベルのユーティリティが使用されるようにするには、getAdSelectionData API と persistAdSelectionResult API の呼び出しあたりのレイテンシを低くする必要があります。Google は 2023 年に API の機能サポートを提供することを目標としていますが、今後のリリースでは、API のレイテンシ ベンチマークと最適化に重点を置いています。

レイテンシを許容上限内に保つために、次の戦略を検討しています。

1. Protected Audience データの販売者ごとの事前生成: 販売者のオークション構成と購入者のペイロードの構成はかなり長い期間（1 日単位）安定するため、プラットフォームは 有効な Protected Audience のデータを事前に計算して保存できます。

   この場合、プラットフォームは、カスタム オーディエンスの更新をモニタリングし、更新に基づいて事前に生成された Protected Audience データを変更するメカニズムを構築する必要があります。また、カスタム オーディエンスの更新とサーバー オークション用に生成された adSelectionData の変更が表示されるまでの間に、広告テクノロジーによるレース遅延が発生すると想定される SLO を宣言する必要もあります。

   デバイスに用意されているのはプロセスの優先順位が変動する制限のあるリソース計算モデルであり、この事前生成機能には高い信頼性と SLO による保証が必要であることを、Google は認識しています。

   Protected Audience データの事前生成は、以下に基づいて行われます。

   1. 販売者が Protected Audience データの事前生成を有効にする。
   2. 購入者に、特定の販売者が開始したオークションに参加する資格がある。
   3. 以下の内容に基づいて、ペイロードの一部として購入者ごとにカスタム オーディエンスを特定する。
      1. 購入者ごとのサイズ上限、販売者の構成で定義された購入者ごとの優先度とサイズ上限。
      2. 販売者ごとのサイズ上限、購入者の構成で定義されたカスタム オーディエンスの優先度。

2. ネガティブ フィルタリングの積極的な適用: 販売者が希望する場合、プラットフォームは、Protected Audience データを事前に生成し、ネガティブ フィルタリングを適用して getAdSelectionData 呼び出しから重要ではないものを除外することで、adSelectionData を事前に計算できます。これにより、販売者はネガティブ フィルタリングの古い値を受け入れながら、レイテンシの短縮をバランスよく実現できます。

   販売者構成で getAdSelectionData に、古い値の上限とオーバーライド オプションが設定されたデフォルト オプションを指定することで、必要に応じてプラットフォームで最新の計算を実施できます。また、プラットフォームでは、オークションをウォームアップするために getAdSelectionData の前に呼び出される追加の初期化 API を指定することもできます。

3. 複数のオークションでのペイロードの計算: 特定のシナリオでは、データの鮮度と引き換えに、レイテンシ パフォーマンスの高い API を使用するほうが望ましい場合があります。これを実現するため、プラットフォームでは、ペイロード全体を計算する初期化 API を導入し、呼び出し元に対して計算されたペイロードへの参照を指定できます。

   その後の getAdSelectionData の呼び出しでは、呼び出し元は、adSelectionData の生成に使用する事前計算済みペイロードへの参照を指定できます。

上記 3 つの戦略はすべて初期の調査段階にあり、プラットフォームのレイテンシ最適化の方向性を説明するためのものです。API と広告テクノロジーの要件のレイテンシ プロファイルについて詳細な調査を進める中で、引き続き追加の戦略を提案する予定です。

不正行為の軽減と特定

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

ただし、デバイス上のすべての購入者データが adSelectionData 出力の生成に使用される場合、悪意のあるエンティティが購入者になりすまし、不正な購入者データを作成して Android のパフォーマンスを低下させたり、ペイロードを肥大化してオークションや入札を実施するための広告テクノロジーのコストを増加させたりする可能性があります。

緩和策

許可リストに登録された販売者を含む購入者のペイロード構成や許可リストに登録された購入者を含む販売者のオークション構成など、サイズに関する考慮事項のセクションで説明したいくつかの手段は、ペイロードで予期しないデータを除外する際に活用できます。

SSP による購入者の優先度の指定、生成されたペイロードへの購入者ごとの割り当ての設定、オークション ペイロードあたりの最大サイズの設定など、その他のサイズに関する考慮事項による対策は、悪意のあるペイロードの急増による影響の軽減にも有効な可能性があります。これらの対策は、広告テクノロジーが、連携する他の広告テクノロジーを定義し、処理する必要があるペイロードに許容可能な上限を設定できるようにすることが目的です。

前述のとおり、不正使用とサイズ制限のための対策は、すべてプライバシーに関する考慮事項に沿って行う必要があります。

悪意のあるエンティティの特定

上記の緩和策は、サーバー オークションの adSelectionData の生成を保護しますが、悪意のあるエンティティを特定する、または不正使用（購入者で構成される前例のない数のカスタム オーディエンスの作成など）からプラットフォームを保護するものではありません。

プラットフォームの安定性と健全性を確保するために、悪意のあるエンティティを特定するメカニズム、不正行為ベクトルを特定するメカニズム、特定の攻撃の動機を特定するメカニズムを見つける必要があります。今後のリリースでは、潜在的な不正行為ベクトルと、それらに対処するための対策に関する詳細な説明について紹介する予定です。