요청 처리

실시간 입찰 상호작용은 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

게시자의 광고 인벤토리가 하나 이상의 사전 타겟팅 구성으로 타겟팅되면 입찰 요청이 수신됩니다. 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에 삽입할 수 있습니다. 하나 이상의 매크로로 엔드포인트 URL을 구성하면 입찰 요청에 해당 정보가 있는 경우 매크로가 확장됩니다. 예를 들어 BidRequest의 정보를 기반으로 부하 분산을 수행하려는 경우에 유용할 수 있습니다. 계정 관리자에게 문의하여 새 매크로 지원을 요청하세요.

Macro설명
%%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가 채워져 있는지에 따라 달라집니다.
%%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입니다.

예를 들면 다음과 같습니다. 신고된 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 세부정보
BidRequest.imp.ext.dfp_ad_unit_code

게시자의 Ad Manager 네트워크 코드와 광고 단위 계층 구조가 포함되어 있으며, 포워드 슬래시로 구분됩니다.

예를 들어 다음과 같은 형식으로 표시됩니다. /1234/cruises/mars
BidRequest.user.data.segment

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

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

실제 요청의 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와 공개 입찰을 사용하는 거래소 및 네트워크에서 사용할 수 있습니다.

실시간 피드백은 이전에 제출한 하나 이상의 입찰 결과를 기반으로 BidRequest.ext.bid_feedback를 채우며, 입찰이 낙찰되었는지 또는 입찰에서 낙찰되기 위해 필요한 최소 입찰가와 같은 세부정보를 찾는 데 사용할 수 있습니다. 실시간 의견을 사용 설정하려면 계정 관리자에게 문의하세요.

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

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;

  // 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: 미디에이션 체인에 다른 네트워크가 있는 경우 이 필드의 값은 입찰 낙찰자보다 높고 예상 게재율에 따라 가중치가 적용된 자격 요건을 충족하는 미디에이션 네트워크 중 하나의 샘플 입찰가를 나타내는 가격입니다. 미디에이션 체인의 네트워크가 채울 것으로 예상되지 않거나 게시자가 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\%\)

입찰 평탄화

입찰 평탄화는 단일 복잡한 BidRequest를 애플리케이션으로 전송되는 여러 입찰 요청으로 처리하는 것을 설명합니다. 입찰 요청이 평면화되면 BidRequest.ext.google_query_id 필드의 값이 동일하므로 원래 입찰 요청이 어떤 것인지 알 수 있습니다.

입찰 평탄화는 기본적으로 사용 설정되어 있지만 사용 중지하려면 계정 관리자에게 문의하세요.

광고 형식

일부 광고 기회는 여러 형식을 허용할 수 있습니다. 입찰 평탄화를 사용하면 각 형식이 별도의 입찰 요청으로 전송되며, 여기서 적격 청구 ID와 같은 속성은 요청에 지정된 형식과 관련이 있습니다.

다음 형식이 포함된 입찰 요청은 별도의 입찰 요청으로 평탄화됩니다.

  • 배너
  • 동영상
  • 오디오
  • 네이티브

광고 형식 평면화 예

다음은 광고 형식 평탄화가 없는 단순화된 OpenRTB JSON 입찰 요청을 평탄화된 요청의 동일한 집합과 비교한 예입니다.

사전 평면화

Post-flatten

특가

특정 입찰자의 광고 기회는 공개 입찰 외에도 다양한 거래 유형에 적용될 수 있습니다. 거래에 대한 입찰 평탄화를 사용하면 공개 입찰에 대해 하나의 입찰 요청이 전송되고 고정 가격 거래 유형별로 하나의 입찰 요청이 전송됩니다. 실제로 광고 제약 조건은 입찰과 고정 가격 거래 유형 간에 다를 수 있습니다. 예를 들어 공개 입찰과 고정 가격 거래 모두에 사용할 수 있는 특정 동영상 광고 기회의 경우 입찰자는 각각에 대해 별도의 입찰 요청을 받게 되며, 최대 광고 재생 시간 및 건너뛸 수 있는 광고 허용 여부와 같은 제약 조건이 다를 수 있습니다. 따라서 광고 기회에 적용된 평면화를 통해 공개 입찰 및 고정 가격 거래의 광고 제약 조건을 더 쉽게 파악할 수 있습니다.

건너뛰기 가능 여부 및 동영상 길이

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를 사용하면 모바일 앱 환경에 게재되는 광고에 독립적인 측정 및 확인 서비스를 제공하는 서드 파티 공급업체를 지정할 수 있습니다.

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

공개 측정 신호가 포함된 입찰 요청을 해석하는 방법에 관한 자세한 내용은 공개 측정 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