オーディエンス データを定義する

Protected Audience API を使用してインタレスト グループを作成し、オーディエンスを定義する方法を学びます。Protected Audience API のライフサイクル全体については、デベロッパー ガイドをご覧ください。ブラウザがインタレスト グループを記録する方法の詳細な提案については、Protected Audience API の説明をご覧ください。

デベロッパー以外の方Protected Audience API の概要をご覧ください。

Protected Audience API インタレスト グループ

Protected Audience API インタレスト グループは、共通の興味や関心を持つユーザーのグループを表し、リマーケティング リストに対応します。すべての Protected Audience API インタレスト グループにはオーナーがいます。

インタレスト グループのオーナーは、Protected Audience API の広告オークションの購入者となります。インタレスト グループのメンバーシップはブラウザとユーザーのデバイスに保存され、ブラウザ ベンダーや第三者とは共有されません。

API 関数

joinAdInterestGroup()

広告主のデマンドサイド プラットフォーム（DSP）または広告主自体が navigator.joinAdInterestGroup() を呼び出し、ブラウザのメンバーシップ リストにインタレスト グループを追加するようブラウザにリクエストします。

joinAdInterestGroup() の呼び出しコンテキストのオリジンは、インタレスト グループのオーナーのオリジンと一致している必要があります。インタレスト グループのオーナーのオリジンが現在のドキュメントのオリジン（独自のインタレスト グループを持つウェブサイトなど）と一致する場合を除き、joinAdInterestGroup() を iframe から（DSP などから）呼び出す必要があります。

joinAdInterestGroup() には以下の権限が必要です:

つまり、dsp.example.com が権限を付与しない限り、malicious.example が dsp.example.com が所有するインタレスト グループの joinAdInterestGroup() を呼び出すことはできません。

アクセスしたサイトからの許可

同じオリジンまたはクロスオリジンから権限を付与できます。デフォルトでは、サイトへのアクセスと同じオリジン（つまり、現在のページの最上位フレームと同じオリジン）からの joinAdInterestGroup() 呼び出しに対して権限が付与されます。

使用例

以下に、インタレスト グループを定義し、ブラウザからグループへの参加をリクエストする方法の例を示します。

const interestGroup = {
  owner: 'https://dsp.example',
  name: 'custom-bikes',
  biddingLogicUrl: ...,
  biddingWasmHelperUrl: ...,
  updateUrl: ...,
  trustedBiddingSignalsUrl: ...,
  trustedBiddingSignalsKeys: ['key1', 'key2'],
  userBiddingSignals: {...},
  ads: [bikeAd1, bikeAd2, bikeAd3],
  adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};

navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);

関数に渡される interestGroup オブジェクトのサイズは 50 KiB 以下にする必要があります。そうしないと、呼び出しは失敗します。2 つ目のパラメータでは、インタレスト グループの期間（上限 30 日）を指定します。連続して呼び出すと、以前に格納されていた値が上書きされます。

必須プロパティ

インタレスト グループの必須プロパティは owner と name のみです。

プロパティ 例 ロール
owner https://dsp.example インタレスト グループ オーナーの作成元。
name custom-bikes インタレスト グループの名前。

省略可能なプロパティ

残りのプロパティは省略可能です。

biddingLogicUrl1、2
例: https://dsp.example/bid/custom-bikes/bid.js
ロール: ワークレットで実行される入札 JavaScript の URL。
biddingWasmHelperUrl1、2
例: https://dsp.example/bid/custom-bikes/bid.wasm
ロール: biddingLogicUrl から駆動される WebAssembly コードの URL。
updateUrl2
例: https://dsp.example/bid/custom-bikes/update
ロール: インタレスト グループ属性を更新するための JSON を返す URL。 （オーディエンス データの更新と広告の更新をご覧ください）。
trustedBiddingSignalsUrl2
例: https://dsp.example/trusted/bidding-signals
ロール: ビッダーの信頼できる Key-Value サービスへの Key-Value リクエストのベース URL。
trustedBiddingSignalsKeys
例: ['key1', 'key2' ...]
ロール: Key-Value の信頼できる Key-Value サービスへのリクエストの鍵。
userBiddingSignals
例: {...}
ロール: オーナーが入札時に使用できる追加のメタデータ。
ads1
例: [bikeAd1, bikeAd2, bikeAd3]
役割: このインタレスト グループに対して表示される可能性のある広告。
adComponents
例: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2]
ロール: 複数の要素で構成される広告のコンポーネント。

1 biddingLogicUrl プロパティと ads プロパティは省略可能ですが、オークションに参加するには必須です。これらのプロパティを使用せずにインタレスト グループを作成するユースケースも考えられます。たとえば、インタレスト グループのオーナーは、まだ実施していないキャンペーンのインタレスト グループにブラウザを追加したり、他の用途でブラウザを追加したりする場合や、一時的に広告予算が不足している場合などです。

2 Protected Audience API の現在の実装では、biddingLogicUrl、biddingWasmHelperUrl、updateUrl、trustedBiddingSignalsUrl はオーナーと同じオリジンである必要があります。これは長期的な制約ではない可能性があり、ads URL と adComponents URL にはそのような制約はありません。

インタレスト グループの広告を指定する

ads オブジェクトと adComponents オブジェクトには、広告クリエイティブの URL と、必要に応じて入札時に使用できる任意のメタデータが含まれます。

次に例を示します。

{
  renderUrl: 'https://cdn.example/.../bikeAd1.html',
  metadata: bikeAd1metadata // optional
}

leaveAdInterestGroup()

インタレスト グループのオーナーは、インタレスト グループからブラウザを削除するようリクエストできます。ブラウザがメンバーシップ リストからインタレスト グループを削除します。

navigator.leaveAdInterestGroup({
  owner: 'https://dsp.example',
  name: 'custom-bikes'
});

ブラウザにインタレスト グループの追加を要求したサイトにユーザーが戻ってきた場合、インタレスト グループのオーナーは navigator.leaveAdInterestGroup() 関数を呼び出して、インタレスト グループの削除をブラウザにリクエストできます。

広告のコードで、インタレスト グループに対してこの関数を呼び出すこともできます。

よくある質問

1 人のユーザーがアクセスできるインタレスト グループの数は、グループ オーナーごとに最大で何個ですか。

Chrome では、所有者あたり最大 1,000 個のインタレスト グループと、最大 1,000 個のインタレスト グループ オーナーを使用できます。これらの上限はガードレールとして意図されており、通常のオペレーションでヒットするものではありません。

k-匿名性のしきい値を満たしたインタレスト グループ広告を最大化するにはどうすればよいですか？

公開の説明にあるように、1 つのインタレスト グループでは、表示される可能性のある複数の広告を掲載できるため、そのグループの最も望ましい選択がしきい値を下回る場合はいつでも、別の広告の「代替広告」として再入札することができます。つまり、k-匿名性の基準値を下回っている小さな特殊な広告でもオークションに参加する可能性があります。インタレスト グループは、専門性の高い広告が十分な数のオーディエンスを獲得するまで、より一般的な広告にフォールバックすることができます。

戦術的な観点からは、次の点を検討できます。

  • 新しい広告の掲載を開始するには、ご希望の場合はその広告の入札を開始します。お客様側で必要な対応は特にございません。
  • 新しい広告が k-匿名性のものでない場合に使用する代替広告を用意できます。代替広告自体が k-匿名でないというリスクがあるため、場合によっては、そもそも代替広告で入札することを検討するとよいでしょう。この方法は、おそらく 1% の確率で実施します。たとえば、フォールバックがしきい値を超えないようにするには、このレベルが適切なレベルです。

他の仕組みに関する最近の議論があるため、このメカニズムが問題を引き起こすユースケースがある場合は、API をどのように改善できるかについて公開の会話を続けてください。

すべての Protected Audience API リファレンス

API リファレンス ガイドが提供されています。

Protected Audience API の解説では、機能のサポートと制約に関する詳細も説明しています。