계측(Measure) 최소 세트
MVP 의사결정에 필요한 이벤트 8~12개, GTM 신호, 퍼널·오류·리텐션 대시보드를 최소 비용으로 설계하고 해석하는 방법과 팀 운영 기준을 정리합니다.
핵심 요약
- 유입·온보딩·핵심 행동·결과·수익 의사·GTM 신호를 아우르는 이벤트 8~12개로 최소 계측 세트를 만듭니다.
result_error처럼 실패 이벤트에는 사유 코드를 남겨야 원인을 분리해 개선 속도를 높일 수 있습니다.- 퍼널·오류·리텐션·GTM 신호 4종 대시보드와 복사용 SQL로 의사결정 근거를 빠르게 뽑습니다.
- 신호는 같은 무게로 보지 말고 페이지 조회(낮음)부터 결제·반복 사용(매우 높음)까지 강도로 가중합니다.
- AI가 분류한 반론은
classified_by: ai, 사람이 확인한 것은verified_by: human으로 구분해 기록합니다.
데이터가 없으면 MVP는 "느린 개발"이 됩니다.
여기서는 최소 계측 세트와 GTM 신호만으로 의사결정을 끌어내는 방법을 정리합니다.
이벤트 최소 세트(8~12개)
| 분류 | 이벤트 예시 |
|---|---|
| 유입 | page_view, cta_click |
| 가입/온보딩 | sign_up, onboarding_complete |
| 핵심 행동 | core_input_start, core_input_submit |
| 결과 | result_view, result_error(사유 코드 포함) |
| 가치 프록시 | save, share, export |
| 수익 의사 | pricing_view, checkout_start, purchase |
| GTM 신호 | demo_request, reply_received, objection_capture |
| 품질 피드백 | result_feedback, trust_warning_view |
실패 이벤트는 꼭 넣기
result_error처럼 실패 이벤트에 사유 코드를 남겨야 개선이 빨라집니다. 실패를 "한 종류"로
기록하면 원인을 찾을 수 없습니다.
이벤트 네이밍 규칙(추천)
- 동사+목적어:
sign_up,result_view,share_link_create - 플랫폼/화면은 속성으로:
page,source,variant - 하나의 이벤트는 하나의 의미만: "view+click" 같이 섞지 않기
이벤트 스펙 표 예시
이벤트를 구체적으로 설계할 때는 아래 형식으로 정리합니다:
| 이벤트 | 정의 | 발생 위치 | 필수 속성 |
|---|---|---|---|
page_view | 페이지 로드 완료 | 모든 페이지 | page, source, referrer |
sign_up | 가입 완료 | 가입 폼 | method (email/google/kakao) |
core_input_submit | 핵심 입력 제출 | 입력 화면 | input_type, file_size |
result_view | 결과 화면 조회 | 결과 화면 | latency_ms, result_quality |
result_error | 결과 생성 실패 | 결과 화면 | error_code, error_message |
share_link_create | 공유 링크 생성 | 결과 화면 | share_type (link/email/kakao) |
pricing_view | 가격 페이지 조회 | 가격 페이지 | variant, source |
checkout_start | 결제 프로세스 시작 | 결제 화면 | plan, price |
demo_request | 데모/상담 요청 | CTA/폼 | source, segment, message_variant |
objection_capture | 구매/사용 반론 기록 | 인터뷰/폼 | objection_type, severity |
최소 대시보드 3종
- 퍼널: 방문 → 가입 → 첫 결과 → 저장/공유
- 오류: 실패 사유별 발생 빈도 / 사용자 영향
- 리텐션: D1/D7 재방문 또는 핵심 행동 재수행
- GTM 신호: 채널/메시지별 리드, 데모 요청, 가격 문의, 반론 유형
신호 품질 점수
초기 MVP에서는 숫자가 작으니 모든 신호를 같은 무게로 보지 않습니다.
| 신호 | 강도 | 해석 |
|---|---|---|
| 페이지 조회 | 낮음 | 타겟/문제 관심의 약한 신호 |
| CTA 클릭 | 낮음~중간 | 메시지 반응은 있으나 실제 의도는 불명확 |
| 이메일/대기자 등록 | 중간 | 후속 연락 가능, 세그먼트 확인 필요 |
| 데모/상담 요청 | 높음 | 문제 강도와 구매 맥락을 확인할 기회 |
| 결제 시작/예약금 | 매우 높음 | 가격 의사의 강한 신호 |
| 반복 사용/공유 | 매우 높음 | 가치 경험과 전파 가능성의 강한 신호 |
퍼널 분석 SQL 예시
실험 판정에 도움이 되는 로그 설계
- 실험 변수(variant, pricing_tier, channel)는 속성으로 남긴다
- 사용자 세그먼트(역할/업종/팀 규모)는 가능한 한 빨리 수집하되, "긴 설문"으로 전환을 깨지 않는다(필요하면 2단계로)
- GTM 접촉은
channel,message_variant,reply_type,objection_type으로 남긴다 - AI가 분류한 반론은
classified_by: ai, 사람이 확인한 반론은verified_by: human으로 구분한다
도구 선택 가이드
| 규모 | 추천 도구 | 이유 |
|---|---|---|
| MVP 초기 (0~100명) | Mixpanel Free / PostHog | 무료, 퍼널/리텐션 기본 제공 |
| 성장기 (100~1,000명) | Amplitude / PostHog | 코호트 분석, A/B 테스트 연동 |
| 자체 구축 | Plausible + SQL | 개인정보 최소화, 커스텀 분석 |
도구보다 설계가 먼저
어떤 도구를 쓰든 이벤트 설계(이름/속성/정의)가 일관되면 나중에 도구를 바꿔도 데이터를 유지할 수 있습니다. 이벤트 스펙 문서를 먼저 만들고, 도구는 나중에 고르세요.
Claude Code 활용 체크리스트(분석)
- 이벤트 스펙 표(이벤트/속성/정의/발생 위치)를 만들어달라
- 퍼널 병목을 기준으로 다음 실험 3개를 제안받기
- 인터뷰 요약을 정량 데이터와 연결해 "왜" 가설을 세우기
- 코호트별 리텐션 SQL을 사용 중인 DB 스키마에 맞게 작성해달라
- 메시지/채널/가격별 GTM 신호 대시보드를 설계해달라
- AI 분류 결과와 사람이 확인한 근거를 분리하는 이벤트 속성을 제안받기
참고 자료
- Dave McClure, Pirate Metrics (AARRR) — Acquisition, Activation, Retention, Revenue, Referral 프레임워크. 퍼널 설계의 표준 모델입니다.
- Kerry Rodden et al., Google HEART Framework — Happiness, Engagement, Adoption, Retention, Task Success. 사용자 경험 계측의 체계적 접근법.
- Amplitude, Mastering Retention — 코호트 분석과 리텐션 최적화의 실전 가이드.
- BCG, Product Teams Can Make AI Sales Agents Smarter — 세일즈/제품 신호를 제품팀의 학습 루프로 연결하는 관점.