본문 바로가기

프로덕트 분석24

[지표 위계] Metric Hierarchy 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. Metric Hierarchy 왜 필요할까? 회사와 제품에 중요한 지표에 집중할 수 있음 우선순위를 선정할 때 도움이 됨 데이터 기반 문화의 기초! 회사 전체 단위로 작성할 수도 있고, 세부 Product 별로 설정할 수도 있음 Metric Hierarchy 장점 회사의 전체적인 Metric 구조를 파악할 수 있음 중립적인 관점에서 작성된 형태로 전사적으로 같은 관점을 바라볼 수 있음 L1, L2 Metric을 통제할 수 있는 지표로 잘 선정하면 어떤 Action을 해야 할지 판단하기 수월함 L1, L2 Metric 레벨로 가면 조직별, 개인별로 지표를 담당 L2 Metric의 개선이 Focus Met.. 2024. 4. 15.
데이터 로그 설계(4) - Amplitude 마켓컬리 이벤트 로그 설계 예시 🎯 아래와 같이 마켓컬리 웹사이트에 진입하여 특정 상품을 선택했을 때 이벤트로그를 예시로 살펴본다 👉 이커머스 웹사이트에 진입해서, 인기 상품을 탐색하고 카트에 담기까지 주요 여정에서 어떤 이벤트와 property가 수집되는지 확인하며 이벤트 로그 설계의 예를 확인할 수 있다 :) 👉 비로그인 상태에서 진행하여 User에 대한 정보는 담기지 않았음! 1. 홈화면 진입 → 뷰티 사이트 클릭 Event name : select_site Event Id 30 Time 4/14/24, 2:32:04 pm GMT+0900 Device Id 0g0OJFklnL2tMJFozZW-ET User Id null(비로그인 상태) Session Id 1713070446958 Platform Web 👇 Event Propert.. 2024. 4. 14.
프로젝트 회고(Retrospect) 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 회고의 효과 회고를 통해 과거의 경험보다 나은 경험을 할 수 있음 중간에 방향성을 확인할 수 있음 개인의 감정 상태를 확인해, 좋은 팀워크를 유지할 수 있음 그 다음 Action Item을 발굴할 수 있음 → 목적 지향적 사고! 회고 방법론 : KPT 🎯 K → P → T 순서로 공유하며, Action Item이 나오는 것이 핵심! K (Keep) : 계속 유지할 것 P (Problem) : 잘 되지 않거나, 문제가 있는 것 T (Try) : P를 해결하기 위해 시도할 것 회고 시 주의사항 회고에서 중요한 것은 방법론이 아니라 회고의 목적과 구성원들의 마음가짐! 회고 경험을 긍정적으로 만들어 감으로써,.. 2024. 4. 14.
데이터 로그 설계(3) - 데이터 QA 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 데이터 QA 👉 데이터의 품질을 향상하기 위한 활동으로, 데이터 QA를 진행하지 않고 배포하면 나중에 분석 시 데이터가 잘못 기록되는 상황을 인지할 가능성 존재! 데이터 QA로 확인하는 것 1. 데이터 로그가 기록되고 있는가 2. 지정한 이름과 지정된 값(Value)로 기록되고 있는가 3. 지정한 데이터 타입대로 기록되는가 4. 의도한 시점에 Trigger 되는가 5. Android, iOS가 동일하게 데이터가 저장되는가 데이터 QA 방법 1 (GA, Firebase 기반 예시) ▶︎ 하나씩 직접 실행하면서 확인 : 데이터 로그 설계한 Tracking Plan을 보면서 진행 ▶︎ 저장된 데이터를 쿼리해.. 2024. 4. 14.
실험하기 - A/B Test의 단계별 주의사항과 Action 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 실험을 시작하는 기준 충분한 사용자 수가 존재 평가 지표를 정의할 수 있는 경우 사용할 수 있는 리소스가 존재하는 경우(개발, 데이터) 실험군과 대조군이 서로 간섭하지 않는 경우 법적인 이슈가 없는 경우 실험을 통해 배울 마인드가 존재하는 경우 무엇을 실험해야 할까? 👉 어떤 실험이 비즈니스 임팩트가 큰지 확인하기 제품 관점에서 제일 중요한 퍼널을 개선하는 것을 먼저 진행(퍼널 역순) 데이터로 실험할 영역에 하루 몇 명이 접근하는지 확인한 후, 유저 몇 명 정도에게 영향을 미치는지 확인해야 함 → 실험 기간을 결정할 때도 영향을 미침 📑 주요 실험 소재 예시 제품 : 특정 화면에서 A라는 기능이 있는 .. 2024. 3. 30.
데이터 로그 설계(2) - Event & User Property 와 Event Taxonomy 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 제품 기획 후, 지표를 고민한 다음 해당 지표를 도출하기 위해 필요한 데이터 로그를 설계한다. 데이터 로그는 크게 두 가지(Event, User)로 나누어 설계한다. 이때도, 문제 정의와 지표 정의하기에 기반함을 잊지 말자! 결국 프로젝트의 목적에 부합하는 지표를 설정하는 것이 핵심이므로👆 데이터 로그 설계 시 2가지 관점 1. 지표에서 필요한 Event 정의 👉 Event Parameter 기능에서 발생할 수 있는 User Event & 이벤트에 저장할 추가 정보(parameter) 데이터 로그 설계 흐름(Event) 어떤 것을 기록하고 싶은지 생각한다 해당하는 event_name을 정의한다 어느 시.. 2024. 3. 23.
데이터 로그 설계(1) - 기초 개념 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 데이터 로깅 : 로그(Log)를 기록하는 행위 로깅을 왜 해야 할까? : (서비스의 특정 기능 개발/개선 배포 후) 지표를 기반으로 서비스의 성과를 측정하기 위해 Event taxonomy / Tracking Plan : 어느 시점에 어떤 데이터가 저장될 지 기록 1. 데이터의 종류 (1) 서비스 로그 (DB data) 서비스가 운영되기 위해 필요한 데이터 예) 구매 기록, 즐겨찾기 등 고객에게 노출되는 데이터 DBMS, DB, Table (2) 유저 행동 로그 (사용자 행동 데이터) 서비스에서 유저의 활동 더 좋은 제품을 위한 '분석'을 위해 필요한 데이터(고객에게 보여줄 필요는 없음) 추천 엔진 만.. 2024. 3. 23.
지표 구성 시 유의사항 & 서비스에 적용해보기(1) 📍본 포스팅은 [인프런] 카일스쿨의 PM을 위한 데이터 리터러시 강의를 기반으로 요약 / 실습했습니다. 지표 : 측정하고 싶은 것을 숫자로 표현한 것 해결하고자 하는 문제 → 문제 정의 과정에서 지표를 생각해야 함(무엇을 확인해야 할까?) 원하는 결과 해당 지표가 어떻게 변할지 🤔 Mental Simulation 하는 것이 중요함 → 불활실성 감소! 지표가 올라간다면 왜 그럴까? → 더 빠르게 올릴 수 있을까? 지표가 내려간다면 왜 그럴까? → 내려가지 않게 하려면 무엇을 해야할까? 좋은 지표의 조건 업무 목적과 관련이 있음 : Objective 측정이 가능함 : Measurable 지표를 토대로 '행동'할 수 있음 : Actionable 누구나 이해할 수 있음 : Understand 정의를 명확하게 함.. 2024. 3. 21.
[분석 사례] 딜라이트룸 : 신규 기능의 진입률과 전환율 높이기 📱 새 기능을 출시했을 때 확인할 것 (1)사용율을 살피고, 해당 기능 사용까지의 (2)퍼널별 전환율을 살핌 퍼널 최적화가 필요함 : 유저의 여정, 제품 내 퍼널의 어느 단계에서 유저 이탈이 심한 지 찾고 그 이유를 찾아 문제를 정의하고 개선해야 함 즉, 퍼널 최적화는 '유저의 제품 내 특정 전환율 증진'을 위한 하나의 방법임 ✔️ 퍼널 최적화를 위한 접근 2가지 1. 진입률 높이기 : 해당 기능 화면까지의 진입률(퍼널 유입량)을 높이는 방법 2. 진입 이후 전환율 높이기 : 해당 기능 내에서의 전환율(퍼널 내 전환율, 완수율)을 높이는 방법 🚨 해석 시 유의할 점은, 대부분의 기능이 출시 직후 '진입률'이 낮을 것이라는 점이다. 따라서 진입 대비 전환율은 새로운 기능에 관심이 많은 소수 유저들이 만든 .. 2024. 3. 11.
728x90