このページは 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 四半期

概要

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

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

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

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

で確認できます。 <ph type="x-smartling-placeholder">

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

で確認できます。

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

SportingGoodsApp が、残っている商品アイテムを購入するようユーザーにリマインドしたいと考えています。カートに商品が追加されます。 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 が失敗します。特に、429（リクエストが多すぎます）ブロックの HTTP ステータスレスポンス。リクエストの数を表します。API 呼び出し購入者からのレスポンスの形式が正しくない場合も失敗します。不具合の報告先一時的な障害（例: サーバー応答なしなど）、永続的なエラーの処理（データの検証など）サーバーとの通信に伴う障害、その他の一時的でないエラーなど）。

CustomAudienceFetchRequest オブジェクトを使用して、API 呼び出し元は上記の例で示すオプションのプロパティを使用してカスタムオーディエンスの情報を指定できます。リクエストでこれらの値を設定した場合、プラットフォームが受信した購入者のレスポンスProtected Audience API はレスポンスのフィールド。リクエストでそれらが設定されていない場合は、それらのフィールドがカスタムイベントを作成するのに必要であるため、できます。CustomAudience のコンテンツの JSON 表現。例: API 呼び出し元によって部分的に定義されたものは、fetchUri への GET リクエストに含まれます。（特別なヘッダー X-CUSTOM-AUDIENCE-DATA 内）。シリアル化された形式のカスタムオーディエンスで指定するデータの上限は 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 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 をカスタムオーディエンス管理のすべてを管理する役割と、カスタムオーディエンスを部分的に管理できるようにするという 2 つの役割があります。 DSP とのパートナーシップにもとづいています
- これにより、この API と fetchAndJoinCustomAudience() の互換性も維持されます同様の情報共有を可能にする API です。

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

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

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

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

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

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

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

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

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

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

広告選択ワークフロー

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

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

インストール済みパッケージ情報がサーバーで利用できない場合、広告テクノロジープラットフォームは、複数のコンテンツターゲット広告をデバイスに送り返し、関連性の高い広告が表示される可能性を最大化するために、広告選択ワークフローを呼び出してアプリのインストールベースのフィルタリングを有効にします。
リマーケティング広告は範囲外で取得されるため、現在の入札モデルをアップデートする必要が生じる場合があります。広告テクノロジープラットフォームが入札サブモデルの作成を希望する場合がある（実装は、Terraform というパターンに基づいて 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-匿名性である必要はありませんが、制限は、1 つのプロジェクトに登録できるキーの数と長さに対する特定のカスタムオーディエンスを対象にできますreportEvent() が呼び出されると、それに対応するセルサイドプラットフォームがイベントレポートをいつでも受信できます。落札したバイサイドプラットフォームは、これらのレポートを受け取れます。

セルサイドレポート

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

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
落札単価
アプリ名
クエリ識別子
購入者向けのシグナル: 供給側と需要側でのデータ共有をサポートするプラットフォームはこの戻り値を入力パラメータとしてデマンドサイドのレポートコードです

バイサイドレポート

プラットフォームがデマンドで reportWin() JavaScript 関数を呼び出す入札ロジックの URL メタデータからダウンロードされた、カスタムオーディエンスの識別に役立ちます。

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 との統合に使用されます。 APIInputEvent オブジェクト（クリックイベントの場合）または null （ビューイベントの場合）。詳しくは、Attribution Reporting API の統合をご覧ください。このパラメータの詳細をご覧ください。

セルサイド SDK が reportEvent を呼び出した後、 reporting_destinations フラグを指定すると、プラットフォームは event_key を reportWin で購入者と販売者が登録した鍵と reportResult JavaScript 関数。一致するものがある場合、プラットフォームは関連する reporting_url に対する event_data。リクエストのコンテンツタイプ本文は event_data である書式なしテキストです。このリクエストは可能な限り正確にネットワークエラーやサーバーエラーの発生時に通知なく失敗する一致するキーが見つからなかった場合に返されます。

Attribution Reporting API の統合

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

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

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

ユーザーが広告を表示またはクリックすると、次のようになります。

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

ソース登録の有効化

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

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

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

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

この例では購入者の立場に立って見ていきますオークション、レンダリングされた広告、コンバージョンアプリからのデータの関連付けにおいて説明します。

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

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

reportWin の実行中、購入者は広告ビーコンを登録して特定のインタラクションイベントが発生したときにトリガーされる（registerAdBeacon()）。広告イベントのオークションシグナルを関連付けるには、ビーコン URL のクエリパラメータとして auctionId。
広告のレンダリング時に、オークション時に登録したビーコンをイベントレベルのデータでトリガーまたは拡張されます。営業担当者は reportEvent() を使用し、イベント単位のデータを渡します。プラットフォームから関連付けられた購入者の登録済み広告ビーコン URL トリガーされた reportEvent()。
購入者は、次の方法で Attribution Reporting API に広告を登録します。レスポンスとして広告ビーコンのリクエストに Attribution-Reporting-Register-Source ヘッダー。オークションシグナルを関連付けるためコンバージョンイベントの場合は、ソース URL の登録に auctionId を設定します。

上記の手順を終えると、購入者にオークションレポートが届きます。インタラクションレポート、コンバージョンレポートです。相互に関連付けることができる一意の ID です。

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

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

現在の広告選択ロジックには、予算の枯渇などのリアルタイムの情報が必要ステータスに基づいて、広告候補をオークションに選出する必要があるかどうかを判断できます。両方バイサイドとセルサイドのプラットフォームは、これらの情報をサーバーです。機密情報の漏洩を最小限に抑えるため、次の制限が適用されます。

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

バイサイド: バイサイドがバイサイド入札ロジックを開始すると、プラットフォームは、信頼できるサーバーから信頼できる入札データの 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 にアクセスする

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

カスタム オーディエンス

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

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

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

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

ユーザー コントロール