대부분의 퍼널은 사용자가 아니라 제품을 측정합니다
일반적인 분석 도구를 열면 퍼널은 엔지니어링 팀이 우연히 계측한 이벤트로 구성되어 있습니다: route_loaded, account_created_v2, modal_opened. 기술적으로는 정확하지만 제품 의사결정에는 거의 쓸모가 없습니다. 그것들이 설명하는 것은 소프트웨어 한 것이지, 무엇이 아니라 사용자 하려던 것. 코드베이스를 측정하는 퍼널은 컴포넌트가 언제 렌더링되었는지 알려줍니다; 의도를 측정하는 퍼널은 누군가 어디서 포기했는지 알려줍니다.
해결책은 관찰된 행동에서 거꾸로 퍼널을 구축하는 것입니다 — 그리고 단 하나의 숫자라도 신뢰하기 전에 모든 단계를 실제 녹화와 대조해 검증하는 것입니다. 다음은 그 워크플로입니다.
사용자 의도에 따라 단계 이름 지정
최고의 퍼널은 사용자 스토리처럼 읽힙니다: 가격 페이지에 도착 → 가입 시작 → 워크스페이스 생성 → 스니펫 설치 → 첫 녹화 확인. 각 단계는 사용자의 관점에서 진행 상황을 설명합니다. 다음과 같은 내부 라벨은 account-created-v2 또는 dashboard-route-loaded 코드에는 유용하지만 제품 검토에서는 의도를 숨깁니다.
퍼널이 사용자 언어로 명명되면, 모두가 격차를 더 빨리 발견합니다. 많은 사용자가 워크스페이스를 만들지만 스니펫을 설치하지 않는다면, 다음 질문은 명백합니다 — 그리고 통역할 분석가가 필요 없습니다. 간단한 테스트: 신입사원이 당신의 퍼널 단계를 소리 내어 읽고 사용자의 목표를 이해할 수 없다면, 그 단계는 결정이 아니라 엔지니어를 위해 명명된 것입니다.
녹화로 모든 단계를 검증하세요
퍼널을 진실로 받아들이기 전에 각 전환 지점 주변의 세션을 살펴보세요. 가장 흔한 퍼널 버그는 차트에 있는 것이 아니라 — 그것에 데이터를 공급하는 이벤트 정의에 있습니다:
- 너무 일찍 발동됨: 그 이벤트는 사용자가 실제로 작업을 완료할 때가 아니라 컴포넌트가 렌더링되거나 경로가 로드될 때 발동되어 — 그 단계를 부풀리고 그 아래의 누수를 숨깁니다.
- 너무 자주 발동됨: 재시도, 리렌더링, 또는 중복 제출은 같은 사용자를 두 번 집계하므로 전환율이 실제보다 좋아 보입니다.
- 잘못된 이유로 발동됨: 그 이벤트는 의도한 성공 상태가 아니라 부수 효과를 캡처합니다.
세션 녹화 대시보드에서는 올바르게 보이지만 실제 맥락에서는 실패하는 이벤트 정의를 가장 빠르게 잡아내는 방법입니다. 전환마다 세 개의 세션을 살펴보세요; 이벤트가 사용자가 분명히 의도한 것과 일치하면 그 단계를 신뢰하세요. 그렇지 않다면 데이터를 바탕으로 행동하기 전에 정의를 수정하세요.
이탈을 읽은 다음, 가서 지켜보세요
퍼널의 역할은 숫자를 표시하는 것이 아니라 — 그 숫자를 설명하는 녹화로 안내하는 것입니다. 어떤 단계에서 이탈이 발생하면 직감으로 다시 설계하지 마세요. 그 단계에 도달했다가 이탈한 사용자로 필터링하고 그들의 세션 다섯 개를 보면, 보통 몇 가지 안 되는 원인 중 하나를 찾게 됩니다:
- 설명 없는 유효성 검사 오류 또는 비활성화된 버튼.
- 사용자가 가지고 있지 않았고 해결할 수도 없었던 필수 입력란 또는 권한.
- 혼란의 순간 — 다음 동작은 그들이 본 곳에 없었습니다.
- 전혀 잘못된 것 없음: 그들은 필요한 것을 얻고 만족하며 떠났습니다(이탈이 아닌 «누수»).
그 마지막 경우가 퍼널만으로는 오해를 부르는 이유입니다. 숫자는 «이탈»이라고 말하지만; 녹화는 «성공»이라고 말합니다. 오직 그 둘의 짝만이 진실을 말합니다.
하나의 활성화 퍼널을 신성하게 유지하세요
소규모 팀은 하나의 핵심 활성화 퍼널을 유지하고 매주 검토해야 합니다. 겹치는 퍼널을 수십 개 만들고 싶은 충동을 참으세요 — 그것들은 주의를 분산시키고 모두가 자기 프로젝트를 돋보이게 하는 차트를 고르게 만듭니다. 집중된 퍼널은 공유된 운영 리듬을 만듭니다: 이번 주에 무엇이 바뀌었는지, 전환이 어디서 움직였는지, 그리고 어떤 세션이 그 움직임을 설명하는지?
그 하나의 신성한 퍼널을 중심으로 특정 조사를 위해 단기적이고 일회용인 퍼널을 만들었다가 보관할 수 있습니다. 핵심은 대시보드 수를 최대화하는 것이 아니라, 팀 전체가 신뢰하고 되돌아오는 하나의 숫자를 갖는 것입니다.
자주 묻는 질문
퍼널 단계는 페이지뷰여야 하나요, 이벤트여야 하나요?
거의 항상 이벤트입니다. 페이지뷰는 탐색을 설명할 뿐 성취를 설명하지 않습니다 — 사용자는 성공하지 않고도 «성공» 페이지를 로드할 수 있고, 탐색 없이 단일 페이지 앱 내에서 성공할 수도 있습니다. 단계를 실제 사용자 의도를 나타내는 이벤트로 정의하세요.
퍼널에는 단계가 몇 개나 있어야 하나요?
이야기를 전할 수 있을 만큼만 — 보통 네 개에서 여섯 개. 각 단계는 의미 있는 결정 지점이어야 합니다. 인접한 두 단계가 항상 함께 전환된다면 합치세요; 그 사이의 간격은 아무것도 알려주지 않습니다.
내 퍼널 전환율이 왜 실제보다 나빠 보이나요?
보통 단계가 너무 일찍 발동하거나 같은 사용자를 한 번 이상 세거나, 사용자별로 중복 제거를 하지 않는 것입니다. 각 이벤트를 녹화와 대조해 검증하고, 원시 이벤트가 아니라 고유 사용자를 측정하고 있는지 확인하세요.
퍼널을 잘 사용하려면 세션 리플레이가 필요한가요?
그것 없이도 퍼널을 실행할 수 있지만, 원인을 추측하게 될 것입니다. 각 이탈을 그 뒤의 녹화와 짝지우는 것이 퍼널을 상태 보고서에서 해결책의 원천으로 바꾸는 것입니다. 다음을 참조하세요 노이즈 없는 세션 리플레이.