[데이터 로그 설계] 3. 데이터 로그 설계
[데이터 로그 설계]
1. 로그에 대해 알아보자 https://songsedit.tistory.com/16
2. 데이터 로그 설계 기본 상식 https://songsedit.tistory.com/17
1. 이벤트 파라미터, 유저 프로퍼티
이벤트
회원가입 버튼(Component)을 클릭한 경우
- 이벤트 : Click
- 이벤트의 파라미터로 "어떤 버튼"을 클릭했는지 기록한다
ex) component_name : sign_up - 이벤트의 구체적인 상태, 세부 정보를 파라미터(프로퍼티)에 저장한다
- Firebase에선 이벤트의 파라미터를 Key라고 부르고, 파라미터에 저장된 데이터를 Value라고 부른다.
유저
- 유저가 특정 이벤트를 할 당시의 정보를 유저 프로퍼티로 저장한다
ex) event - 이커머스 앱 접속
해당 유저의 구매 횟수, 총 누적 금액 등이 유저 프로퍼티로 저장되어 있으면 구매 금액별 분석이 가능함 - DB에서도 유저 데이터 확인이 가능하지만, 데이터 로그 목표에 필요한 데이터는 유저 프로퍼티로 관리하면 좋다
- 특히 AB테스트에서 실험군과 대조군이 유저별로 고정되어야 하기 때문에 유저 프로퍼티로 관리하면 좋다
2. 데이터가 저장되는 형태
DB (Database)
: RDB(관계형 데이터베이스)와 NoSQL 등이 있다. 회원 정보, 주문 정보 등의 데이터는 로그 형태보단 DB에 저장한다
텍스트 파일
: 하나의 파일에 데이터를 저장한다. 이 경우 데이터 분석을 위해 데이터 웨어하우스로 옮기는 파이프라인이 필요할 수 있다
보통 유저에게 빠르게 보여줘야할 경우 DB에 저장, 유저와 상관없이 분석용이라면 텍스트 파일로 저장
3. 이벤트 로그 설계하는 방법
이벤트 로그에는 총 3가지의 Element가 존재한다
- (Event) 어떤 이벤트가 발생했는가?
- Click, View, Swipe 등
- (Trigger) 어느 시점에 실행됐는가?
- 특정 Component를 클릭하는 시점
- 특정 화면이 보이는 경우
- 스와이프로 다음 화면에 넘어간 경우
- 서버의 Request하는 시점
- 서버의 Request 후 Response가 되는 시점
- 실행된 시간
- (State) 어떤 상태를 가지는가?
- 어떤 유저인지, 어떤 화면인지, 어떤 버튼을 클릭한 상태인가
- 이벤트 상태와 관련된 정보를 제공함
- 이벤트 파라미터를 기록함
해당 이벤트들이 발생되는 위치에 따라 설계가 달라진다
- 웹 클라이언트
- GA, GTM를 사용해 데이터 수집
- page_view : 특정 페이지에 접근할 경우
- scroll : 스크롤을 얼마나 내렸는지
- click : 클릭을 한 경우
- view_search_results : 검색을 한 경우
- video_start, video_progress, video_complete
- file_download : 파일 다운로드하는 경우 - Admin ⇒ Data Streams ⇒ Enhanced measurement에 해당 이벤트가 설정되어 있는 것을 확인할 수 있음
- GA, GTM를 사용해 데이터 수집
- 앱(iOS/Android)
- Firebase로 개발할 경우 자동으로 저장되는 이벤트들이 있고, 커스텀 이벤트도 정의 가능함
screen_view(웹에서 page_view와 유사한 개념), session_start, user_engagement 등 기본적인 이벤트가 존재함 - 앱의 라이프사이클에 대한 이해가 중요함
ex) 백그라운드로 이동한 후, 다시 앱으로 진입하면 screen_view 이벤트가 또 찍힘
- Firebase로 개발할 경우 자동으로 저장되는 이벤트들이 있고, 커스텀 이벤트도 정의 가능함
- 서버
- API의 Request, Response를 서버 자체적으로 AWS S3 등의 저장소에 저장
→ 해당 데이터를 데이터 웨어하우스로 옮기는 데이터 파이프라인이 있어야 QA, 데이터 분석 때 용이함
- API의 Request, Response를 서버 자체적으로 AWS S3 등의 저장소에 저장
참고 https://www.slideshare.net/slideshow/ndc18-95524337/95524337
4. 데이터 로깅 프로세스
0. 현 회사에 데이터 로깅 관련 문서, 아키텍처가 있는지 확인
1. 해당 프로젝트에서 메인으로 가져갈 지표 생각해보기 (Goal 설정)
2. 어떤 식으로 저장하면 좋을지 작성해보기
3. 개발자 또는 데이터 분석가와 커뮤니케이션
4. 확정된 로깅 가이드 문서 개발자에게 전달
5. 로깅 개발 완료 후, 실제 데이터가 잘 들어갔는지 테스트
로깅 가이드 문서는 스프레드시트 등으로 관리하면 좋다
- 이벤트 이름
- 어느 상황에 로깅되는지
- 언제부터 적용되는지 (배보 버전 등)
- 이벤트의 세부 파라미터 이름은 무엇이고 어떤 것들이 있는지 (Firebase에선 Key라고 표현함)
데이터 로깅 프로세스는 데이터 로깅 설계와 데이터 로깅 작업, 데이터 QA 로 나눌 수 있다
데이터 로깅 설계
어떤 시점에서, 어떤 데이터를, 어떤 파라미터와 기록할 것인지, 유저의 프로퍼티를 저장할 것인지를 담은 데이터 로깅 추적 계획을 세우는 과정이다.
데이터 로깅 설계 전에 어떤 지표를 메인으로 볼 것인지 구체화하는 과정이 반드시 필요하다.
중요한 지표가 웹/앱이 아니라 DB로도 볼 수 있다면 굳이 로깅할 필요는 없다.
개발 중 기획이 충분히 바뀔 수 있기 때문에 개발이 어느정도 끝난 후, 로직이 확정된 데이터 로깅 작업을 하는 게 좋다.
데이터 QA
데이터 로깅 작업에서 로깅한 데이터가 맞는지 확인하는 과정이다.
5. 이벤트 로그 설계 템플릿 (Tracking Plan)
이벤트 로그 설계 시 문서화하는 게 제일 중요하다.
로그 설계가 잘 관리되어야 → 추후 데이터 분석 시 어떤 이벤트를 봐야할지 알 수 있음
로그 설계가 잘 관리되어야 → 추후 데이터 누락이나 이상한 상황을 확인할 수 있음
!! 조직 사황에 맞춰 스프레드시트, 노션 등 저장하기
Tracking Plan 작성 시점
- 새로운 기능이 출시된 경우
- 새로운 이벤트, 파라미터를 수집해야 하는 경우
- 데이터 타입을 수정하는 경우
- 데이터 수집을 중지하는 경우
Tracking Plan의 장점
- 이벤트, 파라미터 등이 어떤 방식으로 기록되었는지 한번에 볼 수 있음
- 데이터를 여러 번 수집하지 않아 중복을 피할 수 있음
- 일관된 방식으로 데이터를 로깅해서 부정확성을 피할 수 있음
- 모든 사람들이 동일한 규칙으로 로깅함
- 처음 개발하는 사람들도 다른 사람이 이미 만든 이벤트 로그 설계를 참고할 수 있음
Tracking Plan에 포함되는 정보
- 이벤트 이름
- 이벤트 설명
- 이벤트 카테고리
- 이벤트 실행 시점
- 파라미터(프로퍼티) : 파라미터의 타입, 설명, 필수 여부
- 어느 플랫폼에 남기는지
- 언제부터 남기기 시작했는지
- 언제 수집을 중지했는지
- 설계 완료 유무, 개발 완료 유무, QA 개발 유무, 배포 유무 등
Tracking Plan
- Avo : 특정 KPI, Metric에서 사용할 수 있는 이벤트 모아둔 형태
https://docs.google.com/spreadsheets/d/1oEbMAWQt7lFXVJtM8sMdTaqjoeVQvZok24o_lOtxCyI/edit?gid=0#gid=0
- Amplitude
* Amplitude는 event taxonomy라는 단어를 사용함
* E Commerce용 Event Taxonomy, Game용 Event Taxonomy, Music App Event Taxonomy 등 다양한 Use case에 대한 템플릿 제공
* 해당 템플릿은 회사에서 가질 수 있는 질문에 대한 답변을 하면서 이벤트를 정의함
- Practico : Event Lifecycles을 구분하고 Priority를 작성한 부분이 특이함. 이 중요성을 관리할 주체가 필요함
- Mixpanel :
Retail & eCommerce용 Tracing Plan, Saas용 Tracking Plan, Media & Entertainment용 Tracking Plan
- Data-led : Activation, Adoption, Revenue, Page view 관점으로 데이터 로그 설계
위 템플릿을 보고 팀에 맞는 플랜을 조합해보기.
6. 이벤트 로깅 팁
로그는 최대한 자세할수록 좋지만, 우선 순위를 정할 필요는 없다
- 자주 봐야할 지표라면 꼭 심는게 좋다
- 모든 걸 로깅하면 좋지만, 로깅을 위한 추가 개발이 필요하거나 저장하는데 부하나 비용이 될 수가 있기 때문에 우선순위를 정하면 좋다
- 필요한 데이터를 적재적소에 기록하는게 중요하다. 정한 목표에 부합하는 데이터를 우선적으로 설계한다
클라이언트 VS 서버
- 보통 서버 로그로 모두 해결할 수 있지만, 앱 사용 관점이 궁금한 경우 클라이언트 로그를 심는게 좋을 수 있다
- 클라이언트와 서버 로그는 보완재
- 서버 로그의 경우 어떤 페이지에서 입력했는지를 알 수 있어야 한다
- 보통 로그 파일로 저장하면 AWS S3에 저장하는데, 이 파일을 지우지 않고 보관하는게 좋고 비용상의 이슈가 있다면 AWS의 콜드라인으로 저장해 비용을 절감할 수 있음
이벤트 이름을 파라미터까지 포함하는 경우 VS 이벤트만 추상화하는 경우
- 파라미터까지 포함하는 경우 : event_name: click_signup
- 이벤트만 추상화하는 경우 : event_name: click, component_name: signup
- Firebase, GA라면 이벤트 이름 갯수 제한이 500개로 있어서 이벤트 이름을 추상화하고 파라미터로 관리하는 게 좋음
- 파라미터까지 포함하는 경우는 파라미터를 포함하지 않아 쿼리 비용이 감소함(파라미터까지 쿼리할 경우 빅쿼리에서 비용이 증가함)
- 장기적으로 관리하기 위해선 이벤트 속성을 추상화하는 게 좋음
7. 데이터 QA
데이터가 제대로 들어가는지 확인하는 과정이 필요하다
- 오타 확인
- string, integer 확인
- iOS, Android 확인
- 특정 버전부터 값이 남지 않는 경우는 없는지 확인
데이터 QA를 위한 자동화 시스템을 만드는 것도 좋다.
Firebase, GA의 경우 DebugView를 사용하고, 서버 로그의 경우 자체적으로 구축한 시스템을 사용한다
- 데이터 QA 자동화 요소
- 해당 이벤트에 값이 잘 들어갔는가?
- 파라미터가 잘 설정되어 있고, 값이 저장되는가?
- 값이 여러가지인가?
- 기존에 정의된 타입과 동일하게 데이터가 저장되는가?
- 갑자기 N일 동안 데이터가 들어오지 않았는가?
앱/웹 개발 법전에선 토스트 팝업으로 저장되고 있는 로깅을 보여주면 DebugView를 보지 않아도 되어서 편함
출처
데이터 로그 설계 https://zzsza.github.io/data/2021/06/13/data-event-log-definition/
프로덕트 데이터 분석 https://mixpanel.mfitlab.com/blog/2023-05-31-productdataanalysis-beginner-trackingplan