Ad Tech DMP(Data Management Platform) 톺아보기
안녕하세요. 배민혁 입니다.
2022년 광고서버를 개발하기로 결정되었습니다. 광고서버의 아키텍처를 아시는 분도, 모르시는 분도 계시겠지만, 상당히 많은 요구사항이 있고 복잡합니다. 오늘은 그 중에서 데이터 관리 플랫폼(DMP: Data Management Platform)을 살펴보도록 하겠습니다. 해당 내용은 구글에서 제공하는 광고서버 레퍼런스 아키텍처를 참고하였습니다.
0 AD TECH Overview
애드테크는 AD(Advertising, 광고)와 Tech(Technology, 기술)이란 단어가 합쳐진 형태로, IT 기술이 적용된 광고기술을 의미합니다.
0.1 광고 도메인에서 사용되는 주요 단어
- 인벤토리, 광고 지면, 광고 스페이스: 인벤토리는 퍼블리셔가 판매할 수 있는 광고 지면을 뜻함. 이때 노출(CPM), 클릭(CPC), 전환(CPA) 등 여러 방식으로 판매 가능
- 광고주: ‘광고 지면’을 필요로 하는 사람, Demand / Advertiser / Buyer
- 퍼블리셔: ‘광고 지면’을 제공하는 사람, 매체 / Supply / Publisher / Seller
- 광고 슬롯: 광고 스페이스가 호스팅되는 곳이 광고 슬롯
- 크리에이티브: 사용자에게 노출되는 실제 광고를 포함하는 파일
- impression: 광고가 사용자(예를 들어 웹의 사용자)에게 보여지는 것. 소재가 노출될 때마다 계산됨. 새로고침하고 똑같은 광고를 보더라도 새로운 노출로 계산됨
0.2 애드테크의 등장 배경
산업의 변화에 따라 전통적으로 광고 시장도 변하기 시작했습니다. 이에 따라 많은 매체가 생겨났고, 광고주는 많은 매체 중에서 적합한 매체를 원하게 되었습니다. 많은 매체를 제공하는 퍼블리셔 또한 광고 관리의 어려움을 겪에 되었습니다. 이러한 문제를 해결하기 위해서 애드 서버, 애드 네트워크 등이 포함된 애드 테크가 등장하게 되었습니다.
0.3 AD SERVER(애드 서버)의 역할
오늘 주로 이야기 할 애드 서버는 광고 지면에 어떤 광고를 노출할 것인지 결정하는 과정을 담당합니다. 데이터에 기반한 최신 기술을 입히면 타게팅이 가능합니다.
조금더 풀어서 이야기하면, 퍼블리셔 입장에서 누구에게 광고를 노출할 것인지, 광고주 입장에서 어떤 소재를 인벤토리에 전달할지 정하는데 사용됩니다.
1 플랫폼의 공통 구성요소
애드서버에는 광고주를 위한 플랫폼(DSP, Demand Side Platform), 퍼블리셔를 위한 플랫폼(Supply Side Platform)이 존재합니다. 주체는 다르지만 공통 구성요소가 있습니다. 모든 시스템은 User frontend UI를 통해서 다루는 것이 가능합니다.
2 요청 및 광고 선택 데이터 요구사항
광고를 요청하고 선택하는 프로세스는 주로 OLTP의 데이터 관리 형식에 해당합니다. 왜냐하면, 광고를 선택하는 프로세스에서 사용자 프로필, 메타데이터, 컨텍스트 데이터를 참고하기 때문입니다.
2.1 OLTP(Online Transaction Processing)
[정의]
- 컴퓨터 시스템을 사용 하는 트랜잭션 데이터의 관리
- 모든 트랜잭션 및 레코드를 저장하는 데 사용
[목적]
- 조직의 일상적인 작업에서 발생하는 비즈니스 상호 작용을 기록하고, 이 데이터를 쿼리하여 유추할 수 있도록 지원
- 관리 데이터 저장소
- 메타데이터 저장소
[관심사]
- 효율적인 처리
[기타]
- 분석용으로 디자인 되지 않음
- 조직에 귀중한 정보를 포함
- 대량의 데이터에 대한 집계를 처리하는데 항상 적절한 것은 아님
2.2 사용자 프로파일 저장소
2.3 메타데이터 관리 저장소
2.3 컨텍스트 저장소
3 이벤트 및 데이터 관리 데이터 요구사항
광고주는 광고 소재가 어떤 매체에서 원하는 대로 노출이 되었는지 궁금해합니다. 또한 퍼블리셔 또한 광고 소재가 광고주의 요구사항대로 잘 노출이 되었는지 궁금합니다. 이런 데이터를 분석하여 대시보드 형태로 제공할 수 있어야합니다.
3.1 OLAP(Online Analytical Processing
[정의]
- 대규모 비즈니스 데이터베이스를 구성하고 복잡한 분석을 지원하는 기술
- OLTP와 같은 트랜잭션 시스템에 부정적인 영향을 주지 않고 복잡한 분석 쿼리를 수행하는 데 사용
[목적]
- 보고/대시보드 저장소
[관심사]
- 의사결정에 도움되는 데이터 분석
[기타]
- 과도한 읽기, 낮은 쓰기 워크로드에 최적화 되어 있음
- 방대한 양의 데이터에 대한 집계 계산
- 변경에 의한 즉각적인 대응보다는, 전략적 비즈니스 의자 결정에 더 적합함
3.2 분석 저장소
3.3 보고/대시보드 저장소
4 애드 서버 데이터 파이프라인
4.1 애드 서버에서 발생하는 이벤트의 종류
- 광고 및 입찰 요청: 일반적으로 외부 시스템으로부터 받습니다. 요청에는 광고 선택을 위한 입력의 일부인 세부정보가 포함됩니다.
- 노출: 웹페이지에 로드되지만 보이지 않을 수도 있는 광고 소재
- 클릭: 사용자가 광고 소재를 클릭함으로써 취할 수 있는 동작
- 전환: 타겟팅된 사용자가 광고주 웹사이트에서 수행하는 동작
4.2 데이터 파이프라인의 세분화
- 수집 및 저장(내부 데이터화): 스토리지 시스템으로의 반복적인 파일 업로드 또는 메시징 시스템
- 처리: 일괄 또는 스트리밍(데이터를 최신 상태로 유지하는 것이 중요한 경우 실시간 처리로 수행)
- 내보내기(또는 로드): 데이터 처리 도구에서 또는 커스텀 워크플로를 통해 수행
4.2.1 이벤트 수집 방식
- 메시징 시스템에 이벤트를 게시하거나 로컬 로그 파일에 쓰는 커스텀 코드
- 클라우드 서비스 또는 웹 서버의 기본 로깅 기능
4.2.2 이벤트 로깅 방식
- 임시 분석: 읽기와 쓰기 성능이 좋은 스토리지
- 알림 및 실시간 처리: 메시징 시스템에 의한 스트리밍 처리
- 백업 및 통합 분석: object 스토리지
4.2.3 이벤트 처리시 고려사항
- 지연: 어느 데이터를 실시간으로 처리해야하는지를 결정해야함. 예를 들어 예산 카운터를 최대한 빠르게 계산해야 할 수 있음. 즉각 처리가 필요
- 정확성: 일부 값은 반드시 즉각 계산할 필요는 없더라도 정확한 계산이 필요. 예를들어 청구 금액에 대한 계산.
- 고가용성: 매일 수십억 회의 데이터 입력이 수행되는 상황에서 몇 분의 다운타임은 심각한 재무적 영향으로 이어질 수 있음
- 운영 오버헤드: 기술 리소스를 ‘단순 유지 업무’에 투입하는 것은 리소스를 사용하는 최선의 방법이 아닐 수 있음.
[이벤트 처리 예시]
- 노출수: 매 시간 집계가 필요
- 캠페인 빈도: 매일 한도가 적용됨
4.2.4 내보내기
- 처리 결과 내보내기
- 데이터 기반으로 알림보내기
[내보내기 예시]
- 캠페인 결과를 주기적으로 발송하기
- 예산 고갈에 대한 알림
