OpenRTB 기초

2. OpenRTB 기초                                                  

 광고 요청은 publisher site에서 시작. 각 인바운드 광고 요청에 대해 입찰 요청이

입찰자에게 브로드캐스트 되고, response는 일반적인 경매 규칙에 따라 평가하고,

경매에서 이긴 사람에게 공지가 되고 광고 마크업이 리턴됩니다.

경쟁에서 이기면 URL을 공지하고, bidder가 커뮤니케이션 하는데 중요한 정보를

exchange할 수 있는 몇가지 표준 매크로를 포함한 마크업을 포함 할 수 있습니다.

(e.g 명확한 가격)

위 그림을 보면 손실 알림에 대한 명확한 규정이 없다는 것을 알 수 있습니다.

이것은 중요한 시스템 및 대역폭 비용 때문에 그렇게 하는것입니다. 그러나

exchange는 오프라인 또는 요청/응답 프로토콜 이외의 별도의 프로세스를 통해 손실된

입찰 데이터를 제공하는 것이 좋습니다.

이 문서는 입찰 요청 및 응답과 win 공지와 응답의 실시간 상호 작용에 초점을 맞춘다.

다른 상호작용(e.q 차단 목록 동기화, 트래픽 제어)은 미래 전략에 대한 후보 또는 거의

OpenRTB에 의해 정의된다.

2.1 Transport                                                  

 exchange와 bidder 사이의 기본 프로토콜은 HTTP입니다. 구체적으로, HTTP POST는

HTTP GET보다 더 큰 payload를 수용할 수 있는 binary 표현의 사용을 용이하게하기

위해 입찰 요청을 할 때 사용된다. win 공지는 exchange의 재량에 따라 HTTP POST

또는 HTTP GET을 사용 할 수 있습니다.

 ex)연결 성능을 개선하는 간단하고 가장 효과적인 방법 중 하나는 HTTP 통신을

 지속적으로 연결 가능하게 하는 것이다. 이 인터페이스의 양측에 접속 관리

 오버헤드 뿐만 아니라, CPU 사용률을 줄임으로써 전체 성능에 큰 영향을 미친다.

 -2.2 security

  서버간 통신 시 다른 방법으로 보호 할 수 있는 방법이 있기 때문에,

SSL(Secure Sockets Layer)이 꼭 요구되지는 않는다. 또한, SSL은 추가 프로세싱

오버 헤드 때문에 추천하지 않는다.

2.3 Data Format                                              

  bid 요청/응답 data 전송 시 JSON 형식을 사용할 것을 권장합니다. JSON은

가독성과 문서의 소형화의 조합으로 이루어져 있기 때문이다. 하지만 exchange는

bid에게 선호하는 형식으로 추가적으로 다른 형식으로도 표현해서 제공 할 수 있다.

data Format의 종류로는 JSON, XML, Apache Avro, ProtoBuf, Thrift 그 외

다수가 있다. 입찰 요청은 Content-Type HTTP Header를 사용해서 MIME 타입과 표현을

지정합니다. (ex. Content-Type: application/json) 그리고 입찰 응답은 입찰 요청과

반드시 data format이 같아야합니다.

 다른 binary 표현을 사용하는 경우, exchange 또는 SSP(Supply Side Platform)는

Content-Type을 적절하게 지정해야합니다. 만약 Content-Type이 없다면, exchange가

따로 default Type을 지정해놓지 않는 이상, bidder는 application/json을 default로

지정해야한다.

 Convention이나 Attribute의 부재는 공식적인 의미를 갖지 않는다(default가 없다.)

대부분의 경우, 따로 지정하지 않는 이상 default 값은 unknown이 된다.

2.4 OpenRTB Version HTTP Header                         

 OpenRTB 버전은 사용자 정의 헤더 파라메터와 함께 입찰 요청의 헤더에 전달되어야

합니다. 헤더에 버전을 정의해놓으면, 입찰 요청을 파싱하기 전에 포함되어있는 메시지의

버전을 인식하도록 되어있습니다.

   ->> x-openrtb-version: 2.3

  선택사항이지만, 이 입찰은 입찰자가 구현한 프로토콜 버전 응답의 HTTP 헤더에 동일

형식의 메시지를 배치하는 것이 좋습니다. 이 메시지는 요청 헤더와 다른 버전의 번호를

포함할 수도 있습니다.

 버전이 증가할수록 프로토콜이 변경된다. 버전이 세자리인 경우는 프로토콜 컨텐츠에

 영향을 주진 않는다. 헤더에 버전을 명시할 때 세자리로 등록을 안해도 기술적인 문제는

 발생하지 않는다.

2.5 Privacy by Design (개인 보호 정책 디자인)              

 광고의 구매자와 판매자가 지정한대로 OpenRTB 프로젝트는 완전히 privacy 정책을

지원합니다. 특히 OpenRTB는 do-not-track(3.2.11), COPPA 제한 신호(7.1)

및 User Object를 통해 구매자에게 판매자의 사용자 환경 설정을 통과할 수 있는

능력(3.2.13)을 지원합니다.

2.6 Relationship to IAB Quality Assurance Guidelines(QAG)

  OpenRTB는 IAB의 QAG를 완벽히 호환한다. 특히 이 문서에서 사용된 분류 체계는

QAG로부터 유도된다.

2.7 Customization and Extensions (커스터마이징과 확장)   

  OpenRTB의 스펙은 exchange의 특정 커스텀이나 확장이 가능하다. 어떤 객체도

확장을 포함할 수 있다. 일관성 있는 플랫폼에서 확장 필드를 유지하기 위해서는,

끊임없이 'ext'(내선) 이름을 지정해야 합니다.