Funnel, Cohort & Retention Metrics

분류: Layer 13 - Product Engineering & Growth Systems

핵심 질문

tracking plan이 “무엇을 기록할 것인가”를 정한다면, funnel·cohort·retention은 “그 기록을 어떻게 제품 판단으로 읽을 것인가”를 정한다. Product Engineer는 이벤트 수집에서 멈추지 않고, 사용자가 어디서 이탈하고 어떤 사용자군이 다시 돌아오는지 설명할 수 있어야 한다.

1. 한 줄 정의

Funnel, Cohort & Retention Metrics는 사용자 행동 이벤트를 단계별 전환, 사용자군별 차이, 시간에 따른 재방문으로 해석하는 Product Engineering 역량이다.

2. 왜 중요한가

Product Engineer는 기능 출시 후 다음 질문을 자주 받는다.

새 온보딩은 activation을 높였는가?
초대 흐름에서 사용자는 어디서 이탈하는가?
유료 기능을 쓴 사용자는 다음 주에도 돌아오는가?
신규 사용자와 기존 사용자의 행동 차이가 있는가?
성능 개선이 실제 conversion이나 retention에 영향을 줬는가?

이 질문은 단일 이벤트 수로 답하기 어렵다. funnel은 흐름의 이탈을, cohort는 사용자군의 차이를, retention은 시간이 지난 뒤의 재방문과 가치 반복을 보여준다.

2.5. 선행 방식의 한계 — 왜 Funnel과 Cohort가 필요한가

가장 쉬운 분석은 전체 사용자 수, 전체 클릭 수, 전체 가입 수를 보는 것이다. 하지만 전체 평균은 제품 문제를 자주 숨긴다. 신규 사용자의 activation은 떨어졌는데 기존 사용자의 반복 사용이 늘어 전체 평균이 유지될 수 있다. 첫 화면에서 이탈하는 사용자가 많은데 마지막 완료 이벤트만 보면 conversion이 낮다는 사실만 보이고 원인은 보이지 않는다.

Product analytics가 event-level 사용자 행동을 추적하는 이유는 이 한계를 줄이기 위해서다. Amplitude는 product analytics를 engagement, drop-off, retention driver를 이해하는 활동으로 설명한다. Product Engineer에게 이 말은 곧 “전체 count가 아니라 행동 흐름과 사용자군을 기준으로 제품을 읽어야 한다”는 뜻이다.

따라서 funnel과 cohort는 데이터 분석가만의 기법이 아니다. 기능을 설계하고 출시하는 엔지니어가 “이 변경이 어떤 사용자에게 어떤 행동 변화를 만들었는가”를 확인하기 위한 기본 도구다.

3. Funnel은 흐름의 병목을 본다

Funnel은 사용자가 목표 행동까지 가는 단계를 순서대로 놓고 각 단계의 전환율을 보는 방법이다.

예를 들어 workspace 초대 funnel은 다음처럼 잡을 수 있다.

invite_modal_opened
  -> invite_email_entered
  -> invite_created
  -> invite_accepted

이때 Product Engineer가 볼 것은 전체 완료율만이 아니다.

구간	질문	가능한 원인
opened -> email_entered	사용자가 입력을 시작하는가	모달 copy, 대상 이해 부족, UI 신뢰 부족
email_entered -> created	제출이 성공하는가	validation, permission, seat limit, API error
created -> accepted	초대받은 사람이 가치를 느끼는가	email delivery, token expiry, onboarding friction

Funnel은 “어디가 문제인가”를 좁혀준다. 원인을 확정해주지는 않지만, 어디를 봐야 하는지 알려준다.

시나리오

가입자는 늘었는데 첫 프로젝트 생성이 줄었다

마케팅 캠페인 이후 signup_completed 이벤트는 증가했지만 project_created 이벤트는 줄었다. 전체 활성 사용자는 아직 큰 변화가 없다.

이 상황에서 어떤 funnel 단계와 cohort를 먼저 분리해서 볼 것인가?

4. Cohort는 비교 가능한 사용자군을 만든다

Cohort는 같은 조건을 공유하는 사용자군이다. 조건은 가입 주차, 유입 채널, plan, 역할, 실험군, 기능 사용 여부 등이 될 수 있다.

Cohort를 나누는 기준

시간 cohort

같은 기간에 시작한 사용자를 비교한다.

예: 2026년 6월 첫째 주 가입자

행동 cohort

특정 행동을 한 사용자와 하지 않은 사용자를 비교한다.

예: 첫날 팀원을 초대한 사용자 vs 초대하지 않은 사용자

속성 cohort

role, plan, company size, source 같은 property로 나눈다.

예: admin 사용자와 member 사용자

실험 cohort

variant 노출 단위로 결과를 비교한다.

예: onboarding_v2 treatment vs control

Cohort를 나누면 “사용자가 늘었다”보다 훨씬 구체적인 판단이 가능하다. 예를 들어 전체 retention은 그대로인데 enterprise admin cohort의 retention만 떨어졌다면, 제품 문제는 전체 UX가 아니라 권한·초대·SSO 흐름일 수 있다.

5. Retention은 반복 가치의 신호다

Retention은 사용자가 시간이 지난 뒤 다시 돌아와 의미 있는 행동을 하는지 본다. 단순 방문이 아니라 제품 가치와 연결된 return action을 정의해야 한다.

제품 유형	약한 retention 이벤트	강한 retention 이벤트
협업 도구	page_view	comment_created, document_shared
개발자 도구	dashboard_opened	api_call_succeeded, deployment_created
분석 도구	report_viewed	saved_chart_shared, query_run
결제/권한 기능	billing_page_viewed	premium_feature_used

Retention을 볼 때는 “돌아왔다”의 기준도 정해야 한다.

N-day retention: 가입 후 N일째에 return action을 했는가
Unbounded retention: N일 이후 한 번이라도 돌아왔는가
Rolling retention: 특정 기간 안에 반복 행동이 있었는가
Usage frequency: 주간 또는 월간 반복 빈도가 제품 가치와 맞는가

6. Activation, Conversion, Retention을 분리한다

세 지표는 서로 다른 질문에 답한다.

지표	묻는 질문	예시
Activation	사용자가 첫 가치를 경험했는가	첫 프로젝트 생성, 첫 API 성공
Conversion	사용자가 목표 전환을 완료했는가	trial -> paid, invite sent -> accepted
Retention	사용자가 시간이 지나도 반복 가치를 얻는가	다음 주에도 핵심 기능 사용

Activation이 낮으면 onboarding과 첫 가치 전달을 봐야 한다. Conversion이 낮으면 가격, 권한, trust, form UX, checkout friction을 봐야 한다. Retention이 낮으면 기능의 반복 가치, notification, collaboration loop, performance, reliability를 봐야 한다.

퀴즈

signup_completed가 증가했는데 week 1 retention이 떨어졌다면 어떤 해석이 가능한가?

힌트: 유입량과 제품 가치 경험은 같은 말이 아니다.

정답 보기

새 유입이 늘었지만 제품의 핵심 가치를 경험하지 못하는 사용자가 많아졌을 수 있다. 유입 source별 cohort, activation funnel, 첫 가치 경험 이벤트를 분리해서 봐야 한다.

7. 지표 함정

Product Engineer가 자주 만나는 함정은 다음과 같다.

평균의 함정: 전체 평균은 특정 cohort의 문제를 숨긴다.
분모의 함정: conversion rate의 분모가 노출자인지 시작자인지 대상자인지 불명확하다.
이벤트 품질 문제: required property 누락, 중복 이벤트, ad blocker로 인해 funnel이 왜곡된다.
time window 문제: 사용자의 자연스러운 사용 주기와 retention window가 맞지 않는다.
vanity metric: page view, click count가 핵심 가치 행동을 대신한다.
survivor bias: 이미 성공한 사용자만 분석해 초기 이탈 원인을 놓친다.

8. PE용 분석 루틴

새 기능을 출시한 뒤 Product Engineer는 다음 루틴으로 숫자를 읽는다.

tracking plan QA 결과를 확인한다.
대상 사용자와 제외 사용자를 다시 확인한다.
funnel의 단계별 drop-off를 본다.
role, plan, source, device, experiment variant별 cohort를 비교한다.
activation event와 retention event가 제품 가치와 맞는지 점검한다.
guardrail metric, error rate, performance metric이 악화되지 않았는지 본다.
다음 iteration에서 바꿀 UX Flow 또는 시스템 병목을 정한다.

Funnel/Cohort/Retention 해석 체크

분석 질문이 activation, conversion, retention 중 무엇인지 구분했다
funnel 단계마다 이벤트 정의와 분모가 명확하다
사용자군을 role, plan, source, time cohort 등으로 분리했다
return action이 단순 방문이 아니라 제품 가치 행동이다
이벤트 중복, 누락 property, client/server 차이를 확인했다
평균 지표 뒤에 숨어 있는 특정 cohort 악화를 확인했다
지표 변화에서 바로 결론을 내리지 않고 다음 UX/시스템 가설로 연결했다

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

funnel과 cohort는 제품 상태를 읽는 방법이다. 다음 단계에서는 이 변화가 우연인지, 특정 release나 experiment 때문인지 판단해야 한다.

Experimentation & Feature Flags: cohort 차이를 실험 설계와 rollout 판단으로 연결한다.
Frontend Product Quality & RUM: 성능과 접근성 같은 UX 품질이 funnel과 retention에 미치는 영향을 본다.
Privacy, Consent & Product Data Governance: cohort와 event property가 개인정보 경계를 넘지 않도록 관리한다.

추가 학습 키워드

Funnel analysis
Cohort analysis
Activation metric
Conversion rate
Retention curve
Return action
Vanity metric
Guardrail metric
Event quality

참고 소스

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