실무 프로세스에서 데이터 요건 정의가 놓이는 위치

CJM 작성의 실무 프로세스는 (1) 목표·범위·타겟 고객 정의, (2) 페르소나 설정, (3) 실제 데이터 기반 여정 단계 및 터치포인트 정리 순서로 진행됩니다. 데이터 요건 정의는 이 3단계의 핵심 작업입니다. 여정 단계(예: 상품 탐색, 장바구니, 결제, 배송, 재구매)를 먼저 정하고, 각 단계를 대표하는 행동이 정확히 무엇인지를 이벤트 단위로 명세하는 작업입니다. 이 작업 없이 바로 지도를 그리기 시작하면, 나중에 데이터를 넣으려 할 때 어떤 로그를 가져와야 할지 몰라 작업이 되돌아가는 경우가 흔합니다.

여정 단계별 핵심 이벤트를 정의하는 방법

각 여정 단계는 하나 이상의 핵심 이벤트로 대표되어야 합니다. 예를 들어 '상품 탐색' 단계는 상품 상세 페이지 조회(view_item) 이벤트로, '장바구니' 단계는 장바구니 담기(add_to_cart) 이벤트로, '결제' 단계는 결제 시작(begin_checkout)과 결제 완료(purchase) 두 이벤트로 나눠 정의하는 식입니다. 중요한 것은 하나의 여정 단계를 하나의 이벤트로만 단순화하지 않는 것입니다 — 결제처럼 여러 하위 스텝(배송지 입력, 결제수단 선택, 본인인증, 최종 확인)이 있는 단계는 하위 스텝별로 이벤트를 세분화해야, 나중에 어느 하위 스텝에서 이탈이 몰리는지 구분할 수 있습니다.

웹과 인앱 트래킹 체계를 동기화해야 하는 이유

GA4 같은 웹 분석 툴과 자사 앱의 인앱 트래킹 SDK는 이벤트명·파라미터 체계가 서로 다르게 설계된 경우가 많습니다. 웹에서는 'purchase' 이벤트로 기록되는 행동이 앱에서는 'order_complete'라는 다른 이름으로 기록되고 있다면, 두 채널의 데이터를 하나의 CJM으로 합칠 때 같은 행동인데도 서로 다른 이벤트로 취급되어 지도가 왜곡됩니다. 이를 막으려면 CJM 프로젝트를 시작하기 전에 웹·앱 두 채널의 이벤트 명세서를 나란히 놓고, 같은 의미를 가리키는 이벤트끼리 매핑 테이블을 만들어두는 사전 작업이 필요합니다.

이벤트 정의가 부서마다 다를 때 생기는 문제

같은 이름의 이벤트라도 부서마다 다른 기준으로 발생시키고 있다면 더 심각한 문제가 생깁니다. 예를 들어 마케팅팀은 '가입 완료'를 본인인증까지 끝난 시점으로 정의하고, 개발팀은 이메일 입력만 끝나도 '가입 완료' 이벤트를 쏘도록 구현해뒀다면, 같은 지표를 보고도 두 팀이 서로 다른 숫자를 이야기하게 됩니다. 데이터 요건 정의 단계에서는 이벤트의 이름뿐 아니라 '정확히 어느 시점에 발생하는가'까지 명문화하고, 관련 부서(마케팅, 개발, 데이터)가 함께 검토해 합의하는 절차를 거쳐야 이런 사고를 예방할 수 있습니다.

데이터 요건 정의 문서를 만드는 실무 팁

데이터 요건 정의는 한 장의 스프레드시트로 정리하는 것이 실무에서 가장 무난합니다. 열에는 여정 단계, 이벤트명, 이벤트 발생 시점, 필요 파라미터, 웹·앱 매핑 여부, 담당 부서를 각각 두고, 신규 이벤트가 필요하면 개발팀에 요청할 티켓 번호까지 함께 기록해두면 진행 상황을 추적하기 쉽습니다. 이 문서는 CJM 프로젝트의 첫 공식 산출물로 만들어, 이후 모든 정량 분석·대시보드 설계가 이 문서를 기준으로 삼도록 관리하는 것이 데이터 정합성을 오래 지키는 가장 확실한 방법입니다.

기존 트래킹이 이미 있는 조직이라면

새로 트래킹을 설계하는 것이 아니라 기존에 이미 GTM·GA4·자체 로그가 쌓여 있는 조직이라면, 처음부터 새 이벤트를 정의하기보다 기존 이벤트 목록을 먼저 감사(audit)하는 것이 순서입니다. 여정 단계별로 필요한 이벤트가 이미 존재하는지, 존재한다면 명명 규칙과 발생 시점이 이번 CJM 프로젝트의 정의와 일치하는지 대조한 뒤, 부족한 부분만 신규로 추가하는 방식이 개발 리소스를 절약하면서도 데이터 정합성을 지키는 훨씬 현실적인 접근입니다.

데이터 요건 정의를 건너뛰었을 때 나타나는 전형적 증상

데이터 요건 정의 없이 CJM 프로젝트를 시작한 조직에서 공통적으로 나타나는 증상이 있습니다. 지도는 예쁘게 완성됐는데, 몇 달 뒤 "이 지도의 수치를 다시 업데이트하자"는 요청이 들어오면 어떤 데이터를 어디서 가져왔는지 아무도 정확히 기억하지 못하는 상황입니다. 처음 지도를 만들 때 담당자가 수작업으로 여러 툴의 화면을 캡처해 숫자를 옮겨 적었다면, 그 재현 과정 자체가 기록되어 있지 않아 매번 처음부터 다시 데이터를 찾아야 합니다. 데이터 요건 정의 문서가 있으면 이 재현 작업이 문서에 적힌 이벤트명·조회 조건을 그대로 따라가기만 하면 되는 반복 가능한 절차로 바뀝니다.

신규 이벤트 추가를 요청할 때의 우선순위

개발팀에 신규 트래킹을 요청할 때는 모든 빈틈을 한 번에 요청하기보다, CJM에서 감정 곡선이 가장 낮게 나온 단계부터 우선순위를 매겨 순차적으로 요청하는 것이 현실적입니다. 개발 리소스는 항상 제한적이므로, 우선순위 없이 요청 목록을 통째로 넘기면 일정이 뒤로 밀리거나 중요도가 낮은 이벤트부터 먼저 구현되는 비효율이 발생하기 쉽습니다.