광고 플랫폼 구축(개요)

이 문서는 Google Cloud에서 광고 플랫폼을 구축하는 방법을 다루는 시리즈 중 개요 부분입니다. 이러한 플랫폼은 다양한 서비스로 구성되며 수많은 사용자에게 서비스를 제공하므로 이 시리즈에서는 공통 인프라 옵션과 특정 인프라 옵션을 모두 다룹니다.

시리즈 안내

이 시리즈에는 다음과 같은 2개의 주요 축이 있습니다.

용어

다음 용어는 이 시리즈 전체 및 광고 업계 전반에 걸쳐 사용됩니다.

  • 광고 인벤토리: 구매자에게 제공되는 광고 슬롯입니다.
  • 광고 슬롯: 광고가 표시되는 웹 또는 모바일 페이지의 공간입니다.
  • 광고 태그: 광고 슬롯을 설명하는 매개변수가 포함된 작은 코드 조각입니다.
  • 광고 서버: 게시자의 지면에 있는 광고 슬롯에 광고 소재를 게재하기 위해 광고 게재 플랫폼에서 사용하는 기술입니다. 일반적으로 광고 서버에는 광고 소재 선택, 집계, 게재와 같은 기능이 포함됩니다.
  • 광고주: 다른 미디어를 통해 제품을 직접 홍보하거나 다른 구매자를 통해 홍보하려는 조직입니다.
  • 잠재고객: 게시자 속성을 사용하거나 방문하는 (순) 사용자입니다.
  • 잠재고객 세그먼트: 하위 집합의 분류를 기반으로 한 선택으로, 광고주가 타겟팅할 수 있는 (순) 사용자 집합입니다.
  • 구매자: 광고 슬롯을 구매하여 광고 소재를 배치합니다. 구매자는 네트워크, 대행사 또는 광고주일 수 있습니다.
  • 전환: 사용자가 광고주 속성에서 취할 수 있는 광고주가 미리 정의한 액션입니다.
  • CPA: 전환당비용입니다. 구매자가 액션당 지불하는 금액입니다. 액션 또는 전환의 목표에는 가능한 한 많은 사용자를 확보하거나, 중요도가 높은 핵심 고객을 보유하거나, 타겟 사용자가 웹사이트에서 물건을 구매하도록 하는 등 여러 가지가 있을 수 있습니다. 액션을 통해 백서를 다운로드하거나, 뉴스레터에 가입하거나, 광고주 웹사이트에서 제품을 구매할 수 있습니다.
  • CPC: 클릭당비용입니다. 구매자가 광고 클릭당 지불하는 금액입니다.
  • CPM: 1,000회 노출당 비용입니다. 구매자가 1,000회 노출당 지불하는 금액입니다.
  • 광고 소재: 타겟 사용자에게 표시되는 광고입니다.
  • CTR: 클릭률입니다. 클릭수를 노출수로 나눈 값입니다.
  • CVR: 전환율입니다. 전환수를 노출수로 나눈 값입니다.
  • DMP: 데이터 관리 플랫폼(Data Management Platform)의 약어로서, 광고 기술 이용자에게 추가적인 사용자 정보를 제공합니다. Cloud Storage와 같은 객체 스토리지에 액세스 권한을 부여하면 이러한 플랫폼에서 데이터 덤프에 액세스 권한을 부여하거나 간혹 플랫폼에 데이터를 로드하는 경우가 있습니다.
  • 노출: 소스에서 광고를 가져왔을 때를 의미하며 청구 가능합니다.
  • 게시자: 이 시리즈의 내용에서 게시자는 웹사이트 또는 호스팅된 광고를 위해 광고 슬롯을 제공하는 모바일 앱과 같은 디지털 속성 집합을 가지고 있습니다.
  • (게시자의) 속성: 게시자가 광고 슬롯을 제공할 웹사이트, 앱 또는 게임입니다.
  • 공급업체: 여러 게시자를 대신하여 구매할 수 있는 광고 슬롯을 제공합니다.
  • 타겟 사용자: 광고의 타겟 즉, 광고를 볼 것으로 기대되는 사람입니다.
  • 분류: 잠재고객 속성의 분류를 말하며 일반적으로 계층 구조로 되어 있습니다.
  • (순) 사용자: 타겟팅이 가능하고, 고유한 사람임을 알 수 있거나 그렇게 간주되는 사용자입니다. 여러 사람이 같은 기기를 사용하거나 한 사람이 여러 기기를 사용하는 경우와 같은 요인으로 인해 순 사용자 판단은 쉽지 않으며 주로 최선의 추측으로 진행됩니다.

실시간 입찰 용어는 다음과 같습니다.

  • 광고 거래소: SSP에서 광고 요청을 받는 광고 마켓플레이스입니다. 요청을 받으면 SSP는 모든 DSP로부터 입찰이 첨부된 광고를 수신한 후 낙찰된 광고를 선택하고 판매자 측에 반환합니다. 이 거래는 신속하게 진행되어야 합니다. 예를 들어 Google은 구매자가 입찰을 반환하기까지 약 120ms를 기다립니다.
  • DSP: 수요측 플랫폼(Demand-side Platform)의 약어로서, 광고 요청을 수신하며 SSP 또는 광고 거래소에서 설정된 시간 내에 응답해야 합니다. 허용되는 시간은 최소 100ms에서 최대 몇 초 정도일 수 있습니다. DSP는 입찰 여부를 결정합니다. 입찰하면 광고를 선택하고 입찰가를 결정한 후 광고 거래소로 제안을 반환해야 합니다.
  • RTB: 실시간 입찰입니다. 온라인 입찰 메커니즘을 통해 프로그래매틱 구매자에게 광고 인벤토리(광고 슬롯)를 노출하는 프로세스입니다.
  • SSP: 판매측 플랫폼(Supply/sell-side Platform)의 약어로서, 광고 서버의 일부일 수도 있고 게시자 또는 광고 서버에서 광고 요청을 받는 독립형 도구일 수도 있습니다. SSP는 대개 광고 거래소에 광고 요청을 보내지만 가끔은 이 요청을 DSP로 직접 보냅니다. SSP는 광고 슬롯의 가치를 높이기 위해 인구통계와 같은 추가 잠재고객 환경을 통해 이 요청을 보완할 수 있습니다. SSP는 입찰에서 낙찰된 광고를 받아 게시자 또는 광고 서버로 반환합니다.

이 시리즈에서 특별히 사용되는 추가 용어는 다음과 같습니다.

  • 백엔드: 프런트엔드에서 데이터를 검색하거나 머신러닝 모델 학습 등의 처리를 오프로드하는 데 사용하는 서비스 또는 데이터베이스입니다.
  • 고객: 제공하는 플랫폼을 사용하는 플랫폼 사용자입니다.
  • 프런트엔드: 외부 요청을 처리하는 서비스입니다.
  • 기능: 플랫폼에서 실행되는 서비스가 제공하는 특정 기능입니다.
  • 오프라인: 실시간 의사결정 과정에 포함되지 않는 모든 프로세스를 말합니다.
  • 온라인: 실시간 프로세스의 일부로 실행해야 하는 모든 프로세스를 말합니다.
  • 플랫폼: 광고 게재, 인벤토리 제공, 입찰과 같은 주요 기능 중 하나를 제공하는 일련의 서비스입니다.
  • 플랫폼 사용자: 게시자, 판매자, 구매자, 광고주 또는 플랫폼 UI를 사용하는 다른 사용자입니다.
  • QPS: 초당 쿼리 수입니다.
  • 서비스: 세트로 제공되는 하나 이상의 기능으로, 일반적으로 단일 애플리케이션으로 제공됩니다.
  • 작업자: 작업을 수행하는 서비스의 인스턴스입니다. 일반적으로 동시에 실행되는 여러 작업자가 있습니다.

공유 구성요소

광고 서버, 수요측 플랫폼, 공급측 플랫폼(SSP), 광고 거래소와 같은 다양한 광고 플랫폼에는 다음과 유사하게 작동하는 몇 가지 기능 구성요소가 있습니다.

  • 플랫폼 사용자(공급업체, 구매자)가 프런트엔드 UI를 통해 플랫폼과 상호작용할 수 있도록 합니다.
  • 예를 들어, 광고 또는 입찰 요청을 처리합니다.
  • 노출수, 클릭수, 전환수, 잠재적인 낙찰 및 입찰 실패와 같은 이벤트 및 데이터 수명 주기를 관리합니다.

다음 다이어그램은 이러한 구성요소에 기반한 아키텍처를 보여줍니다.

광고 플랫폼의 공유 구성요소 아키텍처

사용자 프런트엔드

대부분의 광고 플랫폼에는 고객 프런트엔드가 필요합니다. 고객 프런트엔드는 일반적으로 하나 이상의 서로 다른 데이터베이스로 백업된 UI로 구성됩니다. 프런트엔드는 다음 요구사항을 충족해야 합니다.

  • 지연 시간을 두고 전 세계에서 액세스할 수 있는 최적의 사용자 환경을 제공해야 합니다.
  • 고객이 언제든지 환경설정을 관리할 수 있도록 가용성이 뛰어나야 합니다.
  • 요구사항에 따라 확장할 수 있어 고객이 재량에 따라 플랫폼 사용자의 시간대 및 글로벌 기반에 맞춰 언제든지 플랫폼을 사용할 수 있어야 합니다.

플랫폼에 따라 이러한 프런트엔드는 공급업체 또는 구매자가 사용할 수 있으며 광고 서버, DSP, SSP 또는 광고 거래소의 일부를 구성할 수 있습니다. 각 프런트엔드는 다양한 관리 기능을 제공하며 다양한 광고 리소스(광고 소재, 입찰, 요청, 인구통계 등)를 처리합니다.

이러한 개념에 대한 자세한 내용은 사용자 프런트엔드(1부)를 참조하세요.

요청 및 광고 선택

요청을 수신한 플랫폼은 광고 선택을 수행합니다. 요청은 일반적인 광고 게재 상황에서 광고 태그로부터 발생한 광고 요청일 수도 있고, RTB 상황에서 SSP 또는 광고 거래소로부터 들어오는 입찰 요청일 수도 있습니다.

광고를 선택하는 요소는 다음 사항을 충족해야 합니다.

  • 고도의 확장성: 광고 기술 요청은 하루에 수십억 건에 이르는 경우가 많습니다.
  • 뛰어난 가용성: 이러한 큰 규모를 감안할 때, 서비스가 1초만 중지되어도 요청 실패가 발생하여 비즈니스에 막대한 영향을 줄 수 있습니다.
  • 지연 시간 최소화: 타겟 사용자에게 광고를 최대한 빨리 표시해야 하므로 광고 선택 속도도 빨라야 합니다. SSP나 광고 거래소는 정해진 시간(짧은 경우 100ms) 이내에 입찰 응답을 반환할 것을 요구하므로 RTB에서 지연 시간은 핵심적인 요구사항입니다.

광고 선택 프로세스의 구성요소는 다음과 같습니다.

  • 광고 요청을 받는 프런트엔드 서비스
  • 프런트엔드가 결정을 내리는 데 사용하는 하나 또는 여러 개의 데이터 저장소
  • 광고를 선택하는 선택 알고리즘

요청 처리(1부)는 프런트엔드를 구현하는 방법을 보여주고, 대량 읽기 저장 패턴(1부)은 저장을 구현하는 방법을 보여줍니다. 광고 서버 및 RTB 입찰자에 대한 자세한 내용은 광고 서버입찰자(4부) 문서의 관련 섹션을 참조하세요.

DSP와 광고 서버 모두 광고 선택 로직을 활용하여 (순) 사용자를 프로파일링하고 관련이 없는 캠페인 및 광고를 필터링한 다음 광고를 선택합니다. 또한, 입찰자 선정 프로세스에는 입찰 여부 결정, 입찰 가격 결정 등이 있으며, 입찰가 최적화가 포함될 수 있습니다. 이 2가지에 대한 관련 링크는 광고 작업 부하를 처리하기 위한 인프라 옵션(1부)에서 확인할 수 있습니다.

이벤트 및 데이터 관리

광고 플랫폼에서 결정되는 대부분의 내용은 다음과 같은 다양한 소스의 데이터를 기반으로 합니다.

  • 광고 서버 프런트엔드에서 받은 광고 요청
  • DSP 프런트엔드에서 받은 입찰 요청
  • DSP 낙찰 엔드포인트에서 받은 낙찰 및 입찰 실패
  • 타겟 사용자에게 광고가 게재된 후에 생성된 노출 이벤트. 대부분의 경우 노출수는 청구 가능한 노출수입니다. 청구 가능한 노출수는 조회 가능으로 표시되고 간주됩니다.
  • 타겟 사용자가 광고를 클릭할 때 생성되는 클릭 이벤트. 이벤트 수는 노출수보다 몇 자릿수가 낮을 수 있습니다.
  • 타겟 사용자가 광고주의 지면에서 희망하는 액션을 수행할 때 생성되는 전환 이벤트. 이벤트 수는 광고 클릭 수보다 낮을 수 있습니다.
  • 플랫폼 사용자가 관리하는 반정적 데이터
  • 기록 이벤트 분석을 통한 오프라인 데이터
  • DMP 등의 외부 소스에서 제공하는 사용자 세그먼트 및 관련 가격과 같은 타사 데이터

머신러닝은 규칙에 기반한 시스템과는 달리, 이전의 데이터를 사용하여 오프라인으로 모델을 학습시키고, 실시간 데이터를 활용하여 모델을 온라인으로 학습시킬 수 있는 중요한 요소입니다. 그런 다음 이러한 모델을 로컬로 배포하여 광고 서버와 같은 개별 구성요소 또는 서비스가 온라인 예측을 할 수 있게 합니다. 이 모델을 사용하여 미리 설정된 예측을 제공하는 캐시 또는 키-값 저장소를 채울 수도 있습니다.

플랫폼은 다음을 수행할 수 있어야 합니다.

  • 테라바이트 단위의 일일 데이터를 수집하여 내부 데이터화하고 처리하여 저장합니다.
  • 수집, 내부 데이터화, 처리, 저장 시 매일 수십억 개의 이벤트로 확장합니다.
  • 실시간 온라인 및 오프라인 처리를 위한 옵션을 제공합니다.
  • 분산 환경에서 머신러닝과 같은 처리 작업을 실행합니다.
  • 스트리밍을 통해 실시간으로 또는 나중에 일괄로 관련 데이터를 인텔리전스 데이터베이스에 자동으로 다시 피드합니다.

입찰 요청, 입찰 결과, 노출수, 클릭수에서 조인을 처리하는 방법에 대한 자세한 설명은 이벤트 처리(3부)를 참조하세요.

광고 서버

광고 서버는 일반적으로 다음 다이어그램과 같이 공유 구성요소와 광고 게재 기능으로 구성됩니다.

광고 게재를 포함한 광고 플랫폼 아키텍처

광고 서버의 핵심인 광고 게재에는 다음이 필요합니다.

  • 짧은 지연 시간: 타겟 사용자가 광고를 볼 수 있고 (스크롤이 허용되는 경우) 광고 조회 환경이 악화되지 않도록 광고를 신속하게 게재해야 합니다.
  • 고가용성: 광고를 선택한 후 플랫폼 다운으로 인해 광고를 게재하지 못하면 낭비일 뿐 아니라 비용이 많이 듭니다.
  • 확장성: 하루에 수십억 개의 광고 요청으로 인해 많은 플랫폼에서 수십억 개의 관련 광고를 게재해야 합니다.

일부 DSP 또는 SSP가 인프라에서 광고를 게재하더라도 이 문서에서는 플랫폼의 일부로 광고 서버를 구현했다고 가정합니다. 광고 게재에 대한 자세한 내용은 선택된 광고를 타겟 사용자에게 게재(3부)를 참조하세요.

입찰자

입찰 프로세스는 RTB 입찰자를 위한 인프라 옵션(4부)에서 자세히 설명합니다.

DSP는 일반적으로 다음 요구사항을 가진 공유 구성요소로 구성됩니다.

  • 입찰 응답은 정의된 기한 내에 이루어져야 지연 시간이 중요하게 설정됩니다.
  • 입찰 요청 당 입찰가가 계산되므로, 광고 선택 로직이 복잡해집니다. 알고리즘의 추가 로직은 일반적으로 추가 입찰자 서비스에 의해 처리됩니다. 자세한 내용은 입찰(4부)을 참조하세요.

다음 다이어그램은 수요측 플랫폼의 대략적인 개요를 보여줍니다.

수요측 플랫폼의 대략적인 개요

다음 단계