목차
1. 개요
2. 프로젝트 목적 & 핵심 지표 정의
3. 분석 전에 하는 EDA
4. 분석 전에 하는 EDA 진행과정 & 인사이트
5. 마무리
1. 개요
데이터 분석가로 일을 시작한지 10개월 정도된 시점에서 배달 앱로그 데이터를 활용한 사이드 프로젝트를 시작했다. 이 프로젝트를 시작한 계기는 다음과 같다.
1) 인하우스 분석가 경험
인하우스 분석가에 대한 경험을 해보고 싶었다. 외부 트래킹 솔루션에 의지해 적재되는 데이터를 확인하는게 아니라 내부 DB에 데이터가 쌓인다면 어떤 구조로 쌓이는지, 이를 위해서는 어떻게 로그를 설계 해야할지 등등. 프로덕트 데이터 분석에 대한 경험이 부족해 관련된 데이터를 활용한 분석 프로젝트를 진행하고 싶었다.
2) 데이터 분석가와의 협업
같은 포지션에 계신 분과 협업하면서 일하면 어떻게 일할지에 대해 경험해보고 싶었다. 같은 주제에 대해 고민하고 그 결과물에 대해 논의해볼 수 있는 시간을 가지면서 결과물을 디벨롭하는 시간을 갖고 싶었다.
이런 니즈를 충족하기 위해 내가 배달 앱로그 데이터 분석가라는 가정을하고 프로젝트를 진행해보기로 했다. 우연한 기회로 만나게 되어 같이 사이드 프로젝트를 진행하기로 한 수연님과 내가 모두 공통적으로 수강했거나 수강 중인 성윤님의 인프런 강의에서 제공 중인 데이터를 활용하기로 했다. 빅쿼리 활용편에서 제공되는 데이터를 활용해, PM을 위한 리터러시 강의 내용을 직접 데이터에 적용해보기로 결정! (약 반년가량,, 사이드 프로젝트를 진행해야겠다고 마음만 먹고 있다가 목표하는 점과 취미 등 공통점이 많고 생각이 깊은 수연님과 함께 진행하게되어 감사하다🙇🏻♀️)
이 프로젝트가 끝난 시점에서는 아래와 같은 결과물을 기대한다.
- 5개 주제로 각각 글을 작성해서 프로젝트 완성하기
- 내가 생각하는 인하우스 데이터 분석가의 업무에 대해 간접적으로 경험하기
- 다음 커리어 방향에 대한 고민 정리
2. 프로젝트 목적 & 핵심 지표 정의
가장 먼저 시작한 건 EDA. 무작정 EDA를 시작했다.
(분석을 위한 분석은 절대 금물이라는 걸 다짐하면서도 늘 반복하지..🥲)
이 과정을 2주 정도 진행하니 방향성이 없이 코드만 주구장창 돌리고 있다고 생각했다. 그래서 다시 한번 PM을 위한 리터러시 강의 자료를 쭉 훑고 내가 회사에서는 어떻게 업무를 했는지 고민했다. '데이터를 탐색하다보면 방향성이 잡히겠지' 하고 생각했던게 가장 문제라고 판단했다. 프로젝트 진행 목적이 있어야 하나의 방향성을 갖고 프로젝트가 진행될 것이라고 생각해 앱 데이터 분석가라면 가장 하고 싶은 프로젝트가 무엇일지에 대해 고민했고, 그 후보군을 나열했다.
1. AARRR 퍼널개선
2. 리텐션 증대
3. 주문율 개선
4. MAU 증대
5. 로그인 사용자 증대
6. 주문 1회 당 매출 비용 증대
7. 방문율 개선
위와 같은 7개의 프로젝트 목적 주제를 리스트업했고 그 중에서 '3. 주문율개선'을 프로젝트 목적으로 선정했다. 위에 나열되어 있는 7개의 목표가 모두 주문율을 위한 하위 목적이지 않을까라는 생각도 들었다. 결국은 모든 제품의 궁극적인 목적은 매출이기에! 그래서 계속 제자리 걸음을 하다가 '주문율'이라는 지표에 대해 고민해봤다.
주문율을 높이기 위해서는 2가지 방법이 가능하다.
1) 방문 횟수를 낮추거나
2) 주문 수를 높이거나
하지만 결국 매출을 증대하는게 목적이라면 1번 방법은 고객 확보 측면에서 절대 회피해야한다고 생각해 2번 방향으로 결정했다. 그래서 궁극적으로 주문수를 증대하는게 목표이되, 이를 평가하는 지표를 '주문율'로 생각해야겠다고 판단했다. 주문수와 방문 횟수 역시 정의할 수 있는 방법이 다양하기에 이번 프로젝트에서 활용하기로한 최종 지표는 다음과 같다.
3. 분석 전에 하는 EDA 시 유의점
무작정 EDA를 진행하다가 발견한 EDA에 대한 글 일부. 이게 맞나라고 생각했던건 데이터 탐색을 위한 EDA 진행이었고, 데이터 특징을 파악하는 과정이었다. 내가 직접 수집하고 설계한 데이터가 아니기에 당연히 필요할 수 밖에 없는 과정!
1. 분석 전에 하는 EDA
분석을 수행하기 전에 데이터에 대해서 점검해 봐야 하는 부분을 확인하고 간단한 분석을 해보면서 데이터를 ‘탐색'해보는 과정. 본격적으로 분석하기 전에 데이터를 탐색해 보는 과정. 이 데이터는 몇 개의 테이블로 이루어져 있고 각 테이블에는 어떤 컬럼이 들어있고 각 컬럼에는 어떤 값들이 들어 있는지, 비어있는 값이나 뭔가 잘못된 값은 없는지, 얼마의 기간만큼 데이터가 있는지 등을 확인.
2. 분석 과정에서 하는 EDA
분석의 전 과정에 걸쳐 가설을 세우기 위해, 또 데이터로 가설을 검증하기 위해, 결론을 뒷받침하는 근거를 데이터에서 찾는 과정
👉출처 : 기억안남 이슈…
이 과정에서 데이터 EDA 진행 시 필수적으로 고려해야할 점에 대해 깨달은 몇가지 포인트들이 있다.
- 날짜 시간대의 시차 맞추기
- 서비스의 특징을 고려해 그 서비스가 활용되는 곳의 시간대로 변형해야함
- 집계 기준의 중요성
- 배달 앱이라는 특성 상 한명의 사용자가 여러 번 방문해 주문할 수 있으므로 데이터 확인 목적 맞춰 집계 기준을 user_id, user_pseudo_id, session_id 로 변경해야함
- 적재되는 이벤트에 따라 session_id가 매개변수로 있는 경우도 있고 없는 경우도 있다.
- 방문에 대한 기준
- 음식 배달 주문이라는 특성 상 로그인이 필수적으로 선행되어야 주문 가능. 또한 한번 로그인한 사용자는 재로그인 하지 않아도 됨
- 방문은 홈 화면에 접속한 경우(로그인이 완료되고 screen_view & fribase_screen & home 일 경우)로 정의
- 사용자를 분류할 수 있는 고유값 정의
- 로그인이 완료되어야 user_id가 할당
- 로그인을 하지 않으면 주문 자체가 불가능하고, 로그인하지 않은 사용자에 대한 앱 행동 분석은 null인 경우가 많아 user_pseudo_id는 고유값으로 적합하지 않다고 판단
- user_pseudo_id로 기준을 집계할 경우 로그인을 완료하지 않은 사용자도 집계되기에 3번 내용과 상충
- 따라서 사용자는 user_id로 정의(로그인이 완료되지 않아 user_id가 null인 경우는 제외)
- 이벤트 별 매개변수 정보 확인
- 가장 기본적으로 주문수를 시각화하다보니 특이점을 발견 -> 주문 횟수가 모두 4의 배수인 것
- 시간대, 요일 별 주문 수를 확인해도 모두 동일하게 4의 배수인걸 확인하고 무언가 잘못됨을 감지
- 확인해보니 주문 이벤트에는 ' firebase_screen, session_id, payment_type, use_recommend_food' 총 4개의 매개변수 정보가 함께 기록되고 있었음. 매개변수가 4개이다 보니 이벤트수 기준으로 집계했을 때 4의 배수로만 집계될 수 밖에 없었던 것
4. 분석 전에 하는 EDA 진행과정 & 인사이트
어떤 말?
- 대표값
- 분포 확인
- 주문 횟수에 따른 사용자 세그먼트 별 특징 확인
- 주문 횟수에 따라 각 세그먼트 별 사용자가 얼마나 분포되어있는지 확인하기 위함
세그먼트 이름 | 주문 수 | 기준 | 특징 |
일회성 사용자 | 0 | 앱을 방문했으나 실제 주문X |
- 첫 방문 후 재방문하지 않거나, 특정 이유로 한 번도 구매하지 않은 사용자 - 주로 앱에 대한 관심이 부족하거나, 첫 방문에서 경험이 부족한 경우가 많음 |
초기 사용자 | 1 | 첫 주문 후 더 이상 주문 X |
- 한 번 구매한 후 재구매로 이어지지 않은 사용자 - 사용자가 구매에 대해 확신을 갖지 못했거나, 경험이 부족한 경우 |
불규칙 사용자 | 2~3 | 2~3회 주문 | - 간헐적으로 주문하는 사용자들로, 일관성 있는 구매를 하지 않는 경향 - 주로 가격이나 프로모션 등 외부 요인에 영향을 받는 경향 |
충성도 높은 사용자 | 4 | 4회 주문 | - 반복 구매가 이루어지는 사용자로, 브랜드나 서비스에 대한 충성도가 높음 - 추천 시스템이나 로열티 프로그램을 통한 강화 필요 |
🚩분석 전에 하는 EDA를 통한 인사이트
- 주문율 개선을 위해서는 방문 횟수를 줄이거나 주문수를 늘리는 2가지 방법이 있는데, 앱의 고객 수 확보를 위해서는 당연히 후자를 택해야하므로 일회성 사용자의 주문을 유도해야함을 발견
5. 마무리
진행 상황 Summary
👉🏻프로젝트 목적 : 주문수 증대
📍평가 지표 : 주문율
📍평가 지표 : 주문율
EDA 과정에서 생각보다 많이 헤맸지만, 조금씩 정리&진행이 되는 느낌이다. 지금은 문제 정의와 가설 파트를 진행하고 있는데 아직까지 확신이 들지 않으면서도 데이터를 보고 그에 대한 스토리를 만들어가는 과정이 재밌다.(사실 이번 글에 분석 과정 중에 하는 EDA와 가설을 뒷받침하는 데이터 선정까지 기록하고 싶었지만 그러다간 글을 제출하지 못할 것 같다!!ㅠ) 중간 회고를 하며 잘한 점과 아쉬운 점을 곱씹어보면 아래와 같다.
👍🏻Good
- 지표에 대해 고민한 것
- raw 형태 데이터를 평면화하며 배열 데이터에 대한 지식 쌓기
- 이벤트 특징을 하나씩 정리해가며 데이터 특징을 파악한 것
- 데이터의 대표값과 분포를 확인한 것
👎🏻Bad
- 무작정 EDA를 시작한 것
- 프로젝트 목적을 생각하지 않고 처음부터 프로젝트를 진행한 것
- 내 생각이 정리되지 않은 상태로 프로젝트를 진행하다보니 같이 진행하는 수연님도 혼란스럽게해드린 점
직접 이벤트 로그를 설계한게 아니니 이벤트 별 특징과 시간대 등에 대한 파악을 정확하게 파악해야한다. 데이터 분포,이벤트가 기록되는 방식 등 집계된 데이터에 대한 정확한 이해도를 갖추어야만 명확하게 문제점을 정의하고 해결방안을 도출해낼 수 있다. 목적 없는 프로젝트 진행의 나비 효과를 절실하게 경험한 것 같다. 향후 단계에서는 방향성을 잃지 않고 진행할 수 있도록!!
👉참고링크
수강한 강의
- https://www.inflearn.com/course/bigquery-%ED%99%9C%EC%9A%A9%ED%8E%B8/dashboard