リクエストを処理する

リアルタイム入札のやり取りは、Google がアプリに入札リクエストを送信したときに開始されます。このガイドでは、入札リクエストを処理するようにアプリケーションをコーディングする方法について説明します。

解析リクエスト

Google は、OpenRTB JSON または Protobuf 形式でシリアル化された入札リクエストを、HTTP POST リクエストのペイロードとして添付して送信します。受信する形式は、エンドポイントの構成によって異なります。例については、入札リクエストの例をご覧ください。

このリクエストを解析して、シリアル化された BidRequest を受け取る必要があります。Protobuf 形式を使用している場合は、リファレンス データページから openrtb.proto と openrtb-adx.proto をダウンロードし、それらを使用して 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++ で OpenRTB の `BidRequest` の取引を反復処理する場合、次のようになります。

for (const BidRequest::Imp::Pmp::Deal& deal : pmp.deals()) {
  DoSomething(deal.id(), deal.wseat());
}

請求 ID

パブリッシャーの広告枠が 1 つ以上の 事前ターゲティング構成の対象となっている場合、入札リクエストが届きます。BidRequest.imp.ext.billing_id には、対象となる購入者の請求 ID と、関連する事前ターゲティング構成が入力されます。また、取引インベントリの場合は、BidRequest.imp.pmp.deal.ext.billing_id を使用して、関連する購入者に関連付けられた請求先 ID を確認できます。入札を行う際に指定できるのは、入札リクエストに含まれる購入者の請求 ID のみです。

入札リクエストに複数の請求 ID が含まれている場合は、BidResponse.seatbid.bid.ext.billing_id フィールドで、入札を帰属させる購入者の請求 ID を指定する必要があります。

imp {
  ext {
    // The billing IDs of all of your matching pretargeting configs and eligible child seats are
    // stored in a flat list here.
    billing_id: 123
    billing_id: 456
    billing_id: 789
  }
  pmp {
    // All eligible deals are stored in a single flat list.
    deal {
      id: 1000
      ext {
        // The specific billing IDs eligible to bid on this deal are indicated here.
        billing_id: 789
      }
      ...
    }
    deal {
      id: 2000
      ext {
        billing_id: 123
        billing_id: 456
      }
      ...
    }
  }
  ...
}
...

ブロックされたカテゴリを特定する

入札を行う場合、含まれるクリエイティブにパブリッシャーがブロックしたカテゴリが検出されていてはなりません。それ以外の場合、入札はオークションから除外されます。

インプレッションでブロックされたカテゴリを確認するには、BidRequest.bcat フィールドを確認します。このフィールドには、アカウントに設定された分類のカテゴリが入力されます。

次の例は、構成された広告カテゴリの分類に基づくブロックされたカテゴリを示しています。

IAB コンテンツの分類 1.0

// Bid request
{
  // Indicates the blocked categories using IAB Content 1.0 Taxonomy.
  "bcat": [
    "IAB9-9",  // Cigars
    "IAB8-18"  // Wine
  ]
  "imp": {
    ...
  }
}
      
// Bid request
{
  // Indicates the blocked categories using Google Ad Category Taxonomy.
  "bcat": [
    "10138",  // Cigar and tobacco collecting
    "10080",  // Tobacco
    "11649",  // Wine
    "10674",  // Wine collecting
    "13008"   // Wine clubs
  ]
  "imp": {
    ...
  }
}

辞書ファイル

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

入札者の URL マクロ

必要に応じて、BidRequest の一部の情報をマクロを使用して入札エンドポイント URL に挿入できます。1 つ以上のマクロを含むエンドポイント URL を構成すると、入札リクエストにその情報が含まれている場合にマクロが展開されます。これは、たとえば、BidRequest の情報に基づいてロード バランシングを行う場合に便利です。新しいマクロのサポートをリクエストするには、アカウント マネージャーにお問い合わせください。

マクロ説明
%%GOOGLE_USER_ID%%

BidRequest.user.id にある Google ユーザー ID に置き換えられます。たとえば、入札者の 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.device.devicetype の値に基づいています。モバイル デバイスは HIGHEND_PHONE（4）または Tablet（5）で示されます。
%%HAS_VIDEO%%

入札リクエストに動画広告枠が含まれている場合は 1 に置き換えられ、それ以外の場合は 0 に置き換えられます。これは、入札リクエストで BidRequest.imp.video が入力されているかどうかに基づきます。
%%HOSTED_MATCH_DATA%%

BidRequest.user.buyeruid に基づく値に置き換えられました。
%%MOBILE_IS_APP%%

入札リクエストがモバイルアプリの広告枠を対象としている場合は 1、それ以外の場合は 0 に置き換えられました。これは、BidRequest.app に値が入力されているかどうかに基づいています。

トランザクション URL からモバイルアプリ ID を確認する

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

mbappgewtimrzgyytanjyg4888888.com

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

オンライン デコーダを使用できますが、文字を大文字にし、末尾の 8 を = 値に置き換える必要があります。

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

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

もう 1 つ例を示します。報告された URL は次のとおりです。 

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

トランザクション URL からモバイルアプリの名前を確認する

アプリ名を取得する例を次に示します。報告された URL は次のとおりです。 

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

Open Bidding のフィールド

Open Bidding に参加しているエクスチェンジとネットワークのビッダーに送信される入札リクエストは、標準のリアルタイム ビッダーに参加している認定バイヤーの入札リクエストと似ています。Open Bidding のお客様には、少数の追加フィールドが提供され、既存のフィールドの一部は別の用途で使用される可能性があります。次に例を示します。

OpenRTB 詳細
BidRequest.imp.ext.dfp_ad_unit_code

パブリッシャーのアド マネージャー ネットワーク コードと広告ユニットの階層がスラッシュで区切られて含まれます。

たとえば、次のような書式設定で表示されます。 /1234/cruises/mars。
BidRequest.user.data.segment

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

BidRequest.user.data.name が “Publisher Passed” に設定されている場合、値はパブリッシャーから送信された Key-Value ペアであると判断できます。

許可するベンダーを宣言する

リサーチ、リマーケティング、広告配信などのサービスを提供するテクノロジー ベンダーは、購入者と販売者の間のやり取りで役割を果たすことがあります。認定バイヤーのインタラクションへの参加について Google の審査を受けたベンダーのみが許可されます。

BidRequest を理解して BidResponse を作成するには、テクノロジー ベンダーを宣言する 2 つの方法を把握しておく必要があります。

  1. 一部のベンダーは宣言する必要がありません。これらのベンダーは、アド マネージャーの認定外部ベンダーに記載されています。
  2. 他のベンダーは、BidRequest で宣言されている場合にのみ参加できます。
    • BidRequest の BidRequest.imp.ext.allowed_vendor_type フィールドでは、販売者が許可するベンダーを指定します。allowed_vendor_type で送信されるベンダーは、vendors.txt 辞書ファイルに一覧表示されます。

入札リクエストの例

次の例は、Protobuf リクエストと JSON リクエストの人間が読めるサンプルを表しています。

OpenRTB Protobuf

OpenRTB JSON

実際のリクエストの 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
  }
}

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

リアルタイム フィードバックは、認定バイヤーだけでなく、Open Bidding を使用するエクスチェンジやネットワークでも利用できます。

リアルタイム フィードバックでは、以前に入札した 1 つ以上の入札の結果に基づいて BidRequest.ext.bid_feedback が入力されます。この情報を使用して、入札がオークションで落札されたかどうかや、オークションで落札するために必要だった最小入札単価などの詳細を確認できます。リアルタイム フィードバックを有効にするには、アカウント マネージャーにお問い合わせください。

入札レスポンス フィードバックで送信されるデフォルトのフィールドに加えて、BidResponse.seatbid.bid.ext.event_notification_token フィールドを使用して、入札レスポンスでカスタムデータを送信することもできます。event_notification_token は、デバッグに役立つ可能性のある、入札者のみが知っている任意のデータです。たとえば、新しいターゲティング ID や、新しい戦術を表す入札 ID、入札者のみが知っているクリエイティブに関連付けられたメタデータなどです。詳しくは、OpenRTB 拡張機能プロトコル バッファ ファイルをご覧ください。

認定バイヤーが入札リクエストをビッダーに送信すると、ビッダーは BidResponse で応答します。入札者がリアルタイム フィードバックを有効にしている場合、認定バイヤーは後続の入札リクエストで、BidFeedback メッセージでレスポンスに関するフィードバックを送信します。

message BidFeedback {
  // The unique id from BidRequest.id.
  optional string request_id = 1;

  // 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 = 2;

  // Deprecated. This field is not populated and will be removed after March,
  // 2025. 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 double price = 3 [deprecated = true];

  // The minimum bid value necessary to have won the auction, in 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 didn't 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 double minimum_bid_to_win = 6;

  // Deprecated. This field will be removed in February 2026.
  // 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 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 BidFeedback object.
  optional double sscminbidtowin = 14 [deprecated = true];

  // 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 = 13 [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 your account currency.
  optional double sampled_mediation_cpm_ahead_of_auction_winner = 8;

  message EventNotificationToken {
    // The contents of the token.
    optional string payload = 1;
  }

  // The token included in the corresponding bid.
  optional EventNotificationToken event_notification_token = 4;

  // The creative ID included in the corresponding bid.
  optional string buyer_creative_id = 5;

  // 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;
  }

  // Deprecated. This field will be removed in February 2026.
  // The type of the BidFeedback message. Google will send separate
  // BidFeedback 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 feedbacktype = 15 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 buyerorigin = 16 [deprecated = true];

  // Deprecated. This field will be removed in February 2026.
  // 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 igbuyerstatus = 17 [deprecated = true];
}

このメッセージで最初に確認すべきフィールドは bid_feedback.creative_status_code です。コードの意味は creative-status-codes.txt で確認できます。入札に落札した場合、価格フィードバックをオプトアウトできます。詳しくは、オプトアウトの方法をご覧ください。

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

オークションの結果 リアルタイムのフィードバック
購入者が入札を送信しなかった。 特になし。
購入者が入札を送信しましたが、オークションに到達する前にフィルタリングされました。 クリエイティブのステータス コード（creative-status-codes.txt）。
購入者が入札を行ったものの、オークションで落札できなかった。 クリエイティブのステータス コード 79（オークションで競合単価を下回った）。
購入者がオークションで落札した入札を送信しました。 クリアリング価格とクリエイティブ ステータス コード 1。

アプリのインプレッションとクリエイティブのステータス コードが 83 の場合、アプリのパブリッシャーがメディエーション ウォーターフォールを使用している可能性があり、落札単価はパブリッシャーのパスバック ウォーターフォール チェーンの他のデマンドと競合します。入札時に sampled_mediation_cpm_ahead_of_auction_winner を使用する方法をご確認ください。

サンプル

サポートされているプロトコルで表示されるリアルタイム フィードバックの例を次に示します。

OpenRTB Protobuf

OpenRTB JSON

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

ファーストプライス オークションに入札すると、入札がオークションから除外されなかった場合は、minimum_bid_to_win フィールドと sampled_mediation_cpm_ahead_of_auction_winner フィールドを含むリアルタイム フィードバックが届きます。これらのシグナルは、インプレッションを獲得するために入札単価をどの程度高くまたは低く設定できたかを入札ロジックに伝えるために使用できます。

  • minimum_bid_to_win: リアルタイム ビッディング オークションで落札するために提示できた最小入札単価。オークションで落札した場合、この値は落札可能な最低入札単価になります。オークションで落札できなかった場合は、落札単価になります。
  • sampled_mediation_cpm_ahead_of_auction_winner: メディエーション チェーンに他のネットワークがある場合、このフィールドの値は、オークションの落札者よりも高い、対象となるメディエーション ネットワークの 1 つからのサンプル入札額を表す価格で、予想されるフィルレートで重み付けされます。メディエーション チェーン内のどのネットワークもフィルが想定されない場合、またはパブリッシャーが SDK メディエーションを使用しない場合、この値は 0 に設定されます。

仕組み

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\]
  • 次の関数は、指定されたフィルレートに基づいて、メディエーション チェーン要素 \(i\)から予想 CPM とその確率を判断するために使用されます。
    \(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\)と表記されます。
  • 次点の入札額は \(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
オークションの次点（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 を複数の入札リクエストに処理して、アプリケーションに送信することを指します。入札リクエストがフラット化されると、BidRequest.ext.google_query_id フィールドの値が同じになるため、元の入札リクエストの一部であった入札リクエストを特定できます。

入札単価の分割はデフォルトで有効になっていますが、無効にしたい場合はアカウント マネージャーにお問い合わせください。

広告フォーマット

一部の広告枠では複数のフォーマットを使用できます。入札の平坦化では、各フォーマットは個別の入札リクエストで送信されます。この場合、対象となる請求 ID などの属性は、リクエストで指定されたフォーマットに関連します。

次のフォーマットを含む入札リクエストは、個別の入札リクエストに分割されます。

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

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

以下に、広告フォーマットのフラット化を行っていない簡略化された OpenRTB JSON 入札リクエストと、同等のフラット化されたリクエストのセットを比較した例を示します。

Pre-flatten

Post-flatten

特価

特定の入札者に対する広告機会は、公開オークションだけでなく、さまざまな取引タイプにも適用できます。取引の入札リクエストの分割では、公開オークション用に 1 つ、固定価格取引のタイプごとに 1 つの入札リクエストが送信されます。実際には、広告の制約はオークションと固定価格取引タイプで異なる場合があります。たとえば、オープン オークションと固定価格取引の両方で利用可能な特定の動画広告枠の場合、入札者はそれぞれ異なる入札リクエストを受け取ります。このとき、広告の最大再生時間やスキップ可能な広告が許可されているかどうかなどの制約が異なる場合があります。その結果、広告機会に適用されたフラット化により、オープン オークションと固定価格取引の広告制約をより簡単に識別できるようになります。

スキップ可能かどうかと動画の再生時間

OpenRTB 仕様には、スキップ可能な広告とスキップ不可の広告の最大動画再生時間を指定するための個別のフィールドはありません。Google の実装では、入札単価の平準化を使用して、既存の BidRequest.video.maxduration フィールドと BidRequest.video.skip フィールドでこれらを区別します。

スキップ不可の広告の最大再生時間が 15 で、スキップ可能な広告の最大再生時間が 60 の場合、動画広告枠は次のようにフラット化されます。

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

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

  • リクエストで動画が許可されています。
  • スキップ可能な動画とスキップ不可の動画の両方が許可されており、それぞれの最大再生時間の値が異なる。
  • このリクエストはプライベート オークションまたは公開オークションの対象です。

このタイプの分割を無効にするには、テクニカル アカウント マネージャーにお問い合わせください。無効になっていて、パブリッシャーがスキップ可能かどうかによって最大再生時間が異なるスキップ可能な動画広告とスキップ不可の動画広告の両方を許可している場合、skip は true に設定され、maxduration はスキップ可能な広告とスキップ不可の広告の制約のうち短い方の再生時間に設定されます。

動画連続配信広告

複数の広告配信の機会を含む動画連続配信広告の入札リクエストは分割され、各入札リクエストがその連続配信広告の個々の広告配信の機会に対応します。これにより、特定のポッドの複数の広告枠に入札できます。

Open Measurement

Open Measurement を使用すると、モバイルアプリ環境に配信される広告に対して独立した測定と検証のサービスを提供するサードパーティ ベンダーを指定できます。

入札リクエストでサイト運営者が Open Measurement をサポートしているかどうかを判断するには、広告枠で サイト運営者が除外可能なクリエイティブ属性にある OmsdkType: OMSDK 1.0 属性が除外されているかどうかを確認します。これは、フォーマットに応じて、バナーまたは動画の battr 属性にあります。

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

入札リクエストの例

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

アプリバナー

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

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

OpenRTB Protobuf

OpenRTB JSON

アプリ ネイティブ

OpenRTB Protobuf

OpenRTB JSON

ウェブ動画

OpenRTB Protobuf

OpenRTB JSON

エクスチェンジ ビッダー向けのモバイルウェブ バナー

OpenRTB Protobuf

OpenRTB JSON

マルチフォーマット ネイティブと動画

OpenRTB Protobuf

OpenRTB JSON