[인프런] PM을 위한 데이터 리터러시_#7. 데이터 로그 설계, 데이터 QA

📌 이 글은 [인프런] 카일스쿨의 'PM을 위한 데이터 리터러시' 강의 내용을 요약 정리한 것입니다.

데이터 로그의 개념과 어려운 이유

로그

• 로그(log)의 사전적 의미 : 통나무, 일지에 기록하다
• 선박의 속도를 측정하기 위해 칩 로그라는 것을 사용
  • 배의 앞에서 통나무를 띄워서 배의 선미까지 도달하는 시간을 재는 방식
• 로그: 컴퓨터에 접속한 기록, 유저가 사용 기록 행동을 기록
• 로깅(Logging) = Log + ing 즉, 로그 설계

로깅을 해야하는 이유

• 서비스의 특정 기능 개발 후 배포할 때, 데이터를 남기지 않으면 나중에 볼 수 없음
• 기억력에 의존한다고 해도 유저 리뷰 등의 데이터, 일부분 데이터만 보고 확인할 수 있음
• 서비스의 성과를 측정하기 위해 정의한 지표를 알기 위해 데이터 로깅이 필요
• 즉, 지표 기반으로 우리의 성과 확인하기 위해 로깅이 필요

데이터 로그 설계가 어려운 이유

• 데이터 로그 설계에 대한 기초 지식(개발 지식 포함) 부족
  • 데이터가 저장되는 방식을 모름
  • 개발자분들이 알아서 해주는 줄 알았음
• 데이터 분석에만 집중하고, 데이터 저장에 집중하지 않음
• 데이터 로그와 관련된 배포 프로세스를 모름
• 커뮤니케이션을 어떻게 해야할지에 대한 고민
• 이슈 대응시 어떻게 대응할지 가이드의 부재
• 이를 해결하기 위해 데이터 로그 설계를 위한 기초 지식부터 알려줌

이 부분이 완전 공감되었다
그간 로그 설계에 대한 기초 지식이 부족했다

 

로그 설계를 위한 데이터 기초 지식

 

1. 데이터의 종류

• 데이터베이스에 저장되는 서비스 데이터
• 사용자 행동 데이터

2. 데이터의 Source : 어디에서 데이터가 발생하는가?

• 앱 / 웹 / 서버

3. 데이터의 Target : 어디에 저장할 것인가?

• 데이터베이스, 파일

4. API

5. 배포의 자유로움

6. 운영 환경(Production)과 개발 환경(Dev)

7. 데이터의 타입

 

데이터의 종류

• 데이터베이스 데이터(서비스 로그)
  • 서비스 운영되기 위해 필요한 데이터
  • 고객이 가입한 날, 어떤 물건을 구입했는지
  • 서비스에서 고객에게 보여준다면 대부분 데이터베이스에 저장하고 보여줌
• 사용자 행동 데이터(유저 행동 로그)
  • 서비스에서 유저의 활동
  • 더 좋은 제품을 만들기 위해 필요한 데이터
  • Click, View 등
  • 고객에게 보여줄 필요가 없고, 분석을 위해 활용하는 경우가 많음

PM, PO가 주로 관리하는 건
유저 행동 로그!

데이터의 Source : 어디에서 데이터가 발생하는가?

• 클라이언트
  • 서버에게 통신할 수 있는 기기
  • 스마트폰일 수도 있음
  • 회사마다 기준이 다를 수 있으나, 앱(APP) + 웹(WEB) 모두 클라이언트로 볼 수 있음
  • 클라이언트 로그 : 사용자가 어떤 행동을 했는가, UX 관점
    • “어떤 화면에 진입했는가?” / “어떤 버튼을 클릭했는가” / “백그라운드로 빠졌다”
• 서버(BE)
  • 클라이언트와 통신해 정보(데이터)나 서비스(기능)를 제공하는 컴퓨터 시스템
  • 서버에서 정보를 제공하기 위해 데이터를 저장하는 데이터베이스에 접근해 데이터를 조회

• 클라이언트 -> 서버(BE): Request(요청), API 호출
• 서버(BE) -> 클라이언트: Request에 대한 결과 반환 즉, Response(응답)

 

클라이언트와 서버의 개념은
원래 알고 있었지만 한 번 더 명확하게
정리하고 넘어가는 느낌!

데이터의 Target : 어디에 저장할 것인가?

• DBMS(Database)
  • 서비스에서 활용하기 위한 데이터를 저장하는 장소
  • 예 : 배달 가게, 배달 가게 메뉴 및 가격, 좌표, 배달 가게의 평점, 유저의 과거 주문건, 좋아요 누른건 등
  • 분석 용도로 활용할 수 있으나, 분석 용도보다 서비스에서 바로 활용되거나 고객에게 보이는 목적(운영 용도)
  • OLTP(온라인 트랜잭션 처리) : 거래(Transaction) 발생, 데이터 수정, 빠르게 처리
  • MySQL, Oracle, AWS RDS(Aurora), PostgreSQL
• 데이터 웨어하우스
  • 데이터 분석을 위해 사용됨
  • OLAP(온라인 분석 처리) : 데이터 분석에 초점
  • AWS Redshift, GCP BigQuery, Snowflake 등
  • 데이터베이스의 데이터를 데이터 웨어하우스로 옮기고, 유저 행동 로그, 외부 데이터를 모으는 과정을 데이터 엔지니어가 진행하며 이를 ETL 파이프라인 구축이라고 함. 데이터 웨어하우스 분석 속도가 더 빠름. 

데이터베이스와 
데이터 웨어하우스의 주요 용도를
명확히 구분할 수 있게 되었다!

• NoSQL
  • 데이터베이스 중 관계형 데이터베이스가 아닌 비관계형 데이터베이스
  • Not only SQL로 SQL만을 사용하지 않는 시스템
  • 엑셀 표 같이 저장하는 RDBMS와 다르게 Key Value로 구성
  • MongoDB, CouchDB 등

 

{“고향”: “인천”,
 “연령대”: “30대”
 “다닌 회사” : [{“name”: “A사", “기간”: “3년”},
                     {“name”: “B사", “기간": “4년”}] 

 

API(Application Programming Interface)

• 정보를 주고 받을 때 사용되는 인터페이스(약속, 형식)

배포의 자유로움

• 회사마다 제품을 어떻게 개발했는지가 다르며, 그에 따라 배포 방법이 달라짐
  • 웹(WEB)만 있는 경우
  • 앱(APP)만 있는 경우
  • 하이브리드: 웹과 앱을 같이 사용하는 경우
• 배포: 새로운 기능, 버전 출시하는 경우, 버그 픽스 등도 포함
  • 웹, 서버 : 배포가 자유로움 
  • 안드로이드: 거의 자유로움 
  • iOS: 심사 시간이 1~2일 소요 

데이터 수집 도구(무료)

• 웹: GA4
• 앱: Firebase 

웹&앱 모두 지원하는 SaaS: Product Analytics 도구(유료) 

• Amplitude
• Mixpanel

한 번씩은 다 들어본 툴 이름들인데
정확히 어떤 차이가 있는 것인지 
확실히 정리할 수 있었다!

 

운영 환경(Production)과 개발 환경(Dev)

• 개발할 때는 운영 환경(Production 환경)과 개발 환경(Dev)을 나눠서 개발함
• 배포 순서(회사마다 개발 프로세스가 다를 수 있음)
  • 1. 개발 배포(Dev, Staging)
    2. 운영 배포(Prod)
• 개발 환경에 배포한 경우 => 개발 환경 데이터베이스에 저장됨(DB의 분화)
• 데이터, 로그 확인도 개발 환경에서 확인 필요
  • 개발 환경에서 잘 기록된다면 운영 환경에서도 잘 기록되었을 것

 

데이터의 타입

• STRING : 문자열, 따옴표로 감싸서 사용. “카일”, “1”
• INTEGER : 숫자(정수), 따옴표로 감싸지 않음. 1
• FLOAT : 숫자(부동 소수점), 1.23
• TIMESTAMP : 특정 기준일을 토대로 시간을 숫자로 표현한 것. 1670901502
  • UTC TIMESTAMP : 1970년 1월 1일 자정을 0 밀리초로 기준으로 그 후로 몇 밀리초가 지닜는지 계산
  • 서버에서 시간을 다룰 때 대부분 TIMESTAMP
• DATETIME : 사람이 익숙한 날짜. 2022-12-12 12:18:34
  • DATETIME이 사람이 이해하긴 좋지만, 위치에 따라 시간이 다름(시차)
• 타임존 : 영국의 그리니치 천문대를 기준으로 지역에 따른 시간 차이를 조정하기 위한 구분선
  • 한국 : GMT+9(기준점 : 1970년 1월 1일 09:00:00)
  • UTC TIMESTAMP와 한국은 9시간 차이가 존재(UTC 00:00:00 = 한국의 09:00:00)

 

데이터 로그 설계 기초 지식 총 정리

 

---

데이터 로그 설계

데이터 로그 설계 Process

로깅 솔루션

• 아래 솔루션들의 본질은 동일함
  "필요한 데이터 정의 후, 정의한 상황이 되면 데이터를 이렇게 저장!"  
•  무료
  • (웹) Google Analytics 4
  • (앱) Firebase
• 유료 - 대부분 Product Analytics 도구
  • Amplitude
  • Mixpanel
• 그 외에도 마케팅 툴들도 로깅을 해야할 경우가 존재함
  • "도구 이름 API Document"를 확인하면 자세한 문서가 존재함

클라이언트 로그와 서버 로그

• 두 로그는 상호 보완적인 관계
• 클라이언트 로그
  • 앱, 웹 상에서 사용자의 행동
  • click, view..
• 서버 로그
  • API Request, Response 기록
• 틀리면 안되는 데이터, 돈과 관련된 데이터는 서버 로그로 저장하며, 클라이언트 로그는(Firebase) 유실될 수도 있음

Event와 User Property

1. Event Parameter : 이벤트의 정보

- “누가, 무엇을, 언제”

 

1) Event : 발생한 행위가 무엇인지
- Click, View, Swipe, Custom Event

2) Trigger : 어느 시점에 발생하는가?
- 유저가 특정 행동하는 경우 : Component를 클릭하는 시점
- 특정 화면이 보이는 경우(로딩이 시작된 경우, 로딩이 완료된 경우)
- 클라이언트가 서버에 Request하는 시점(API Request)

3) State : 어떤 상태를 가지는지
- 어떤 화면인지, 어떤 버튼을 클릭했는지?
- 그 당시에 클릭한 제품 id, 제품 카테고리 등
- 이벤트의 파라미터에 기록

 

2. User Property : 유저가 특정 이벤트를 하는 시점의 유저 정보

- "누가"에 대한 정보 기록 

- 특정 Event를 실행하는 시점의 유저 정보
- 예 : 우리 서비스의 가입일, 인구 통계 정보, 접속한 위치, 멤버십 레벨 등
- DB에도 있지만, Product Data 분석 도구에서 편의를 위해 기록

 

로그 설계 시,
클라이언트, 서버, 데이터 분석가
모두 같이 모여서 회의하기!

 

로그 설계 과정도
기능 개발에 포함된다는 것 중요! 

 

 

많은 데이터 로그 설계는 
개발자&데이터 분석가의 시간 많이 할애

-> 우선순위에 따라 단계적으로 구분한 후,
꼭 볼 지표 위주로 로그 설계할 것.

1. 꼭 해야 하는 것
2. 여유 있으면 하면 좋은 것
3. 추가적으로 사용성 목적으로 할 수 있는 것

같이 일하는 입장에서 상대를 압박되도록 하기 보다,
  점진적이고 단계적으로 표현할 것!
늘 감사함을 표현할 것.

 

 

Tracking Plan, Event Taxonomy

• Tracking Plan: 데이터 로그 설계 시 기록해두고, 데이터 분석 시 어떤 이벤트, 파라미터가 있는지 확인하는 공간(항상 최신화 상태로 유지해야 함)
• 데이터 로그 설계에 대한 내용을 공통적으로 저장하는 문서가 필요
• 공통화된 패턴을 잘 기록하고, 새로운 사람이 와도 확인할 수 있도록 온보딩 문서 작성
• Event 이름을 어떻게 사용할 것인가?
  • Event와 Component를 같이 쓰는 경우 : click_login_button
    • 분석 도구에서 Event Count를 쉽게 가능
    • Event Name으로 의미 파악 가능
    • 이벤트 갯수 제한이 존재할 수 있음
    • 이벤트가 너무 많아져서 관리가 어려울 수 있음
  • Event만 포함하는 경우 : click
    • 이벤트 갯수를 관리할 수 있음
    • 파라미터를 기반해 데이터를 판단할 수 있음
    • 파라미터 기반의 분석이 처음엔 어려울 수 있음
• Event 이름을 snake_case와 camelCase 어떤 것을 사용할 것인가?
  • 프로그래밍 언어마다 권장이 다름
  • 표시가 다르면 데이터를 볼 때 혼란스러움
  • 하나로 통일하고 가는 것이 좋음
  • SQL, 파이썬에선 snake_case를 권장, Node는 후자
• 최초에 시작할 수 있는 포인트
  • 스프레드시트
  • 노션

 

 

 

 

 

다양한 조직이 데이터를 잘 볼 수 있도록,
표준 규격을 만들자!
모두 같은 문서를 보며 이야기하도록 하자!!

 

 

Tracking Plan 설계하다가 어렵다면
클라이언트, 프론트엔드,
백엔드 개발자, 데이터 분석가분들에게 논의하자!

 

 

foodie express 케이스 연습 문제

메인 지표

- 추천 클릭률 = '추가' 버튼 click 수 / 최소 주문 금액 넘지 않은 상태에서 카트에 진입한 view 수 

- 추천을 통한 주문 전환율 = 추천을 통해 주문한 수 / 추천 클릭 수   

 

보조지표

- 전체 주문 수

- 해당 기능에서 우측 스크롤 이동 횟수 

 

<메인지표 로그설계>

1. 추천 클릭률(CTR) 

- 분자: click_recommend_food(parameter: food_id = 2134, food_name = 감자튀김, food_price = 7000, food_sequence = 1, is_meet_min_order_price = False, cart_price = 15000)

- 분모: view_recommend_food(parameter: is_meet_min_order_price = False, cart_price = 15000)

=> 둘다 is_meet_min_order_price = False일 때! 

 

2. 추천을 통한 주문 전환율(CVR) 

- 분자: click_payment

- 분모: click_recommend_food

=> 분자는 is_meet_min_order_price = True,  분모는 is_meet_min_order_price =  False일 때!

 

---

데이터 QA

• 데이터가 의도한대로 잘 저장되고 있는가?
• 의도한 시점에 이벤트가 발생하는가?

데이터 QA(Quality Assurance: 데이터 품질 향상 활동)로 확인하고 싶은 것

1. 데이터 로그가 기록되고 있는가?
2. 지정한 이름으로 지정한 값(Value)으로 기록되는가?
3. 지정한 데이터 타입대로 기록되는가?
4. 의도한 시점에 Trigger 되는가?
5. Android, iOS가 동일하게 데이터가 저장되는가?

데이터 QA 방법(Google Analytics, Firebase)

• 웹은 Google Analytics Debugger (opens new window)크롬 확장 프로그램 설치 후 진행

• 앱은 개발자분들에게 디버그 모드를 On 요청한 버전을 받고 설치해야 함
  • DebugView 문서 (opens new window)에 해당 내용이 정리되어 있음
  • 데이터 확인하는 것은 웹과 동일

데이터 QA 방법(Amplitude)

• Amplitude Event Explorer (opens new window)크롬 확장 프로그램 설치 후 진행

 

---

요약

데이터 로깅 포인트 

• 클라이언트(앱)
• 웹
• 서버 로그

성과 지표 설정 - 데이터 로깅 - 데이터 QA 과정 이해하기

Tracking Plan, Event Naming 가이드 설정하기 

조직에서 이 작업이 왜 중요한지 계속 설명하기

내가 좋아하는, 자주 사용하는 서비스를 보면서 역으로 로그 설계해보기(기록하고 블로그 등에 정리해보기)