헤더 비딩: 그것이 무엇이며 어떻게 작동합니까?

게시 됨: 2020-04-23

Adtech는 광고주와 게시자 간의 거래를 간소화하는 것을 목표로 합니다. 업계의 발전에도 불구하고 디지털 광고 시장은 여전히 ​​조정이 부족합니다. 따라서 게시자는 광고 인벤토리를 최대한 활용하기 위해 다양한 플랫폼과 수익 창출 소스를 저글링해야 합니다.

헤더 비딩은 이러한 불연속성을 해결하기 위한 솔루션으로 등장했습니다. 게시자가 광고 인벤토리에서 수익을 창출할 수 있는 보다 효과적인 메커니즘을 제공합니다. 지난 몇 년 동안 헤더 비딩(header-bidding)이 두각을 나타내었고 대규모로 채택되었습니다. 그러나 시스템의 내부 작동은 여전히 ​​혼란을 야기합니다.

목차:
  • 헤더 입찰이란 무엇입니까?
  • 헤더 비딩 vs 워터폴 vs RTB
  • 헤더 입찰은 어떻게 작동합니까?
  • 클라이언트 측 헤더 입찰 프로세스
  • 클라이언트 측 및 서버 측 헤더 입찰
  • 헤더 입찰 전문가
  • 더 높은 수율
  • 더 높은 유효노출률
  • 쿠키 매칭
  • 제어 및 투명성
  • 헤더 입찰 단점
  • 지연 문제
  • 제한된 광고 요청
  • 호환성
  • 마무리

헤더 입찰이란 무엇입니까?

헤더 입찰은 게시자가 여러 DSP에 인벤토리를 표시하고 여러 광고주로부터 동시에 입찰가를 받을 수 있도록 하는 자동화된 경매 기술입니다. 모든 DSP가 입찰에 대해 동등하게 액세스할 수 있는 경매입니다. 반면에 워터폴링 및 공개 RTB는 차례로 경매에 참여합니다.

헤더 입찰은 트래픽 값에 대한 게시자와 광고주 간의 정보 비대칭을 제거합니다. 이를 통해 게시자는 광고 공간에 대해 공정한 수요 기반 가격을 얻을 수 있습니다.

Admixer.Network 화이트 라벨 솔루션의 소유자는 이제 헤더 입찰 기술의 잠재력을 최대한 활용하여 게시자에게 더 많은 수입을 제공하고 프로그래밍 방식 구매의 전반적인 효율성을 높일 수 있습니다.

헤더 비딩 vs 워터폴 vs RTB

헤더 입찰 모델이 도입되기 전에 게시자는 거의 폭포식 경매와 공개 RTB를 통해 인벤토리를 판매했습니다.

데이지 체인 또는 폭포 태그라고도 하는 Waterfalling 은 게시자 자산을 순차적으로 판매하여 한 번에 하나의 수요 소스를 호출하는 방법입니다. 이 시나리오에서 게시자는 광고 네트워크 및 광고주에 대한 우선 주문을 설정하고 특정 광고 게재위치에 대해 허용되는 최소 금액인 가격 하한선을 설정합니다.

게시자는 과거 수익에 따라 설정된 순서대로 수요 파트너에게 인벤토리를 순차적으로 제공합니다. 특정 광고주가 가격 하한선을 충족하는 즉시 노출이 판매됩니다.

공개 RTB 에서 게시자는 유사한 모델을 사용하지만 대신 데이지 체인 광고 교환 및 SSP 경매를 사용합니다. 기본적으로 게시자는 모든 광고 인벤토리가 구매될 때까지 일련의 실시간 경매를 실행합니다. 공개 RTB는 2차 가격 경매 모델을 활용합니다. 낙찰자는 두 번째로 높은 입찰자가 제시한 가격에 $0.01를 더한 금액을 지불합니다.

헤더 비딩이 퍼블리셔들 사이에서 선호되는 모델이 된 이유는 이전에 자세히 설명했습니다.

헤더 입찰은 어떻게 작동합니까?

헤더 입찰은 게시자 웹사이트의 헤더에 포함된 JavaScript 코드 문자열을 통해 실행됩니다. 헤더는 독자에게 보이지 않는 HTML 요소입니다. 일반적으로 탐색 링크, 저작권 정보 등을 저장합니다.

코드 문자열은 웹사이트를 광고 인벤토리 구매에 관심이 있는 다양한 소스에 연결합니다. 페이지가 로드될 때마다 수요 소스는 해당 페이지의 각 노출에 대해 입찰할 수 있습니다.

이 절차는 공급측 플랫폼 또는 SSP(예: Admixer.SSP)가 입찰 중인 수요 플랫폼과 입찰 가치를 알 수 있도록 하여 투명성을 높여 CPM을 최대화합니다.

클라이언트 측 헤더 입찰 프로세스

헤더 입찰 작동 방식 - Admixer 블로그
  1. 사용자가 게시자의 웹사이트에 들어갑니다.
  2. 웹페이지 헤더의 JavaScript 래퍼는 사용자 요청을 활성화하고 여러 SSP와 수요 소스(DSP 및 Ad Exchange)에 전달합니다.
    • SSP는 수요 소스로 경매를 수행하고 낙찰된 입찰가를 결정하고 페이지로 반환합니다.
    • 수요 소스는 페이지에 대한 입찰가를 반환합니다.
  3. JavaScript 래퍼 페이지는 브라우저에서 수신된 입찰 사이의 헤더 경매를 수행하고 낙찰된 입찰을 광고 서버로 보냅니다.
  4. 광고 서버는 페이지에서 낙찰된 입찰의 광고 소재를 제공합니다.

사용자는 최고 입찰자의 광고를 봅니다. 모든 것이 밀리초 이내에 발생합니다.

클라이언트 측 및 서버 측 헤더 입찰

위에서 설명한 프로세스는 클라이언트 측 헤더 입찰의 한 예이며 서버 측 구현과 함께 이 기술의 다른 다양성도 있습니다.

서버 측 헤더 입찰은 한 가지 주목할만한 예외를 제외하고 클라이언트 측과 유사한 절차를 따릅니다. 광고 요청을 광고 기술 플랫폼으로 직접 보내는 대신 서버 측 헤더 입찰은 광고 요청을 별도의 서버로 전달합니다. 그 후에야 서버가 Ad Exchange에 요청을 보냅니다. 서버가 입찰을 수신한 후 브라우저로 다시 보냅니다.

서버 측 모델 은 브라우저가 아닌 전용 서버에서 입찰이 이루어지기 때문에 헤더 입찰 , 페이지 대기 시간 의 주요 문제를 해결 합니다.

그러나 이 모델은 투명성이 부족합니다. 입찰은 서버에서 이루어지기 때문에 게시자는 경매 결과를 평가하는 데 어려움을 겪을 수 있습니다. 또한 브라우저에서 입찰이 제거되기 때문에 쿠키가 손실되어 광고주가 사용자를 식별하기 어려울 수 있습니다.

헤더 입찰 전문가

더 높은 수율

가격 하한선을 설정하기 위해 이전 데이터에 의존하는 대신 헤더 입찰을 통해 광고주가 광고를 게재하기 전에 노출에 대해 미리 지불할 의사가 있는 금액을 확인할 수 있습니다. 게시자는 한 번에 여러 광고주에게 광고 노출이 얼마나 가치가 있는지 결정합니다. 입찰가가 가장 높은 수요 소스가 궁극적으로 노출을 얻습니다.

Liz Tokareva SmartyAds - Admixer 블로그

SmartyAds의 클라이언트 서비스 부사장인 Liz Tokareva는 다음과 같이 말합니다.

"헤더 입찰은 게시자가 인벤토리 및 거래에 대한 제어를 강화하여 더 많은 수익을 창출할 수 있도록 하기 때문에 프로그래밍 방식에서 뜨거운 주제입니다. 헤더 입찰을 사용하면 게시자는 각 노출에 대해 최상의 구매자를 찾고 콘텐츠로 수익을 창출하고 거의 또는 절대적으로 무료로 독자에게 제공할 수 있습니다.

인벤토리 관리의 이러한 변화는 게시자에게 상당한 이점을 제공하지만 신속하고 정보에 입각한 결정도 필요합니다. 통합 엔드 투 엔드 솔루션은 특히 보고 및 분석 기능과 관련하여 이러한 솔루션을 만드는 데 매우 중요합니다.”

더 높은 유효노출률

광고 인벤토리의 더 높은 수익 외에도 헤더 입찰은 노출이 무인 상태로 남아 있지 않은 더 높은 유효노출률을 보장합니다. 게시자는 SSP가 전체 노출을 제공할지 여부를 알고 있습니다. 헤더 입찰은 SSP가 제공된 모든 인벤토리를 채우는 통합 경매로 감소시켜 여러 수준의 순차 입찰과 관련된 채우기 위험을 제거합니다. 헤더 비딩을 사용하면 게시자 측에서 데이지 체인을 설정하는 수동 작업이 없습니다.

쿠키 매칭

입찰 프로세스가 브라우저에서 이루어지기 때문에 SSP와 DSP는 쿠키를 동기화하여 광고주가 게시자의 웹사이트에서 사용자를 식별할 수 있도록 합니다.

사용자 기록을 추적하는 기능을 통해 광고주는 타겟 캠페인 및 리타겟팅 광고를 실행하여 청중을 더 잘 파악할 수 있습니다. 동시에 게시자는 수요가 많은 잠재고객으로부터 더 많은 수익을 얻습니다.

제어 및 투명성

헤더의 JavaScript 문자열은 게시자의 관리 시스템으로 작동합니다.

이 헤더 입찰 래퍼의 도움으로 게시자는 입찰 기간을 손쉽게 설정할 수 있을 뿐만 아니라 새로운 수요 파트너를 제거 및 추가할 수 있습니다.

그럼에도 불구하고 래퍼를 변경하는 것은 간단한 작업이 아니며 이 복잡한 설정에 대한 전문 지식이 필요합니다. 그러나 헤더 입찰 래퍼 또는 태그는 가격 책정 및 수요 소스에 대한 제어 측면에서 게시자에게 더 큰 투명성을 부여합니다.

헤더 입찰 단점

지연 문제

헤더 입찰은 폭포식 경매, 특히 패스백의 비효율성을 완화하기 위해 설계되었습니다. 그러나 헤더 비딩의 구현은 완벽하지 않습니다.

헤더 입찰은 페이지 헤더에 더 많은 스크립트를 추가하여 페이지 로드 시간을 늘리고 사용자 경험을 손상시키며 결과적으로 표시되는 노출수를 줄입니다.

또한 헤더 비딩은 서버 및 플랫폼과의 수많은 연결을 수반하기 때문에 인터넷 연결 속도가 느려져 사용자 경험에 또 다른 부정적인 요소가 됩니다.

제한된 광고 요청

브라우저가 한 번에 만들 수 있는 요청의 수는 제한되어 있습니다. 즉, 헤더 입찰 래퍼도 제한된 양의 광고 요청을 보낼 수 있습니다. 이 때문에 광고 공간에 입찰할 수 있는 수요 파트너의 수도 제한됩니다.

호환성

헤더 입찰은 브라우저를 통해 작동하므로 다른 브라우저 및 버전과 역호환되어야 하며, 이로 인해 추가 장애물이 발생할 수 있습니다. 특정 브라우저는 외부 픽셀에 대한 우선 순위가 낮을 수 있습니다. 결과적으로 그들은 그것들을 완전히 차단하여 헤더 입찰 경매를 비효율적으로 만들 수 있습니다.

마무리

헤더 입찰을 구현함으로써 게시자는 보다 다양한 광고주 풀로부터 더 많은 입찰가를 받습니다. 그 결과 광고 게재 가격과 게시자의 수익을 높이는 총 수요가 높아집니다.

그러나 헤더 래퍼 설정은 단순한 광고 태그보다 복잡하므로 기술 파트너를 현명하게 선택해야 합니다.

헤더 비딩은 업계의 새로운 표준이 되고 있으며 공개 RTB는 특정 광고주 풀의 우선 순위를 지정하려는 퍼블리셔를 위한 실행 가능한 전략으로 남아 있습니다. 두 가지 장점을 모두 활용하고 싶다면 Admixer는 헤더 입찰과 공개 RTB를 통합하는 하이브리드 모델을 제공합니다.

헤더 비딩 구현을 고려하고 있다면 Admixer의 CPO인 Elena Podshuvejt에게 문의하십시오. [email protected]