실전 스타트업 데이터분석: 소셜데이팅 이음은 이렇게 한다

실전 스타트업 데이터분석: 소셜데이팅 이음은 이렇게 한다 from 승화 양

실전 스타트업 데이터분석: 소셜데이팅 이음은 이렇게 한다

1. 1. 실전, 스타트업 데이터분석 소셜데이팅<이음>은이렇게한다 이음소시어스 양승화
2. 2. 이 프리젠테이션은 2014년 3월 20일 D.Camp에서 진행된 ‘실전 스타트업 데이터분석: 소셜데이팅 이음은 이렇게 한다’ 강의 자료입니다. 애초에 강의용으로 만들어진 자료라서, 해설 없이 보시기에 그리 친절하진 않지만 ^^;;; 전체 큰 맥락을 파악하시는데는 무리가 없을 것으로 생각됩니다. 설명 없이 자료만 보는 경우 의도하지 않은 내용이 전달될 우려가 있어서 회사 내부데이터가 포함된 일부 페이지는 수정/보완 후 공유함을 알려드립니다. 내용에 대한 문의/피드백은 leoyang@i-um.net으로 해주세요! 이 자료는…
3. 3. 양승화 leoyang@i-um.net 이음소시어스 이음본부 본부장 (전) 이음소시어스 데이터운영팀 팀장 (전) 이음소시어스 기획팀 쩌리 (전) NHN UX랩 선임연구원 발표자
4. 4. 맥주와 기저귀 포토그래퍼와 Airbnb 서울시와 심야버스 데이터분석 세미나, 재미있긴 한데… “무엇을”에 대한 이야기는 해 주지만, “어떻게”에 대한 이야기는 듣기 힘들다.
5. 5. 이음 누적 다운로드 150만 총회원 110만 누적 연결된 커플(상호 OK) 120만 쌍 공식 결혼커플 104쌍 매출 많음 먹고 살 만큼 우리나라 최초의 소셜데이팅 서비스 카피캣 100개까지 세다가 포기 정식 런칭 2010년 11월~ 소셜데이팅 <이음> 1. 최초가 늘 최고가 되는 건 아닌데… 수많은 카피캣들이 여전히 이음을 이기지 못하는 이유는? 2. 런칭 후 3개월/6개월에 정점을 찍고 떨어지는 서비스와 달리 이음이 4년 가까이 꾸준한 성장을 기록할 수 있는 이유는?
6. 6. 서비스 운영 Framework 셋업하기 Log를 Metric으로 만들기 OMTM 설정하기 데이터 들여다보기 무슨 데이터를, 어떻게 쌓아야 하나? 어떤 시점에 어떤 방식으로 데이터를 분석해야 하나? ‘스타트업’ 데이터분석 많은 세미나에서 “데이터 들여다보기” 단계에 대해 주로 이야기하지만 사실 중요한 건 1단계부터 차근차근 쌓아가는 것.
7. 7. User AU (Active User) 활동유저. 일반적으로는 ‘접속’을 기준으로 이야기하며, DAU를 의미하는 경우가 많음. DAU (Daily Active User) 일별 활동 사용자. 하루를 기준으로 활동하는(=접속한) 사람의 숫자라고 보면 됨. 많은 서비스들이 공통적으로 key metric으로 생각하는 중요한 지표. MAU (Monthly Active User) 월별 활동 사용자. 해당 월에 최소 1회 이상 접속한 사람의 숫자 (cf. WAU = Weekly Active User) MCU (Maximum Current User) 최대 동시접속자 수 PU (Paying User) 결제자. 보통 일단위 혹은 월단위로 끊어서 보는 경우가 많음. 본격 데이터분석에 들어가기에 앞서… 기초 용어정리 - User
8. 8. - 보통의 게임 앱들은 DAU/MAU가 10~30% 수준에 분포. - Facebook과 같은 SNS의 경우 50% 이상의 높은 Engagement. - 데이팅 서비스의 DAU/MAU는 일반적으로 10% 이하, 매우 낮은 편. Engagement = DAU/MAU [Source: gamesbrief]
9. 9. Revenue 판매액. 매출액 ARPU (Average Revenue Per User) 사용자당 평균 매출. (혹은 가입자당 평균 매출). 세 글자로 줄이면 '객단가' 해당 기간의 매출 총합을 사용자수로 나누면 된다. ARPPU (Average Revenue Per Paying User) 결제자당 평균 매출. 일명 '결제자 객단가'. 마찬가지로 월 단위로 주로 계산하게 되며, 해당 기간의 매출 총합을 결제자수로 나누면 된다. 주의할 점은, 소수의 고액결제자들로 인해 크게 영향을 받을 수 있는 지표라는 점. 실제 데이터를 구할 때 아웃라이어에 대한 체크가 필요하다. 본격 데이터분석에 들어가기에 앞서… 기초 용어정리 - Revenue
10. 10. ASP (Average Selling Price) 결제 건당 매출. 매출을 판매개수로 나누면 된다. 개별아이템의 단가가 얼마나 높은지 파악할 수 있는 지표. CAC (Customer Acquisition Cost) 유저 모객단가. (=한 사람의 신규 고객을 데려오는 데 드는 비용) 광고 등 마케팅비용을 신규유저수로 나누면 된다. LTV (Lifetime Value) 고객 생애가치, CLV라고도 한다 (Customer Lifetime Value) 한 명의 고객이 서비스에 진입해서 이탈하기까지의 전체 기간동안 창출하는 가치 (주의!) Lifetime Value와 Lifetime Revenue 본격 데이터분석에 들어가기에 앞서… 기초 용어정리 – Cost/Value
11. 11. Retention Rate 회원 잔존율. D-day에 들어온 유저가 D+x일에 얼마나 남아있는지를 보여주는 비율. 보통 D+7 잔존율, D+30 잔존율, D+60 잔존율 등을 살펴본다. Download Install Ranking History Session Duration Screen View … 본격 데이터분석에 들어가기에 앞서… 기초 용어정리 – etc.
12. 12. 서비스 운영 Framework 셋업하기 Log를 Metric으로 만들기 OMTM 설정하기 데이터 들여다보기 다시, ‘스타트업’ 데이터분석
13. 13. 서비스 운영 회원상태 요청처리 (가입/탈퇴) 사용자 문의 신고사항 처리 이벤트 생성 진행 결과공지 서비스 및 지표 모니터링 생성되는 데이터 정리 Task 기반 Operation 버그 리포팅 1. 운영 프레임워크 한계! - 전체 프로세스에서 누락된 Task 존재가능성 - 수동적인 ‘사후대응’ 위주의 업무처리
14. 14. Framework 기반 Operation Framework? 1. 운영 프레임워크
15. 15. Dave McClure의 AARRR Pirate Metric http://www.youtube.com/watch?v=irjgfW0BIrw 1. 운영 프레임워크
16. 16. Dave McClure의 AARRR Pirate Metric 1. 운영 프레임워크
17. 17. Eric Ries의 Engine of Growth 사용자들이 서비스에 머무르고, 재방문 할 수 있도록 하는 엔진 사용자들이 친구들에게 자발적으로 추천/홍보를 하도록 하는 엔진 사용자들이 서비스 내에서 그들의 지갑을 열도록 하는 엔진 1. 운영 프레임워크
18. 18. Get Users 사용자를 데려오기 Drive Usage 데려온 사용자들을 서비스 내에 안착시키고 서비스 핵심 기능을 계속 사용하도록 하기 Make Money 그 과정에 적절한 BM을 붙여서 매출을 일으키기 - 유저가 들어오는 순간부터, 나가는 순간까지를 모두 포괄 - 각 단계가 일종의 funnel 형태로 서로 유기적으로 엮여있음 좋은 Framework 1. 운영 프레임워크
19. 19. 앱 다운로드 가입 프로필작성 심사요청 심사통과회원 홀딩 탈퇴 활동회원 결제회원 ▷ ‘화살표’의 Conversion ▷ ‘네모’의 Value ▷ ‘화살표/네모’에 영향을 주는 Variable Status 1 Status 2 Status 3 Status 4 Status 5 Status 8 Status 9 Status 6 Status 7 소셜데이팅 <이음>은 이렇게 합니다!
20. 20. 1. 운영 프레임워크: 짚고 넘어가자 “어제는 100명 가입 심사처리했는데 오늘 200명 가입 심사처리 완료했어요!” 오늘 100명 가입했는데 승인 통과한 회원은 50%인 50명입니다. 중요하게 생각하는 부분이 완전 다름 VS
21. 21. METRICLOG 분석가능한 형태로 변환 visualization 2. LOG를 METRIC으로
22. 22. 서비스 내 데이터(Metric)를 들여다보는 방법은? 1. 자체 Tool을 이용한다 2. 상용 데이터분석 서비스를 이용, SDK 연동한다. 2. LOG를 METRIC으로
23. 23. - “분석은 저희가 할테니, 개발/마케팅에만 집중하세요” (X) - 분석을 위한 프레임웍을 셋업하는데 도움을 받을 수 있음 (∆) - 시스템 구축/유지보수와 관련된 비용과 리소스를 줄일 수 있음 (O) - 리포팅에 드는 비용(?)과 리소스를 줄일 수 있음 (O) Pros. - 서비스 핵심 데이터가 전혀 걸러지지 않고 외부에 오픈 - 대부분의 툴이 모바일게임에 최적화, 개별 서비스에 맞춰서 커스텀 한계 - Metric과 함께, Log 단위로도 데이터를 받아서 볼 수 있는가 하는 자유도의 문제 Cons. - 비용? 2. LOG를 METRIC으로
24. 24. 소셜데이팅 <이음>은 이렇게 합니다! Google Analytics User/접속/화면 단위의 General한 지표 자체시스템 – “통계왕” 매칭/아이템 등 Service-Oriented 지표
25. 25. 1. Stock과 Flow를 혼동하지 않아야 함. - Stock은 시간 개념이 들어가지 않은 ‘저량’ ex) 누적가입자수 - Flow는 시간 개념이 포함된 ‘유량’ ex) 1월1일 가입자 2. Metric보다는 Log에 대한 정리가 우선. - Log->Metric은 가능하나, 반대는 어려움. - 분석의 자유도 3. 통계가 먼저인가, 서비스가 먼저인가? - 완벽한 통계시스템 셋업에 집착하지 말 것. - 중요한 건 대응프로세스 Inflow (liter/분) Outflow (liter/분) Stock (liter) 생각해 볼 만한 point 2. LOG를 METRIC으로
26. 26. - 얼마나 빠르게 death valley를 통과해서, growth 단계에 접어드는가? (물론 death valley를 통과할 수는 있는가? 라는 질문도...) - 서비스 성숙기(maturity)에 들어서, 찍을 수 있는 정점이 얼마나 높은가? - 정점을 찍은 이후, 떨어지는(decline) 기울기가 얼마나 완만한가? 서비스 성장곡선 관련, 몇 가지 중요한 질문 Death valley 3. One Metric That Matters
27. 27. - 매출, 가입자수, 다운로드, 체류시간, 활동유저, 결제자수, ARPPU, 재방문율… - 이 모든 지표를 똑같은 비중으로 들여다보고 관리할 것인가? - 현실적으로 엄청난 리소스 낭비 - 보다 중요하게는, 지표간 우선순위가 명확하지 않으면 서비스 방향을 directing 할 수 없음 모든 지표가, 모든 시기에, 같은 중요도를 가지지 않는다. OMTM One Metric That Matters 특정 시점에, 운영과 데이터분석을 위해 꼭 집중해야 하는 지표 3. One Metric That Matters
28. 28. OMTM One Metric That Matters “Capture everything, but focus on what’s important” - 지금 가지고 있는 ‘가장 중요한 질문’에 대한 답을 해준다. - OMTM은 단기/중기/장기 목표와 밀접하게 연관되어 있다. OMTM을 모르는 상황에서는 ‘과연 지금 잘 하고 있는지’의 상황 판단이 어렵다. - 넓은 시야에서 서비스를 바라보고, 서비스 자체에 초점을 맞출 수 있게 한다. - 전사적으로 실험, 측정, 판단 의 문화를 가질 수 있게 한다. - Yoskovitz & Croll <Lean Analytics> 3. One Metric That Matters
29. 29. Drawing lines in the sand OMTM 이야기를 하면 자연스럽게 뒤따라 나오는 질문. - OMTM 좋다. 하나에 집중한다고 하고... 그러면 도대체 그 지표가 '어떻게' 되는 걸 목표로 잡아야 하는거지? - 지금 우리 서비스는 '일가입자'가 OMTM인데... 이거 목표를 위한 가이드라인을 얼마로 잡아야 하나? ▶ 우리 BM을 고려하면, 그 지표가 얼마가 되어야 하는가? (from the business model: what a metric has to be?) ▶ 예측할 수 있는 normal한 수치, 그리고 가장 이상적인 수치는 얼마인가? (to look at what normal or ideal) 3. One Metric That Matters
30. 30. 현명하게 ‘목표설정’ / ‘예측’하는 방법 1. 목표값에 영향을 미치는 변수들을 찾으세요. 2. 각 변수의 ‘현재’ 상태를 기준으로, 이를 설명할 수 있는 수식을 완성하세요. 3. 우리가 조절가능한 변수, 그리고 조절 불가능하지만 영향을 받는 변수를 찾으세요. 4. 조절가능한 변수를 기준으로, 민감도분석을 합니다. 5. 예측은 항상 범위와 확률을 바라봐야 합니다. 소셜데이팅 <이음>은 이렇게 합니다!
31. 31. Monitoring vs. Data Analysis - 모니터링의 경우, “왜”에 대한 내용이 없으므로 인과관계가 아니라 단순한 상관관계만 알 수 있음 - 변수들이 1차원적, 대부분 알고 있는 내용에 대한 확증적 결과. “OOO 게임은 오후 9시에 동접자 수가 가장 높다” 어떻게 하면 데이터로부터 가치 있는 insight를 뽑아낼 수 있을까? - 쪼개서 보거나, 조합해서 보거나 4. 데이터 분석
32. 32. Cohort Analysis - Cohort: 유사한 특성을 가진 집단으로 유저를 잘게 쪼개는 것 - 전체 데이터를 놓고 보면 쉽게 보이지 않는 특성들을, 개별 cohort별로 쪼개놓고 보면 유의미하게 확인할 수 있다. 4. 데이터 분석
33. 33. Cohort Analysis: Case 서비스 A 서비스 B 4. 데이터 분석
34. 34. 서비스 A 서비스 B 4. 데이터 분석 알고보니, A는 밑빠진 독에 물 붓기
35. 35. 여기서 잠깐. 그렇다면 어떻게 log를 쌓아야?
36. 36. 회원잔존율 Cohort Analysis 매출 Cohort Analysis 분석을 위한 로그 쌓기 - 기본
37. 37. Data Mashup - 다양한 소스에서 얻은 데이터들을 조합해서, 새로운 insight를 찾아내는 방법 - 해석에 보다 주의를 기울여야 함 - 공개 API를 이용해서, 매시업 서비스를 만드는 사례가 늘어나고 있음 http://oakland.crimespotting.org/ 4. 데이터 분석
38. 38. 아이템A 매출 아이템B 매출+ 스토어X 매출 스토어Y 매출+ 판매개수 ASPX 결제자 ARPPUX 아이템C 매출+ 스토어Z 매출+ 매출 소셜데이팅 <이음>은 이렇게 합니다!
39. 39. 결제자 ARPPUX 활동회원 결제비율 ARPPUXX 회원잔존율 결제비율 ARPPUXX가입자 X 이달 가입자 M-1 가입자 M-2 가입자 M-3 가입자 소셜데이팅 <이음>은 이렇게 합니다!
40. 40. 남은 이야기들…
41. 41. 개인이 할 수 있는 영역 조직의 역량이 필요한 영역 궁극적으로는 전사적인 ‘문화’가 필요 개인 . 조직 . 문화
42. 42. 운영. 상시업무의 중요성 운영과 데이터분석의 결합 (협업 수준으로 안됨) Raw 데이터를 들여다보기 손에 흙 묻히면서 일하기
43. 43. Open Book Test 외우고 있는 것 보다, 쉽게 찾아볼 수 있는 구조를 만드는 게 중요
44. 44. 상관관계와 인과관계 Question First! 집요하게 인과관계에 주목하자
45. 45. Data-informed, not Data-driven 분석 자체를 맹신하지 말 것 직관과 데이터의 보완이 잘 이루어지는 게 최선
46. 46. 합리적인 의심 찾은 것도 모름 < 내가 엄청난 걸 찾았어! < 검증
47. 47. 전략적 통찰이 없는 분석의 함정 차별화 불가 아무 짝에도 쓸모없는 BM을 뒷받침
48. 48. Silver Bullet? 서비스의 성공은 기대고 있는 사업 영역 & 서비스가 가진 BM에서부터 출발
49. 49. Google Play Top Grossing Chart 100위 내 비게임 앱은 단 3개 얘는 모바일 대표플랫폼 린, 스타트업을 이끄는 지표 2/15 디캠프 / 레진코믹스 권정혁CTO 실전 스타트업 데이터분석 3/20 디캠프 / 이음 양승화 본부장 구글Play 매출 상위랭킹 앱의 공통점? 우연일까요? 
50. 50. leoyang@i-um.net 감사합니다 잠깐광고! 이음소시어스에서 서비스기획자/PM 안드로이드개발자 채용중입니다 ^^ apply@i-um.net