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 API のテストをご利用いただけるのは、認定バイヤーのみです。Open Bidding に参加するエクスチェンジ入札者とネットワーク入札者はまだサポートされていません。

注: Chrome で Protected Audience API（旧 FLEDGE）の一般提供が開始されると、アド マネージャーではテスト対象のトラフィック量を徐々に増やしていきます。Google では、トラフィックの割合を少しずつ増やしながら、パブリッシャー様の収益への影響を注視し、顕著な悪影響がある場合はそれ以上の引き上げを行いません。2023 年末までに、Chrome トラフィックの最大 10% が Protected Audience API のテスト対象となる見込みです。

サービング フローの概要

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

1. ビッダーは広告主と連携して、広告主ごとにインタレスト グループを管理します。広告主は、インタレスト グループにブラウザを追加するために、広告主のページにビッダーのタグを追加することがよくあります。
2. エンドユーザーが広告主のページにアクセスします。このページには、ビッダーのタグが含まれている場合があります。
3. ビッダーのタグが Protected Audience API joinAdInterestGroup() を呼び出します。この呼び出しは、ユーザーをインタレスト グループに追加するようブラウザにリクエストします。
4. エンドユーザーがパブリッシャーのウェブページにアクセスします。ユーザーのブラウザが Google のパブリッシャー広告タグをリクエストします。
5. Google のパブリッシャー広告タグが Google サーバーにコンテキスト広告リクエストを行います。
6. Google がコンテンツ ターゲットの入札リクエストを入札者に送信します。詳しくは、入札リクエストの変更セクションをご覧ください。
7. ビッダーは、interest_group_bidding フィールドを含む BidResponse を返します。ビッダーが interest_group_bidding を指定していない場合、Google はオークションの設定の interestGroupBuyers にビッダーのオリジンを含めません。入札レスポンスには interest_group_bidding.per_buyer_signals を含めることもできます。 per_buyer_signals は、ブラウザ内オークション中にビッダーの入札関数に渡されます。詳しくは、入札レスポンスの変更に関するセクションをご覧ください。
8. Google がサーバーサイド オークションを実施し、ブラウザに入札レスポンスを返します。サーバーサイド オークションでは、従来のサーバーサイドの入札が考慮されます。 入札レスポンスには、コンテキストで落札した入札に関する情報（存在する場合）を含めることができます。
9. 入札レスポンスには、ブラウザ内オークションのオークション設定が含まれます。これには、参加する各購入者のコンテキスト シグナル（interest_group_bidding.per_buyer_signals を介して送信されたもの）、コンテキスト落札情報、入札資格の設定が含まれます。
10. Google のパブリッシャー タグが Protected Audience API runAdAuction() を呼び出し、デバイス上のインタレスト グループ オークションを開始します。オークション構成で以前に interest_group_bidding を interestGroupBuyers として返した購入者のみが含まれます。
11. Google は、対象となる各ビッダーの per_buyer_signals を Protected Audience オークション構成に渡します。
12. 特定のビッダーのインタレスト グループで trustedBiddingSignalsUrl が指定されている場合、ブラウザは各グループの trustedBiddingSignalsUrl にリクエストを送信して、各グループのリアルタイム シグナルを取得します。詳しくは、Protected Audience API の仕様をご覧ください。
13. ブラウザは、オプトインされ、ブラウザ内オークションに参加する資格があるインタレスト グループごとに、ビッダーの generateBid() を呼び出します。このステップでは、入札単価を計算し、クリエイティブを選択します。generateBid() は、ビッダーが提供する per_buyer_signals と、指定されたインタレスト グループに対する信頼できる入札シグナルにアクセスできます。
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

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

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

ビッダーは、Realtime Bidding 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 は、認定バイヤーのレポートツールに新しいディメンションとして購入者のレポート ID ディメンションとして表示されます。

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

入札リクエストの変更

テストでの使用がサポートされているプロトコルの初期バージョンは次のとおりです。

• Google RTB プロトコルの早期リンク
• OpenRTB 早期リンク

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

入札リクエストに新しいフィールド auction_environment が追加されました。

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

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

• SERVER_SIDE_AUCTION（OpenRTB JSON: 0）: 従来のサーバーサイド オークション
• ON_DEVICE_INTEREST_GROUP_AUCTION（OpenRTB JSON: 1）: Protected Audience をサポートするリクエスト。このケースでは、コンテキスト オークションがエクスチェンジのサーバーで実施され、インタレスト グループでの入札と最終的なオークションがブラウザで実行されます。

Protected Audience の広告スロットサイズを指定する

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

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

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

このサイズは、コンテキスト リクエストのサイズ（Adslot.width と Adslot.height、または OpenRTB では BidRequest.imp.banner.format）とは異なる場合があります。

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

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

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

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

ユーザー ID への依存を最小限に抑える

Protected Audience API のテスト範囲内のコンテキスト入札リクエストでは、google_user_id（OpenRTB の BidRequest.user.id）フィールドや hosted_match_data（OpenRTB の BidRequest.user.buyerid）フィールドなど、ブラウザで使用可能な場合、引き続き従来の Cookie ベースの識別子を保持できます。入札リクエストにこのような識別子が含まれている場合、既存のプライバシー ポリシーは引き続き適用されます。テスト中は、サードパーティ Cookie が使用できなくなっても効率的に購入できるように、ターゲティングや入札で Cookie ベースの識別子に依存しないことをおすすめします。

また、Protected Audience API のテスト範囲内で、入札リクエストから Cookie ベースの識別子を削除する小規模なテストを行う場合もあります。サードパーティ Cookie のサポート終了による影響を評価する。

Chrome がサポートするサードパーティ Cookie のサポート終了テスト

2024 年のサードパーティ Cookie のサポート終了（3PCD）に備え、Chrome では Chrome を活用したテストを提供しています。

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

Google は、RTB 入札リクエストで Chrome API から取得した未変更のラベルを渡します。個々のラベルのトラフィック スライスは小さいため、プライバシーが限られている状況では必ずしもラベルが含まれるとは限りません。

ラベルを表示する項目は次のとおりです。

• Google RTB プロトコル: BidRequest.device.cookie_deprecation_label
• OpenRTB: BidRequest.device.ext.cdep

入札レスポンスの変更

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

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

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

コンテンツ ターゲットの入札レスポンスを指定する必要があります。レスポンスにコンテキスト入札を含める必要はありません。InterestGroupBidding オブジェクトにはインタレスト グループのオーナーの origin を含める必要があります。これは、ビッダーが自分のアカウントに設定したオリジンのいずれかと一致する必要があります。origin は、Google パブリッシャー タグが runAdAuction() を呼び出したときにオークション設定の interestGroupBuyers に追加されます。

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

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

• Google RTB: BidResponse.interest_group_bidding.per_buyer_signals
• OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

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

Protected Audience の提案では、入札単価の計算と最終的なオークションは、デバイス上でローカルに実行することが想定されています。これにより、落札単価など、最終的なオークション結果の整合性に影響を与える不正行為のベクトルが生じる可能性があります。

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

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

• Google RTB プロトコル: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros （microCPM で表記）
• OpenRTB: BidResponse.igbid.igbuyer.maxbid（CPM 通貨単位で表示）

インプレッションを複数のアカウントに関連付ける

ビッダーは、以下のフィールドを使用して請求 ID を選択し、インタレスト グループ入札のインプレッションを関連付ける必要があります。

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

選択した請求 ID は、入札リクエストに含まれている有効な請求 ID である必要があります。

• Google RTB プロトコル: BidRequest.adslot.matching_ad_data.billing_id
• OpenRTB: BidRequest.imp.ext.billing_id

インタレスト グループ入札のインプレッションに関連付けられる請求 ID が指定されていない場合、ビッダーは Protected Audience のオークションに参加しません。

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

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

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

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

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

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

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

• auctionSignals: 空
• perBuyerSignals: コンテキスト レスポンスで入札者から提供されるのと同じシグナルを持つ JavaScript オブジェクト。

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

• ad: このフィールドは無視されます。
• bid: オークションに参加する入札単価の数値。マイクロ単位ではなく CPM 単位で入力してください。
• render: オークションで落札した場合、クリエイティブを表示するためにレンダリングされる URL。Google がこの URL を審査して承認する必要があります。承認しないと、この URL はオークションから除外されます。
• 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 テスト中は、ブラウザ内のインタレスト グループ入札に対して、クリエイティブ ポリシーとパブリッシャーの管理設定の適用が、より厳しくなる可能性があります。

デジタル サービス法（Digital Services Act）の支援

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

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

デジタル サービス法による広告の透明性について詳しくは、ヘルプセンターの記事: デジタル サービス法のサポートをご覧ください。

入札フィルタ

デバイス上のオークションでは、Google がパブリッシャーの管理設定と広告ポリシーを適用します。

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

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

次の引数は入力されません。

• auctionSignals
• sellerSignals

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

詳しくは、Protected Audience API 説明ページのレンダリング イベントと広告イベントに関する購入者のレポートをご覧ください。

マクロ

注: マクロは 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)	これらのマクロにより、広告スロットの幅と高さが挿入されます。

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

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

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

Protected Audience API のテストに関する Google の目標の一つは、このような不一致を特定して削減することです。

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

Protected Audience のブラウザ内オークションでのビッダーの費用はすべて、そのビッダーに対して設定されたインタレスト グループ オーナーのオリジンのマッピングに基づいて、単一のビッダー アカウントに結び付けられます。ビッダーの異なる子シート アカウントに費用を割り当てることはできません。

1 日の予算の上限

Protected Audience API のテスト中、各アカウントには、Protected Audience の 1 日の予算にアカウント単位で上限が設定されます。1 日の予算の上限により、ブラウザ内オークション環境におけるリスクが制限されます。1 日の予算の上限に達すると、アカウントは Protected Audience の対象となる入札リクエストを受信しなくなります。

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

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

リアルタイムのフィードバックの受け取りを有効にしているビッダーは、デバイス上の Protected Audience オークションへの参加がリクエストされたインタレスト グループ購入者からのフィードバックを受け取ります。ビッダーが入札レスポンスで指定したインタレスト グループの各購入者は、インタレスト グループの購入者が Protected Audience のオークションに入札した数に関係なく、1 つのフィードバック オブジェクトを受け取ります。インタレスト グループの購入者のフィードバック オブジェクトでは、次の情報を確認できます。

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

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

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

Chrome には Protected Audience API 用の一時的なデバッグ API が用意されています。この API を使用すると、アド マネージャーは Protected Audience の入札に関するフィードバックを含むサーバー間デバッグ通知をリアルタイムで送信できます。この通知には、以下で説明する入札単価に関するその他の情報に加え、Protected Audience のブラウザ内オークションで入札が除外された理由が含まれます。

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

• %%GOOGLE_QUERY_ID%%: このマクロは、Protected Audience が有効になっているコンテキスト入札リクエストで送信された Google クエリ ID（認定バイヤー プロトコルでは BidRequest.google_query_id、OpenRTB プロトコルでは BidRequest.ext.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 に依存する一時的な機能です。

クリック イベント

ビッダーは、Fenced Frame Reporting API を使用して、Protected Audience 広告のクリック イベントを Google に報告できます。ビッダーは、click イベントタイプを使用して Google にクリックを通知する必要があります。次の例をご覧ください。

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

商品単位の TURTLEDOVE

Google RTB パートナーは、Protected Audience API のテスト時に、複数の要素で構成される広告または商品単位の 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 テストに関連する広告枠のプレターゲティングを設定します。
• 審査と承認を受けるために、Creatives 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. Real-time Bidding 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: （省略可）レンダリングしないテスト

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

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

準備が整ったら、アカウント マネージャーにご連絡いただくか、認定バイヤー ヘルプセンターからチケットを提出してください。Google がこの段階でアカウントを有効にします。

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

Google とパートナーが、Protected Audience オークションをレンダリングせずに大規模に検証すると、Google はパートナーが Protected Audience 落札広告をレンダリングできるようになります。Protected Audience オークションが実施できる少量のトラフィックがあり、落札したインタレスト グループ広告が表示されます。参加するビッダーのブラウザ内の入札は、従来の入札と競合します。

準備が整ったら、アカウント マネージャーにご連絡いただくか、認定バイヤー ヘルプセンターからチケットを提出してください。Google がこの段階でアカウントを有効にします。