https://www.youtube.com/watch?v=cE38iV4KczQ
1. 로깅설계 진행시 해봐야할 질문
1) 왜 이 지표를 봐야하는가?
2) 이번 Feature에서 볼 지표들은 무엇인가?
3) 지표 중 메인 지표, 보조 지표, 운영 지표, 가드레일 지표는 어떻게 되는가/
4) 지표를 분자와 분모로 작성하면 어떻게 되는가?
2. 변성윤님이 볼 때 지표를 어떻게 바라보는가
1) 메인 지표 : 해당 기능의 성장성을 확인할 수 있는, 기능의 성공을 판단할 지표
2) 보조 지표 : 해당 기능으로 궁극적으로 변하면 좋겠다고 생각하는 지표, 그 기능 관련해서 필요한 지표
3) 운영 지표 : 운영하면서 계속 체크해야 하는 지표
4) 가드레일 지표 : 이 지표는 떨어지면 안된다 하는 지표
5) 메인 지표 - 보조 지표 - 운영 지표 순으로 데이터 로그 설계 (모두 기록하면 좋지만 우선순위가 필요한 경우!)
3. 프로젝트 Flow
1) 성과지표 설정
- 해당 프로젝트의 목적은?
-> 목적에 부합하는 지표를 설정해야 함
1) 기획 확인하기 - 문제 정의 및 목표 확인
2) 성과를 측정할 수 있는가?
a. 모든 프로젝트가 100% 성과 측정이 되는 것은 아님
b. 단, 보조 지표를 모니터링해서 볼 수는 있음
3) 성과 지표 고민
a. 상황에 따라 모두 다름
- 프로젝트가 시작된 이유를 떠올려주세요
- 과거에도 있었던 기능이 개선된 것인지
- 새로운 기능이 추가되었는지
- UX 등의 큰 변화가 있었는지
b. 어떻게 데이터를 비교해볼지
- AB Test : 새로운 기능
- 전후 비교 : 과거에 있던 기능이 있는 경우
c. 너무 고민이 많아질 경우엔 생각을 심플하게 바꿔보기
d. 메인으로 볼 지표 1개를 선정하고, 나머지는 보조 지표로 선택
- 직관적으로 잘 이해되는 지표 고르기
2) 대표적인 지표
a. 데이터 지표는 매번 다르게 설계하는 것이 당연하고, 기능을 기획하시는 분이 고민하시는 것이 제일 의도대로 가능
b. 대표적인 지표
- 클릭률 (페이지 전환율) : 노출 대비 클릭
- 리텐션 : 단, 빠르게 보기 어려울 수 있음(Daily가 아닌 Weekly의 경우)
- 해당 기능을 통해 얻은 수익 (예약건수, 매출, 손익 등)
- 기능의 배포 성공 여부
- 퍼널별 전환율 등
c. 회사에서 자주 사용하는 지표를 모아두면 패턴화할 수 있음
3) 데이터 로그 설계
a. 데이터가 어디에서 발생하는지 확인해야 함
- 서비스 / 앱 / 웹
- 서버 : 특정 API의 Request / Response 정보를 기록함. 앱이나 웹에서 API 호출할 경우 저장
- 앱 : 화면에서 유저가 어떤 화면에 진입했는지, 어떤 버튼을 클릭했는지 등을 기록함
- 웹 프론트엔드 : 웹 브라우저의 기록. 어떤 웹페이지에 진입했고 어떤 버튼을 클릭했는지 등을 기록
- 참고) API Request 할 경우에 로그를 남길 수도 있고, Request 후 Response 받은 후 로그를 남길 수도 있음
b. 클라이언트 로그와 서버 로그
- 두 로그는 상호 보완적
- 클라이언트에서만 기록할 수 있는 로그, 서버에서만 기록할 수 있는 로그, 둘 다 기록할 수 있는 로그 등 다양
- 둘 다 기록할 수 있는 경우 => 보통 서버에서 기록하도록 권장
- 언제 클라이언트가 기록할 수 있고, 언제 서버가 기록할 수 있는지 감을 얻는게 중요
- 하나의 API를 여러 화면에서 호출할 경우, API Request에 화면 정보가 없다면 앱/웹 로그로 남기거나, API Request의 파라미터로 추가해야 함
c. 꼭 기억해야 할 것
- 서버로그 : API
- 앱 로그 : 유저의 화면, 버튼 클릭
- 웹 로그 : 웹 기록
3가지를 남긴다
4) 데이터 로그 설계 - Event와 User
a. 많은 솔루션에서 보통 Event만 정의
b. GA4, Firebase는 Event와 User 두 갈래로 정의할 수 있음
c. Event Parameter : 이벤트의 정보
d. User Property : 유저의 특정 이벤트하는 시점의 정보
5) 데이터 로그 설계 - Event
a. "누가, 무엇을, 언제, 왜"
b. Event : 발생한 행위가 무엇인지(Event)
- Click, View, Swipe, Custom Event
c. Trigger : 어느 시점에 저장되는가
- 유저가 특정 Component를 클릭하는 시점
- 특정 화면이 보이는 경우(로딩이 시작된 경우, 로딩이 완료된 경우)
- 클라이언트가 서버에 Request하는 시점
- 서버가 Request를 처리하고 Response가 보이는 시점
d. State : 어떤 상태를 가지는지
- 어떤 User인지, 어떤 화면인지, 어떤 버튼을 클릭했는지?
- 그 당시에 노출된 답변 id, 답변 수 등
- 이벤트의 파라미터를 기록
6) 데이터 로그 설계 - User Property
a. "누가"에 대한 정보를 기록
- 특정 Event를 실행하는 시점의 유저 정보 (ex - 콴다 앱 가입일)
b. BigQuery에 저장된 데이터
Event Property 기준 BigQuery
User Property 기준 BigQuery
7) 매스프레소 사례 : 콴다 프리미엄의 PO였다면?
a. 지표를 다음과 같이 설정
b. 제품 개선 1순위 : 동영상 풀이 노출 CVR
- 신규 구독자를 늘릴 수 있는 Input Metric들 중, 개선하기 위한 액션이 가장 명확한 것 선택
- 동영상 풀이 존재율과 노출율을 각각 트래킹
- 존재율 : 검색 결과 내 동영상 풀이가 존재하는 비율
- 노출률 : 존재하는 동영상 풀이가 유저에게 노출된 비율
- Action 1 : 존재율 늘리기
- 더 많이 노출될만한 문제를 선정해서 동영상 풀이를 제작
- Action 2 : 노출률 늘리기
- ex - 풀이 검색 결과에서 동영상 풀이 존재하는 검색 결과를 더 앞에 보여주도록 검색 엔진을 tuning
c. 메인 지표와 보조 지표
- 메인 지표 : 위 지표
- 보조 지표 ( 또는 운영 지표) : 앱을 어떻게 사용하는지?
- 콴다풀이에서 다른 답변을 얼마나 클릭하는지?
- 콴다풀이에서 얼마나 공유하는지?
- 이미지 풀이 노출 CVR
- 무료 질문하기 클릭
- 이 풀이가 도움이 되었나요?
- 콴다 문제집 - 비슷한 문제 풀어보기
- 문제를 못 풀겠다면 개념 강의 클릭 / 스와이프
- 함께 보면 좋을 개념서 클릭 / 스와이프
- 동영상 풀이 노출 전환 이후 프리미엄 구독 전환수
8) 매스프레소 사례 ) 메인 지표를 위한 로그 설계
a. 메인 지표 : 검색 결과 / 동영상 풀이 노출 CVR(전환율) = 검색 결과
b. 가장 간단하게 전환율을 확인하려면
- 검색 결과 Page View
- 동영상 풀이 Player View
c. 연습 문제 : 어떤 이벤트로 어떤 파라미터를 남겨야 할까?
d. 모범 답안
- Event : View
- Parameter
- image_id : 검색 이미지 id
- page_name : "검색 결과"
- Event : Click
- Parameter
- component_name : Click한 Component
- component_id : Click한 Component Id
- page_name : "검색한 결과"
- image_id : 검색 이미지 id
- page_name : "검색 결과"
검색 이미지 id별 전환율을 구하고 싶다면 Click에 파라미터 추가
e. 예시 쿼리 (로깅 설계시 쿼리를 친다고 생각해보면 더 효과적)
SELECT
image_id
, COUNTIF(event_name="View") AS view_count
, COUNTIF(event_name="Click" AND component_name="quandar_answer_play_button") AS click_count
FROM
WHERE
page_name = "콴다풀이"
GROUP BY image_idf. 검색엔진이라 검색 결과가 하나도 나오지 않는 경우
- 존재율 : 검색 결과 내 동영상 풀이가 존재하는 비율
- (앱 로그) : View 이벤트의 파라미터로 콴다풀이 결과 수를 추가할 수 있음
- (서버 로그) : 이미지 검색 요청(Request)과 Response를 비교할 수 있음
- 선택의 문제 : 앱에 로깅할 것인가 vs 서버에 로깅할 것인가 vs 둘 다 할 것인가
- 목적을 나눔
- 앱 로그 : UX의 전환율을 측정하기 위함
- 서버 로그 : 콴다풀이 엔진 성능 평가를 위함
- 만약 데이터가 이상하면 두 데이터를 보완할 수 있음
9) 매스프레소 사례 - 보조지표를 보기 전에
a. 보조 지표(또는 운영 지표) : 앱을 어떻게 사용하는지?
- 콴다풀이에서 다른 답변을 얼마나 클릭하는지?
- 콴다풀이에서 얼마나 공유하는지?
- 이미지 풀이 노출 CVR
- 무료 질문하기 클릭
- 이 풀이가 도움이 되었나요?
- 콴다 문제집 : 비슷한 문제 풀어보기
- 문제를 못 풀겠다면 개념 강의 클릭 / 스와이프
- 함께 보면 좋을 개념서 클릭 / 스와이프
- 동영상 풀이 노출 전환 이후 프리미엄 구독 전환수
b. 현실
- 이정도 지표를 로깅하려면 최소 2~4배의 이벤트를 로깅해야 함
- 일정 조율이 필요하거나, 보조 지표 중 꼭 볼 것을 먼저 정하면 좋음
- 혹은 스와이프를 보지 않고, 클릭을 본다 등
- 지표가 많다 = 데이터 로깅해야 하는 것이 많다 = SQL 쿼리 작성할 것이 많다 = 이 모든 지표를 토대로 의사결정할 것은 아닌데(보조지표이므로) 이 정도 리소스를 투입할 것인가? 결정을 잘 해야 함
=> 보통 큰 기능을 최초 배포시엔 보조 지표나 로깅할 부분이 많긴 함
- 같이 협업하는 동료가 이런 느낌을 받지 않도록
- 너무 많은 요청 사항보단 단계적으로 가는 편 (협상이나 화법 공부하시는 것도 추천)
- 대표님이 이번 달 안에 제품 5개 런칭해야 합니다 라고 말을 듣는 경우와 비슷한 느낌 아닐까요?
- 항상 감사함을 표현합니다(개발자님 최고... 만세 감사합니다)
10) 매스프레소 사례 - 보조 지표를 위한 로그 설계
a. 보조지표 1 : 콴다 풀이 결과를 얼마나 클릭하는가?
- Event : Click
- Parameter
- component_name : qanda_answer
- component_id : answer_id
- component_order : answer의 순서
- image_id : 검색 image id
- page_name : "콴다풀이"
b. 보조지표 2 : 콴다 풀이 결과를 얼마나 공유하는가?
- Event : Click
- Parameter
- component_name : qanda_answer_share_button
- image_id : 검색 image id
- page_name : "콴다풀이"
c. 보조지표 3 : 무료 질문하기를 얼마나 클릭하는가
- Event : Click
- Parameter
- component_name : free_question_button
- image_id : 검색 image id
- page_name : "콴다풀이"
d. 보조지표 4 : 이 풀이가 도움이 되었나요 클릭 수
- 이 데이터는 DB에 저장될 데이터
- 문제 풀이에 대한 정보 => 보통 DB에 저장
- DB에 저장된 데이터로 알 수 있으므로 앱 로그로 저장하지 않음
e. 보조지표 5 : 비슷한 문제 풀어보기 클릭 수
- Event : Click
- Parameter
- component_name : try_similar_problem_button
- image_id : 검색 image id
- page_name : "콴다풀이"
11) 매스프레소 사례 - 유저 프로퍼티
a. 앞선 Event를 실행할 때 유저의 정보를 같이 추가할 수 있음
b. User Property
- 가입일
- 과거 프리미엄 가입 유무
- 현재 프리미엄 가입 유무
- 콴다에서 문제 검색한 수 (총 누적)
12) 데이터 로그 설계 정리
a. 보려고 했던 지표 확인
b. 그 지표에서 필요한 분자와 분모 확인
c. 어느 시점에 데이터를 기록해야 하는지 확인
d. Event 관점 외에 User Property도 고민하기
13) 데이터 로그 설계 : Event 이름을 어떻게 사용할 것인가?
| event_name | Event와 Component를 같이 쓰는 경우 | Event만 포함하는 경우 |
| 예시 | click_login_button | click |
| 장점 | 분석 도구에서 Event Count를 쉽게 가능 event_name만으로 의미 파악 가능 |
이벤트 갯수를 관리할 수 있음 (Click, View 등 추상화된 이벤트) 파라미터에 기반해 데이터를 판단 |
| 고려할 점 | - 이벤트 갯수가 많아질 수 있음(메인 화면에 5개의 버튼이 있으면 = 5개의 이벤트가 생성) - GA, Firebase는 하나의 앱에 500개 이벤트만 기록할 수 있음 |
- 파라미터 기반의 데이터 분석이 익숙하지 않을 경우 초반 온보딩 필요 - GA/Firebase는 배열로 저장되어서 사용하기 어려울 수 있음 |
14) 데이터 로그 설계하며 고민할 포인트
a. 데이터 로그 설계한 사람 = 데이터 보려는 사람인 경우
- 어딘가 기록을 남기거나, 기억에 기반하여 파악할 수 있음
b. 데이터 로그 설계한 사람 != 데이터 보려는 사람인 경우
- 조직이 커지면 데이터 로그 설계한 사람과 데이터를 보려는 사람이 달라짐
c. 슬랙에서 누군가 외침 : "이 데이터 보려면 어떻게 해야해요?" "이 컬럼의 의미는 뭐에요?"
d. 데이터 로깅 설계에 대한 WIKI가 필요
15) Tracking Plan
a. Tracking Plan을 잘 사용하는 일
- 데이터 로그 설계하는 사람이 매번 잘 기록해야 함
- 만약 기능 배포로 변경 사항이 있다면 잘 기록해야 함
- 일하는 방식, 문화와 관련된 부분
- 다양한 조직이 데이터를 잘 볼 수 있도록, 표준 규격이 필요 (조직마다 다르면... 조직을 통틀어서 분석할 경우 어려움)
b. 매번 기능배포할 때마다 Tracking Plan 수정하다보면 Human Error가 발생
16) Meta Platform의 시대
a. 그냥 어딘가 컬럼 정보만 저장하면! 그 정보 검색도 가능하고, 시각화도 가능하게 만들자!
b. 많은 회사에서 개발
c. 단, DB데이터만 잘 지원하고 GA/Firebase는 아직
'Growth' 카테고리의 다른 글
| 긴장된다 - 고객을 끌어오는 구글 애널리틱스4 (0) | 2022.03.27 |
|---|---|
| 빅데이터를 활용한 예측마케팅 전략 (0) | 2022.03.24 |
| 마케팅이 데이터 사이언스를 만나면 생기는 일 (1/2) - Gain & Lift Chart (0) | 2022.02.26 |
| 그로스해킹 회사 설득 포기하세요 (0) | 2022.01.24 |
| 그로스해킹 - 양승화 (0) | 2021.11.29 |
댓글