데이터 로깅 관련 이것저것

프로덕에서 로깅을 남길 때, 참고하면 좋을 이모저모를 남겨보려고 한다.

회사에 들어갔을 때, 이벤트 정의된 문서가 있다면 먼저 파악해보면 많은 도움이될 것 같다! (회사마다 방법이 다르니)

 

💡 지표를 뽑을 때, 항상 정형화된 방식으로만 생각하지말고 실제로 어떤 이유로 이 지표를 확인하려고 하는지를 생각하고! 고민하고 뽑을 수 있어야한다 & 각종 함정들에 대해 생각하고 고민하기

 

[이벤트 로그]

• event type(사용자 행동 유형) - event action(이벤트 타입 내에서 구분되는 사용자 행동) : description
  • visit : 페이지 방문시에 찍히는 로그 (page_id = 프로모션 페이지 / 홈탭 / 찜하기..등등) 
  • select_product : 상품상세를 클릭했을때 로깅 (어떤 상품을 클릭했는지 pid와 어느 페이지로부터 클릭되어 들어왔는지 함께 로깅 -> 지면별 pdp pv를 구할 때 사용된다)
  • select : 버튼 선택 시 로깅 (어떤 페이지의 어떤 버튼 - page_id / button_id로 구분된다. cta버튼 ctr 등을 확인할 때 사용)
  • impression : 검색결과 등의 리스트에서 상품이 노출될 때. (pid와 함께 기록, 어떤 광고 캠페인으로 노출되는지도 함께 로깅되면 좋음)
  • exposure : pid 노출 외(impression)의 앱 내의 컴포넌트 노출 (ex. 탑배너, 버튼)
  • launch : 사용자가 앱을 열었을 때
  • search : 어떤 검색어로 검색을 했는지가 로깅 (search_term)
  • 주의하면 좋을 점
    • 로그는 무겁기 때문에 항상 날짜 조건 걸어서 사용해줄 것 (WHERE절에 기술, 필요없는 데이터를 조회하지 않아 속도가 빠르다)
    • select *보다는 조회하는 컬럼을 명시하는 것이 더 빠르다
    • UTC 날짜라면 KST(한국 시간)로 변경해줄 것

 

---

[로깅 관련 지식]

+ 현업에서 기획전 페이지 성과 분석을 위해 추가 로깅 요청을 진행했던 적이 있는데

데이터 로그 설계에 대한 기초지식이 필요하다고 생각되어 추가로 공부해본 것들을 적어보려고 한다.

 

* 로깅을 해야하는 이유?

데이터를 남기지 않으면 나중에 볼 수 없음 + 성과 측정을 위해

 

• 데이터의 source
  • 데이터가 시작되는 곳, 데이터의 출처
  • 구조 : 클라이언트(=웹) <-> 서버(=백엔드) <-> DB(=데이터베이스)
    
    • 클라이언트가 서버에 API를 호출하는 request(요청)와 전달해주는 response(응답)로 이루어져있다.
    • 로직
      • 프론트(클라이언트) - 요청 > [백엔드(서버) - 요청 >  데이터베이스 ]
        프론트 < 응답 - [백엔드 < 응답 - DB]
    • 상세하게 돌아가는건 서버에서 작업하고, 그걸 사용하고 싶으면 프론트가 호출 (서버가 만든 api를 프론트가 호출하면 다시 db에 쌓인다.
    • 만약 서버에서 서버 성능 향상 관련한 논의를한다면, 서버에 로그를 심어야해서 서버와 협업이 이루어지지만, 분석가가 유저 행동 분석을 위한 로그 수집을 한다고하면, FE랑 협업할 일이 많음
• 데이터 target(저장소)
  • 데이터 베이스(RDBMS) : 서비스 운영 DB로 서비스의 운영을 위해 사용되며 mysql, oracle, postgresql
  • 데이터 웨어하우스 (DW) : DA들이 분석하기 편하라고 만든 DB, 따라서 매우 빠르고 Redshift(aws), BigQuery(GCP), Databricks, Snowflake 등이 있다.

중요한 것만 적어봤다.

 

중요한건 분석을 위해 추가 로깅을 할 때, 꼭 볼 지표 위주로 로그 설계를 한 후에 사용 목적이 명확할 때만 로그 설계를 하는 것이 중요하다.

사용되지 않을 데이터를 로깅하는 것은 리소스 낭비 (언젠가 사용되겠지 관점이 되어선 안된다!!!)

 

출처. 카일스쿨

 

---

[DW에 대한 이것저것]

 

• 스키마 (Schema)
  • 스키마는 각 테이블을 용도에 따라 묶어 놓은 것으로, 디렉토리 개념
    
    • [내부 스키마] 누구나 테이블을 생성할 수 있는, 작업 공간으로 사용한 스키마
    • [내부 스키마] 사용자, 상품 등 서비스 DB에 있는 데이터를 이전시킨 스키마
      • 서비스 DB에는 데이터가 쌓이고 있지만 DW에 없다면 이전 요청을 해야한다.
    • [내부 스키마] 배치작업으로 업데이트되는 테이블
    • [외부 스키마] 로그 데이터를 담고있는 테이블
      • 새롭게 로깅 추가작업을 했을 때, 해당 테이블이 없다면 역시 DW 이전 요청을 해야한다.
      • 외부 테이블에서 같은 데이터를 여러번 조회하는 경우에는 create table로 임시 테이블로 데이터를 옮긴 후에 처리하는 것이 더 효율적이다 (비용이 발생하기 때문)
      • 속도를 빠르게 효율적으로 조회할 수 있는 방법이 있을지 문서 찾아보기 🤔
        • 없다면 내가 찾아보는 방법도? (수행시간 기준)
    • 외부 스키마는 외부에 저장소를 별도로 둔 테이블이다. 로그 데이터와 같이 규모가 큰 데이터는 외부 저장소에 저장된 데이터를 읽어들이는 방식으로 작동한다. 아마도 사용할 때마다 비용 발생

 

*참고문서

프론트엔드 개발자의 이벤트 로깅 설계와 생산성 극대화 (React, Typescript)