데이터만 있으면 어떻게든 분석할 수 있겠지라고 생각했지만..
주어진 데이터셋을 바탕으로 분석을 해보면서 깨달았다.
그냥 데이터만 쌓여 있으면, 별거 아닌 일에도 손이 많이 가고,
심하면 분석 자체가 어려워질 수 있다는 것을... 🥲
더하여, 실제로 현직자 분들의 말에 따르면 데이터 분석가의 업무는 다음과 같은 비율로 이루어진다고 한다.
- 50% : 데이터 운영/관리 (DQM: Data Quality Management)
- 30% : 단순 데이터 추출/정리/전달
- 10% 기타 버그 픽싱
- 5~10% 데이터 분석 같은 것들?
→ 분석 시간을 확보하려면 데이터 표준화와 택소노미 설계가 필수다.
택소노미(Taxonomy)란?
원래는 생물 분류 체계(종, 속, 과 같은 구분)에서 사용되던 개념이다.
데이터 분야에서는 이를 확장해, 데이터를 일관되게 정의하고 분류하는 체계로,
누구나 같은 방식으로 이해하고 사용할 수 있도록 정리하는 것을 의미한다.
택소노미 설계하기
1. 분석 목표 및 비즈니스 목표 정의
데이터 분석의 목적은 성과를 개선하고 비즈니스 문제를 해결하는 것이다.
따라서 "무엇을 측정할 것인지", "어떤 의사결정을 지원하는지"를 명확히 정리한 후, 이벤트를 설계해야 한다.
할 수 있는 모든 행동을 모두 기록해야지 라는 생각은 위험하다.
매일 수십만 개의 이벤트가 쌓이기 시작
데이터 저장 비용 급증 (GCP, AWS 비용 폭등)
분석하려고 데이터를 뽑으면 노이즈 투성이...
- 회원가입 전환율 개선
→ "가입 페이지에 들어온 유저 중 몇 %가 실제로 가입을 완료했는가?"- 상품 추천 클릭률 향상
→ "추천 상품을 본 사람 중 얼마나 많은 사용자가 클릭했는가?"- 결제 이탈률 감소
→ "결제 프로세스 중 어떤 단계에서 가장 많이 이탈하는가?"
2. 핵심 이벤트 정의
목표가 정해졌다면, 그에 맞는 핵심 사용자 행동을 구체적으로 뽑아야 한다.
원칙: 하나의 행동은 하나의 이벤트로 분리한다.
다시 말해, "회원가입 버튼 클릭"과 "회원가입 완료"는 서로 명확히 다른 행동이므로, 각각 별개의 이벤트로 정의해야 한다.
- 회원가입 전환율 개선
view_signup_page (가입 페이지 조회)
click_signup_button (가입 버튼 클릭)
complete_signup (가입 완료)- 상품 추천 클릭률 향상
view_recommendation_list (추천 목록 조회)
click_recommendation_item (추천 상품 클릭)- 결제 이탈률 감소
start_checkout (결제 프로세스 시작)
input_payment_info (결제 정보 입력)
complete_payment (결제 완료)
abandon_checkout (결제 도중 이탈)
3. 이벤트 이름 짓는 규칙(Naming Convention) 정하기
정의한 이벤트들을 관리하기 위해 이름 짓는 규칙을 설정해야 한다.
예를 들자면,
- 이벤트 이름은 소문자
- 단어 사이는 언더바(snake_case)로 연결
- 동사 + 명사 구조를 기본으로
추가 권장사항:
자주 쓰는 동사, 명사를 사전으로 정리해 표준화하기
같은 버튼이라도 submit_btn, signup_button 처럼 다르게 표현할 가능성이 있기 때문이다.
4. 이벤트 속성(Event Properties) 설계
속성은 행동이 발생한 상황을 설명하는 부가 정보다.
잘 설계되어 있다면, 이후 데이터 분석 시 더 정확한 인사이트를 얻을 수 있다.
이벤트 이름 설명 추가 파라미터 view_signup_page 사용자가 가입 페이지를 조회했을 때 { "page_name": "어떤 가입 페이지인지", "referrer": "이전 방문 페이지" }view_recommendation_list 사용자가 추천 목록을 조회했을 때 { "page_name": "추천 목록이 노출된 페이지", "recommendation_type": "추천 방식" }start_checkout 사용자가 결제를 시작했을 때 { "cart_id": "장바구니 ID", "total_price": "결제 시작 시 총 결제 금액" }
5. 공통 필드(Common Fields) 설정
모든 이벤트에 반드시 들어가야 하는 공통 필드를 설정해야 한다.
대표적으로 user_id, session_id, timestamp, platform 등이 있다.
이런 필드들은 이벤트를 연결하고, 사용자 단위로 데이터를 집계하거나 세션 단위 분석을 수행하는 데 필수적이다.
만약 이런 공통 필드를 누락하게 된다면, 이벤트 간 연결이 불가능해진다.
RDB의 본질적 역할을 위해 공통 필드 설계는 필수다.
event_name user_id session_id timestamp platform params view_signup_page user_00123 session_abc456 2025-04-27T12:34:56Z web { "page_name": "signup_basic", "referrer": "landing_page" }
6. 카테고리 구조 설계
수많은 이벤트를 효율적으로 관리하고 분석하기 위해 카테고리를 정의하는게 좋다.
카테고리는 기능별, 서비스 흐름별로 이벤트를 묶어주는 논리적 그룹이다.
카테고리 구조를 잘 짜두면 이후 데이터 조회나 리포트 작성시 더 빠르게 필요한 이벤트를 찾을 수 있을 것이다.
카테고리 설명 포함될 수 있는 주요 이벤트 회원 관리 (User Management) 사용자의 가입, 로그인, 프로필 관리 흐름 view_signup_page,submit_signup_form,login_success,logout상품 탐색 (Product Discovery) 상품을 탐색하거나 관심 상품을 찾는 흐름 view_product_list,view_product_detail,search_product,add_to_wishlist구매 (Purchase) 실제 구매로 이어지는 흐름 add_to_cart,start_checkout,complete_payment,view_order_confirmation고객 지원 (Customer Support) 사용자가 고객센터나 FAQ를 이용하는 흐름 view_faq_page,submit_support_request기타 (Others) 그 외 분류되지 않는 활동 app_open,notification_click
7. 버전 관리 규칙 마련
버전 관리는 다음과 같은 방법으로 진행한다:
① 이벤트 이름에 버전 넘버를 붙인다
이벤트의 주요 구조나 의미가 바뀔 경우, 이벤트 이름에 버전을 명시한다.
purchase→purchase_v2(구매 로직 변경)purchase_completed(구매 완료 상태를 분리)purchase_reserved(예약 구매 상태 추가)
② 변경 이력(Change Log)을 관리한다
이벤트 변경 시마다 변경 일자, 이벤트 이름, 변경 내용, 변경자를 기록한다.
날짜 이벤트 이름 변경 내용 변경자 2022-07-01 purchase 예약 주문 기능 추가 데이터팀 2022-09-15 signup 추가 가입 채널(kakao, apple) 수집 시작 데이터팀
③ 신규 이벤트는 항상 문서화하고 공유한다
새로운 이벤트를 만들거나 버전이 올라갈 경우, 변경된 점과 기존 버전과의 차이점을 명확히 문서화하여 관련 부서에 공유한다.
버전 관리의 중요성을 체감하기 어렵다면 상상해보자.
처음엔 별생각 없이 purchase 이벤트를 썼다.
그냥 "결제 완료"만 기록하면 됐다.
그러다 예약 주문 기능이 추가됐다.
개발팀은 기존 purchase 이벤트에 예약 주문까지 같이 태웠다.
그때는 대수롭지 않게 넘겼다.
그런데 리포트를 뽑을 때 문제가 터졌다.
진짜 결제와 예약 주문이 구분되지 않았다.
퍼널 분석은 엉키고, 전환율 계산도 뒤죽박죽이었다.
결국 전체 리포트를 갈아엎어야 했다.
"00년 0월 이전 데이터는 따로 주의해야 합니다" 라는 주석을 리포트마다 붙였다.
이미 쌓인 데이터는 고칠 수도 없었다.
8. 문서화 및 공유
설계한 문서가 없거나 공유하지 않는다면
그 데이터를 활용하는 모든 사람들이 나만 찾게 되거나, 못쓰는 데이터가 될 수 있다.
다른 사람도 쉽게 데이터를 이해할 수 있도록
이벤트 이름, 설명, 속성 리스트, 데이터 타입, 카테고리, 버전 정보를 정리하고,
검색이 용이하도록 문서 구조를 깔끔하게 정리해보자.
마무리 한 줄
데이터를 잘 관리하는 것이, 진짜 데이터 분석의 시작이라고 생각한다.
