입찰 요청

A 입찰 요청은 광고 익스체인지 또는 서플라이 사이드 플랫폼이 광고 슬롯이 사용 가능해지자마자 보내는 구조화된 메시지로, 노출, 페이지 또는 앱 컨텍스트, 그리고 사용자 및 기기에 대해 알려진 모든 정보를 설명하여 잠재 구매자가 입찰 여부와 금액을 결정할 수 있도록 합니다.

입찰 요청의 내부 구성#

대부분의 업계가 표준으로 사용하는 OpenRTB 프로토콜에서 입찰 요청은 상당히 일관된 필드 집합을 포함하는 JSON 객체입니다: 광고 슬롯의 크기와 형식을 설명하는 노출 객체, 퍼블리셔 및 사이트 또는 앱 ID, 국가 및 지역과 같은 지리적 타겟팅 데이터, 기기 유형 및 연결 정보, 그리고 판매자가 공유할 수 있는 모든 사용자 또는 퍼스트파티 데이터가 포함됩니다. 노출이 협상된 거래의 일부인 경우, 요청에는 해당 특정 거래를 참조하는 거래 식별자도 포함됩니다.

해당 익스체인지에 연결된 모든 수요 측면 플랫폼은 일반적으로 밀리초 단위로 측정되는 엄격한 응답 시간 내에 동시에 동일한 요청을 받습니다. 각 DSP의 입찰 로직은 이를 활성 캠페인과 비교하여 평가하고, 가격과 크리에이티브가 포함된 입찰 응답을 반환하거나 전혀 입찰하지 않기로 결정합니다.

입찰 요청이 구매자에게 중요한 이유#

입찰 요청의 품질과 완전성은 DSP가 이를 활용할 수 있는 방식을 직접적으로 결정합니다. 풍부한 컨텍스추얼 타겟팅 신호와 깔끔한 사이트 또는 앱 식별 정보가 포함된 요청은 구매자의 알고리즘이 진정으로 정보에 기반한 결정을 내릴 수 있게 합니다. 반면, 정보가 부족하거나 라벨링이 잘못된 요청, app-ads.txt 검증이 누락되거나 공급망 객체가 불완전한 경우 DSP가 활용할 수 있는 정보가 적어지며, 신중한 구매자는 블라인드 입찰보다는 보수적으로 입찰하거나 해당 요청을 완전히 건너뛰는 경우가 많습니다.

이것은 또한 사기가 걸러지거나 빠져나가는 지점입니다. 프리미엄 퍼블리셔의 인벤토리를 대표한다고 주장하면서, 그 주장을 뒷받침하는 ads.txt 또는 sellers.json 기록이 없는 입찰 요청은 DSP와 구매자가 입찰하기 전에 스푸핑되거나 잘못 표현된 인벤토리를 거부하는 데 사용하는 신호입니다.

입찰 요청 볼륨을 시장 신호로 읽기#

구매자는 개별 입찰 요청을 직접 보는 경우는 드물지만, 특정 배치 또는 지역이 생성하는 요청 수와 실제 입찰 응답과의 비교와 같은 집계 패턴은 실제 시장 수요를 파악하는 유용한 대리 지표입니다. 원시 경매 로그보다는 경쟁 조사를 위해, 어떤 크리에이티브와 광고주가 실제로 승리하고 네트워크 전반에서 라이브로 실행되고 있는지 보는 것은 입찰량만 보는 것보다 시장에 대해 더 많은 정보를 제공합니다. OpenAdLibrary의 광고 인텔리전스 인덱스는 정확히 이를 위해 구축되었습니다: 경매 인프라에서 시장을 추론하는 대신 라이브 크리에이티브 수준의 가시성을 제공합니다.

FAQ#

모든 DSP가 동일한 입찰 요청을 보게 되나요?

단일 경매 라운드 내에서는 연결된 DSP들이 일반적으로 동시에 동일한 요청을 받습니다. 차이점은 각 DSP의 자체 로직이 해당 요청에 대해 입찰할지 여부와 얼마를 입찰할지 결정하는 방식에 있습니다.

DSP는 입찰 요청에 얼마나 빨리 응답해야 하나요?

응답 시간은 일반적으로 수십 밀리초에서 수백 밀리초 미만으로 측정되며, 제시간에 응답하지 못한 DSP는 해당 노출에 대해 입찰하지 않은 것으로 간주될 정도로 짧습니다.

입찰 요청에 항상 사용자 데이터가 포함되나요?

아니요. 포함되는 내용은 동의, 규정, 그리고 퍼블리셔와 해당 SSP가 전달하도록 설정된 내용에 따라 달라집니다. 오늘날 많은 요청은 과거보다 개인 수준의 사용자 데이터를 적게 포함하며, 대신 컨텍스추얼 및 퍼스트파티 신호에 더 의존합니다.

입찰 요청에 공급망 데이터가 누락되면 어떻게 되나요?

구매자와 그들의 사기 탐지 도구는 불완전한 공급망 또는 ads.txt 데이터를 위험 신호로 간주하는 경우가 많습니다. 일부 DSP는 여전히 입찰하지만 더 보수적으로 입찰하는 반면, 다른 DSP는 해당 요청을 아예 건너뛰도록 구성되어 있습니다.