이전 챕터에서는 문제를 정의하고 가설을 수립한 뒤 검증하는 과정을 정리했었다.
하지만 좋은 가설도 결국 데이터가 있어야 검증할 수 있다.
이번 챕터에서는 사용자의 행동 데이터를 분석하는 대표적인 방법인
퍼널 분석(Funnel Analysis)과 AARRR 프레임워크를 살펴보고,
데이터를 어떻게 해석하고 의사결정에 활용해야 하는지 정리해보려 한다.
[게시글 목차]
1. 퍼널 분석(Funnel Analysis)
◾예시. 회원가입 퍼널
◾퍼널 분석 활용 방법
2. AARRR
◾예시. 배달앱
3. 퍼널 분석과 AARRR 비교
4. 데이터 분석 시 주의할 점
◾CASE 1. 데이터가 이상할 때
◾CASE 2. 지표 하나만 보고 판단할 때
5. PM의 우선순위 판단
◾판단 기준
6. 협업 갈등과 의사결정
◾갈등 해결 원칙
[개인적인 갈등 해결 Tip - 팀원 질문에 대한 답변(문체 거의 그대로 유지)]
1. 퍼널 분석(Funnel Analysis)
- 퍼널(Funnel)은 사용자가 목표 행동에 도달하기까지의 과정을 단계별로 분석하는 방법이다(Like. 깔때기).
- 사용자가 서비스에 들어와 최종 목표(회원가입, 구매, 예약 등)에 도달할수록 인원이 줄어드는 형태를 보인다.
◾예시. 회원가입 퍼널
| 단계 | 사용자 수 | 전환율 |
| 회원가입 버튼 클릭 | 10,000 | 100% |
| 약관 동의 | 8,500 | 85% |
| 이메일 입력 | 7,800 | 78% |
| 인증 완료 | 5,300 | 53% |
| 회원가입 완료 | 4,900 | 49% |
| → 인증 단계에서 가장 많은 사용자가 이탈하고 있음을 확인할 수 있다. | ||
◾퍼널 분석 활용 방법
| 단계 | 질문 |
| 목표 정의 | 무엇을 분석할 것인가? |
| 단계 정의 | 사용자는 어떤 순서로 행동하는가? |
| 이탈 분석 | 어디에서 가장 많이 이탈하는가? |
| 개선안 도출 | 이탈 원인은 무엇인가? |
| → 단순히 전환율이 낮다는 사실을 아는 것에서 끝나는 것이 아니라, 어느 단계에서 문제가 발생하는지 찾을 수 있기 때문에 중요하다. |
|
2. AARRR
- AARRR은 서비스 성장 과정을 분석하는 대표적인 프레임워크다.
- 스타트업 투자자 Dave McClure가 제안하여 '해적 지표(Pirate Metrics)'라고도 불린다.
| 단계 | 의미 | 대표 질문 |
| Acquisition | 유입 | 사용자는 어디서 왔는가? |
| Activation | 활성화 | 첫 경험은 만족스러웠는가? |
| Retention | 유지 | 다시 방문하는가? |
| Revenue | 수익 | 돈을 지불하는가? |
| Referral | 추천 | 다른 사람에게 추천하는가? |
| → 서비스 전체 성장 흐름을 한눈에 볼 수 있기 때문에 중요하다. 퍼널이 특정 기능의 문제를 분석한다면, AARRR은 서비스 전체의 성장 구조를 분석한다. |
||
◾예시. 배달앱
| 단계 | 의미 | 예시 |
| Acquisition | 유입 | 광고를 보고 앱 설치 |
| Activation | 활성화 | 첫 주문 완료 |
| Retention | 유지 | 재주문 |
| Revenue | 수익 | 결제 발생 |
| Referral | 추천 | 친구 초대 |
3. 퍼널 분석과 AARRR 비교
| 구분 | 퍼널 분석 | AARRR |
| 목적 | 특정 행동 분석 | 서비스 성장 분석 |
| 범위 | 기능 단위 | 서비스 전체 |
| 활용 예시 | 회원가입, 구매 | 사용자 성장 |
| 주요 질문 | 어디서 이탈하는가? | 어디서 성장이 멈추는가? |
| ex. - 회원가입 완료율이 낮다 ⤷ 퍼널 분석 : 회원가입 버튼 → 약관 동의 → 이메일 입력 → 인증 → 완료 - 재방문율이 낮다 ⤷ AARRR : Acquisition → Activation → Retention |
||
4. 데이터 분석 시 주의할 점
- 데이터가 있다고 해서 항상 올바른 결론이 나오는 것은 아니다.
◾CASE 1. 데이터가 이상할 때
- ex. 어제 구매 건수 : 1,000건 / 오늘 구매 건수 : 0건
→ 바로 결론 내리기 X- 로그 수집 오류 여부
- 배치 작업 실패 여부
- 이벤트 누락 여부
- 데이터 적재 오류 여부
→ 먼저 확인 / 데이터 분석 전에 데이터 품질 검증이 우선이다.
◾CASE 2. 지표 하나만 보고 판단할 때
- ex. 클릭률 증가 → 좋은 결과? NO... 반드시 그렇지는 않다.
- 확인할 항목 : 구매 전환율 / 이탈률 / 체류시간 / 재방문율
→ 하나의 지표만 보면 잘못된 결론에 도달할 수 있다.
5. PM의 우선순위 판단
- 실무에서는 여러 문제가 동시에 발생한다.
ex. 상황 A : 앱이 일부 사용자에게 느림 + 상황 B : 결제가 불가능함 → 둘 중 무엇을 먼저 해결해야 할까?
⤷ 대부분의 경우 '결제 불가'가 우선이다.
◾판단 기준
| 항목 | 의미 |
| Impact | 사용자 영향도 |
| Business Value | 비즈니스 영향 |
| Urgency | 긴급성 |
| Effort | 해결 난이도 |
| → PM은 단순히 중요한 문제가 아니라, 먼저 해결해야 할 문제를 찾아야 한다. | |
6. 협업 갈등과 의사결정
- PM은 개발자, 디자이너, 데이터 분석가 등 다양한 이해관계자와 협업한다.
- 따라서 의견 충돌도 자주 발생한다.
(어느 정도는 내려놓는 마음가짐이 필요하다... 그래, 그럴 수도 있지...)
- BAD 접근 : 내 생각에는 이게 맞음(일방적 의견 강요)
- GOOD 접근 : 데이터 기준으로 보면 A안의 전환율이 더 높음
(물론 실제로는 사람(상황/개인 성향)에 따라 대응이 다르게 나올 수밖에 없다)
◾갈등 해결 원칙
| 원칙 | 설명 |
| 감정과 사실 분리 | 의견보다 근거 중심 |
| 데이터 활용 | 검증 가능한 정보 사용 |
| 목표 정렬 | 공통 목표 확인 |
| 기록 남기기 | 의사결정 과정 공유 |
| → PM은 정답을 가장 많이 아는 사람이 아니라, 다양한 의견을 모아 더 나은 의사결정을 이끌어내는 조율자에 가깝다. |
|
[개인적인 갈등 해결 Tip - 팀원 질문에 대한 답변(문체 거의 그대로 유지)]
Q. 논리적으로 설득을 시도했는데 상대가 감정적으로 나올 경우 어떻게 해결하시는지?
일단 감정적으로 번진 상황이면 논리적인 소통이 불가한 경우라고 생각하고 삭힐 시간을 좀 드립니다…
‘10분 정도 쉬고 다시 할까요?’ 이렇게 일단 해보고, 그래도 감정이 잘 안 삭혀진다 하면
‘도저히 이대로는 소통이 불가능하다/이대로 진행해도 일이 되지 않을 것 같다’로 판단하고 미팅 일자를 다르게 잡아요.
좀 시간을 주면 집에 가서 밥도 먹고 일상생활을 하다보면(본인도 곱씹어 보시겠죠…? 그러길 바라봅니다) 침착해져서 오는 경우도 있고 아닌 경우도 있더라구요.
아닌 경우는 서면으로 각자 의견을 받아서 조율자가 처리하거나 1:1 면담을 진행하기도 합니다…
(정말 귀찮고 번거롭고 싫은 상황………………..가뜩이나 전 감정 공감도 못하는데!!!!!!!)
근데 갑자기 사람이 변하면…. 아시죠? 사람은 엄청 큰 계기가 있지 않는 한 잘 안 변합니다…ㅠㅠ
계속 문제가 되는 인원들이 또 눈 굴리듯이 문제를 일으키는 경우가 많죠.
넘나 슬픔…
+) 예전엔 나도 상대가 감정적으로 나오면 좀 반응하고 그랬는데 나름의 룰을 정했다.
그냥 그런가 보다... 하는 귀찮음 이슈와 더불어 요즘 친구들은 자유롭구나...를 반영한 사고와
3번까진 지켜보자는 삼진아웃룰을 자체적으로 진행하고, 3번 이상 상대가 도를 넘는다 싶으면
(나도 가급적 하고 싶지 않지만, 더는 일이 불가하다고 판단되면/팀원들의 민원이 통제 불가 상태로 진전되면/내부적으로 많은 방법을 시도했으나 도저히 해결되지 않을 때/기업에도 타격이 간다고 생각되면(ex. 장시간 회의로 심신이 지쳐 업무에 차질이 장기적으로 반복해서 발생하는 경우/시간적 비용은 곧, 매출에 직접적인 영향을 끼치기도 하니까) 등등 여러 요인을 복합적으로 분석한 뒤에)
(최후의 보루)보다 상위 부서에 그간 모은 정황을 제출하고 개입해서 중재해 주길 간곡히 청한다.
(이건 나에게도 리스크가 발생하기 때문에(일단 구두로도 상황을 전달해야 하고 상위 부서에서도 파악을 위해 자주 불려 간다...) 진짜 더는 손을 쓸 수 없는 자연재해와도 같은 상황일 때 사용하길 권장한다. 사실 안 하는 게 베스트. 근데 팀원들의 업무 환경 개선을 위해 내가 리스크를 감수하는 한이 있어도 문제를 해결하고 싶다면 그땐 사용하는 게 개인적으로 맞다고 생각한다.)
++) 요즘 궤도님 영상이 알고리즘에 자주 떠서 보는데,
내용이 물론 흥미롭긴 하지만 나는 개인적으로 궤도님의 소통 방식이 더 흥미롭다.
어떤 질문이 들어와도 궤도님은 그 질문을 존중하고 최대한 진지하게 답변을 해주신다.
그게 막힘없이 진행된다는 점이 더욱 놀랍다(반응 속도 무엇...뇌를 거치긴 하는 걸까).
근데 들어보면 좀 웃기는 부분도 있는데 납득이 된다.
상대의 의견을 존중하고 이해하며 진지하게 임하는 태도를 배워야겠다고 생각했다.
'PM Notes > 내용정리' 카테고리의 다른 글
| 특강+Q&A) A/B 테스트(감(感)이 아니라 데이터로 의사결정하기) (0) | 2026.06.15 |
|---|---|
| 서비스 기획 숙련 4. 프로젝트 운영과 협업(킥오프, 공유, 회고)+개인적인 업무 공유/회의록 작성 Tip (0) | 2026.06.11 |
| 특강) PM의 데스크 리서치 : 정보의 편린에 휩쓸리지 않고 판을 읽는 법 (0) | 2026.06.09 |
| 서비스 기획 숙련 2. 데이터 수집과 로그 설계 (0) | 2026.06.09 |
| 서비스 기획 숙련 1. 데이터의 중요성 (0) | 2026.06.08 |