[인프런] PM을 위한 데이터 리터러시_#14. Case Study + 고민 상담소

📌 이 글은 [인프런] 카일스쿨의 'PM을 위한 데이터 리터러시' 강의 내용을 요약 정리한 것입니다.

쏘카 차량 예약 퍼널 개선기

• 자세한 내용은 쏘카 PM의 차량 예약 퍼널 단계 개선기(feat. AB TEST) (opens new window)에서 확인할 수 있습니다!
  • 쏘카 CPO님에게 사용 허락을 받았습니다

쏘카 소개

• 국내 1위 카쉐어링 서비스
• 2023년 1월 기준 여러 서비스가 존재
  • 왕복 대여
  • 여기로 부르기(부름)
  • 장기 대여(쏘카 플랜)
  • 쏘카-KTX
  • 숙박(쏘카 TO-GO)
  • 쏘카 비즈니스
  • 패스포트
  • 퇴출근패스

쏘카 PM의 문제 해결 방식

• 문제 확인 : 왜 사용자는 이렇게 생각할까?
• 가설 도출 : 문제의 원인은 이거였구나
• 가설 검증(AB Test 등) : 이 방법을 시도해보고 결과가 달라지는지 확인하자
• 개선안 적용 : 좋은 결과를 더 많은 고객에게 전달하자

문제 정의를 하는 과정

• 왕복 대여 서비스
  • 최초로 만든 서비스
  • 사용자가 직접 쏘카존에 이동해 차량을 픽업하고 사용하는 흐름
• 부름 서비스
  • 사용자가 집 앞으로 차를 부르고, 차량이 지정한 장소로 호출
  • 왕복 서비스 이후 사용자의 편의를 위해 런칭한 기능
• 왕복 대여 서비스와 부름 서비스는 Flow, UX를 거의 유사하게 공유하고 있었음
• Key Question : 과연 사용자에게 최고의 경험일까?
• 회사의 목표
  • 회사의 성장
  • 부름 예약량 증가
• 상황
  • 1년간 예약 지표가 정체되고 있음
• 부름 서비스를 사용할 수 있는 경로
  • 1. 쏘카존을 클릭한 후, 차량 리스트에서 부름 차량 선택 => 결제 정보 확인 페이지 
    2. 부름 PIN을 이동한 후, 차량 리스트에서 부름 차량 선택 => 결제 정보 확인 페이지
  • "두개의 페이지 전환율 차이가 존재" : 1은 20%, 2는 70%
• 사용자 Segment 분석, 전화 인터뷰, 사용성 Test 진행
  ㄴ 부름 사용자의 3-40대 비중이 약 10% 높음, 부름 차량의 예약 시간이 2.3배 더 김
  ㄴ TPO(Time, Place, Occasion- 언제 사용하는가?): 차에 실어야 할 짐이 있는 경우, 동행이 많은 경우, 야간에 대여하는 경우 
  ㄴ 매력 포인트: 위 상황에서 명확하게 부름을 사용, 쏘카존까지 걸어가지 않아도 되는 장점을 느낌 
  ㄴ 사용성 테스트(사용자들이 기존 앱을 어떻게 사용하는지, 무슨 생각을 하는지 수집): 부름 서비스 사용해보지 않은 경우 - "둘러보기는 했으나 이해하기 어렵다"

최종 문제 정의

• 사용자가 부름 서비스에 대한 인지 부족
• 서비스를 사용하지 않은 사람들은 부를 때 어떤 일이 생기는지, 회사가 어떤 방지책을 제공하는지 알기 불안함
• 한번도 부름을 써보지 않은 사용자들이 특히 어려워한다(신규 유저)
• 해결 방법: 부름 예약 페이지 리뉴얼 
  • 부름만의 매력을 직관적으로 전달하기
    ㄴ 페이지 진입 후 바로 서비스에 대한 직관적인 설명(ATF 영역에 노출) "챙길 짐이 많은 날엔 차를 집 앞으로 불러보세요"
    ㄴ 서비스를 나타내는 워딩 사용: 비즈니스 모델을 바로 이해 가능 "언제, 어디로 가져다 드릴까요?"
  • 불안감을 낮출 수 있는 예약 경험 제공하기
    ㄴ 서비스에 대한 안내 문서를 여는 배너 적극 노출 "(예약부터 차근차근 알려드려요!) 부름 이용방법" 

AB Test

• 사람들의 불안함: 이게 정말 올바른 문제 해결 방법일까요?  
  • 사람들의 우려점 
    ㄴ 갑자기 예약 과정을 다 바꿔버려도 될까요?
    ㄴ 기존 사용자들이 적응하지 못하고 이탈하면 어떡하죠? 이 UX를 사용자들이 좋아할거라 어떻게 확신할 수 있어요?
    ㄴ 혹시나 잘못되면 원래 유지되던 예약률은 방어할 수 있을까요? 
  • AB Test를 통해 목표가 달성되는지 확인 후, 전체 배포 여부를 결정하자!

 

이 사례에서 배울 점

• 문제를 구체화하기 위해 데이터를 확인하고, 사용자에게 인터뷰, 사용성 테스트를 진행한 점(정량적/정성적 데이터 분석)
• 가설을 만들고 그걸 확인하기 위해 점진적인 AB Test를 진행한 점
• AB Test의 결과에 따라 의사 결정한 점
• 전사의 방향과 Align된 상황에서 진행한 프로젝트
• 프로젝트를 하면서 많은 사람들을 설득하고 끝까지 Action한 점

 

주어진 목표를 쉽게 해결하는 방법에 집중했다면
지속 불가능한 방법을 택했을 것
(안내 문구 더 잘 보이게, 가격 내리기 등)
=> 무엇을 해결할지를 찾는 부분에서 
사용자와 많은 대화를 진행했다!

 

---

콴다 팀의 실험 플랫폼과 Metrics Store

• 자세한 내용은 아래 링크에서 확인할 수 있습니다!
• QANDA Team의 실험 플랫폼, QXP를 소개합니다.(opens new window)
• 실험 의사결정 가이드 자동화 : QXP Tracker(opens new window)
• Metric을 체계적으로 관리하기 : Metrics Store(opens new window)
  • 콴다 데이터팀 팀장님에게 사용 허락을 받았습니다

콴다 팀 소개

• 한국 초,중,고 3명 중 2명이 쓰는 국민 교육 앱
• 50여개 국가, 8개 언어로 서비스 중인 글로벌 앱

콴다 실험 플랫폼(QXP - QANDA eXperimentation Platform)

• QXP
  • 실험 진행
  • QXP Admin
  • 실험 결과 집계(Tracker)
• 별개로 Metrics Store가 존재하며, 실험 플랫폼과 같이 사용할 수 있음

• Metric을 저장하는 Metrics Store와 QXP가 연동되어서 지표 정의할 때 쉽게 활용할 수 있음

• 실험 시작 후, 매일 실험 Reporting을 통해 사람들의 Action 촉구
• 실험 관련 가이드라인, 지표를 확인할 수 있는 곳을 제공

• Holistics의 Dashboard를 사용해서 실험 지표를 확인함
• Dashboard Template이 존재하고, 이것을 복제한 후 실험 ID만 변경해서 실험 지표를 확인함

• 실험 결과 집계 과정은 QXP Admin에 선언된 성공 지표, 가드레일 지표를 가지고 Metrics Store로 결과 집계한 후 Decision Tree로 의사 결정

• 콴다 팀의 실험 Decision Tree

이 사례에서 배울 점

• Metrics Store + 실험 플랫폼을 연계해서 구현한 점이 매우 인상적
• 실험 의사 결정을 위한 자동화 진행
  • Dashboard 템플릿
  • 의사 결정 Decision Tree
  • 지표 슬랙 알림
• 실험 Decision Tree를 가지고 자동으로 계산
• 데이터 인프라를 통해 문화를 쌓고 있다는 것을 보여주는 사례(글에서 BigQuery에서 어떻게 구현했는지 나옴)

---

고민 상담소

1. UX 대규모 개편 시 고려해야 하는 것은 무엇일까요?

• Key Question: 지표의 기준이 변하는가? 
  ㄴ 기존에 사용하던 지표를 계속 사용해도 되는가?
  ㄴ 새로운 서비스가 생겼는가?, 퍼널을 다시 정의해야 하는가?
  ㄴ 어떻게 정의할 것인가? 
• 많은 제품들이 슈퍼 앱으로 성장 중 
  ㄴ 슈퍼 앱: 하나의 앱으로 여러 서비스를 사용할 수 있는 앱 
  ㄴ 토스, 쏘카, 우버, 마이리얼트립, 야놀자 등
  ㄴ 각 라인업 별로 Active User를 세분화해서 정의해야 할 수도 있음 
• Key Question: 로그가 변하는가? 새롭게 추가해야 하는 로그는 무엇인가? 
  ㄴ 로그의 변화로 기존 지표가 달라지면 안 됨. 
  ㄴ 로그 또는 DB의 데이터를 활용해 데이터 오퍼레이션을 하고 있다면 과거 로그는 그대로 두고, 새로운 부분을 만들어야 함.
• 제품 분석 
  ㄴ 대규모 개편 시 사람들의 사용 패턴이 변경되는가?
  ㄴ 대규모 개편으로 우리가 달성하고자 하는 목표는 무엇인가? (= 성공 지표는 무엇인가?)
• Action Plan
  ㄴ 로그, 지표 관점에서 개선할 부분 고민해보기 
  ㄴ 배포한 후 어떻게 될지 멘탈 시뮬레이션 해본 후 어떤 것이 필요한지 고민하기
  ㄴ 대규모 개편 후 사용성이 좋아졌는지 어떻게 확인할지 지표 다시 생각해보기

 

2. 상사 드리븐 의사결정, 직관 의사결정만 하는 회사, 어떻게 해야 할까요?

• 우선, 현재 회사의 상황을 확인하자!
  ㄴ 1) 회사가 데이터를 볼 상황이 되는지 
  ㄴ 2) 다른 분들은 왜 그렇게 하고 있는지 파악
• 데이터 리터러시는 "직관과 데이터를 모두 활용하는 방식"임 
  ㄴ 직관이 맞는 경우도 있고, 데이터가 맞는 경우도 있으니 모두 잘 활용하는 것이 핵심
• 대화의 중심이 우리가 아닌 다른 회사, 트렌드에 맞춰져서는 안 됨 
  ㄴ 다른 회사가 이렇게 하니까 우리도 해야 해요 (X) 
  ㄴ 이렇게 요즘 많이 한다고 해요 (X)
  ㄴ 우리의 상황에 초점을 맞추고, 그 상황에서 서로 보완하는 방법으로 진행 
• 상대방을 이해하고 존중하며, 변화를 위한 대화를 시도하는 것부터가 변화의 시작! 

 

3. 보고 싶은 것, 하고 싶은 것이 너무 많아요

• 발산 후 (정리하는) 수렴을 꼭 진행하기
  ㄴ 발산만 하고 수렴을 거의 하지 않은 상황일 수 있음  
• "목적 중심" 사고를 다시 떠올리기
  ㄴ "이 지표가 우리 제품을 만드는 목적에 부합하는 지표가 맞나? 
• 너무 고민이 많은 경우엔 "일단 하나씩 해보기, simple하게 생각하기" 

4. 우리 회사는 데이터 엔지니어, 데이터 분석가가 없어요 어쩌죠?

• 우선 지금 할 수 있는 것에 대해 생각해보기 
  ㄴ 제품에서 핵심으로 볼 지표 정의 
  ㄴ 데이터 로그 설계, GA, Firebase 등 
  ㄴ Amplitude, Mixpanel
  ㄴ DB의 데이터를 BI 시각화 
• 개발자분들과 협업해서 하나씩 만들기 
• 그 후 데이터 직무 채용 시작
  ㄴ 데이터 엔지니어(인프라 마련) -> 데이터 분석가