데이터 로그 기획

1. 데이터 로깅의 정의, 해야하는 이유
2. 데이터 기본 지식
3. 프로젝트 프로세스와 함께하는 데이터 로깅 예시
4. 로그 설계하면서 고민할 포인트

1. 데이터 로깅의 정의, 해야하는 이유

데이터는 서비스에 대한 기록이다. 기록을 남기지 않으면 나중에 볼 수 없고 이로 인해 성과 측정이 불가하게 된다.

서비스 오픈 시 자주 하는 실수들
1. 서비스의 버전이 업그레이드 되는 경우에도 필요한 데이터들을 세분화하여 정의 필요하다.
2. 배포한 후에 데이터 로깅이 잘못된 경우 수정 후 재 배포가 필요하다. 이 때 이전 데이터는 확인할 수 없음
3. 내가 원하는 데이터가 잘 정의되어 있는지 확인이 필요하다. 배포 후에 잘못된 데이터가 수집될 경우가 있음

2. 데이터 기본 지식

데이터는 크게 2가지 영역에서 기록될 수 있다.

클라이언트와 서버 (출처: 위키백과)

1. Server: 서버(server)는 클라이언트에게 네트워크를 통해 서비스하는 컴퓨터를 의미한다. (출처: 나무위키 '서버')

2. Client: 클라이언트-서버(client-server) 구성에서 사용자가 서버에 접속하기 위해 사용하는 프로그램 또는 서비스를 말한다. (출처: 나무위키 '클라이언트')

서버와 클라이언트는 요청과 응답을 진행하면서 기록을 만들어내는데, 이를 로그라고 한다.
클라이언트와 서버 로그는 상호 보완적으로 기록이 가능하나 가능하다면 서버의 로그를 활용하는 것이 좋다.

3. 프로젝트 프로세스와 함께하는 데이터 로깅 예시

로깅을 할 수 있는 솔루션에 대표적으로 Google Analytics가 있다.

"우리가 필요한 데이터를 정의하고 이 시점에 이렇게 남겨줘"를 설정할 수 있다.

그러면 우리가 필요한 데이터를 어떻게 정의할 수 있나요? 이는 힙데비 주차 별 과제에서 이미 고민을 해 왔습니다.
아래 절차를 토대로 필요한 데이터를 정의할 수 있습니다.

해결하고자 하는 Pain Point가 무엇인가요?

이를 해결하기 위해 확인해야하는 지표는 무엇이 있을까요? 이 지표는 왜 봐야하나요?

이번 Feature에서 볼 지표들은 무엇인가요?

지표 중 메인 지표, 보조 지표, 운영 지표, 가드레일 지표는 어떻게 되는가? 메인 지표 : 해당 기능의 성장성을 확인할 수 있는, 기능의 성공을 판단할 지표 보조 지표 : 해당 기능으로 궁극적으로 변하면 좋겠다고 생각하는 지표, 그 기능 관련해서 필요한 지표 운영 지표 : 운영하면서 계속 체크해야 하는 지표 가드레일 지표 : 이 지표는 떨어지면 안된다 하는 지표

지표를 분자와 분모로 작성하면 어떻게 되는가?

데이터 로그 설계 시 고려해야 하는 점이 있다. '누가, 무엇을, 언제, 왜'를 기준으로 아래 정보들을 로깅할 수 있다.

1) Event : 발생한 행위가 무엇인지(Event)
- Click, View, Swipe, Custom Event
2) Trigger : 어느 시점에 저장되는가
- 유저가 특정 Component를 클릭하는 시점
- 특정 화면이 보이는 경우(로딩이 시작된 경우, 로딩이 완료된 경우)
- 클라이언트가 서버에 Request하는 시점
- 서버가 Request를 처리하고 Response가 보이는 시점
3) State : 어떤 상태를 가지는지
- 어떤 user인지, 어떤 화면인지, 어떤 버튼을 클릭했는지?
- 그 당시에 노출된 답변 id, 답변 수 등
- 이벤트의 파라미터를 기록

4. 로그 설계하면서 고민할 포인트

데이터 로그 설계 시 내가 설계를 하였어도 다른 팀에서 볼 가능성이 크다. 이에 데이터 로그 설계에 대한 정보도 WIKI화 하여 함께 공유하는 것이 필요하다.

데이터 QA가 제일 어렵다. 기록이 되는지, 타입, 명칭과 값, 의도한 순서대로 기록 되었는지 등등 점검할 항목들이 많기도 하지만 다양한 환경에서 테스트가 필요한 부분이다. QA는 최대한 자동화하는 것이 좋다!