15강까지 다룬 파이프라인·Identity Resolution이 "데이터를 어떻게 모아 하나로 합칠 것인가"의 문제였다면, 이번 강은 "합쳐진 데이터를 CDP 안에서 어떤 구조로 저장하고 꺼내 쓸 것인가"의 문제다. 대부분의 CDP는 이 구조를 프로필(Profile), 이벤트(Event), 세그먼트(Segment) 세 축으로 나눠 설계한다. 프로필은 "이 사람이 누구인가"에 대한 고정적·누적적 정보를, 이벤트는 "이 사람이 언제 무엇을 했는가"에 대한 시계열 기록을, 세그먼트는 이 둘을 조합해 "이 조건을 만족하는 사람들의 집합"을 정의한다. 세 축을 명확히 구분하지 못하고 설계하면, 나중에 특정 조건의 세그먼트 하나를 만들 때마다 어느 테이블에서 무엇을 가져와야 할지 매번 헷갈리는 구조가 된다.
프로필은 15강에서 다룬 Identity Resolution의 최종 산출물이다: 여러 시스템의 식별자가 매칭돼 하나로 합쳐진 결과가 프로필 레코드로 저장된다. Salesforce Data Cloud는 이 결과를 Unified Individual, Unified Individual Contact Email/Phone/Address 같은 통합 객체로 생성한다. 프로필에 담기는 정보는 대체로 상대적으로 변하지 않거나 누적되는 값이다: 회원가입일, 거주지역, 회원등급, 누적 구매액, 마지막 로그인 시각 같은 값들이다. 프로필은 한 사람당 하나의 최신 상태를 유지하는 것이 원칙이며, 매번 새 레코드를 쌓는 것이 아니라 값이 바뀔 때마다 갱신(update)되는 구조로 설계한다.
이벤트는 프로필과 달리 시간 순서대로 계속 쌓이는 로그다. 장바구니 담기, 페이지 조회, 앱 실행, 결제완료 같은 개별 행동이 발생 시각과 함께 기록된다. 15강에서 다룬 대로 이 데이터는 클라이언트 SDK(행동 데이터)나 서버사이드 API·웹훅(거래 이벤트)으로 CDP에 들어온다. 이벤트 데이터의 설계에서 중요한 것은 이벤트 이름과 속성(property)을 미리 표준화해두는 것이다: 같은 "구매완료"라는 행동을 어떤 팀은 purchase_complete, 어떤 팀은 order_done으로 서로 다르게 이름 붙이면, 나중에 세그먼트 조건을 만들 때 어느 이벤트명을 써야 할지 혼선이 생긴다.
정적 리스트는 특정 시점에 조건을 만족한 유저를 한 번 뽑아 고정한 명단으로, 다음 날 조건을 새로 만족하는 유저가 생겨도 자동으로 추가되지 않는다. 반면 다이나믹 세그먼트(Dynamic Segmentation)는 조건 자체를 저장해두고, 유저의 상태가 바뀔 때마다 그 조건을 다시 평가해 진입·이탈을 자동으로 갱신하는 방식이다. 세그먼트 조건은 크게 세 종류로 나뉜다. 행동 조건은 이벤트 테이블에서 특정 이벤트가 정해진 기간 안에 몇 번 발생했는지(빈도)와 마지막 발생이 언제인지(최근성)를 쓴다. 거래·상태 조건은 이벤트에 딸린 금액 같은 숫자 임계값을 쓴다. 속성 조건은 프로필 테이블에 저장된 거주지역, 회원등급처럼 비교적 고정적인 정보를 쓴다. 실무에서 쓰는 대부분의 정밀 세그먼트는 이 세 유형을 AND로 묶어 만들어진다: "최근 3일 내 앱 방문 3회 이상(행동, 이벤트 테이블)이면서 장바구니에 5만 원 이상 담은(거래, 이벤트 테이블) 서울 거주(속성, 프로필 테이블) 유저"가 대표적인 예다.
아무리 룰셋을 정교하게 설계해도, 그 조건에 쓰이는 이벤트나 속성이 CDP에 실제로 들어와 있지 않으면 세그먼트는 항상 0명이거나 잘못된 인원으로 나온다. "장바구니 5만 원 이상"이라는 조건을 쓰려면 장바구니 담기 이벤트가 상품 금액 정보와 함께 실시간으로 CDP에 전송되고 있어야 하고, "서울 거주"라는 조건을 쓰려면 회원 정보의 거주지역 필드가 CDP의 프로필과 매핑돼 있어야 한다. 이 부분이 15강에서 다룬 데이터 파이프라인 설계와 직접 연결되는 지점이다: 데이터 모델을 설계할 때, 각 필드가 프로필에 들어갈지 이벤트에 들어갈지를 정하는 동시에 그 데이터가 실제로 파이프라인을 통해 들어오고 있는지 함께 확인해야 시행착오를 줄일 수 있다.
"다이나믹"이라는 이름과 달리, 모든 조건이 완전히 실시간으로 갱신되는 것은 아니다. 실시간 이벤트 기반 조건은 초 단위로 갱신되지만, 배치로 연동되는 CRM 속성(프로필 테이블의 일부 필드)은 하루에 한 번만 갱신될 수 있다. 데이터 모델을 설계할 때 각 필드 옆에 갱신 주기(실시간/배치, 배치라면 몇 시간 주기인지)를 함께 기록해두면, 이후 세그먼트나 저니를 만들 때 이 조건이 실제로 실시간 반응하는지 하루 지난 데이터를 기준으로 도는지 헷갈리지 않는다.
정밀 타겟팅을 목표로 조건을 계속 AND로 추가하다 보면 세그먼트 인원이 급격히 줄어드는 함정에 빠지기 쉽다. 조건 세 개를 AND로 묶으면 전체 유저 기반에서 이 조건을 모두 만족하는 사람은 소수로 좁혀지고, 캠페인 하나를 돌려도 통계적으로 의미 있는 결과를 보기 어려운 규모가 될 수 있다. 세그먼트를 설계할 때는 예상 인원을 미리 추정해보고, 인원이 지나치게 적다면 조건 하나를 완화하거나(최근성을 3일에서 7일로), OR 조건으로 유사한 행동을 묶어 규모를 확보하는 절충이 필요하다. 정밀도와 규모는 항상 트레이드오프 관계에 있다는 것을 데이터 모델 설계 단계에서부터 염두에 둬야 한다.
[CDP 데이터모델 초안]
1. 프로필(Profile) 필드 정의
| 필드명 | 데이터 종류 | 소스 시스템 | 갱신 주기 |
|---|---|---|---|
| user_id | 식별자 | 회원 시스템 | 실시간(가입 시) |
| 거주지역 | 속성 | 회원 시스템 | 배치(일 1회) |
| 회원등급 | 속성 | CRM | 배치 |
| 누적구매액 | 누적값 | 주문 시스템 | (실시간/배치 결정 필요) |
2. 이벤트(Event) 정의
| 이벤트명(표준화) | 발생 시점 | 주요 속성(property) | 소스·수집 방식 |
|---|---|---|---|
| view_product | 상품 조회 | 상품ID, 가격 | 웹/앱 SDK |
| add_to_cart | 장바구니 담기 | 상품ID, 금액 | 웹/앱 SDK |
| purchase_complete | 결제완료 | 주문ID, 총액 | 서버 API/웹훅 |
3. 세그먼트(Segment) 설계 예시
| 세그먼트명 | 행동 조건 | 거래 조건 | 속성 조건 | 예상 인원(추정) |
|---|---|---|---|---|
| (예: 서울 고관여 이탈) | 최근 3일 앱 방문 3회 이상 | 장바구니 5만원 이상 | 서울 거주 | |
4. 확인 사항
□ 이벤트명이 팀 간 표준화돼 있는가(같은 행동에 다른 이름 쓰지 않는가)
□ 세그먼트 조건에 쓰인 필드가 실제로 파이프라인을 통해 CDP에 들어오는가
□ 각 필드의 갱신 주기(실시간/배치)를 표에 기록했는가
17강. 서버사이드 태깅과 CDP의 관계: A03의 GTM을 인프라 관점으로 재조명에서 서버사이드 태깅을 다룹니다.