CDP 고객 여정 분석, 이벤트 기준 설정 5단계
- 고객 여정의 질문과 전환 기준부터 정합니다.
- 이벤트명·속성·식별자를 공통 규칙으로 정의합니다.
- 개발 환경에서 누락·중복·순서 오류를 점검합니다.
CDP 고객 여정 분석에 쓸 이벤트는 고객이 실제로 한 행동을 기준으로 정의하고, 분석에 필요한 속성·발생 조건·식별 기준까지 함께 기록해야 합니다. 먼저 분석 질문과 핵심 전환을 정한 뒤, 여정의 각 단계에서 필요한 이벤트만 설계하세요. 행동을 무작정 많이 수집하면 경로는 복잡해지고, 팀마다 같은 행동을 다르게 해석하기 쉽습니다.
이벤트 기준은 분석 질문에서 시작합니다
고객 여정의 판단 기준을 먼저 정하기
예를 들어 “상품을 본 고객 중 어떤 경로로 구매까지 이어지는가?”를 분석한다면 상품 조회부터 구매 완료까지의 단계가 필요합니다. 이때 페이지뷰 전체를 모두 핵심 이벤트로 삼기보다, 고객의 다음 행동을 설명하거나 캠페인 조건으로 활용할 행동을 골라야 합니다. 구매 전환율을 볼지, 장바구니 이탈을 줄일지에 따라 필요한 이벤트와 속성이 달라집니다.
이벤트와 속성을 구분하기
이벤트는 특정 시점에 일어난 행동이고, 이벤트 속성은 그 행동의 맥락입니다. ‘장바구니 담기’는 이벤트이고 상품 ID, 수량, 유입 채널은 그 이벤트를 설명하는 속성입니다. 회원 등급처럼 여러 행동에 걸쳐 유지되는 값은 사용자 속성으로 관리하는 편이 적절합니다. 이 구분이 흐려지면 같은 정보를 서로 다른 이름으로 중복 수집하게 됩니다.
CDP 이벤트 기준 설정 5단계
1단계. 핵심 여정과 성공 조건을 정합니다
가입, 탐색, 장바구니, 결제, 구매처럼 여정의 주요 단계를 그린 뒤 각 단계에서 답할 질문을 씁니다. ‘구매 완료’의 성공 조건도 정해야 합니다. 결제 버튼 클릭인지, 결제 승인인지, 주문 시스템에 주문이 생성된 시점인지 합의하세요. 실무에서는 데이터가 신뢰할 수 있는 발생 지점 하나를 기준으로 삼고, 보조 행동은 별도 이벤트로 둡니다.
2단계. 이벤트 이름과 발생 조건을 정의합니다
이벤트 이름은 한 가지 표기 규칙을 정해 일관되게 씁니다. 예를 들어 product_viewed, add_to_cart, purchase_completed처럼 행동을 알아볼 수 있는 이름을 정하고, 대소문자나 단복수 표기를 섞지 않습니다. 화면 이름이나 상품명을 이벤트명에 매번 붙여 동적 이벤트를 만들기보다 고정된 이벤트명과 속성 조합을 사용하세요.
3단계. 필수 속성과 데이터 형식을 정합니다
각 이벤트마다 필수·선택 속성, 값의 형식, 허용 값을 명시합니다. 금액은 숫자, 통화는 표준 통화 코드, 구매 식별자는 주문마다 고유한 문자열처럼 규칙을 둡니다. 상품 ID는 화면에 보이는 상품명과 별도로 관리해야 이름이 바뀌어도 상품 단위 분석이 유지됩니다. 구매 이벤트의 금액과 통화, 거래 ID 같은 값은 목적에 맞게 검증하세요. Google의 전자상거래 측정 문서는 구매 이벤트에서 거래 ID와 통화를 설정하는 방법을 안내합니다.
4단계. 사용자 식별과 채널 정보를 연결합니다
익명 방문자와 로그인 고객의 행동을 어떤 조건에서 연결할지 정합니다. 로그인 전 임시 식별자와 로그인 후 고객 ID를 병합하는 기준, 로그아웃·기기 변경 때의 처리, 식별이 불확실한 경우의 예외를 기록하세요. 광고 유입 분석이 필요하면 캠페인·매체 정보를 이벤트 또는 세션 맥락에 일관되게 붙이고, 광고 플랫폼으로 전달하는 이벤트는 별도 매핑표로 관리합니다. 개인 식별 정보는 분석 편의를 이유로 이벤트에 그대로 넣지 말고, 필요한 수집 범위와 접근 권한을 내부 정책에 따라 검토하세요.
5단계. 개발·검수 후 기준 문서를 관리합니다
개발 프로젝트에서 실제 이벤트를 발생시켜 이름, 필수 속성, 값의 형식, 발생 시점을 확인합니다. 구매 버튼을 여러 번 눌렀을 때 구매 완료 이벤트가 중복 전송되는지, 실패한 결제가 구매로 기록되는지, 웹과 앱이 같은 의미의 이벤트를 보내는지도 점검하세요. 이상이 확인되면 구현이나 기준 문서를 수정하고, 변경 사유와 적용 시점을 남깁니다. 이벤트 계획은 구현 명세이자 분석팀과 마케팅팀이 공유하는 기준표입니다. Amplitude의 택소노미 계획 문서도 비즈니스 목표와 지표에서 출발해 이벤트와 속성을 선택하고 이름을 정하는 흐름을 안내합니다.
실무 기준표에 꼭 넣을 항목
스프레드시트나 데이터 카탈로그에는 아래 항목을 한 줄씩 정의하면 기획·개발·분석 간 해석 차이를 줄일 수 있습니다. 속성 설명에는 예시만 적지 말고 값이 만들어지는 시스템과 허용 범위도 덧붙이세요.
| 항목 | 기록할 내용 | 예시 |
|---|---|---|
| 이벤트 | 고정 이름과 사용자 행동 | purchase_completed · 결제 승인 후 주문 생성 |
| 필수 속성 | 이름, 형식, 필수 여부 | order_id 문자열, 중복 방지용 고유값 |
| 발생 조건 | 전송 시점과 제외 조건 | 승인 성공 시 전송, 결제 실패는 제외 |
| 식별·소유 | 사용자 연결 기준, 담당자, 변경 이력 | 로그인 ID 연결, 데이터 담당팀 |
- 명명 규칙: 대소문자, 단어 순서, 동사 시제를 통일하고 기존 이벤트와 중복되는지 확인합니다.
- 속성 규칙: 필수값, 자료형, 단위, 허용 값, 누락 시 처리 방식을 적습니다.
- 버전·담당: 변경 요청자, 승인자, 적용일, 이전 기준과의 차이를 남깁니다.
여정 분석을 흐리는 흔한 오류
클릭을 구매 완료로 간주하는 경우
버튼 클릭은 의도를 보여줄 수 있지만 거래 성공을 보장하지 않습니다. 클릭, 결제 시도, 승인, 주문 확정을 각각 구분하면 어느 구간에서 이탈하는지 추적할 수 있습니다. 분석 목적에 따라 전환 이벤트를 선택하되, 그 이벤트가 실제로 무엇을 뜻하는지 보고서에도 명시하세요.
같은 행동을 채널마다 다르게 부르는 경우
웹은 add_to_cart, 앱은 cart_added로 보내면 하나의 여정을 볼 때 매핑 작업이 늘고 누락 가능성도 커집니다. 이벤트의 의미와 속성 구조를 공통으로 맞추고, 플랫폼 차이는 platform 같은 속성으로 표현합니다. 기존 시스템의 이름을 바꾸기 어렵다면 표준 이벤트명과 원천 이벤트명 사이의 매핑표를 유지하세요.
진입과 이탈 조건을 이벤트 정의와 혼동하는 경우
이벤트 기준은 행동 데이터를 어떻게 기록할지 정하고, 여정 조건은 기록된 행동을 누구의 진입·종료 판단에 사용할지 정합니다. 예컨대 장바구니 담기는 이벤트이고, “담은 뒤 24시간 동안 구매하지 않은 고객”은 이벤트와 시간 조건을 조합한 여정 조건입니다. 조건을 더 구체화할 때는 CDP 세그먼트 진입·이탈 조건 설계법에서 진입과 이탈 기준을 별도로 정리할 수 있습니다.
- 시간대와 이벤트 발생 시점이 채널 간 동일하게 해석되는지 확인합니다.
- 재시도·새로고침·중복 콜백이 이벤트를 반복 전송하는지 확인합니다.
- 동의 상태와 내부 데이터 정책에 맞게 수집·활용 가능한 데이터를 구분합니다.
검수 후 운영까지 이어가는 방법
처음부터 모든 행동을 수집하려 하기보다 핵심 여정에 필요한 이벤트부터 적용하고, 분석에서 부족한 점이 확인될 때 추가하는 편이 관리하기 쉽습니다. 기준표는 승인된 이벤트와 속성을 확인하는 단일 문서로 두고, 변경 요청은 담당자가 검토하도록 운영하세요. 이벤트 의미가 바뀌면 과거 데이터와 비교 가능한지 먼저 판단하고, 필요하면 새 이벤트명이나 버전을 사용해 해석의 연속성을 지킵니다.
최종적으로는 대표 여정 하나를 기준으로 유입부터 전환까지 이벤트가 실제 순서대로 연결되는지 확인하세요. 사용자가 익명 상태에서 시작해 로그인하거나 다른 기기로 이동하는 경우도 검수 시나리오에 포함합니다. 이 과정이 끝나야 CDP의 세그먼트와 자동화 조건이 기대한 고객 행동을 반영합니다.
자주 묻는 질문
Q. CDP 이벤트는 몇 개부터 정의해야 하나요?
정해진 개수보다 분석 질문과 핵심 여정에 필요한 행동을 우선하세요. 가입·주요 탐색·핵심 전환처럼 실제 판단에 쓰이는 이벤트부터 시작하고, 운영 중 확인된 데이터 공백에 맞춰 확장하면 됩니다.
Q. 이벤트명에 상품명이나 화면명을 넣어도 되나요?
매번 달라지는 값을 이벤트명에 넣으면 이벤트 종류가 불필요하게 늘어납니다. 고정된 이벤트명을 쓰고 상품명이나 화면명은 속성으로 보내는 방식이 일반적으로 분석과 관리에 유리합니다.
Q. 구매 완료 이벤트는 어느 시점에 보내야 하나요?
결제 성공과 주문 확정 중 어떤 사실을 측정할지 먼저 정하고, 그 사실을 확인할 수 있는 시스템의 발생 시점을 기준으로 삼으세요. 클릭이나 결제 시도만으로 실제 구매 완료를 기록하지 않도록 실패·취소 처리도 함께 정의해야 합니다.
Q. 웹과 앱 이벤트 이름은 달라도 되나요?
같은 행동을 분석하려면 공통 의미와 속성 구조를 맞추는 것이 좋습니다. 기존 구현 때문에 이름이 다르면 표준 이름으로 매핑하고, 채널 정보는 별도 속성으로 구분하세요.
Q. 이벤트 기준은 언제 다시 검토해야 하나요?
여정이나 결제 흐름이 바뀌거나, 데이터 누락·중복이 발견되거나, 새 채널이 추가될 때 검토하세요. 변경 날짜와 이유를 기록하고 개발 환경에서 검증한 뒤 운영 데이터에 반영하는 절차를 두면 과거 지표 해석도 쉬워집니다.
