헤더 비딩은 퍼블리셔가 광고 인벤토리를 여러 디맨드 및 익스체인지에게 동시에 제공하여 실시간 경매를 진행하는 프로그래매틱 광고 방식이다.실시간으로 가장 높은 입찰가를 제시한 광고가 선택된다. 웹페이지의 <head> 섹션에 JavaScript 코드를 삽입하여 구현되기 때문에 헤더 비딩이라고 불리는데, 모바일 앱 환경에서는 웹페이지의 "헤더"가 존재하지 않기 때문에, 이때는 "패러렐 비딩(Parallel Bidding)" 또는 "패러렐 경매(Parallel Auction)", 혹은 App Bidding이라고도 부른다.
반면 워터폴 방식은, 광고 인벤토리에의 입찰 기회를 "동시에" 여러 파트너사들에게 제공하지 않고, 퍼블리셔가 미리 설정한 우선순위에 따라 순차적으로 광고 네트워크에 요청을 보낸다. 주로 과거 eCPM 데이터를 기반으로 우선순위를 결정한다. 직관적으로 아래와 같은 문제점이 waterfall bidding에서 발생한다고 예상해볼 수 있다: Waterfall auction서 Ad Network 3 이 Ad Network 2보다 보다 높은 입찰가를 제시함에도 불구하고, Waterfall에서는 Ad Network 3까지 기회가 가지 않는다.
당연히 헤더비딩이 매체 수익 관점에서 이득이 크다 하겠다.
그럼에도 워터폴 방식을 사용하게 되는 경우 / 헤더비딩에 어려움이 있는 경우에 대해 이야기해보자면,
1. 기술적 난이도: 헤더비딩의 기술적 난이도가 있는 편이다. 여러 개 ad network에 동시에 요청하고 응답을 처리하는 과정의 복잡도나 지연속도가 문제가 될 수 있다. HTTP 1.1 시기에는 브라우저에서 동작 시 동시에 처리할 수 있는 요청 수가 제한되어(6개) 있어, 많은 수의 입찰 요청을 동시에 처리하는 데 어려움이 있었다 (2.0 이후부터는 제한이 없어졌다). (그러나 1.1에서도 각 SSP 요청을 ssp1.domain.com, ssp2.domain.com 식으로 분산하여 브라우저의 연결 제한 회피하는 방법도 있다고 한다.)
2. 클라이언트 사이드에서 구동됐기 때문에, 사용자의 네트워크 속도에 구애를 받는다. 워터폴도 비딩 passback이 많아지면 지연이 발생하지만서도. 이를 위해 서버사이드 비딩이 도입되었는데, 입찰 프로세스가 사용자의 브라우저나 앱이 아닌 퍼블리셔의 서버에서 이루어진다.
3. 매체마다 사정이 다르기 때문에: 내부광고를 내보내야 할 수도 있고, 직접판매한 광고의 노출수 보장이라든가 하는 이유도 있겠다. 이런 케이스를 위해 하이브리드 방식도 존재한다. 그럼에도 불구하고 2022년 1분기 기준으로 미국 매체사의 70%가 웹사이트에 헤더 비딩 기술을 도입했다고 한다.
'Adtech' 카테고리의 다른 글
| Programmatic Buying Models (1) | 2025.01.12 |
|---|---|
| MRAID와 VAST (2) | 2024.12.25 |
| RTB real-time bidding의 간략한 역사 (3) | 2024.12.22 |
| SKAdNetwork (SKAN)의 정의 (0) | 2022.06.25 |
| Moloco 몰로코 (0) | 2022.04.23 |
