Product Analytics & Tracking Plan

분류: Layer 13 - Product Engineering & Growth Systems

핵심 질문

Product Engineer는 기능이 배포된 뒤 “잘 됐나요?”라는 질문에 대답할 수 있어야 한다. 이때 필요한 것은 클릭 이벤트 몇 개가 아니라, 제품 질문에서 출발해 이벤트 이름, 속성, 소유자, QA 기준까지 연결된 tracking plan이다.

1. 한 줄 정의

Product Analytics & Tracking Plan은 사용자 행동을 신뢰 가능한 이벤트와 속성으로 모델링하고, 제품 의사결정에 필요한 지표를 재현 가능하게 만드는 역량이다.

2. 왜 중요한가

프론트엔드 개발자는 버튼 클릭, 페이지 진입, 폼 제출 같은 이벤트를 자연스럽게 본다. 하지만 Product Engineer에게 이벤트는 UI 부수 효과가 아니다. 이벤트는 제품 질문에 답하기 위한 데이터 계약이다.

예를 들어 “온보딩을 개선했다”는 말은 다음 질문으로 바뀌어야 한다.

어떤 사용자 segment의 온보딩인가?
시작 이벤트와 완료 이벤트는 무엇인가?
완료까지 걸린 시간은 어떻게 계산하는가?
실패나 이탈은 어느 단계에서 관찰하는가?
실험이나 rollout에 따라 이벤트 속성이 달라지는가?
개인정보가 이벤트 property에 들어가지는 않는가?

이 질문에 답하지 못하면 대시보드 숫자는 있어도 제품 판단은 어렵다.

2.5. 선행 방식의 한계 — 왜 Tracking Plan이 등장했는가

운영 로그와 analytics 이벤트를 같은 감각으로 다루면 초반에는 빠르다. “필요해 보이는 곳에 로그를 찍고, 나중에 쿼리하면 된다”는 방식이다. 하지만 제품 이벤트는 서버 로그와 다르게 사용자의 행동, UI 맥락, 실험 노출, 개인정보 경계를 함께 담는다. 이벤트 이름이 팀마다 다르고 속성이 자주 바뀌면 funnel과 cohort는 서로 다른 사실을 말하기 시작한다.

Product analytics 도구들은 이런 문제를 줄이기 위해 event-level 행동 추적과 tracking plan을 강조한다. Amplitude는 product analytics를 사용자의 행동, engagement, drop-off, retention driver를 이해하는 활동으로 설명한다. Segment의 tracking plan 문서는 business metric에서 출발해 user action을 event로 매핑하고, 실제 수집 이벤트가 spec과 맞는지 검증하는 흐름을 제안한다.

따라서 tracking plan의 등장은 “데이터를 많이 쌓으면 나중에 알 수 있다”는 방식의 한계에서 나온다. Product Engineer는 instrumentation을 기능 구현의 마지막 줄이 아니라, 제품 가설을 검증하는 계약으로 다뤄야 한다.

3. 제품 질문에서 이벤트로 내려가기

이벤트 설계는 코드 위치에서 시작하지 않는다. 먼저 제품 질문을 작게 만든다.

제품 질문	필요한 행동 신호	이벤트 후보
사용자가 첫 가치를 경험했는가	activation 행동 완료	`project_created`, `api_call_succeeded`
사용자가 핵심 흐름에서 어디서 이탈하는가	단계별 시작·실패·완료	`invite_modal_opened`, `invite_created`, `invite_accepted`
새 UX가 더 좋은가	실험군별 전환과 guardrail	`onboarding_completed`, `error_seen`
유료 기능이 실제로 쓰이는가	entitlement 기반 기능 사용	`premium_export_completed`

좋은 이벤트 이름은 화면 구조보다 사용자의 행동을 표현한다. button_clicked보다 invite_created가 낫고, modal_submit보다 workspace_created가 낫다. 화면 이름은 property로 남길 수 있지만, 핵심 event는 제품 행동이어야 한다.

4. Event Taxonomy 기본 구조

Event taxonomy는 이벤트 이름과 property의 규칙이다. 다음 규칙을 먼저 정하면 이후 분석 품질이 크게 좋아진다.

Event Taxonomy 설계 규칙

행동 중심 이름

UI 컴포넌트가 아니라 사용자의 제품 행동을 이름으로 둔다.

좋음: invite_created / 약함: submit_button_clicked

일관된 시제

성공적으로 끝난 행동은 과거형, 노출은 viewed/opened처럼 구분한다.

예: checkout_started, checkout_completed, checkout_failed

공통 property

workspace_id, plan, role, source, experiment_key 같은 공통 축을 표준화한다.

대시보드와 cohort가 같은 필터를 쓸 수 있다.

민감정보 제외

email, 이름, 원문 입력값처럼 식별 가능하거나 민감한 값은 기본 제외한다.

필요하면 별도 동의·마스킹·해싱 정책을 세운다.

이벤트는 사용자 행동의 압축 표현이다. 이름은 행동을, property는 분석 축을, timestamp는 순서를, user/group id는 집계 단위를 담당한다.

5. Tracking Plan 최소 필드

tracking plan은 문서, 스프레드시트, 코드 schema 중 어떤 형태여도 된다. 핵심은 다음 필드를 빠뜨리지 않는 것이다.

필드	설명	예시
Event name	표준 이벤트 이름	`invite_created`
Trigger	언제 발생하는가	초대 API가 성공한 뒤
Owner	변경 책임자	Growth/Workspace PE
Properties	함께 보내는 속성	`workspace_id`, `role`, `source`
Required/optional	누락 허용 여부	`workspace_id` required
Privacy class	개인정보/민감정보 여부	non-PII
Destination	어디로 보내는가	warehouse, analytics tool
QA rule	검증 방법	staging event inspector + warehouse query

시나리오

초대 funnel을 분석하고 싶다

초대 모달을 열고, 이메일을 입력하고, 초대가 생성되고, 상대가 수락하는 흐름이 있다. 현재는 버튼 클릭 이벤트만 있다.

제품 질문을 기준으로 어떤 이벤트와 property를 tracking plan에 추가할 것인가?

초대 기능이라면 최소 이벤트는 다음처럼 잡을 수 있다.

invite_modal_opened
  properties: workspace_id, role, source, plan

invite_created
  properties: workspace_id, role, invite_role, source, seat_limit_state

invite_create_failed
  properties: workspace_id, role, error_code, seat_limit_state

invite_accepted
  properties: workspace_id, invite_role, time_to_accept_bucket

여기서 email 원문은 넣지 않는다. 분석에는 초대 대상의 식별자가 필요한 것이 아니라, 어떤 조건에서 초대가 성공하거나 실패하는지가 필요하기 때문이다.

6. 클라이언트와 서버 이벤트를 나누는 기준

Product Engineer는 이벤트를 어디서 발생시킬지도 결정해야 한다.

위치	적합한 이벤트	주의점
Client	노출, 클릭, 입력 시작, abandon 등 UI 행동	ad blocker, 네트워크 실패, 중복 발송 가능성
Server	결제 성공, 초대 생성, 권한 변경, API 성공	UI 맥락 property를 놓치기 쉬움
Worker/Webhook	비동기 완료, 결제 갱신, 이메일 발송 결과	지연 시간과 idempotency 필요

일반적으로 비즈니스 상태가 바뀌는 이벤트는 서버가 더 신뢰할 수 있다. 반대로 사용자가 봤는지, 어디서 이탈했는지는 클라이언트 이벤트가 필요하다. 중요한 것은 둘을 섞어 funnel을 만들 때 같은 user id, workspace id, correlation id를 유지하는 것이다.

7. Analytics QA

tracking plan은 작성보다 검증이 더 중요하다. 제품 배포 전 최소 QA는 다음 순서로 한다.

staging에서 핵심 흐름을 직접 수행하고 event inspector로 이름과 property를 확인한다.
required property 누락, 타입 오류, enum 오타를 찾는다.
중복 발생 여부를 본다. 같은 행동에 이벤트가 두 번 찍히면 conversion이 부풀려진다.
서버 이벤트와 클라이언트 이벤트의 순서와 id 연결을 확인한다.
warehouse나 analytics tool에서 샘플 쿼리로 funnel 계산이 가능한지 확인한다.
개인정보 property가 들어가지 않았는지 privacy review를 한다.

퀴즈

tracking plan 없이 이벤트를 나중에 붙이면 가장 먼저 깨지는 것은 무엇인가?

힌트: 이벤트가 있는 것과 분석 가능한 이벤트가 있는 것은 다르다.

정답 보기

이벤트 이름, property, 발생 시점이 제각각이 되어 funnel, cohort, 실험 분석을 재현하기 어렵다. 특히 required property 누락과 중복 발생은 지표를 조용히 왜곡한다.

8. 코드에 가까운 계약으로 만들기

가능하면 tracking plan을 타입이나 schema와 연결한다.

type InviteCreatedEvent = {
  event: "invite_created";
  workspace_id: string;
  actor_role: "owner" | "admin" | "member";
  invite_role: "admin" | "member";
  source: "onboarding" | "settings" | "share_modal";
  seat_limit_state: "available" | "near_limit" | "blocked";
};

이런 타입은 analytics SDK wrapper, backend event publisher, test fixture에서 재사용할 수 있다. Product Engineer에게 중요한 것은 analytics를 “외부 도구 설정”이 아니라 코드 계약으로 다루는 습관이다.

9. 실무 체크리스트

Tracking Plan 작성 체크

제품 질문이 먼저 있고 이벤트가 그 질문에 답하도록 설계되어 있다
이벤트 이름이 UI 요소가 아니라 사용자 행동을 표현한다
required property와 optional property가 구분되어 있다
user, account, workspace 같은 집계 단위가 일관된다
client/server/worker 이벤트의 역할이 나뉘어 있다
중복 발생과 누락 property를 QA할 방법이 있다
실험, rollout, source, plan 같은 분석 축이 property에 포함되어 있다
PII와 동의가 필요한 값이 기본 property에서 제외되어 있다

10. 다음 문서로 이어지는 연결

tracking plan은 측정의 입력이다. 다음 단계에서는 이 입력으로 funnel, cohort, retention을 해석한다.

Funnel, Cohort & Retention Metrics: 이벤트를 제품 흐름 분석으로 바꾼다.
Experimentation & Feature Flags: 이벤트를 실험 지표와 rollout 판단에 연결한다.
Privacy, Consent & Product Data Governance: 이벤트 수집의 개인정보 경계를 다룬다.

추가 학습 키워드

Product analytics
Event taxonomy
Tracking plan
Required property
Analytics QA
Client-side analytics
Server-side analytics
Correlation id
Data contract

참고 소스

Amplitude, Product Analytics Guide: https://amplitude.com/explore/analytics/product-analytics-guide
Twilio Segment, Create a Tracking Plan: https://www.twilio.com/docs/segment/protocols/tracking-plan/create
PostHog, Product Analytics Privacy Controls: https://posthog.com/docs/product-analytics/privacy