지난 번 cookie 글에서 cookie의 정의나 발급 방식 등에 대해 살펴봤는데, 오늘은 이 중 3rd party cookie를 적극적으로 사용하는 DMP에 대해서 좀 자세하게 알아보려고 한다. 상대적으로 최근 트렌드에 불리한 플랫폼 맞고 - 최근 참관했던 컨퍼런스에는 "네 저희도 DMP에서 가져온 데이터 쓰레기인 거 아는데 (전체적인 트렌드 관점에서는 맞다) "를 육성으로 들었다. 관계자들 많을텐데 대단하세요 - , CDP 쪽 논의가 최근에는 대세인 것으로 아는데, DMP 내용이 너무 길어져서 CDP는 좀 잘라서 가려고.
DMP
세상 모든 약어에 대해 불만이 좀 있는 편인데 DMP는 그 중 심각하다. 적어도 무슨 데이터인지, 데이터를 매니지하는 목적인지 아니면 적어도 그 둘 중 하나라도 좀 포함해보는 게 어때?????
3rd party cookie를 포함한 각종 쿠키의 key와 value, IDFA 같은 mobile identifier 기준으로 수집된 데이터를 수집하고 분석하는 일종의 data warehouse 이다. 수많은 웹사이트들로부터 받은 데이터셋을 구조화하고, 분석을 거쳐 이용자를 세그먼트화하거나 특정할 수 있도록 한다. 글로벌에서는 오라클 DMP(구 BlueKai), Salesforce의 Krux, Adobe의 Audience Manager 등이 있고 이 외에도 너무 많은 업체들이 존재하고 있다. 한국에서는 NHN ADLIB이나 와이더플래닛의 Molecule 등이 있다.
DMP의 구조
DMP의 역할인 데이터 수집 / 저장 / 분석 / 세그먼트화 / 수익화를 한 눈에 들어오게 한 좋은 그림이 있어서 가져와봤다. 데이터가 들어오면 정규화하고 머징해 데이터 스토리지에 넣고, 이 스토리지는 DSP나 SSP에 S2S로 납품하거나 고객 대상의 서비스 프론트/리포트에 쏴주는 것. CDP(Customer Data Platform)도 대충 이와 유사한 구조/흐름을 가지고 있다고 한다.
데이터 수집
픽셀과 태그
1st party data를 제공받는 가장 보편적인 방법인데, 웹사이트에 1x1 사이즈의 투명한 픽셀 (html 코드)을 추가한다. 이 코드가 하는 일은 DMP를 호출해 DMP가 유저의 브라우저에 심을 쿠키를 제공하도록 하는 건데, 이 이후로는 쿠키가 DMP와의 정보 교류에 계속해 사용된다 (쿠키의 만료일자까지는).
추가로, Piggybacking 이라는 방법이 있다. 여러 개의 픽셀을 설치하는 게 아니라, 단일한 픽셀이 여러 개의 트래킹 픽셀을 호출하도록 하는 방식이다.
물론 픽셀이나 배너를 통해 3rd party cookie를 심을 수도 있고, 이 경우에는 여러 사이트에 걸쳐 cross-site 트래킹이 가능하다. DMP는 기본적으로 도움이 되는 식별자든 속성이든 있다면 일단 다 쓸어담고, 나중에 매핑하고 정규화하겠다는 기조.
태그
픽셀과 유사하게 웹사이트 - DMP를 거쳐 클라 브라우저에 쿠키가 심어지는 것인데 JavaScript나 iframe으로 구성된다. 태그 매니저의 장점은 html을 수시로 건드리거나 그때그때 코드를 수정해야 할 필요 없이, <body>에 한 번 스크립트를 삽입하고 나머지는 편하게 태그매니저 상 UI에서 태그 단위로 수정할 수 있다는 점이다. Google의 Tag Manager가 하는 역할이 "개발자 도움 없이 마케터가 알아서" 였는데, 바로 이 점 때문인듯.
API
귀찮게 언제 코드 넣고 있냐. 그냥 Server to Server 로 주고받자. 라는 방법도 가능하다.
PII (personally identifiable information)
기업이 자체적으로 가지고 있는 crm 데이터를 전달하기도 하는데, 이때는 해싱이나 암호화, generalization 등을 통해 데이터를 익명화하거나 뭉개서 전달한다.
식별자
ADID (Apple의 IDFA나 구글의 GAID 등), 심지어는 Connected TV 식별자 (삼성의 TIFA, Roku의 RIDA) 까지 가져간다. 독한놈들...
데이터 정규화 / 정제
이렇게 받은 정보들은 당연히 그 구조가 각자 다르고 엉망진창일 것이므로, 식별자를 정돈하고 Primary Key로 통일하거나, 정보의 중복을 제거하고 DMP의 공통 schema로 정리하고 하는 과정이 필요하다. 분석에 앞서 당연히 필요한 정제 과정.
프로파일 생성 및 머징
ADID(애플의 IDFA나 구글의 GAID 같은), cookie id, 디바이스 정보를 활용해 이를 key로 프로파일을 새로 생성하거나, 새로운 정보가 들어왔을 때 이것이 기존 프로필과 겹칠 경우 이들을 동일한 프로파일로 합치는 과정이다.
머징할 때는 ID를 key로 사용하거나, 타임스탬프나 알파벳순을 사용하거나, 아니면 충분한 정보가 쌓일때까지 프로파일 생성을 유보하거나 하는 방법이 사용된다. 이를테면, 아래 이미지의 이벤트 세 개는 독립적인 이벤트이지만 Ben이라는 한 사람의 프로파일이라는 걸 알게 되는 건 Event #3이 인입되는 시점이다. (온전한 정보가 수집된 Event#3이 있을때 Event#1은 같은 firefox에서 생성된 쿠키id로, Event #2는 브라우저가 달라서 쿠키id가 다르지만 Email로 엮을 수 있다.)
DMP가 정보를 분류하는 방법
Data Taxonomy (분류)
유사한 데이터의 분류를 정의하거나 합치거나 과정이 필요하다. segment를 폴더처럼 관리하는 것이라고 생각하면 편하다.
- Organize data into groups based on their similarities and relationships between one another.
- Create a hierarchy of all your data.
- Make it easy to search for and use individual entries and groups (e.g. for data segmentation).
Audience Segmentation
이 고객은 어느 세그먼트에 포함돼, 라는 것을 정의한다. Taxonomy에서 정의한 행동(클릭, Page view, 최종결제안함/함), 인구통계정보(성/연령/가구소득), 관심사(테 크 조 아) 같은 것들에 고객을 집어넣는다. 고도화된 DMP일수록 and/or 조건들도 제공하는데, 구글 등 광고를 셀링하는 쪽에서 일관적으로 내보내는 얘기는 "모든 고객들을 식별할 수는 없어. 조건을 너무 많이 걸지 마. 너네가 알 수 없는 고객들도 소중해"이다. 돈 벌려고 하는 이야기.
DMP가 타게팅을 돕는 방법
일반적으로 DMP는 DSP나 SSP 모두와 상호작용한다. DMP는 유저 정보를 수취한 후 이 데이터를 분석한 뒤 taxanomy file과 audience data file을 csv 등의 파일 포맷으로 전달한다. 통신 정의에 따라 다르겠지만 FTP나 클라우드 등을 통해 증분/전체 데이터 전달한다.
taxonomy 파일 예시
| segment ID | segment name | price |
| 123 | travel-enthusiasts | $2.50 |
| 456 | HH Income > $100k | $1.50 |
| 789 | My First-Party Segment |
audience file 예시
각 유저 id가 어떤 seg에 속하는지를 알려준다.
| identifier | segment id |
| 30255BCE-4CDA-4F62-91DC-4758FDFF8512 | 123, 456 |
| 84625BCE-7HDA-4F62-61DF-9254FDFF8512 | 123 |
| 92545BCE-9PSA-4F62-73DC-8462FDFF8512 | 456, 789 |
미디어 구매가 이루어질 때는 cookie syncing 이라는 과정을 통해 SSP, DSP, DMP 간 "얘가 걔야" 라는 합의를 본다.
Look-Alike 모델링
사전 정의된 segment 뿐 아니라 "나는 이 유저 타겟하고 싶은데, 얘랑 비슷한 애들 뽑아줘" 라는 방식으로 DMP를 활용하는 것도 가능하다. 몇 가지 기준을 정의하면 유사한 이용자군을 뽑아낼 수도 있다. DMP에 따라 look-alike 모델링을 서비스로 제공하는 곳도, 별도 과금하는 곳도 있다.
DMP vs CDP 맛보기
CDP에 대해서는 다음 글에서 쓸 거고, CRM과의 비교도 같이 있으면 좋겠는데, 마케팅 업계 특유의 개같은 화술 (speaking marketese like a dick) 상 "야 그래도 CRM CDP DMP 모두 다 친구고 소중해" 라는 결론이기 때문에... 일단은 대략적인 비교표만 두고 CDP에 대해서는 다음 글에서 논해보도록 한다.
| DMP | CDP | |
| full name | Data Management Platform | Customer Data Platform |
| 목적 | 데이터분석+미디어수익화 디지털 광고 |
전반적인 마케팅 지원 |
| 사용하는 데이터 | 주로 온라인의 - 1st~3rd party data - mobile identifier (안드로이드 AAID, 애플 IDFA 등) |
온.오프라인의 - 1st party data |
| cookie 기반 임시 데이터 (약 90일) |
고객정보 (CRM 등으로 관리하는) 반영구적 데이터 |
|
| 익명의 id | PII (Personally Identifiable Information) |
참고
https://adtechexplained.com/dmp-explained/
https://adtechbook.clearcode.cc/dmp-and-data-usage/
https://blogs.oracle.com/marketingcloud/post/cdp-vs-crm-vs-dmp
https://www.youtube.com/watch?v=PJsyHSBOuH8
'Adtech' 카테고리의 다른 글
| MRAID와 VAST (2) | 2024.12.25 |
|---|---|
| RTB real-time bidding의 간략한 역사 (3) | 2024.12.22 |
| SKAdNetwork (SKAN)의 정의 (1) | 2022.06.25 |
| Moloco 몰로코 (0) | 2022.04.23 |
| What is adtech and why is it important? (Amazon Ads 번역: 애드테크란 무엇이고 왜 중요한가요?) (1) | 2022.04.03 |
