Protected Audience API（旧 FLEDGE）

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

Chrome でオリジン トライアル Protected Audience API の 3 つです認定バイヤーは アド マネージャーのパブリッシャー広告枠での Protected Audience API のテスト。 ビッダーは Protected Audience API をテストすることで、次のことが可能になります。

• Protected Audience API フローの有効性について学習していきます。
• 公開フォーラムで API の潜在的な改善点に関するフィードバックを生成する （例: GitHub）。
• サードパーティ Cookie に依存せずに、API を介してパーソナライズド広告をサポートする準備をします。

テストにご興味をお持ちの認定バイヤーは、オンボーディング セクションで詳細をご確認ください。

ベータ版: ここで説明する動作は、今後の テストを実施し、パブリッシャーと認定バイヤーからフィードバックを収集できます。

注: Protected Audience API のテストは認定バイヤーのみを対象としています。 Open Bidding に参加しているエクスチェンジおよびネットワーク入札者はサポートされていません。

注: Protected Audience API（旧 FLEDGE）が アド マネージャーでは、 トラフィック量に応じて異なります。パブリッシャーへの影響をモニタリングします トラフィックの割合を少しずつ増やしながら 顕著な悪影響がある場合は さらに複雑になります2023 年末までに、Chrome トラフィックの最大 10% が Protected Audience 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() を呼び出して、デバイス上のインタレスト グループ オークションを開始します。入札の構成時に 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 内にレンダリングされます。

サービング フローの詳細

広告配信前

クリエイティブの審査

クリエイティブを配信するには、Google による審査と承認が必要です Protected Audience のブラウザ内オークション。審査のためにクリエイティブを送信できます Real-time Bidding API または クリエイティブの自動スキャンを使用する。クリエイティブの対象 Protected Audience のブラウザ内インタレスト グループの広告オークションには、次を含める必要があります 審査のためにrenderUrls。

renderUrls の要件:

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

Real-time Bidding 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 日間有効です。リアルタイム ビッダーを使用してクリエイティブを送信すると、 15 日経過したらクリエイティブを再送信する必要があります。クリエイティブの自動スキャンを使用している場合、スキャン プロセスによってクリエイティブが自動的に再スキャンされます。

購入者のレポート ID

ディメンションを使用してレポート指標（インプレッションなど）を分類できる （キャンペーン ID や広告主 ID など）。スペースを追加するには、 インタレスト グループの費用のディメンションの場合、buyerAndSellerReportingId を ユーザーのデバイスをインタレスト グループに追加すると、自動的に広告に追加されます。さらに表示 詳しくは、Protected Audience ドキュメントをご覧ください。

buyerAndSellerReportingId をプロジェクトに追加する方法の例を次に示します。 次のように変更します。

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

buyer_reporting_id は、正式な購入者のレポート ツールに「購入者のレポート ID ディメンション」という新しいディメンションとして表示されます。

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

入札リクエストの変更

以下は、 テスト:

• OpenRTB 早期リンク
• Google RTB プロトコル（サポート終了）早期リンク

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

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

• OpenRTB: <ph type="x-smartling-placeholder">
  </ph>
  • 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 の広告スロットサイズを指定する

入札リクエストには、Protected API の状態を示す次のフィールドが含まれます。 オーディエンスの広告スロットサイズ:

• OpenRTB: <ph type="x-smartling-placeholder">
  </ph>
  • BidRequest.imp.ext.interest_group_auction.width
  • BidRequest.imp.ext.interest_group_auction.height
• Google RTB プロトコル（サポート終了）: <ph type="x-smartling-placeholder">
  </ph>
  • 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 フィールド。

コンテキスト リクエストには複数のサイズが存在する場合があります。オンデバイス オークションで落札した広告は、1 つの固定スロットサイズにのみ配信されます。

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

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

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

また、Protected Audience API のテスト対象となるビッドリクエストから Cookie ベースの識別子を削除する小規模なテストも実施される場合があります。これは、サードパーティ Cookie の廃止による影響を評価するためのものです。

Chrome を利用したサードパーティ Cookie のサポート終了テスト

試験の準備には サードパーティ Cookie のサポート終了（3PCD） 2024 年に発表された Chrome は Chrome を利用したテスト。

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

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

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

• 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 を含める必要があります。これは、ビッダーがアカウント用に構成した出発地のいずれかと一致する必要があります。origin がオークションに追加されました 設定の interestGroupBuyers（Google パブリッシャー タグから runAdAuction()。

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

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

• OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
• Google RTB（非推奨）: BidResponse.interest_group_bidding.per_buyer_signals

購入者のコンテキスト レンダリング シグナルを伝達する

インタレスト グループ クリエイティブでは、レンダリング時に制限付きのコンテキスト シグナルが使用される場合があります。 コンテキスト入札レスポンスを通じてシグナルを送信し、 レンダリング URL リクエストでマクロ展開して表示します。たとえば シグナルを使用してクリエイティブのデザインをカスタマイズし、 特定の広告スロットやパブリッシャーのページのコンテキストでのパフォーマンス

警告: この機能は deprecatedRenderURLReplacements ブラウザのサポートに依存します。

購入者のレンダリング シグナルを 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 （microCPM で表記）

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

ビッダーは、請求 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 はコンテキストの費用用で、もう 1 つはインタレスト グループの費用用です。 2 つの請求 ID を設定したい場合は、アカウント マネージャーにお問い合わせください 制限されています。

請求 ID ごとに 1 日の予算を設定できます。子アカウントのお支払い ID の 1 日の予算を設定するには、アカウント マネージャーにお問い合わせください。

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

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

ブラウザでの入札単価を生成

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

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

• auctionSignals: 空
• perBuyerSignals: コンテキストに基づくレスポンスで

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

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

次の例をご覧ください。

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 によって返された通貨と異なる場合、またはどちらかが無効な通貨を返した場合、入札はオークションの前に除外されます。

広告の品質チェック

クリエイティブ ポリシーとパブリッシャーの管理設定の適用は、 Protected Audience API の RTB テストにおけるブラウザ内インタレスト グループの入札単価 共有します

デジタル サービス法の支援

デジタル サービス法第 26 条に基づき、パブリッシャーは購入者に広告内の透明性に関する開示を表示するよう求める場合があります。「DSA を使用する広告のみを表示するよう購入者に依頼する」 EEA のサイトやアプリに表示される透明性に関する情報」コントロールが有効になっている インタレスト グループの購入者は、 購入者に透明性を提供するために 入札単価: BidRequest.regs.dsa.required、BidRequest.dsa.pubrender リクエスト（BidRequest.dsa.dsa_support と （非推奨）には、それぞれ BidRequest.dsa.publisher_rendering_support Google RTB プロトコルなど）が使用されます。

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()

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

• auctionSignals
• sellerSignals

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

詳しくは、購入者向けレンダリングと広告に関するレポート イベント をご覧ください。

マクロ

注: マクロは Protected Audience API のテスト用に設計されているため、将来的にサポートが終了する可能性があります。

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

${GDPR}	GDPR が適用されていない場合は 0 に、GDPR が適用される場合は 1 に展開されます。ドキュメントをご覧ください。
${GDPR_CONSENT_XXXX}	透明性にまで拡大 &リクエストに関連付けられた同意（TC）文字列。もし透明性と 同意（TC）文字列が空白または無効です。このマクロは展開されません。 このマクロは、IAB GVL に登録されているベンダーに URL で 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 のブラウザ内オークションでインプレッションのカウントに使用されるイベントは、RTB 購入者パートナーがインプレッションのカウントに使用するものとは異なる可能性があるため、インプレッション数は異なる場合があります。

Protected Audience API をテストする目的の一つは、 差異を減らすことができます

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

Protected Audience のブラウザ内オークションで支払われたビッダーの費用は、すべて 1 つの入札者アカウントに紐付けられます。 ビッダーに設定されたグループ オーナーのオリジン。費用の要因別 ビッダーの子シート アカウントはサポートされていません。

1 日の予算の上限

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

その後も、アカウントはサーバーサイドのコンテキスト オークションに引き続き参加できます。 Protected Audience の上限に近づいています。たとえば、100 ミリ秒以内に 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 は一時的なデバッグを API Protected Audience API により、アド マネージャーで フィードバックを含むサーバー間のデバッグ通知に、Protected オーディエンスの入札単価。この通知には、入札が行われなかった可能性のある理由が示されます。 Protected Audience のブラウザ内オークションで除外されます。 入札単価に関する情報が表示されます。

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

• %%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

複数の要素で構成される広告 または商品レベル TURTLEDOVE Google RTB パートナーは Protected Audience API の期間中、PLTD（PLTD）がサポートされます。 説明します。PLTD をテストする予定がある場合は、追加のリソースと構成が必要になるため、統合時にアカウント マネージャーに伝えてください。

オンボーディング

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

手順

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

広告の審査

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

• 次のフィールドの renderUrl に &pltd=True クエリ パラメータを含めます。 コンポーネント広告のコンテナ（最上位の renderUrl ともいいます）を、 クリエイティブの審査時にトップレベルの renderUrls を区別できるようになりました。
• 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. 以下を使用して Privacy Sandbox API と Fenced Frame を有効にします。 chrome://flags/#privacy-sandbox-ads-apis、 chrome://flags/#enable-fenced-frames。詳しくは、プライバシーのテスト サンドボックスです。
3. Real-time Bidding API を使用して、クリエイティブを送信して承認を得る。
4. ビッダー提供の広告主ページで、ビッダーが所有するブラウザにブラウザを追加する クリックします

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

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

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

6. 以下を確認します。

   1. 想定される落札広告が表示されます。
   2. オークションの結果はサーバーサイドで送信されます。つまり、落札した入札者は reportWin() から ping バックを受け取ります。
   3. テスト パブリッシャー ページのテスト コンソールには、各入札のデバッグ メッセージがログに記録されます。 次の情報を参照してください。 <ph type="x-smartling-placeholder">
      </ph>
      • 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 オークションを大規模に検証した後 パートナーが Protected Storage オブジェクトを オーディエンスを獲得した広告。Google では、Protected に移行したトラフィックが少量で オーディエンス オークションを実施でき、インタレスト グループ広告を落札できるのは 表示されます。参加ビッダーのブラウザ内入札は、従来の入札と競合します。

準備ができたら、アカウント マネージャーにお問い合わせいただくか、認定購入者ヘルプセンターからチケットを提出してください。このステージでは、アカウントが有効になります。

その他の機能

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

並列化

並列化とは、エンドツーエンドのオークション レイテンシを短縮する最適化手法です。 コンテンツ ターゲット広告のリクエストと並行して、 購入者の信頼できるサーバー trustedBiddingSignalsUrl で指定します。

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

サービング フローの概要

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

オンデバイス インタレスト グループの購入者の利用資格

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

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

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. パラレル オークションが実行されていても、特定の購入者のオリジンがキャッシュに存在しない場合、その購入者は現在のデバイス上のオークションに追加できません。これは、parallelized=True を含むリクエストで、 特定のインタレスト グループの購入者のオリジンに対する ParallelAuctionBuyer エントリ。 ただし、有効かつ適格な入札を含めることで関心を示しているビッダーは、 InterestGroupBuyer（入札レスポンスに対する入札レスポンス） 対応するインタレストグループの購入者と キャッシュに追加されたオリジンは、キャッシュ内の 同じブラウザおよびドメインから将来的に並列リクエストを実行できます。 インタレスト グループ オークションへの参加の意向は、次のフィールドで指定できます。

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

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