Skip to content

구간별 프로토콜과 데이터 경계

문서 목적

광고플랫폼의 전체 흐름을 역할이 아니라 구간 기준으로 나눠서 본다. 각 구간마다 관심사가 다르고, 강한 업계 표준이 있는 구간과 플랫폼별 공통 모델에 더 많이 의존하는 구간이 다르다는 점을 구분하는 것이 목표다.

핵심 요약

  • 광고플랫폼은 하나의 단일 프로토콜로 처음부터 끝까지 이어지지 않는다.
  • DSP ↔ SSP / Exchange 구간은 OpenRTB가 강하게 작동하는 대표 구간이다.
  • SSP ↔ Publisher SDK / Player / Tag 구간은 업계 공통 패턴은 있지만 단일 범용 표준은 약하다.
  • SDK / Player ↔ Measurement / Verification 구간은 VAST tracking과 OM SDK / OMID가 중요한 기준선이 된다.
  • 광고주 · Agency ↔ DSP 구간은 실시간 입찰보다 캠페인 제어와 운영 데이터에 더 가깝다.

전체 그림

구간별 한눈에 보기

구간주요 관심사강한 표준 프로토콜대표 데이터
광고주 · Agency ↔ DSP캠페인 설정, 타기팅, 예산, 크리에이티브 운영단일 범용 표준은 약함campaign, line item, creative, audience, budget, goal
DSP ↔ SSP / Exchange경매, 입찰 판단, 가격, 크리에이티브 전달OpenRTBid, imp, site/app, device, user, source, regs, price, adm
SSP ↔ Publisher SDK / Player / Tag광고 요청, 광고 응답, creative/VAST 전달단일 범용 표준은 약함, video에서 VAST 비중이 큼placement, app/site context, VAST URL/XML, markup, tracker
SDK / Player ↔ Measurement / Verification노출, 클릭, 진행률, viewability, verificationVAST Tracking, OM SDK / OMIDimpression, click, quartile, AdVerifications, OM session

왜 이 구분이 중요한가

1. OpenRTB가 모든 구간을 직접 표준화한다고 오해하지 않기 위해서

OpenRTB는 매우 중요하지만, 주로 SSP ↔ DSP / Exchange 경매 구간에서 강하게 작동한다. SDK가 광고를 요청하고 실제로 노출과 검증 이벤트를 발생시키는 구간은 다른 프로토콜과 런타임 규칙이 함께 작동한다.

2. 필드의 책임 주체를 분리하기 위해서

  • campaign budget는 광고주 · DSP 구간 데이터다.
  • imp, device, regs는 주로 bid request 구간 데이터다.
  • adm, VAST URL, markup은 delivery 구간으로 넘어가는 연결점이다.
  • impression, click, quartile, viewability는 runtime event 구간 데이터다.

3. 설계 논의를 더 정확하게 하기 위해서

실무에서 가장 흔한 오해는 ad requestbid request, ad responsebid response, impimpression을 같은 층으로 섞어 보는 것이다. 구간을 분리해 보면 어떤 데이터가 어디에서 생성되고 어느 주체가 책임지는지 더 명확해진다.

관련 표준 문서

이어서 볼 문서

광고플랫폼 이해를 위한 공개형 학습 문서