무엇과 무엇을 비교하는 것인지부터 정의한다

CDP(Customer Data Platform)는 2013년 David Raab가 창시한 개념으로, CDP Institute는 이를 '다른 시스템이 접근 가능한, 영속적이고 통합된 고객 데이터베이스를 만드는 패키지형 소프트웨어'로 정의합니다. 핵심 산출물은 단일 고객 뷰로, 흩어진 데이터를 하나의 프로필로 병합해 모든 팀이 같은 정보를 참조하게 하는 단일 진실 공급원입니다. 여기서 정합성 검증의 첫 함정이 나옵니다. 매체가 보고하는 '전환수'는 이벤트를 세는 숫자이고, CDP가 보여주는 '고객 수'는 사람을 세는 숫자입니다. 한 사람이 두 번 구매하면 매체 전환은 2건, CDP 고객은 1명이므로 둘은 애초에 같아질 수 없습니다. 그러므로 대조는 사람 단위가 아니라 주문·거래 단위로 내려서 해야 합니다. 검증 설계의 출발점은 '어떤 키로 붙일 것인가'이고, 실무적으로 가장 안전한 키는 주문번호(거래 ID)입니다.

정본을 무엇으로 둘 것인가

매체 리포트와 CDP를 나란히 놓고 어느 쪽이 맞는지 다투면 결론이 나지 않습니다. 자사 주문·결제 시스템(또는 CRM)을 정본으로 놓고, 그 아래에 CDP와 매체를 각각 붙이는 3열 구조로 표를 짜십시오. 열은 ①정본 주문 건수 ②CDP에 적재된 주문 건수 ③매체별 귀속 전환수이고, 행은 일자입니다. ①과 ②의 차이는 적재 파이프라인 문제이므로 먼저 해결해야 하고, ②와 ③의 차이는 어트리뷰션·매칭 문제라 성격이 다릅니다. 이 둘을 섞어서 하나의 '오차'로 보고하면 원인을 영영 찾지 못합니다. Salesforce Data Cloud의 파이프라인은 Data Streams로 여러 소스를 수집해 Data Transforms로 정제·정규화한 뒤 아이덴티티 레졸루션을 적용하는 순서인데, ①과 ②의 차이는 대개 수집·정제 단계에서 생깁니다.

아이덴티티 레졸루션이 만드는 오차는 어떻게 잡아내나

아이덴티티 레졸루션은 서로 다른 기기·채널·세션에서 발생한 파편화된 데이터를 하나의 고객 프로필로 연결하는 과정으로, 이메일·전화번호 같은 정확한 식별자를 맞추는 결정론적 방식과 행동 신호로 추론하는 확률론적 방식을 함께 씁니다. 문제는 방향이 두 개라는 점입니다. 너무 엄격하면 같은 사람이 여러 프로필로 쪼개져 고객 수가 부풀고, 너무 느슨하면 다른 사람이 한 프로필로 잘못 병합됩니다. Salesforce Data Cloud의 룰셋 설계에 대해서도 과도하게 느슨하면 다른 사람을 한 프로필로 병합할 위험이 있다는 지적이 공통적으로 나옵니다. 검증도 양방향이어야 합니다. 과다 병합 쪽은 한 프로필에 서로 다른 성명·생년월일·배송지가 섞여 있는 케이스를 샘플로 뽑아 확인하고, 과소 병합 쪽은 같은 이메일 또는 같은 전화번호가 서로 다른 프로필에 들어 있는 케이스를 쿼리로 뽑습니다. 이 두 쿼리를 월 1회 정기 실행하고 건수 추이를 기록해두면, 룰셋을 바꿨을 때 어느 방향으로 움직였는지 숫자로 확인할 수 있습니다.

매칭이 안 되는 진짜 원인은 대부분 규격이다

CDP나 클린룸에서 식별자를 매칭하려면 양측이 동일한 정규화 규칙(소문자 변환, 공백 제거 등)을 적용한 뒤 동일한 해시 알고리즘(흔히 SHA-256)과 동일한 인코딩으로 해싱해야 하며, 이 중 하나라도 어긋나면 매칭률이 급격히 낮아지는 문제가 도입 실무에서 반복적으로 보고되는 대표적 실패 원인으로 꼽힙니다. 그러니 '매칭률이 낮다'는 보고를 받으면 알고리즘이나 데이터 양을 의심하기 전에 규격부터 한 줄씩 대조하십시오. 점검 항목은 다섯 가지입니다. ①앞뒤 공백 제거 여부 ②소문자 변환 여부 ③전화번호 국제 형식 정규화 여부 ④인코딩 방식(Hex인지 Base64인지, Base64라면 웹세이프인지) ⑤빈 값·더미 값 처리 방식입니다. 매체마다 요구 규격이 다를 수 있으므로 공식 개발자 문서를 개별 확인하고, 한 매체용 파이프라인을 다른 매체에 그대로 재사용하지 마십시오. 이 다섯 항목을 표로 만들어 시스템별로 채워보는 것만으로 원인의 상당수가 드러납니다.

GA4 쪽 정의 차이도 함께 걷어내야 한다

CDP와 매체 사이의 차이만 보다 보면 분석 도구 쪽 정의 차이를 놓칩니다. GA4의 주요 이벤트 카운팅 방법은 '세션당 한 번'과 '이벤트당 한 번' 두 가지인데, UA 목표를 마이그레이션한 전환은 세션당 한 번이 기본값이고 새로 만든 전환은 이벤트당 한 번이 기본값입니다. 구매처럼 한 세션에 여러 번 발생할 수 있는 이벤트를 세션당 한 번으로 두면 실제 주문 수보다 적게 잡힙니다. GA4 보고 ID의 블렌드 옵션도 User-ID가 있으면 우선 쓰고 없으면 기기 ID, 그마저 없으면 모델링으로 폴백하므로, 연동이 부실하면 같은 사람이 여러 명으로 중복 집계됩니다. 검증 착수 전에 시스템별 전환 정의·카운팅 방식·식별자 우선순위를 한 표에 적어 용어를 통일하십시오.

오차 몇 %까지가 정상인가

국내에 공인된 허용 오차율 기준은 확인된 것이 없습니다. 그러므로 세 단계로 접근하십시오. ①확인된 인접 사실을 참고치로만 인용합니다 — 제휴 마케팅 영역에서는 네트워크가 집계한 전환 수와 사업자 내부 주문 수가 510% 이상 차이 나는 것이 추적 시스템 문제의 가장 뚜렷한 신호로 꼽힙니다. 다만 이는 제휴 영역의 업계 관찰이므로 CDP·매체 대조의 합격선으로 그대로 옮기지 마십시오. ②우리 계정 데이터로 기준선을 만듭니다. CDP 도입 전 48주간 정본 주문 수와 매체 전환수의 일자별 차이를 계산해 평상시 오차 분포(중앙값·최대·최소)를 구하고, 도입 후 같은 방식으로 계산해 그 분포를 벗어나는 날만 조사 대상으로 삼습니다. ③확인 경로를 문서에 적습니다 — 매체 공식 문서와 광고주센터, 자사 CRM·주문 데이터, CDP 벤더 계약서입니다. 다수 CDP 벤더는 MTU(월간 추적 유저 수)나 이벤트량 기준 티어형 과금을 쓰는 것으로 알려져 있고 단가는 맞춤 견적으로 산정되므로, 프로필 중복을 방치하면 비용까지 함께 샙니다.