프로덕트 이벤트 택소노미는 “분석을 잘하기 위한 목록”이 아니라, 팀이 같은 언어로 제품을 운영하게 만드는 계약(Contract) 입니다. 북극성 지표를 정해놓고도 지표가 흔들리는 팀은 대부분 이벤트가 일관되지 않거나, 정의가 문서가 아니라 사람 머릿속에만 남아 있기 때문입니다. 아래는 북극성 지표부터 이벤트 딕셔너리까지 한 번에 설계하는 실무 프로세스입니다.
북극성 지표를 이벤트로 “계산 가능”하게 정의하기
북극성 지표(North Star Metric)는 보통 “활성 사용자 수” 같은 추상어로 끝나기 쉬운데, 택소노미 설계에서는 반드시 계산식으로 내려와야 합니다. 예를 들어 “주간 활성(WAU)”도 이벤트로는 여러 정의가 가능합니다.
- 단순 방문: app_open 1회 이상
- 핵심행동 기반 활성: core_action_completed 1회 이상
- 가치 기반 활성: purchase 또는 subscription_active 또는 revenue_event 발생
어떤 정의를 선택하느냐에 따라 제품 방향이 달라지므로, 먼저 “우리 제품이 사용자에게 제공하는 핵심 가치가 무엇이고, 그 가치를 사용자가 실제로 경험했다는 증거가 되는 행동은 무엇인지”를 합의합니다. 북극성 지표는 반드시 “핵심 가치 행동”으로 닫혀야 하고, 그 행동은 이벤트로 측정 가능해야 합니다.
지표 트리(메트릭 트리)로 분해해서 “필요 이벤트”를 역산하기
북극성 지표 하나만 정하면 부족합니다. 운영은 결국 입력 지표를 조정하는 일이기 때문에, 지표 트리로 분해합니다. 예시(구독/커머스/게임 모두에 공통적으로 적용 가능한 형태)로 보면:
북극성 지표(예: 주간 가치 활성 사용자)
= 유입 × 활성화율 × 핵심행동 전환율 × 잔존율
여기서 각 항목은 다시 이벤트로 쪼개집니다.
- 유입: install, first_open, landing_view, signup_started
- 활성화: onboarding_completed, tutorial_completed
- 핵심행동: core_action_started / core_action_completed
- 잔존: app_open(또는 core_action) on D1/D7/D30
이 과정을 거치면 “우리는 이벤트를 몇 개 찍어야 하는가”가 감이 아니라 논리로 결정됩니다. 이벤트는 늘리면 늘릴수록 운영·QA·데이터 품질 비용이 증가하므로, 지표 트리에서 의사결정에 직접 쓰는 지표를 만들기 위한 최소 이벤트로 시작하는 게 좋습니다.
이벤트 설계 원칙: 이벤트는 ‘행동’, 프로퍼티는 ‘상태’
좋은 택소노미의 첫 번째 원칙은 역할 분리입니다.
- 이벤트(Event): 사용자가 무엇을 했는가(행동, verb)
- 프로퍼티(Property): 그 행동이 어떤 맥락에서 발생했는가(상태/컨텍스트)
예를 들어 “상품 상세 페이지”는 이벤트가 아니라 화면(view) 이벤트가 될 수 있고, “어떤 상품”은 프로퍼티로 들어가야 합니다. - event: product_view
- properties: product_id, category, price, currency, position, referrer
이 원칙이 무너지면 이벤트가 폭발적으로 늘고(상품별/카테고리별 이벤트), 유지보수가 불가능해집니다.
이벤트 네이밍 규칙을 먼저 고정한다
네이밍은 취향 문제가 아니라 데이터의 장기 비용을 결정하는 규칙입니다. 팀 전체가 동일한 규칙을 쓰게 만드는 게 핵심입니다. 실무에서 가장 관리가 쉬운 형태는 아래입니다.
- 이벤트명: 동사_목적어 (snake_case)
예: signup_started, signup_completed, product_viewed, purchase_completed - “완료” 이벤트는 반드시 completed로 끝내고, 시작 이벤트는 started로 끝낸다
예: checkout_started / checkout_completed - 화면/페이지는 view 계열로 통일
예: screen_viewed 또는 page_viewed 중 하나로 고정 - 클릭은 남발하지 말고, 의사결정에 필요한 클릭만 정의
예: cta_clicked는 OK, button_clicked는 보통 과도함
네이밍을 고정하면 분석 쿼리/대시보드/온보딩이 크게 쉬워집니다.
프로퍼티 스키마: 공통 속성과 도메인 속성을 분리한다
프로퍼티는 크게 세 종류로 나눠 관리하면 깔끔해집니다.
- 공통(Common) 프로퍼티: 모든 이벤트에 공통으로 붙는 분석 필수값
- user_id(또는 anonymous_id), device_id
- timestamp(클라이언트 발생시각 + 서버 수신시각)
- platform(iOS/Android/Web), app_version, os_version
- locale, country, timezone
- session_id(가능하면)
- traffic_source(가능하면 UTM/캠페인 정보)
- 컨텍스트(Context) 프로퍼티: “왜/어디서” 발생했는지
- screen_name, referrer_screen
- entry_point, placement, experiment_variant(A/B)
- attribution(가능한 범위에서)
- 도메인(Domain) 프로퍼티: 제품의 엔티티/비즈니스 로직
- 커머스: product_id, category, price, currency, coupon, payment_method
- 구독: plan_id, trial, billing_period, renewal
- 콘텐츠: content_id, content_type, creator_id, duration
이 분리를 해두면 공통 품질(QA)과 도메인 확장을 동시에 잡을 수 있습니다.
이벤트 딕셔너리(Event Dictionary)는 “표준 문서”가 아니라 “검증 가능한 스펙”이어야 한다
이벤트 딕셔너리는 단순 설명문이 아니라, 개발/데이터/마케팅이 합의한 스펙입니다. 최소한 아래 필드를 포함하세요.
- event_name: signup_completed
- description: 회원가입이 성공적으로 완료되었을 때 발생
- trigger: 서버에서 계정 생성 성공 응답을 받은 직후(클라이언트) 또는 계정 생성 트랜잭션 커밋 시점(서버)
- required_properties: user_id, method, country, app_version
- optional_properties: referral_code, campaign_id
- property_definitions: method(email/kakao/apple/…) 같은 허용값, 타입(string/int/bool), null 허용 여부
- dedup_rule: 동일 user_id + 동일 request_id는 1회만 인정
- owner: 책임자(제품/데이터)
- consumers: 이 이벤트를 쓰는 지표/대시보드 목록
- privacy_classification: PII 포함 여부, 보관 정책, 마스킹 규칙
이 정도까지 적혀 있어야 “누가 맞냐” 논쟁이 줄고, 데이터 이슈가 나면 원인 추적이 빨라집니다.
클라이언트 vs 서버 이벤트 경계를 명확히 한다
가치가 걸린 이벤트(결제, 구독, 보상 지급, 거래 성사)는 가급적 서버 기준이 신뢰도가 높습니다. 반대로 UI 상호작용(화면 노출, 버튼 클릭)은 클라이언트가 자연스럽습니다. 중요한 건 한 이벤트가 양쪽에서 중복 발행되거나, 성공/실패 기준이 다르게 정의되는 일을 막는 것입니다.
실무 권장:
- purchase_completed, subscription_activated 같은 이벤트는 서버를 소스 오브 트루스로 두고
- 클라이언트에는 purchase_started, payment_method_selected 같은 과정 이벤트를 둔다
이렇게 하면 퍼널 분석과 매출 정합성을 동시에 잡습니다.
실험/퍼널/리텐션이 바로 돌아가도록 “핵심 이벤트 세트”를 먼저 만든다
처음부터 완벽한 전체 택소노미를 만들려다 실패하는 경우가 많습니다. 대신 2~3주 안에 아래가 가능한 최소 세트를 먼저 정의하세요.
- 유입: first_open 또는 landing_view
- 활성화: onboarding_completed
- 핵심행동: core_action_completed
- 수익: purchase_completed(또는 subscription_started/renewed)
- 리텐션 기준: app_open 또는 core_action_completed
이 최소 세트로 대시보드가 돌아가기 시작하면, 그 다음 확장은 지표 트리의 병목(전환이 낮은 단계)부터 추가 이벤트를 설계하는 방식이 효율적입니다.
거버넌스: “추가/변경/폐기” 절차가 없으면 택소노미는 무너진다
이벤트가 늘어날수록 가장 큰 리스크는 스키마 드리프트(정의가 조금씩 변함)입니다. 운영 규칙을 간단히라도 문서로 박아두세요.
- 신규 이벤트는 반드시 PR/리뷰를 거친다(데이터 오너 승인)
- 프로퍼티 추가는 가능하되, 타입 변경/의미 변경은 버전업 원칙 적용
- 폐기(deprecate) 이벤트는 일정 기간 병행 후 제거, 대체 이벤트 명시
- 스키마 검증(타입/필수값 누락) 실패율을 모니터링
이 절차가 없으면 몇 달 뒤 “같은 지표를 서로 다른 정의로 계산”하는 상황이 반드시 옵니다.
마무리: 좋은 택소노미의 기준은 ‘깔끔함’이 아니라 ‘의사결정 비용 절감’
프로덕트 이벤트 택소노미의 목적은 이벤트를 많이 찍는 것이 아니라, 팀이 같은 수치로 같은 결론을 내리게 만드는 것입니다. 북극성 지표를 이벤트로 계산 가능하게 정의하고, 지표 트리로 필요한 이벤트를 역산한 뒤, 네이밍/프로퍼티/딕셔너리/거버넌스까지 스펙으로 고정하면, 분석 속도뿐 아니라 제품 개발과 실험 속도도 같이 올라갑니다.