퍼널 분석으로 이탈 지점 찾기: 가입·온보딩에서 사용자가 빠지는 구간 진단법

1. 먼저 퍼널의 시작과 끝을 고정하기

퍼널 분석은 도구보다 질문이 먼저입니다. “가입자가 몇 명인가?”보다 “가입한 사람이 첫 핵심 행동까지 어디에서 멈추는가?”를 물어야 합니다.

가입 완료가 퍼널의 시작은 아닐 수 있다

서비스에 따라 방문 → 회원가입 시작 → 회원가입 완료 → 온보딩 완료 → 핵심 기능 실행 → 첫 결과 확인처럼 단계를 나눌 수 있습니다. 모든 클릭을 넣으면 그래프는 복잡해지고, 어느 단계가 중요한지 흐려집니다. 처음에는 사용자가 제품의 가치를 처음 체감하는 행동까지 4~7단계로 제한하세요.

예를 들어 메모 서비스라면 가입 완료보다 “첫 메모 저장”이 더 중요한 활성화 기준일 수 있습니다. 핵심은 이벤트 이름을 예쁘게 짓는 것이 아니라 각 단계가 실제 사용자 행동을 나타내는지 확인하는 것입니다. 이벤트 설계가 아직 불안하다면 이벤트 이름 짓기 규칙: 나중에 후회 안 하는 분석 이벤트 택소노미 설계법을 먼저 참고해보세요.

분석 기간과 사용자 조건을 통일한다

최근 7일, 최근 30일처럼 기간을 정하고, 신규 가입자만 볼지 전체 사용자를 볼지 정해야 합니다. 로그인 사용자의 재방문 행동과 첫 방문자의 온보딩 행동을 섞으면 이탈 원인을 잘못 해석할 수 있습니다. 한 번에 하나의 질문만 남기고 조건을 고정하세요.

2. 숫자로 가장 큰 이탈 구간 좁히기

PostHog나 GA4에서 단계별 사용자 수와 전환율을 확인합니다. 중요한 것은 전체 전환율보다 “바로 앞 단계 대비 얼마나 줄었는가”입니다.

절대값보다 구간 간 차이를 본다

가입 시작 100명 중 80명이 가입을 완료하고, 그중 30명만 온보딩을 끝냈다면 우선 살펴볼 곳은 가입 폼보다 온보딩입니다. 반대로 온보딩 완료 후 핵심 기능 실행까지 급격히 줄었다면, 사용자가 다음 행동을 이해하지 못했거나 가치를 느끼기 전에 선택지를 너무 많이 만났을 가능성이 있습니다.

표를 만들 때는 다음 열만 있어도 충분합니다.

수치를 보고 바로 “온보딩이 나쁘다”고 결론 내리지 마세요. 가장 큰 이탈 구간은 문제의 위치를 알려줄 뿐, 원인까지 알려주지는 않습니다. AARRR 해적 지표 프레임워크로 사이드 프로젝트 퍼널 처음 그려보기처럼 획득·활성화·리텐션을 구분해 보면 분석 범위가 더 선명해집니다.

세그먼트로 착시를 줄인다

기기, 유입 경로, 신규·기존 사용자, 로그인 방식처럼 행동 차이가 클 만한 조건으로 나눠보세요. 모바일에서만 이탈이 크다면 메시지의 문제가 아니라 화면 크기나 입력 방식의 문제일 수 있습니다. 단, 세그먼트를 너무 많이 만들면 우연한 차이를 중요한 신호로 착각하기 쉬우므로 가설과 직접 연결되는 조건만 선택합니다.

3. 원인 가설을 검증하는 순서

퍼널에서 이탈 지점을 찾았다면 숫자를 설명할 가설을 2~3개로 좁힙니다. “버튼이 안 보인다”, “입력 부담이 크다”, “이 단계의 필요성을 모른다”처럼 관찰 가능한 문장으로 쓰세요.

먼저 행동 로그와 세션을 확인한다

해당 단계에 도착한 사용자가 어떤 버튼을 눌렀는지, 오류가 발생했는지, 페이지를 오래 열어둔 뒤 나갔는지 확인합니다. 세션 리플레이를 볼 때는 한두 명의 특이한 행동을 일반화하지 말고, 비슷한 패턴이 반복되는지 살펴보세요.

그다음 짧은 인터뷰로 이유를 묻는다

로그는 “무엇을 했는가”를 보여주지만 “왜 멈췄는가”는 설명하지 못합니다. 이탈한 사용자에게 “왜 가입하지 않았나요?”라고 묻기보다 “이 화면에서 다음에 무엇을 하려고 했나요?”, “어느 부분이 가장 망설여졌나요?”처럼 당시 상황을 복원하는 질문을 사용하세요. 질문 설계는 사용자 인터뷰 제대로 하는 법: 유도질문 없이 진짜 문제를 캐내는 질문 설계에서 더 자세히 다뤘습니다.

4. 수정은 가장 좁은 병목부터 시작하기

한 번에 온보딩 전체를 개편하지 말고, 가장 큰 이탈 구간의 마찰 하나만 줄입니다. 입력 필드 하나를 제거하거나, 다음 행동을 설명하는 문장을 추가하거나, 실패 시 복구 경로를 보여주는 식입니다.

조코헌트에 출시된 프로덕트 298개를 보면 다양한 제품이 공존합니다. 따라서 다른 제품의 전환율을 기준으로 삼기보다, 내 제품에서 사용자가 핵심 가치를 경험하기까지의 흐름을 기준선으로 잡는 편이 현실적입니다.

수정 전에는 가설과 성공 조건을 기록하세요. “온보딩 완료율이 오른다”처럼 결과를 쓰되, 특정 수치를 미리 지어내기보다 비교 기간과 사용자 조건을 동일하게 유지하는 것이 중요합니다. 분석 도구 설치가 아직이라면 PostHog Next.js 설치부터 첫 이벤트 추적까지: 인디 메이커용 30분 셋업 가이드를 참고할 수 있습니다.

5. 퍼널을 정기 점검 루틴으로 만들기

퍼널 분석은 한 번의 대형 리디자인보다 작은 실험을 반복할 때 효과가 커집니다. 매주 또는 격주로 다음 체크리스트를 확인하세요.

• 이번 기간에 가장 크게 줄어든 단계는 어디인가?
• 특정 기기나 유입 경로에서만 문제가 커졌는가?
• 오류·반복 클릭·페이지 이탈이 함께 나타나는가?
• 로그로 설명되지 않는 부분을 인터뷰했는가?
• 수정한 뒤 같은 조건으로 다시 비교했는가?

조코헌트의 데이터에서 출시 첫 24시간 안에 업보트나 댓글 같은 반응을 하나라도 받은 프로덕트는 53%입니다. 이 수치를 가입 퍼널의 목표로 삼을 필요는 없지만, 출시 뒤에는 가입자 수만 보지 말고 실제 반응이나 핵심 행동까지 이어지는지 함께 확인해야 한다는 힌트로 볼 수 있습니다. 퍼널은 사용자를 평가하는 표가 아니라, 다음에 고칠 한 지점을 찾는 지도입니다.