Table Of Contents
‘사용자 중심’이 당연한 세상입니다. 그런데 우리는 사용자에 대해 잘 알고 있나요? 개밥 먹기, 고객 인터뷰, 사용성 테스트를 하고 계시다고요? 좋아요! 여기에 더해, 사용자를 낱낱이 알기 위해 가장 객관적이고 대표성이 높은 방법은 사용자 데이터를 기록하고, 관리하고, 분석하는 일입니다. 이벤트 로그, 쌓는다고 끝이 아니에요. 이후의 기능 수정과 확장, 서비스 성장을 고려해 데이터를 어떻게 체계적으로 남기고, 관리할 수 있는지, 산처럼 쌓인 데이터를 어떻게 잘 활용할 수 있는지, 사용자 행동 로그의 파종부터 수확까지 쉽게 설명 드릴게요. 아래 글은 작성자의 원 블로그에서도 확인할 수 있답니다.
꽤나 방대한 내용을 다루기 때문에, 두 편으로 나누어 발행합니다. 첫 번째, <잘 쌓기> 편에서는 행동 로그의 정의, 행동 로그를 잘 쌓기 위한 설계 규칙과 Governance에 대해 이야기할 거에요. 두 번째, <잘 쓰기> 편에서는 데이터 분석 Tool을 잘 활용하고 팀에 전파 하기 위한 방법과 더불어, 데이터 기반의 의사결정 체계를 제품 개발 과정에 접목하는 과정을 다룰 예정입니다.
행동 로그가 뭐에요?
모든 웹 또는 모바일 기반의 서비스는 Tracker를 촘촘히 남김으로써, 사용자의 족적을 확인할 수 있습니다. 사용자가 서비스를 이용할 때 기록할 수 있는 데이터는 큰 틀에서 (1) 서비스 로그와 (2) 행동 로그로 구분할 수 있어요.
(1) 서비스 로그는 Transaction 결과에 대한 정보로, 가입, 등록, 결제와 같이 서비스가 정상적으로 돌아가기 위해 필요한 이력이 시스템에 기록됩니다. 서비스를 운영에 필요한 데이터이기 때문에 대부분 기록 및 관리에 큰 문제가 없습니다.
(2) 행동 로그는 User Action에 대한 기록으로, 사용자가 어떤 페이지 및 정보를 보거나, 특정 버튼을 누르거나, 스크롤을 넘기는 등의 행동을 할 때 관련 정보를 저장합니다. 이러한 정보는 서비스 로그에 비해 데이터를 어떻게 설계하고, 얼마나 기록해야 할지에 대한 자유도가 높기 때문에, 신경써서 관리하지 않으면 쓸모 없는 정보가 잔뜩 쌓이기도, 꼭 필요한 정보가 누락되기도 하지요.
이번 글에서 주요하게 다룰 행동 로그는 이벤트와 이벤트 속성(Event Property), 그리고 사용자 속성(User Property)으로 구분됩니다.
먼저, 이벤트와 이벤트 속성이 무엇인지 볼게요. 아래 이미지는 대표적인 사용자 분석 툴 중 하나인 Amplitude에서 제공하는 데모 데이터의 일부입니다.
이렇게 정의한 이벤트를 잘 쌓으면 다음과 같은 정보를 집계해 볼 수 있어요 :
- 지난 일주일 간 노래 또는 비디오가 재생된 횟수
- 지난 일주일 간 힙합 장르 노래를 재생한 사용자 수 (Genre_Type, Content_Type 이벤트 속성 활용)
- 2022년 5월 한달 간, 사용자 평균 비디오 재생 횟수 (Content_Type 속성 활용)
- 사용자 비디오 재생 주기 분포 (Content_Type 속성 활용)
반면, 사용자 속성은 이름 대로 사용자에 대한 정보를 담고 있는 데이터 입니다. 개별 사용자를 구분할 수 있는 식별값(ID)을 포함해서, 서비스 내 사용자의 이름, 가입 경로, 접속 기기, 플랫폼 등 여러 축으로 사용자를 쪼개어 볼 수 있는 정보를 포함합니다. 서비스 특성에 따라, 구독 여부를 저장하거나, 마지막 결제일 등의 사용자와 관련된 다양한 정보를 정의하고, 기록할 수 있어요.
자, 이제 이벤트 속성과 사용자 속성을 조합해볼까요? 더욱 깊이 있는 Insight를 확인할 수 있습니다. ’Subscription’이라는 사용자 속성과 ‘Play Song or Video’ 이벤트를 조합하면, 구독 여부에 따라 노래나 비디오 재생 횟수가 얼마나 달라지는지 비교할 수 있어요. 또, 가입 경로(from 사용자 속성)에 따른 컨텐츠 재생 횟수(from 이벤트)를 집계해서, 신규 사용자를 모객할 때 어떤 채널에 집중해야 할 지를 알 수도 있겠죠.
Event Convention 정의하고, Logging 요청하기
앞서 행동 로그가 무엇이고, 어떤 요소를 포함하는지 설명 드렸습니다. 이제부터 우리 서비스의 어떤 지점에 행동 로그를 남길지 정의하고, 이 작업을 실제로 수행할 엔지니어와 어떻게 잘 의사소통할 수 있을지 말씀 드릴게요.
조직 구조와 규모에 따라 다를 수 있지만, 대부분의 경우 이벤트를 정의하고 관리하는 과정은 여러 사람(직군)을 거쳐서 이루어 지게 됩니다. 이에 따라, 효과적으로 의사소통하고, 효율적으로 작업하기 위해서는 개별 이벤트와 속성 값을 정의 하기 전에, 전체 Event 관리의 원칙과 공통 규칙을 정의할 것을 추천합니다.
과거 제가 담당했던 서비스에서는 크게 (1) 원칙, (2) 공통 속성, (3) Naming 규칙을 기록하고 공유 했어요.
(1) 원칙은 이벤트를 정의할 때 기본적으로 고려 해야 하는 목적과 방향성을 담았습니다. 구체적인 Wording까지 공개하기는 어렵지만 대략 아래와 같은 내용을 담아 구성했어요 :
- 내부 구성원이 이벤트의 의미를 직관적으로 파악할 수 있도록 이벤트 명을 구성한다.
- 이벤트 개수의 무분별한 증가를 방지하고, 데이터 활용이 용이하도록, 이벤트는 적정 수준으로 추상화한다.
(2) 공통 속성은 어떤 이벤트를 정의하더라도 공통으로 포함키로 약속한 속성 값입니다. 플랫폼, 앱 버전, 사용자 ID 등이 이에 해당하는데, 개별 이벤트의 특성에 관계 없이 서비스 전반에 대한 분석을 진행할 때, 데이터 간의 연결이 끊어지지 않도록 하기 위해 필요합니다.
(3) Naming 규칙은 이벤트 이름을 어떻게 정할지에 대한 대략적인 가이드 입니다. 이벤트의 유형(페이지 조회, 클릭, 입력 등)에 따라 어떤 접두사(prefix) 혹은 접미사(suffix)를 붙일지, 이름에 포함되는 단어는 어떤 정보를 참조할지 등을 미리 정의해두면, 이후에 데이터를 활용하는 구성원이 손쉽게 데이터의 의미를 이해할 수 있습니다. 또, 계속해서 쌓이는 신규 Event를 관리하기에도 편리하죠.
이렇게 기본적인 Event Convention을 정의했다면, 개별 Event를 추가할 때는 이벤트 정의서를 작성하도록 해요. 행동 로그는 서비스 로그에 비해 수정이나 추가가 매우 잦은 주기로 발생합니다. 제품의 기능 수정 및 확장뿐 아니라, UI가 변경되거나, 심지어 서비스 변경이 없어도 추가적인 데이터를 확인해야 하는 경우, 모두 신규로 Event를 정의하거나 기존 Event를 수정하는 작업이 필요합니다. 이벤트 정의서를 작성하는 목적은 첫 째 코드 작업을 담당할 엔지니어와 명확하게 소통하기 위해서, 둘 째 Event 추가/수정 이력을 잘 남기기 위함이에요. 그렇기 때문에, 이벤트 정의서는 최대한 구체적으로 작성하는 것이 좋습니다.
상품 홍보를 위한 신규 랜딩 페이지를 기획하고 배포한다고 가정해볼게요. “신규 랜딩 페이지를 몇 명이 봤는지 알 수 있게 해주세요”라고 요청하면, 필요한 정보를 모두 얻을 수 있을까요? 엔지니어는 페이지로 들어가는 링크를 누르는 시점에 이벤트를 기록할 수도, 페이지가 최초에 로딩된 시점에 이벤트를 기록할 수도, 또 페이지 스크롤을 최하단까지 내린 시점에 기록할 수도 있습니다. 또, 어떤 경로로 페이지에 진입했는지, 여러 개의 랜딩 페이지 중 어떤 페이지를 조회했는지 등의 정보를 알 수 없게 될지도 몰라요.
저는 이벤트 정의서를 작성할 때 통상적으로 이벤트 발생 화면, 이벤트 이름, 이벤트 기록 시점, 이벤트 속성 (이름과 Data Type), 상황별 이벤트 속성 값을 나누어 정의합니다. 아래 예시 이미지 처럼요.
어렵지만 꼭 생각해 보아야 하는 Data Governance
Google Colud의 정의에 따르면, Data Governance는 수집에서 사용, 폐기에 이르는 데이터 수명 주기 동안 데이터 관리에 사용되는 원칙적인 접근법입니다. 조금 어려우니 설명을 풀어보면, Data Governance란 데이터를 만들고, 사용하고, 삭제하는 과정에서 발생할 수 있는 일과 그 일을 잘 하기 위한 의사결정의 방법을 모두 포괄하는 개념이에요. Governance에는 전략, 조직, 절차(프로세스), 시스템, 리소스 등의 구성요소가 모두 포합됩니다. 정말 넓은 개념이죠. 사용자 행동 로그로 주제를 좁혀 Governance를 보더라도, 회사의 제품 조직과 데이터 조직 구성, Data-Driven 문화적 성숙도, 사용하고 있는 데이터 시스템, 리소스 현황에 따라 수십 수백 가지의 갈래가 있을 거에요. 이 글에서는 조금 더 실용적인 관점에서 사용자 행동 로그를 잘 쌓고 관리하기 위해서 주요하게 고민 해보아야 할 질문 3개를 남겨보겠습니다.
(1) 사용자 행동 로그를 설계하고 요청하는 주체는 누구일까요?
정해진 답은 없습니다. 여기서 중요한 점은 행동 로그를 심을 때, 그 데이터가 왜 필요하고, 어떻게 활용할지 목적이 먼저 정해져야 한다는 것입니다. 글 서두에도 말 했던 것처럼, 행동 로그는 설계의 자유도가 굉장히 높기 때문에 단지 불안하다거나 잘 모르겠다는 이유로 생각나는 모든 이벤트를 심게 되면, 관리 복잡성이 기하급수적으로 늘어납니다. 그러니 누구든 행동 로그를 설계하는 사람은 데이터가 일정 수준 정도 쌓이고 난 뒤 어떤 관점에 서 분석할지 명확하게 정의할 수 있는 사람이어야 하고요. 필요하다면 PM, 분석가, 엔지니어 등 여러 주체가 함께 모여서 논의해도 좋습니다.
(2) 어떤 주기로 로그 신규 추가 및 수정 작업을 적용할까요?
일주일, 격주, 한달 등 제품 배포 주기가 명확하게 정해져 있는 경우는 해당 주기에 맞추어 행동 로그도 추가/수정 하면 됩니다. 배포일을 기준으로, 로그 설계, 로그 작업, QA, 수정사항 적용에 필요한 시간을 역순으로 계산해서 미리 계획을 잡아두고 따라 가세요! 배포 주기가 정해져 있지 않더라도, 로그 추가/수정은 너무 잦은 주기로 하기보다 최소 일주일 이상 간격을 두고 정기적으로 진행하는 게 좋아요. 먼저, 로깅 작업을 진행하는 엔지니어의 생산성에 영향을 주기도 하고요. 또, 데이터 관리자 관점에서도 특정 주기별로 신규/수정 사항이 쌓이는 것이 관리에 용이합니다. 마지막으로, 로그 수정이 기존에 데이터를 사용하고 있던 내부 구성원들에게 의도치 않게 영향을 줄 수 있어요. 그러니 데이터를 수정한 뒤에는 직접적인 영향 범위가 아니더라도, 데이터를 사용자에게 관련 내용을 공유하기를 추천합니다.
(3) 어떤 우선순위로 로그를 관리할까요?
새로운 이벤트를 심을 때, 작업 리소스가 부족한가요? 또는 기존에 만들어진 이벤트들이 명확한 활용처 없이 방치되고 있지는 않나요? 무분별한 로그 쌓기를 멈추고, 우선순위를 판단해볼 시기 입니다. 저는 주로 아래 6가지 기준에 입각해서 중요도를 평가하고, 중요도에 따라 작업 시기나 해당 이벤트 수집의 존속 여부를 판단했어요 :
- 분석을 통해 사업 지표의 변화를 꾀할 수 있는 Action Item이 도출되는가
- 시의성 있는 성과 측정이 필요한 안건인가 (e.g. 프로모션)
- 주요 Funnel에 직접적으로 해당하는 이벤트인가
- 이전까지 없던 신규 Feature인가
- 장기적인 활용 계획을 가지고 있는가
- 대체 가능한 추적 방안이 없는가 이렇게 평가 기준을 만들어 사용하면, 우선순위를 객관적으로 판단하기에도 좋지만, 로그 작업과 관련된 이해관계자를 훨씬 편하게 설득할 수 있답니다!
지금까지 사용자 행동 로그를 잘 쌓을 수 있는 방법을 다루었습니다. 많은 내용이 있었지만, 가장 중요한 두 가지를 꼭 기억 해주세요!
- 새롭게 설계했거나 기존에 수집하고 있는 행동 로그가 우리 사용자를 이해하기 위해 어떻게 활용될 수 있는지 생각해보기
- 반복적이이고 챙길 거리 많은 작업을 어떻게 하면 실수 없이 잘 할 수 있을지 관련된 구성원과의 논의를 통해 필요한 규칙을 명문화하고 공유하기
다음 편에서는 이렇게 쌓은 데이터를 어떻게 잘 활용할 수 있을지를 다룰 예정입니다. 이벤트 잘 쓰는 법이 궁금하시다면, 댓글과 좋아요(박수)를 눌러주세요! 험난한 글쓰기 과정에 큰 응원이 됩니다 ❤️
Reference
모바일 앱 로그분석, 어떻게 시작해야 할까? (201AD, September 2). [web log]. Retrieved from https://brunch.co.kr/@leoyang99/15.