들어가며
광고주가 모르는 채 구매하고 있는 디스플레이·동영상 광고 인벤토리의 상당수는 header bidding이라는 동시 경매 구조 위에서 거래됩니다. publisher가 한 광고 슬롯을 여러 SSP·DSP에 동시에 노출해서 가장 높은 입찰가를 부른 광고주에게 파는 방식이고, 이 구조가 자리 잡으면서 광고 가격·도달 분포·운영 함정이 모두 바뀌었습니다. 이 글은 header bidding의 작동 원리와 마케터가 알아야 할 함의를 RTB 운영자 시선에서 정리합니다.
한 광고 슬롯을 여러 곳이 동시에 보는 작은 시장 — 가격이 더 정확해진다
Waterfall vs Header Bidding
옛 구조 — Waterfall
전통적인 구조에서 publisher는 SSP를 우선순위 순으로 호출했습니다.
- SSP 1번에 인벤토리 보여줌 → 입찰 받음 → 일정 가격 이상이면 거래
- 거래 안 되면 SSP 2번에 보여줌
- 그래도 안 되면 SSP 3번…
문제는 1번 SSP가 우선이라 그 안에서만 경쟁이 일어나고, 2번 SSP의 광고주가 더 높은 가격을 부를 수 있어도 1번에서 거래되면 못 봅니다.
📌 이 글의 전제
프로그래매틱·DSP·SSP라는 단어를 한 번이라도 들어봤다고 가정합니다(rtb-bidding 참고). 광고주 측 자동 입찰 운영을 한다고 가정합니다.
새 구조 — Header Bidding
publisher가 모든 SSP에 동시에 인벤토리를 보여줍니다. 모든 SSP가 자기 광고주들의 입찰을 모아 publisher에게 보내고, publisher가 가장 높은 가격을 부른 곳과 거래합니다.
| 구조 | 경쟁 범위 | 가격 결정 |
|---|---|---|
| Waterfall | 우선순위 순서대로 | 첫 거래 가격 |
| Header bidding | 모든 SSP 동시 | 최고가 |
가격 발견(price discovery)이 더 정확해지고, publisher 매출이 평균 10~30% 늘어났다는 보고가 일반적입니다.
작동 흐름 — 한 광고 노출의 안쪽
단계별
- 사용자가 publisher 페이지 로드
- publisher의 header bidding 라이브러리(prebid.js 등)가 여러 SSP에 동시 입찰 요청
- 각 SSP가 자기 DSP·광고주 입찰을 수집해 응답
- 모든 응답이 도착하거나 timeout(보통 100~300ms)되면 최고가 결정
- publisher 광고 서버가 최고가 입찰을 광고로 띄움
시간 제약
전체 과정이 수백 ms 안에 끝나야 페이지 로딩 속도에 영향이 없습니다. timeout 너무 짧으면 좋은 입찰을 놓치고, 너무 길면 페이지 느려져 사용자 이탈.
광고주(우리) 입장의 함의
더 많은 입찰 기회
같은 인벤토리에 더 많은 SSP를 통해 입찰 기회가 생깁니다. 우리 DSP가 SSP 1번에 연결되어 있다면 waterfall에서 SSP 1번이 우선일 때만 입찰 기회가 있었지만, header bidding에서는 모든 라운드에 참여할 수 있습니다.
가격 상승 압력
publisher 매출이 늘었다는 건 광고주 평균 단가도 올랐다는 뜻입니다. 같은 인벤토리에 더 많은 광고주가 동시 입찰하니까 시장가가 올라갑니다.
| 효과 | 광고주 입장 |
|---|---|
| 입찰 기회 증가 | 도달 reach 늘어남 |
| 평균 단가 상승 | 효율 일부 하락 |
| 가격 발견 정확 | 우리 가치 인식 정확해짐 |
| 인벤토리 다양성 | 같은 인벤토리에 다른 광고주 |
자동 입찰의 적응
자동 입찰 ML은 header bidding 환경에서 다음을 학습합니다.
- 같은 인벤토리에 대한 시장 가격 분포
- timeout 안에 응답할 수 있는 입찰 처리 속도
- 다른 SSP와의 가격 경쟁력
이 학습이 잘 되면 같은 예산으로 더 효율적인 인벤토리를 사고, 안 되면 비효율적인 인벤토리를 비싸게 사게 됩니다.
SSP·DSP·DMP — 누가 무엇을 하나
역할 정의
| 약자 | 역할 | 예시 |
|---|---|---|
| SSP (Supply-side Platform) | publisher 측, 인벤토리 판매 | Magnite, PubMatic, OpenX |
| DSP (Demand-side Platform) | 광고주 측, 인벤토리 구매 | DV360, The Trade Desk |
| DMP (Data Management) | 사용자 데이터 관리 | Adobe Audience Manager |
| Ad Exchange | 매칭 시장 | Google Ad Manager, Xandr |
광고주는 DSP로 들어가고, 그 DSP가 여러 SSP·exchange에 입찰을 보냅니다.
멀티 DSP 운영
큰 광고주는 두 개 이상 DSP를 동시에 운영해 인벤토리 도달과 가격 협상력을 늘립니다. 단점은 동일 사용자에게 여러 DSP가 입찰해 같은 사람한테 광고가 더 자주 보일 수 있고, 통합 frequency cap이 안 되면 노출 폭주.
Server-side Header Bidding
Client-side vs Server-side
전통 header bidding(client-side)은 사용자 브라우저에서 SSP에 직접 요청합니다. 페이지 로딩 속도에 영향이 큽니다.
server-side header bidding은 publisher 서버가 대신 SSP에 요청합니다. 사용자 측 부담이 줄지만 publisher의 서버 비용이 늘고 디버깅이 어렵습니다.
| 항목 | Client-side | Server-side |
|---|---|---|
| 페이지 속도 | 영향 큼 | 영향 작음 |
| Publisher 비용 | 적음 | 큼 |
| 1st-party 데이터 활용 | 어려움 | 쉬움 |
| 디버깅 | 브라우저 도구 | 서버 로그만 |
쿠키·IDFA 끊긴 시대에 1st-party 데이터를 쓰기 좋다는 점에서 server-side가 늘어나는 추세입니다.
Floor Price와 Bid Floor
Publisher가 정하는 최소가
publisher가 인벤토리 슬롯마다 최소 입찰가(floor price·bid floor)를 정합니다. floor 이하 입찰은 거래 안 됨. floor 너무 높으면 거래 자체가 안 일어나고, 너무 낮으면 매출 잃음.
Dynamic Floor
요즘은 publisher가 사용자 가치·시간대·인벤토리 가용량에 따라 floor를 동적으로 조정합니다. 광고주 입장에서는 같은 인벤토리도 시점마다 다른 floor를 만나게 됩니다.
⚠️ floor 함정
Publisher가 floor를 갑자기 올리면 같은 캠페인이 같은 예산으로 도달하는 reach가 줄어듭니다. 캠페인 reach가 갑자기 떨어지면 publisher측 floor 변경 가능성을 의심합니다.
Brand Safety와 Inventory Quality
모든 인벤토리가 우리 브랜드와 어울리는 건 아님
header bidding은 도달은 늘리지만 brand safety 위험이 늘어납니다. 같은 광고가 우리 브랜드와 안 맞는 페이지에 노출될 가능성.
대응: 카테고리 블록·키워드 블록·publisher 화이트리스트·brand safety 도구(IAS·DoubleVerify) 사용.
Made For Advertising (MFA) 사이트
광고 매출만 노린 저품질 사이트(MFA)는 header bidding을 통해 자동으로 우리 광고를 받을 수 있습니다. 분기마다 한 번 인벤토리 도달 분포를 점검해 MFA 비중을 확인.
| 인벤토리 카테고리 | 평균 ROAS |
|---|---|
| 메인스트림 미디어 | 높음 |
| 전문·니치 사이트 | 중간 |
| MFA·낮은 품질 | 낮음 또는 음수 |
💡 브랜드 보호 룰
· MFA 사이트 자동 차단 도구 활성화
· publisher 도메인 list를 분기마다 검토
· "ad fraud" 의심 도메인은 즉시 차단
· brand safety 도구의 카테고리 블록 정책 점검
측정 — 어디서 도달했나
분기 점검
- 광고가 도달한 publisher 도메인 top 100
- 도메인별 ROAS·CTR 분포
- 도메인별 평균 단가
- MFA·suspect 도메인 비중
알림 디자인
- MFA 비중 > 10% → 알림
- 단일 publisher 비중 > 30% → 알림 (한쪽 의존)
- 평균 단가 분기 대비 ±25% 변동 → 알림
이 알림이 자동 입찰 환경에서 운영 가시성을 유지하는 거의 유일한 방법입니다.
Open RTB와 표준화
OpenRTB 프로토콜
header bidding과 RTB 전체의 표준 통신 프로토콜이 OpenRTB입니다. SSP·DSP가 이 프로토콜로 통신해 입찰 요청·응답을 주고받습니다.
Prebid.js — 오픈소스 라이브러리
publisher가 client-side header bidding을 구현할 때 가장 흔히 쓰는 라이브러리. SSP·exchange를 어댑터로 추가해 동시 입찰 운영 가능.
분기 점검 체크리스트
인벤토리 분포
- [ ] 도달 publisher 도메인 다양성 (top 5 비중 < 50%)
- [ ] MFA·suspect 도메인 < 10%
- [ ] brand safety 카테고리 블록 정책 갱신
- [ ] 카테고리별 ROAS 분포 확인
가격·효율
- [ ] 평균 단가 변동성 < 25%
- [ ] 자동 입찰 ML 학습 안정 (1~2주 안정화)
- [ ] floor price 변동 모니터링
Multi-DSP 운영 (해당 시)
- [ ] DSP 간 frequency cap 통합
- [ ] DSP 간 인벤토리 중복 비율
- [ ] 각 DSP의 ROAS 비교
💡 실무 운영 룰
중소 광고주는 단일 DSP로 충분합니다. 멀티 DSP 운영은 월 광고비 1~10억 수준 이상에서 ROI가 나옵니다. {/* TODO_HUNY: 우리 회사가 사용하는 DSP·SSP와 도달 인벤토리 가시성 한 단락 */}
함정 모음
- 도달 인벤토리 분포 무시 — MFA 비중 폭증 모름
- floor 변동 미인식 — reach 갑자기 줄어듦
- multi-DSP frequency 폭주 — 통합 cap 없음
- brand safety 정책 노화 — 새 카테고리·도메인 미반영
- timeout 너무 짧게 — publisher 측 설정, 입찰 기회 놓침
마치며
Header bidding은 디스플레이·동영상 광고 시장의 현재 표준 거래 구조이고, 광고주에게 도달 reach와 가격 정확도를 동시에 늘려준 변화입니다. 동시에 brand safety·MFA·multi-DSP 노출 폭주 같은 새 함정도 가져왔습니다. 마케터가 자동 입찰을 켜고 있더라도 분기마다 도달 인벤토리 분포·가격 변동성을 점검하는 게 운영 안전선입니다.
다음 분기에 한 번만 시도해 볼 만한 것은 도달 publisher 도메인 top 100 리스트를 받아 MFA·suspect 비중과 도메인별 ROAS를 정량화하는 분석입니다. brand safety 정책의 다음 사이클을 거기서 시작합니다.
{/* TODO_HUNY: 우리가 도달한 publisher 도메인 분포에서 가장 큰 의외 한 단락 */}
참고
- IAB, "OpenRTB Specification": https://iabtechlab.com/standards/openrtb/
- Prebid.js: https://prebid.org/
- Magnite, "Header bidding explained": https://www.magnite.com/blog/header-bidding/
- "MFA sites and brand safety" (ANA): https://www.ana.net/
- IAS, "Brand safety report": https://integralads.com/insights/
