퍼널 분석

Date:     Updated:

카테고리:

태그:

퍼널 분석

1. 퍼널(Funnel)의 정의

  • 사용자가 서비스나 웹사이트를 이용하며 전환에 이르기까지의 과정을 단계별로 분석하는 기법
  • 하나의 퍼널에서 다음 퍼널로 얼마나 전환되는가를 파악할 수 있음
  • 퍼널은 목적에 맞게 구성할 수 있음.
    • 특정 페이지를 하나의 퍼널로 볼 수도 있고,
    • 특정 페이지의 묶음을 퍼널로 정의할 수도 있음
  • 대표적인 퍼널 : 회원 가입 퍼널, 온보딩, 결제 퍼널 등

    ex) 광고 클릭 -> 회원가입 -> 상품조회 -> 장바구니 -> 결제

    • 이 흐름에서 어떤 단계에서 사용자가 많이 이탈하는지, 어디를 개선해야 전환율이 많이 올라가는지 확인 가능



2. 퍼널 정의하는 방법

    1. 이벤트가 명시적으로 존재하는 경우
      • 예 : 메인 화면 진입, 구매 완료
      • 이벤트의 조합으로 사용
    1. 명시적으로 존재하진 않으나, 모든 페이지의 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가 없는 경우
      • 사용자의 로그 기반으로 세션을 직접 생성 (세션을 만들 때 윈도우 함수를 사용해서 미활동의 시간을 임의로 설정할 수 있음)
  • 일자가 바뀌는 시점에 세션을 어떻게 처리하는가
    • 일자가 넘어가는 시점에 걸쳐서 세션이 존재하는 경우 처리가 어려울 수 있음
    • 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명 ₩5,000 ₩16,000,000
      상품 상세 -> 장바구니 950명 ₩30,000 ₩28,500,000
      장바구니 -> 결제 클릭 300명 ₩100,000 ₩30,000,000
    • 결과

      • 이탈자 수는 적지만, 장바구니 → 결제 클릭 구간의 손실 매출이 가장 큼
      • 즉, 고객 수보다 매출 기준으로 판단해야 전략적으로 더 맞을 수 있음



  • 전략 선택 기준

    전략 방향 설명 우선 개선할 퍼널 단계
    유입 증가 중심 전략 많은 유저를 확보해야 할 시점(신규 서비스 론칭 등) 홈 -> 카테고리
    수익성 개선 중심 전략 구매 직전 유저의 이탈을 막아야 할 시점(최적화 단계) 장바구니 -> 결제 클릭
    ROI 기반 전략 매출 손실 + 개선 난이도 모두 고려 손실이 크면서도 개선이 쉬운 구간



3) 퍼널 분석 결과, 팀과 어떻게 공유하고 실행할 것인가

팀 공유

  • 정답이 명확히 있지 않으므로 팀 내 공유
  • 어떤 기능을 만들어볼까? 가설을 만들기
  • 정답을 내리는 것이 아닌 가능성이 있는 것을 만들고 그것이 진짜 되도록 하는 것


퍼널 관련 여러 아이디어

  • 퍼널 단계를 줄이기(Gap 줄이기)
  • 퍼널 순서를 바꾸기 : 회원 가입 전에 체험하고, 체험의 어느 단계에서 회원 가입 또는 로그인하도록 설계
  • 결제 직전에 추가 상품을 추천해서 업셀링
  • 장바구니에 담기 전에 할인 프로모션 안내, 할인 가격 적용해서 노출

SQL 카테고리 내 다른 글 보러가기

댓글 남기기