dmswl
[로그/앱 데이터 분석] 1. 로그 데이터로 유저 이해하기 본문
해당 글은 공부 목적으로 우아한형제들 기술블로그 '로그 데이터로 유저 이해하기' 포스트를 요약 및 정리한 글입니다.
0. 로그를 설계/정의하고 데이터를 분석하는 것이란?
유저가 남긴 로그로부터 유저의 경험을 추정하고 니즈를 파악해 서비스 개선에 필요한 인사이트를 제공하는 것.
이를 위해 로그 설계/수집/분석에 이르는 전반적인 과정에 직/간접 관여
1. 분석의 시작은 서비스를 이해하는 것부터
1) 클라이언트 로그 설계 및 정의
앱의 모든 화면과 이벤트(클릭, 배너 노출)를 상세히 파악하고, 시나리오와 서비스의 흐름을 이해하는 것.
마치 실제 유저가 앱을 쓰듯이 모든 기능과 화면을 하나씩 파악하면서 로깅 항목을 정리.
-> 앱에 대한 이해가 한 단계 깊어지는 경험, 편리한 기능과 불편한 기능을 파악하여 향후 분석을 위한 방향과 프레임을 잡는 데 유용한 정보를 얻을 수 있음.
2) 로그 수집
엔지니어 및 개발자와 협업하면서 로그 수집 진행.
데이터는 JSON 형태로 저장소에 차곡히 쌓이고, 언제든 저장소에 접근해 데이터를 추출/분석할 수 있는 환경을 엔지니어가 마련해 줌.
유저가 서비스에 접속해 특정 화면을 보거나 액션을 할 때마다, 설계된 스키마대로 데이터가 쌓이고 샘플을 추출하여 데이터 탐색을 마무리 함.
3) 품질 확보와 분석 프레임 설정
로그 수집 프로세스가 처음 진행된 경우, 본격적인 데이터 분석을 진행하기 앞서 데이터 품질을 확보하는 것이 중요하다고 판단. 기존에 정의한 대로 각 필드 및 파라미터에 적절한 로그가 쌓이고 있는지, 누락되거나 이상한 데이터는 없는지 확인하고 만약 수정/보완이 필요한 경우 데이터 품질을 확보하는 작업을 진행.
아래 예시와 같이 수집이 잘못된 경우 유관자와 원인을 파악하고 문제 해결 과정을 통해 데이터 품질 확보에 많은 노력과 시간을 투입함.
또 다른 중요한 과정은 데이터 분석 프레임을 설정하는 것. 일반적으로 로그 데이터의 경우 단기간에 몇 십만, 몇 백만 건의 데이터가 순식간에 쌓이고 로그 정의 항목은 수백 건에 달함. 무작정 데이터 탐색 분석으로 뛰어들 경우 망망대해에서 길을 잃고 허우적 거리는 사태 발생할 수 있음. 따라서 목적을 명확히 설정하고 적절한 질문을 사전에 작성하는 것이 효과적이라고 판단, 로그 설계 시 경험을 바탕으로 대략적인 프레임을 구축하여 데이터 분석 및 인사이트 도출 과정에서 유용한 나침반으로 활용. 분석 프레임 설정 예시는 아래와 같음.
- 목적
- 앱내 시나리오 및 기능을 개선할 수 있는 방안을 찾자(궁극적으로 사용성 및 UX 개선)
- 질문
- 구간별 Conversion Rate는? 어떠한 기준으로 계산할 것인가? 세션 기준? DAU 기준?
- Funnel 별 이탈율은 얼마나 될까? 주요 bottleneck 구간은 어디일까?
- 재구매율 혹은 재방문율은 어떠한가?
- 지표 계산 방식은? 평균 재구매 시간? 시간이 오래 걸릴수록 패널티 주는 방식은?
- 초기 주요 인사이트 및 시사점은?
- 분석의 한계점 및 논의/개선 필요사항은?
- 목적
- 전체 유저를 세분화하여 행동 패턴의 차이를 확인하자 >> 핵심 그룹 타깃팅
- 질문
- 지역별에 따른 유저 행동 패턴의 차이는?
- 주간 방문수 기준으로 구분하면?
- 주문 경험 유 vs 무 여부로 구분
- 신규 유저 vs 기존 가입 유저의 행동 패턴의 차이는?
- 타 플랫폼 이용 경험 유 vs 무 (디바이스 크로스)가 결제에 미치는 영향은?
- 주문한 카테고리 (예, 시킨 것만 시키는 그룹, 바꾸는 그룹)별로 구분하면?
- 결제시 주문 방식별 세분화? 주문 방식별로 특이한 패턴은?
- 클릭한 배너에 따른 결제율 차이는?
3. 디테일에 목숨걸지 말자!
로그 데이터를 추출해보면 난해한 결과가 나오는 경우가 있음. 경험상 주로 다음과 같은 이유로 발생하는 것 같다고 함.
- 로그 설계 과정에서 항목 누락 혹은 잘못된 필드/값 정의
- 로그 데이터 관리 부족(ex. 업데이트 된 서비스의 시나리오 및 기능을 기존 로그 설계에 반영 못했을 경우)
- 데이터 품질 확보를 위한 노력 부족
- 수집 과정에서 중복 데이터 발생(아래 표 예시 참고)
| Date | UserNo | Screen | Action |
| 2017.05.01 10:10:00 | 1004 | /MyPage | View |
| 2017.05.01 10:10:01 | 1004 | /MyPage | View |
| 2017.05.01 10:10:02 | 1004 | /MyPage | View |
| 2017.05.01 10:10:03 | 1004 | /MyPage | View |
| 2017.05.01 10:10:04 | 1004 | /MyPage | View |
1,2,3 : 인적 요인으로 인해 발생 -> 실무자와 협의를 통해 해결 가능한 부분
4 : 기계적으로 수집되는 과정에서 자연스럽게 발생할 수 있는 부분 -> 이 역시 협업을 통해 해결할 수 있으나
분석 과정에서 자체적으로 해결하는 것이 효과적
즉, 위 테이블을 그대로 읽으면 'UserNo'가 1004인 유저가 MyPage 화면을 3초동안 5번 보았다' 라고 해석이 되는데, (유저는 기계가 아닌 인간이기에) 어떤 유저도 이런 식으로 앱을 사용하진 않을 것 같았다. 차라리 초(second) 단위의 정보를 무시하고(중복 수집으로 판단), '2017년 5월 1일 10시 10분에 1004 유저가 MyPage를 1번 보았다'라고 해석하는 것이 더 적절할 것이라고 판단하였음.
때로는 '이러한 방식이 세밀한 정보를 놓치는 것이 아닌가?' 혹은 '너무 자의적인 해석이 아닌가?' 라고 스스로 반문하기도 했으나(비록 정보 손실이 있더라도) 효율을 추구하는 동시에, 인간의 행동을 효과적으로 설명할 수 있는 해석이 타당해보였다.
=> 로그 데이터는 인간의 행동을 효과적으로 설명할 수 있어야 한다.
결과적으로 기존 5개의 행의 데이터를 중복으로 처리해 하나의 행으로 축약시켰으며, 유사한 데이터가 있을 경우 '무엇을 기준으로 중복 값을 제거하는 것이 적절한가?'에 대한 물음을 자문하며 분석을 진행함.
이 과정에서 초반에 설정한 목적과 의미, 그리고 논리성과 인간을 기반으로 한 접근 방식이 유용했다!!
4. 결과는 이해하기 쉽고 명확하게!
로그 데이터를 설계/수집하고 분석하는 일련의 과정은 이 업무의 절반(1/2)에 해당한다고 생각.
나머지는 분석 결과를 유관자에게 전달하고, 설득을 통해 실제적인 변화와 성과를 이끌도록 지원하는 것이라고 생각.
이를 위해서 분석 결과를 명확하고 간결하며, 이해하기 쉽게 전달하는 것은 매우 중요한 과정. ⭐
주니어 분석가 시절에는 시각화와 리포트 작성에 많은 노력을 투입했고, 단순하고 쉬운 방법론보다 고급 방법론이 항상 좋은 것이라고 착각했었는데,
아무리 고수준의 방법론이라도 결과를 공유받는 상대로부터 실제적인 변화를 이끌어내지 못한다면 큰 의미가 없다는 것을 깨닫고 아래 원칙을 토대로 커뮤니케이션을 하고 있다고 한다.
- 단순하고 이해하기 쉬운 그래프👍
- 보기에는 멋지지만 이해하는 데 시간이 오래 걸리고 만들기도 어려운 시각화👎
5. 로그 데이터를 잘 활용하는 방법
일반적으로 로그 데이터를 수집/처리/분석하기 위해 많은 담당자분들이 노력과 시간을 투입함.
이러한 인적자원뿐 아니라, 서버 및 분석도구 등 시스템적 비용 역시 발생하기 때문에 데이터 활용도를 높이는 것이 중요하다고 생각합니다.
일차적으로 생각해볼 수 있는 각 영역/부문별 데이터 활용 방안은 아래와 같음.
- 개발 영역
- 버그 혹은 크래시율 수집 및 상시 트래킹
- 이슈 발생 후 롤백 및 대응 등에 대한 의사결정 판단의 근거로 활용
- 특정 기능에 대한 사용성 진단
- 마케팅 영역
- 마케팅 채널별 ROI 진단 및 비용 최적화
- 배너/프로모션/이벤트 효과 측정
- 유저 Segmentation, Targeting
- 기획/디자인 영역
- 시나리오/기능/디자인에 대한 성과 측정 및 개선 (A/B 테스트)
- 유저 Journey 경로 분석 및 이탈 구간 개선 (UX/UI 최적화)
- 유저 Persona 구축 (with 리서치) 및 신규 기능 Ideation
- 기타 영역
- 영업 및 CS 관련 대응
- 사업 및 투자 성과 진단
6. 마치며
개인적으로 데이터가 비로소 그 가치를 발휘하는 순간은 분석 결과가 실제 비즈니스에 적용되어 가시적인 성과를 일으키는 것이라고 생각합니다. 다만 첫술에 배부를 수 없듯이, (작은 규모라도) 반복적인 프로세스로 운영하고 개선이 필요할 경우 기민하게 진행하는 것이 필요하다고 생각합니다. 이를 위해 부서간 기밀한 협업과 업무 프로세스에 대한 공감대 형성이 필요하며, 또 데이터에 대한 적극적이고 열린 태도로 업무를 진행하려는 노력이 필요할 것 같습니다.
'Data Analysis' 카테고리의 다른 글
| [데이터 시각화] 1. 데이터 시각화 툴 조사 - Tableau, Looker, Redash, Metabase, Amplitude (0) | 2023.01.17 |
|---|---|
| [데이터 시각화] 0. 데이터 시각화 툴, 대시보드, BI 개념 (0) | 2023.01.12 |
| A/B 테스트 (0) | 2023.01.12 |
| 마케팅/CRM 개념과 관련 지표 (0) | 2023.01.12 |
| 그로스 해킹(Growth Hacking) (0) | 2023.01.05 |
