リクエストを処理する

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

リクエストの解析

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

このリクエストを解析して、BidRequest メッセージのインスタンスに変換する必要があります。BidRequest は、参照データページから入手できる realtime-bidding.proto で定義されます。BidRequest 用に生成されたクラスで ParseFromString() メソッドを使用して、メッセージを解析できます。たとえば、次の 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、言語、地理的位置など）は、常に利用できるとは限りません。 プレターゲティング広告グループの中にあるインプレッションについて不明な情報を使用している場合、それらの広告グループは一致しません。欠落している情報がプレターゲティング条件に該当しない場合、入札リクエストは除外された情報とともに送信されます。

プレターゲティング広告グループに関する情報は、各 AdSlot の MatchingAdData グループで確認できます。これには、入札リクエストの送信元となったプレターゲティング広告グループ（レスポンスがインプレッションのオークションで落札された場合に課金される広告グループとキャンペーン）の最初に一致した広告グループ ID が含まれます。BidRequest.AdSlot に複数の matching_ad_data がある場合など、特定の状況では、BidResponse.AdSlot のアトリビューションに billing_id を明示的に指定する必要があります。入札の内容に関する制約について詳しくは、realtime-bidding.proto をご覧ください。

辞書ファイル

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

入札 URL のマクロ

必要に応じて、BidRequest の一部のフィールドを HTTP POST リクエストで使用される URL に挿入できます。これは、リクエストの値を使用して複数のバックエンドにわたってロード バランシングを行う軽量のフロントエンドを使用する場合などに役立ちます。新しいマクロのサポートをリクエストするには、テクニカル アカウント マネージャーにお問い合わせください。

マクロ説明
%%GOOGLE_USER_ID%%

BidRequest の google_user_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%%

BidRequest の has_mobile() を呼び出すときに 1 または 0 に置き換えられます。
%%HAS_VIDEO%%

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

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

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

取引 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 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” に設定されている場合に、パブリッシャーから送信される Key-Value ペアであることを判別できます。

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

調査、リマーケティング、広告配信などのサービスを提供する技術ベンダーは、購入者と販売者の間のやり取りに関与することがあります。ただし、許可されるのは、認定バイヤーとのやり取りへの参加について Google が審査したベンダーのみです。

BidRequest を理解し、BidResponse を作成するには、テクノロジー ベンダーを宣言する 2 種類の可能性に注意する必要があります。

  1. 一部の事業者は宣言の必要なく、認定バイヤー ヘルプでご確認いただけます。
  2. 他のベンダーは、BidRequest と BidResponse の両方で宣言されている場合にのみ参加できます。
    • 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 または Android の広告 ID を使用できます。これらは、認定バイヤーが管理する JavaScript タグ内の %%EXTRA_TAG_DATA%% マクロを介して送信されます。

%%ADVERTISING_IDENTIFIER%% マクロを使用すると、購入者はインプレッションのレンダリング時に iOS IDFA または Android の広告 ID を受け取ることができます。 %%EXTRA_TAG_DATA%% のような暗号化されたプロトコル バッファ MobileAdvertisingId を返します。

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 の サーバーで管理できますGoogle のサーバー上にユーザーリストを作成するには、Google の一括アップロード機能を使用します。

モバイル広告 ID がユーザーリストと一致すると、その ID を使用してリマーケティングを実施できます。

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

リアルタイムのフィードバックは、認定バイヤー、Open Bidding を使用しているエクスチェンジ、ネットワークにご利用いただけます。

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

入札レスポンスのフィードバックで送信されるデフォルトのフィールドに加えて、BidResponse で返される event_notification_token を使用して、入札レスポンス（AdX プロトコルまたは OpenRTB）でカスタムデータを送信することもできます。event_notification_token は、デバッグに役立つ可能性がある入札者にのみ知られている任意のデータです。たとえば、新しいターゲティング ID や新しい戦術を表す入札 ID、入札者のみが認識しているクリエイティブに関連付けられたメタデータなどが該当します。詳しくは、RTB の場合は OpenRTB 拡張機能プロトコル バッファ、AdX の場合は 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 メディエーションを使用していない場合は、この値は 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\)と示されます。
  • 第 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 件、固定価格取引ごとに 1 件ずつ、入札リクエストが送信されます。実際には、広告の制約はオークションと固定価格取引のタイプによって異なる場合があります。たとえば、公開オークションと固定価格取引の両方で利用可能な特定の動画広告機会について、ビッダーは広告の最大再生時間やスキップ可能な広告を許可するかどうかなどの制約が異なる入札リクエストを個別に受け取ります。その結果、広告機会にフラット化を適用することで、公開オークションと固定価格取引の広告の制約を簡単に識別できるようになります。

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

Google のプロトコルと OpenRTB 実装では、動画の再生時間とスキップ可能性に関する次のフィールドがサポートされています。

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

つまり、Google プロトコルではスキップ可能とスキップ不可の時間を細かく設定できますが、OpenRTB の実装では最大再生時間の値は 1 つのみとなります。

入札リクエストの分割の前に、OpenRTB の maxduration は、Google プロトコルの max_ad_duration フィールドと skippable_max_ad_duration フィールドの小さい方に設定されます。この動作が変更され、これらの値が異なる場合に 2 つの別々の入札リクエストが送信されるようになりました。1 つはスキップ可能広告の maxduration を表し、もう 1 つはスキップ不可の広告の入札リクエストが送信されます。

次の例は、入札リクエストの分割の前と後の Google プロトコル リクエストが OpenRTB にどのように変換されるかを示しています。同等の Google プロトコル リクエストでは、max_ad_duration は 15 で、skippable_max_ad_duration は 60 です。

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

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

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

このタイプのフラット化を無効にするには、テクニカル アカウント マネージャーにお問い合わせください。

動画連続配信広告

複数の広告配信の機会がある動画連続配信広告の入札リクエストは分割されるため、入札リクエストはそれぞれ、その連続配信広告の個々の広告配信の機会に対するリクエストになります。これにより、特定の連続配信広告の複数の広告配信の機会に入札できます。

Open Measurement

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

パブリッシャーが入札リクエストで Open Measurement に対応しているかどうかは、パブリッシャーが除外できるクリエイティブの属性に記載されている OmsdkType: OMSDK 1.0 属性が広告配信の機会で除外されているかどうかをチェックすることで確認できます。認定バイヤー プロトコルの場合は、BidRequest.adslot[].excluded_attribute にあります。OpenRTB プロトコルの場合、これはフォーマットに応じてバナーまたは動画の battr 属性にあります。

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

入札リクエストの例

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

アプリバナー

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

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

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

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

Google

OpenRTB プロトコル バッファ

アプリ ネイティブ

Google

OpenRTB JSON

OpenRTB プロトコル バッファ

ウェブ動画

Google

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

OpenRTB プロトコル バッファ