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

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 を超えないようにする必要があります。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 と 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 つのインタレスト グループは複数の広告を同時に掲載できるため、グループでは別の広告の 1 つを再入札して「代替広告」として機能させることができます。最も望ましい選択肢がしきい値を下回った場合に 通知を受け取ることができますつまり、k-匿名性の基準に満たない、小規模で特殊な広告でもオークションに参加でき、インタレスト グループは、汎用性の高い広告にフォールバックして、十分な数のオーディエンスを確保できることを意味します。

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

  • 新しい広告の掲載を開始するには、掲載を希望するケースで入札を開始します。他に何もする必要はありません。
  • 新しい広告が k-匿名性のない場合に、代替広告を使用できます。代替広告自体が匿名ではないというリスクがあるため、場合によっては、そもそも代替広告だけで入札することを検討してもよいでしょう。たとえば、一定の割合でフォールバックがしきい値を超えることが見込まれる場合は、全期間の 1% を対象に、このテストを行います。

他の機能についても最近議論されていますので、このメカニズムが問題を引き起こすユースケースがある場合は、API の改善方法についての一般公開の会話に引き続き関与してください。

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

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

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