https://zzsza.github.io/data/2021/06/13/data-event-log-definition/
데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것
이벤트 데이터 로그 설계, 데이터 로그 설계, 데이터 로깅, 데이터 QA에 대해 작성한 글입니다 키워드: 데이터 로깅, 데이터 로깅이란, 데이터 로깅 시스템, Firebase event logging, 이벤트 로그 설계,
zzsza.github.io
위 포스팅을 참고하여 공부한 내용을 정리했습니다.
1. 데이터 로깅?
앱을 사용하면 우리가 어떤 행동을 하는지 데이터가 남음
ex. 쿠팡 접속 → '사과' 검색 → 장바구니 → 결제
이런 데이터를 사용자 로그 데이터, 이벤트 로그 데이터 등으로 부름
로그
접속 기록, 특정 행동 관련 기록
로그 데이터 종류
- 서비스 로그 (데이터베이스 데이터)
- 서비스가 운영되기 위해 필요한 데이터
- ex. 고객 가입 일자, 구매 물품
- 데이터베이스에 저장되는 데이터를 서비스 로그라고 부르는 경우도 존재
- 유저 행동 로그 (유저 로그, 사용자 행동 데이터)
- 서비스에 반드시 필요하진 않지만 더 좋은 제품을 만들기 위해 필요한 데이터 (이 데이터를 분석하여 서비스를 개선하는데 사용할 수 있음)
- 앱이나 웹에서 유저가 어떤 행도을 하는지 나타내는 데이터
- UX와 관련해서, 인터랙션이 이루어지는 관점에서 발생하는 데이터
- ex. Click, View, Swipe
유저 로그 데이터의 예시
- user_id가 1234인 user가
- 특정 웹사이트에 로그인
- 제품 구매 페이지 (URL)에 접근
- 제품 구매 페이지에서 특정 버튼 (Component) 클릭
- 제품 구매 요청 (Request)
- 특정 웹사이트에서 로그아웃
요약
데이터 로깅 (이벤트 로그 설계) 란
특정 상황을 이벤트로 정의하고, 이벤트의 파라미터가 어떤 것으로 저장해야 하는지 등의 내용을 정의하는 행동
2. 데이터 로깅을 해야 하는 이유
- 데이터를 정확히 보기 위해서는 데이터를 올바르게 기록해야 함
- 데이터를 잘 심지 않으면 이상한 데이터를 볼 수 있음
- 데이터 로깅을 하지 않으면 데이터를 볼 수 없음
ex. 데이터 로깅을 신경쓰지 않고 특정 기능을 배포한 경우
성과 확인을 위해 데이터를 보고자 함 → 데이터 누락 or 잘못된 로깅 → 다시 로깅 후 배포 → 과거 성과는 알 수 없음
⇒ 이런 경우를 방지하기 위해 데이터 로깅을 항상 신경쓰고 데이터 QA도 진행해야 함
- 기획자, PM : 특정 기능에 대해 어떤 데이터를 보고싶은지 잘 알고있음
- 데이터 분석가 : 데이터가 어느 형태로 저장되어야 데이터 분석시 활용하기 용이한지 잘 알고있음
3. 데이터 로그 설계를 위한 기본 상식
1. Source
데이터가 발생하는 곳
Source에는 대표적으로 서버, 앱, 웹이 있음
- 서버
- 특정 API의 Request 정보 기록
- 클라이언트나 웹에서 API 호출할 경우 저장
- 앱
- (IOS, And)앱의 기록
- 유저가 어떤 화면에 진입했는지, 어떤 버튼을 클릭했는지 등을 기록
- 웹
- 웹 브라우저의 기록
- 유저가 어떤 웹페이지에 진입했는지, 어떤 버튼을 클릭했는지 등을 기록
- 유저가 앱/웹을 어떻게 사용하는지 궁금한 경우 → 앱/웹에 로그를 남기는 것이 좋음
- 서버 → API의 요청을 남김
- 두가지는 상호보완적이고, 특정 상황은 한쪽에서 쌓기로 합의하는 것도 좋음
- 데이터를 원하는 경우, 앱/웹쪽에 로깅할지 OR 서버에 남길지를 알고 있으면 좋음
2. 웹뷰 (Web View)
Web View : 앱에서 웹 페이지를 띄우는 것
ex. 앱에서 네이버의 웹페이지를 보여주는 것
- 웹뷰는 웹이므로 GA로 데이터 수집 가능
- 앱 → 웹 이동시 사용
3. 딥링크 (Deep Link)
특정 페이지에 접근할 수 있는 링크
- Moblie Deep Link : 모바일 앱의 특정 페이지에 접근할 수 있는 링크
- 딥링크를 사용하면
- 앱이 설치된 경우 → 앱 실행 가능
- 앱이 설치되지 않은 경우 → 앱스토어 OR 앱 특정 화면으로 이동 가능
4. 구글 애널리틱스 (Google Analytics, GA)
글에서 제공하는 웹 분석 서비스
- 웹사이트의 데이터를 수집, 분석 → 온라인 비즈니스 성과 측정, 개선에 사용할 수 있는 도구
- GA에 쌓인 데이터를 구글 클라우드의 빅쿼리로 추출 가능
5. 구글 파이어베이스 (Google Firebase)
구글에서 만든 앱, 웹 어플리케이션 개발 플랫폼
- 파이어베이스를 사용해 앱을 만드는 경우, 빠른 시간 내에 비즈니스 로직을 구현해 앱을 만들 수 있음
6. 구글 태그 매니저 (GTM)
다양한 태그를 관리할 수 있는 이벤트 트래킹 도구
- page_view나 click은 쉽게 수집 가능
- 별도로 원하는 데이터가 있는 경우 개발자에게 코드를 심어달라고 요청해야 함
- 태그 매니저가 연결되어있는 경우, 개발자가 직접 정의하지 않아도 기획자, 마케터가 직접 정의해서 데이터를 획득할 수 있음
4. 이벤트 파라미터와 유저 프로퍼티
이벤트 파라미터
- 이벤트의 구체적인 상태, 세부 정보를 파라미터(=프로퍼티)에 저장
- 이벤트 : Click
- 파라미터 : 어떤 버튼을 클릭했는지 기록 (component_name : sign_up)
- ex. 회원 가입 버튼 (Component) 클릭한 경우
** Firebase에서는 이벤트 파라미터 = Key, 파라미터에 저장된 데이터 = Value
유저 프로퍼티
- 유저가 특정 이벤트를 할 당시의 정보를 유저 프로퍼티로 저장유저가 여태까지 제품을 구매한 횟수, 총 누적 구매 금액이 유저 프로퍼티로 저장
- → 유저가 이벤트 페이지에 접속하면 구매 금액별 분석이 가능
- ex. 이커머스 앱 내 이벤트 페이지 내에
- 이런 데이터는 데이터베이스에 저장될 수도 있음
- 분석 용이성을 위해서는 유저 프로퍼티로 저장할 수도 있음
- ex. 특정 시점의 테이블에 저장된 데이터 추출 → JOIN
- 단, 유저 DB에서 확인할 수 있는 정보 중 정말 의미있다고 판단되는 것만 유저 프로퍼티로 넣는 것이 좋음
- AB test와 같은 실험을 할 때는 실험군과 대조군이 유저별로 계속 고정되어야 함 → 이런 정보를 유저 프로퍼티로 넣음
5. 데이터가 저장되는 형태
DB or Text File
- DataBase
- RDB (관계형 데이터베이스), NoSQL 등
- 회원정보, 주문정보 등 데이터는 로그 형태보다 DB에 저장
- Text File
- 하나의 파일에 데이터를 저장
- 텍스트 파일로 저장된 경우 다시 데이터 분석을 위해 데이터 웨어하우스로 옮기는 파이프라인이 필요할수도 있음
유저에게 빠르게 보여줘야 하는 경우 → DB
유저와 상관없이 분석용 → TextFile
6. 이벤트 로그 설계하는 방법
이벤트 로그의 Element
이벤트 로그에는 총 3가지 Element가 존재
- Event : 발생한 이벤트는 무엇인지
- Click, View, Swipe 등
- Trigger : 어느 시점에 실행되는지
- 특정 Component 클릭 시점
- 특정 화면이 보이는 경우
- 스와이프로 다음 화면에 넘어간 경우
- 서버의 Request 시점
- 서버의 Request 후 Response 시점
- 실행된 시간도 같이 기록
- State : 어떤 상태를 가지는지
- 어떤 User인지, 어떤 화면인지, 어떤 버튼을 클릭한 상태인지
- 이벤트 상태와 관련된 정보 제공
- 이벤트 파라미터 기록
7. 로깅 예시 (포켓몬)
- 무쇠체육관 관장을 이긴 경우
- event_name : mu_clear
- 무쇠체육관 id
- stage_id : 001
- 유저 아이디
- user_id : eunjeongee
- 각 포켓몬이 획득한 경험치
- {’Piplup’ : 200, ‘Magikarp’ : 100}
- 레벨업 유무
- {’Piplup’ : True, ‘Magikarp’ : False}
- 도전 시작 시간, 완료 시간
- start_timestamp
- end_timestamp
- 유저 캐릭터가 진화하는 경우
- event_name : character_levelup
- 기존레벨
- before_level : 1
- 레벨업 후 레벨
- after_level : 2
- 획득 경험치
- earned_exp : 200
8. 데이터 로깅 프로세스
단계별 설명
- 현 회사에서 데이터 로깅 관련 문서 또는 아키텍쳐가 있는지 확인하기
- 해당 프로젝트에서 메인으로 가져갈 지표 생각해보기
- 어떤 식으로 저장하면 좋을지 작성해보기
- 데이터가 어떤 형태로 저장되는지 확인
- 이 데이터를 어떻게 바라볼 수 있는지 생각
- 개발자 or 데이터분석가와 커뮤니케이션
- 확정된 로깅 가이드 문서를 개발자에게 전달
- 로깅 개발 완료 후 실제로 데이터가 잘 들어가는지 테스트
로깅 가이드 문서
- 이벤트 명
- 어느 상황에 로깅
- 언제부터 적용 (=언제부터 배포)
- 이벤트 세부 파라미터의 이름
- 들어가는 파라미터
- ex. 주문 완료 이벤트의 파라미터로 key : product_id, value : 1 등으로 저장될 수 있음 (product_id가 1번인 상품을 주문완료)
데이터 로깅 프로세스의 구분
데이터 로깅 설계, 데이터 로깅 작업, 데이터 QA로 나눌 수 있음
하지만 데이터 로깅 설계 전 **어떤 지표를 메인으로 볼 것인지?**를 구체화하는 것이 꼭 필요
- 어떤 지표를 메인으로 볼 것인지?
- 어떤 지표를 볼 것인지에 따라 로깅 계획이 달라짐 → 어떤 지표를 왜 보려 하는지 고민하는 것이 중요
- 생각했던 지표가 꼭 웹/앱이 아니라 DB의 데이터로 볼 수 있다면 굳이 로깅하지 않아도 됨
- 퍼널 단계를 볼 때 이런 데이터가 꼭 필요
- 데이터 로깅 설계
- 어느 시점에 어떤 데이터를 어떤 파라미터와 기록할 것인지, 유저의 프로퍼티를 저장할 것인지를 담은 데이터 로깅 추적 계획을 세우는 과정
- 데이터 로깅에서 모든 것을 남길 수는 없기 때문에, 지표에 대한 사전 고민을 가져야 필요한 것만 남길 수 있음
- 데이터가 로깅되면 어떻게 분석할 지 미리 생각해보기
- 데이터 로깅 작업
- 개발이 어느정도 끝나고, QA가 들어가는 시점 쯤에 작업
- 개발 중에 기획이 바뀌면 로깅도 바뀌어야 하고 로깅을 놓칠 수 있으므로 보통 모든 개발이 완료되거나 로직이 확정된 경우 로깅 시작
- 개발이 어느정도 끝나고, QA가 들어가는 시점 쯤에 작업
- 데이터 QA
- 데이터 로깅 작업에서 로깅한 데이터가 맞는지 확인
- 데이터 로깅 설계에서 정의한 내용이 잘 들어가있는지 확인
- 데이터 QA가 잘 되지 않으면 이상한 데이터를 볼 수 있으므로 확인 필요
특정 기능 개발을 위한 작업을 시작할 때
지표 생각 → 개발 착수
지표 기반으로 어떤 데이터를 로깅할 것인지 설계
설계한 내용을 개발자와 공유해서 어떻게 남길지 논의
로깅이 모두 개발한 후 데이터 QA 통해 데이터가 잘 저장되었는지 확인
9. 이벤트 로그 설계 템플릿(Tracking Plan)
이벤트 로그 설계시 스프레드시트 or 노션에 이벤트 로그 설계한 내용을 잘 기록해두는 것이 제일 중요함
- 로그 설계가 잘 관리되어야…
- 추후 데이터 분석시 어떤 이벤트를 봐야하는지 알 수 있음
- 추후 데이터 누락이나 이상한 상황을 확인할 수 있음
- ex. 특정 이벤트가 이상하다 → 데이터 로그 설계 확인 → 이슈 확인
Tracking Plan 작성 시점
- 새로운 기능이 출시
- 새로운 이벤트, 새로운 이벤트의 파라미터 수집 필요
- 데이터 타입 수정
- 데이터 수집 중지
Tracking Plan에 포함되는 정보
- 이벤트 이름
- 이벤트 설명
- 이벤트 카테고리
- 실행 시점
- 이벤트에 어떤 파라미터를 가지는지
- 파라미터 타입
- 파라미터 설명
- 파라미터 필수 여부
- 어느 플랫폼에서 남기는지
- 언제부터 남기는지
- 언제 수집 중지하는지
- 설계 완료 유무, 개발 완료 유무, QA 개발 유무, 배포 유무
10. 개인적인 이벤트 로깅 팁
지표에 대해 생각 → 로깅 설계
11. 데이터 QA
데이터가 제대로 들어가는지 확인하는 과정
12. 정리
Tracking Plan을 통한 전사적 데이터 관리가 중요
데이터 분석 전에 중요한 것은 데이터 로깅 설계와 데이터 QA
'Domain Knowledge' 카테고리의 다른 글
| [Ad] 플랫폼, 미디어 (0) | 2024.04.12 |
|---|