데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA (1)

 

데이터 로그와 퍼널 분석에 대한 공부를 하다가 소중한 게시물을 찾아서 똑같이 필사하며 공부했다.

데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것 · 어쩐지 오늘은 (zzsza.github.io) 

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

 

 

데이터 로깅이란?

- 매일 사용하는 핸드폰, 카카오톡, 쿠팡 등 각각의 앱을 사용할 때마다 우리가 어떤 행동을 하는지 데이터가 남음

- 이런 데이터를 사용자 로그 데이터, 이벤트 로그 데이터 등으로 부름

 

로그의 어원

- 과거 선박의 속도를 측정하기 위해 칩 로그 라는 것이 사용됨

- 요즘엔 컴퓨터에 접속한 기록, 특정 행동을 한 경우 남는 것을 로그라고 부름

- 컴퓨터를 사용할 때도 로그인/로그아웃을 측정하기 위해 사용

 

데이터의 종류

- 데이터베이스 데이터(서비스 로그)

  - 서비스가 운영되기 위해 필요한 데이터

  - 고객이 언제 가입했는지, 어떤 물건을 구입했는지 등

  - Database에 저장되는 데이터를 서비스 로그라고 부르는 경우도 존재

 

- 사용자 행동 데이터(유저 행동 로그)

  - 유저 로그라고 지칭하면 사용자 행동 데이터를 의미함

  - 서비스에 반드시 필요한 내용은 아니지만 더 좋은 제품을 만들기 위해 또는 데이터 분석 시 필요한 데이터를 의미함

  - 앱이나 웹에서 유저가 어떤 행동을 하는지를 나타내는 데이터

  - UX와 관련해서 인터랙션이 이루어지는 관점에서 발생하는 데이터를 뜻함

  - Click, View, 스와이프 등

 

유저 로그 데이터의 예시

- user_id가 1인 user가 특정 웹 사이트에 로그인했다

- user_id가 1인 user가 제품 구매 페이지(URL)에 접근했다

- user_id가 1인 user가 제품 구매 페이지에서 특정(Component) 버튼을 클릭했다

- user_id가 1인 user가 제품 구매 요청(Requset)을 했다

- 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 등

 

4) 구글 애널리틱스(Google Analytics)

- 구글 애널리틱스는 구글에서 제공하는 웹 분석 서비스

- 웹사이트의 데이터를 수집, 분석해서 온라인 비즈니스 성과를 측정하고 개선할 때 사용하는 도구

- 구글 애널리틱스에 쌓인 데이터를 구글 클라우드의 빅쿼리로 추출할 수 있음(GA4를 사용하면 무료)

 

5) 구글 파이어베이스(Google Firebase)

- 구글 파이어베이스는 구글에서 만든 앱, 웹 애플리케이션 개발 플랫폼

- 파이어베이스를 사용해 앱을 만드는 경우, 빠른 시간 내에 비즈니스 로직을 구현해 앱을 만들 수 있음

- 최근 구글에서 GA와 Firebase의 이벤트 로깅 형태를 동일하게 변경하고 있으며, Firebase를 사용할 경우 앱 애플리케이션의 데이터를 설계만 하면 자동으로 구글 클라우드의 빅쿼리에 저장함

 

6) 구글 태그 매니저(GTM)

- 구글에서 출시된 솔루션 중 하나로, 다양한 태그를 관리할 수 있는 이벤트 트래킹 도구

- 구글 애널리틱스를 사용하면 page_view나 click은 쉽게 수집할 수 있지만 별도로 원하는 데이터가 있을 때 개발자에게 코드를 심어달라고 요청해야 함

    - 이런 경우 태그 매니저가 연결되어 있으면 개발자가 직접 정의하지 않아도 기획자, 마케터가 직접 정의해 데이터를 획        득할 수 있음

- 태그 매니저를 자유롭게 사용하기 위해선 HTML, CSS, 자바스크립트 기초를 알고 있으면 좋음

 

7) 배포의 용이성

- 앱(IOS/Android)은 출시할 때 항상 스토어의 Dependency가 존재함(안드로이드는 상대적으로 자유롭지만 IOS는 승인받아야 함)

    - 데이터 로깅에서, 앱에서 이슈가 생긴 경우 다시 배포하기에 시간이 소요될 수 있음

- 반면에 웹과 서버는 회사 내부의 이슈만 아니라면 다시 배포하기 수월한 편

    - 웹과 서버 로그는 로깅에 이슈가 있는 경우 빠르게 재배포 할 수 있음

- 배포의 용이성에 따라 어디에 남길지도 정할 수 있음

 

 

 

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

이벤트

- 예를 들어 회원 가입 버튼(Component)을 클릭한 경우

  - event : Click

  - 이벤트의 파라미터로 "어떤 버튼"을 클릭했는지 기록.

  - 예) component_name : sign_up

- 이벤트의 구체적인 상태, 세부 정보를 파라미터(또는 프로퍼티)에 저장함

- Firebase에선 이벤트의 파라미터를 Key라고 부르고, 파라미터에 저장된 데이터를 Value라고 부름

 

유저

- 유저가 특정 이벤트를 할 당시의 정보를 유저 프로퍼티로 저장함

- 예를 들어 이커머스 앱에 접속한 이벤트에 그 유저가 여태까지 제품을 구매한 횟수와 총 누적 구매 금액 등이 유저 프로퍼티로 저장되어 있으면 구매 금액별 분석을 할 수 있음

- 이런 데이터는 Database에 저장될 수도 있는데, 특정 시점의 테이블에 저장된 데이터를 추출한 후, Join해서 사용할 수도 있음. 그러나 분석의 용이성을 위해서 유저 프로퍼티로 저장할 수도 있음

- 단, 유저의 DB에서 확인할 수 있는 정보 중 정말 의미가 있다고 판단되는 것만 유저 프로퍼티로 넣는 것이 좋음. 혹은 사용자에 따라 수시로 변할 수 있는 옵션이거나 서버에선 모르는 경우 로깅

- AB Test 같은 실험할 때, 실험군과 대조군이 유저별로 계속 고정되어야 하기에 이런 정보를 유저 프로퍼티로 넣음

 

 

 

데이터가 저장되는 형태

- 저장되는 형태는 DB로 or 텍스트 파일로 크게 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인지, 어떤 화면인지, 어떤 버튼을 클릭한 상태인지?

      이벤트 상태와 관련된 정보를 제공함

      이벤트의 파라미터를 기록함

 

웹 클라이언트

- 보통 구글 애널리틱스를 연결하고, 구글 태그 매니저도 같이 사용함

- 구글 애널리틱스(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를 사용할 경우 링크에 있는 이벤트( [GA4] 자동 수집 이벤트 - 애널리틱스 고객센터 (google.com) )가 자동으        로 저장되며, 커스텀 이벤트를 정의할 수 있음

    - Firebase도 screen_view(웹에서 page_view와 유사한 개념), session_start, user_engagement 등 기본적인 이벤트가          존재함

- 클라이언트는 앱의 라이프사이클을 잘 이해하면 좋음. 예를 들어 백그라운드로 이동한 후, 다시 앱으로 진입하면 screen_view 이벤트가 또 찍힘

 

Firebase, Google Analytics 외에도 Snowplow, Segment, 자체 개발(Kafka, Pub/Sub 등 사용)을 해서 이벤트 데이터를 로깅할 수 있음

 

서버

- 서버 로그는 보통 API의 Request, Response를 기록함

- GA, Firebase가 아닌 서버 자체적으로 AWS S3 등의 저장소에 저장할 것이고, 그 데이터를 데이터 웨어하우스로 옮기는 데이터 파이프라인이 필요함

- 이런 데이터 파이프라인이 있어야 데이터 QA, 데이터 분석할 때 활용할 수 있음

 

위 데이터를 모두 한 곳에서 확인할 수 있도록, 데이터 웨어하우스에 데이터를 저장해 두는 것이 좋음

- DB의 데이터와 유저 행동 로그가 함께 있어야 로그를 중복해서 저장하지 않고, 필요시 JOIN해서 활용할 수 있음

- DB 데이터는 AWS의 Database에 저장되고, 앱/웹 유저 로그 데이터는 GCP의 빅쿼리에 저장되는 경우가 많은데, 우선 이 데이터를 한 곳으로 모아두는 작업이 필요함

 

 

 

로깅 예시(게임)

RPG 게임에서 특정 던전을 공략 완료한 경우 : event_name : stage_success

  - 캐릭터 각각이 획득한 경험치

     - {"indong":200, "space":150, "korea":400}

  - 레벨업 유무

     - {"indong":False, "space":True, "korea":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