Chrome はプライバシー サンドボックスの一環として、 Protected Audience API - ブラウザ内 API 広告主や広告テクノロジー企業がインタレスト グループ ターゲット広告を表示できる サードパーティ Cookie に依存することなく、クロスサイトからユーザーを保護できます。 トラッキングできます
Chrome でオリジン トライアル Protected Audience API の 3 つです認定バイヤーは アド マネージャーのパブリッシャー広告枠での Protected Audience API のテスト。 ビッダーは Protected Audience API をテストすることで、次のことが可能になります。
- Protected Audience API フローの有効性について学習していきます。
- 公開フォーラムで API の潜在的な改善点に関するフィードバックを生成する (例: GitHub)。
- API によるパーソナライズド広告のサポートに向けて準備する サードパーティ Cookie に依存しています
テストに関心のある認定バイヤーの方は、オンボーディング セクションをご覧ください。
サービング フローの概要
認定バイヤーの Protected Audience 広告配信フローの概要 パートナー:
- ビッダーは広告主と連携して、各タイプのインタレスト グループを管理する 広告主多くの場合 広告主はビッダーのタグを 広告主のページで、インタレスト グループにブラウザを追加します。
- エンドユーザーが広告主のページにアクセスします。このページには、ビッダーの できます。
- ビッダーのタグが Protected Audience API
joinAdInterestGroup()
を呼び出します。 この呼び出しにより、ユーザーをインタレスト グループに追加するようブラウザにリクエストされます。 - エンドユーザーがニュース メディアのウェブページにアクセスします。ユーザーのブラウザ リクエスト Google のパブリッシャー広告タグ。
- Google のパブリッシャー広告タグが、コンテキスト広告リクエストを Google サーバーに送信します。
- Google は参加しているビッダーにコンテキストに基づく入札リクエストを送信します。詳しくは、 詳しくは、入札リクエストの変更に関する記事をご覧ください。
- ビッダーは
interest_group_bidding
フィールドを含むBidResponse
を返します。 ビッダーがinterest_group_bidding
を指定していない場合、Google は オークションにinterestGroupBuyers
にビッダーの送信元を含める 構成をご覧ください。 入札レスポンスにはinterest_group_bidding.per_buyer_signals
を含めることもできます。per_buyer_signals
は、次のイベント中にビッダーの入札関数に渡されます。 行うことができます入札レスポンスの変更に関するページ セクションをご覧ください。 - Google がサーバーサイド オークションを実施し、入札レスポンスが できます。サーバーサイド オークションでは、従来のサーバーサイドの入札単価が考慮されます。 入札レスポンスには、コンテキストに応じた落札単価に関する情報が含まれることがあります( 問いません。
- 入札レスポンスには、ブラウザ内向けのオークション設定が含まれます。
決定しますこれには、参加している各購入者からのコンテキスト シグナルが含まれる場合があります。
(
interest_group_bidding.per_buyer_signals
経由で送信)、 落札のコンテキスト情報、入札の要件に関する設定。 - Google のパブリッシャー タグが Protected Audience API
runAdAuction()
を呼び出します。 オンデバイスインタレストグループのオークションを開始しますGoogle は 以前interest_group_bidding
を オークションの設定でinterestGroupBuyers
。 - Google は、条件を満たす各ビッダーの
per_buyer_signals
を Protected オーディエンス オークションの設定 - 特定のビッダーのインタレスト グループで
trustedBiddingSignalsUrl
。ブラウザは、各グループのtrustedBiddingSignalsUrl
: 各グループのリアルタイムのシグナルを取得します。詳しくは、 詳しくは、Protected Audience API 仕様をご覧ください。 - ブラウザで、インタレスト グループごとにビッダーの
generateBid()
が呼び出されます 入札可能で、ブラウザ内オークションに参加できる購入者のみです。この ステップで入札単価を計算して クリエイティブを選択しますgenerateBid()
は以下にアクセスできます: ビッダーから提供されたper_buyer_signals
と信頼できる入札 すべてのシグナルが表示されます - ブラウザは、販売者(この場合は Google)の
scoreAd()
を呼び出して、 インタレスト グループの広告オークションの各入札にランクが設定される。入札単価はランク付けされる パブリッシャーの保護設定や広告ポリシーなどに基づいて 必要があります。 - ブラウザで、インタレスト グループの有効な入札単価でオークションが実施されます。「 ブラウザ内オークションに参加する上位のコンテンツ ターゲットの入札単価
- オークション後に、落札したインタレスト グループがいる場合、ブラウザは
販売者の
reportResult()
とビッダーのreportWin()
に送られ、それぞれが通知されます。 落札します - インタレスト グループ広告が落札されると、Google のパブリッシャー タグによって広告が 使用できます。
サービングフローの詳細
広告配信前
クリエイティブの審査
クリエイティブを配信するには、Google による審査と承認が必要です
Protected Audience のブラウザ内オークション。審査のためにクリエイティブを送信できます
Real-time Bidding API または
クリエイティブの自動スキャンを使用する。クリエイティブの対象
Protected Audience のブラウザ内インタレスト グループの広告オークションには、次を含める必要があります
審査のためにrenderUrls
。
renderUrls
の要件:
- API を通じて送信される
renderUrl
は、使用するrenderUrl
と一致する必要があります。 1 つまたは複数表示されます - 各
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
文字列
に従ってエンコードされたクリエイティブの、宣言されたリンク先 URL のセット RFC2396 に準拠する必要があります。
例:
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 ディメンション)。
サーバーサイド オークション
入札リクエストの変更
以下は、 テスト:
インタレスト グループによるオークションのサポート
入札リクエストに新しいフィールド 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 API の状態を示す次のフィールドが含まれます。 オーディエンスの広告スロットサイズ:
- Google RTB プロトコル:
<ph type="x-smartling-placeholder">
- </ph>
BidRequest.adslot.interest_group_auction.width
BidRequest.adslot.interest_group_auction.height
- OpenRTB:
<ph type="x-smartling-placeholder">
- </ph>
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
)。
コンテキスト リクエストには複数のサイズが存在する場合があります。デバイス上のオークションの落札者 広告は 1 つの固定スロットサイズにのみ表示されると想定されます。
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 テストの対象となるコンテキスト 入札リクエストでは、
従来の Cookie ベースの識別子が
たとえば、google_user_id
(OpenRTB では BidRequest.user.id
)や
hosted_match_data
(OpenRTB では BidRequest.user.buyerid
)フィールド。存在感
の ID が引き続き既存の
遵守する必要があります。Cookie ベースの識別子は、
効率的にターゲティングや入札を
サードパーティ Cookie が使えなくなったときに広告枠を購入できます。
また、Google は Cookie ベースの識別子(Cookie ベースの識別子)を使用した小規模なテストを行う場合もあります。 Protected Audience API テストの対象となる入札リクエストから削除されました。この サードパーティ Cookie の廃止による影響を評価することです。
Chrome を利用したサードパーティ Cookie のサポート終了テスト
試験の準備には サードパーティ Cookie のサポート終了(3PCD) 2024 年に発表された Chrome は Chrome を利用したテスト。
サイトやベンダーは、Chrome を利用したテストを使用して、 3PCD。このテストでは、Chrome ブラウザは 3PCD テストグループに割り当てられます。 モード A と B のどちらかになります各ブラウザに一貫したラベルを割り当てる 特定の 3PCD テストグループに対応しています ブラウザ内 Chrome API を使用します。
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 パブリッシャー タグの呼び出し時に、設定の interestGroupBuyers
runAdAuction()
。
購入者のコンテキスト シグナル(perBuyerSignals)を伝播する
コンテキスト入札レスポンスに購入者のシグナルを含めると、Google が
オンデバイス入札機能に JSON オブジェクトとして渡され、
perBuyerSignals
引数。この情報は、
プロトコルに応じて、次のフィールドがあります。
- Google RTB:
BidResponse.interest_group_bidding.per_buyer_signals
- OpenRTB:
BidResponse.ext.igbid.igbuyer.buyerdata
購入者のコンテキスト レンダリング シグナルを伝達する
インタレスト グループ クリエイティブでは、レンダリング時に制限付きのコンテキスト シグナルが使用される場合があります。 コンテキスト入札レスポンスを通じてシグナルを送信し、 レンダリング URL リクエストでマクロ展開して表示します。たとえば シグナルを使用してクリエイティブのデザインをカスタマイズし、 特定の広告スロットやパブリッシャーのページのコンテキストでのパフォーマンス
URL セーフ文字列としてシリアル化された購入者のレンダリング シグナルを
コンテキストに基づく入札レスポンス(落札したインタレストで置き換えられます)
作成することで、グループ レンダリング URL を
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}
マクロ:
レンダリング シグナルは、以下を使用して入札レスポンスで指定できます。 プロトコルに応じて、次のように記述します。
- Google RTB:
BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
- OpenRTB:
BidResponse.ext.igbid.igbuyer.rsig
マクロの接尾辞が異なるレンダリング シグナルを 3 セットまで含めることができます 各シグナルを区別できます。例: 接尾辞 クリエイティブのみに適用される特定のシグナルセットとのマッチングに使用できる 対応するマクロがレンダリング URL に追加されるため、データ転送が 指定します。
インタレスト グループの購入者は、Protected プログラムに参加できなくなります オーディエンス オークション(シグナルが URL セーフでない場合、マクロの接尾辞が一意でない場合) 3 つ以上のシグナルセットが指定されている場合
ブラウザでの入札単価の上限を指定する
Protected Audience では、 提案の場合、入札単価の計算方法が 最終的なオークションは、ローカル デバイス上で実行されることが想定されています。これにより、 最終的なオークションの完全性に影響する可能性がある不正使用の経路 落札単価などの結果をお知らせします
Google による 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 を設定できます。購入者は 1 つまたは複数の 請求 ID はコンテキストの費用用で、もう 1 つはインタレスト グループの費用用です。 2 つの請求 ID を設定したい場合は、アカウント マネージャーにお問い合わせください 制限されています。
請求 ID ごとに 1 日の予算を設定できます。担当の アカウント マネージャーが子アカウントの請求 ID の 1 日の予算を設定する。
入札可能な予算があるすべての子アカウントの請求 ID 費用のアトリビューションを選択する場合は、入札リクエストにインプレッション数が表示されます。手を伸ばす インタレスト グループ請求 ID の予算を変更するには、アカウント マネージャーにお問い合わせください。
ブラウザ内オークション時
ブラウザでの入札単価を生成
ブラウザ内入札単価を生成するには、generateBid()
を使用します。
Google は次のパラメータを提供しています。
auctionSignals
: 空perBuyerSignals
: コンテキストに基づくレスポンスで
次のパラメータが返されます。
ad
: Google はこのフィールドを無視します。bid
: オークションに参加する数値による入札単価。CPM 単位で指定してください (マイクロではありません)。render
: 落札した場合にクリエイティブを表示するためにレンダリングされる URL 決定しますこの URL は Google の審査と承認が必要です。審査が行われない場合、URL は除外されます 入札から除外できますallowComponentAuction
:true
にする必要があります。Google は現在、 3 つあります
次の例をご覧ください。
function generateBid(...) {
...
return {'ad': 'example',
'bid': ad.metadata.bid,
'render': ad.renderUrl,
'allowComponentAuction': true};
}
Protected Audience の仕様(オンデバイス)
入札戦略
generateBid()
関数の説明をご覧ください。
入札単価の通貨
ブラウザでのオークションへの入札は、選択した入札通貨の CPM 単位で行われます。
入札の通貨は、コンテキスト入札レスポンスと
generateBid
の戻り値。有効な ISO 4217 アルファコード(
「USD」、「EUR」、「JPY」のように入力できます。
OpenRTB では、次のように InterestGroupBuyer
オブジェクトの新しい cur
フィールドを使用します。
Google の入札レスポンス表示オプション。
次の例をご覧ください。
ext {
igbid {
impid: "1"
igbuyer {
origin: "https://examplebuyerorigin.com"
cur: "EUR"
}
}
}
Google RTB プロトコルでは、currency
入札レスポンスの InterestGroupBuyer
メッセージ。
次の例をご覧ください。
interest_group_bidding {
adslot_id: 1
interest_group_buyer {
origin: "https://examplebuyerorigin.com"
currency: "EUR"
}
}
ビッダーgenerateBid
関数は、
コンテキストに基づく入札レスポンスで示されます。次の新しい bidCurrency
プロパティを入力します:
generateBid
の戻り値:
function generateBid(...) {
...
return {'ad': ad,
'bid': bid,
'bidCurrency': 'EUR',
...};
}
コンテンツ ターゲットの入札レスポンスの通貨が通貨と異なる場合
generateBid
から返されたものか、いずれかが無効な通貨を返した場合は、
オークションの前に除外されます
広告の品質チェック
クリエイティブ ポリシーとパブリッシャーの管理設定の適用は、 Protected Audience API の RTB テストにおけるブラウザ内インタレスト グループの入札単価 共有します
デジタル サービス法の支援
デジタル サービス法第 26 条に基づき、パブリッシャー様は購入者に対して
広告内の透明性の開示「DSA を使用する広告のみを表示するよう購入者に依頼する」
EEA のサイトやアプリに表示される透明性に関する情報」コントロールが有効になっている
インタレスト グループの購入者は、
購入者への透明性をレンダリングするために
必要な項目です
受信した入札リクエスト:
BidRequest.dsa.dsa_support
および BidRequest.dsa.publisher_rendering_support
認定バイヤーのプロトコルとBidRequest.regs.dsa.required
OpenRTB プロトコルの場合は BidRequest.dsa.pubrender
です。
Protected Audience API オークションへの参加を希望するビッダーが
DSA の透明性を表示する必要があるというシグナルを入札リクエストで受信する
Protected Audience API を介して配信される広告については、
必要な情報を適切に表示し、
BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render
認定バイヤーのプロトコルまたは
BidResponse.ext.igbid.igbuyer.dsaadrender
(OpenRTB プロトコルの場合)それ以外の場合は
購入者は Protected Audience API オークションに参加できません。
デジタル サービス法の「広告の透明性」について詳しくは、 ヘルプセンター記事: デジタル サービス法の支援
入札のフィルタリング
Google はニュース メディアを コントロールと広告 ポリシー オンデバイスのオークションで 入札されることになります
ブラウザでのオークション後
オークション結果を購入者に報告する: reportWin()
以下の引数は入力されません。
auctionSignals
sellerSignals
reportWin()
を使用して、オークション結果を購入者に報告します。
詳しくは、購入者向けレンダリングと広告に関するレポート イベント をご覧ください。
マクロ
Protected Audience API クリエイティブを参照する renderUrl
には以下を含めることができます。
1 つ以上のプレースホルダがありますインタレスト グループのオークション後
マクロはレンダリングの前に、対応する
使用できます。デバイス上のオークションで使用される renderUrl
には以下が含まれます
マクロ:
${GDPR}
|
GDPR が適用されていない場合は 0 に、GDPR が適用される場合は 1 に展開されます。ドキュメントをご覧ください。 |
${GDPR_CONSENT_XXXX}
|
透明性にまで拡大
およびリクエストに関連付けられた同意(TC)文字列。もし透明性と
同意(TC)文字列が空白または無効です。このマクロは展開されません。
このマクロは、IAB GVL に登録されているベンダーに URL で TC 文字列を渡す場合に使用します。
${GDPR_CONSENT_XXXX} マクロは、
renderUrl 。
|
${ADDL_CONSENT}
|
「その他の リクエストに関連付けられた同意(AC)文字列。 |
${AD_WIDTH}, ${AD_HEIGHT)
|
これらのマクロは、広告スロットの幅と高さを挿入します。 |
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}
|
レンダリング時の購入者シグナルを含むマクロ 入札レスポンスで指定されます
|
インプレッションのカウント
RTB パートナーを対象とした Protected Audience API テストでは、
ブラウザが reportResult()
関数を呼び出したときのインプレッションと、
その後、sendReportTo()
の呼び出しで Google のレポート URL を取得します。
Protected Audience のインプレッションのカウントに Google が使用するイベント ブラウザ内オークションは、カウントに使用されるイベントとは異なる場合があります。 インプレッション数が異なるため、インプレッション数は異なる場合があります。
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: 0
)で受信される可能性があります。
Protected Audience オークション。
リアルタイムのフィードバックと落札に必要な最小入札単価
ビッダーの入札が リアルタイムのフィードバック は、 オンデバイスの Protected Audience オークションです。個々のインタレストグループの購入者は では、入札レスポンスで 1 つの feedback オブジェクトを受け取ると、 Protected Audience オークションでインタレスト グループの購入者が入札した回数です。「 インタレスト グループの購入者のフィードバックでは、次の情報を確認できます オブジェクト:
- feedback オブジェクトの feedback タイプは、
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 が取得されます オークションが終了した後です以下のマクロは、 supported:
%%GOOGLE_QUERY_ID%%
: このマクロは Google クエリ ID に置き換えられます。 (認定バイヤー プロトコルのBidRequest.google_query_id
、 OpenRTB プロトコルのBidRequest.ext.google_query_id
)が、 Protected Audience 対応のコンテキストに基づく入札リクエスト。%%INTEREST_GROUP_OWNER%%
: インタレスト グループのオーナーのオリジン。%%BID_CPM%%
: 購入者がgenerateBid()
関数を使用します。%%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)がサポートされます。 説明します。テストの実施を予定している場合は、統合時にアカウント マネージャーにお知らせください (追加のリソースと構成が必要となるため)。
オンボーディング
Protected Audience API をテストする方法は次のとおりです。
手順
- リクエスト フォームに記入する Protected Audience API テストに参加できます。
- リクエスト フォームを送信したら、担当のアカウント マネージャーにお問い合わせいただくか、 チケットを作成する方法については、認定バイヤー ヘルプをご覧ください。 Center にあります。
- アカウントの構成が完了すると、Google とパートナー様の両者が テストステージの手順に沿って統合します。
広告の審査
商品単位の広告(複数の要素で構成される広告)を使用して入札するには 次の要件を満たす必要があります。
- 次のフィールドの
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 オークションを手動でトリガーして、広告が確実に インプレッションを記録します。
- Chrome 101 以降を使用してください。
- 以下を使用して Privacy Sandbox API と Fenced Frame を有効にします。
chrome://flags/#privacy-sandbox-ads-apis
、chrome://flags/#enable-fenced-frames
。詳しくは、プライバシーのテスト サンドボックスです。 - リアルタイム ビッダーを使用してクリエイティブを送信し、承認を得る API。
- ビッダー提供の広告主ページで、ビッダーが所有するブラウザにブラウザを追加する クリックします
Google 提供の以下のテスト パブリッシャー ページを使用して Protected オーディエンス オークション:
https://fledge-testing.uc.r.appspot.com/?nid=allow_all
ブラウザ内インタレスト グループは、オークションで勝つために十分に高い入札単価を設定している必要があります。これは、 従来のサーバーサイドの入札と競合する可能性があります。また Google では 各パートナーの専用テストページ オークションに参加できます確実に成約する方が簡単かもしれません パートナー固有のページでブラウザ内オークションを 簡単に実施できます
以下を確認します。
- 落札が予想された広告が表示される。
- オークション結果がサーバーサイドで送信(落札者)
reportWin()
から ping が返されます。 - テスト パブリッシャー ページのテスト コンソールには、各入札のデバッグ メッセージがログに記録されます。
次の情報を参照してください。
<ph type="x-smartling-placeholder">
- </ph>
renderUrl
: 入札のレンダリング URL。interestGroupOwner
: 入札単価のインタレスト グループのオーナー。accepted
: 入札が承認され、false
の場合、このフィールドはtrue
になります。 入札がscoreAd()
によって拒否された場合。externalBidStatus
: 入札が次の期間内に拒否された場合のステータス コードscoreAd()
。値はクリエイティブのステータス 。
ステージ 2: (省略可)レンダリング以外のテスト
Google とパートナーによる手動での確認が済んだら、 Protected Audience オークションに参加した場合、Google はパートナー様の 準備が整いました
Google が Protected Audience を実行するために、少量のライブ トラフィックを割り当てる 実施できますこれにより、Google とパートナーは手動で Protected Audience オークション。Protected Audience オークションの結果は 表示されます。これにより、統合を大規模にテストできます。
アカウント マネージャーにお問い合わせいただくか、認定バイヤーを通じてチケットを提出してください。 ヘルプセンターをご覧ください。 Google は、この段階でアカウントを有効にします。
ステージ 3: レンダリング テスト
Google とパートナーが Protected Audience オークションを大規模に検証した後 パートナーが Protected Storage オブジェクトを オーディエンスを獲得した広告。Google では、Protected に移行したトラフィックが少量で オーディエンス オークションを実施でき、インタレスト グループ広告を落札できるのは 表示されます。参加するビッダーの従来のブラウザとブラウザ内での入札単価が 入札できます。
アカウント マネージャーにお問い合わせいただくか、認定バイヤーを通じてチケットを提出してください。 ヘルプセンターをご覧ください。 Google は、この段階でアカウントを有効にします。
その他の機能
次の機能はコア プロトコルの拡張機能です。
並列化
並列化とは、エンドツーエンドのオークション レイテンシを短縮する最適化手法です。
コンテンツ ターゲット広告のリクエストと並行して、
購入者の信頼できるサーバー
trustedBiddingSignalsUrl
で指定します。
並列化によりレイテンシは短縮されますが、インタレスト グループには影響があります 購入者の要件とサポートを 共同テストも行います。 並列処理は、参加するすべてのビッダーに適用されます。 オンデバイスインタレストグループのオークションですビッダーは何もしなくても 同時に参加することもできますが、 並列化がデバイス上のオークションでの適格性に与える影響 調整されたテストのテストグループ ID はまだサポートされていません 1 つのオークションに入札できます
サービング フローの概要
オークションの並行フローの概要は次のとおりです。
オンデバイス インタレスト グループの購入者の利用資格
並行オークションの場合、navigator.runAdAuction
の呼び出しは前に行われます
コンテキスト広告レスポンスが返されます。購入者との信頼関係を
使用すると、navigator.runAdAuction
では、
interestGroupBuyers
パラメータは
渡され、残りのオークション パラメータは JavaScript を受け付けます。
コンテキスト広告レスポンスの後に解決できる Promise。以降
コンテキスト広告レスポンスの前に interestGroupBuyers
が渡されます。
コンテキストに基づく広告レスポンス(入札レスポンスを含む)
同時オークションに参加する購入者を選択することはできません
表示されます。代わりに Google のパブリッシャータグは
ユーザーのブラウザで、前のステップの interestGroupBuyers
パラメータが
同じドメイン上での navigator.runAdAuction
件の実行があります。
並列化にはいくつかの重要な考慮事項があります。
購入者の信頼できるサーバー リクエストに必要ないオークション シグナル
perBuyerSignals
などは、RTB 入札レスポンスで引き続き指定できます。 通常のオークションと同じ方法で入札できます これらのシグナルの Promise が解決されると、 オークションは非並列オークションと同様に完了します。 決定します並列処理ではインタレスト グループ購入者のリストをキャッシュに保存するため、 Google は並列オークションを常に実行するわけではなく、並列化キャッシュ 空白か期限切れの可能性があります。キャッシュが空または期限切れになっている場合は、 標準の非並列 Protected Audience API オークションに入札し、購入者の意向に基づいて 非並行オークションに参加して、インタレスト グループの購入者キャッシュを構築する。
現在のパブリッシャーについて、任意のビッダーの購入者が少なくとも 1 つキャッシュされている場合 作成されている場合、Google は複数の 入札リクエストに表示されます。
- Google RTB プロトコル:
BidRequest.adslot.interest_group_auction.parallelized
- OpenRTB:
BidRequest.imp.ext.interest_group_auction.parallelized
- Google RTB プロトコル:
特定のビッダーに対する、登録済みインタレスト グループの購入者元それぞれ 同時オークションの対象となった場合、
ParallelAuctionBuyer
エントリ:- Google RTB プロトコル:
BidRequest.adslot.interest_group_auction.parallel_auction_buyer
- OpenRTB:
BidRequest.imp.ext.interest_group_auction.pbuyer
- Google RTB プロトコル:
並行オークションが実施されているが、特定の購入者の配信元が その購入者を現在のデバイス上の デバイスに追加することはできません 決定しますこれは、
parallelized=True
を含むリクエストで、 特定のインタレスト グループの購入者のオリジンに対するParallelAuctionBuyer
エントリ。 ただし、有効かつ適格な入札を含めることで関心を示しているビッダーは、InterestGroupBuyer
(入札レスポンスに対する入札レスポンス) 対応するインタレストグループの購入者と キャッシュに追加されたオリジンは、キャッシュ内の 同じブラウザおよびドメインから将来的に並列リクエストを実行できます。 インタレスト グループ オークションへの参加の意向 次のフィールドで確認できます。- Google RTB プロトコル:
BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB:
BidResponse.ext.igbid.igbuyer
- Google RTB プロトコル:
キャッシュに保存された購入者のオリジン(並行オークションに含まれる
interestGroupBuyers
パラメータなど)に、入札者がインテントを示していないもの 入札レスポンスに参加すると、購入者が信頼できるサーバー呼び出しを受け取ります。 同時オークションには参加しません