このページは 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 四半期
Attribution Reporting の統合	なし	2023 年第 4 四半期
Open Bidding メディエーション	2023 年第 4 四半期	2023 年第 4 四半期
通貨の管理	2024 年第 1 四半期	2024 年第 2 四半期
k-匿名性の統合	なし	2024 年第 2 四半期
集計レポートの統合	2024 年第 3 四半期	2024 年第 4 四半期

概要

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

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

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 は、アプリでのユーザーエンゲージメントなどに基づいて、カスタムオーディエンスへのjoin、またはカスタムオーディエンスからの脱退を選択できます。

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

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

オーナー: オーナーアプリのパッケージ名。暗黙的に、呼び出し元アプリのパッケージ名に設定されます。
購入者: このカスタムオーディエンスの広告を管理する購入者の広告ネットワーク。また購入者は、カスタムオーディエンスにアクセスし、関連する広告情報を取得する当事者を表します。購入者は 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 呼び出し元に報告され、一時的な障害（サーバーが応答しないなど）による再試行や、永続的な障害（データ検証の失敗、サーバーとの通信に関するその他の非一時的なエラーなど）の処理を担当します。

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 delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

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

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

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

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

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

PartialCustomAudience: この API では、オンデバイス SDK から部分的に作成されたカスタムオーディエンスのリストを送信することもできます。これにより、アプリ内 SDK は DSP との連携に基づいて、カスタムオーディエンス管理を完全な制御から部分的な制御まで、2 つの役割を果たすことができます。
- また、この API と fetchAndJoinCustomAudience() API との互換性も維持されるため、同様の情報共有が可能になります。

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

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

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

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

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

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

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

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

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

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

広告選択ワークフロー

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

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

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

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

この広告選択ワークフローは、以下の順に沿って、広告テクノロジーが提供する 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}};
}

出力: 格納されたテキストを含む

ステータス: 成功の場合は 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 関数で登録したキーとのマッチングを試みます。一致する場合、プラットフォームは関連する reporting_url に event_data を POST します。リクエストのコンテンツタイプは書式なしテキストで、本文は event_data です。このリクエストはベストエフォートとして実行され、ネットワークエラーやサーバーエラーのレスポンスが発生した場合、または一致するキーが見つからなかった場合は、通知なく失敗します。

Attribution Reporting API の統合

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

この API 間の統合により、アドテックは次のことが可能になります。

1）広告インタラクションのレポートと 2）ソースの登録の両方に使用する URI の Key-Value マップを作成します。
集計サマリーレポート（Attribution Reporting API を使用）では、Protected Audience オークションからのオークションデータをソース側のキーマッピングに含めます。詳しくは、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 はビューイベントとクリックイベントをサポートしているため、この 2 つのタイプの区別には InputEvents が使用されます。ARA ソース登録と同様に、reportEvent() API はプラットフォームで確認済みの InputEvent をクリックイベントとして解釈します。InputEvent が欠落しているか、null または無効な場合、ソース登録はビューとみなされます。

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

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

この例では、オークション、レンダリングされた広告、コンバージョンアプリのデータを関連付けることに関心がある購入者の立場から考えてみましょう。

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

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

reportWin の実行中、購入者は、広告のレンダリング時と特定のインタラクションイベント（registerAdBeacon()）でトリガーされる広告ビーコンを登録できます。広告イベントにオークションシグナルを関連付けるには、auctionId をビーコン URL のクエリパラメータとして設定します。
広告のレンダリング時に、オークション時に登録したビーコンをトリガーまたはイベント単位のデータで拡張できます。販売者は 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 を使ってカスタム オーディエンス ターゲティングをサポートする

最近の更新

タイムライン

概要

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

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

カスタム オーディエンス

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

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

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

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

ユーザー コントロール