요청 처리

실시간 입찰은 Google에서 애플리케이션에 입찰 요청을 보내면 작동되기 시작합니다. 다음은 입찰 요청을 처리하기 위해 애플리케이션을 코딩하는 방법을 설명합니다.

  1. 요청 파싱
  2. 사전 파일
  3. 콘텐츠 라벨
  4. 입찰 URL 매크로
  5. 허가 제휴업체 명시
  6. BidRequest 필드의 지원 중단에 대한 적응
  7. 입찰 요청 예제

요청 파싱

Google은 입찰 요청을 HTTP POST 요청의 2진법 페이로드로 첨부된 직렬화된 프로토콜 버퍼로 전송합니다. Content-Typeapplication/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);
    // adslot에서 입찰할 가격을 결정
}

Google 사용자 ID, 언어, 카테고리 등급, 지리적 위치 등과 같이 BidRequest에 보내지는 일부 정보는 항상 유효한 것은 아닙니다. 해당 노출수가 알려지지 않은 정보를 사용하는 사전 타겟팅 광고그룹은 검색되지 않습니다. 사전 타겟팅 조건에 분실 정보가 문제 되지 않는 경우, 생략된 정보로 입찰 요청을 보냅니다.

AdSlot에 대한 MatchingAdData 그룹에서 사전 타겟팅 광고그룹에 대한 정보를 이용할 수 있습니다. 여기에는 입찰 요청을 전송하게 하는 사전 타겟팅 광고그룹의 첫 번째 일치 광고그룹 ID가 포함됩니다. 이 광고그룹은 응답이 노출에 대한 입찰에서 낙찰에 성공하면 비용이 부과되는 광고그룹과 캠페인입니다. 특정 조건, 즉 BirdRequest.AdSlot에 2개 이상의 matching_ad_data가 있을 경우 BidResponse.AdSlot에서 기여에 대한 adgroup_id를 명시적으로 지정해야 합니다. 입찰 콘텐츠에 대한 제한을 알고 싶으면 realtime-bidding.proto에서 내용을 확인하세요.

맨 위로

사전 파일

입찰 요청은 다운로드 페이지에서 다운로드할 수 있는 사전 파일에 정의된 식별자를 사용합니다. 사전 파일의 샘플은 아래에 설명되어 있습니다. 이 파일들은 시간이 지남에 따라 바뀌므로, 최신 버전을 다운로드 페이지에서 확인하세요.

  • ad-categories.txtBidRequestexcluded_sensitive_category 필드에서 사용됩니다. 이 필드는 게시자가 허용하지 않은 제품 카테고리를 설명합니다. 예를 들어 자동차나 정치와 관련한 광고를 호스팅하지 않도록 게시자가 선택할 수 있습니다.
  • creative-attributes.txt BidRequestexcluded_attribute 필드에서 사용됩니다. 이 필드는 게시자가 허용하지 않을 광고 소재의 유형을 설명합니다. 예를 들어 게시자가 쿠키 사용이나 리치 미디어 광고, 텍스트 광고를 제한할 수 있습니다.
  • vendors.txtBidRequestallowed_vendor_type 필드에서 사용됩니다. 이 필드는 게시자가 명시한 대로 제공되는 광고 소재에 대해 Eyeblaster, Pointroll 같은 리치 미디어 제휴업체가 허가되었음을 명시합니다.
  • publisher-verticals.txtBidRequestdetected_vertical 필드에서 사용됩니다. 이 필드는 광고가 게재될 페이지의 카테고리(키워드와 유사)를 지정합니다. Google은 페이지를 천천히 움직이게 하고, 콘텐츠를 분석하여 이 필드를 생성합니다.

맨 위로

콘텐츠 라벨

콘텐츠 라벨은 입찰 대상인 인벤토리의 특성, 즉 콘텐츠에 불경한 내용이 포함되어 있는지 범죄나 군사 분쟁에 관해 언급하는지를 구매자에게 알려줍니다. BidRequestdetected_content_labels 필드에 콘텐츠 라벨에 해당하는 값이 포함됩니다. 예를 들어 23은 '소셜 네트워크'를 나타냅니다. 콘텐츠 라벨과 이를 나타내는 값의 전체 목록은 다운로드 페이지에서 제공되는 content-labels.txt 파일에서 정의됩니다.

BidRequest에서 설명한 인벤토리에 적용되는 콘텐츠 라벨이 없는 경우 해당 BidRequest에서 detected_content_labels 필드가 생략됩니다. 여러 라벨을 등록하는 경우 해당 필드에 여러 값이 포함됩니다.

동영상 인벤토리의 경우, 콘텐츠 라벨은 어떤 등급이 적절한지(모든 연령, 14세 이상, 성인용)나 해당 동영상 콘텐츠가 등급이 매겨지지 않았는지를 나타낼 수 있습니다. 현재, 모든 동영상 인벤토리가 YouTube에서 오기 때문에 YouTube 콘텐츠 라벨로 되어 있습니다. 동영상 인벤토리의 해당 아이템은 YouTube 콘텐츠 라벨과 함께 하나 이상의 정규 콘텐츠 라벨을 가질 수 있습니다. 도움말 센터에 설명된 것과 같이 YouTube 콘텐츠용 사용자 인터페이스 광고 캠페인을 운영하는 구매자는 필터를 이용하여 광고가 하나 이상의 카테고리에 게재되지 않도록 제한할 수 있습니다.

Google이 가장 적합한 노출에 대한 입찰 요청서를 보내는지 확인하기 위해 사전 타겟팅을 사용할 수 있습니다. 콘텐츠 라벨은 사전 타겟팅에서 사용하는 속성 중에 있습니다.

맨 위로

입찰 URL 매크로

선택사항으로 BidRequest의 일부 필드를 HTTP POST 요청에서 사용되는 URL에 삽입할 수 있습니다. 예를 들어 이 요청의 값을 이용해 여러 백엔드를 통해 밸런스를 로드하는 경량 프론트엔드를 사용할 경우 이 선택 기능은 유용합니다. 현재는 해당 매크로인 GOOGLE_USER_ID만 지원됩니다. 새로운 매크로에 대한 지원을 요청하려면 기술 계정 관리자에게 문의하세요.

입찰자 URL에 %%GOOGLE_USER_ID%%를 삽입하면 이 값이 BidRequest의 해당 google_user_id 필드로 교체됩니다. 예를 들어 입찰자 URL인 http://google.bidder.com/path?gid=%%GOOGLE_USER_ID%%는 요청 시점에 http://google.bidder.com/path?gid=dGhpcyBpcyBhbiBleGFtGxl와 같은 URL로 교체됩니다.

Google 사용자 ID를 모르는 경우에는 빈 문자열이 http://google.bidder.com/path?gid=와 같은 URL로 대체됩니다.

맨 위로

BidRequest 필드의 지원 중단에 대한 적응

언제든지 BidRequest에 있는 일부 필드가 프리픽스인 DEPRECATED_와 함께 나타날 수 있습니다. 즉, 지정된 시간 후에 이들 필드가 더 이상 BidRequest에 나타나지 않습니다. 모든 경우에 정확한 기간(알림 기간)이 출시 노트, 블로그 게시물 및 이메일 뉴스레터를 통해 공지됩니다. 알림 기간 동안 사용중지 필드의 모든 종속 내용을 삭제할 수 있도록 입찰자 코드를 업데이트해야 합니다. 이렇게 하지 않으면 입찰자가 더 이상 전송되지 않는 BidRequest의 정보에 의존할 수 있습니다.

지원이 중단된 필드(2013년 5월 1일에 업데이트됨)

아래 표에 나온 필드는 더 이상 전송되지 않습니다.

메시지 필드
BidRequest protocol_version
excluded_click_through_url
company_name
BidRequestMobile 하위 메시지(종전 MobileApp 하위 메시지) app_name
company_name
carrier_name
carrier_country
BidRequestMatchingAdData 하위 메시지 campaign_id

아래 표에는 지원이 중단된 BidRequest의 필드가 설명되어 있습니다.

메시지 필드
BidRequestMatchingAdData 하위 메시지 buyer_minimum_cpm
fixed_cpm_micros
BidRequestAd 하위 메시지 allowed_attribute
publisher_settings
excluded_click_through_url
BidRequest protocol_version
click_tracking_url
cookie
country
region
city
metro
hashed_cookie
excluded_click_through_url
seller_network
publisher_settings
MatchingNetwork network_id
google_user_id

맨 위로

허가 제휴업체 명시

시장조사, 리마케팅, 광고 서버와 같은 서비스를 제공하는 제휴업체는 Ad Exchange 구매자와 판매자 사이의 상호작용 역할을 하기도 합니다. Google이 Ad Exchange 상호작용 참여를 심사한 제휴업체만을 허가합니다.

BidRequest를 이해하고 BidResponse를 생성하려면 제휴업체 명시의 세 가지 방법을 숙지해야 합니다.

  1. 일부 제휴업체는 명시하지 않아도 됩니다.

  2. 다른 제휴업체가 BidRequestBidResponse에 명시된 경우 이들 제휴업체만 참여할 수 있습니다.

    • BidRequest에서 allowed_vendor_type 필드는 판매자가 허용하는 제휴업체를 지정합니다.
    • BidResponse에서 vendor_type 필드는 구매자가 사용할 허용된 제휴업체를 지정합니다.

  3. 마지막으로 Google 디스플레이 네트워크(GDN)에서 발생하는 노출의 경우 항상 허용되는 제휴업체의 목록이 있습니다. 이들 제휴업체는 BidRequest에 명시되지 않습니다. BidResponse에서 구매자는 이 목록에 있는 제휴업체만 명시해야 합니다.

이 카테고리들에 어떤 제휴업체가 들어가는지를 알려면 다음의 자료를 참조하세요.

  • 명시할 필요가 없는 제휴업체는 Ad Exchange 구매자 도움말에 나와 있습니다.
  • BidRequest의 allowed_vendor_type 필드에서 전송되는 제휴업체는 Vendors.txt 사전 파일에 나와 있습니다.
  • Google 디스플레이 네트워크(GDN)의 노출에 대한 BidResponse에 명시해야 하는 제휴업체는 전송되지 않습니다. gdn_vendors.txt 사전 파일에서는 이들 제휴업체를 묵시적으로 나타냅니다.

참고: 이 규칙은 2012년 4월 1일에 발효된 RTB 프로토콜의 간소화를 나타냅니다. 제휴업체 신고에 대해 이 날짜 이전의 BidRequestBidResponse는 다소 다르며 관련 사전 파일의 일부도 다릅니다.

맨 위로

입찰 요청 예제

다음의 예에는 BidRequest 프로토콜 버퍼가 google/protobuf/text_format.hTextFormat 클래스를 이용하여 직렬화된 것으로 나와 있습니다. 아래는 Google로부터 받을 수 있는 내용의 예입니다.

id: "Mv\2005\000\017.\001\n\345\177\307X\200M8"
ip: "\314j\310"
user_agent: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13,gzip"
country: "US"
region: "US-MA"
city: "Boston"
metro: 506
url: "http://www.example.com/"
detected_language: "en"
detected_vertical {
  id: 22
  weight: 0.67789277
}
detected_vertical {
  id: 355
  weight: 0.32210726
}
adslot {
  id: 1
  width: 300
  height: 250
  excluded_attribute: 7
  excluded_attribute: 22
  matching_ad_data {
    adgroup_id: 3254984134
    minimum_cpm_micros: 2000000
  }
  matching_ad_data {
    adgroup_id: 2646216548
    minimum_cpm_micros: 2000000
  }
  targetable_channel: "all pages,middle right"
  publisher_settings_list_id: "I\034\334o~)\367\034\020\230E#\235w\212"
  slot_visibility: BELOW_THE_FOLD
}
is_test: false
cookie_version: 1
google_user_id: "CAESEIcS1pC2TBvb-4SLDjMqsY9"
seller_network_id: 1
publisher_settings_list_id: "\357\237V\206)\231\3125%|$\032\""
vertical_dictionary_version: 2
timezone_offset: -300
cookie_age_seconds: 7685804

이를 2진법 형식으로 변환하기 위해, 실제 요청에서 POST 페이로드에서와 마찬가지로, C++에서 다음을 할 수 있습니다.

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은 프로토콜 버퍼의 2진법 직렬화임
  }
}

맨 위로

 

다음에 대한 의견 보내기...

DoubleClick Ad Exchange Real-Time Bidding Protocol