데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것

in Data on Analytics


  • 이벤트 데이터 로그 설계, 데이터 로그 설계, 데이터 로깅, 데이터 QA에 대해 작성한 글입니다
    • 키워드: 데이터 로깅, 데이터 로깅이란, 데이터 로깅 시스템, Firebase event logging, 이벤트 로그 설계, 이벤트 로그 분석, 로그 데이터, 데이터 QA, 로그 데이터 설계
  • 예상 독자 : 데이터 로그 설계를 해야하는 기획자, PM, 마케터
  • 아래 나오는 내용을 토대로 PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 로그 설계, 실험, 지표 정의, 문화 만들기, 회고 등 다양한 내용을 담은 강의니 궁금하신 분들은 참고하셔도 좋을 것 같아요!
  • 목차
    • 데이터 로깅이란
    • 데이터 로깅을 해야 하는 이유
    • 데이터 로그 설계를 위한 기본 상식
    • 이벤트 파라미터, 유저 프로퍼티
    • 데이터가 저장되는 형태
    • 이벤트 로그 설계하는 방법
    • 로깅 예시(게임)
    • 데이터 로깅 프로세스
    • 이벤트 로그 설계 템플릿(Tracking Plan)
    • 개인적인 이벤트 로깅 팁
    • 데이터 QA
    • 정리


데이터 로깅이란?

  • 데이터는 이제 우리의 삶 어디에서나 볼 수 있음
    • 매일 사용하는 핸드폰, 카카오톡, 쿠팡 등 각각의 앱을 사용할 때마다 우리가 어떤 행동을 하는지 데이터가 남음
    • 이런 데이터를 사용자 로그 데이터, 이벤트 로그 데이터 등으로 부름
  • 로그의 어원
    • 로그를 사전에 검색하면 통나무라는 뜻이 나옴
    • 과거 선박의 속도를 측정하기 위해 칩 로그라는 것이 사용됨
    • 배의 앞에서 통나무를 띄워서 배의 선미까지 도달하는 시간을 재는 방식에 로그를 사용함
    • 요즘엔 컴퓨터에 접속한 기록, 특정 행동을 한 경우 남는 것을 로그라고 부름
    • 컴퓨터를 사용할 때도 로그인/로그아웃을 측정하기 위해 사용

  • 데이터의 종류
    • 데이터베이스 데이터(서비스 로그)
    • 사용자 행동 데이터(유저 행동 로그)
      • 유저 로그라고 지칭하면 사용자 행동 데이터를 의미함
      • 서비스에 반드시 필요한 내용은 아니고, 더 좋은 제품을 만들기 위해 또는 데이터 분석시 필요한 데이터를 의미함
      • 앱이나 웹에서 유저가 어떤 행동을 하는지를 나타내는 데이터
      • UX와 관련해서 인터랙션이 이루어지는 관점에서 발생하는 데이터를 뜻함
      • 예를 들어 Click, View, 스와이프 등
  • 유저 로그 데이터의 예시
    • user_id가 1인 user가 특정 웹 사이트에 로그인했다
    • user_id가 1인 user가 제품 구매 페이지(URL)에 접근했다
    • user_id가 1인 user가 제품 구매 페이지에서 특정(Component) 버튼을 클릭했다
    • user_id가 1인 user가 제품 구매 요청(Request)을 했다
    • user_id가 1인 user가 특정 웹 사이트에 로그아웃했다
  • “특정 상황을 이벤트로 정의하고, 이벤트의 파라미터가 어떤 것으로 저장해야 하는지” 등의 내용을 정의(설계)하는 행동을 데이터 로깅, 이벤트 로그 설계등으로 부름
  • 이 글은 사용자 행동 데이터(유저 행동 로그)를 로깅하는 관점에 대해 집중함


데이터 로깅을 해야 하는 이유

  • 데이터를 정확히 보기 위해, 데이터를 올바르게 기록해야 함
    • 데이터를 잘 심지 않으면, 이상한 데이터를 볼 수 있음
    • 또는 데이터 로깅을 하지 않는 경우, 데이터를 볼 수 없음(당연한 결과)
    • 혹은 과거에 출시된 기능에 대한 데이터 로깅을 하지 않았다면 그 데이터는 추가로 로깅하지 않는 이상 볼 수 없음
  • 데이터 관련 책, 강의에서 나오는 예제 데이터 이미 누군가 데이터 로깅을 진행한 결과를 집계한 데이터
    • DB면 스키마 정의를 할 것이고, 클라이언트/서버 등의 로그를 집계한 것
  • 회사에서 겪을 수 있는 상황
    • 로깅을 신경쓰지 않고 진행 ⇒ 특정 기능 배포 ⇒ 성과를 확인하려고 하니, 데이터에 누락이 있음을 발견(혹은 잘못된 로깅) ⇒ 다시 로깅을 한 후, 배포 ⇒ 과거 성과는 알 수 없음
    • 이런 경우를 방지하기 위해 데이터 로깅도 항상 진행쓰고 + 데이터 QA도 진행해야 함
  • 데이터 로깅 자동화할 순 없을까?
    • 모든 Interaction마다 자동으로 데이터를 저장하게 앱을 만들 수도 있음
    • 이런 경우 필요한 값이 모두 자동으로 저장되기 때문에 데이터 로깅 설계를 하는 시간을 아낄 수 있음
    • 그러나 이런 시스템 개발은 생각보다 공수가 들고, 결국 이런 시스템을 만들어도 커스텀하게 값을 저장하고 싶은 경우가 있어서 데이터 로깅 작업을 해야 함
    • 만약 레거시가 없이 새롭게 개발하고, 일정에 여유가 있다면 데이터 로깅 자동화를 한번 만들고 시작하는 것도 좋을듯
  • 보통 제품의 퍼널 데이터를 볼 때, 웹/앱에 로깅 작업이 필요함
  • 데이터 로깅 설계하는 주체
    • 회사에 따라 역할이 나뉘어져 있을 수 있고, 규모에 따라 다름
    • 데이터 로깅 설계하는 주체는 크게 1) 해당 기능을 만든 기획자, PM 2) 데이터 분석가 또는 데이터 엔지니어 로 나눌 수 있음
    • 해당 기능을 만든 사람이 “어떤 기능이 추가되었는지”, “어떤 데이터를 보고 싶은지”를 잘 알고 있으니 기획자, PM 직군에 계신 분들이 이벤트 로그 설계를 하기도 함
    • 데이터 분석가는 데이터 분석하는 관점에서 어떤 데이터가 어느 형태로 저장해야 데이터 분석할 때 활용할 수 있다는 의견을 줄 수 있음
    • 결국 꼭 기획자, PM, 데이터 분석가, 데이터 엔지니어 한쪽에서 이벤트 로그 설계를 하는 것보다, 서로 협업하는 구조로 가는 것이 좋음


데이터 로그 설계를 위한 기본 상식

  • 1) 데이터가 어디에서 발생하는지 확인해야 함(Source)
    • 대표적으로 서버 / 앱 / 웹
    • 서버 : 특정 API의 Request 정보를 기록함. 클라이언트나 웹에서 API 호출할 경우 저장함
    • 앱 : IOS/Android에서 만든 앱의 기록. 화면에서 유저가 어떤 화면에 진입했는지, 어떤 버튼을 클릭했는지 등을 기록함
    • 웹 : 웹 브라우저의 기록. 어떤 웹 페이지에 진입했고 어떤 버튼을 클릭했는지 등을 기록함
      • 유저가 앱/웹을 어떻게 사용하는지 궁금한 경우엔 앱/웹에 남기는 것이 좋고, 서버는 API의 요청을 남김
      • 두 가지는 상호 보완적이고, 특정 상황은 한 쪽에서 쌓기로 합의하는 것도 좋음
      • 그래도 데이터를 원하는 경우 앱/웹쪽에 로깅할지 서버에서 남길지를 알고 있으면 좋음 - 클라이언트와 서버에 대한 차이가 더 궁금하다면 어떤 개발자를 찾아가야 할까? 영상 추천!
      • 예를 들어 서버 API는 동일하지만 요청하는 화면이 다를 수 있음(화면 관련 파라미터도 없고) 이런 경우 클라이언트 로그에 심거나 서버 로그에 남기는 것이 좋음
    • DB와 파일 로그로 남기는 것은 빠르게 보여줘야 하는 경우엔 DB, 빨리 보여주지 않아도 괜찮고 서비스와 관련해 필수가 아닌 경우엔 파일 로그로 저장할 수 있음(파일로 저장한 후, 빅쿼리 등으로 옮김)
  • 2) 웹뷰(WebView)
    • Web View는 앱에서 웹 페이지를 띄우는 것. 예를 들어 앱에서 네이버나 구글의 웹 페이지를 보여주는 것
    • 웹뷰는 웹이므로 구글 애널리틱스로 데이터를 수집할 수 있음
    • 앱에서 웹으로 이동할 경우 사용함
    • 참고로 IOS에서 UIWebView가 있었고, 최근엔 WKWebView를 가이드로 주고 있음.
  • 3) 딥링크(Deeplink)
    • 딥링크 : 특정 페이지에 접근할 수 있는 링크
    • 모바일 딥링크 : 모바일 앱의 특정 페이지에 접근할 수 있는 링크
    • 딥링크를 사용하면 앱이 실행되거나, 앱이 설치되어 있지 않으면 스토어, 또는 앱 특정 화면으로 이동시킬 수 있음
    • 보통 페이스북 광고 ⇒ 광고 클릭 ⇒ (앱 설치) ⇒ 앱 화면으로 이동할 때 딥링크가 사용됨
    • 웹 URL처럼 앱마다 별도의 프로토콜이 있는데, 유튜브는 youtube:// 이런 식으로 시작됨
    • 웹에서 앱으로 이동할 경우 사용할 수도 있음
    • 딥링크의 종류는 URL Schemes, Universal Link, Deferred Deep Link 등이 있는데 해당 내용은 김나영님의 웹에서 앱으로 이동하기 (feat.딥링크) 글에 잘 나와있음
  • 4) 구글 애널리틱스(Google Analytics)
    • 구글 애널리틱스는 구글에서 제공하는 웹 분석 서비스
    • 웹사이트의 데이터를 수집, 분석해서 온라인 비즈니스 성과를 측정하고 개선할 때 사용하는 도구
    • 구글 애널리틱스에 쌓인 데이터를 구글 클라우드의 빅쿼리로 추출할 수 있음(GA4를 사용하면 무료)
  • 5) 구글 파이어베이스(Google Firebase)
    • 구글 파이어베이스는 구글에서 만든 앱, 웹 애플리케이션 개발 플랫폼
    • 파이어베이스를 사용해 앱을 만드는 경우, 빠른 시간 내에 비즈니스 로직을 구현해 앱을 만들 수 있음
    • 최근 구글에서 GA와 Firebase의 이벤트 로깅 형태를 동일하게 변경하고 있으며, Firebase를 사용할 경우 앱 어플리케이션의 데이터를 설계만 하면 자동으로 구글 클라우드의 빅쿼리에 저장함
  • 6) 구글 태그 매니저(GTM)
    • 구글에서 출시된 솔루션 중 하나로, 다양한 태그를 관리할 수 있는 이벤트 트래킹 도구
    • 구글 애널리틱스를 사용하면 page_view나 click은 쉽게 수집할 수 있지만 별도로 원하는 데이터가 있을 때 개발자에게 코드를 심어달라고 요청해야 함
      • 이런 경우 태그 매니저가 연결되어 있으면 개발자가 직접 정의하지 않아도 기획자, 마케터가 직접 정의해 데이터를 획득할 수 있음
    • 태그 매니저를 자유롭게 사용하기 위해선 HTML, CSS, 자바스크립트 기초를 알고 있으면 좋음
    • 자세한 내용은 GTM, Google Tag Manager 뜯어보기에 잘 나와있음
  • 7) 배포의 용이성
    • 앱(IOS/Andorid)는 출시할 때 항상 스토어의 Dependecy가 존재함(안드로이드는 상대적으로 자유롭지만 IOS는 승인받아야 함)
      • 데이터 로깅에서 앱에서 이슈가 생긴 경우, 다시 배포하기에 시간이 소요될 수 있음
    • 반면에 웹과 서버는 회사 내부의 이슈만 아니라면 다시 배포하기 수월한 편
      • 웹과 서버 로그는 로깅에 이슈가 있는 경우 빠르게 재배포할 수 있음
    • 배포의 용이성에 따라 어디에 남길지도 감을 잡을 수 있음


이벤트 파라미터, 유저 프로퍼티

  • 이벤트
    • 예를 들어 회원 가입 버튼(Component)을 클릭한 경우
      • event : Click
      • 이벤트의 파라미터로 “어떤 버튼”을 클릭했는지 기록. 예: component_name: sign_up
    • 이벤트의 구체적인 상태, 세부 정보를 파라미터(또는 프로퍼티)에 저장함
    • Firebase에선 이벤트의 파라미터를 Key라고 부르고, 파라미터에 저장된 데이터를 Value라고 부름
  • 유저
    • 유저가 특정 이벤트를 할 당시의 정보를 유저 프로퍼티로 저장함
    • 예를 들어 이커머스 앱에 접속한 이벤트에 그 유저가 여태까지 제품을 구매한 횟수와 총 누적 구매 금액 등이 유저 프로퍼티로 저장되어 있으면 구매 금액별 분석을 할 수 있음
    • 이런 데이터는 Database에 저장될 수도 있는데, 특정 시점의 테이블에 저장된 데이터를 추출한 후, Join해서 사용할 수도 있음. 그러나 분석의 용이성을 위해서 유저 프로퍼티로 저장할 수도 있음
    • 단, 유저의 DB에서 확인할 수 있는 정보 중 정말 의미가 있다고 판단되는 것만 유저 프로퍼티로 넣는 것이 좋음. 혹은 사용자에 따라 수시로 변할 수 있는 옵션이거나 서버에선 모르는 경우 로깅
    • AB Test 같은 실험할 때, 실험군과 대조군이 유저별로 계속 고정되어야 하기에 이런 정보를 유저 프로퍼티로 넣음


데이터가 저장되는 형태

  • 저장되는 형태는 DB냐 텍스트 파일로 저장되느냐 크게 2가지로 구분할 수 있음
  • DB : 데이터베이스로, RDB(관계형 데이터베이스)와 NoSQL 등이 있음. 회원 정보, 주문 정보 등의 데이터는 로그의 형태보다 DB에 저장함
  • 텍스트 파일 : 하나의 파일에 데이터를 저장함
    • 텍스트 파일로 저장된 경우 다시 데이터 분석을 위해 데이터 웨어하우스로 옮기는 파이프라인이 필요할 수 있음
  • 보통 유저에게 빠르게 보여줘야하는 경우, DB에 저장하고 유저와 상관없이 분석용이라고 하면 텍스트 파일로 저장할 수 있음
    • Disk IO vs File IO


이벤트 로그 설계하는 방법

  • 이벤트 로그는 총 3가지 Element가 존재함
    • 1) 발생한 이벤트가 무엇인지(Event)
      • Click, View, Swipe 등
    • 2) 어느 시점에 실행되는지(Trigger)
      • 특정 Component를 클릭하는 시점
      • 특정 화면이 보이는 경우
      • 스와이프로 다음 화면에 넘어간 경우
      • 서버의 Request하는 시점
      • 서버의 Request 후 Response가 되는 시점(이런 경우엔 Response에 있는 데이터를 알고 싶은 경우)
      • 실행된 시간도 같이 기록함
    • 3) 어떤 상태(State)를 가지는지
      • 어떤 user인지, 어떤 화면인지, 어떤 버튼을 클릭한 상태인지?
      • 이벤트 상태와 관련된 정보를 제공함
      • 이벤트의 파라미터를 기록함
  • 웹 클라이언트
    • 보통 구글 애널리틱스를 연결하고, 구글 태그 매니저도 같이 사용함
    • 최근에 Google Analytics 4가 정식으로 도입되었는데, 이 관련된 설명은 Google Analytics GA4 101 글에 잘 나와있음
    • 구글 애널리틱스(GA4)에서 자동으로 수집되는 이벤트는 다음과 같음
      • page_view : 특정 페이지에 접근할 경우
      • scroll : 스크롤을 얼마나 내렸는지
      • click : 클릭을 한 경우
      • view_search_results : 검색을 한 경우
      • video_start, video_progress, video_complete
      • file_download : 파일 다운로드하는 경우
    • Admin ⇒ Data Streams ⇒ Enhanced measurement에 해당 이벤트가 설정되어 있는 것을 확인할 수 있음
  • 앱(IOS/Android)
    • 어떻게 개발되었느냐에 따라 다르지만, 요샌 Firebase를 사용해 클라이언트 개발하는 경우가 많음
      • Firebase를 사용할 경우 다음 링크에 있는 이벤트가 자동으로 저장되며, 커스텀 이벤트를 정의할 수 있음
      • [Firebase] 자동으로 수집되는 이벤트
      • Firebase도 screen_view(웹에서 page_view와 유사한 개념), session_start, user_engagement 등 기본적인 이벤트가 존재함
    • 클라이언트는 앱의 라이프사이클을 잘 이해하면 좋음. 예를 들어 백그라운드로 이동한 후, 다시 앱으로 진입하면 screen_view 이벤트가 또 찍힘
  • Firebase, Google Analytics 외에도 Snowplow, Segment, 자체 개발(Kafka, Pub/Sub 등 사용)을 해서 이벤트 데이터를 로깅할 수 있음
  • 서버
  • 위 데이터를 모두 한 곳에서 확인할 수 있도록, 데이터 웨어하우스에 데이터를 저장해두는 것이 좋음
    • DB의 데이터와 유저 행동 로그가 함께 있어야 로그를 중복해서 저장하지 않고, 필요시 JOIN해서 활용할 수 있음!
    • DB 데이터는 AWS의 Database에 저장되고, 앱/웹 유저 로그 데이터는 GCP의 빅쿼리에 저장된 경우를 정말 많이 봤는데, 우선 이 데이터를 한 곳으로 모아두는 작업이 필요함!
  • 데이터 로깅 사례 발표는 백정상님의 로그 기깔나게 잘 디자인하는 법 발표 자료 추천!


로깅 예시(게임)

  • 로깅 네이밍은 제가 임의로 한거라 양해 부탁드립니다! 느낌만 봐주세요
  • RPG 게임에서 특정 던전을 공략 완료한 경우 : event_name : stage_success
    • 캐릭터 각각이 획득한 경험치
      • {“kyle”: 200, “metamong”: 150, “zzsza”: 400}
    • 레벨업 유무
      • {“kyle”: False, “metamong”: True, “zzsza”: True}
      • 이 값은 직전 레벨과 이후 레벨을 남기는 것이 좋을 수도 있음. 예를 들어 레벨을 한번에 5이 올라갔는지, 1이 올라갔는지는 지금 로깅 구조로 알기 어려움.
      • 혹은 레벨업 유무를 꼭 이벤트에 기록하지 않고, 그 다음 이벤트에서 레벨이 몇이였는지 기록할 수도 있음
    • 던전 id
      • stage_id : 200
    • user_id
    • 공략 도전 시간, 공략 완료 시간
      • start_timestamp
      • end_timestamp
    • 자동 사냥 유무
      • auto_mode: True
  • 유저의 캐릭터가 레벨업 하는 경우 : event_name : character_levelup
    • 기존 레벨
      • before_level : 5
    • 레벨업한 후 레벨
      • after_level : 10
    • 획득 경험치
      • earned_exp : 300
    • 물약 유무
      • use_portion : True


데이터 로깅 프로세스

  • 단계별 설명
    • 0) 현 회사에서 데이터 로깅 관련 문서 또는 아키텍쳐가 있는지 확인하기
    • 1) 해당 프로젝트에서 메인으로 가져갈 지표 생각해보기
    • 2) 어떤 식으로 저장하면 좋을지 작성해보기
      • 데이터가 어떤 형태로 저장되는지 확인해보고, 이 데이터를 어떻게 바라볼 수 있는지 생각해보기
    • 3) 개발자 또는 데이터 분석가와 커뮤니케이션(이 데이터를 볼 수 있는지 등)
    • 4) 확정된 로깅 가이드 문서를 개발자에게 전달
    • 5) 로깅 개발 완료 후, 실제로 데이터가 잘 들어갔는지 테스트
    • 로깅 가이드 문서는 스프레드시트 등을 통해 관리하면 좋음
      • 이벤트 이름은 무엇인지
      • 어느 상황에 로깅되는지
      • 언제부터 적용되는지(=언제 배포되었는지)
      • 이벤트의 세부 파라미터의 이름은 무엇인지(Firebase에선 Key라고 표현함), 어떤 Parameter가 들어가는지(예를 들어 주문 완료 이벤트의 파라미터로 Key:product_id, Value : 1 등으로 저장될 수 있음. 이는 product_id가 1번인 주문을 완료했다는 뜻)
  • 데이터 로깅 프로세스는 크게 데이터 로깅 설계와 데이터 로깅 작업, 데이터 QA으로 나눌 수 있음
  • 데이터 로깅 설계
    • 어느 시점에 어떤 데이터를 어떤 파라미터와 기록할 것인지, 유저의 프로퍼티를 저장할 것인지를 담은 데이터 로깅 추적 계획을 세우는 과정
    • 데이터 로깅 설계 전에 어떤 지표를 메인으로 볼 것인지?를 구체화하는 것이 꼭!!! 필요함.
      • 어떤 지표를 볼 것인지에 따라 로깅 계획이 달라지므로 어떤 지표를 왜 보려고 하는지 고민하는 것이 중요함
      • 생각했던 지표가 꼭 웹/앱이 아니라 Database의 데이터로 볼 수 있다면 굳이 로깅하지 않아도 괜찮음
      • 퍼널 단계를 볼 때 이런 데이터가 꼭 필요함
    • 지표를 설정하는 방법에 대해 관심이 많으면 추후 글로 다룰 예정
    • 데이터 로깅에서 모든 것을 남길 수는 없기 때문에, 이런 지표에 대한 사전 고민이 있어야 필요한 것만 남길 수 있음. 필요하지 않는 것은 굳이 남길 필요가 없음!(=데이터가 로깅되면 어떻게 분석할지 미리 생각해보기)
  • 데이터 로깅 작업은 개발이 어느정도 끝난 후, QA에 들어가는 시점 쯤에(거의 출시 직전) 작업함
    • 개발 중에 기획이 바뀌면, 로깅하는 부분도 바뀌어야 하고 로깅을 놓칠 수 있으므로 보통 모든 개발이 완료된 후, 또는 로직이 진짜 확정된 경우 로깅을 시작함
    • 데이터 로깅 작업(개발자가 데이터 로깅 설계를 보고 코드에 작성하는 경우)
  • 데이터 QA
    • 데이터 로깅 작업에서 로깅한 데이터가 맞는지 확인하는 과정
    • 개발자가 직접 하는 경우도 존재하고, 기획자, PM, 데이터 분석가, QA 등 회사마다 어떤 사람이 할지 다름
    • 위에서 데이터 로깅 설계에서 정의한 내용이 잘 들어가있는지 확인함
    • 데이터 QA가 잘 되지 않으면 이상한 데이터를 볼 수 있으므로(데이터 유실 등) 꼭 확인해야 함
  • 정리
    • 특정 기능 개발을 위한 작업을 시작할 때 지표에 대해 생각한 후, 개발 착수함
    • 그 후에 지표 기반으로 어떤 데이터 로깅을 할 것인지 설계
    • 설계한 내용을 개발자분들과 공유해서 어떻게 남길지 논의. 이 과정에서 개발이 어떻게 되었느냐에 따라 앱/웹에서 남길지 서버에서 남길지가 결정되기에 관련 개발을 하는 개발자분들과 모두 회의하는 것을 추천
    • 로깅이 모두 개발한 후, 데이터 QA를 통해 데이터가 잘 저장되었는지 확인
    • 간혹 데이터 로깅 없이 출시하자는 경우도 있는데, 이런 경우 유저가 어떤 부분을 사용하고 있는지 알 수 없어 그 이후 방향성을 잡을 때 힘들어짐


이벤트 로그 설계 템플릿(Tracking Plan)

  • 이벤트 로그 설계시, 스프레드시트 또는 노션에 이벤트 로그 설계한 내용을 잘 기록해두는 것이 제일!!! 중요함
    • 이 로그 설계가 잘 관리되어야 추후 데이터 분석시 어떤 이벤트를 봐야하는지 알 수 있음
    • 이 로그 설계가 잘 관리되어야 추후 데이터 누락이나 이상한 상황을 확인할 수 있음(특정 이벤트가 이상하다 => 데이터 로그 설계 확인 => 이슈 확인 등)
    • 스프레드시트, 노션, 자체 개발한 시스템 등 어디에 저장할지는 조직의 상황에 따라 다름. 다만 처음 시작할 땐 개발 공수가 들지 않는 곳에서 시작하고 점점 개발하는 것을 추천
    • 관련 내용이 궁금할 경우 데이터 거버넌스(Data governance)를 검색하면 데이터 관리에 대한 내용이 나옴
  • 이벤트 로그 설계는 Tracking plan이란 단어로 검색하면 템플릿이 꽤 나옴
  • Tracking Plan을 작성하는 시점
    • 새로운 기능이 출시되는 경우
    • 새로운 이벤트, 새로운 이벤트의 파라미터를 수집해야 하는 경우
    • 데이터 타입을 수정하는 경우
    • 데이터 수집을 중지하는 경우
  • Tracking Plan의 장점
    • 이벤트, 이벤트의 파라미터 등이 어떤 방식으로 기록되어 있는지 한번에 볼 수 있음
    • 데이터 중복을 피할 수 있음. 동일한 데이터를 여러 번 수집하지 않음
    • 데이터의 부정확성을 피할 수 있음 : 일관된 방식으로 데이터를 로깅
    • 모든 사람들이 사용할 때, 동일한 규칙으로 로깅함
    • 처음 개발하는 사람들도 다른 사람이 이미 만든 이벤트 로그 설계를 참고할 수 있음
  • Tracking Plan에 포함되는 정보
    • 이벤트의 이름
    • 이벤트의 설명
    • 이벤트의 카테고리가 무엇인지(추상화 또는 도메인)
    • 어느 시점에 실행되는지
    • 이벤트에 어떤 파라미터(또는 프로퍼티)를 가지는지
      • 파라미터의 타입
      • 파라미터의 설명
      • 파라미터의 필수 여부(Required)
    • 어느 플랫폼에서 남기는지
    • 언제부터 남기기 시작했는지
    • 언제 수집을 중지했는지
    • 설계 완료 유무, 개발 완료 유무, QA 개발 유무, 배포 유무 등
  • Avo의 Analytics Tracking Plan Template
    • 특정 KPI, Metric에서 사용할 수 있는 이벤트를 모아두는 형태
  • Segment의 Tracking Plan(Basic)
  • Amplitude의 Basic Event Taxonomy Template
  • Practico Analytics의 Analytics Tracking Plan
    • Event Lifecycles을 구분하고 Priority를 작성한 부분이 특이함. 이 중요성을 관리할 주체가 필요함
  • Mixpanel
  • Data-led의 Tracking Plan
    • Activation, Adoption, Revenue, Page view 관점으로 데이터 로그 설계
  • 위에 링크로 연결된 Tracking Plan을 모두 확인해보고 => 회사에 맞는 Tracking Plan을 만드는 것을 추천!!!
  • 공통적으로 파라미터의 이름을 이렇게 사용하자! 정의하는 것도 중요하고, 화면의 이름도 개발 - 디자인 - 기획에서 통일되면 데이터 로깅 설계시 그대로 활용하면 좋음. 개발과 기획에서 부르는 이름을 통일하면 로깅 설계도 편함


개인적인 이벤트 로깅 팁(★★★)

  • 로그는 최대한 자세할수록 좋지만, 우선 순위를 정할 필요가 있음
    • 자주 봐야하는 지표라면 꼭 심는 것이 좋음
    • 모든 것을 다 로깅하면 좋지만, 그러기 힘든 이유는 로깅을 위해 추가적인 개발이 필요하거나 저장하는데 부하나 비용이 될 수 있음. 우선 순위를 항상 작성하면 좋음
    • “모든 데이터를 저장하는 것이 중요한 것이 아니고, 필요한 데이터를 적재 적소에 남기는 것이 중요함. 보고 싶은 데이터라고 하면 끝이 없기에 먼저 지표에 대해 생각하고 그 기반으로 로깅 설계하기!”
    • “사용되지 않을 데이터를 저장하기 위해 시간을 쓰는 것은 아깝다. 데이터가 남으면 어떤 분석이 가능할지 고민해보기”
  • 클라이언트 VS 서버
    • 보통 서버 로그로 모두 해결될 수 있지만, 앱의 사용 관점이 궁금한 경우 클라이언트 로그를 심는 것이 좋을 수 있음
    • 서버 로그의 경우 어떤 페이지에서 입력했는지를 알 수 있어야 하는데, 이렇게 개발이 안되었다면 특정 API가 3 화면에서 불릴 경우 어떤 화면에서 불렸는건지 확인할 수 없음
    • 클라이언트와 서버 로그는 보완재로 사용하면 좋음
  • 보통 로그 파일로 저장하면, AWS S3에 저장하는데, 이 파일을 지우지 않고 보관하는게 좋고, 비용상의 이슈가 있다면 AWS의 콜드라인으로 저장해 비용을 절감할 수 있음
  • 내가 아는 것 ≠ 개발자가 아는 것
    • 개발자의 언어로 이해해야 함
    • API 호출이라면 Request하는 시점을 기록할 것인지, Response를 기록할 것인지(성공/실패 유무나 실패의 원인 등이 궁금한 경우) 정확히 명시해줘야 커뮤니케이션이 좋음
  • 서비스마다 다름
    • 게임이여도 일반 RPG, 방치형 RPG 모두 비슷하지만 어떤 것을 로깅할지에 대한 생각이 다름
  • 로그 네이밍 룰이 있으면 좋음(영어 동사로 시작한다, 명사로 시작한다 등)
  • 어떻게 개발되었느냐에 따라 어디에 로깅을 남길지가 다르기 때문에 협업!! 기획자, PM, 개발자(프론트, 앱, 서버), 데이터 분석가, 데이터 엔지니어와 적극적으로 이야기하기
  • 로깅할 때, 개발이 많이 변경되야 하는 경우가 존재함. 이런 경우 이 데이터를 통해 어떤 지표를 볼 것이고, 이 지표가 어떻게 변하면 우리가 이런 행동을 할 수 있다고 적극적인 데이터 활용 사례를 이야기하며 개발자분들을 설득하기
    • 데이터 로깅이 불필요한 일이 아니라는 것을 지속적으로 알려주며, 이 데이터를 통해 이런 분석이 나왔다고 감사함 표현하기!
    • 왜 이 데이터 로깅이 중요하고, 어떤 문제를 해결할지에 대한 목적을 알려주는 것이 중요함
  • 데이터 로깅 설계에 집중한 후, 데이터를 잘 확인할 수 있는 공간에 대한 이야기를 하는 것도 중요함(데이터를 잘 봐야 의미가 있으니!!)
  • 이벤트 이름을 파라미터까지 포함해서 저장하는 경우 vs 이벤트만 추상화하는 경우
    • 전자 : event_name: click_signup
    • 후자 : event_name: click로 남고 파라미터인 component_name : signup로 저장하는 경우
    • 어떤 플랫폼을 사용하느냐에 따라 다른데, Firebase나 Google Analytics라면 이벤트 이름의 갯수 제한이 있음(500개). 따라서 이런 경우에 이벤트 이름은 추상화하고, 파라미터로 관리하는 것이 좋음
      • 전자의 경우도 빅쿼리에서 쿼리하는 비용 차원에서 파라미터를 포함하지 않아서 쿼리 비용이 감소함(파라미터까지 쿼리할 경우 빅쿼리에서 비용이 증가되기 때문)
    • 장기적으로 잘 관리하기 위해선 이벤트 속성을 추상화하는 것이 좋음


데이터 QA

  • 데이터가 제대로 들어가는지 확인하는 과정
  • 회사에서 겪을 수 있는 케이스
    • 오타!
    • string으로 넣어야 하는데 integer로 넣은 경우!
    • 안드로이드와 IOS가 다른 경우!
    • 갑자기 특정 버전부터 값이 남지 않는 경우!
  • 데이터 QA를 위한 자동화 시스템을 만드는 것도 좋음
  • Firebase, Google Anayltics의 경우 DebugView 사용하고, 서버 로그의 경우 자체적으로 구축한 시스템을 사용함
  • 데이터 QA 자동화할 요소
    • 해당 이벤트에 값이 들어갔는가?
    • 파라미터가 잘 설정되어 있고, 값이 저장되는가?
    • 값이 여러가지인가?
    • 기존에 정의된 타입과 동일하게 데이터가 저장되는가?
    • 갑자기 N일 동안 데이터가 들어오지 않았는가?
  • 앱/웹에서 개발 버전에선 토스트 팝업으로 저장되고 있는 로깅을 보여주면 DebugView를 보지 않아도 되서 편함


정리

  • 제일 중요한건 전사적으로 이런 데이터를 잘 관리해야 데이터를 확인할 수 있음(Tracking Plan)
  • 데이터 분석 전에 중요한 것은 데이터 로깅 설계! 데이터 QA!
  • 앱, 웹 사이드에서 저장되는 데이터는 유저의 인터랙션 데이터, 서버 사이드에서 저장되는 데이터와 보완재로 사용할 수 있음


참고 자료


카일스쿨 유튜브 채널을 만들었습니다. 데이터 분석, 커리어에 대한 내용을 공유드릴 예정입니다.

PM을 위한 데이터 리터러시 강의를 만들었습니다. 문제 정의, 지표, 실험 설계, 문화 만들기, 로그 설계, 회고 등을 담은 강의입니다

이 글이 도움이 되셨거나 의견이 있으시면 댓글 남겨주셔요.

Buy me a coffeeBuy me a coffee



© 2017. by Seongyun Byeon

Powered by zzsza