퍼널 분석
카테고리: SQL
퍼널 분석
1. 퍼널(Funnel)의 정의
- 사용자가 서비스나 웹사이트를 이용하며 전환에 이르기까지의 과정을 단계별로 분석하는 기법
- 하나의 퍼널에서 다음 퍼널로 얼마나 전환되는가를 파악할 수 있음
- 퍼널은 목적에 맞게 구성할 수 있음.
- 특정 페이지를 하나의 퍼널로 볼 수도 있고,
- 특정 페이지의 묶음을 퍼널로 정의할 수도 있음
- 대표적인 퍼널 : 회원 가입 퍼널, 온보딩, 결제 퍼널 등
ex) 광고 클릭 -> 회원가입 -> 상품조회 -> 장바구니 -> 결제
- 이 흐름에서 어떤 단계에서 사용자가 많이 이탈하는지, 어디를 개선해야 전환율이 많이 올라가는지 확인 가능
2. 퍼널 정의하는 방법
-
- 이벤트가 명시적으로 존재하는 경우
- 예 : 메인 화면 진입, 구매 완료
- 이벤트의 조합으로 사용
- 이벤트가 명시적으로 존재하는 경우
-
- 명시적으로 존재하진 않으나, 모든 페이지의 view가 존재하는 경우
- 페이지의 view를 기준으로 퍼널을 정의
- view 이벤트, 커스텀 이벤트 등을 모두 활용
- 명시적으로 존재하진 않으나, 모든 페이지의 view가 존재하는 경우
3. 퍼널의 종류
1) Open 퍼널
- 유저의 이벤트 행동 순서에 상관없이 집계
- 즉, 사용자가 특정 단계까지만 도달해도 퍼널에 포함됨
- 모든 단계에서 시작될 수 있다고 가정
- 중간 단계만 거쳐도 분석 대상
- 원클릭 결제 등이 있다면 특정 순서를 넘길 수 있음
- 목적 : 각 단계별 진입/이탈 확인, 퍼널의 유연한 흐름 파악
2) Closed 퍼널
- 유저가 정해진 단계를 순서대로 거쳐야 집계
- 즉, 시작 지점부터 마지막 단계까지 모두 거친 사용자만 포함됨
- 엄격한 순서를 거쳐야 함
- 전체 흐름을 순차적으로 따라야 분석 대상
- 다음 단계가 항상 이전 단계보다 작거나 같음
- 대부분의 분석 도구에서 활용
- 전체 여정의 전환율 최적화, 전환 구조 분석에 초점
3) Open 퍼널과 Closed 퍼널 예시
제품 페이지 방문 → 장바구니 담기 → 결제 시도 → 결제 완료
- Open 퍼널
- 사용자가 “장바구니 담기” 단계만 해도 퍼널에 포함됨
- “결제 시도”나 “결제 완료” 단계에 도달하지 않아도 각각의 단계 진입율 따로 분석 가능
- 각 단계별 유입량과 이탈률을 유연하게 확인하고, 개선 포인트 파악에 유리
광고 클릭 → 회원가입 → 제품 탐색 → 장바구니 → 결제 완료
- Closed 퍼널
- 반드시 광고 클릭부터 결제 완료까지 모든 단계를 순서대로 거친 사용자만 퍼널에 포함
- 중간에 하나라도 건너뛰면 포함되지 않음
- 퍼널 전체의 전환율, 유실 지점 등을 정확히 분석할 수 있음
4) Closed 퍼널과 Open 퍼널 비교
- SQL 쿼리 상에서 두 개의 차이
- Closed 퍼널은 유저의 로그 데이터를 기반으로 앞선 퍼널의 이벤트가 먼저 진행되었는지 확인
- Open 퍼널은 해당 이벤트가 존재하는지만 파악
- 제품에 따른 차이
- 제품을 잘 이해해야 어떤 퍼널을 사용할 것인지 결정됨
- 온보딩 과정, 결제 과정에서 Skip 하는 기능이 존재할 수 있음
- 어떤 앱은 자유롭게 이동할 수 있으나, 어떤 앱은 순서가 고정되어 있는 경우도 존재
- 웹은 자유롭게 이동할 수 있. URL로 직접 접근
- 앱도 Deep Link로 직접 접근하는 경우도 존재
5) Closed 와 Open 퍼널 중 어떤 것을 선택할까?
Open 퍼널
- 유연한 유저의 여정 : 다양하게 진입할 수 있는 경우
- 광범위한 분석 : 시작 위치와 관계없이 모든 사용자의 상호 작용을 파악하고 싶은 경우
- 최초에 큰 그림을 보고 싶은 경우
Closed 퍼널
- 유저의 흐름이 고정되어 있는 경우
- 모든 단계가 순서대로 완료되어야 하는 경우
- 순차적으로 해야하며, 앞선 조건이 엄격한 경우
6) 어떤 퍼널을 먼저 개선해야 할까?
- 상황과 전략에 따라 달라진다!
- 퍼널 분석의 핵심은 사용자의 여정을 파악하고, 이탈이 많은 지점을 개선하는 것.
- 그러나 단순히 전환율이 낮은 단계부터 무작정 개선하는 것은 전략적으로 부족할 수 있음.
전환율 낮은 구간부터 개선하는 접근
- 가장 흔하게 추천되는 접근법
- 데이터상 가장 큰 병목을 제거하여 즉각적인 성과 향상을 기대할 수 있음. -ex) 결제 단계 전환율이 5% -> UX개선, 신뢰도 요소 강화 등
- 단점
- 제품의 근본적인 부분을 손보지 않고 특정 전환율만 올리려고 하면 근본적인 해결이 아님
- 단기적 성과엔 유리하지만 장기적 습관 형성이나 충성도 개선에는 한계
제품 매력을 먼저 강화하는 접근
- “유저가 제품을 사랑하게 만드는 경험 설계”를 우선
- 초기 경험(예: 온보딩, 핵심 기능 노출)을 강화하여 유저가 습관적으로 쓰게 만듦
- 이후에 전환율 개선은 자연스럽게 따라옴
- 단점
- 즉각적인 ROI가 낮을 수 있음 (전환률 상승까지 시간이 걸림)
- 정성적 평가가 많고, 설득이 어려울 수 있음
전략적으로 둘 다 접근할 수 있다면?
실무에서는 “어느 하나만” 하지 않는다. 결국은 모두 개선해야 한다.
- 단기 성과를 볼 수 있는 퍼널 하단(전환)부터 일부 개선하면서,
- 동시에 제품 자체의 매력을 높이는 UX/UI 구조 개선,
- 습관 형성을 위한 기능(알림, 추천, 리마인더 등)도 준비해야 함
4. 지표 집계 단위
1) 주로 사용하는 집계 단위
집계 단위 | 설명 | 예시 |
---|---|---|
Session | 한 번의 방문 안에서 발생한 행동 흐름 | 같은 유저가 하루 2번 방문하면 2세션 |
User | 고유 유저 기준 집계 | 한 유저가 여러 번 방문해도 1로 집계 |
Event | 모든 이벤트를 개별로 취급 | 클릭 5번 -> 이벤트 수 5 |
- 여러 차원(Dimension)으로 집계
- 시간축 : 일자별 / 주차별 / 월별 등
- 지역 정보
- 사용자 인구 통계
2) 집계 단위별 이해: “영화 예매 앱”을 예로 들어보기
- 상황 설정 :
사용자 A
가 하루에 두 번 영화 앱에 접속해서 이런 행동을 했다고 가정
오전 10시
- 앱 접속
- 영화 ‘듄 2’ 검색
- 예매 시도 (결제 실패)
오후 8시
- 앱 재접속
- 영화 ‘듄 2’ 다시 검색
- 예매 성공
User 단위 집계
- 누가 했는지가 중요
- 동일 사용자는 하루에 몇 번 행동해도 1명으로 카운트
- SQL에선
DISTINCT user_id
지표 이름 | 값 |
---|---|
예매 시도 유저 수 | 1명 |
예매 성공 유저 수 | 1명 |
👉 장점: 사용자 수 기준으로 유입, 이탈, 전환 분석이 가능
👉 사용처: 퍼널 분석, 리텐션 분석 등 유저 행동 분석에서 주로 사용
Event 단위 집계
- 클릭, 검색, 예매 시도 등 모든 행동 하나하나를 이벤트로 셈
- 하루에 10번 클릭하면 10건으로 집계
지표 이름 | 값 |
---|---|
영화 검색 이벤트 수 | 2건 |
예매 시도 이벤트 수 | 2건 |
결제 성공 이벤트 수 | 1건 |
👉 장점: 세부 행동 흐름을 정밀하게 분석 가능
👉 사용처: 이벤트 로그 분석, 클릭률, 기능별 사용량 파악
Session 단위 집계
- 앱을 한 번 켜고 끌 때까지가 한 세션
- 하루에 여러 번 접속하면 그만큼 세션이 생김
지표 이름 | 값 |
---|---|
총 세션 수 | 2세션 |
예매 시도한 세션 수 | 2세션 |
예매 성공한 세션 수 | 1세션 |
👉 장점: 유저의 접속 타이밍, 행동 흐름을 분석할 수 있음
👉 사용처: 마케팅 채널 분석, 유입 → 행동 전환 흐름 분석
Session에서 생각할 부분
- 세션을 어떻게 만드는가
- Session_id가 존재하는 경우
- 해당 세션을 사용할 수 있음. 단, session이 어떤 기준으로 만들어지는지 확인 필요 (30분 동안 활동이 없다면 이탈로 간주 등)
- Session_id가 없는 경우
- 사용자의 로그 기반으로 세션을 직접 생성 (세션을 만들 때 윈도우 함수를 사용해서 미활동의 시간을 임의로 설정할 수 있음)
- Session_id가 존재하는 경우
- 일자가 바뀌는 시점에 세션을 어떻게 처리하는가
- 일자가 넘어가는 시점에 걸쳐서 세션이 존재하는 경우 처리가 어려울 수 있음
- 2024년 5월 5일 23시 58분에 접속해서 5월 6일 1시에 세션이 종료된 경우엔 5월5일에 포함해야 하는가?
- 기준에 따라 다르고, 정의하기 나름
- 아예 12시에 모든 세션을 종료시키는 것도 방법이고, 혹은 사용자가 갑자기 떨어지는 시점 기준(예 : 새벽 3시)을 토대로 하는 것도 방법
- 세션을 꼭 사용해야 하는가
- 어떤 기준을 사용하는지는 해결하고자 하는 문제의 목적에 따라 다름
- 하루에 접속이 많은 서비스라면 세션을 확인하는 것이 좋음
- 하루에 반복해서 쓰는 비율이 적다면 세션의 집계를 굳이 하지 않고, 일자별 유저별 집계를 하는 것이 더 좋을 수도 있음
- 세션을 직접 만들면 쿼리가 복잡해지기 때문에 작업하는 시간이 더 소요될 수도 있다는 점을 인지하기
- 판단이 어렵다면 일자 단위, 세션 단위 등을 구한 후에 어떻게 해석이 되는가 살펴보고 결정하기(데이터를 추출하고 보면 계속 비슷하게 가는 경우도 있고, 아예 다른 해석이 되는 경우도 존재)
- “이탈”이라는 이벤트가 명시적으로 발생할까
- 실제 로그 데이터를 본 적이 없다면 “이탈” 이벤트가 있다고 생각할 수 있음
- 그러나 앱, 웹 서비스에선 이탈 이벤트가 명확하지 않은 경우가 많음
- 로그아웃 등은 명확하지만, 사용할 때마다 로그아웃을 하지 않는 경우도 존재
- 따라서 유저의 행동이 없는 경우를 이탈로 정의하는 경우가 많음
- 앱 활성화 여부, 사용자 인터랙션 등을 종합적으로 고려하여 세션 기준을 만들어야 함
5. 유저를 식별 기준
- 로그인 유저 식별 : user_id
- 명확하고 일관된 식별자
- 회원 기반 서비스에서 가장 정확한 기준
✅ 장점: 고유함, 여러 디바이스에서도 동일 유저로 인식 가능
⚠️ 단점: 로그인하지 않으면 값이 없음 -
비로그인 유저 식별 : device_id / cookie_id
구분 설명 device_id 앱에서 수집(Android: GAID / iOS: IDFA 등) cookie_id 웹에서 사용자의 브라우저에 저장된 쿠키 기반 ID ✅ 장점: 로그인하지 않아도 사용자를 어느 정도 식별 가능
⚠️ 단점: 기기 변경, 앱 재설치, 브라우저 삭제 시 새로운 ID 발생
⚠️ 개인정보 수집에 대한 동의 필요 (GDPR, CCPA 등 이슈 있음) - Firebase/GA에서 자동 생성 : user_pseudo_id
- Firebase, GA4 등에서 자동으로 생성되는 유저 식별자
- 앱 설치 or 첫 접속 시 생성되며, 쿠키/디바이스 기반으로 유지
✅ 장점: GA 기반 분석에서는 거의 모든 유저 식별 가능
⚠️ 단점: 앱 삭제/재설치 시 변경됨 (완전한 고유 ID는 아님)
- 어떤 식으로 COUNT 해야 할까?
목적 | 쿼리 예시 |
---|---|
전체 이벤트 수 | COUNT(*) |
고유 유저 수(중복 제거) | COUNT(DISTINCT user_id) |
로그인 + 비로그인 모두 포함 | COUNT(DISTINCT COALESCE(user_id, user_pseudo_id)) |
GA4/Firebase 기준 유저 수 | COUNT(DISTINCT user_pseudo_id) |
6. 퍼널 쿼리 작성 예시
퍼널 :
① 첫 방문 → ② 상품 조회 → ③ 장바구니 담기 → ④ 결제 완료
WITH base_events AS (
SELECT
user_id,
event_name,
event_timestamp,
DATE(event_timestamp) AS event_date,
MIN(IF(event_name = 'visit', event_timestamp, NULL)) OVER (PARTITION BY user_id) AS first_event_ts
FROM your_event_table
WHERE event_name IN ('visit', 'view_product', 'add_to_cart', 'purchase')
),
funnel_steps AS (
SELECT
user_id,
MAX(IF(event_name = 'visit', 1, 0)) AS step_1_visit,
MAX(IF(event_name = 'view_product', 1, 0)) AS step_2_view,
MAX(IF(event_name = 'add_to_cart', 1, 0)) AS step_3_cart,
MAX(IF(event_name = 'purchase', 1, 0)) AS step_4_purchase
FROM base_events
GROUP BY user_id
)
SELECT
COUNT(*) AS total_users,
SUM(step_1_visit) AS visited,
SUM(step_2_view) AS viewed_product,
SUM(step_3_cart) AS added_to_cart,
SUM(step_4_purchase) AS purchased
FROM funnel_steps;
-- 전환율 계산하기
SELECT
ROUND(SUM(step_2_view)/SUM(step_1_visit)*100, 2) AS visit_to_view_rate,
ROUND(SUM(step_3_cart)/SUM(step_2_view)*100, 2) AS view_to_cart_rate,
ROUND(SUM(step_4_purchase)/SUM(step_3_cart)*100, 2) AS cart_to_purchase_rate
FROM funnel_steps;
- 고려사항
- 퍼널 분석 유형
- Strict Funnel (Closed): 순서를 반드시 따라야 함
- Loose Funnel (Open): 순서 무관, 이벤트만 발생하면 포함
- 타임 윈도우 설정
- 각 단계 사이의 시간 제한 설정 가능 (예: 7일 이내)
- 퍼널 분석 유형
7. 퍼널 분석 의사 결정
1) 현황 파악
- 서비스에 대해 전반적인 큰 그림 파악
- 현재 주요 이벤트는 얼마나 발생하고 있는가
- 퍼널 별로 얼마나 사용자가 있는가
- 퍼널을 어떻게 정의할 것인가
- 일자별로 달라지는가 (시간의 흐름)
- 특히 더 빠지는 구간이 있는가
2) 퍼널 데이터 해석하기
- 단순히 그래프만 보는 것이 아닌 숫자도 보면서 계속 질문해야 함
- “정말 이럴까? 맞다면 다른 데이터가 어떻게 나와야할까?”
- “전체로 봤을 때와 일자별로 나눌 때의 결과가 같을까?”
- “지금은 home -> food_category만 생각하는데 다른 경로도 가능하다. 그쪽은 얼마나 갈까?”
- “일자별 또는 공휴일의 패턴이 있을까?”
-
쇼핑몰 기준으로 예시를 들었을 때
퍼널 단계 이탈자 수 이탈율 홈 -> 카테고리 페이지 진입 3,200명 60% 상품 상세 -> 장바구니 담기 950명 45% 장바구니 -> 결제 페이지 클릭 300명 30%
- 겉으로 보면 앞단(Home → 카테고리) 이탈이 많아 보이지만
- 이탈자 수 기준: 홈 → 카테고리에서 무려 3,200명 이탈
- => 그래서 이 구간을 먼저 개선해야 할 것처럼 보임
- => 그래서 이 구간을 먼저 개선해야 할 것처럼 보임
- 이탈자 수 기준: 홈 → 카테고리에서 무려 3,200명 이탈
- 하지만 매출 기준으로 보면 판단이 달라진다
-
각 구간 이탈자의 예상 평균 구매 금액
퍼널 단계 이탈자 수 평균 객단가 예상 매출 손실 홈 -> 카테고리 3,200명 ₩5,000 ₩16,000,000 상품 상세 -> 장바구니 950명 ₩30,000 ₩28,500,000 장바구니 -> 결제 클릭 300명 ₩100,000 ₩30,000,000 -
결과
- 이탈자 수는 적지만, 장바구니 → 결제 클릭 구간의 손실 매출이 가장 큼
- 즉, 고객 수보다 매출 기준으로 판단해야 전략적으로 더 맞을 수 있음
-
-
전략 선택 기준
전략 방향 설명 우선 개선할 퍼널 단계 유입 증가 중심 전략 많은 유저를 확보해야 할 시점(신규 서비스 론칭 등) 홈 -> 카테고리 수익성 개선 중심 전략 구매 직전 유저의 이탈을 막아야 할 시점(최적화 단계) 장바구니 -> 결제 클릭 ROI 기반 전략 매출 손실 + 개선 난이도 모두 고려 손실이 크면서도 개선이 쉬운 구간
3) 퍼널 분석 결과, 팀과 어떻게 공유하고 실행할 것인가
팀 공유
- 정답이 명확히 있지 않으므로 팀 내 공유
- 어떤 기능을 만들어볼까? 가설을 만들기
- 정답을 내리는 것이 아닌 가능성이 있는 것을 만들고 그것이 진짜 되도록 하는 것
퍼널 관련 여러 아이디어
- 퍼널 단계를 줄이기(Gap 줄이기)
- 퍼널 순서를 바꾸기 : 회원 가입 전에 체험하고, 체험의 어느 단계에서 회원 가입 또는 로그인하도록 설계
- 결제 직전에 추가 상품을 추천해서 업셀링
- 장바구니에 담기 전에 할인 프로모션 안내, 할인 가격 적용해서 노출
댓글 남기기