リクエストを処理する

リアルタイム ビッダーのインタラクションは、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 Content Taxonomy 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": {
    ...
  }
}

コンテキスト カテゴリを特定する

入札リクエストには、インプレッションが発生するウェブサイトまたはアプリを説明するコンテキスト カテゴリ フィールドを含めることができます。これらのフィールドも広告カテゴリの分類体系を使用しますが、クリエイティブの制限ではなく、インプレッションのコンテキストを表します。これらのフィールドでは、BidRequest.bcat フィールドと同じ分類法が使用されない場合があります。これらのコンテキスト カテゴリは、Google またはパブリッシャーが提供できます。コンテキスト カテゴリを使用すると、インプレッション評価、コンテキスト ターゲティング、ブランド保護を改善できます。

Google が検出したコンテキスト カテゴリ

Google は、サイト、アプリ、ページの検出された IAB コンテンツ カテゴリを次のフィールドに入力します。

フィールド 説明
BidRequest.site.cat サイトを説明するコンテンツ カテゴリ ID の配列。
BidRequest.site.pagecat サイトの現在のページまたはビューを表すコンテンツ カテゴリ ID の配列。
BidRequest.app.cat アプリを説明するコンテンツ カテゴリ ID の配列。
BidRequest.app.pagecat アプリの現在のページまたはビューを記述するコンテンツ カテゴリ ID の配列。

特定の入札リクエストでこれらのフィールドに使用される正確な分類は、BidRequest.site.cattax フィールドまたは BidRequest.app.cattax フィールドで確認できます。パブリッシャーの設定や規制上の懸念により、コンテキスト カテゴリ フィールドが入力されない場合があります。詳細については、Google アド マネージャーの OpenRTB コンテキスト カテゴリをご覧ください。

パブリッシャー提供のシグナル

入札リクエストには、Google が検出したコンテキスト カテゴリに加えて、パブリッシャーから提供されたシグナルが含まれることもあります。このシグナルもインプレッションのコンテキストを表します。Google が検出したコンテキスト カテゴリとは異なり、これらのシグナルはパブリッシャーから提供された場合にのみ入力されます。これらのシグナルは、BidRequest.site.content オブジェクトと BidRequest.app.content オブジェクト（content.data.segment や content.genre など）で送信されます。content.data.segment エントリに使用される分類は content.data.ext.segtax で報告されます。詳しくは、リアルタイム ビッダー（RTB）のパブリッシャー提供のシグナル（PPS）をご覧ください。

辞書ファイル

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

ビッダー 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 のような URL に置き換えられます。

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 が入力されているかどうかに基づきます。
%%IS_CTV%%

1 に置き換えられ、入札リクエストがコネクテッド テレビ デバイスからのものであることを示します。それ以外の場合は 0 に置き換えられます。これは BidRequest.device.devicetype の値に基づいています。Protobuf の場合、コネクテッド テレビ デバイス（CTV デバイス）は CONNECTED_TV、CONNECTED_DEVICE、または SET_TOP_BOX で、JSON の整数値 3、6、または 7 に対応します。
%%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;

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

このメッセージで最初に確認する必要があるフィールドは 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 入札リクエストと、同等の平坦化されたリクエストのセットを比較した例です。

事前フラット化

フラット化後

取引

特定のビッダーの広告機会は、公開オークションに加えて、さまざまな取引タイプに適用できます。取引の入札リクエストの分割では、公開オークション用に 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