リクエストを処理する

リアルタイム ビッダーのインタラクションは、Google が入札リクエストを 説明します。このガイドでは、アプリケーションをコーディングし、 入札リクエストが処理されます

リクエストを解析する

Google は入札リクエストを、シリアル化されたプロトコル バッファとして HTTP POST リクエストのバイナリペイロードContent-Type の設定 application/octet-stream。例については、入札リクエストの例をご覧ください。

このリクエストをパースして BidRequest のインスタンスに変換する必要があります。 表示されます。BidRequest は realtime-bidding.proto で定義されます。 これは参照データのページから取得できます。メッセージは、 生成されたクラスの ParseFromString() メソッドを使用して、 BidRequest。たとえば、次の C++ コードはリクエストを解析します。 POST ペイロードを文字列に格納すると、次のようになります。

string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
  // Process the request.
}

BidRequest を取得したら、それを次のように操作できます。 必要なフィールドを抽出、解釈します。たとえば、 C++:

for (int i = 0; i < bid_request.adslot_size(); ++i) {
  const BidRequest_AdSlot& adslot = bid_request.adslot(i);
  // Decide what to bid on adslot.
}

BidRequest で送信される一部の情報（Google ユーザーなど） ID、言語、地理的位置は常に利用できるとは限りません。<ph type="x-smartling-placeholder"></ph> 特定のキャンペーンについて不明な情報を使用する、広告グループをプレターゲティングする それらの広告グループは一致しません指標が見つからない場合は、 どの情報に関係ないかは関係なく、入札リクエストは 情報を省略して送信します。

プレターゲティング広告グループに関する情報は、 AdSlot ごとの MatchingAdData グループ。これには、 広告表示につながったプレターゲティング広告グループの最初に一致した広告グループ ID 入札リクエスト（請求対象の広告グループとキャンペーン）を送信する レスポンスがインプレッションのオークションを落札した場合一定の割合の下 billing_id を明示的に指定する必要があります。 BidResponse.AdSlotたとえば、ユーザーが BidRequest.AdSlot に matching_ad_data が複数あります。 入札内容に対する制約について詳しくは、このモジュールの realtime-bidding.proto。

辞書ファイル

入札リクエストでは、辞書ファイルで定義された識別子が使用されます。 （参照データを参照） できます。

入札 URL マクロ

必要に応じて、BidRequest のいくつかのフィールドを HTTP POST リクエストで使用される URL。これは、たとえば、kubectl の ロード バランシングを行う軽量のフロントエンドで、 取得されます。テクニカル アカウント マネージャーに連絡して、 作成します。

マクロ説明
%%GOOGLE_USER_ID%%

google_user_id に置き換え BidRequest から取得します。たとえばビッダーの URL が 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 は、次のようになります。 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 指定することもできます。

Google ユーザー ID が不明な場合は、空の文字列に置き換えられ、 次のような結果が

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

次の呼び出し時に 1 または 0 に置き換えられます。 BidRequest さんの has_mobile()。
%%HAS_VIDEO%%

1（true）または 0（false）に置き換えられます。 BidRequest の has_video() の呼び出し時。
%%HOSTED_MATCH_DATA%%

hosted_match_data フィールドの値に置き換えられます。 BidRequest から取得します。
%%MOBILE_IS_APP%%

1（true）または 0（false）に置き換えられます。 BidRequest の mobile.is_app フィールドから取得します。

取引 URL からモバイルアプリ ID を確認する

モバイル アプリケーションのトランザクションでは、次のような URL がレポートされます。

mbappgewtimrzgyytanjyg4888888.com

base-32 デコーダを使用して、文字列の太字部分をデコードします。 （gewtimrzgyytanjyg4888888）。

オンライン decoder になりますが、文字を大文字にし、末尾を = 値を持つ 8。

この値をデコードすると次のようになります。 

GEWTIMRZGYYTANJYG4======
 結果は次のようになります。 
1-429610587
 文字列 429610587 は、iOS アプリのアプリ ID です。 iFunny。

別の例を次に示します。報告された URL は次のとおりです。 

mbappgewtgmjug4ytmmrtgm888888.com
 この値をデコードすると、次のようになります。 
GEWTGMJUG4YTMMRTGM======
 結果は次のようになります。 
1-314716233
 結果の 314716233 が iOS アプリのアプリ ID になります。 TextNow。

取引 URL からモバイルアプリ名を確認する

以下は、アプリ名を取得する例です。報告された URL は次のとおりです。 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 この値をデコードすると、次のようになります。 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
 結果は次のようになります。 
air.com.hypah.io.slither
 結果は Android アプリと同じ slither.io.

Open Bidding フィールド

Open に参加しているエクスチェンジとネットワーク入札者に送信される入札リクエスト 入札は、スタンダード ティアの認定バイヤーの入札と リアルタイム ビッダーOpen Bidding のお客様には、ごく一部の 既存の一部のフィールドについては、別の用途がある場合があります。これらの 次の内容が含まれます。

OpenRTB 認定バイヤー 詳細
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

パブリッシャーのアド マネージャー ネットワーク コードの後に広告が続きます 単位階層構造をスラッシュで区切って示しています

たとえば、次のような形式で表示されます。 /1234/cruises/mars。
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

パブリッシャーからエクスチェンジ ビッダーに送信される Key-Value ペアの繰り返し。

値は、ファイアウォール ルールによって BidRequest.user.data[].name が次の値に設定されている場合のパブリッシャー “Publisher Passed”。

許可されたベンダーを宣言する

調査、リマーケティング、 広告配信は、購入者と販売者のやり取りで役割を担う場合があります。単独 Google が認定した認定バイヤー参加ベンダー やり取りが許可されています。

BidRequest について理解を深め、 BidResponse さんの場合、この 2 つの違いに注意する必要があります。 次のテクノロジー ベンダーを宣言します。

  1. 宣言が不要なベンダーもあります。利用できるベンダーについては、認定バイヤーのヘルプをご覧ください。
  2. それ以外のベンダーは、 BidRequest と BidResponse: <ph type="x-smartling-placeholder">
      </ph>
    • BidRequest の allowed_vendor_type フィールドには、販売者が許可しているベンダーを指定します。送付されるベンダー BidRequest の allowed_vendor_type フィールドが Vendors.txt に記載されている あります。
    • BidResponse の vendor_type フィールド は、許可されたベンダーの中から購入者が使用する予定のベンダーを指定します。

入札リクエストの例

次の例は、人間が読める形式の Protobuf サンプルと JSON リクエスト。

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

入札リクエストをバイナリ形式に変換するには、 POST ペイロードを実際のリクエストで呼び出す場合は、次のことができます（C++ の場合）。注: OpenRTB JSON には適用されません。

string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
  string post_payload;
  if (bid_request.SerializeToString(&post_payload)) {
    // post_payload is a binary serialization of the protocol buffer
  }
}

リマーケティング

認定バイヤーは、入札リクエストでモバイル広告 ID を 説明します。モバイル広告 ID には iOS IDFA または <ph type="x-smartling-placeholder"></ph> Android の広告 ID: <ph type="x-smartling-placeholder"></ph> によって管理される JavaScript タグの %%EXTRA_TAG_DATA%% マクロ 認定バイヤー。

%%ADVERTISING_IDENTIFIER%% マクロを使用すると、 インプレッション レンダリング時の iOS IDFA または Android 広告 ID。このメソッドは、 暗号化された proto バッファ MobileAdvertisingId など <ph type="x-smartling-placeholder"></ph> %%EXTRA_TAG_DATA%%:

message MobileAdvertisingId {
  optional bytes advertising_id = 1;
  optional int32 user_id_type = 2;
}

user_id_type は、定義されている値のいずれかです。 enum AdxMobileIdType:

enum AdxMobileIdType {
  MOBILE_ID_UNKNOWN = 0,
  IDFA = 1,
  ANDROID_ID = 2,
};

広告 ID を使用してモバイル広告 ID からユーザーリストを作成できます 合計バイト数を表しますこれらのユーザーリストは ご自身のサーバーや当社のサーバーに 置かずに済みますGoogle のサーバーでユーザーリストを作成するには、次を使用します。 一括アップロード機能を使用できます。

モバイル広告 ID がユーザーリストと一致した場合は、その ID を使用して できます。

リアルタイムのフィードバック

認定バイヤーはリアルタイムのフィードバックを利用できます。 Open Bidding を使用するエクスチェンジとネットワークをターゲティングできます。

入札レスポンスのフィードバックは、後続の入札リクエストでサポートされます。 AdX プロトコルと OpenRTBOpenRTB の場合は、 BidRequestExt。

入札レスポンスのフィードバックで送信されるデフォルトのフィールドに加えて、次の操作が可能です。 入札レスポンスでカスタムデータも送信（AdX Proto または OpenRTB） 返される event_notification_token を使用して BidResponse。event_notification_tokenは 入札者だけが知っている任意のデータで、デバッグに役立ち、 例: 新しい戦術を表す新しいターゲティング ID や入札 ID そのクリエイティブに関連付けられたメタデータを、ビッダーだけに知られるようになります。詳しくは OpenRTB を参照 拡張機能プロトコル バッファ: RTB と AdX プロトコル ご覧ください

認定バイヤーからビッダーに入札リクエストが送信されると、ビッダーは BidResponse に置き換えます。ビッダーでリアルタイム フィードバックが有効になっている場合は、 後続の入札リクエストで認定バイヤーから BidResponseFeedback メッセージでレスポンスを返します。次に例を示します。

message BidResponseFeedback {
  // The unique id from BidRequest.id
  optional bytes request_id = 1;

  // The index of the BidResponse_Ad if there was more than one. The index
  // starts at zero for the first creative.
  optional int32 creative_index = 2;

  // The status code for the ad. See creative-status-codes.txt in the
  // technical documentation for a list of ids.
  optional int32 creative_status_code = 3;

  // If the bid won the auction, this is the price paid in your account
  // currency. If the bid participated in the auction but was out-bid, this
  // is the CPM that should have been exceeded in order to win. This is not
  // set if the bid was filtered prior to the auction, if the publisher or
  // winning bidder has opted out of price feedback or if your account has
  // opted out of sharing winning prices with other bidders. For first-price
  // auctions, minimum_bid_to_win is populated instead of this field.
  optional int64 cpm_micros = 4;

  // The minimum bid value necessary to have won the auction, in micros of
  // your account currency. If your bid won the auction, this is the second
  // highest bid that was not filtered (including the floor price). If your
  // bid did not win the auction, this is the winning candidate's bid. This
  // field will only be populated if your bid participated in a first-price
  // auction, and will not be populated if your bid was filtered prior to the
  // auction.
  optional int64 minimum_bid_to_win = 7;

  // The minimum bid value necessary to have won the server-side component of
  // the overall auction given that there was also an interest group bidding
  // component to the overall auction which ran using the Protected Audience
  // API. The value is expressed in CPM micros of the buyer account currency.
  // The minimum bid to win for the overall auction, including bids from the
  // server-side and the on-device interest group components, is populated in
  // the minimum_bid_to_win field of the same BidResponseFeedback object.
  optional int64 server_side_component_minimum_bid_to_win = 16;

  // Billable event rate multiplier that was applied to this bid during
  // ranking. The adjustment reflects the likelihood that your bid would
  // generate a billable event (namely, the ad renders successfully) if it won
  // the auction, relative to the probability that other bids generate a
  // billable event if they won the auction. This adjustment can be larger or
  // smaller than 1. This affects the final ranking in the auction only; in
  // particular, this multiplier does not affect the payment or whether the
  // bid clears any floor price.
  optional float billable_event_rate_bid_adjustment = 15 [default = 1];

  // When a publisher uses an RTB auction and waterfall-based SDK mediation on
  // the same query, the winner of the real-time auction must also compete in
  // a mediation waterfall (which is ordered by price) to win the impression.
  // If the bid participated in the auction and there was no waterfall, the
  // value of this field is 0. If the bid participated in the auction and
  // there was a waterfall, the value of this field is a price representing a
  // sample bid from the eligible mediation networks that were higher than the
  // auction winner, weighted by expected fill rate. This field can be used
  // in conjunction with minimum_bid_to_win to train bidding models. The CPM
  // is in micros of your account currency.
  optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;

  // Event notification token that was included in the bid response.
  optional bytes event_notification_token = 5;

  // Buyer creative ID that was included in the bid response.
  optional string buyer_creative_id = 6;

  // Possible types of bid response feedback objects.
  enum FeedbackType {
    FEEDBACK_TYPE_UNSPECIFIED = 0;

    // Feedback for a bid that was submitted on a bid response.
    BID_FEEDBACK = 1;

    // Feedback for an interest group buyer submitted on a bid response to
    // particpate in an interest group bidding component of the auction run
    // using the Protected Audience API.
    INTEREST_GROUP_BUYER_FEEDBACK = 2;
  }

  // The type of the BidResponseFeedback message. Google will send separate
  // BidResponseFeedback objects for:
  // a) Each bid submitted on a bid response
  // b) Each buyer submitted on a bid response to particpate in an interest
  // group bidding component of the auction run using the Protected Audience
  // API.
  optional FeedbackType feedback_type = 17;

  // Origin of an interest group buyer that was included in the bid response.
  // This field is populated only for feedback where a bidder opted in an
  // interest group buyer to participate in the interest group bidding
  // component of the overall auction run using the Protected Audience API.
  // To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
  // To learn more about interest group bidding and the Protected Audience
  // API, see
  // https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
  optional string buyer_origin = 18;

  // The status code for the submitted interest group buyer. This field is
  // only populated in the feedback for an interest group buyer that a bidder
  // requested to enter into the interest group auction through the bid
  // response. Individual creative status codes of bids submitted by the buyer
  // in the on-device interest group auction are not available. See
  // https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
  // for a list of interest group buyer status codes.
  optional int32 interest_group_buyer_status_code = 19;
}

このメッセージから、最初に確認する必要があるフィールドは bid_response_feedback.creative_status_code、コードの での意味 Creative-status-codes.txt。落札した場合は、無効にすることもできます。 料金のフィードバックから導き出されます。詳細については、 オプトアウトします。

リアルタイムのフィードバックには、入札リクエスト ID といずれかの 次のとおりです。

オークション結果 リアルタイムのフィードバック
購入者が入札しませんでした。 特になし。
購入者が送信した入札は除外され、到達前に除外されました 決定します クリエイティブのステータス コード（creative-status-codes.txt）。
購入者が入札したものの、オークションで負けました。 クリエイティブのステータス コード 79（入札単価が低い） 。
購入者がオークションで落札した入札を送信しました。 清算価格とクリエイティブのステータス コード 1。

アプリ インプレッションでクリエイティブのステータス コードが 83 の場合、 アプリ パブリッシャーがメディエーション ウォーターフォールを使用していた可能性があるため、 落札した入札がパブリッシャーの パスバック ウォーターフォール チェーンです。使用方法を見る 次の場合: sampled_mediation_cpm_ahead_of_auction_winner 入札。

サンプル

以下は、サポートされているリアルタイム フィードバックの例です。 機能:

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

ファーストプライス オークションの入札モデルを構築する

ファーストプライス オークションに入札すると、 minimum_bid_to_win や sampled_mediation_cpm_ahead_of_auction_winner フィールドは、入札時に オークションから除外されませんでした。これらのシグナルを使用して コンバージョンを達成するために獲得できたはずの入札単価を インプレッションを落札します

  • minimum_bid_to_win: 獲得できたはずの最小入札単価 オークションで落札されたオークションのオークションで落札した場合は 最小入札価格になります。紛失した これが落札単価となります
  • sampled_mediation_cpm_ahead_of_auction_winner: メディエーション チェーンの他のネットワーク、 このフィールドの値は、 オークションの落札者よりも高かった、条件を満たすメディエーション ネットワーク（重み付けあり） 推定広告掲載率で入札しますネットワーク内のどのネットワークも メディエーション チェーンが埋めることが期待される場合、またはパブリッシャーが SDK を使用していない場合 調整します。

仕組み

取り得る値を求めるために使用する計算について説明するには、 minimum_bid_to_win と sampled_mediation_cpm_ahead_of_auction_winner には、まず 次のように定義します。

  • 以下は、メディエーション チェーンの CPM を降順で表したものです。
    \[C_1, C_2, …, C_n\]
  • 各キャンペーンの CPM に対応する広告掲載率は、以下のようになります。 メディエーション チェーン:
    \[f_1, f_2, …, f_n\]
  • 以下の関数は、予想 CPM とその値を求めるときに使用します。 指定された広告掲載に基づくメディエーション チェーン要素からの確率 \(i\) レート:
    \(X_i = \{C_i\) 確率あり \(f_i\); \(0\) 確率あり \(1 - f_i\}\)
  • 最終的に落札されたメディエーション チェーンは次のようになります。
    \[\{C_1, C_2, …, C_K, W\}\]
    \(W\) は落札単価、 \(C_K > W >= C_{K+1}\)
  • 予約料金（最小価格）は \(F\)と表されます。
  • 第 2 位の入札単価は \(R\)と表されます。
オークション落札者の計算
フィールド 計算
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(\{C_i\) 確率あり \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
\(1 <= i <= K\)向け。
落札できなかったオークションの計算方法
フィールド 計算
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_
of_auction_winner
\(max\{X_1, …, X_K\}\)

単純なメディエーション チェーンの例

パブリッシャー様が、リアルタイム ビッダーと SDK メディエーション チェーンの両方を 次のようになります。

SDK メディエーション チェーン 推定 CPM 広告掲載率
ネットワーク 1 \(C_1 = $3.00\) \(f_1 = 5\%\)
ネットワーク 2 \(C_2 = $2.00\) \(f_2 = 45\%\)
ネットワーク 3 \(C_3 = $0.50\) \(f_3 = 80\%\)
ネットワーク 4 \(C_4 = $0.10\) \(f_4 = 85\%\)

RTB オークションの結果、次のことを前提とします。

RTB オークション CPM
オークションの落札者（W） $1.00
オークション第 2 位（R） $0.05
予約料金 / 最小価格（F） $0
オークションで落札した入札単価

次のサンプルは、特定のフィールドに対する値と確率が minimum_bid_to_win、 sampled_mediation_cpm_ahead_of_auction_winner は、 落札します

minimum_bid_to_win 確率
\(max(F, R, C_3) = $0.50\) \(f_3 = 80\%\)
\(max(F, R, C_4) = $0.10\) \((1-f_3) \cdot f_4 = 17\%\)
\(max(F, R, 0) = $0.05\) \((1-f_3) \cdot (1-f_4) = 3\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 確率
\(C_1 = $3.00\) \(f_1 \div (1-(1-f_1) \cdot (1-f_2)) =~ 10.5\%\)
\(C_2 = $2.00\) \(((1-f_1) \cdot f_2) \div (1-(1-f_1) \cdot (1-f_2)) =~ 89.5\%\)
オークションで落札できなかった入札数

次のサンプルは、特定のフィールドに対する値と確率が minimum_bid_to_win、 sampled_mediation_cpm_ahead_of_auction_winner は、 落札できませんでした

minimum_bid_to_win 確率
\(max(F, W) = $1.00\) \(100\%\)
sampled_mediation_cpm_
ahead_of_auction_winner		 確率
\(C_1 = $3.00\) \(f_1 = 5\%\)
\(C_2 = $2.00\) \((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\) \((1-f_1) \cdot (1-f_2) =~ 52.2\%\)

入札単価のフラット化

入札単価のフラット化は、1 つの 複数の入札リクエストに対してBidRequestを 説明します。同じ ID が保持されるため （認定バイヤー RTB プロトコルの BidRequest.google_query_id OpenRTB プロトコルの BidRequestExt.google_query_id）では、 フラット化後に相互に関連付ける入札リクエストを特定する。

広告フォーマット

一部の広告配信機会では、複数のフォーマットを使用できます。入札単価のフラット化では という形式が個別の入札リクエストで送信されます。その場合は、 請求 ID は、リクエストで指定された形式に関連しています。

次のフォーマットを含む入札リクエストは、 利用できるので、

  • バナー
  • 動画
  • 音声
  • ネイティブ

広告フォーマットのフラット化の例

以下は、広告なしの簡略化した OpenRTB JSON 入札リクエストの例です。 フラット化されたリクエストの同等のセットと比較した場合のフォーマットのフラット化:

事前にフラット化

ポストフラット化

特価

特定のビッダーの広告配信機会はさまざまな取引に適用できる 公開オークションに加え取引のフラット化では 固定価格のタイプごとに 1 つずつ、 あります実際のところ、広告の制約はオークションと固定価格とで異なる場合があります。 取引タイプ（たとえば特定の動画広告オポチュニティの 公開オークションと固定料金取引の両方の 入札が同じ場合 広告の最大再生時間や広告の最大再生時間などの 異なる場合がありますその結果、広告にはフラット化が適用され オポチュニティでは、公開オークションの広告制約が 固定料金取引が使用されます

スキップ可能な動画の最大再生時間

Google のプロトコルと OpenRTB の実装でサポートされるフィールドは次のとおりです。 （動画の再生時間とスキップの可否）:

所要時間 スキップ可能な再生時間 スキップ可能かどうか
Google プロトコル max_ad_duration skippable_max_ad_duration video_ad_skippable
OpenRTB maxduration なし skip

つまり、Google のプロトコルではスキップ可能かどうかを細かく スキップ不可の広告の再生時間を指定する場合、OpenRTB の実装では 最大再生時間の値を指定します。

入札単価のフラット化が行われる前は、OpenRTB の maxduration は次のように設定されています。 Google プロトコルの max_ad_duration と skippable_max_ad_duration フィールド。この動作は、次のように変更されました。 これらの値が異なる場合は、それぞれ別の入札リクエストを maxduration（スキップ可能）とスキップ不可（スキップ不可） 学びます。

次の例は、Google プロトコル リクエストが OpenRTB への入札のフラット化の前後に行われます。同等の Google プロトコル リクエストの max_ad_duration は 15、 60 件中 skippable_max_ad_duration 件目です。

例 max_ad_duration skip（true または false）
フラット化なしの元のリクエスト 15 true
フラット化されたリクエスト #1: スキップ不可 15 false
フラット化されたリクエスト #2: スキップ可能 60 true

スキップ可能な動画の再生時間の入札リクエストの分割は、次の場合にのみ行われます。 次の条件が満たされます

  • リクエストで動画が許可されます。
  • スキップ可能とスキップ不可の動画の両方が許可され、それぞれ 2 つまで 値が異なります。
  • このリクエストは、プライベート オークションまたは公開オークションの対象です。
  • ビッダー アカウントにアクティブな OpenRTB エンドポイントがあります。

このタイプのフラット化からオプトアウトするには、テクニカル 担当します。

動画連続配信広告

複数の広告配信機会がある動画連続配信広告の入札リクエストは、平坦化されます。 入札リクエストを、その連続配信広告の個別の広告配信機会に対するものとして処理できます。 これにより、特定の連続配信広告に対して複数の広告配信の機会に入札できます。

Open Measurement

Open Measurement では、 モバイルアプリに配信される広告を対象とした、独立した測定および検証サービス 必要があります。

パブリッシャーが入札で Open Measurement に対応しているかどうかを判別できる 広告リクエストに、「Publisher-excludable」属性のOmsdkType: OMSDK 1.0属性が クリエイティブの属性をご覧ください。認定バイヤーのプロトコルの場合、次のようになります。 BidRequest.adslot[].excluded_attribute で見つかりました。対象: OpenRTB プロトコル（battr 属性の下にあります） （Banner または 動画（ できます。

「Open」を含む入札リクエストの解釈方法について詳しくは、 測定シグナルについては、Open Measurement を参照 SDK のヘルプセンター記事をご覧ください。

入札リクエストの例

以下のセクションでは、広告タイプ別の入札リクエストの例を示します。

アプリバナー

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

アプリ インタースティシャル

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

アプリ インタースティシャル動画

Google

OpenRTB プロトコル バッファ

アプリ ネイティブ

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

ウェブ動画

Google

エクスチェンジ入札者のモバイルウェブ バナー

OpenRTB プロトコル バッファ