Statsig 입문 5편 — Product Analytics 깊이 · 6 차트 · Funnel · Retention

이 글은 Statsig 입문에서 운영까지 시리즈 5편이에요. 1편 종합 · 2편 SDK Quickstart · 3편 Feature Flags 깊이 · 4편 Experiments 깊이 까지 기능 출시 + 통계적 검증 의 두 축을 봤다면, 이번 5편은 세 번째 축 — Product Analytics. 사용자가 실제로 어떻게 쓰는가 의 깊이.

왜 Product Analytics 가 필요한가

Feature Gate · Experiment 만으로는 답이 안 나오는 질문이 따로 있어요. 예를 들면 gate 켰을 때 결제 funnel 의 어느 step 에서 효과가 났는지, 실험 결과 숫자 너머의 진짜 사용 흐름, 재방문 사용자 vs 새 가입 의 행동 차이, 기능 도입 후 retention 변화 — 이런 질문들이에요. 이게 Product Analytics 가 답하는 자리. 1편의 4 축 중 가장 많은 시간을 쏟는 영역.

처음 만나면 헷갈리는 이유 — 차트 종류가 6개 인데 어느 차트가 어느 질문에 답하는지 가 안 보여요. 해결법 = 각 차트의 대표 질문 한 줄 잡기.

Event 모델 — 데이터 원천

모든 Product Analytics 의 원자 단위 = Event.

statsig.logEvent(user, "checkout_completed", "1500", {
  currency: "KRW",
  items_count: 3,
  payment_method: "card"
});

이 한 줄이 모든 차트의 데이터 원천. Funnel (단계별 전환) · Retention (재방문) · Cohort (가입 시점 그룹) 가 모두 event 들의 가공.

Event 의 4 구성 요소

여기서 시험 함정이 하나 있어요 — event 설계가 끝까지 영향. 처음 박은 eventName · property 가 미래의 모든 분석을 결정. 첫 박을 때 잘 박기 가 운영의 핵심.

Event 설계 원칙

원칙 1: 동사 + 명사

✓ checkout_completed   (결제 완료)
✓ item_added_to_cart    (장바구니 추가)
✓ video_played           (동영상 재생)
✗ checkout                (모호 — 시작? 완료? 실패?)
✗ user_action             (너무 일반)

동사 = 무엇이 일어났는지, 명사 = 무엇에 대해. 시제도 과거형 (completed) 권장.

원칙 2: 일관된 naming convention

snake_case 통일:
  checkout_completed
  item_added_to_cart

또는 camelCase 통일:
  checkoutCompleted
  itemAddedToCart

한 코드베이스 내 혼용 금지. 2편의 함정 4 — checkoutCompleted 와 checkout_completed 가 두 event 로 갈림.

원칙 3: Cardinality 통제

Cardinality = 한 property 의 unique 값 개수.

✓ payment_method: "card" / "kakao_pay" / "naver_pay"   (3~5 종)
✓ tier: "free" / "premium" / "enterprise"               (3 종)
✗ user_id: "user-123", "user-456", ... (수백만 종)
✗ session_id: 매번 새 UUID                                (무한)

High cardinality property = 메모리·쿼리 폭증 + dashboard 사용 불가. userID 는 property 가 아닌 user identifier, session_id 는 차트 dimension 아님.

→ property 는 분류 가능한 카테고리 만.

원칙 4: Property 표준화

// 모든 결제 event 가 같은 property 구조
statsig.logEvent(user, "checkout_started", null, {
  cart_value: 50000,
  items_count: 3,
  currency: "KRW"
});

statsig.logEvent(user, "checkout_completed", "50000", {
  cart_value: 50000,
  items_count: 3,
  currency: "KRW",
  payment_method: "card"
});

같은 funnel 안의 event = 공통 property + 단계별 추가 property. funnel 분석이 깔끔.

원칙 5: value vs property

✓ logEvent(user, "purchase", "50000", {...})
  → value = 결제 금액 (집계 가능한 숫자)

✓ logEvent(user, "video_played", "120", {...})
  → value = 재생 시간 (초)

✗ logEvent(user, "purchase", "card", {...})
  → value 에 categorical 박지 X — property 로!

value = 정량 (sum · avg 가능), property = 정성 (분류). 헷갈리면 "이걸 sum 할 의미가 있나?" 자문.

Metric vs Event — 두 단어의 정확한 차이

여기서 처음 헷갈리는 자리 하나 — Event 와 Metric 이 같은 거 아닌가?

Event = 단일 발생

event 'checkout_completed' = 사용자가 결제 완료한 *1 회 사건*

raw data. 언제 · 누가 · 어떤 property 로 발생.

Metric = Event 의 집계 정의

Metric "Daily Conversions" = COUNT(checkout_completed) / DAU
Metric "Total Revenue" = SUM(checkout_completed.value)
Metric "Average Order Value" = AVG(checkout_completed.value)

Event 들의 집계 + 비즈니스 의미 부여.

→ Experiment 의 Primary Metric (4편) = event 가공해서 만든 metric.

Metric 종류

→ 이게 6 차트의 input 종류.

Metrics Explorer 의 6 차트 — 깊이 풀이

차트 1: Metric Drilldown — 한 메트릭 깊이 보기

답하는 질문 — "이 메트릭이 시간 따라 어떻게 변하는가? segment 별로 차이가 있는가?"

비유 — 매출 그래프를 날짜 · 국가 · 디바이스 별로 여러 각도 에서 보는 도구.

대표 사용:

• 일별 매출 trend
• 국가별 결제 전환율 비교
• iOS vs Android 평균 주문 금액
• 시간대별 활성 사용자

옵션:

• Date range — 7일 · 30일 · 90일 · custom
• Granularity — 시간 · 일 · 주 · 월
• Group by — country · device · custom property
• Filter — 특정 사용자 segment

차트 2: Funnels — 단계별 전환율

답하는 질문 — "사용자가 어느 단계에서 이탈 하는가? 전체 funnel 의 bottleneck (병목) 어디?"

비유 — 깔때기 위에 사용자 100명 부으면 단계마다 빠지고 마지막엔 몇 명 남는가.

대표 사용:

Funnel "결제 완료까지":
  1. landing_page_viewed     100,000  (100%)
  2. product_viewed           75,000   (75%)
  3. cart_added               25,000   (25%)   ← 큰 drop !
  4. checkout_started         15,000   (15%)
  5. checkout_completed       12,000   (12%)

3단계 cart_added 의 drop 이 큼 = product view → cart add 사이 의 UX 검토 필요.

Funnel 설계 옵션:

• Step 간 시간 제한 — 24시간 안 N 단계 모두 통과 (오래 걸린 사용자 제외)
• Step 간 순서 — strict (정확한 순서) vs loose (어떤 순서든)
• First-touch vs Recent-touch — 어느 시점 user 기준

차트 3: Retention — 재방문율 곡선

답하는 질문 — "가입한 사용자가 N일 후에도 돌아오는가? retention curve 의 모양 이 어떻게 변하는가?"

비유 — 6월 1일 가입한 100명 중 6월 2일 · 3일 · 7일 · 30일 에 다시 온 사람 비율.

대표 차트 모양 = 시간에 따라 감소하는 곡선. 좋은 제품 = 완만한 감소 + 일정 plateau 도달.

Retention 종류:

대부분 시작 = D1 · D7 · D30 Retention. D7 Retention 이 제품의 long-term health 의 핵심 지표.

Cohort 분석 (Cohort = 같은 시점에 가입/유입된 사용자 묶음):

• 주별 가입 cohort (week-of-signup)
• 각 cohort 의 retention curve 비교
• 최근 cohort 가 더 높은 retention = 제품 개선 효과

차트 4: Distribution — 분포 분석

답하는 질문 — "이 값이 어떻게 분포 되어 있는가? 평균만으로 안 보이는 long tail 이 있는가?"

비유 — 평균 주문 금액 50,000원 의 함정. 대부분 10,000원 + 소수 1,000,000원 일 수도. histogram 으로 진짜 분포 확인.

대표 사용:

• 사용자별 주문 횟수 분포 (1회 사용자 vs 매월 사용자)
• 결제 금액 분포 (소액 vs 고액)
• 페이지 체류시간 분포
• 세션 길이 분포

중요한 통찰 — 평균 (mean) vs 중앙값 (median) vs P90 · P99 비교. long tail 비즈니스 (e-commerce · 광고) 는 Distribution 차트 가 필수.

차트 5: User Journeys — Sankey 다이어그램

답하는 질문 — "사용자가 실제로 거치는 경로 가 어떻게 되는가? 예상한 흐름과 다른가?"

비유 — funnel 이 고정된 step 순서 라면 User Journey 는 실제 자유로운 흐름. 어디서 와서 어디로 가는지 의 양방향 traffic.

대표 표시 방식 = Sankey 다이어그램 (흐름의 두께로 양을 보여주는 띠 그림) — 시작 event 에서 다음 event 들 로 두께가 비율 인 흐름.

landing_page → (40%) product_viewed → (60%) cart_added → (50%) checkout_started
              ↓ (35%) search_started → ...
              ↓ (25%) about_viewed → ...

대표 사용:

• 첫 방문 후 N step 의 흐름 분석
• 예상치 못한 path 발견
• 주요 entry point 별 사용자 행동

차트 6: Lifecycle — 사용자 상태 전환

답하는 질문 — "사용자가 활성 → 비활성 → 이탈 어떻게 흐르는가? churn rate 어디서 발생?"

비유 — 회사 사원 재직 → 휴직 → 퇴직 의 전환 비율.

Lifecycle 의 사용자 상태:

중요 metric:

• Reactivation rate — Dormant → Active 전환율
• Churn rate — Active → Churned 비율
• Net change — 새 가입 - 이탈

대표 사용 = 제품의 health 평가. new 만 늘고 churn 도 늘면 net 0 = 제자리.

차트 별 핵심 한 줄

→ 각 차트 = 다른 도메인 질문. 한 dashboard 에 여러 차트 묶어 종합 view.

Dashboards — 통합 view

Dashboard 는 중요한 insight 를 공유 하는 좋은 방법. 차트 + 텍스트 + 단일값 + Feature Gate/실험 snapshot 까지 묶음. — 공식 docs

Dashboard 의 구성 요소

→ 데이터 + 운영 상태 가 한 화면에. 의사결정 회의의 표준 자료.

운영 기능

• Export to PDF — 정적 버전 저장 (보고서 첨부)
• Subscriptions — email/Slack 으로 정기 snapshot 전송 (daily · weekly)
• Duplicate — 기존 dashboard 복제 + 빠른 새 버전
• Auto Refresh — 백그라운드 쿼리 + 캐시 → 즉시 표시
• Filter — 전역 필터 (모든 widget 동시 적용)
• Date range — 기본값 · 임시 변경

Dashboard 의 위계 패턴

대시보드 1: "Executive KPI" (경영진용)
  - 일/주/월 매출 · 전환율 single value
  - 핵심 metric drilldown
  - Top 3 진행 중 실험 snapshot

대시보드 2: "Product Health" (PM 용)
  - D1/D7/D30 retention curve
  - 핵심 funnel + 단계별 drop
  - User journey 의 주요 path

대시보드 3: "Feature Rollouts" (엔지니어링용)
  - 활성 Feature Gate 들 + rollout %
  - 진행 중 실험 + p-value
  - 메트릭 alert

각 역할별 맞춤 dashboard + 주기적 review.

Feature Gate · Experiment · Analytics 통합 view

Statsig 의 차별점 — 세 축이 한 데이터 흐름.

통합 query 의 예

질문 1: "새 결제 flow gate 켠 사용자의 결제 funnel 변화?"

1. Feature Gate "new_checkout" Pass 사용자 vs Fail 사용자 segment
2. 각 segment 의 결제 funnel 차트 비교
3. 단계별 drop rate 차이

질문 2: "실험의 primary metric 외 다른 funnel 영향?"

1. Experiment "button_color" 의 control vs treatment 사용자
2. Retention curve · Lifecycle 분포 비교
3. 의도하지 않은 side effect 발견

질문 3: "Holdout 5% vs 나머지 의 long-term retention 차이?" (Holdout = 모든 실험에서 제외해 둔 기준 그룹, 3편 참고)

1. Holdout segment (3편) 의 D30 retention
2. Non-holdout 의 D30 retention
3. 1년간 모든 새 기능의 누적 효과 측정

→ 별도 도구 (Optimizely + Mixpanel) 로는 stitching 부담 큰 query 가 Statsig 에서는 자연스럽게 한 클릭.

자주 만나는 사고 — Product Analytics 운영

사고 1: Event name 혼용

원인 — checkoutCompleted 와 checkout_completed 가 프론트 다른 위치 · 다른 SDK 에서 혼용.

해결 — 2편의 event name 상수 패턴. 한 코드베이스 = 한 convention.

사고 2: Property cardinality 폭증

원인 — user_id · session_id · request_id 를 property 로 박음.

해결 — high cardinality 값 = property 아닌 dimension 만. user 단위 분석은 user identifier 따로.

사고 3: Funnel step time window 너무 짧음

원인 — 1시간 안 5 step 통과 조건 → 대부분 사용자는 며칠 걸려서 funnel 통과 X.

해결 — 사용자의 실제 행동 패턴 에 맞는 time window (24시간 · 7일).

사고 4: Retention 의 활동 정의 불명

원인 — "D7 retention" 이 어떤 event 기준 인지 모호.

해결 — 명시적 활동 event 정의 (session_started · app_opened 등). dashboard 에 명시.

사고 5: Distribution 무시 → 평균 함정

원인 — 평균 주문 금액 + 7% 증가 라 ship → 실제는 상위 5% 의 일시 증가, 나머지 변화 없음.

해결 — Distribution 차트 로 median · P90 · P99 함께 확인.

사고 6: User Journey 너무 깊게

원인 — 10+ step 의 흐름 분석 → 거의 모든 사용자 unique path → 통찰 X.

해결 — 3~5 step 으로 압축. 주요 entry / exit point 우선.

사고 7: Dashboard 의 outdated 데이터

원인 — 자동 refresh 미설정 → 보고서에 3일 전 데이터.

해결 — Auto Refresh 설정 (daily · hourly).

사고 8: Event 추가 시 기존 분석 깨짐

원인 — purchase event 의 property 스키마 변경 (예: currency 추가) → 과거 데이터 호환 X.

해결 — property 추가는 OK, 변경/제거는 새 event. 또는 event versioning (purchase_v2).

운영 권장 패턴

Pattern 1: Event Naming Spec 문서

# Event Naming Convention

## 규칙
- snake_case
- 동사_명사 형식
- 과거형 (completed, viewed, clicked)
- 단복수 일치 (item_*, items_*)

## 표준 도메인 event
### Auth
- `signup_started`
- `signup_completed`
- `login_completed`
- `logout`

### Commerce
- `product_viewed`
- `item_added_to_cart`
- `cart_viewed`
- `checkout_started`
- `checkout_completed`
- `refund_requested`

### Engagement
- `session_started`
- `notification_clicked`
- `feature_used` (with feature_name property)

코드베이스의 문서로 박아둠 + 새 event 박을 때 review.

Pattern 2: Event 정의 상수화 + lint

// types/events.ts
export const EVENT = {
  SIGNUP_COMPLETED: "signup_completed",
  CHECKOUT_COMPLETED: "checkout_completed",
  // ...
} as const;

export type EventName = typeof EVENT[keyof typeof EVENT];

// 사용
statsig.logEvent(user, EVENT.CHECKOUT_COMPLETED, value, props);

오타 = 컴파일 에러. runtime 에 새 event 박는 것 = lint 경고.

Pattern 3: Event 추적 wrapper

class Analytics {
  trackCheckoutCompleted(user: User, value: number, items: number, method: string) {
    statsig.logEvent(user, EVENT.CHECKOUT_COMPLETED, String(value), {
      cart_value: value,
      items_count: items,
      payment_method: method
    });
  }

  trackProductViewed(user: User, productId: string, category: string) {
    statsig.logEvent(user, EVENT.PRODUCT_VIEWED, null, {
      product_id: productId,
      category: category
    });
  }
}

event name + property 구조 가 한 곳 정의. 호출자는 typed 메서드 만. 일관성 자동 보장.

Pattern 4: Dashboard 위계

Tier 1 (Executive · Weekly review):
  - 주간 매출 · 신규 가입 · DAU
  - Top 진행 실험 snapshot

Tier 2 (Product · Daily check):
  - 핵심 funnel + 단계별 drop
  - D7/D30 retention curve
  - 활성 Feature Gate 상태

Tier 3 (Engineering · 즉시 확인):
  - 메트릭 alert
  - 에러 event 추적
  - 인프라 성능

각 청중별 맞춤 dashboard + 주기적 review.

Pattern 5: Subscription 자동화

Daily Email Subscription (07:00 AM):
  - 어제 매출 · 신규 가입 · 활성 사용자 single values
  - 핵심 funnel chart

Weekly Slack Subscription (월요일):
  - 주간 핵심 metric 변화
  - 종료된 실험 결과
  - 새 시작 실험 안내

수동 dashboard check 없이 자동 받음. 문제 발생 시 즉시 인지.

Pattern 6: Cohort 정기 분석

매주 월요일 자동:
  - 지난 주 가입 cohort 의 D1 retention 측정
  - 4주 전 cohort 의 D30 retention 측정
  - 최근 10 cohort 의 retention curve 비교

cohort 별 retention 추세 = 제품 개선의 핵심 long-term 지표.

시험 직전 한 번 더 — Product Analytics 깊이 함정 압축 노트

• Product Analytics = 1편의 4 축 중 사용자 행동 분석
• Event = 단일 발생 (raw data)
• Metric = event 의 집계 정의 (count · sum · ratio · funnel · retention)
• Experiment 의 Primary Metric (4편) = metric
• Event 4 구성 = eventName · value · metadata · timestamp
• Event 설계 원칙 5종:
• 동사_명사 (checkout_completed)
• naming convention 통일 (snake_case)
• Cardinality 통제 — user_id · session_id 는 property X
• Property 표준화 (funnel 안 event 공통 property)
• value (정량 sum) vs property (정성 분류)
• Metric Type 7종 = Count · Sum · Mean · Ratio · Funnel · Retention · Time to Event
• 6 차트 = Metric Drilldown · Funnels · Retention · Distribution · User Journeys · Lifecycle
• Metric Drilldown = 한 메트릭의 시간/segment 변화 (group by · filter)
• Funnels = 단계별 이탈 (bottleneck 발견)
• Funnel 옵션 = step 간 시간 제한 · 순서 strict/loose · first/recent touch
• Retention = N일 후 재방문 곡선
• Retention 종류 = Day N · Rolling · Bracket
• D7 retention = long-term health 핵심
• Cohort 분석 = 주별 가입 그룹 비교
• Distribution = histogram · long tail · 평균 함정 회피
• mean vs median vs P90/P99 비교
• User Journeys = Sankey · 자유 경로 흐름
• Lifecycle = 사용자 상태 전환 (New · Active · Returning · Dormant · Churned)
• Reactivation rate · Churn rate · Net change
• Dashboards = 차트 + 텍스트 + 단일값 + Gate/실험 snapshot
• 기능 — Export PDF · Subscriptions (email/Slack) · Duplicate · Auto Refresh · Filter
• 위계 패턴 — Tier 1 (Executive) · Tier 2 (Product) · Tier 3 (Engineering)
• Feature Gate · Experiment · Analytics 통합 view = Statsig 차별점
• gate Pass/Fail 별 funnel 비교 · experiment side effect · Holdout long-term retention
• 함정 — Event name 혼용 → 상수화 + lint
• 함정 — Cardinality 폭증 → high cardinality 는 dimension X
• 함정 — Funnel time window 너무 짧음
• 함정 — Retention 활동 정의 불명 → 명시적 활동 event
• 함정 — Distribution 무시 → 평균만 보면 함정
• 함정 — User Journey 너무 깊게 → 3~5 step
• 함정 — Dashboard outdated → Auto Refresh
• 함정 — Event property 변경 → versioning (event_v2)
• 패턴 — Event Naming Spec 문서
• 패턴 — TypeScript event 상수 + typed wrapper
• 패턴 — Analytics 추적 클래스 (event name + property 한 곳 정의)
• 패턴 — Dashboard 위계 (역할별 맞춤)
• 패턴 — Subscription 자동화 (daily email · weekly Slack)
• 패턴 — Cohort 정기 분석 (주별 retention 추세)

공식 문서: Product Analytics Overview · Dashboards 에서 원문을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 1편 — 통합 플랫폼 종합 (Feature Flag · 실험 · 분석 · Infra)
• 2편 — SDK Quickstart · 30분 첫 Feature Gate
• 3편 — Feature Flags 깊이 · Targeting · Rollout · Holdout
• 4편 — Experiments 깊이 · RCT · Allocation · 통계 함정

다음 글:

• 6편 — Warehouse Native 깊이 · Snowflake · BigQuery · dbt 결합
• 7편 — CDP · Slack · MCP · Webhook 운영 통합
• 8편 — Session Replay · Web Analytics · Infra Analytics
• 9편 — 시리즈 마무리 · 도입 결정 · 경쟁 도구 · 학습 경로