このページは 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 は通知なく失敗します。

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

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

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

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

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

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

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

広告テクノロジーはプライバシーサンドボックスに登録し、カスタムオーディエンスのすべての 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}};
}

出力: 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 関数で購入者と販売者が登録した鍵とのマッチングを試みます。一致する場合、プラットフォームは関連する reporting_url に event_data を 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 は、必要なデータを提供します。この URL は、Attribution Reporting API でビューまたはクリックを適格ソースとして登録する際に必要となるデータを提供します。
広告テクノロジーは、その URL を使用して CustomAudience（または広告の配置や視聴時間など、広告に関するその他の関連するコンテキスト情報）を渡すこともできます。これにより、広告テクノロジーがキャンペーンの集計パフォーマンスを確認しているときに、このメタデータを概要レポートに伝播できます。

ソース登録の有効化

reportEvent() は、新しい省略可能なパラメータ InputEvent を受け入れます。広告ビーコンを登録して落札した購入者は、どの reportEvent レポートを登録ソースとして Attribution Reporting API に登録するかを選択できます。リクエストヘッダー Attribution-Reporting-Eligible は、reportEvent() から送信されたすべてのイベントレポートリクエストに追加されます。適切な 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()）でトリガーされる広告ビーコンを登録できます。広告イベントにオークションシグナルを関連付けるには、ビーコン 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 を使ってカスタム オーディエンス ターゲティングをサポートする

最近の更新

タイムライン

概要

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

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

カスタム オーディエンス

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

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

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

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

ユーザー コントロール