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

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 匿名性のしきい値を下回る小規模で専門的な広告でも、オークションに参加することを選択できます。また、より専門的な広告のオーディエンスが十分に大きくなるまで、より一般的な広告にフォールバックする方法がインタレスト グループに用意されています。

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

  • 新しい広告の表示を開始するには、表示させたい場合にその広告で入札を開始します。追加で必要な対応はございません。
  • 新しい広告が 𝑘-匿名化されていない場合に使用するフォールバック広告を設定できます。フォールバック広告自体が 𝑘-匿名化されていないリスクがあるため、最初からフォールバック広告のみで入札することを検討してもよいでしょう。たとえば、フォールバックがしきい値を超えた状態を維持することが予想されるレベルであれば、1% の確率でこの処理を行うとよいでしょう。

最近、他の方法で動作させることについての議論がいくつか行われています。このメカニズムが問題となるユースケースがある場合は、API を改善する方法についての公開の議論に引き続きご参加ください。

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

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

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