매칭 방식은 왜 결정론적/확률론적으로 나뉘나

Identity Resolution(신원 해석)은 서로 다른 기기·채널·세션에서 발생한 파편화된 데이터를 하나의 정확한 고객 프로필로 연결하는 과정입니다. 이때 매칭 방식은 두 갈래로 나뉩니다—이메일·전화번호처럼 정확히 일치하는 식별자를 기준으로 연결하는 결정론적(deterministic) 매칭과, 정확한 식별자가 없을 때 행동 패턴(같은 기기·유사한 접속 시간대 등)을 근거로 같은 사람일 가능성을 추론하는 확률론적(probabilistic) 매칭입니다. 결정론적 매칭은 정확도가 높지만 공통 식별자가 없으면 아예 매칭이 안 되고, 확률론적 매칭은 공통 식별자가 없어도 연결을 시도할 수 있지만 오탐(다른 사람을 같은 사람으로 잘못 판단) 위험이 있습니다.

anonymous ID와 user_id는 어떻게 병합되나

User Mapping의 핵심 시나리오는 이렇습니다—비회원 상태로 사이트를 둘러보는 방문자는 쿠키나 로컬 저장소 기반의 anonymous ID로 추적되고, 이 ID로 조회 이력·장바구니 담기 같은 행동이 CDP에 쌓입니다. 이후 이 방문자가 실제로 로그인하면, 그 순간 시스템은 로그인 이벤트와 함께 "이 세션의 anonymous ID는 user_id XXX와 같은 사람이다"라는 매핑 신호를 CDP로 보냅니다. 이 신호를 받은 CDP는 로그인 이전의 anonymous ID 행동 기록 전체를 user_id 프로필로 병합해, 로그인 전후의 행동이 끊기지 않고 하나의 고객 여정으로 이어지게 만듭니다. 이 병합은 유저 본인이 로그인이라는 명시적 행위로 자신의 신원을 확인해준 시점에 이뤄지므로, 결정론적 매칭 중에서도 가장 신뢰도가 높은 케이스로 취급됩니다.

Salesforce가 이 과정을 룰셋으로 관리하는 방식

Salesforce Data Cloud 공식 문서는 이 매칭·정합 과정을 룰셋(ruleset)이라는 개념으로 관리합니다. 룰셋은 서로 다른 소스의 레코드가 동일 고객을 가리키는지 판단하는 매칭 규칙의 모음으로, 조직이 "어떤 필드를 어떤 우선순위로 비교할지"를 직접 설계할 수 있습니다. 이 과정을 거친 결과는 Unified Individual, Unified Individual Contact Email/Phone/Address 같은 통합 객체로 생성됩니다—즉 매칭 로직 자체가 블랙박스가 아니라 조직이 검토·수정 가능한 규칙 형태로 관리된다는 것이 특징입니다.

룰셋을 잘못 설계하면 생기는 위험

룰셋 설계에서 가장 조심해야 할 부분은 매칭 기준을 지나치게 느슨하게 잡는 경우입니다. 예를 들어 이름과 생년월일만으로 매칭하도록 설계하면, 동명이인이 다른 사람의 구매 이력·개인정보와 한 프로필로 잘못 병합될 위험이 있습니다—이는 Salesforce 관련 공식 커리큘럼(Trailhead)에서도 공통으로 지적하는 위험입니다. 반대로 매칭 기준을 지나치게 엄격하게 잡으면(예: 이메일·전화번호가 완전히 일치해야만 매칭), 실제로는 같은 사람인데도 매칭에 실패해 단일 고객 뷰가 조각난 채로 남는 문제가 생깁니다. 실무에서는 이메일을 1순위, 전화번호를 2순위로 두고 로그인 시점의 명시적 매핑 신호를 최우선으로 신뢰하는 식으로, 신뢰도 순서를 명확히 정한 룰셋을 설계하는 것이 권장됩니다.