퍼널 분석, 어디부터 볼 것인가

 

분석 도구를 열어 보면 숫자가 정말 많아요.
방문자 수, 페이지뷰, 체류 시간, 클릭 수까지 다 중요해 보여서 어디부터 봐야 할지 막막해질 때가 있습니다.
이럴 때 제가 가장 먼저 꺼내는 틀이 퍼널 분석이에요.
퍼널은 깔때기라는 뜻으로, 사용자가 서비스에 들어와서 목표 행동까지 가는 과정을 단계로 나누고 단계마다 몇 명이 남는지 보는 방법입니다.

 

깔때기의 위쪽은 넓고 아래쪽은 좁아요.
방문한 사람이 모두 가입하지는 않고, 가입한 사람이 모두 구매하지는 않으니까요.
단계가 내려갈수록 사람이 줄어드는 건 자연스러운 일이에요.
문제는 줄어드는 정도가 단계마다 균등하지 않고, 유독 많이 빠지는 곳이 있다는 점입니다.

퍼널 분석의 목적은 그 유독 많이 빠지는 곳을 찾아서 "왜"를 묻는 데 있어요.
숫자를 예쁘게 정리하는 게 목적이 아니라, 다음에 무엇을 고칠지 정하는 게 목적입니다.
그래서 퍼널을 그릴 때는 항상 "이 분석으로 어떤 결정을 내리고 싶은가"를 먼저 적어 둬요.

 

퍼널은 단계를 어떻게 자르느냐에 따라 결과가 달라져요.
너무 크게 자르면 어디서 문제가 생겼는지 알 수 없고, 너무 잘게 자르면 단계가 많아져서 오히려 흐름이 안 보입니다.
저는 보통 사용자가 "마음을 한 번 더 먹어야 하는 지점"을 단계 경계로 삼아요.
화면 이동이 아니라 결심의 전환을 기준으로 보는 거예요.

예를 들어 쇼핑몰이라면 이런 식이에요.
상품 목록 보기, 상품 상세 보기, 장바구니 담기, 결제 정보 입력, 결제 완료.
각 단계에 해당하는 이벤트가 정확히 무엇인지도 정해 둬야 해요.
"상품 상세 보기"가 페이지 진입인지, 일정 시간 이상 머문 것인지에 따라 숫자가 달라지거든요.
단계 정의는 문서로 남겨서 팀이 같은 기준으로 숫자를 읽게 하는 게 좋습니다.

또 하나 확인할 건 순서와 기간이에요.
단계를 반드시 순서대로 밟아야 하는지, 며칠 안에 완료해야 같은 퍼널로 치는지에 따라 이탈의 모습이 달라집니다.
예약이나 고가 상품처럼 결정에 시간이 걸리는 서비스에서는 하루 안에 끝나지 않는 경우가 많아서, 기간을 너무 짧게 잡으면 이탈이 부풀려져 보여요.

 

퍼널이 그려지면 보통 가장 많이 빠지는 구간부터 보라고들 해요.
저도 기본은 그 말에 동의해요.
다만 이탈이 크다는 것과 고칠 수 있다는 것은 다른 문제라서 몇 가지를 같이 따져 봅니다.

 

첫째, 원래 이탈이 클 수밖에 없는 구간인지 봐요.
상품 목록에서 상세로 넘어가는 구간은 둘러보는 사람이 많아서 이탈이 크기 마련이에요.

둘째, 개선했을 때 뒤쪽 단계에 미치는 영향이 큰지 봐요.
결제 직전 구간은 사람이 적어도 한 명 한 명의 가치가 큽니다.

셋째, 고치는 데 드는 비용을 봐요.
문구 하나 바꾸면 되는 구간과 시스템을 새로 만들어야 하는 구간은 우선순위가 달라요.

 

전체 평균 퍼널만 보면 중요한 단서를 놓치기 쉬워요.
같은 서비스라도 사용자 집단마다 퍼널 모양이 다르기 때문이에요.
신규와 재방문, 모바일과 PC, 유입 채널별로 나눠서 같은 퍼널을 겹쳐 보면 차이가 드러납니다.

가정해 보면 이런 경우가 있어요.
전체로는 장바구니에서 결제 정보 입력으로 넘어가는 비율이 평범해 보이는데, 모바일만 따로 보니 이 구간에서만 유독 낮다고 해 볼게요.
그러면 "결제 단계가 문제"가 아니라 "모바일에서 입력 폼이 불편한 것"일 수 있다는 가설이 생기죠.
세그먼트 비교는 원인을 좁히는 가장 값싼 방법이라고 생각해요.
다만 세그먼트를 너무 잘게 나누면 표본이 부족해져서 우연한 흔들림을 의미 있는 차이로 착각할 수 있으니 주의가 필요합니다.

 

가상의 구독 서비스 가입 퍼널을 보겠습니다.
랜딩 페이지 방문, 가입 버튼 클릭, 이메일 입력, 인증 완료, 첫 콘텐츠 이용의 다섯 단계라고 가정해요.
어느 단계에서 가장 많이 빠졌는지 보니 "이메일 입력에서 인증 완료" 구간이라고 해 볼게요.
여기서 바로 인증 메일 디자인을 고치기보다는 먼저 질문을 던져 봅니다.
메일이 늦게 오는 건 아닌지, 스팸함으로 가는 건 아닌지, 인증 안내 문구가 불친절한 건 아닌지 말이에요.
이 질문들을 하나씩 확인할 수 있는 데이터가 있는지 점검하고, 없다면 로그를 추가하는 것도 개선의 일부예요.
이탈의 원인이 정말 메일 지연이라면 해결은 개발 쪽이 맡고, 안내 문구가 문제라면 기획과 디자인이 맡게 되는 식으로 원인에 따라 담당과 해결 방법이 달라져요.

 

퍼널 분석은 답을 주는 도구가 아니라 질문의 위치를 알려 주는 도구라고 생각해요.
어디가 문제인지는 퍼널이 알려 주지만, 왜 문제인지는 사용자 관찰이나 인터뷰 같은 정성 자료가 필요해요.
그래서 저는 퍼널로 구간을 좁힌 다음 정성 자료로 이유를 찾는 순서를 기본으로 삼고 있어요.

퍼널을 정기적으로 보는 습관도 중요해요.
한 번 분석하고 끝내면 지난번에 고친 구간이 정말 나아졌는지 확인할 수가 없으니까요.
저는 주요 퍼널을 월 단위로 같은 형식으로 뽑아서 변화를 비교해 봅니다.
개선 전후를 비교할 때도 기간과 세그먼트 조건을 맞춰야 한다는 점을 잊지 않으려고 해요.

아직 고민되는 건 퍼널 단계가 고정되지 않는 서비스예요.
사용자가 이리저리 오가며 목표에 도달하는 서비스에서는 일직선 퍼널이 현실을 잘 담지 못하거든요.
그런 경우에는 경로 분석 같은 다른 방법을 함께 써야 할 것 같아서, 다음 글에서 이어서 정리해 보려고 해요.