나는 내가 기획한 서비스에 대해 얼마나 잘 알고 있을까?
고객, 유저들이 어떤 콘텐츠를 선호하고, 어떤 기능에서 어려워하는지 알고 있나?
더 좋은 서비스를 위해 유저들의 행동들에 대해 분석할 필요가 있다.
유저 데이터를 기록하고, 볼 수 있는 방법에 대해 알아보자.
로그 데이터
서비스를 이용하는 유저의 모든 행동 데이터를 우리는 '사용자 로그 데이터', '이벤트 로그 데이터'라고 부른다.
로그(Log) : 이벤트에 대한 기록
- 시스템 로그
: 프로그램의 버그나 OS 레벨에서 시스템 이벤트를 추적하기 위한 기록들
- 서비스 로그
: 유저의 입장/퇴장, 아이템 구매, 획득 및 사용 등(KPI, CS) 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들
- 유저 로그 (사용자 행동 데이터)
: UX와 관련해서 인터랙션이 이루어질 때 발생하는 데이터로 Click, View, 스와이프 등
그럼, 우리가 봐야할 좋은 로그란 무엇일까?
- 필요한 정보가 있다
- 의미(event)가 명확하다
- 편리하게 데이터를 얻을 수 있다
좋은 로그를 위해서는 로그에 대한 충분한 설계와 지속적인 품질 관리가 필요하다.
1. 필요한 정보가 있는 로그
- 목표가 있는 로그
- 한 문장으로 정의된 목표
- 목표를 위해 다양한 각도의 고민
- 목표에 따라 남겨야 할 이벤트와 항목들 정의 - 일관성 있는 로그
- 로그 간의 구성요소들이 일관적이어야 함 - 믿을 수 있는 로그
- 의도한 시점에서 발생했을 것이라는 믿음 (버그로 인한 유실, 설계와 다른 시점에서 로그 발생은 일어나면 안됨)
- 의도한 대로 데이터가 남았을 것이라는 믿음 (단순 실수. 어뷰징에 의한 변조는 일어나면 안됨)
신뢰가 깨진다면 로그는 쓸 수 없게 되거나 다루는데 많은 시간이 필요하게 된다.
2. 의미가 명확한 로그
- 이름에 대한 합의와 규약
- 이벤트, 항목의 이름이 의미를 충분히 표현할 수 있어야 함
- 나중에 이름을 바꾸는 건 큰 비용이 발생할 수 있음
- 때문에 길더라도 구체적인 이름을 사용해 다른 의미와의 혼동을 피한다
- 이름을 정의하기 위한 최소 규약(Naming convention) 정의
Naming convention
- 이벤트 이름
1. 파스칼 표기법(단어의 첫문자를 대문자로 시작)을 따른다.
2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다.
ex) 플레이어의 아이템 획득 → PlayerGotItem
구성요소 → Player, Item
행동 → Get(Got)
- 항목 이름
1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다.
ex) Player_level
... (중략)
- 이벤트를 구분하는 기준
- '퀘스트의 시작', '퀘스트의 종료' 각각의 이벤트 VS '퀘스트 상태 업데이트' 하나의 이벤트
- <상태>의 시작과 종료
: 의미적으로 명확한 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. 시작과 완료 항목 구성 차이가 큰 경우 적합
- <상태> 업데이트
: 로그 항목에서 상태변화의 종류를 알 수 있는 구조. 아래의 경우에 편리한 분석이 가능함
a. 같은 구성요소에 대해 상태만 변한다
b. 항목 구성이 거의 비슷하다
c. 이력의 변화가 중요하다
- 한 이벤트가 억지로 여러 개 이벤트를 포괄하지 않도록 한다
a. 특정 이벤트에 대한 내용이 변경될 때 유연한 대처가 어렵기 때문
b. 이벤트 항목의 이름이 여러 의미를 갖게 되어 불명확해짐
c. 데이터 타입이나 표현 방법이 통일되면서 데이터를 상세하게 남기지 못할 수 있음 - 표현력
- 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다.
- 경우에 따라 데이터 타입에 대한 고려가 필요하다. (ex. 소수점 표현, 숫자 범위 등) - 빈 값의 의미를 명확하게
- 빈 값은 해당 항목에 대한 정보가 아예 없을 경우, 실제 값이 빈 값이 경우 등 다양하게 해석될 수 있기 때문
3. 편리하게 데이터를 얻을 수 있는 로그
- 로그 형식
- 서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많음
- 집계나 검색을 위해 컴퓨터가 읽기 쉽도록 구조화된 형식, 사람이 읽을 수 있는 형식
- JSON 형식 (key/value 쌍으로 이루어짐) - 메타데이터 사용에 대한 충분한 고민
- 메타데이터 : 서비스를 구성하는 정보에 대해 식별자와 그 상세정보가 매핑된 데이터
- 로그에서 메타데이터를 사용하면 로그에는 퀘스트 상세정보를 남기지 않고, 아이디(식별자)만 기록하여 로그를 사용할 때 메타데이터를 참고하여 나머지 정보를 얻는 방식
a. 메타데이터가 많으면 관리가 힘들어지고 집계할 때마다 메타데이터를 참조하는 번거로움 때문에
목표를 위한 기본적인 데이터는 로그 항목에 직접 포함하는 게 좋음
b. 정적 데이터가 과도하게 많고, 정의했던 로그 목표에 필요하지 않은 경우 → 메타데이터
c. 유저나 다른 환경에 의해 변경되지 않고 서비스 제공자만 변경할 수 있어야 함
d. 서비스 성장에 따라 메타데이터가 불가피하게 많아질 경우, 메타데이터를 관리할 수 있는 도구가 필요함
- 문맥 식별자(Context identifier)
- 하나의 행동으로 일어난 여러 개의 로그는 같은 문맥 식별자를 갖게 한다
ex) 유저가 경험치 획득한 로그를 보고 어떤 경로로 획득했는지 궁금하다면
해당 로그와 같은 문맥 식별자를 가진 다른 로그를 찾아볼 수 있음
- 인과관계나 선후관계를 파악하는 데 도움을 준다
ex) 만약 퀘스트 완료와 같은 문맥 식별자를 가졌다면
퀘스트를 완료함으로써 경험치를 얻었음을 확인할 수 있음 - 고유 식별자(Unique identifier)
- 하나의 로그에 대한 고유한 식별자로, 중복 로그를 쉽게 식별할 수 있음
- 특정한 로그 하나를 기준으로 집계하기 편리함
위와 같은 것을 고려해 로그를 정의하면 좋지만, 로그로 인해 서비스에 미치는 영향을 고려해야 한다.
ex1. 로그에 필요한 값을 채우는 것이 서버 과부화를 일으킴 → 서버에서 캐싱하거나 or 메타데이터 활용
ex2. n초마다 모든 유저에 발생하는 로그가 필요한 경우 → 샘플링하거나 값이 변경될 때만 남기는 방향
그리고 지난 데이터가 아닌 현재부터 쌓을 데이터에 집중한다.
이미 없거나, 잘못 남겨진 데이터는 깔끔하게 포기하고 현재 상황에서 최선의 방향을 찾고 앞으로의 개선 방향을 논의한다.
4. 로그 품질 관리
- 품질 관리가 필요한 이유
- 이벤트와 항목들은 서비스가 성장할수록 점점 많아진다
- 계속해서 변경과 특이사항들이 발생할 것이다
- 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다 - 서비스 구성요소별 로그 관리
- 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음
- 로그에 존재하는 항목의 일관성을 유지하는 데 도움 - 로그의 문서화
a. 로그의 목표와 의미
b. 로그의 정확한 발생 시점
c. 각 항목들의 의미와 데이터 타입
d. 항목의 추가/변경/삭제 이력
e. 유실과 같은 특이사항 기록(발생 일시, 내용)
f. 로그가 사용되는 곳
- 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음
(ex. 어떤 대시보드에서 어떤 용도로 사용되고 있음) - 로그 유실 실시간 모니터링
- 믿을 수 있는 로그
- 로그 유실에 대한 빠른 대응
- 특이사항 기록
a. 버그 또는 시스템 이슈로 인해 유실된 경우
b. 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 - 로그 추가 및 변경의 프로세스화
1. 목표 정의
: 추가 또는 변경의 목표를 구체적으로 정의하고, 어떤 데이터가 필요한지 정의
2. 관계자들의 의견을 종합하여 로그를 설계
: 관계자들과 우선순위, 한계, 대안, 설계 등 의견을 종합하여 로그 설계
3. 로그 추가 또는 변경 작업
4. 테스트 / QA
: 의도한 시점에 제대로 발생하는지, 의도한 형태로 남는지, 값이 정확한지
5. 배포
출처
'기획 > 데이터' 카테고리의 다른 글
| [데이터 로그 설계] 3. 데이터 로그 설계 (2) | 2024.10.04 |
|---|---|
| [데이터 로그 설계] 2. 데이터 로그 설계 기본 상식 (4) | 2024.09.30 |
댓글