서비스의 오늘과 어제는 매우 다르다
작가에 대한 간단 소개
자란다에서 UX 기획자, PM으로 근무 중, “프로그램”이라는 스쿼드에서 일하고 있어요
유저의 문제, 니즈를 발견하여 이를 제품으로 해결하는 것
우리는 유저의 니즈가 뭔지 단지 예측으로만 알 수 있습니다.
런칭하기 전까지 유저는 직접 말해주지 않아요
그렇다면 우리는 유저의 문제를 “뭐”를 통해 정의하고 확인해야 할까요?
제일 좋은 방법 중 하나가 “데이터” 입니다
세부적으로는 어떤 데이터를 봐야 내가 세운 가설을 확인할 수 있는지 검토하기 위해서
수집된 데이터 중 무엇을, 어떻게 봐야 올바로 확인할 수 있는지 이해하기 위해서
검증된 결과를 바탕으로 이해관계자들을 설득하기 위해서
고객이 당신의 제품으로 무엇을 하는지에 대한 이해는, 고객을 파악하는데 큰 비중을 차지한다, 대부분의 제품 관리자는…(중략) 30분 정도의 시간 동안에 지난 24시간 동안 무슨 일이 일어났는지를 파악한다. (출처 : 인스파이어드 - 마티 케이건)
우리는 제품을 길게 보지만, 유저들은 매일 보고 있지 않다는 사실을 깨닫게 되었습니다.
그저 사용하고 있는 서비스 중 하나일 뿐이죠. 따라서 유저의 오늘과 어제는 매우 다릅니다.
우리의 지표는 아름답게 우상향 하지 않고 당연히 굴곡이 있을 수 밖에 없습니다.
이럴 때 프로덕트 팀은 해당 프로젝트의 KPI를 이뤘나도 중요하지만, 그 과정에서 유저들이 무엇을 학습했고, 무엇 때문에 이탈했는지 파악하는 것도 중요합니다.
매일 매일 이런 부분을 파악하면 유저의 행동 패턴 파악과 즉각적인 제품 대응을 할 수 있게 됩니다
유저가 어떤 행동을 하는지 수집하고 이러한 흔적을 분석해 잠재고객의 행동 패턴을 파악합니다.
고객의 행동 패턴을 분석하게 되면 다음의 3가지 분석기반의 전략활동을 시도할 수 있습니다.
1. 패턴으로 파악한 트렌드의 원인을 파악하고, 그 인사이트를 가지고 서비스/프로덕트의 목표 달성에 필요한 가설을 수립할 수 있습니다.
2. 분석 인사이트를 실시간 알림이나 푸싱 메시지에 적용하여 구매 혹은 전략적 유의미한 고객의 행동으로 연결할 수 있습니다.
3. 관련 부서에게 이 분석 인사이트와 데이터셋을 공유해 여러 관점에서 더 깊은 분석을 유도할 수 있습니다.
(출처 : 믹스패널로 제품과 사용자행동 분석하기)
무작정 데이터를 수집하기보단, 어떤 목적에 따라 이 데이터가 필요한지 검증하면서 디깅해보면 좋습니다
성공 지표 : 기존 운영되던 제품인 경우 기존의 여러 지표들을 기반으로 학습된 상향식 예측을 통해 핵심 지표에 대한 목표치를 수립할 수 있습니다.
모니터링 지표 : 성공 지표에 상관 관계가 있는 지표를 의미합니다.
가드레일 지표(전사 공동 지표) : 보통 전사에서 공통적으로 보는 지표를 의미합니다. 모든 도메인이 존재하는 이유는 가드레일 지표에 기여하기 위함이므로 이를 확인하여 Sync를 맞추는게 중요합니다.
사용자 분석 툴 : Mixpanel, Amplitude 흔히, Event라는 개념이 있는 툴
데이터 시각화 툴 : Tableau, Redash
대부분 내부 DB에 기반한 정보를 볼 때 활용합니다.
사용자 분석 툴로 확인할 수 없는 지표를 볼 때 유용합니다 (ex. 매출, 객단가)
핵심 지표들의 이상 유무를 살피고, 추가적으로 살펴본 데이터들을 정리합니다.
이 과정에서 정기적으로 팀에 공유하는게 중요합니다.
지표 미팅이나, 비동기적 공유를 통해, 해당 지표가 나만의 고민이 아닌, 전체 팀이 꾸준히 고민하는 주춧돌이 되도록 만듭니다.
사용자들의 모든 행동은 인과와 상관 관계가 있다는 사실을 알 수 있었습니다.
이 문제를 해결하기 위해 아래와 같이 다양한 사용자 행동 데이터를 수집하고 분석을 합니다 사용자가 수업을 신청할 때 어떤 퍼널에서 정체하는지 언제 어떤 과목을 가장 많이 파는지 특정 연령대에서 잘 팔리는 과목이 있는지 수업을 신청하고 실제 방문까지 이어지는 비율이 얼마나 되는지 얼마나 있어야 다시 수업을 신청하는지
우리가 사용하고 보는 제품들은 육하원칙에서 What을 보여주고 있습니다.
프로덕트 팀은 보통 How를 위주로 생각하지만, 이보다 더 중요한 것은 Why라는 사실을 깨달았습니다. 결국 제품을 만드는데 있어서 가장 중요한 것은 고객 비즈니스 제품의 목표가 한 방향을 바라볼 수 있도록 하는 것이라는 사실도 알게되었습니다
데이터를 보면서 가장 좋았던 것은 올바른 문제 정의를 정확하고 빠르게 할 수 있는 것이었습니다
매일 데이터를 보게 되면서, 1) 실제 제품에 버그가 있는 부분이 있거나, 2) 지표에 유의미한 인사이트가 있을 때 가장 먼저 알 수 있게 되었습니다.
데이터를 보기 전에는 되게 내가 만드는 프로덕트가 너무 막연하게만 느껴지고, 검증되지 않은 기분이 들 때도 많았습니다
데이터를 보며 내가 만든 프로덕트가 매일 매일 살아있다는 증거들을 보며 좀 더 모티베이션이 되었습니다.
또한, Why를 이해하고 프로덕트를 만들었을 때, 좀 더 세밀하게, 책임감을 가지고 만든 프로덕트가 더 성과가 좋았던 경험도 얻게 되었습니다.
좋은 팀은 그들의 비전과 목표, 고객 불편의 관찰, 제품을 사용하면서 고객들이 만들어 낸 분석 데이터, 문제를 해결하기 위해 새로운 기술을 끊임없이 탐색하는 과정을 통해 영감과 제품 아이디어를 얻는다. 나쁜 팀은 영업과 고객으로부터 요구사항을 수집한다. (출처 : 인스파이어드 - 마티 케이건)
코호트는 획득 날짜, 제품 유형 또는 행동과 같은 공통 특성을 공유하는 유저 그룹입니다
공통적인 이벤트 형태로 설정할 수 있고, 다른 데이터를 확인할 때 해당 Cohort 그룹의 데이터를 구분해서 파악할 수 있습니다.
코호트를 잘 이용하면, 서비스를 잘 이용하는 유저 군을 확인하고 잠재 유저에게 비슷한 행동을 유도하여 새로운 유저를 확보할 수 있습니다
활용 방법
B라는 기능을 런칭한 기획자 김아이, 매일 지표를 보다가 최근 들어 서비스를 이용하지 않은 Cohort 들이 B 페이지에 많이 인입됨을 발견
이에 맞춰 해당 기능을 Inflow 용도로 활용할 수 있지 않을까? 하는 가설을 세움