요청 처리

Google이 입찰 요청을 실행할 수 있습니다 이 가이드에서는 애플리케이션을 다음과 같이 코딩하는 방법을 설명합니다. 입찰 요청을 처리합니다.

요청 파싱

Google은 HTTP POST 요청의 바이너리 페이로드입니다. Content-Type는 다음과 같이 설정됩니다. application/octet-stream입니다. 예를 보려면 입찰 요청 예시를 참조하세요.

이 요청을 BidRequest의 인스턴스로 파싱해야 합니다. 메시지가 표시됩니다. BidRequest는 realtime-bidding.proto에 정의되어 있습니다. 이는 참조 데이터 페이지에서 얻을 수 있습니다. 메시지를 파싱할 수 있습니다. 다음을 위해 생성된 클래스에서 ParseFromString() 메서드 사용 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++:

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: 입찰 요청, 즉 비용이 청구되는 광고그룹 및 캠페인을 내 응답이 노출에 대한 입찰에서 낙찰되는 경우입니다. 확실치 않음 billing_id를 명시적으로 지정해야 합니다. BidResponse.AdSlot의 저작자 표시(예: BidRequest.AdSlot에 matching_ad_data이(가) 2개 이상 있습니다. 입찰 콘텐츠의 제약 조건에 대한 자세한 내용은 realtime-bidding.proto

사전 파일

입찰 요청은 사전 파일에 정의된 식별자를 사용하며, 참조 데이터에서 사용 가능 있습니다.

입찰 URL 매크로

원하는 경우 BidRequest의 일부 필드를 HTTP POST 요청에 사용되는 URL입니다. 이는 예를 들어 값을 사용하여 여러 백엔드에 걸쳐 부하를 분산하는 경량형 프런트엔드 삭제합니다. 다음에 대한 지원을 요청하려면 기술계정 관리자에게 문의하세요. 새로운 매크로를 사용해야 합니다.

Macro설명
%%GOOGLE_USER_ID%%

google_user_id로 대체됨 (BidRequest에서 가져옴) 예를 들어 입찰자 URL이 

http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%
 드림 다음과 같이 교체됩니다 
http://google.bidder.com/path?gid=dGhpyBhbiBleGFtGxl
 드림 API에 액세스할 수 있습니다.

Google 사용자 ID를 모르는 경우 빈 문자열이 과(와) 유사한 검색결과

http://google.bidder.com/path?gid=
%%HAS_MOBILE%%

호출 시 1 또는 0로 대체됨 BidRequest님의 has_mobile()입니다.
%%HAS_VIDEO%%

1 (true) 또는 0 (false)로 대체됨 BidRequest의 has_video()를 호출할 때
%%HOSTED_MATCH_DATA%%

hosted_match_data 필드의 값으로 대체됨 (BidRequest에서 가져옴)
%%MOBILE_IS_APP%%

1 (true) 또는 0 (false)로 대체됨 BidRequest의 mobile.is_app 필드에서 가져옴

거래 URL에서 모바일 앱 ID 찾기

모바일 애플리케이션 거래는 다음과 같은 URL로 보고됩니다.

mbappgewtimrzgyytanjyg4888888.com

base-32 디코더를 사용하여 문자열의 일부를 굵게 디코딩 (gewtimrzgyytanjyg4888888)

온라인 디코더와 유사하지만 문자를 대문자로 표기하고 뒤에 오는 문자는 값이 =인 8

따라서 이 값을 디코딩하면 다음과 같습니다. 

GEWTIMRZGYYTANJYG4======
 드림 결과: 
1-429610587
 드림 문자열 429610587는 iOS 앱의 앱 ID입니다. iFunny 형식

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

mbappgewtgmjug4ytmmrtgm888888.com
 드림 이 값 디코딩: 
GEWTGMJUG4YTMMRTGM======
 드림 결과: 
1-314716233
 드림 결과 314716233는 iOS 앱의 앱 ID입니다. TextNow에서 확인하세요.

거래 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. 일부 공급업체는 신고하지 않아도 됩니다. 이러한 공급업체는 Authorized Buyers 도움말에 나와 있습니다.
  2. 다른 공급업체는 BidRequest 및 BidResponse: <ph type="x-smartling-placeholder">
      </ph>
    • BidRequest에서 allowed_vendor_type 필드는 판매자가 허용하는 공급업체를 지정합니다. 파견할 공급업체 BidRequest의 allowed_vendor_type 필드는 Vendors.txt에 나열되어 있음 사전 파일에 있습니다.
    • BidResponse의 vendor_type 필드 허용되는 공급업체 중 구매자가 사용하려는 공급업체를 지정합니다.

입찰 요청 예시

다음 예는 사람이 읽을 수 있는 Protobuf 및 JSON 요청

Google

OpenRTB JSON

OpenRTB Protobuf

입찰 요청을 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에서는 사용할 수 있습니다. 모바일 광고 ID는 iOS IDFA 또는 <ph type="x-smartling-placeholder"></ph> Android의 광고 ID: <ph type="x-smartling-placeholder"></ph> %%EXTRA_TAG_DATA%% 매크로를 Authorized Buyers입니다.

%%ADVERTISING_IDENTIFIER%% 매크로를 사용하면 구매자가 노출 렌더링 시 iOS IDFA 또는 Android의 광고 ID 이 함수는 암호화된 proto 버퍼 MobileAdvertisingId와 같은 파일 <ph type="x-smartling-placeholder"></ph> %%EXTRA_TAG_DATA%%:

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 서버에 사용자 목록을 만들려면 다음을 사용하세요. 사용할 수 있습니다.

모바일 광고 ID가 사용자 목록과 일치하면 이를 사용하여 리마케팅에 사용할 수 있습니다.

실시간 피드백

실시간 피드백은 Authorized Buyers뿐만 아니라 광고 거래소 및 네트워크로 전환할 수 있습니다

입찰 응답 피드백은 두 가지 모두에 대한 후속 입찰 요청에서 지원됩니다. AdX 프로토콜과 OpenRTB를 사용합니다. OpenRTB의 경우 BidRequestExt

입찰 응답 의견에서 보낸 기본 입력란 외에 다음 작업도 가능합니다. 입찰 응답에서 (AdX Proto 또는 OpenRTB) 맞춤 데이터 전송 다음과 같이 반환된 event_notification_token를 사용하여 BidResponse입니다. event_notification_token는 디버깅에 도움이 될 수 있는 입찰자에게만 알려진 임의의 데이터, 예: 새 전략을 나타내는 새 타겟팅 ID 또는 입찰 ID 입찰자에게만 알려진 광고 소재와 관련된 메타데이터입니다. 자세한 내용은 자세한 내용은 OpenRTB RTB 및 AdX Proto용 확장 프로그램 프로토콜 버퍼 확인하시기 바랍니다.

Authorized Buyers에서 입찰자에게 입찰 요청을 보내면 입찰자는 BidResponse로 교체합니다. 입찰자가 실시간 피드백을 사용 설정한 경우 이후의 입찰 요청에서 Authorized Buyers는 다음과 같이 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 Protobuf

단일 가격 입찰을 위한 입찰 모델 구축하기

단일 가격 입찰에 참여한 후 실시간 minimum_bid_to_win 및 입찰가가 sampled_mediation_cpm_ahead_of_auction_winner인 경우 필드 입찰에서 필터링되지 않았습니다 이러한 신호는 입찰가를 얼마나 더 높게 또는 낮췄을지를 보여주는 입찰 로직입니다. 광고가 게재됩니다.

  • minimum_bid_to_win: 설정하려고 했을 수 있는 최소 입찰가 실시간 입찰 경매에서 낙찰됩니다. 낙찰되면 낙찰받았을 때 책정할 수 있는 최저 입찰가가 됩니다. 분실한 경우 이 입찰의 낙찰가가 됩니다.
  • sampled_mediation_cpm_ahead_of_auction_winner: 다른 네트워크가 있는 경우 이 필드의 값은 입찰 낙찰자보다 높았으며 가중치가 적용된 사용 가능한 미디에이션 네트워크 예상 유효노출률을 기준으로 산출됩니다 이 값은 채워질 것으로 예상되거나 게시자가 SDK를 사용하지 않는 경우 중재를 받을 수도 있습니다.

작동 방식

가능한 값을 결정하는 데 사용되는 계산을 설명하기 위해 minimum_bid_to_win 및 sampled_mediation_cpm_ahead_of_auction_winner님, 먼저 해야 할 일 다음을 정의합니다.

  • 다음은 미디에이션 체인의 CPM을 내림차순으로 나타냅니다.
    \[C_1, C_2, …, C_n\]
  • 다음은 미디에이션 체인:
    \[f_1, f_2, …, f_n\]
  • 다음은 예상 CPM과 지정된 채우기를 기반으로 미디에이션 체인 요소 \(i\)의 확률 평가:
    \(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 입찰의 결과는 다음과 같다고 가정해 보겠습니다.

실시간 입찰 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을(를) 입찰 요청에 포함하여 애플리케이션입니다. ID가 동일하므로 (Authorized Buyers RTB 프로토콜의 BidRequest.google_query_id 또는 BidRequestExt.google_query_id)를 사용하면 평탄화 후 상관관계가 있는 입찰 요청을 결정합니다.

광고 형식

여러 형식을 허용하는 광고 기회도 있습니다. 입찰가 평준화를 사용하면 형식이 다른 입찰 요청에서 사용 가능한 결제 ID가 요청에 지정된 형식과 관련이 있는지 확인합니다.

다음 형식을 포함하는 입찰 요청은 확인할 수 있습니다.

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

광고 형식 평탄화 예

다음은 광고가 없는 간소화된 OpenRTB JSON 입찰 요청을 보여주는 예입니다. 다음과 같이 동일한 평탄화된 요청 집합과 비교하여 평탄화 형식을 사용합니다.

사전 평면화

사후 평탄화

할인 상품

특정 입찰자의 광고 기회는 다양한 거래에 적용될 수 있습니다. 선택할 수 있습니다. 거래에 대해 입찰가를 평준화하면 공개 입찰, 그리고 각 고정 가격 유형별로 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(건너뛸 수 있는 광고) 및 나머지 하나(건너뛸 수 없는 광고) 있습니다.

다음 예는 Google 프로토콜 요청이 입찰 평준화 전후의 공개 입찰 비교 동등한 Google 프로토콜 요청의 max_ad_duration가 15이고 60개 중 skippable_max_ad_duration번째입니다.

예 max_ad_duration skip (참 또는 거짓)
평면화가 없는 원래 요청 15 true
평면화된 요청 #1: 건너뛸 수 없음 15 false
평탄화된 요청 #2: 건너뛸 수 있음 60 true

건너뛸 수 있는 동영상 길이 입찰 요청 평준화는 다음 조건이 충족됩니다.

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

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

동영상 광고 모음

광고 기회가 여러 개인 동영상 광고 모음에 대한 입찰 요청이 평탄화됩니다. 각 입찰 요청이 해당 광고 모음의 개별 광고 기회에 대한 것입니다. 이를 통해 특정 광고 모음에 대한 여러 광고 기회에 입찰할 수 있습니다.

개방형 측정

Open Measurement를 사용하면 더 높은 수준의 확장성을 제공하는 서드 파티 공급업체를 모바일 앱에 게재되는 광고에 대한 독립적인 측정 및 인증 서비스 지원합니다

게시자가 입찰에서 Open Measurement를 지원하는지를 확인할 수 있습니다. 광고 기회에서 게시자 제외 가능 항목에서 발견된 OmsdkType: OMSDK 1.0 속성을 제외하는지 확인하여 광고 소재 속성을 참조하세요. Authorized Buyers 프로토콜의 경우 BidRequest.adslot[].excluded_attribute 아래 있음 대상 OpenRTB 프로토콜의 경우 battr 속성에서 확인할 수 있습니다. (배너 또는 동영상(사용자에 따라 다름) 지정합니다.

공개 측정 신호에 관한 자세한 내용은 Open Measurement SDK 고객센터 도움말을 참고하세요.

샘플 입찰 요청

다음 섹션에는 여러 광고 유형에 대한 샘플 입찰 요청이 나와 있습니다.

앱 배너

Google

OpenRTB JSON

OpenRTB Protobuf

앱 전면 광고

Google

OpenRTB JSON

OpenRTB Protobuf

앱 전면 광고 동영상

Google

OpenRTB Protobuf

앱 네이티브

Google

OpenRTB JSON

OpenRTB Protobuf

웹 동영상

Google

거래소 입찰자용 모바일 웹 배너

OpenRTB Protobuf