요청 처리

실시간 입찰 상호작용은 Google에서 애플리케이션에 입찰 요청을 전송하면 시작됩니다. 이 가이드에서는 입찰 요청을 처리하도록 애플리케이션을 코딩하는 방법을 설명합니다.

Protobuf 요청 파싱

Google은 입찰 요청을 HTTP POST 요청의 바이너리 페이로드로 첨부된 직렬화된 프로토콜 버퍼로 전송합니다. Content-Type는 application/octet-stream로 설정됩니다. 예시는 입찰 요청 예를 참고하세요.

이 요청을 BidRequest 메시지의 인스턴스로 파싱해야 합니다. 선택한 프로토콜에 따라 BidRequest는 openrtb.proto 또는 지원 중단된 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++에서 OpenRTB `BidRequest` 의 거래를 반복하는 것은 다음과 같습니다.

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

결제 ID

게시자의 광고 인벤토리가 하나 이상의 사전 타겟팅 구성에 의해 타겟팅되면 입찰 요청이 전송됩니다. BidRequest.imp.ext.billing_id에는 요건을 충족하는 구매자의 결제 ID와 관련된 사전 타겟팅 구성이 채워집니다. 또한 거래 인벤토리의 경우 BidRequest.imp.pmp.deal.ext.billing_id를 사용하여 관련 구매자와 연결된 결제 ID를 찾을 수 있습니다. 입찰할 때는 입찰 요청에 포함된 구매자의 결제 ID만 지정할 수 있습니다.

입찰 요청에 결제 ID가 여러 개 포함된 경우 BidResponse.seatbid.bid.ext.billing_id 필드로 입찰 기여도를 부여하려는 구매자의 결제 ID를 지정해야 합니다.

사전 파일

입찰 요청은 참조 데이터 페이지에서 사용할 수 있는 사전 파일에 정의된 식별자를 사용합니다.

Google RTB 프로토콜 입찰 URL 매크로

원하는 경우 BidRequest의 일부 필드를 HTTP POST 요청에 사용된 URL에 삽입할 수 있습니다. 예를 들어 요청의 값을 사용하여 여러 백엔드에 걸쳐 부하를 분산하는 경량 프런트엔드를 사용하는 경우 유용합니다. 기술계정 관리자에게 문의하여 새 매크로 지원을 요청하세요.

Macro설명
%%GOOGLE_USER_ID%%

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

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입니다.

예를 들면 다음과 같습니다. 신고된 URL은 다음과 같습니다. 

mbappgewtgmjug4ytmmrtgm888888.com
 이 값을 디코딩합니다. 
GEWTGMJUG4YTMMRTGM======
는 다음과 같은 결과를 보입니다. 
1-314716233
 결과 314716233는 iOS 앱 TextNow의 앱 ID입니다.

거래 URL에서 모바일 앱 이름 찾기

다음은 앱 이름을 가져오는 예입니다. 보고된 URL은 다음과 같습니다. 

mbappMFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q888.com
 이 값을 디코딩합니다. 
MFUXELTDN5WS42DZOBQWQLTJN4XHG3DJORUGK4Q===
는 다음과 같은 결과를 보입니다. 
air.com.hypah.io.slither
 결과는 Android 앱 slither.io와 같습니다.

공개 입찰 입력란

공개 입찰에 참여하는 거래소 및 네트워크 입찰자에게 전송되는 입찰 요청은 표준 실시간 입찰에 참여하는 Authorized Buyers의 입찰 요청과 유사합니다. 공개 입찰 고객에게는 소수의 필드가 추가로 제공되며 일부 기존 필드에는 다른 용도가 있을 수 있습니다. 여기에는 다음이 포함됩니다.

OpenRTB Authorized Buyers 세부정보
BidRequest.imp[].ext.dfp_ad_unit_code BidRequest.adslot[].dfp_ad_unit_code

게시자의 Ad Manager 네트워크 코드와 광고 단위 계층 구조를 포워드 슬래시로 구분하여 포함합니다.

예를 들어 /1234/cruises/mars과 유사한 형식으로 표시됩니다.
BidRequest.user.data[].segment[] BidRequest.adslot[].exchange_bidding.key_value[]

게시자에서 거래소 입찰자에게 전송된 반복된 키-값 쌍입니다.

BidRequest.user.data[].name가 “Publisher Passed”로 설정된 경우 값이 게시자가 전송한 키-값 쌍이라고 판단할 수 있습니다.

허용된 공급업체 선언

시장조사, 리마케팅, 광고 게재와 같은 서비스를 제공하는 기술 공급업체는 구매자와 판매자 간의 상호작용에 역할을 할 수 있습니다. Google에서 Authorized Buyers 상호작용 참여를 위해 심사한 공급업체만 허용됩니다.

BidRequest를 이해하고 BidResponse를 만들려면 기술 공급업체를 선언하는 두 가지 방법을 알아야 합니다.

  1. 선언할 필요가 없는 공급업체도 있습니다. 이러한 공급업체는 Ad Manager 인증 외부 공급업체에 나와 있습니다.
  2. 다른 공급업체는 BidRequest에 선언된 경우에만 참여할 수 있습니다.
    • BidRequest에서 BidRequest.imp.ext.allowed_vendor_type 필드는 판매자가 허용하는 공급업체를 지정합니다. allowed_vendor_type로 전송할 공급업체는 vendors.txt 사전 파일에 나열됩니다.

입찰 요청 예시

다음 예는 사람이 읽을 수 있는 Protobuf 및 JSON 요청 샘플을 나타냅니다.

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

실제 요청의 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
  }
}

실시간 피드백

Authorized Buyers는 물론 공개 입찰을 사용하는 거래소와 네트워크에서도 실시간 의견을 확인할 수 있습니다.

입찰 응답 피드백은 OpenRTB와 지원 중단된 Google RTB 프로토콜 모두의 후속 입찰 요청에서 지원됩니다. OpenRTB의 경우 BidRequest.ext.bid_feedback로 전송됩니다.

입찰 응답 의견에 전송되는 기본 필드 외에도 BidResponse.seatbid.bid.ext.event_notification_token 필드를 사용하여 입찰 응답에 맞춤 데이터를 전송할 수도 있습니다. event_notification_token는 디버깅에 도움이 될 수 있는 입찰자만 알고 있는 임의의 데이터입니다(예: 새 전략을 나타내는 새 타겟팅 ID 또는 입찰 ID, 입찰자만 알고 있는 광고 소재와 연결된 메타데이터). 자세한 내용은 OpenRTB의 OpenRTB 확장 프로그램 프로토콜 버퍼 또는 지원 중단된 Google RTB 프로토콜을 참고하세요.

Authorized Buyers에서 입찰자에게 입찰 요청을 보내면 입찰자는 BidResponse로 응답합니다. 입찰자가 실시간 피드백을 사용 설정한 경우 후속 입찰 요청에서 Authorized Buyers는 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;

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

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

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

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

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

이 메시지에서 확인해야 하는 첫 번째 필드는 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

Google (지원 중단됨)

단일 가격 입찰을 위한 입찰 모델 빌드

단일 가격 입찰에 입찰가를 설정하면 입찰에서 입찰가가 필터링되지 않은 경우 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\) with probability \(f_i\); \(0\) with probability \(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 입찰 결과로 가정합니다.

실시간 입찰 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\%\)

입찰 평탄화

입찰 평탄화는 단일 복잡한 BidRequest를 애플리케이션으로 전송되는 여러 입찰 요청으로 처리하는 것을 설명합니다. 입찰 요청이 평면화되면 BidRequest.ext.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 구현에는 단일 최대 길이 값만 있습니다.

입찰가 평탄화 전에 OpenRTB의 maxduration는 Google 프로토콜의 max_ad_duration 필드와 skippable_max_ad_duration 필드 중 더 낮은 값으로 설정됩니다. 이제 이 값이 다르면 두 개의 개별 입찰 요청을 전송하도록 변경되었습니다. 하나는 건너뛸 수 있는 광고의 maxduration를 나타내고 다른 하나는 건너뛸 수 없는 광고의 maxduration를 나타냅니다.

다음 예는 입찰 평탄화 전후에 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

건너뛸 수 있는 동영상 길이 입찰 요청 평준화는 다음 조건이 충족되는 경우에만 진행됩니다.

  • 요청에서 동영상을 허용합니다.
  • 건너뛸 수 있는 동영상과 건너뛸 수 없는 동영상이 모두 허용되며, 두 동영상의 최대 재생 시간은 값이 다릅니다.
  • 이 요청은 비공개 입찰 또는 공개 입찰에 사용할 수 있습니다.
  • 입찰자 계정에 활성 OpenRTB 엔드포인트가 있습니다.

기술계정 관리자에게 문의하여 이러한 유형의 평탄화를 선택 해제할 수 있습니다.

동영상 광고 모음

광고 기회가 여러 개인 동영상 광고 모음의 입찰 요청은 평탄화되므로 각 입찰 요청은 해당 광고 모음의 개별 광고 기회에 대한 입찰 요청입니다. 이렇게 하면 특정 광고 모음에 대한 여러 광고 기회에 입찰할 수 있습니다.

Open Measurement

Open Measurement를 사용하면 모바일 앱 환경에 게재되는 광고에 대해 독립적인 측정 및 인증 서비스를 제공하는 서드 파티 공급업체를 지정할 수 있습니다.

광고 기회에서 게시자 제외 가능 광고 소재 속성에 있는 OmsdkType: OMSDK 1.0 속성을 제외하는지 확인하여 게시자가 입찰 요청에서 Open Measurement를 지원하는지 여부를 확인할 수 있습니다. 형식에 따라 배너 또는 동영상의 battr 속성 아래에서 찾을 수 있습니다.

공개 측정 신호가 포함된 입찰 요청을 해석하는 방법에 관한 자세한 내용은 공개 측정 SDK 고객센터 도움말을 참고하세요.

샘플 입찰 요청

다음 섹션에서는 다양한 광고 유형의 샘플 입찰 요청을 보여줍니다.

앱 배너

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

앱 전면 광고

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

앱 전면 광고 동영상

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

앱 네이티브

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

웹 동영상

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)

거래소 입찰자를 위한 모바일 웹 배너

OpenRTB Protobuf

OpenRTB JSON

형식 다각화 네이티브 및 동영상

OpenRTB Protobuf

OpenRTB JSON

Google (지원 중단됨)