Protected Audience API（旧 FLEDGE）

プライバシー サンドボックスの一環として、Chrome は Protected Audience API を提案しました。これは、広告主や広告テクノロジー企業がサードパーティ Cookie に依存せずにインタレスト グループ ターゲティング広告を表示し、ユーザーをクロスサイト トラッキングから保護できるブラウザ内 API です。

Chrome では、Protected Audience API のオリジン トライアルが実施されています。認定バイヤーは、アド マネージャーのパブリッシャー広告枠での Protected Audience API のテストに参加できます。入札者は、Protected Audience API をテストすることで、次のことを実現できます。

  • Protected Audience API フローの有効性を繰り返しテストし、学習します。
  • 公開フォーラム（GitHub など）で、API の改善案に関するフィードバックを生成します。
  • サードパーティ Cookie に依存せずに API を通じてパーソナライズド広告をサポートする準備をします。

テストに関心のある認定バイヤーは、オンボーディングのセクションで詳細をご確認ください。

サービング フローの概要

認定バイヤー パートナー向けの Protected Audience 広告配信フローの概要は次のとおりです。

フロー図

  1. ビッダーは広告主と連携して、各広告主のインタレスト グループを維持します。多くの場合、広告主は入札者のタグを広告主のページに追加して、ブラウザをインタレスト グループに追加します。
  2. エンドユーザーが広告主のページにアクセスします。ページに広告申込情報のタグが含まれている可能性があります。
  3. 入札者のタグが Protected Audience API joinAdInterestGroup() を呼び出します。この呼び出しは、ブラウザにユーザーをインタレスト グループに追加するようリクエストします。
  4. エンドユーザーがパブリッシャーのウェブページにアクセスします。ユーザーのブラウザが Google のパブリッシャー広告タグをリクエストします。
  5. Google のパブリッシャー広告タグが、Google サーバーにコンテキスト広告リクエストを送信します。
  6. Google は、参加している入札者にコンテキスト入札リクエストを送信します。詳しくは、入札リクエストの変更に関するセクションをご覧ください。
  7. ビッダーは、インタレスト グループ オークションに参加するために必要な InterestGroupBidding メッセージを含む入札レスポンスを返します。OpenRTB では BidResponse.ext.igbid フィールドで指定され、非推奨の Google RTB プロトコルでは BidResponse.interest_group_bidding フィールドで指定されます。入札者がこの情報を指定しない場合、Google はオークション構成の interestGroupBuyers に入札者のオリジンを含めません。InterestGroupBidding には、ブラウザ内オークション中に入札者の入札関数に渡される、購入者固有のオプションのシグナルを含めることもできます。OpenRTB では BidResponse.ext.igbid.igbuyer.buyerdata フィールドで指定され、非推奨の Google RTB プロトコルでは BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals フィールドで指定されます。詳しくは、入札レスポンスの変更に関するセクションをご覧ください。
  8. Google はサーバーサイド オークションを実行し、入札レスポンスをブラウザに返します。サーバーサイド オークションでは、従来のサーバーサイド入札が考慮されます。入札レスポンスには、コンテキストの落札単価に関する情報を含めることができます（該当する場合）。
  9. 入札レスポンスには、ブラウザ内オークションのオークション構成が含まれています。これには、参加している各バイヤーからのコンテキスト シグナル（以前は OpenRTB の buyerdata または非推奨の Google RTB プロトコルの per_buyer_signals を介して送信されたもの）、コンテキストの落札者情報、入札の対象となる条件の設定などが含まれます。
  10. Google のパブリッシャー タグは、Protected Audience API runAdAuction() を呼び出して、デバイス上のインタレスト グループ オークションを開始します。Google は、オークション構成時に InterestGroupBidding の InterestGroupBuyer として含まれていたバイヤーのみを含めます。
  11. Google は、対象となる各入札者のオプションの購入者固有のシグナルを Protected Audience オークション構成に渡します。
  12. 特定の入札者のインタレスト グループで trustedBiddingSignalsUrl が指定されている場合、ブラウザは各グループの trustedBiddingSignalsUrl にリクエストを送信し、各グループのリアルタイム シグナルを取得します。詳しくは、Protected Audience API の仕様をご覧ください。
  13. ブラウザは、オプトインし、ブラウザ内オークションに参加する資格のあるインタレスト グループごとに、ビッダーの generateBid() を呼び出します。このステップでは、入札単価を計算してクリエイティブを選択します。generateBid() は、ビッダーが提供するオプションの購入者シグナルと、特定のインタレスト グループの信頼できる入札シグナルにアクセスできます。
  14. ブラウザは販売者（この場合は Google）の scoreAd() を呼び出して、インタレスト グループ広告オークションの各入札にランクを割り当てます。入札は、パブリッシャーの保護設定、広告ポリシー、その他の制約に基づいてランク付けされ、フィルタされます。
  15. ブラウザは、対象となるインタレスト グループの入札でオークションを実施します。上位のコンテキスト入札がブラウザ内オークションに参加します。
  16. オークションの後、インタレスト グループの落札者がいる場合は、ブラウザが販売者の reportResult() と入札者の reportWin() を呼び出し、ブラウザ内オークションの落札者を各当事者に通知します。
  17. インタレスト ベース広告が落札された場合、Google のパブリッシャー タグによって広告が iframe にレンダリングされます。

サービング フローの詳細

広告配信前

クリエイティブの審査

クリエイティブは、ブラウザ内オークションの Protected Audience から配信される前に、Google の審査を受けて承認される必要があります。クリエイティブの審査をリクエストするには、Real-time Bidding API を使用するか、クリエイティブの自動スキャンを使用します。ブラウザ内の Protected Audience インタレスト グループ広告オークションのクリエイティブには、審査用の renderUrls を含める必要があります。

renderUrls の要件:

  • API を介して送信された renderUrl は、インタレスト グループ広告オークションで使用される renderUrl と一致する必要があります。
  • 各 renderUrl は、1 つの広告主または広告キャンペーンのみを表すことができます。特定の renderUrl を使用して、複数の広告主様の代わりに広告をレンダリングすることはできません。各 renderUrl は 1 つのクリエイティブにマッピングする必要があります。
  • renderUrl は、広告が最後に使用されてから 7 日間は、Google のオフライン クリエイティブ審査システムからアクセス可能で、取得可能である必要があります。
Real-time Bidding API

入札者は、リアルタイム ビッダー API を使用して、インタレスト グループ入札用のクリエイティブをアップロードできます。

クリエイティブの自動スキャン

ビッダーは、リアルタイム ビッダー API を介してアップロードされていないクリエイティブに対して、クリエイティブの自動スキャンを設定できます。

クリエイティブの自動スキャンを設定すると、ブラウザ内オークションのクリエイティブが検出され、自動的にスキャンされるため、今後のオークションの対象となります。

クリエイティブの自動スキャンを有効にする方法は次のとおりです。

  • インタレスト グループ クリエイティブの renderUrl オリジンをすべて認定バイヤー アカウントに追加します。

  • クリエイティブの HTTP レスポンスに次のカスタム HTTP ヘッダーを追加します。

    Authorized-Buyers-Creative-ID

    文字列

    購入者固有のクリエイティブ ID。クリエイティブ ID の最大長は 128 バイトです。
    Authorized-Buyers-Click-Through-URLs

    文字列

    RFC2396 に従ってエンコードされた、クリエイティブの宣言済みリンク先 URL のセット。

例:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
クリエイティブの有効期限

クリエイティブは 15 日間承認されます。Real-time Bidding API を使用してクリエイティブを送信する場合は、15 日後にクリエイティブを再送信する必要があります。クリエイティブの自動スキャンを利用している場合は、スキャン プロセスで自動的に再スキャンされます。

購入者のレポート ID

購入者が提供するディメンション（キャンペーン ID や広告主 ID など）を使用して、レポートの指標（インプレッション数など）を分類できます。インタレスト グループの費用のディメンションを追加するには、ユーザーのデバイスをインタレスト グループに追加するときに、広告の buyerAndSellerReportingId を指定します。詳しくは、Protected Audience のドキュメントをご覧ください。

次の例は、インタレスト グループの構成に buyerAndSellerReportingId を追加する方法を示しています。

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

buyer_reporting_id は、Authorized Buyer のレポートツールで [Buyer Reporting ID ディメンション] という新しいディメンションとして表示されます。

サーバーサイド オークション

入札リクエストの変更

テストで使用できるサポート対象プロトコルの初期バージョンは次のとおりです。

インタレスト グループ オークションのサポートを示す

入札リクエストに、インタレスト グループ オークションのサポートを示す新しいフィールドが追加されました。

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Google RTB プロトコル（非推奨）:
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

このフィールドを使用すると、ブラウザ内の Protected Audience インタレスト グループ オークションをサポートするインプレッション機会と、従来のサーバーサイド エクスチェンジ オークションのみをサポートするインプレッション機会を区別できます。AuctionEnvironment 列挙型には次の値を指定できます。

  • SERVER_SIDE_AUCTION（OpenRTB JSON: 0）: 落札広告を決定するオークションがエクスチェンジのサーバーで実行されます。
  • ON_DEVICE_INTEREST_GROUP_AUCTION（OpenRTB JSON: 1）: Protected Audience をサポートするリクエスト。コンテキスト オークションがエクスチェンジのサーバーで実行され、インタレスト グループの入札と最終オークションがブラウザで実行されます。
  • SERVER_SIDE_INTEREST_GROUP_AUCTION（OpenRTB JSON: 3）: コンテキスト オークションはエクスチェンジのサーバーで実行され、インタレスト グループの入札の入札ロジックと最終的な落札広告を決定するスコアリング ロジックは、入札サーバーとオークション サーバーで実行されます。
Protected Audience の広告スロットのサイズを指定する

入札リクエストには、プロテクト オーディエンスの広告スロットのサイズを提供するための次のフィールドが含まれます。

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Google RTB プロトコル（非推奨）:
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

これらのフィールドは、Protected Audience オークションの広告スロットのサイズをピクセル単位で示します。

このサイズは、OpenRTB の BidRequest.imp.banner.format.w フィールドと BidRequest.imp.banner.format.h フィールドや、非推奨の Google RTB プロトコルの BidRequest.adslot.width フィールドと BidRequest.adslot.height フィールドなど、コンテキスト リクエストのサイズとは異なる場合があります。

コンテキスト リクエストには複数のサイズが含まれる場合があります。オンデバイス オークションで落札した広告は、単一の固定スロットサイズのみを埋めることが想定されています。

Protected Audience 広告のレンダリング可能性を示す

Protected Audience 広告は、現在の統合ステージに応じてレンダリングされる場合とされない場合があります（レンダリングされないテストを参照）。入札リクエストの render_interest_group_ads フィールドは、落札した Protected Audience 広告がレンダリングされるかどうかを示します。

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Google RTB プロトコル（非推奨）: BidRequest.adslot.interest_group_auction.render_interest_group_ads
ユーザー識別子への依存を最小限に抑える

Protected Audience API のテストの対象となるコンテキスト入札リクエストでは、ブラウザから利用可能な場合、従来の Cookie ベースの ID（BidRequest.user.id フィールドや BidRequest.user.buyerid フィールド、または非推奨の Google RTB プロトコルの BidRequest.google_user_id や BidRequest.hosted_match_data など）を引き続き使用できます。入札リクエストにこのような識別子が含まれている場合は、既存のプライバシー ポリシーが適用されます。テスト中は、ターゲティングと入札の目的で Cookie ベースの識別子を使用しないことをおすすめします。これにより、サードパーティ Cookie が利用できなくなったときに、効率的な購入に向けてより適切に準備できます。

また、Google は、Protected Audience API テストの対象となる入札リクエストから Cookie ベースの ID を削除する小規模なテストを実施する場合があります。これは、サードパーティ Cookie のサポート終了が及ぼす潜在的な影響を評価するためのものです。

2024 年のサードパーティ Cookie の廃止（3PCD）に備えるため、Chrome ではChrome 主導のテストが提供されています。

サイトとベンダーは、Chrome 主導のテストを使用して、3PCD の下でシステムをテストできます。このテストでは、Chrome ブラウザは 3PCD テストグループ（モード A またはモード B）に割り当てられます。各ブラウザには、特定の 3PCD テストグループに対応する一貫したラベルが割り当てられます。このラベルには、ブラウザ内の Chrome API を通じてアクセスできます。

Google は、変更されていないラベルを Chrome API から RTB 入札リクエストに渡します。個々のラベルのトラフィック スライスが小さいため、Google はプライバシーが制限されたコンテキストにラベルを常に含めるとは限りません。

ラベルを表示できるフィールドは次のとおりです。

  • OpenRTB: BidRequest.device.ext.cdep
  • Google RTB プロトコル（非推奨）: BidRequest.device.cookie_deprecation_label

入札レスポンスの変更

インタレスト グループ オークションへの参加を示す

コンテキスト入札レスポンスで InterestGroupBidding オブジェクトを返すことで、ブラウザ内オークションへの参加意向を明示的に示す必要があります。

  • OpenRTB: BidResponse.ext.igbid
  • Google RTB プロトコル（非推奨）: BidResponse.interest_group_bidding

コンテキスト ターゲティングの入札レスポンスを指定する必要があります。レスポンスにコンテキスト入札を含める必要はありません。InterestGroupBidding オブジェクトには、各 InterestGroupBuyer の origin が含まれている必要があります。この InterestGroupBuyer は、入札者がアカウント用に構成したオリジンのいずれかと一致する必要があります。Google パブリッシャー タグが runAdAuction() を呼び出すと、オークション構成の interestGroupBuyers に origin が追加されます。

購入者のコンテキスト シグナルを伝播する

購入者のシグナルをコンテキスト入札レスポンスに含めることができます。Google は、perBuyerSignals 引数を介して、JSON オブジェクトとしてデバイス上の入札関数に伝播します。これは、プロトコルに応じて次のフィールドを使用して入札レスポンスに含めることができます。

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB（非推奨）: BidResponse.interest_group_bidding.per_buyer_signals
購入者のコンテキスト レンダリング シグナルを伝播する

インタレスト グループ クリエイティブは、コンテキスト入札レスポンスを通じてシグナルを送信し、マクロ展開を使用してレンダリング URL リクエストでシグナルを受信することで、レンダリング時に限定的なコンテキスト シグナルを使用できます。たとえば、レンダリング シグナルを使用して、特定の広告スロットやパブリッシャー ページのコンテキストでパフォーマンスを改善するために、クリエイティブのルック アンド フィールをカスタマイズできます。

購入者のレンダリング シグナルを URL 安全な文字列としてシリアル化し、コンテキスト入札レスポンスに含めることができます。Google は、${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]} マクロを構築して、落札したインタレスト グループのレンダリング URL でこの文字列を置き換えます。

レンダリング シグナルは、プロトコルに応じて次のフィールドを使用して入札レスポンスで指定できます。

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB（非推奨）: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

異なるシグナルを区別するために、入札レスポンスには異なるマクロ接尾辞を持つレンダリング シグナルのセットを最大 3 つ含めることができます。たとえば、接尾辞を使用して、レンダリング URL に対応するマクロを含むクリエイティブにのみ適用される特定のシグナルセットを照合し、データ転送サイズを削減できます。

シグナルが URL 安全でない場合、マクロ接尾辞が一意でない場合、または 3 セットを超えるシグナルが提供された場合、インタレスト グループの購入者は Protected Audience オークションへの参加を拒否されます。

ブラウザ内入札単価の上限を指定する

Protected Audience のプロポーザルでは、入札単価の計算と最終オークションはローカル デバイス上で実行されることになっています。これにより、落札価格など、最終的なオークション結果の完全性に影響する可能性のある不正使用のベクトルが生まれる可能性があります。

Google が RTB パートナー向けに Protected Audience API のテストでサポートしている緩和策として、各コンテキスト入札レスポンスで想定される最大入札額を指定できます。予想される上限単価は、入札関数が返すことが想定される上限単価です。ブラウザ内オークションから報告された落札額がこの金額を超えている場合、落札額は課金対象イベントとしてカウントされません。このアプローチは変更される可能性があります。

入札レスポンスでは、次のフィールドで想定される上限入札単価を指定できます。

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid（CPM の通貨単位で表されます）
  • Google RTB プロトコル（非推奨）: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros （マイクロ CPM で表されます）
複数のアカウントにインプレッションを割り当てる

入札者は、次のフィールドを使用して、インタレスト グループの入札のインプレッションを帰属させるための請求先 ID を選択する必要があります。

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • Google RTB プロトコル（非推奨）: BidResponse.interest_group_bidding.interest_group_buyers.billing_id

選択した請求 ID は、入札リクエストの対象となる請求 ID である必要があります。

  • OpenRTB: BidRequest.imp.ext.billing_id
  • Google RTB プロトコル（非推奨）: BidRequest.adslot.matching_ad_data.billing_id

インタレスト グループの入札インプレッションの帰属先となる請求 ID が指定されていない場合、入札者は Protected Audience オークションに参加しません。

子アカウントには最大 2 つの請求先 ID を設定できます。購入者は、コンテキスト広告の費用に 1 つの請求 ID を使用し、インタレスト グループの費用に別の請求 ID を使用できます。子アカウントに 2 つの請求先 ID を設定する場合は、アカウント マネージャーにお問い合わせください。

請求 ID ごとに 1 日の予算を設定できます。アカウント マネージャーに連絡して、子アカウントの請求 ID の 1 日の予算を設定します。

インプレッションに入札できる予算があるすべての子アカウントの請求先 ID が、費用配分選択の入札リクエストに表示されます。インタレスト グループの請求先 ID の予算を変更するには、アカウント マネージャーにお問い合わせください。

ブラウザ内オークション中

ブラウザ内入札を生成する

generateBid() を使用してブラウザ内入札を生成します。

Google は次のパラメータを提供します。

  • auctionSignals: 空
  • perBuyerSignals: コンテキスト レスポンスで入札者が提供したシグナルと同じシグナルの JavaScript オブジェクト

次のパラメータが返されます。

  • ad: Google はこのフィールドを無視します。
  • bid: オークションに参加する数値入札。CPM 単位（マイクロ単位ではない）で指定する必要があります。
  • render: 入札がオークションで落札された場合にクリエイティブを表示するためにレンダリングされる URL。この URL は Google による審査と承認が必要であり、審査と承認が行われない場合はオークションから除外されます。
  • allowComponentAuction: true でなければなりません。現在、Google はマルチセラー オークションのテストをサポートしています。

次の例をご覧ください。

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

generateBid() 関数の説明については、Protected Audience の仕様のオンデバイス ビッディングのセクションをご覧ください。

入札通貨

ブラウザ内オークションの入札単価は、選択した入札通貨の CPM 単位で設定されます。

入札通貨は、コンテキスト入札レスポンスと generateBid の戻り値の両方で指定する必要があります。また、有効な ISO 4217 アルファコード（「USD」、「EUR」、「JPY」など）である必要があります。

OpenRTB では、Google の入札レスポンス拡張機能の InterestGroupBuyer オブジェクトで新しい cur フィールドを使用します。

次の例をご覧ください。

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

Google RTB プロトコルでは、入札レスポンスの InterestGroupBuyer メッセージで新しい currency フィールドを使用します。

次の例をご覧ください。

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

入札者の generateBid 関数は、コンテキスト入札レスポンスで示されたものと同じ通貨で入札を返す必要があります。generateBid の戻り値に新しい bidCurrency プロパティを入力します。

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

コンテキスト入札レスポンスの通貨が generateBid から返された通貨と異なる場合、またはどちらかが無効な通貨を返した場合、入札はオークションの前に除外されます。

広告の品質チェック

RTB パートナー向けの Protected Audience API テストでは、ブラウザ内のインタレスト グループの入札に対するクリエイティブ ポリシーとパブリッシャーの管理設定の適用がより厳しくなる可能性があります。

デジタル サービス法への対応

デジタル サービス法第 26 条に基づき、パブリッシャーは購入者に対して広告内の透明性に関する開示情報の表示を求める場合があります。「EEA のサイトまたはアプリで、DSA の透明性に関する情報を含む広告のみを表示するよう購入者に依頼する」設定を有効にしている場合、インタレスト グループの購入者は、入札リクエストの BidRequest.regs.dsa.required と BidRequest.dsa.pubrender の値（非推奨の Google RTB プロトコルではそれぞれ BidRequest.dsa.dsa_support と BidRequest.dsa.publisher_rendering_support）を確認することで、購入者の透明性をレンダリングする必要がある機会を特定できます。

Protected Audience API オークションへの参加を希望する入札者は、Protected Audience API を介して配信される広告で DSA の透明性を表示する必要があるというシグナルを入札リクエストで受け取った場合、必要な情報を適切に表示できるかどうかを確認し、BidResponse.ext.igbid.igbuyer.dsaadrender（非推奨の Google RTB プロトコルでは BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render）を設定して指定する必要があります。そうしないと、購入者は Protected Audience API オークションに含まれません。

デジタル サービス法に基づく広告の透明性について詳しくは、ヘルプセンター記事「デジタル サービス法への対応」をご覧ください。

入札のフィルタリング

Google は、オンデバイス オークション中にパブリッシャーのコントロールと広告ポリシーを適用します。

ブラウザ内オークション後

オークションの結果を購入者に報告する: reportWin()

Google は次の引数を入力しません。

  • auctionSignals
  • sellerSignals

reportWin() を使用して、オークションの結果を購入者に報告します。

詳しくは、Protected Audience API の説明のレンダリングと広告イベントに関するバイヤー レポートのセクションをご覧ください。

マクロ

Protected Audience API のクリエイティブを参照する renderUrl には、マクロと呼ばれる 1 つ以上のプレースホルダを含めることができます。インタレスト グループ オークションの終了後、レンダリングの前に、マクロは対応する値に置き換えられます。オンデバイス オークションで使用される renderUrl には、次のマクロを含めることができます。

${GDPR} GDPR が適用されない場合は 0、適用される場合は 1 に展開されます。ドキュメントをご覧ください。
${GDPR_CONSENT_XXXX} リクエストに関連付けられた透明性と同意（TC）文字列に展開されます。透明性と同意（TC）文字列が空白または無効な場合、このマクロは展開されません。

このマクロは、URL で IAB GVL 登録済みベンダーに TC 文字列を渡す場合に使用します。XXXX は、IAB GVL に登録されているベンダーの IAB GVL ID に置き換えます。TC 文字列が空白または無効な場合、このマクロは展開されません。

${GDPR_CONSENT_XXXX} マクロを含むクリエイティブは、挿入した IAB GVL ID に該当する IAB GVL 登録ベンダーに対してユーザーの同意がない場合、ブロックされる可能性があります。

${GDPR_CONSENT_XXXX} マクロは renderUrl 内に 1 回だけ含める必要があります。
${ADDL_CONSENT} リクエストに関連付けられた追加同意（AC）文字列に展開されます。
${AD_WIDTH}, ${AD_HEIGHT) これらのマクロは、広告スロットの幅と高さを挿入します。
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

入札レスポンスで指定されたレンダリング時の購入者シグナルを含むマクロ。

buyer.origin.example プレースホルダは、インタレスト グループの購入者のオリジンに置き換えます。これは、入札レスポンスの interest_group_buyers.origin に対応している必要があります。_OPTIONAL_SUFFIX を含めて、最大 3 つの異なるレンダリング シグナル値を指定できます。

インプレッションのカウント

RTB パートナーとの Protected Audience API テストでは、ブラウザが reportResult() 関数を呼び出し、その後 sendReportTo() の呼び出しで Google のレポート用 URL を取得したときに、インプレッションがカウントされます。

Protected Audience のブラウザ内オークションでインプレッション数をカウントするために Google が使用するイベントは、RTB バイヤー パートナーがインプレッション数をカウントするために使用するイベントと異なる場合があるため、インプレッション数が異なる可能性があります。

Protected Audience API のテストにおける Google の目標の一つは、こうした差異を特定して減らすことです。

請求対象インプレッションのアトリビューション

ブラウザ内 Protected Audience オークションでの入札者のすべての費用は、入札者用に構成されたインタレスト グループの所有者のオリジンからのマッピングに基づいて、単一の入札者アカウントに帰属します。入札者の異なる子シート アカウントに費用を割り当てることはできません。

1 日の予算の上限

Protected Audience API のテスト中、各アカウントにはアカウント レベルの Protected Audience の 1 日の費用の上限が設定されます。1 日の費用の上限により、ブラウザ内オークション環境のリスクが制限されます。1 日の予算の上限に達すると、アカウントはプロテクト オーディエンスの対象となる入札リクエストを受け取らなくなります。

Protected Audience の上限に達した後も、アカウントはサーバーサイドのコンテキスト オークションに参加できます。たとえば、Protected Audience の上限に達したビッダー アカウントは、Protected Audience オークションの対象となる入札リクエストであっても、auction_environment = SERVER_SIDE_AUCTION（OpenRTB JSON: 0）を含む入札リクエストを受け取る可能性があります。

リアルタイムのフィードバックと落札に必要な最小単価

リアルタイムのフィードバックを受け取るように設定している入札者は、デバイス上の Protected Audience オークションへの参加をリクエストされたインタレスト グループの購入者に関するフィードバックを受け取ります。入札者が入札レスポンスで指定したインタレスト グループの購入者ごとに、Protected Audience オークションでインタレスト グループの購入者が入札した回数に関係なく、1 つのフィードバック オブジェクトが送信されます。インタレスト グループの購入者のフィードバック オブジェクトでは、次の情報が利用可能になります。

  • フィードバック オブジェクトのフィードバック タイプは INTEREST_GROUP_BUYER_FEEDBACK になります。
  • インタレスト グループ購入者のオリジン。
  • 全体的なオークションで落札するために、インタレスト グループの購入者が提示する必要がある最小入札単価。
  • インタレスト グループの購入者が、オークション全体のサーバーサイド コンポーネントで最も高いランクの入札を上回るために必要な最小落札単価。
  • インタレスト グループの購入者のステータス コード。ステータス コードは、interest-group-buyer-status-codes.txt で定義されています。

特定のフィールド名については、認定バイヤー RTB と OpenRTB 拡張機能のプロトコル ドキュメントをご覧ください。

入札に関するフィードバック通知

Chrome は、Protected Audience API の一時的なデバッグ API を提供します。これにより、アド マネージャーは Protected Audience 入札に関するフィードバックを含むリアルタイムのサーバー間デバッグ通知を送信できます。この通知には、入札に関する以下の情報に加えて、Protected Audience のブラウザ内オークションで入札がフィルタされた理由も含まれます。

入札者は、アカウント マネージャーに連絡して、Protected Audience のデバッグ入札フィードバック通知の配信に使用される静的 URL を構成できます。この静的 URL は、Protected Audience オークションの完了後に、選択したマクロが置き換えられた状態で Google サーバーから取得されます。次のマクロがサポートされています。

  • %%GOOGLE_QUERY_ID%%: このマクロは、プロテクト オーディエンスが有効になっているコンテキスト入札リクエストで送信された Google クエリ ID に置き換えられます。OpenRTB プロトコルでは BidRequest.ext.google_query_id で指定されますが、非推奨の Google RTB プロトコルでは BidRequest.google_query_id が使用されます。
  • %%INTEREST_GROUP_OWNER%%: 利害関係者グループの所有者のオリジン。
  • %%BID_CPM%%: generateBid() 関数で買い手が指定した CPM の入札価格。
  • %%RENDER_URL%%: クリエイティブのレンダリング URL。
  • %%STATUS%%: 入札が scoreAd() 内で拒否された場合のステータス コード。値はクリエイティブのステータス コードです。

入札者がアカウント マネージャーに提供する静的 URL の例を次に示します。

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

入札フィードバック通知は、Chrome の一時的な ForDebuggingOnly API に依存する一時的な機能です。

商品レベルの TURTLEDOVE

Protected Audience API のテスト期間中、Google RTB パートナーは複数の要素で構成される広告またはプロダクト レベルの TURTLEDOVE（PLTD）を利用できます。PLTD のテストを予定している場合は、統合時にアカウント マネージャーにお知らせください。追加のリソースと構成が必要になります。

オンボーディング

Protected Audience API をテストする方法は次のとおりです。

手順

  1. Protected Audience API テストに参加するには、リクエスト フォームに記入してください。
  2. リクエスト フォームを送信したら、アカウント マネージャーにお問い合わせいただくか、認定バイヤー ヘルプセンターを使用してチケットを送信してください。
  3. アカウントが構成されると、Google とパートナーの両方が、テスト ステージの手順に沿って統合を確認できます。

広告の審査

Protected Audience API のオークションで商品レベルの広告（複数の要素で構成される広告）を使用して入札するには、次の要件を満たす必要があります。

  • クリエイティブの審査時に最上位の renderUrls を区別するために、コンポーネント広告のコンテナ（最上位の renderUrl とも呼ばれます）の renderUrl に &pltd=True クエリ パラメータを含めます。
  • Google によるクリエイティブの審査のためにコンポーネント広告のコンテナが取得されたときに、代表的なクリエイティブをレンダリングします。代表的な広告レンダリングを返すタイミングを把握するには、Google クリエイティブ審査システムによって設定された validation=True クエリ パラメータを参照してください。

統合チェックリスト

  • コンテキスト入札レスポンスの Protected Audience API 関連フィールド（interest_group_bidding など）に入力する入札リクエスト エンドポイントを設定します。
  • 広告主のページにタグを設定して、ユーザーのブラウザをインタレスト グループに参加させます。
  • generateBid() と reportWin() を実装します。
  • インタレスト グループのオーナーのオリジンを選択し、認定バイヤー アカウントに追加します。
    • インタレスト グループのオーナーのオリジンは、generateBid() 関数がホストされているオリジンと一致する必要があります。
    • この手順を完了するには、アカウント マネージャーにお問い合わせいただくか、認定バイヤーのヘルプセンターからチケットを送信してください。
  • Protected Audience API のテストに関連するインベントリの事前ターゲティングを設定します。
  • クリエイティブ API を使用して、審査と承認のためにクリエイティブを送信します。
  • （省略可）信頼できる入札シグナルのエンドポイントを設定します。
  • （省略可）Google のエンジニアがブラウザをインタレスト グループ バイヤーのオリジンが所有するインタレスト グループに追加できるようにするテスト広告主ページを設定します。これにより、Protected Audience オークションを手動でトリガーできます。
  • （省略可）アカウントでリアルタイム フィードバックを有効にして、Protected Audience オークションへの参加をリクエストしたインタレスト グループの購入者に対するフィードバックを受け取ります。
  • （省略可）アカウント マネージャーに連絡して、静的 URL を設定し、デバイス上の Protected Audience オークションの入札ステータスに関する Protected Audience 入札フィードバックを提供するサーバー間通知を受信して、予期しない問題のデバッグに役立てます。詳しくは、入札に関するフィードバックの通知をご覧ください。

テスト ステージ

ステージ 1: 手動テスト

Protected Audience オークションを手動でトリガーし、広告をレンダリングできることを確認して、インプレッションを記録する方法は次のとおりです。

  1. Chrome 101 以降を使用します。
  2. chrome://flags/#privacy-sandbox-ads-apis と chrome://flags/#enable-fenced-frames を使用して、プライバシー サンドボックス API とフェンス付きフレームを有効にします。詳しくは、プライバシー サンドボックスをテストするをご覧ください。
  3. リアルタイム ビッダー API を使用して、クリエイティブを承認用に送信します。
  4. 入札者が提供する広告主様のページを使用して、入札者が所有するインタレスト グループにブラウザを追加します。

  5. 次の Google 提供のテスト パブリッシャー ページを使用して、Protected Audience オークションをトリガーします。

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    ブラウザ内のインタレスト グループは、従来のサーバーサイドの入札と競合する可能性があるため、オークションで落札できるだけの高い入札単価を設定する必要があります。また、Google はパートナーごとに専用のテスト パブリッシャー ページを提供しています。このページでは、指定されたパートナーのみがオークションに参加できます。パートナー固有のページでは、ブラウザ内オークションで確実に落札しやすくなる可能性があります。

  6. 以下を確認します。

    1. 落札広告が表示されます。
    2. オークションの結果はサーバーサイドで送信されます。つまり、落札者は reportWin() からの ping を受け取ります。
    3. テスト パブリッシャー ページのコンソールには、次の情報を含む入札ごとにデバッグ メッセージが記録されます。
      • renderUrl: 入札のレンダリング URL。
      • interestGroupOwner: 入札のインタレスト グループの所有者。
      • accepted: 入札が承認された場合は true、scoreAd() によって入札が不承認となった場合は false になります。
      • externalBidStatus: scoreAd() 内で入札が拒否された場合のステータス コード。値はクリエイティブのステータス コードです。

ステージ 2:（省略可）レンダリングなしのテスト

Google とパートナーが、パートナーが Protected Audience オークションに参加できることを手動で確認した後、Google はテストの次の段階に進むためにパートナーを有効にします。

Google は、Protected Audience オークションを実行するために、少量のライブ トラフィックを割り当てます。これにより、Google とパートナーは Protected Audience オークションを手動でトリガーする必要がなくなります。Protected Audience オークションの結果がレンダリングされません。これにより、統合を大規模にテストできます。

準備が整いましたら、アカウント マネージャーにお問い合わせいただくか、認定バイヤー ヘルプセンターからチケットをご提出ください。Google はこのステージのアカウントを有効にします。

ステージ 3: レンダリング テスト

Google とパートナーがレンダリングなしで Protected Audience オークションを大規模に検証したら、Google はパートナーが Protected Audience の落札広告をレンダリングできるようにします。Google では、Protected Audience オークションの対象となるトラフィックがわずかに存在し、落札したインタレスト グループの広告がレンダリングされます。参加しているビッダーのブラウザ内入札は、従来型の入札と競合します。

準備が整いましたら、アカウント マネージャーにお問い合わせいただくか、認定バイヤー ヘルプセンターからチケットをご提出ください。Google はこのステージのアカウントを有効にします。

その他の機能

次の機能は、コア プロトコルの拡張機能です。

並列化

並列化は、trustedBiddingSignalsUrl で指定された購入者の信頼できるサーバーへのリクエストと並行してコンテキスト広告リクエストを開始することで、オークションのエンドツーエンドのレイテンシを短縮する最適化です。

並列化によりレイテンシは短縮されますが、インタレスト グループの購入者の適格性と調整されたテストのサポートに影響します。並列化は、オンデバイスのインタレスト グループ オークションに参加するすべてのビッダーに適用されます。入札者は並行オークションに参加するために行動を起こす必要はありませんが、並列化がデバイス上のオークションでの適格性にどのように影響するかを理解しておく必要があります。並行オークションでは、調整されたテストのテストグループ ID はまだサポートされていません。

サービング フローの概要

並列オークション フローの概要は次のとおりです。 フロー図

オンデバイス インタレスト グループの購入者の適格性

並列オークションの場合、navigator.runAdAuction の呼び出しはコンテキスト広告のレスポンスが返される前に行われます。バイヤーの信頼できるサーバー呼び出しを開始するには、navigator.runAdAuction で interestGroupBuyers パラメータを値として渡す必要があります。残りのオークション パラメータは、コンテキスト広告レスポンスの後に解決できる JavaScript Promise を受け入れます。interestGroupBuyers はコンテキスト広告レスポンスの前に渡されるため、コンテキスト広告レスポンス（入札レスポンスを含む）を使用して、特定のリクエストの並列化されたオークションに参加する購入者を選択することはできません。代わりに、Google パブリッシャー タグは、同じドメインでの以前の navigator.runAdAuction 実行の interestGroupBuyers パラメータをユーザーのブラウザにキャッシュに保存します。

並列化には、いくつかの重要な考慮事項があります。

  1. perBuyerSignals など、購入者の信頼できるサーバー リクエストに必要のないオークション シグナルは、並列化されていないオークションの場合と同様に、RTB 入札レスポンスで引き続き指定できます。これらのシグナルの Promise が解決されると、オンデバイス オークションの残りのステップは、並列オークション フローの場合と同様に完了します。

  2. 並列化はインタレスト グループの購入者のリストのキャッシュ保存に依存しているため、並列化キャッシュが空であるか期限切れになっている場合、Google は必ずしも並列オークションを実行しません。キャッシュが空または期限切れの場合、Google は標準の非並列 Protected Audience API オークションを実行し、購入者の意図を使用して非並列オークションに参加し、インタレスト グループの購入者キャッシュを構築します。

  3. 現在のパブリッシャー ドメインで 1 つ以上の購入者（いずれかの入札者）がキャッシュに保存されている場合、Google は並行オークションを実行します。これは入札リクエストで示されます。

    • Google RTB プロトコル: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. 並行オークションに含まれていた特定の入札者の登録済みインタレスト グループの各購入者オリジンには、対応する ParallelAuctionBuyer エントリがあります。

    • Google RTB プロトコル: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. 並行オークションが実行されていても、特定の購入者のオリジンがキャッシュに存在しない場合、その購入者を現在のオンデバイス オークションに追加することはできません。これは、特定のインタレスト グループの購入者のオリジンに対する ParallelAuctionBuyer エントリがない parallelized=True を含むリクエストで示されます。ただし、入札レスポンスに有効で対象となる InterestGroupBuyer を含めることで関心を示す入札者は、対応するインタレスト グループの購入者のオリジンがキャッシュに追加され、そのオリジンは同じブラウザとドメインからの今後の並列リクエストの対象となります。インタレスト グループ オークションへの参加意向は、次のフィールドで示すことができます。

    • Google RTB プロトコル: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. 入札者が入札レスポンスで参加の意向を示していない、キャッシュに保存された購入者のオリジン（並行オークションの interestGroupBuyers パラメータに含まれる）は、購入者の信頼できるサーバー呼び出しを受け取る可能性がありますが、並行オークションには参加しません。