프로덕트 분석 프로세스

 

1. 지표(KPI) 기반 상태 진단

지표 설정 기준

EX. 목표: 온보딩 기능(유료 회원 증가 → 수익 극대) 
(신규 사용자가 서비스를 처음 접했을 때 서비스의 핵심 가치를 이해하고 정착할 수 있도록 안내하는 초기 경험 과정 )

- 기능이 잘 작동하는지 판단하는 기준이 되는가

정보수집(KPI) GOOD , 신규 유입자수(KPI) BAD, 회원가입자수 GOOD

- 비즈니스의 핵심 목표와 잘 연결되는가

정보수집(KPI) 온보딩 과정이 복잡하여 BAD, 신규 유입자수(KPI) GOOD, 회원가입자수 GOOD

 

대시보드(tableau, Amplitude)를 통해 트래킹

- 지표를 볼때 특정 추세 및 장기적인 추세를 모두 고려해서 트레킹

- 절대 지표(ex. 신규 유입자 수, 회원 가입자 수),  비율 지표(ex. 회원 가입자 수 / 신규 유입자 수) 모두 참고 

 

 →   회원 가입자 수 / 신규 유입자 수 감소, 회원 가입자 수 감소 시, 온보딩 기능 문제 확인

 

2. 문제 발견 & 데이터 기반 원인 탐구

ex. 가설설정, 특정 유저그룹, 및 단계에서 원인 탐구 및 정성적인 인터뷰 수행

다양한 관점, 데이터 기반 탐지 방법

1. 시간의 흐름에 따른 변화 확인: 시점별 이벤트 확인

2. 유저 세그멘테이션 : 인구통계학적 특성, 유입 시점, 행동특성에 따라 분석

3. 퍼널 분석: 퍼널 단계 정의(논리적인 행동 순서에 따라) → 기간 정의 → 단계별 유저 수 집계

 

 →   퍼널 분석으로 인해 환영 인사, 플랜 설정 단계에 문제 확인

 

3.해결 방안 도출

 → 디자인의 변화

4.기능 구현 :

기능이란 구체적인 컴포넌트가 아닌 사용자가 서비스에서 경험하는 일련의 흐름과 가치 EX.결제 전체 흐름

 

*데이터 수집이 원활하게 되어야함. 사용자 행동 로그는 담당자가 따로 적재해야함. 

-> 기능이 추가될때 마다 기능 구현 단계에서 담당자가 로그 설계(로깅)으로 적재하기 위해 작업해야함.

+) 배포 전에 a/b테스트 진행

a: 기존안 , b:개선안 으로 설정하여 정확히 같은 시기, 유저 랜덤 배정하여 다른 영향 배제하기에 비교적 정확한 성과 판단 가능

결과)

- 기존안 < 개선안: 전체 유저 대상 배포

- 기존안 > 개선안: 롤백

- 기존안 ~= 개선안: 전체 유저 대상 배포 or 롤백 or 재실험 (비즈니스 판단)

 

* a/b테스트가 불가능한 경우 

- 유저 수가 너무 적은 경우

- 유저가 랜덤하게 분리하기 어려운 경우

- 윤리적 문제나 반발 예상되는 경우

- 비즈니스 판단에 따라 하지 않은 경우

 

→ 배포 후 성과 분석 진행(확신이 아닌 추정에 가까움)

따라서 아래와 같은 분석을 진행함

- 변화를 겪지 않은 그룹과 변화를 겪는 그룹을 확보할 수 있다면 비교(앱 업데이트 여부)

- 시간의 흐름에 따른 변화 보정

: 과거의 현재와 유저 구성이 다른 경우 어려움 →  과거의 유저 구성과 현재의 유저 구성을 의도적으로 비슷하게 분류

5.배포

6.개선안의 성과 평가:

인사이트 정리해 추후 참고/ 빠르게 대응 조치 -> 다시 지표 기반 상태 진단으로 돌아감

 

배포 전에 a/b테스트 진행

a: 기존안 , b:개선안

-> 이외의 다른 영향을 배제하기 때문에 (정확히 같은 시기, 유저 랜덤 배정)하여 비교적 정확한 성과 판단 가능

결과)

- 기존안 < 개선안: 전체 유저 대상 배포

- 기존안 > 개선안: 롤백

- 기존안 ~= 개선안: 전체 유저 대상 배포 or 롤백 or 재실험 (비즈니스 판단)

 

+) a/b테스트가 불가능한 경우

: 유저 수가 너무 적은 경우, 유저가 랜덤하게 분리하기 어려운 경우, 윤리적 문제나 반발 예상되는 경우, 비즈니스 판단에 따라 하지 않은 경우

-> 배포 후 성과분석 진행(확신이 아닌 추정)

- 변화를 겪지 않은 그룹과 변화를 겪는 그룹을 확보할 수 있다면 비교(앱 업데이트 여부)

- 시간의 흐름에 따른 변화 보정: 과거의 현재와 유저 구성이 다른 경우 어려움-> 과거의 유저 구성과 현재의 유저 구성을 의도적으로 비슷하게 분류