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

Protected Audience API を使ってカスタムオーディエンスターゲティングをサポートする

タイムライン

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

機能	デベロッパープレビューで利用可能	ベータ版で利用可能
イベントレベルのレポート	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 は、購入者の ID を fetchUri の eTLD+1CustomAudience 購入者の ID は次の処理に使用されます joinCustomAudience() による同じ登録とアプリの認証チェック取得レスポンスで変更することはできません。CustomAudience のオーナー: 呼び出し元のアプリのパッケージ名。eTLD+1 チェック以外に fetchUri の検証はありません。具体的には k-匿名性のチェックはありません。fetchAndJoinCustomAudience() API は、HTTP GET リクエストを発行します。 fetchUri であり、カスタムオーディエンスを表す 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 Audiences。

/**
* 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 に設定し、同じ購入者について、以前にリクエストされた更新が scheduleCustomAudienceUpdate への呼び出しを ScheduleCustomAudienceUpdateRequest は失敗します。デフォルトは 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-匿名性である必要はありませんが、制限は、1 つのプロジェクトに登録できるキーの数と長さに対する特定のカスタムオーディエンスを対象にできますreportEvent() が呼び出されると、それに対応するセルサイドプラットフォームがイベントレポートをいつでも受信できます。これらのレポートを受け取ることができるのは、落札したバイサイドプラットフォームのみです。

セルサイドレポート

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

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 は、最近実施されたオークションの AdSelectionId である必要があります AdSelectionOutcome から取得します。
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 機能を提供しています。この機能を使用すると、広告テクノロジーはさまざまなリマーケティング手法でアトリビューションのパフォーマンスを分析し、どのタイプのオーディエンスが最高の ROI を達成しているかを把握できます。

この 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 に登録するかを選択できます。リクエストすべてのイベントレポートに「Attribution-Reporting-Eligible」ヘッダーが追加される reportEvent() から送信されたリクエスト。適切な 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() をトリガーし、イベント単位のデータを渡す必要があります。プラットフォームから関連付けられた購入者の登録済み広告ビーコン URL トリガーされた reportEvent()。
購入者は、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 を使ってカスタム オーディエンス ターゲティングをサポートする

最近の更新

タイムライン

概要

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

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

カスタム オーディエンス

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

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

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

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

ユーザー コントロール