** 수정중 **
데이터 기반 의사결정
의사결정
= 갈림길에서 왼쪽으로 갈지, 오른쪽으로 갈지 정하는 것
데이터 기반 의사결정의 유형
유형 1. Data Driven Decision
: 데이터가 하라는 대로 결정한다. 이미 있는
유형 2. Data Informed Decision
: 데이터로 기록이 없는 새로운 일을 시작할 때, 비슷한 과거의 데이터를 찾아서 참고하는 방식에 가까움
결론) 모든 결정을 데이터로 할 수는 없다. 데이터는 과거의 기록일 뿐 현재, 지금 이 순간의 상태를 설명할 수 있을지 없을지 아무도 모름! 그런 점에서 Data Driven Decision 보다 Data Informed Decision이 더 바람직할 수 있다.
미팅을 할 때마다 next mattew's fealous..?
데이터 기반 의사결정 방법
1. 데이터를 기반으로 정의하고 중요 지표를 대시보드로 만들어서 시각화하는 방법
2. 데이터를 보고 서비스/제품의 개선이 필요한 부분을 발견한 다음, 가설을 바탕으로 A/B 테스트를 수행하여 검증하는 방법
- 중요한 지표를 대시보드로 시각화하기
- 고객의 이탈/잔존 확률 분석하기 -> '코호트'를 기준으로 분석
** 코호트 : 동일한 특성을 갖는 고객 그룹
사람들이 처음으로 우리 서비스의 회원이 된 달을 기준으로 코호트를 설정한다. 이 후, 다음 달에는 우리 서비스를 계속 사용하는지/이탈했는지에 대한 분석을 진행한다. 회원의 가입년월을 본다.
- 마케팅 기여도 분석 -> 마케팅 예산을 어떤 채널에 어떤 캠페인으로 돌렷을때 가장 많이 우리 서비스를 방문하고 이들 중 얼만큼이 실제로 우리 서비스를 이용하는지 분석할 수 있음!
ex. facebook 광고를 통해서 서비스를 발견한 사람들, 블로그를 통해 서비스를 발견한 사람들 => 비디오, 카드뉴스, 등등의 마케팅 방법을 활용한다.
** 이탈률 churm rate
ex. skip 이라는 샌프란시스코 기반 전동 스쿠터 회사
샌프란시스코는 언덕이 많아서 직접 운전을 하기 매우 나쁘 환경이다. 그 점에서 전동 스쿠터가 도움이 많이 되었는데, 계속 사용할 거 돈을 주고 조금씩 빌리기 보다는 아예 개인 스쿠터를 사는게 더 나을 것이다 -> 관광지에서 재미삼아 잠깐씩 타는게 훨씬 도움이 많이 될 것이다. + 날씨가 좋을 때 사람들이 많이 탄다
결론) 돈을 지불하는 고객들이 게속해서 서비스를 사용할지 말지 여부는 서비스 운영에 있어서 가장 중요한 요소이다.
<데이터 분석가 역할>
- 비즈니스 인텔리전스를 책임짐
= 중요한 지표를 정의하고 이를 대쉬보드 형태로 시각화
(사용되는 툴 : Tableau, Looker, Superset 등등..)
= 그 회사가 속한 비즈니스 도메인에 대한 다양하고 깊은 지식이 필요함
- 다른 부서들로부터 데이터 관련된 질문을 많이 받게됨
= 계획을 기반으로 일을 하는 것 보다, 외부 요청의 interupt를 받으면서 질문들에 대한 답을 빠르게 해야 하는 스트레스가 존재할 수 있음
= 좋은 데이터 분석의 마인드셋 : 반복적인 질문들을 어떤식으로 셀프서비스 형태의 대쉬보드로 만들어서, 이 문제에 대해 궁금한 사람들이(관련된 타 부서들, 회사의 의사결정권자들) 내가 답을 따로 하지 않아도 시각화된 자료와 지표만으로 원하는 답을 얻게 만들 수 있는가!
= 의사결정권자들이 데이터 기반 결정을 내릴 수 있도록 교육
조직 구조의 중요성과 트렌드
<데이터 팀 조직 구조>
1. 중앙 집중 구조
: 모든 팀원들이 하나의 데이터 팀에 속해서 일하는 구조. 다수의 현업 부서를 서포트하는 구조
데이터 팀 내에서 커리어 패스가 생기기 때문에 데이터 팀의 만족도가 올라간다. But, 현업 부서의 만족도는 떨어짐(이유 : 모든 일들을 데이터 팀을 중심으로 돌아가서. 응답속도가 빠르지 않음)
2. 분산 구조
: 같이 일을 하는 현업 조직이 있고, 그 현업 조직별로 데이터 팀이 밑에 소속되어 일하는 구조
보통 인프라를 담당하는 데이터 엔지니어들은 중앙 조직에 속해있는 것이 일반적이다.
- 현업 부서의 만족도는 올라간다. But, 데이터 팀의 관점에서는 데이터 팀이 모여서 지식과 경험을 공유하고 팀을 이루어 커리어의 방향성이 보이는 환경에서 근무해야 만족도가 올라가는데, 특정 부서의 분석만 해주는 사람으로 박탈감을 느낄 수 있음
3. 하이브리드 구조
: 중앙 집중 구조와 분산 구조의 결합된 형태
모든 중앙 조직들과 데이터 팀이 한 팀에 소속되지만, 일을 할 때는 약간의 파견, 임베드 형태로 현업 부서와 밀접하게 같이 일을 하는 형태의 구조
- 데이터 팀의 관점에서는 중앙에 소속되어 있기 때문에 함께 모여서 일할 수 있고 커리어 패스가 보임. 주변 인프라는 현업부서에 담당되는데, 계속 바뀌기 때문에 유연하고 집중적으로 일할 수 있다.
- 현업 부서와 데이터 팀 두 개의 만족도를 높일 수 있는 가장 이상적인 형태
** 데이터 메쉬 Data Mesh(2019)
: 분산데이터 아키텍처
: 큰 조직일수록 데이터를 한 곳에 모아두고 관리/사용하는 것은 쉽지 않음. 각 팀이 알아서 데이터를 관리할 수 있는 형태로 가되, 발생할 수 있는 문제를 최소화하기 위해 중앙에서 관리할 수 있도록 '표준'을 만든 것.
- 조직별로 데이터 시스템을 별도로 구성해서 속도를 높이고 효율을 늘리되, 각 조직이 갖고있는 데이터가 무엇이 있는지 카탈로그를 만들어 공유와 탐색을 용이하게 하는 방식
- 요즘 뜨고 있는 방식
예) Azure : Microsoft의 클라우드
-> 현업부서가 데이터를 탐색하는데 드는 시간과 비용을 줄임
-> 현업부서로부터의 반복되는 질문들을 데이터화한 후 챗봇으로 만들어 활용
** 마이크로 서비스 Micro Service
: 하나의 큰 코드 베이스 안에 특정 서비스에 해당되는 모든 코드가 들어가는 방식
- 속도가 안난다.
- 굉장히 많은 서비스와 API가 만들어진다.
=> Service Registry : 어떤 마이크로 서비스들이 있는지 기록하는 저장소의 개념
Service Registry를 통해 어떤 서비스를 사용하면 될지 이해하고, 개발시간을 단축할 수 있음
<데이터 팀의 업무 루틴>
워터폴 방법론 -> 애자일 방법론
** 짧은 싸이클 = 스프린트(Sprint)
- 매 스프린트마다 작은 기능들을 구현해서 바로 사용할 수 있도록 만듦
- 매 스프린트마다 3가지 단계를 반복한다.
1) 플래닝 미팅
2) (매일) 스탠드업 미팅
3) 데모/회고 미팅
1. 월요일
- 지난번 스프린트 리뷰 및 회고 미팅
- 새로운 스프린트 계획 (스프린트 동안 사용할 수 있는 인력 측정이 핵심) => 새로운 기능 개발 + 과거에 만들었던 기능 개선 및 재작성(유지/보수)+ETL의 경우 데이터 엔지니어에게 권한이 있기 때문에 ETL 온콜을 담당할 인력 정함+데이터 관련 질문을 담당할 인력 정함
** 애자일/스크럼 보드 (ex. JIRA, Swit, Click UP)
어떤 일들의 진행중/진행완료 등에 대한 기록
2. 화요일
- 스탠드업 미팅(첫날은 안하고 두번째 날부터 매일 진행)
- 내/외부(sync-up) 다양한 미팅 진행
3. 수요일&목요일
- 스탠드업 미팅
- (데이터 분석가의 경우) 주요 지표 리뷰 미팅, A/B 테스트 결과 관련 미팅
- (데이터 과학자의 경우) 머신러닝 모델 개발 리뷰 미팅, A/B 테스트에 머신러닝 모델이 있다면 관련 미팅 진행
4. 금요일
- 스탠드업 미팅
- 데이터 팀의 주간 스태프 미팅(지난 한주 결과 리뷰)
- 개발상황, A/B테스트 상황 요약해서 전체 공지
- 채용 관련 미팅
- 주간 사고 리뷰
** post mortem(사후 점검 미팅) : 문제가 생기는 것은 막을 수 없지만, 동일한 문제가 재발하는 것을 막을 수 있도록 하는 것을 목표로 하는 미팅
- 메인 프로젝트 리뷰(내외부 프로젝트 관련)
- 팀별/개인별 업데이트 진행
좋은 지표(KPI)란?
<KPI(Key Performance Indicator)>
지표의 일종.
모든 지표가 중요한 것은 아니므로 수많은 지표들 중 중요하다고 판단되는 지표를 말함
- 다시말하면, "조직내 달성하고자 하는 중요한 목표"를 말함
- KPI는 명확한 정의가 중요하므로, '사전 형태'로 어딘가에 저장하고 확인하는 방식이 사용됨
- 개수가 적을수록 좋다. 집중해서 나아갈 방향성이 정해지기 때문이다!
- 성과 측정은 어떤 시점의 숫자만 보는 것이 아니라, 시간을 두고 어떤 트렌드를 보는 것이 일반적이다. 그래서 대쉬보드에 시각화를 하는것이 중요하다.
KPI vs Metrics(지표)
- 지표가 더 큰 개념. KPI는 지표의 일정
- 따라서 지표라는 것은 중요도에 따라 KPI일수도 있고 일반 지표일 수도 있다.
- 꼭 회사 전체에 중요한 KPI가 아니더라도 개인이 판단했을 때 중요한 목표가 있다면 그에 해당하는 성공/실패 여부, 진행 상황을 알려주는 지표를 만드는 것이 중요하다 -> 데이터 문해력의 시작점
KPI의 기준
1) 어떤 가치를 나타내는 것이어야 한다.
ex. 등록회원수는 아무 가치가 없음 -> 허영지표(Vanity Metrics)
ex. 전체 매출 (현재 가치를 나타내주는 중요한 지표) = Total revenue
2) 좋은 지표는 현재 가치만 이야기 하는 것이 아니라, 계속해서 재발생하는 가치를 야기할 수 있는 지표여야 한다.
ex. 신규 상품/서비스가 첫 방문/구매만 가능한 것이 아니라, 이후 기간에도 고객들이 지속적으로 재방문/재구매를 하고 있는지 판단 가능한가
ex. 반복 구매를 통해서 나오는 매출을 나타내는 지표 = MRR(Monthly Recurring Revenue)
3) KPI는 후행 지표이다.
: 회사의 상황이 어떻게 바뀔건지 예측하는 지표가 아니라, 모든 일들이 벌어지고 나서 최종 결과를 보여주는 지(=후행지표)표이다.
** vs 선행지표
: B2B 형태의 기업은 매출액이 후행지표이다. 영업 파이프라인에 이야기하고 있는 고객의 수가 선행지표이다.
4) 지금 우리 서비스를 사용하고 있는 고객의 인원수가 WAU(Weekly Active User), MAU, DAU의 트렌드를 보면서 우리 상황이 좋아지고 있는지, 이슈가 발생할 경향이 보이는지 확인한다.
** Next Dashboard Fallacy 의사결정장애
: 지금 내린 결정을 확정하는 것이 아니라, 확신이 없어서 더 완벽한 결정을 내리기 위해 시간을 낭비하며 대시보드를 계속해서 생성하는 현상
-> 지표의 수, 대쉬보드의 수는 적을수록 좋다!
-> 수가 많을수록 Dashboard Discovery Issue만 발생할 뿐, 시간과 비용 모두 줄이지 못하는 악영향을 미친다.
** Next Feature Fallacy
: 만들고 있는 프로덕트 방향이나 미션, 비전을 생각하는것이 아니라 '해당 기능만 구현하면 게임 끝이다!' 라는 잘못된 생각을 갖는 현상
선행지표 & 후행지표
추천 책 : Working Backwards(아마존이 일하는 방식을 설명한 도서)
< Input metrics = 선행지표>
- 우리가 통제 가능하다
<Output metrics = 후행지표>
- 최종적으로 케어하는 것
- 직접 통제는 불가능하다.
- MAU, DAU, WAU, 매출 등이 후행지표에 해당된다
- 기업의 financial performance를 나타내는 지표들
=> 여기에 영향을 주는 선행 지표를 파악하고 관리해야 최종 KPI의 역할을 하는 후행지표가 제대로 나온다.
=> 선행지표가 개선되야 결론적으로 후행지표에도 좋은 방향으로 영향을 줄 수 있다.
<KPI의 예시 - 두 가지 중요한 KPI>
1. 매출액
** 매출액 = 가격 * 판매량
=> 이 때 [가격]은 변화시키기 쉽지 않아서 거의 고정되었다고 생각하지만, [판매량]의 경우, 조절할 수 있다.
때문에 판매량에 해당하는 '선행지표'를 파악하는 것이 핵심이다. (ex. 영업건수)
- 기존 고객에게 팔았을때의 매출인지/ 새로 유입된 고객에 의한 매출인지 구분하는 것이 중요함
2. 서비스 사용 고객수(Active Users)
** 여기서 Active의 의미는?
: 어떤 행동을 했을 때 이 사용자가 '활성화된 사용자'라고 정의할 수 있을까
- 무료 고객/유료 구매 고객 구분 중요하다
- market place의 경우, 콘텐츠의 공급자와 소비자의 구분도 중요하다.
시각화 툴
<시각화 툴>
: KPI, 지표 등 데이터의 중요한 포인트를 데이터를 기반으로 분석, 표시, 식별할 수 있게 하는 도구
- 대시보드 혹은 BI(Business Intelligence) 툴 이라고 부른다.
- time-series 형태로 보여주는 것이 일반적이다.
- 기업의 의사결정권자들이 데이터를 기반으로 의사결정할 수 있게 한다.
- 가장 많이 사용되는 툴 : 엑셀, 구글 스프레드시트
- 그 다음 많이 사용하는 것들 : Taleau, Power BI, Looker, Apache Superset(오픈소스) 등
- 조직이나 개인에 맞게 Looker 혹은 Tableau를 사용하는 추세이다. 두개 모두 처음에는 'Learning Curve(배우는데 필요한 시간)'가 필요하다.
결론) 시각화 툴이 셀프서비스가 가능한 형태가 되어야 한다. -> 뼈대를 잘 만들어야 함!
어떤 형태로 대시보드를 만들건, 대시보드를 사용하는 사람이 대시보드 제작자(보통 데이터 분석가)에게 많은 요구를 하지 않고도 본인이 필요한대로 다양하게 분석하거나, 부족한 기능을 추가하는 것이 가능해져야 한다.
-> 데이터 민주화와 데이터 탈중앙화의 파운데이션
꼭 하나의 데이터 팀을 통해서 데이터 활용을 하지 않으려면, 대시보드를 쉽게 만들고 활용할 수 잇는 인프라가 구축되어야 하며, 이것의 핵심은 어떤 대쉬보드 툴을 사용하는지가 관건이 될 것이다.
너무 심하게 각자 대시보드를 만들 경우 잘못된 형태의 대시보드를 만들 수도 있고, 대시보드가 너무 많이 생겨서 어떤 것을 사용해야 할지 헤매는 'Dashboard Discovery' 이슈가 발생할 수 있다. 정말 중요한 지표는 몇개의 공식 대시보드를 만들고 그것들만 보고 결정해야 한다. 즉 '데이터 거버넌스'가 필요하다!
[실습] Tableau public
<Tableau 제품 유형>
1) Tableau Desktop
: 대시보드를 만들 수 있는 저작환경 (Mac OS, Windows 사용 가능)
2) Tableau Server
: Tableau Desktop으로 만든 대시보드를 호스팅 해주는 환경. 이를 통해 다양한 대시보드를 공유할 수 있고, 접근권한을 설정할 수 있다.
내가 직접 설치하고 운영해야 한다.
3) Tableau Online
: 직접 설치하고 운영하는 것이 힘들다면 사용자의 수에 맞게 라이센스 비용을 지불하고 사용하는 클라우드 방식이 있다.
4) Tableau Prep
: 대시보드를 사용하기 전에 data transformation 혹은 EDA 등을 해줄 수 있게 해주는 코딩이 필요없는 데이터 전처리 툴
보통은 Tableau Desktop과 연동해서 사용함
5) Tableau Public <- 실습에서 사용할 것
: 기능에는 약간의 제약이 있으나 무료이기 때문에 학습용으로는 많이 사용한다. (Mac OS, Windows 사용 가능)
- 보통 Tableau는 Data Warehouse와 같은 관계형 DB를 백엔드로 해서 거기에 연결하여 데이터를 테이블 형태로 다운받아 시각화하는데, Tableau public은 무조건 파일 형태(CSV파일)로 '정적인 데이터'를 기반으로 대시보드를 만든다.
- 읽어올 수 있는 최대 레코드 수가 1500만개로 제약되어있지만 기능상 제약은 없다.
- 만든 대시보드는 다른 사람들에게 공유하기 어렵다.
- But, 개인 포트폴리오로 만들어서 이력서에 사용하는 것은 무관하다.
6) Tableau Mobile
: tableau로 만든 대시보드를 모바일 환경에서 쉽게 볼 수 있게 해주는 애플리케이션
<실습>
- Colums(열) : Dimension = 우리가 갖고있는 데이터(수치)를 어떤 관점으로 바라볼 것인지. Timestamp(X축)에 따른 형태로 보는 것이 일반적이다.
- Rows(행) : Measure = 실제로 알고 싶은 지표, 트래킹하고 싶은 수치
* 중요한 것은 사용자가 기간 내에 여러번 방문해도 1번 방문한 것으로 카운트 해야 한다 => Count Distinct 해야 함
- 오른쪽 상단에 범주들은 Filter이라 한다. 해당 예제에서는 각각에 속한 범주들을 Channel이라 한다.
-> 그래프를 한번에 그리는 것이 아니라 사용자가 유입된 Channel에 따라서 그래프를 그려야 한다. Multi line Graph
-> Filter를 선택해서 원하는 그래프만 살펴볼 수 있다.
- 차트를 MAU라는 이름으로 저장하고, 대시보드를 따로 만들어서 MAU라는 하나의 차트로만 구성되게 최종적으로 만든다.
- 이후 Tableau Public Server에 저장한다.
* Tableau에서 대시보드는 하나 혹은 여러개의 차트(혹은 시트)의 집합이다.
<Tableau 분석>
요약 테이블
1) Type 유형 : 해당 컬럼의 데이터 유형을 보여준다. (숫자/ 문자/ 문자/ 시간/ 날짜 등)
2) Field Name 필드명 : 해당 필드의 이름을 보여준다.
3) Physical Table 물리적 테이블 : 해당 필드가 어떤 테이블로부터 왔는지 실제 파일명을 보여준다.
4) Remote 원격 필드명 :
더보기(필드명 옆 삼각형) 클릭 > Measure > Count(Distinct): 해당 월에서 사용자들의 unique한 수를 카운트할 수 있다.
Channel 드래그> Marks밑에 드랍 : 채널에 따른 count의 트렌드를 볼수 있음
저장해보자!
파일>Save to Tableau Public> Tableau Public 웹사이트 로그인 : 나의 Tableau Public account 밑에 해당 대시보드를 publish 할 수 있다. 이렇게 만들어진 대시보드는 Tableau Public을 사용하는 사용자라면 누구나 열람할 수 있기 때문에, 이를 잘 만들어서 포트폴리오롤 활용하는 경우가 많다.
