데이터 로그 설계
데이터 로그 설계 Process
로깅 솔루션
- 무료
- (웹) Google Analytics 4
- (앱) Firebase
- 유료 - 대부분 Product Analytics 도구
- 그 외에도 마케팅 툴들도 로깅을 해야할 경우가 존재함
- "도구 이름 API Document"를 확인하면 자세한 문서가 존재함
클라이언트 로그와 서버 로그
- 두 로그는 상호 보완적인 관계
- 클라이언트 로그
- 서버 로그
- 틀리면 안되는 데이터, 돈과 관련된 데이터는 서버 로그로 저장하며 클라이언트 로그는(Firebase) 유실될 수도 있음
Event와 User Property
- Event Parameter : 이벤트의 정보
- “누가, 무엇을, 언제”
- Event : 발생한 행위가 무엇인지
- Click, View, Swipe, Custom Event
- Trigger : 어느 시점에 발생하는가?
- 유저가 특정 행동하는 경우 : Component를 클릭하는 시점
- 특정 화면이 보이는 경우(로딩이 시작된 경우, 로딩이 완료된 경우)
- 클라이언트가 서버에 Request하는 시점(API Request)
- State : 어떤 상태를 가지는지
- 어떤 화면인지, 어떤 버튼을 클릭했는지?
- 그 당시에 클릭한 제품 id, 제품 카테고리 등
- 이벤트의 파라미터에 기록
- User Property : 유저가 특정 이벤트를 하는 시점의 유저 정보
- 특정 Event를 실행하는 시점의 유저 정보
- 예 : 우리 서비스의 가입일, 인구 통계 정보, 접속한 위치, 멤버십 레벨 등
- DB에도 있지만, Product Data 분석 도구에서 편의를 위해 기록
Tracking Plan, Event Taxonomy
- 데이터 로그 설계에 대한 내용을 공통적으로 저장하는 문서가 필요
- 공통화된 패턴을 잘 기록하고, 새로운 사람이 와도 확인할 수 있도록 온보딩 문서 작성
- Event 이름을 어떻게 사용할 것인가?
- Event와 Component를 같이 쓰는 경우 : click_login_button
- 분석 도구에서 Event Count를 쉽게 가능
- Event Name으로 의미 파악 가능
- 이벤트 갯수 제한이 존재할 수 있음
- 이벤트가 너무 많아져서 관리가 어려울 수 있음
- Event만 포함하는 경우 : click
- 이벤트 갯수를 관리할 수 있음
- 파라미터를 기반해 데이터를 판단할 수 있음
- 파라미터 기반의 분석이 처음엔 어려울 수 있음
- Event 이름을 snake_case와 camelCase 어떤 것을 사용할 것인가?
- 프로그래밍 언어마다 권장이 다름
- 표시가 다르면 데이터를 볼 때 혼란스러움
- 하나로 통일하고 가는 것이 좋음
- SQL, 파이썬에선 snake_case를 권장
- 최초에 시작할 수 있는 포인트
