CDP 도입 실무에서 가장 먼저 해야 할 일은 벤더를 고르는 게 아니라, 우리 조직의 데이터가 소스 시스템에서 CDP까지 어떤 경로로 흐를지 그려보는 것이다. Salesforce Data Cloud 공식 문서는 이 흐름을 세 단계로 정리한다: 먼저 Data Streams가 CRM·마케팅 플랫폼·데이터 레이크 등 소스 시스템의 데이터를 Data Lake Objects(DLO)라는 원시 데이터 영역으로 수집하고, 이어서 Data Transforms가 이 원시 데이터를 정제·정규화하며, 마지막으로 Identity Resolution이 정제된 데이터에 매칭 규칙을 적용해 통합 프로필을 만든다. 이 3단계 구조는 Salesforce만의 특수한 방식이 아니라 대부분의 CDP가 공통으로 따르는 일반 원리이므로, 다른 벤더를 쓰더라도 이 순서로 설계를 시작하는 게 안전하다.
수집 방식은 데이터의 성격에 따라 갈린다. 웹사이트·앱에서 발생하는 클릭·스크롤·화면 진입 같은 행동 데이터는 대개 클라이언트 SDK(자바스크립트 SDK, 모바일 SDK)를 페이지·앱에 심어 실시간으로 전송한다. 반면 결제 완료, 배송 상태 변경처럼 서버(백엔드)에서 발생하는 이벤트는 서버사이드 API 호출이나 웹훅(Webhook)으로 보내는 것이 일반적이다. 웹훅은 특정 이벤트가 발생했을 때 외부 시스템(CDP)의 지정된 엔드포인트로 자동 HTTP 요청을 보내는 방식으로, 결제 시스템·CRM처럼 CDP가 직접 폴링(polling)하기 어려운 외부 시스템의 이벤트를 실시간에 가깝게 전달하는 데 쓴다. CRM 데이터나 과거 거래 이력처럼 실시간성이 필요 없는 대량 데이터는 배치 커넥터(Data Streams류)로 정기 동기화하는 것이 일반적이다.
Identity Resolution(신원 해석)은 서로 다른 기기·채널·세션에서 발생한 파편화된 데이터를 하나의 정확한 고객 프로필로 연결하는 과정이다. 매칭 방식은 두 갈래로 나뉜다: 이메일·전화번호처럼 정확히 일치하는 식별자를 기준으로 연결하는 결정론적(deterministic) 매칭과, 정확한 식별자가 없을 때 행동 패턴(같은 기기·유사한 접속 시간대 등)을 근거로 같은 사람일 가능성을 추론하는 확률론적(probabilistic) 매칭이다. 결정론적 매칭은 정확도가 높지만 공통 식별자가 없으면 아예 매칭이 안 되고, 확률론적 매칭은 공통 식별자가 없어도 연결을 시도할 수 있지만 오탐(다른 사람을 같은 사람으로 잘못 판단) 위험이 있다.
파이프라인을 설계할 때 가장 자주 간과되는 부분이 식별자(identifier) 표준화다. 14강에서 만든 소스맵에서 봤듯, 웹은 쿠키 기반 익명 ID, 앱은 기기 ID, 회원 시스템은 회원번호, POS는 멤버십 카드번호를 쓰는 식으로 시스템마다 식별자 체계가 다르면, 아무리 데이터를 잘 모아도 이후 Identity Resolution 단계에서 같은 사람인지 판단할 공통 기준이 없어 정확도가 떨어진다. 따라서 파이프라인 설계 단계에서부터 "이메일은 소문자로 정규화한다", "전화번호는 국가 코드를 포함한 E.164 형식으로 통일한다" 같은 규칙을 미리 정해 각 시스템의 전송 스펙에 반영해두는 것이, 나중에 정제 단계에서 다시 손보는 것보다 훨씬 적은 비용으로 끝난다.
비회원 상태로 사이트를 둘러보는 방문자는 쿠키나 로컬 저장소 기반의 anonymous ID로 추적되고, 이 ID로 조회 이력·장바구니 담기 같은 행동이 CDP에 쌓인다. 이후 이 방문자가 실제로 로그인하면, 그 순간 시스템은 로그인 이벤트와 함께 "이 세션의 anonymous ID는 user_id XXX와 같은 사람이다"라는 매핑 신호를 CDP로 보낸다. 이 신호를 받은 CDP는 로그인 이전의 anonymous ID 행동 기록 전체를 user_id 프로필로 병합해, 로그인 전후의 행동이 끊기지 않고 하나의 고객 여정으로 이어지게 만든다. 이 병합은 유저 본인이 로그인이라는 명시적 행위로 자신의 신원을 확인해준 시점에 이뤄지므로, 결정론적 매칭 중에서도 가장 신뢰도가 높은 케이스로 취급된다.
Salesforce Data Cloud 공식 문서는 이 매칭·정합 과정을 룰셋(ruleset)이라는 개념으로 관리한다. 룰셋은 서로 다른 소스의 레코드가 동일 고객을 가리키는지 판단하는 매칭 규칙의 모음으로, 조직이 "어떤 필드를 어떤 우선순위로 비교할지"를 직접 설계할 수 있다. 이 설계에서 가장 조심해야 할 부분은 매칭 기준을 지나치게 느슨하게 잡는 경우다. 이름과 생년월일만으로 매칭하도록 설계하면, 동명이인이 다른 사람의 구매 이력·개인정보와 한 프로필로 잘못 병합될 위험이 있다: 이는 관련 공식 커리큘럼에서도 공통으로 지적하는 위험이다. 반대로 매칭 기준을 지나치게 엄격하게 잡으면(이메일·전화번호가 완전히 일치해야만 매칭), 실제로는 같은 사람인데도 매칭에 실패해 단일 고객 뷰가 조각난 채로 남는 문제가 생긴다.
CDP 벤더 대부분은 웹·iOS·안드로이드용 SDK와 서버사이드 API를 기본 제공하지만, 실제 설치·검증은 개발팀 리소스가 필요한 작업이다. 실무에서는 우선순위를 정해 단계적으로 진행하는 것이 현실적이다: 먼저 핵심 전환 이벤트(회원가입, 구매) 몇 개만 SDK로 심어 데이터가 실제로 CDP에 들어오는지 검증하고, 이후 세부 행동 이벤트(장바구니 담기, 특정 페이지 조회)를 추가하는 순서다. 처음부터 모든 이벤트를 한 번에 설계·구현하려 하면 개발 일정이 지연되고, 정작 마케팅팀이 당장 필요한 핵심 세그먼트조차 만들 데이터가 없는 상태로 오래 머물게 된다.
[식별자 매칭 우선순위 설계안]
1. 시스템별 식별자 현황(14강 소스맵 재사용)
| 시스템 | 식별자 종류 | 정규화 규칙(예: 이메일 소문자, 전화번호 E.164) |
|---|---|---|
| 웹 | 쿠키 ID | |
| 앱 | 기기 ID | |
| 회원 시스템 | 이메일 | |
| POS | 멤버십 카드번호 | |
2. 매칭 우선순위(신뢰도 순)
1순위: 로그인 시점의 명시적 매핑 신호(anonymous ID ↔ user_id)
2순위: 이메일 완전 일치
3순위: 전화번호 완전 일치
4순위: (확률론적 매칭 도입 시) 기기·행동 패턴 유사도: 오탐 위험 명시
3. 룰셋 설계 시 확인
□ 너무 느슨한 매칭 기준(이름+생년월일 등)을 쓰고 있지 않은가
□ 너무 엄격해 같은 사람을 놓치는 필드 조합은 없는가
□ 로그인 이벤트에 anonymous ID ↔ user_id 매핑 신호가 실제로 CDP에 전송되는가(개발팀 확인 필요)
16강. CDP 데이터 모델 설계에서 프로필·이벤트·세그먼트라는 CDP의 실제 데이터 구조를 설계합니다.