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

Protected Audience API を使ってカスタムオーディエンスターゲティングをサポートする
bookmark_border コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

タイムライン

今後数か月以内に新機能をリリースする予定です。正確なリリース日は機能によって異なり、この表はドキュメントが利用可能になり次第、ドキュメントへのリンクとともに更新されます。

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

概要

モバイル広告で一般的に広告主が必要とするのは、ユーザーが過去に広告主のアプリで行った操作に基づいて、興味を持ちそうなユーザーに広告が配信されることです。たとえば、SportingGoodsApp のデベロッパーは、ショッピングカートにアイテムが残っているユーザーに広告を表示して、購入手続きの完了を促そうとします。業界では、このような考え方を一般的に「リマーケティング」、「カスタムオーディエンスターゲティング」などの用語で表現します。

現在のところ、このようなユースケースは、広告の表示方法に関するコンテキスト情報（アプリ名など）やオーディエンスリストなどの個人情報を、広告テクノロジープラットフォームと共有して実装することが一般的です。このような情報を使用することで、広告主は自身のサーバー上で関連性の高い広告を選択できます。

Android 版 Protected Audience API（旧称 FLEDGE）には、広告テクノロジープラットフォームと広告主向けの以下の API が含まれ、一般的なインタラクションベースのユースケースを、アプリ間の識別子とユーザーによるアプリとのインタラクション情報の両方を第三者と共有することを制限しつつ、サポートします。

Custom Audience API: 広告主が指定する共通のインテントを持ったオーディエンスを表す「カスタムオーディエンス」の抽象化を主な役割としています。オーディエンス情報はデバイス上に保存され、オーディエンスに関わる広告候補や、入札シグナルなどの任意のメタデータと関連付けることができます。この情報は、広告主の入札、広告のフィルタリング、レンダリングに関する通知に使用できます。
Ad Selection API: デバイス上のシグナルを使用して、ローカルに保存されている広告候補を考慮し、広告テクノロジープラットフォームがデバイスに返す広告候補に追加の処理を実行することで、「落札」広告を決定する広告テクノロジープラットフォームのワークフローをオーケストレートするフレームワークを提供します。

Android 版プライバシーサンドボックスにおけるカスタムオーディエンス管理と広告選択のワークフローを示すフローチャート。

統合作業の概要は次のとおりです。

SportingGoodsApp は、ユーザーが 2 日以内に購入処理を完了しなかった場合、カートに残っている商品の購入を促します。SportingGoodsApp が、Custom Audience API を使用して、ユーザーを「商品がカートに入っている」オーディエンスリストに追加します。プラットフォームはこのオーディエンスリストをデバイス上で管理、保存し、第三者との共有を制限します。SportingGoodsApp は広告テクノロジープラットフォームと連携して、オーディエンスリストのユーザーに広告を表示します。広告テクノロジープラットフォームは、オーディエンスリストのメタデータを管理し、広告候補を提供します。これは広告選択ワークフローでの検討に使用できます。プラットフォームは、バックグラウンドでアップデートされたオーディエンスベース広告を定期的に取得するように構成できます。これによりオーディエンスベースの広告候補リストが最新の状態に保たれ、広告を出す機会が訪れた際に、第三者広告サーバーに送信されるリクエスト（コンテンツターゲット広告リクエスト）と相関しない状態に保たれます。
ユーザーが FrisbeeGame をプレイすると、同じデバイス上にある SportingGoodsApp のショッピングカートに残るアイテムの購入処理を促す広告が表示される場合があります。これを行うには、FrisbeeGame（統合広告 SDK を使用）で Ad Selection API を呼び出し、ユーザーが属している可能性のあるオーディエンスリスト（この例では SportingGoodsApp が作成した「商品がカートに入っている」カスタムオーディエンスリスト）に基づいて落札広告を選択します。広告選択ワークフローは、広告テクノロジープラットフォームのサーバーから取得した広告に加え、カスタムオーディエンスや他のデバイス上のシグナルに関連付けられたデバイス上の広告を考慮するように設定できます。このワークフローは、カスタム入札とスコアリングロジックを使用して、広告テクノロジープラットフォームと広告 SDK がカスタマイズし、適切な広告掲載の目標を達成するようにすることもできます。このアプローチでは、ユーザーの興味またはアプリ操作データを広告の選択に反映させつつ、第三者とのこのようなデータの共有を制限できます。
広告配信アプリまたは広告テクノロジープラットフォームの SDK が、選択された広告をレンダリングします。
プラットフォームにより、インプレッションと広告選択結果のレポートが容易になります。このレポート機能は Attribution Reporting API を補完するものです。広告テクノロジープラットフォームはレポートのニーズに応じてカスタマイズできます。

Android 版 Protected Audience API にアクセスする

広告テクノロジープラットフォームが Protected Audience API にアクセスするには登録が必要です。詳しくは、プライバシーサンドボックスアカウントの登録をご覧ください。

カスタムオーディエンス管理

カスタムオーディエンス

カスタムオーディエンスとは、共通の意図または興味に基づき広告主が特定したユーザーのグループを表します。アプリまたは SDK はカスタムオーディエンスを使用して、特定のオーディエンス（「ショッピングカートにアイテムが残っているユーザー」、ゲームの「初級レベルをクリアしたユーザー」など）を指定できます。プラットフォームは、デバイス上でオーディエンス情報をローカルに保持して保存します。ユーザーがどのカスタムオーディエンスに属するかは表示されません。カスタムオーディエンスは、Chrome の Protected Audience のインタレストグループとは異なり、ウェブやアプリ間で共有することはできません。こうすることにより、ユーザー情報の共有を制限できます。

広告主アプリまたは統合 SDK は、アプリでのユーザーエンゲージメントなどに基づいて、カスタムオーディエンスへの参加、またはカスタムオーディエンスからの脱退を選択できます。

カスタムオーディエンスメタデータ

カスタムオーディエンスには次のメタデータが含まれます。

オーナー: オーナーアプリのパッケージ名。暗黙的に、呼び出し元アプリのパッケージ名に設定されます。
購入者: このカスタムオーディエンスの広告を管理する購入者の広告ネットワーク。また購入者は、カスタムオーディエンスにアクセスし、関連する広告情報を取得する当事者を表します。購入者は eTLD+1 形式で指定されます。
名前: カスタムオーディエンスの任意の名前または識別子（「ショッピングカートを放棄した」ユーザーなど）。この属性は、たとえば、広告主の広告キャンペーンにおけるターゲティング条件の一つとして、または入札コードを取得するための URL のクエリ文字列として使用できます。
有効化時刻と有効期限: これらのフィールドでは、カスタムオーディエンスが有効になる期間を定義します。プラットフォームはこの情報を使用して、カスタムオーディエンスのメンバーシップを取り消します。有効期限は、カスタムオーディエンスの存続期間を制限する最大期間を超えることはできません。
日次更新 URL: 「ユーザー入札シグナル」フィールドで定義された広告候補またはその他のメタデータを、プラットフォームが定期的に取得するために使用する URL。詳細については、カスタムオーディエンスの広告候補を取得する方法についてのセクションをご覧ください。
ユーザー入札シグナル: リマーケティング広告の入札のための、広告テクノロジープラットフォーム固有のシグナル。シグナルの例としては、ユーザーの大まかな位置情報、優先する言語 / 地域などがあります。
信頼できる入札データ: 広告テクノロジープラットフォームは、リアルタイムデータに基づいて広告の取得とスコアリングについて通知します。たとえば、ある広告が予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイムデータを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理するサーバーが、広告テクノロジープラットフォームが管理する信頼できるサーバーになります。
入札ロジック URL: デマンドサイドプラットフォームから入札コードを取得するためにプラットフォームが使用する URL。広告オークションが開始されると、このステップが実施されます。
広告: カスタムオーディエンスの広告候補のリスト。これには、広告テクノロジープラットフォーム固有の広告メタデータと、広告をレンダリングするための URL が含まれます。カスタムオーディエンス向けにオークションが開始されると、この広告メタデータのリストが考慮されます。この広告のリストは、可能な場合は日次更新 URL エンドポイントを使用してアップデートされます。モバイルデバイスではリソースの制約があるため、カスタムオーディエンスに保存できる広告の数には制限があります。

カスタムオーディエンス委任

従来のカスタムオーディエンスの定義と構成は、通常、広告テクノロジーが代理店、広告主クライアント、パートナーと連携して主導するサーバーサイドの技術と統合に依存しています。Protected Audience API は、カスタムオーディエンスの定義と構成を、ユーザーのプライバシーを保護しつつ可能にします。カスタムオーディエンスに参加するには、アプリに SDK がない購入者の広告テクノロジーが、モバイル測定パートナー（MMP）やサプライサイドプラットフォーム（SSP）などのデバイス上のプレゼンスがある広告テクノロジーと連携する必要があります。Protected Audience API は、購入者に代わってカスタムオーディエンスの作成をデバイス上で呼び出せるようにして、柔軟性のあるカスタムオーディエンス管理のソリューションを提供し、このような SDK をサポートすることを目指しています。このプロセスはカスタムオーディエンス委任と呼ばれます。カスタムオーディエンス委任を設定する手順は以下のとおりです。

カスタムオーディエンスに参加する

カスタムオーディエンスへの登録は、次の 2 つの方法でできます。

joinCustomAudience()

アプリまたは SDK は、想定されるパラメータで CustomAudience オブジェクトをインスタンス化した後に joinCustomAudience() を呼び出すことで、カスタムオーディエンスへの参加をリクエストできます。次にコードスニペットの例を示します。

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

アプリまたは SDK は、想定されるパラメータで fetchAndJoinCustomAudience() を呼び出し、デバイス上のプレゼンスがない広告テクノロジーに代わって、カスタムオーディエンスへの参加をリクエストできます。例は以下のとおりです。

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

購入者が所有する URL エンドポイントは、レスポンスの本文で CustomAudience JSON オブジェクトを返します。カスタムオーディエンスの購入者とオーナーのフィールドは無視されます（API によって自動入力されます）。また、この API は日次更新 URL が購入者の eTLD+1 にも一致するようにします。

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchAndJoinCustomAudience() API は fetchUri の eTLD+1 から購入者の ID を特定します。CustomAudience 購入者の ID は、joinCustomAudience() によって行われる同じ登録とアプリの認証チェックに使用されます。取得レスポンスによって変更することはできません。CustomAudience オーナーは、呼び出し元アプリのパッケージ名です。eTLD+1 チェック以外に fetchUri の検証はありません。具体的には k-匿名性のチェックはありません。fetchAndJoinCustomAudience() API は fetchUri に対して HTTP GET リクエストを実行し、カスタムオーディエンスを表す JSON オブジェクトを想定します。レスポンスには、カスタムオーディエンスオブジェクトフィールドと同じ必須項目、オプションの制約とデフォルト値が適用されます。現在の要件と制限事項については、デベロッパーガイドをご覧ください。

購入者から HTTP エラーが返されると、fetchAndJoinCustomAudience でエラーが発生します。特に、HTTP ステータスレスポンスが 429（リクエストが多すぎる）の場合、現在のアプリからのリクエストが設定される期間ブロックされます。購入者からのレスポンスの形式が正しくない場合も、API 呼び出しは失敗します。エラーは API 呼び出し元に報告され、API 呼び出し元が一時的な障害（サーバーが応答していないなど）が発生した場合に再試行し、永続的な障害（データ検証のエラー、その他のサーバーとの通信における一時的でない障害など）に対応する責任があります。

CustomAudienceFetchRequest オブジェクトを使用して、API 呼び出し元は上記の例で示すオプションのプロパティを使用してカスタムオーディエンスの情報を指定できます。リクエストで設定された値は、プラットフォームが受け取った購入者レスポンスによって上書きされません。Protected Audience API は、レスポンスのフィールドを無視します。これらのフィールドはカスタムオーディエンスの作成に必要であるため、リクエストで設定されていない場合はレスポンスで設定する必要があります。API 呼び出し元によって一部指定された CustomAudience のコンテンツの JSON 表現は、特別なヘッダー X-CUSTOM-AUDIENCE-DATA の fetchUri への GET リクエストに含まれます。カスタムオーディエンスで指定するデータのシリアル化された形式のサイズの上限は 8 KB です。サイズが超過すると、fetchAndJoinCustomAudience API 呼び出しは失敗します。

k-匿名性のチェックがないため、購入者の検証に fetchUri を使用して、購入者と SDK との間で情報共有ができます。カスタムオーディエンスの検証を容易にするため、購入者は確認トークンを提示できます。デバイス上の SDK では、このトークンを fetchUri に含めて、購入者がホストするエンドポイントがカスタムオーディエンスのコンテンツを取得し、確認トークンを使用して fetchAndJoinCustomAudience() オペレーションが購入者に対応しており、信頼できるデバイス上のパートナーからであることを検証できるようにする必要があります。情報共有のために、購入者はカスタムオーディエンスの作成に使用される情報の一部がクエリパラメータとして fetchUri に追加されることを、デバイス上の呼び出し元と合意できます。これにより、購入者はその呼び出しを監査し、悪意のある広告テクノロジーで確認トークンが使用された場合に検知し、複数のカスタムオーディエンスを作成できます。

確認トークンの定義と保存に関する注意事項

確認トークンは Protected Audience API の目的では使用されず、オプションです。
- 確認トークンは購入者が作成されているオーディエンスが購入者の代わりに実行されていることを確認するために使用します。
- Protected Audience API プロポーザルでは、確認トークンの形式や、購入者が確認トークンを呼び出し元に転送する方法は指定していません。たとえば、確認トークンをオーナーの SDK またはバックエンドに事前に読み込むことも、オーナーの SDK が購入者のサーバーからリアルタイムで取得することもできます。

カスタムオーディエンスから脱退する

カスタムオーディエンスのオーナーは、次のコードスニペットに示すように、leaveCustomAudience() を呼び出して脱退することもできます。

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

カスタムオーディエンスは、ストレージやその他のデバイスリソースの使用量を節約するために、所定の期間が経過すると期限切れとなり、デバイス上のストアから削除されます。デフォルト値は未定です。オーナーはこのデフォルト値をオーバーライドできます。

ユーザーコントロール

このプロポーザルは、カスタムオーディエンスを 1 つ以上作成したインストール済みのアプリのリストをユーザーが確認できるようにすることを目的としています。
ユーザーはこのリストからアプリを削除できます。削除すると、アプリに関連付けられているカスタムオーディエンスがすべて消去され、アプリが新しいカスタムオーディエンスに参加できなくなります。
ユーザーは Protected Audience API を完全にリセットできます。リセットした場合、デバイス上の既存のカスタムオーディエンスはすべて消去されます。
ユーザーは Protected Audience API を含む Android 版プライバシーサンドボックスから完全にオプトアウトできます。ユーザーがプライバシーサンドボックスをオプトアウトしている場合、Protected Audience API はサイレントで失敗します。

この機能の設計は現在進行中であり、詳細については今後のアップデートに反映される予定です。

スケジュール設定された更新

前述のソリューションでは、アプリまたは広告テクノロジー SDK が、アプリがフォアグラウンドにあるときに API を呼び出し、カスタムオーディエンスのすべてのプロパティを直接または委任を使用して提供する必要があります。ただし、広告主と広告テクノロジープロバイダが、ユーザーがアプリを使用しているときに、ユーザーがどのオーディエンスに属しているかをリアルタイムで定義できるとは限りません。

これを容易にするために、広告テクノロジーが scheduleCustomAudienceUpdate() API を呼び出すことができます。この API を使用すると、呼び出し元は API 呼び出しを行うタイミングの遅延を指定できます。これにより、応答する広告テクノロジーがアプリレベルのイベントを処理し、ユーザーが参加または削除する Protected Audience を決定する時間を確保できます。

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest には、プラットフォームで実行する遅延ジョブを登録するために必要な情報が含まれています。指定した遅延時間の経過後に、バックグラウンドジョブが定期的に実行され、リクエストが送信されます。ScheduleCustomAudienceUpdateRequest には次の情報を含めることができます。

UpdateUri: 更新を取得するために GET 呼び出しが送信される URI エンドポイント。購入者の ID は eTLD+1 から推測されるため、明示的に指定する必要はなく、更新レスポンスで変更することもできません。GET リクエストは、返される customAudience オブジェクトのリストを含む JSON オブジェクトを想定しています。
DelayTime: scheduleCustomAudienceUpdate() API 呼び出しから更新のスケジュール設定までの遅延時間を表す時間。

PartialCustomAudience: この API を使用すると、オンデバイス SDK は部分的に作成されたカスタムオーディエンスのリストを送信することもできます。これにより、アプリ内 SDK は、DSP とのパートナーシップに基づいて、カスタムオーディエンスの管理を完全に制御することも部分的に制御することもできるようになります。
- また、この API は、同様の情報共有を可能にする fetchAndJoinCustomAudience() API との互換性も維持しています。
ShouldReplacePendingUpdates: 保留中のスケジュール設定された更新をキャンセルして、現在の ScheduleCustomAudienceUpdateRequest に詳細が記載されている更新に置き換えるかどうかを決定するブール値。これが false に設定され、同じアプリで同じ購入者に対して以前にリクエストされた更新が保留中である場合、この ScheduleCustomAudienceUpdateRequest を使用して scheduleCustomAudienceUpdate を呼び出すと失敗します。デフォルトは false です。

アプリの権限とコントロール

このプロポーザルは、アプリがカスタムオーディエンスを管理できるようにすることを目的としています。

アプリはカスタムオーディエンスとの関連付けを管理できます。
アプリは、第三者の広告テクノロジープラットフォームに、アプリに代わってカスタムオーディエンスの管理権限を付与できます。

この機能の設計は現在実施中であり、詳細については今後のアップデートに反映される予定です。

広告テクノロジープラットフォームによるコントロール

このプロポーザルでは、広告テクノロジーがカスタムオーディエンスをコントロールする方法の概要を説明します。

広告テクノロジーはプライバシーサンドボックスに登録し、カスタムオーディエンスのすべての URL と一致する eTLD+1 ドメインを指定します。
広告テクノロジーはアプリまたは SDK と連携し、確認トークンを使ってカスタムオーディエンスの作成を検証できます。このプロセスがパートナーに委任する場合、カスタムオーディエンスの作成において、広告テクノロジーによる承認を必須とするよう設定できます。
広告テクノロジーに代わって joinCustomAudience の呼び出しを無効にし、fetchAndJoinCustomAudience API のみすべての呼び出しカスタムオーディエンスの有効化ができるようにすることもできます。コントロールはプライバシーサンドボックスの登録時に更新できます。コントロールではすべての広告テクノロジーを許可するか、一切許可しないかを選択できます。プラットフォームの制限により、委任権限を広告テクノロジーごとに指定することはできません。

広告候補とメタデータのレスポンス

バイサイドプラットフォームから返される広告候補とメタデータには、次のフィールドが含まれている必要があります。

メタデータ: バイサイドの広告テクノロジー固有の広告メタデータ。たとえば、広告キャンペーンに関する情報や、地域や言語などのターゲティング条件が含まれる場合があります。
レンダリング URL: 広告クリエイティブをレンダリングするためのエンドポイント。
フィルタ: Protected Audience がデバイス上のデータに基づいて広告をフィルタするために必要なオプションの情報。詳細はバイサイドフィルタリングロジックのセクションをご覧ください。

広告選択ワークフロー

このプロポーザルでは、広告テクノロジープラットフォームのオークションの実施を調整する Ad Selection API を導入することで、プライバシーを向上させることを目的としています。

現在の広告テクノロジープラットフォームは、入札と広告の選択を自社サーバーのみで行うことが一般的です。このプロポーザルでは、カスタムオーディエンスやプライベートなユーザーシグナル（利用可能なインストール済みのパッケージ情報など）に対して Ad Selection API 経由でのみアクセスできます。さらに、リマーケティングのユースケースでは、広告候補が範囲外（広告が表示されるコンテキスト以外）で取得されます。広告テクノロジープラットフォームは、現在のオークションと広告選択ロジックの一部をデバイスにデプロイして実行できるように準備する必要があります。広告テクノロジープラットフォームは、広告選択ワークフローに対し次の変更を検討できます。

インストール済みパッケージ情報がサーバーで利用できない場合、広告テクノロジープラットフォームは、複数のコンテンツターゲット広告をデバイスに送り返し、関連性の高い広告が表示される可能性を最大化するために、広告選択ワークフローを呼び出してアプリのインストールベースのフィルタリングを有効にします。
リマーケティング広告は範囲外で取得されるため、現在の入札モデルをアップデートする必要が生じる場合があります。広告テクノロジープラットフォームは、広告機能とコンテキストシグナルを別々に扱い、デバイス上でサブモデルの出力を組み合わせて入札を予測できる、入札サブモデルを作成できます（実装はツータワーモデルというパターンに基づくことがあります）。これにより、サーバーサイドオークションと、任意の広告配信機会のオークションの両方にメリットが生じます。

このアプローチでは、ユーザーのアプリ操作データを広告の選択に利用しつつ、第三者とのデータ共有を制限できます。

この広告選択ワークフローは、以下の順に沿って、広告テクノロジーが提供する JavaScript コードのデバイス上における実行を調整します。

バイサイド入札ロジックの実行
バイサイドの広告フィルタリングと処理
セルサイド判断ロジックの実行

カスタムオーディエンスが関係する広告選択の場合、プラットフォームは、カスタムオーディエンスの「入札ロジック URL」メタデータで定義された公開 URL エンドポイントに基づいて、バイサイドによって提供される JavaScript コードを取得します。セルサイド判断コードの URL エンドポイントも、広告選択ワークフローを開始するための入力として渡されます。

カスタムオーディエンスが関係しない広告選択については、現在設計中です。

広告選択ワークフローを開始する

アプリで広告を表示する必要がある場合、広告テクノロジープラットフォーム SDK は、想定されるパラメータを指定して AdSelectionConfig オブジェクトをインスタンス化した後、selectAds() メソッドを呼び出して広告選択ワークフローを開始します。

販売者: eTLD+1 形式のセルサイド広告プラットフォームの識別子。
判断ロジック URL: 広告オークションが開始されると、プラットフォームはこの URL を使用してセルサイドプラットフォームから JavaScript コードを取得し、落札広告を評価します。
カスタムオーディエンス購入者: このオークションについてカスタムオーディエンスに基づく需要があるバイサイドプラットフォームのリスト（eTLD+1 形式）。
広告選択シグナル: オークションに関する情報（広告サイズ、広告フォーマットなど）。
販売者シグナル: サプライサイドプラットフォーム固有のシグナル。
信頼できるスコアリングシグナル URL: クリエイティブ固有のリアルタイム情報を取得できる、セルサイドの信頼できるシグナルの URL エンドポイント。
購入者ごとのシグナル: 参加しているデマンドサイドは、このパラメータを使用してオークションのための入力を提供できます。たとえば、このパラメータに、入札単価の決定に役立つ包括的なコンテキスト情報を含めることができます。

次のコードスニペットに、広告テクノロジープラットフォーム SDK が広告選択ワークフローを開始する例を示します。まず AdSelectionConfig を定義してから、selectAds を呼び出して落札広告を取得しています。

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

バイサイド入札ロジック

通常、入札ロジックはバイサイドプラットフォームが提供します。このコードの目的は、広告候補の入札単価を決定することです。結果を判断するために、追加のビジネスロジックが適用される場合があります。

プラットフォームは、カスタムオーディエンスの「入札ロジック URL」メタデータを使用して、次の関数シグネチャを含む JavaScript コードを取得します。

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

generateBid() メソッドは、算出された入札単価を返します。プラットフォームは、すべての広告（コンテンツターゲット広告またはリマーケティング広告）に対してこの関数を順次呼び出します。入札ロジックのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。

関数には次のパラメータが必要です。

広告: バイサイド入札コードで検討される広告。対象となるカスタムオーディエンスからの広告です。
オークションシグナル: セルサイドのプラットフォーム固有のシグナル。
購入者ごとのシグナル: 参加しているデマンドサイドは、このパラメータを使用してオークションのための入力を提供できます。たとえば、このパラメータに、入札単価の決定に役立つ包括的なコンテキスト情報を含めることができます。
信頼できる入札シグナル: 広告テクノロジープラットフォームは、リアルタイムデータに基づいて広告の取得とスコアリングについて通知します。たとえば、ある広告キャンペーンが予算を使い果たし、すぐに配信を停止する必要が生じることがあります。広告テクノロジーは、このリアルタイムデータを取得できる URL エンドポイントと、リアルタイム検索を行う必要があるキーのセットを定義できます。このリクエストを処理する広告テクノロジープラットフォームが管理するサーバーが、広告テクノロジープラットフォームが管理する信頼できるサーバーになります。
コンテキストシグナル: おおまかなタイムスタンプやおおよその位置情報、広告のクリック単価などが含まれることがあります。
ユーザーシグナル: 利用可能なインストール済みパッケージ情報などの情報が含まれることがあります。

広告費用

バイサイドプラットフォームは、入札単価に加えて、generateBid() の一部としてクリック単価を返すことができます。次に例を示します。

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

この広告が落札した場合、プライバシー保護のため、adCost は 8 ビットに確率的丸めされます。インプレッションレポートの処理中に、adCost の丸められた値が reportWin の contextual_signals パラメータに渡されます。

バイサイドフィルタリングロジック

バイサイドプラットフォームは、広告選択フェーズで利用できる、デバイス上の追加のシグナルに基づいて広告をフィルタできるようになります。たとえば、広告テクノロジープラットフォームは、ここでフリークエンシーキャップ機能を実装できます。フィルタリングのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。

バイサイドフィルタリングロジックは、入札ロジックの一部として、特定の広告の入札単価 0 を返す形で実装できます。

さらに、バイサイドプラットフォームは Protected Audience で利用できる、デバイス上の追加のシグナルに基づいて特定の広告をフィルタする必要があるということを通知できます。デバイスを離れることはありません。追加のフィルタリングロジックの設計が固まれば、バイサイドプラットフォームは同じ構造に従って、フィルタリングが行われることを通知します。

セルサイドスコアリングロジック

通常、スコアリングロジックはセルサイドプラットフォームが提供します。このコードの目的は、入札ロジックの出力に基づいて落札広告を決定することです。結果を判断するために、追加のビジネスロジックが適用される場合があります。判断ロジックのプロバイダが複数ある場合、プロバイダ間の実行順序は保証されません。プラットフォームは、selectAds() API の「判断ロジック URL」入力パラメータを使用して、次の関数シグネチャを含む JavaScript コードを取得します。

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

関数には次のパラメータが必要です。

広告: 評価する広告。generateBid() 関数の出力。
入札単価: generateBid() 関数から出力される入札単価。
オークション設定: selectAds() メソッドへの入力パラメータ。
信頼できるスコアリングシグナル: 広告テクノロジープラットフォームは、リアルタイムデータに基づいて広告のフィルタリングとスコアリングについて通知します。たとえば、アプリのパブリッシャーは、アプリで広告を表示しないように広告キャンペーンをブロックすることがあります。このデータは、オークション設定の信頼できるスコアリングシグナル URL パラメータから取得されます。このリクエストを処理するサーバーは、広告テクノロジーが管理する信頼できるサーバーである必要があります。
コンテキストシグナル: おおまかなタイムスタンプやおおよその位置情報が含まれることがあります。
ユーザーシグナル: アプリのインストールを開始したアプリストアなどの情報が含まれることがあります。
カスタムオーディエンスシグナル: スコアリングする広告がデバイス上のカスタムオーディエンスからのものである場合は、カスタムオーディエンスのリーダーや名前などの情報が含まれます。

広告選択コードランタイム

このプロポーザルでは、広告テクノロジープラットフォームが提供するオークションコードが、設定可能な URL エンドポイントから取得され、デバイスで実行されます。モバイルデバイスのリソース制約を考慮して、オークションコードは以下のガイドラインを遵守する必要があります。

コードは、事前に定義した時間内に実行を終了する必要があります。この制限は、すべての購入者広告ネットワークに対して一律に適用されます。この制限の詳細については、今後のアップデートで共有される予定です。
コードは自己完結している必要があり、外部との依存関係があってはなりません。

入札ロジックなどのオークションコードは、アプリのインストール元などの非公開のユーザーデータにアクセスする必要が生じる場合があるため、ランタイムはネットワークやストレージへのアクセスを提供しません。

プログラミング言語

広告テクノロジープラットフォームが提供するオークションコードは、JavaScript で記述する必要があります。これにより、たとえば広告テクノロジープラットフォームは、プライバシーサンドボックスをサポートするプラットフォーム間で入札コードを共有できます。

落札広告のレンダリング

スコアが最も高い広告がオークションの落札者と見なされます。この最初のプロポーザルでは、落札広告が SDK に渡され、レンダリングされます。

今後はソリューションを進化させて、ユーザーのカスタムオーディエンスメンバーシップに関する情報やアプリの操作履歴を、落札広告に関する情報を通じてアプリまたは SDK から判断できないようにする予定です（Chrome の Fenced Frames のプロポーザルと同様）。

インプレッションとイベントのレポート

広告がレンダリングされると、落札インプレッションは、参加しているバイサイドとセルサイドのプラットフォームにレポートされます。これにより、購入者と販売者は、入札単価やカスタムオーディエンス名などのオークション情報を落札インプレッションレポートに含めることができます。また、落札広告に関するイベントレベルの追加レポートを、落札したセルサイドプラットフォームと購入側プラットフォームが受け取ることができます。これにより、オークションに関する情報（入札単価、カスタムオーディエンス名など）を、クリック、視聴回数、その他の広告イベントに含めることができます。プラットフォームは、レポートロジックを次の順序で呼び出します。

セルサイドレポート
バイサイドレポート

これにより、バイサイドとセルサイドのプラットフォームは、デバイス上の重要な情報をサーバーに送信し、リアルタイムの予算設定、入札モデルのアップデート、正確な支払いワークフローなどの機能を実現できます。このインプレッションレポートのサポートは Attribution Reporting API を補完するものです。

イベントレポートをサポートするには、2 つのステップが必要です。セルサイドと購入側の JavaScript で、イベントレポートを受信するイベントを登録する必要があります。イベントレベルの情報のレポートはセルサイドが行います。

Protected Audience には、ビーコンを登録して、落札したオークションに関連する今後のイベントを定期購入するメカニズムが用意されています。販売者の reportResult() JavaScript 関数で、販売側のプラットフォームはプラットフォームの registerAdBeacon() 関数を使用してビーコンを登録できます。同様に、バイサイドプラットフォームは reportWin() JavaScript 関数から registerAdBeacon() メソッドを呼び出すことができます。

registerAdBeacon(beacons)

入力:

event_key: 登録するインタラクションタイプを示す文字列。これは、オークションの結果を報告する際にプラットフォームが ping するエンドポイントを検索するためのキーとして使用されます。
reporting_url: イベントを処理する広告テクノロジープラットフォームが所有する URL。

イベントキーは、オークションの結果を報告するセルサイド SDK が所有する文字列識別子です。コールバックを実行するには、広告テクノロジーが、イベントのレポート時にセルサイドで使用されるキーと一致するキーを使用してビーコンを登録します。これらのキーは k-匿名である必要はありませんが、特定のカスタムオーディエンスに登録できるキーの数と長さには上限があります。reportEvent() が呼び出されると、オークションを実施したセルサイドプラットフォームは常にこれらのイベントレポートを受信できます。これらのレポートを受け取ることができるのは、落札したバイサイドプラットフォームのみです。

セルサイドレポート

プラットフォームは、selectAds() API の販売者の判断ロジック URL パラメータからダウンロードしたサプライサイド提供のコードで、reportResult() JavaScript 関数を呼び出します。

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

出力: 次を含む JSON オブジェクト。

ステータス: 成功の場合は 0、失敗の場合はその他の値。
レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。
購入者向けシグナル: 購入者の reportWin 関数に渡される JSON オブジェクト。

サプライサイドは、レポート URL で関連性の高いシグナルをエンコードすることで、オークションや落札広告についてさらに詳しい分析情報を得ることができます。たとえば、次のようなシグナルが該当します。

広告レンダリング URL
落札単価
アプリ名
クエリ識別子
購入者向けシグナル: サプライサイドとデマンドサイドでのデータ共有をサポートするために、プラットフォームはこの戻り値を入力パラメータとしてデマンドサイドレポートコードに渡します。

バイサイドレポート

プラットフォームは、オークションに関連付けられたカスタムオーディエンスの入札ロジック URL メタデータからダウンロードしたデマンドサイド提供のコードで、reportWin() JavaScript 関数を呼び出します。

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

入力:

auction_signals と per_buyer_signals は AuctionConfig から取得されます。バイサイドプラットフォームがレポート URL に渡す必要がある情報は、このデータから取得される可能性があります。
signals_for_buyer は、セルサイドの reportResult の出力です。これにより、セルサイドプラットフォームはレポートのためにバイサイドプラットフォームとデータを共有できます。
contextual_signals にはアプリ名などの情報が含まれ、custom_audience_signals にはカスタムオーディエンス情報が含まれます。今後、その他の情報が追加される可能性があります。

出力:

ステータス: 成功の場合は 0、失敗の場合はその他の値。
レポート URL: プラットフォームは、関数から返されたこの URL を呼び出します。

イベントの報告

イベントのレポートは、オークションのインプレッションレポートの完了後にのみ可能です。イベントのレポートはセルサイド SDK が行います。プラットフォームは、最近行われたオークション、報告されるイベントキー、そのキーに関連付けられたデータ、レポートを買い手または売り手（または両方）に送信するかどうか、および広告イベントのオプションの入力イベントを指定する ReportEventRequest を受け取る API を公開します。クライアントは、イベントキーとレポートするデータのコレクションを定義します。

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

入力:

ad_selection_id は、AdSelectionOutcome から取得した最近行われたオークションの AdSelectionId である必要があります。
event_key は、インタラクションイベントを記述するセルサイド定義の文字列です。
event_data は、event_key に関連付けられたデータを表す文字列です。
reporting_destinations は、プラットフォームから提供されるフラグを使用して設定されるビットマスクです。FLAG_REPORTING_DESTINATION_SELLER または FLAG_REPORTING_DESTINATION_BUYER のいずれか、またはその両方を使用できます。
input_event（省略可）は、Attribution Reporting API との統合に使用されます。InputEvent オブジェクト（クリックイベントの場合）または null（ビューイベントの場合）です。このパラメータの詳細については、Attribution Reporting API の統合をご覧ください。

セルサイド SDK が reportEvent を呼び出した後、reporting_destinations フラグに応じて、プラットフォームは event_key を、購入者と販売者が reportWin と reportResult JavaScript 関数で登録したキーと照合しようとします。一致すると、プラットフォームは event_data を関連する reporting_url に POST します。リクエストのコンテンツタイプはプレーンテキストで、本文は event_data です。このリクエストはベストエフォートとして行われ、ネットワークエラー、サーバーエラーレスポンス、一致するキーが見つからない場合、サイレントで失敗します。

Attribution Reporting API の統合

Protected Audience オークションに参加する購入者をサポートするため、Protected Audience API と Attribution Reporting API（ARA）にクロス API 機能を提供しています。この機能により、広告テクノロジーはさまざまなリマーケティング戦術の貢献度を評価し、広告費用対効果が最も高いオーディエンスのタイプを把握できます。

このクロス API 統合により、アドテックは次のことができます。

1）広告インタラクションレポートと 2）ソース登録の両方に使用される URI の Key-Value マップを作成します。
集計サマリーレポート用に、Protected Audience オークションのオークションデータをソースサイドのキーマッピングに含めます（Attribution Reporting API を使用）。詳細については、ARA 設計案をご覧ください。

ユーザーが広告を閲覧またはクリックしたとき:

Protected Audience を使用してこれらのイベントインタラクションをレポートするために使用される URL は、Attribution Reporting API で有効なソースとして視聴回数またはクリックを登録するために必要なデータを購入者に提供します。
広告テクノロジーは、その URL を使用して CustomAudience（または広告プレースメントや視聴時間など、広告に関するその他の関連コンテキスト情報）を渡すことができます。これにより、広告テクノロジーがキャンペーンの総合的なパフォーマンスを確認する際に、このメタデータが概要レポートに反映されます。

ソースの登録を有効にする

reportEvent() は、新しいオプションパラメータ InputEvent を受け入れます。広告ビーコンを登録した落札した購入者は、どの reportEvent レポートを登録済みソースとして Attribution Reporting API に登録するかを選択できます。reportEvent() から送信されるすべてのイベントレポートリクエストに、リクエストヘッダー Attribution-Reporting-Eligible が追加されます。適切な ARA ヘッダーを含むレスポンスは、他の通常の ARA ソース登録レスポンスと同じ方法で解析されます。ソース URL を登録する方法については、Attribution Reporting API の説明をご覧ください。

Android の ARA はビューイベントとクリックイベントをサポートしているため、InputEvents を使用して 2 つのタイプを区別します。ARA ソースの登録と同様に、reportEvent() API はプラットフォームで検証された InputEvent をクリックイベントとして解釈します。InputEvent がない場合、null の場合、または無効な場合、ソース登録はビューと見なされます。

オークション後の eventData には機密情報が含まれている可能性があるため、プラットフォームはリダイレクトされたソース登録リクエストの eventData を破棄します。

エンゲージメントとコンバージョンのレポートの例

この例では、オークション、レンダリングされた広告、コンバージョンアプリのデータの関連付けに関心を持つ購入者の視点から説明します。

このワークフローでは、購入者は販売者と連携して、オークションに一意の ID を送信します。オークション中に、購入者はこの一意の ID をオークションデータとともに送信します。レンダリング時とコンバージョン発生時に、レンダリングされた広告のデータも同じ一意の ID で送信されます。後で、一意の ID を使用してこれらのレポートを関連付けることができます。

ワークフロー: 購入者は、オークションの開始前に、プログラマティックリアルタイム入札（「RTB」）入札レスポンスの一部として一意の ID を販売者に送信します。ID は auctionId などの変数として設定できます。ID は auctionConfig で perBuyerSignals として渡され、購入者の入札ロジックで使用できるようになります。

reportWin の実行中に、広告のレンダリング時と特定のインタラクションイベント（registerAdBeacon()）でトリガーされる広告ビーコンを登録できます。広告イベントのオークションシグナルを関連付けるには、ビーコン URL のクエリパラメータとして auctionId を設定します。
広告のレンダリング時に、オークション時に登録したビーコンをトリガーしたり、イベント単位のデータで拡張したりできます。販売者は reportEvent() をトリガーし、イベント単位のデータを渡す必要があります。プラットフォームは、トリガーされた reportEvent() に関連する、購入者の登録済み広告ビーコン URL に ping を送信します。
購入者は、Attribution-Reporting-Register-Source ヘッダーを使用して広告ビーコンリクエストに応答することで、Attribution Reporting API に広告を登録します。コンバージョンイベントのオークションシグナルを関連付けるには、登録ソース URL に auctionId を設定します。

上記のプロセスが完了すると、購入者はオークションレポート、インタラクションレポート、コンバージョンレポートを入手できます。これらのレポートは、相互に関連付けることができる一意の ID を使用して相関付けることができます。

アトリビューションデータにアクセスする必要がある販売者にも同様のワークフローが適用されます。販売者は、一意の ID を使用して registerAdBeacon() で送信することもできます。reportEvent() 呼び出しには、購入者と販売者の両方にレポートを送信するために使用できる宛先プロパティが含まれています。

広告テクノロジープラットフォームが管理する信頼できるサーバー

現在の広告選択ロジックでは、オークション向けに広告候補を選択するかどうかを判断するために、予算の枯渇状況など、リアルタイムの情報が必要です。バイサイドとセルサイドのプラットフォームはいずれも、自社の運用するサーバーからこの情報を取得できます。これらのサーバーを経由した機密情報の漏洩を最小限に抑えるために、このプロポーザルでは以下の制限を求めています。

これらのサーバーの動作（このセクションで後述）によってユーザー情報が漏洩しない。
サーバーが、参照するデータに基づいて仮名化されたプロファイルを作成しない（つまり「信頼できる」必要がある）。

バイサイド: バイサイドがバイサイド入札ロジックを開始すると、プラットフォームは、信頼できるサーバーから信頼できる入札データの HTTP 取得を行います。URL は、処理されるカスタムオーディエンスの信頼できる入札シグナルのメタデータに存在する URL とキーを付加することで構成されます。この取得は、デバイス上のカスタムオーディエンスの広告を処理する場合にのみ行われます。この段階で、バイサイドによる予算の執行、キャンペーンの一時停止 / 一時停止解除状態の確認、ターゲティングの実施が可能となります。

カスタムオーディエンスからの信頼できる入札シグナルのメタデータに基づいて、信頼できる入札データを取得する URL の例を次に示します。

https://www.kv-server.example/getvalues?keys=key1,key2

サーバーからのレスポンスは、キーが key1 や key2 などであって、値を購入者の入札機能に利用できる JSON オブジェクトである必要があります。

セルサイド: 前述のバイサイドフローと同様に、セルサイドが、オークションで考慮されるクリエイティブについての情報取得を望む場合があります。たとえば、パブリッシャーは、ブランド保護の観点から、特定のクリエイティブがアプリに表示されないように強制したい場合があります。この情報を取得して、セルサイドオークションロジックで利用できるようにすることができます。バイサイドの信頼できるサーバーの検索と同様に、セルサイドの信頼できるサーバーの検索も HTTP 取得によって行われます。URL は、信頼できるスコアリングシグナル URL と、データを取得する必要があるクリエイティブのレンダリング URL を付加することで構成されます。

クリエイティブのレンダリング URL に基づいて、オークションで考慮するクリエイティブについての情報を取得する URL の例を次に示します。

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

サーバーからのレスポンスは、リクエストで送信されたレンダリング URL をキーとする JSON オブジェクトである必要があります。

これらのサーバーが信頼できる方法で動作することで、セキュリティとプライバシーに関して、次の利点をもたらします。

各キーに対するサーバーの戻り値がそのキーのみに基づいているということを信頼できる。
サーバーがイベントレベルのロギングを行わない。
サーバーに、これらのリクエストに基づくその他の副作用がない。

一時的なメカニズムとして、購入者と販売者は、自社で運営するサーバーを含め、どのサーバーからも入札シグナルを取得できます。ただし、リリースバージョンでは、信頼できる Key-Value 型サーバーにのみリクエストを送信します。

購入者と販売者は、Android 版プライバシーサンドボックスと互換性のあるプラットフォームとウェブ用に、共通の信頼できる Key-Value 型サーバーを使用できます。

Protected Audience API を使ってカスタム オーディエンス ターゲティングをサポートする bookmark_borderbookmark コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

最近の更新

タイムライン

概要

Android 版 Protected Audience API にアクセスする

カスタム オーディエンス管理

カスタム オーディエンス

カスタム オーディエンス メタデータ

カスタム オーディエンス委任

カスタム オーディエンスに参加する

カスタム オーディエンスから脱退する

ユーザー コントロール