OpenRTB bid request 필드 해석 방법: 4단계 체크리스트
- 먼저 스펙 버전과 필수 필드부터 확인합니다.
- imp의 광고 형식과 거래 조건을 분리해 읽습니다.
- 개인정보 신호와 확장 필드는 추측하지 않습니다.
OpenRTB bid request는 먼저 스펙 버전과 최상위 구조를 확인하고, 다음으로 imp에서 광고 기회와 거래 조건을 읽으면 됩니다. 이후 매체 유형에 맞는 site, app 또는 dooh, device, regs, source를 대조하세요. 필드 누락은 필드마다 스펙 기본값이 다를 수 있으므로 일괄적으로 ‘아니오’나 동의로 해석하지 말고, 스펙과 거래 파트너의 전송 규칙을 함께 확인해야 합니다.
1. 버전과 요청의 뼈대부터 확인하기
요청 버전과 JSON 구조 확인
OpenRTB는 실시간 입찰 요청·응답을 주고받기 위한 표준입니다. IAB Tech Lab 공식 저장소는 OpenRTB 2.6부터의 스펙을 관리합니다. 저장소의 버전 정책에 따르면 비호환 변경이 있을 때 버전 번호를 올리고, 호환 가능한 개선 사항은 날짜 코드로 구분해 배포합니다. 로그를 볼 때 ‘2.6’만 기록돼 있는지, 거래 상대가 어떤 세부 릴리스와 구현 규칙을 쓰는지도 확인하세요. IAB Tech Lab OpenRTB 2.6 스펙에서 필드 정의를 확인할 수 있습니다.
최상위 필드의 역할
JSON 최상위의 id는 거래소가 부여하는 입찰 요청 식별자이고, imp는 판매하려는 노출 목록입니다. 최상위 tmax는 거래소가 입찰 응답을 받기까지 허용하는 최대 시간(밀리초), at는 경매 방식, cur는 허용 통화 목록을 나타냅니다. 기본값과 동작은 필드별 스펙 및 거래 파트너의 구현 규칙을 함께 확인하세요.
핵심 기준: 각
imp.id는 요청 안에서 노출을 구분하는 값입니다. 응답의 입찰은 이 ID를 참조하므로, 요청과 응답을 연결할 때 최상위 요청 ID와 혼동하지 마세요.
2. imp에서 실제 광고 기회와 조건 읽기
광고 형식과 노출 식별자
imp는 하나 이상의 객체로 구성될 수 있습니다. 각 객체의 id를 기준으로 광고 기회를 나누고, banner, video, audio, native 중 어떤 하위 객체가 있는지 살펴 형식을 판단합니다. 여러 형식 객체가 함께 있으면 요청이 허용하는 후보 형식을 뜻할 수 있으므로, 무조건 단일 형식으로 단정하지 말고 각 객체의 요구 조건을 읽으세요.
가격과 거래 조건 구분
bidfloor는 노출의 최소 입찰 가격(CPM), bidfloorcur는 그 가격의 통화를 나타냅니다. OpenRTB 2.6 스펙의 bidfloor 기본값은 0이고, 통화 기본값은 USD입니다. 다만 실제 거래에서 기본값을 어떻게 적용하는지 파트너 문서로 확인하세요. pmp와 그 안의 deals가 있다면 비공개 마켓플레이스 거래 조건이 포함됐는지 확인합니다. instl처럼 형식·배치 성격을 나타내는 필드의 열거값은 최신 AdCOM 정의와 파트너 문서에서 확인하는 편이 안전합니다.
| 필드 묶음 | 읽을 내용 | 주의할 점 |
|---|---|---|
imp.id |
요청 내 노출 식별 | 최상위 id와 구분 |
banner/video/audio/native |
허용되는 광고 형식과 요건 | 하위 객체별 조건 확인 |
bidfloor, pmp |
가격 기준과 거래 유형 | 통화·deal 조건 함께 확인 |
3. 매체, 기기, 규제 신호를 교차 확인하기
site, app, dooh는 매체 유형에 맞춰 읽기
site는 웹사이트 정보, app은 앱 정보, dooh는 디지털 옥외 매체 정보를 담습니다. OpenRTB 2.6에서는 이 세 객체 가운데 요청에 둘 이상을 함께 넣지 않습니다. 요청에 포함된 객체를 확인하고, site.domain, site.page, app.bundle, app.storeurl 등 실제 전송된 값이 매체 정보를 일관되게 설명하는지 살펴보세요. 객체가 없다고 바로 잘못된 요청이라고 단정할 수는 없지만, 해당 거래의 필수 필드 규칙은 확인해야 합니다. 필드 하나만으로 매체의 적법성이나 광고 판매 권한을 판정할 수는 없습니다.
device, geo, user와 개인정보 신호
device에는 기기·운영체제·사용자 에이전트·지역 정보가 들어갈 수 있고, user에는 사용자 또는 오디언스 관련 데이터가 실릴 수 있습니다. 식별자 필드는 규제와 플랫폼 정책의 영향을 받으므로, 없는 값을 다른 필드로 추정하거나 로그에 남은 값을 목적 외로 이용하지 마세요. regs의 규제 신호와 user.consent, regs.gpp 등 개인정보 관련 항목은 서로 다른 위치에 있을 수 있어 함께 확인해야 합니다.
주의: 동의 문자열이나 규제 필드가 없다는 사실만으로 동의 상태를 추정하지 마세요. 미전달, 미적용, 파트너별 별도 처리 여부를 해당 연동 문서에서 확인해야 합니다.
4. source와 ext는 공급 경로까지 확인하기
source와 schain의 의미
source는 요청의 출처와 경매 결정에 관한 정보를 담습니다. source.fd는 최종 노출 판매 결정을 맡는 주체를 나타내고, source.tid는 여러 참여자 사이에서 공통으로 사용할 거래 ID입니다. source.schain(SupplyChain 객체)은 OpenRTB 2.6에서 공급 경로의 참여 노드와 경로의 완전성 여부를 표현합니다. 2.5에서는 source.ext.schain 위치를 사용하므로 버전에 맞는 경로를 확인하세요. schain.complete가 0이면 스펙상 공급 경로가 불완전하다는 뜻입니다. 값과 노드 목록, 파트너의 전달 범위를 함께 검토하세요.
ext는 공급자 정의에 따라 해석하기
ext는 거래소나 공급 파트너가 정의한 확장 필드를 담는 자리입니다. 이름이 익숙해도 의미와 자료형이 표준에서 보장되는 것은 아닙니다. 공급자 문서에서 정의, 허용값, 필수 여부, 버전을 확인하고, 문서화되지 않은 값을 타깃팅이나 과금 규칙에 곧바로 연결하지 마세요.
5. bid request 필드 해석 순서 4단계
1단계: 원본과 버전 고정
요청 원본 JSON, 수신 시각, 거래 파트너, 적용 스펙 버전을 함께 기록합니다. 민감한 식별자는 분석용 사본에서 마스킹하고, 원본을 임의로 정규화해 필드 누락 여부가 바뀌지 않게 합니다.
2단계: 구조와 필수 연결 검증
최상위 id와 하나 이상의 imp가 있는지 확인한 뒤, 각 imp.id가 고유한지 봅니다. 입찰 응답을 함께 분석한다면 응답의 impid가 요청의 노출 ID와 일치하는지도 대조합니다. IAB 공식 예시는 OpenRTB 예시 저장소에서 확인할 수 있습니다.
3단계: 형식과 조건을 노출별로 정리
각 imp마다 광고 형식, 크기·미디어 요건, 바닥 가격과 통화, deal 조건을 한 줄씩 정리합니다. 요청 전체에 적용되는 cur, bcat, badv 같은 제한과 노출별 조건을 섞지 않아야 입찰 가능 여부를 설명하기 쉽습니다.
4단계: 맥락·규제·확장 필드 대조
site, app 또는 dooh, device, regs, source의 값을 확인하고, 누락·상충·미지원 필드를 표시합니다. 마지막으로 파트너의 ext 문서와 샘플 요청을 대조해 해석 결과를 확정합니다. 모르는 값은 추측값으로 채우지 말고 ‘미확인’으로 남기는 것이 재현 가능한 분석에 도움이 됩니다.
자주 묻는 질문
Q. OpenRTB 요청에서 반드시 봐야 할 필드는 무엇인가요?
기본적으로 최상위 id와 하나 이상의 imp, 각 노출의 imp.id 및 광고 형식 하위 객체를 확인하세요. 매체와 거래에 따라 추가 필드의 중요도는 달라집니다.
Q. site와 app이 모두 없으면 잘못된 요청인가요?
바로 오류라고 단정할 수 없습니다. 매체 유형이나 공급자 구현에 따라 맥락 정보가 생략될 수 있습니다. 해당 거래의 필수 필드 규칙과 실제 요청 사례를 확인하세요.
Q. bidfloor가 없으면 바닥 가격은 0인가요?
OpenRTB 2.6 스펙에서는 bidfloor의 기본값을 0으로 정의합니다. 다만 실제 연동에서 이 기본값을 적용하는지, 파트너가 별도 규칙을 두는지 확인하세요.
Q. ext 필드는 어디서 확인하나요?
요청을 보낸 거래소나 SSP의 공식 연동 문서와 버전별 샘플을 확인하세요. 표준 스펙만으로 확장 필드의 의미를 확정할 수 없습니다.
