데이터로그 설계, 이것만 지켜도 80%는 성공합니다
데이터로그 설계 특강 (2)
안녕하세요. 유저와 제품을 데이터로 말하는 8 년차 T-shaped Product Manager 나단입니다. 앞으로 런어스하이 브런치를 통해 데이터로그 설계 / 데이터 기반 제품 개선 등의 이야기를 나눌 예정입니다.
(지난 글이 궁금하시다면 아래 링크를 통해 확인하세요!)
https://brunch.co.kr/@learnushigh/50
나단, 안녕하세요. 저번에 말씀드린 고객 행동 데이터 수집 관련 업무는 어떻게 진행되고 있을까요? 어떤식으로 수집 및 관리를 하면 좋을지에 대해서 정리해서 금주 중에 Review 한번 부탁드릴게요!
PM으로 이직한 지 2주일 차, 아무것도 모르는 상태에서 업무를 요청 받은 이후 이것 저것 찾다보니, 고객 데이터 로그는 Taxonomy, Tracking Plan라는 이름으로 불리고 이를 체계적으로 관리하는 템플릿 등이 존재한다는 것을 알게 되었습니다. 다만, 시트를 처음 열람했을 때 느끼는 이 암담하고 답답한 심경을 어찌해야 좋을까요? 채워야할 항목이 수백줄은 되는 것 같고, 이벤트 탭 안에도 프로퍼티(Property)가 있는데 별도의 프로퍼티탭이 존재하고.. 이 방대한 업무 제가 끝낼 수 있을까요?
행동 데이터 중요한 것 알겠는데, 어떤 로그부터 수집해야 할까요?
실제 고객 행동 데이터를 정리 및 수집해야 하는 업무를 맡게 된다면 위와 같은 사례는 흔하게 경험할 수 있습니다. 막상 정리를 하려고 하면 고객이 우리 앱이나 웹에서 행동하는 Flow는 너무나 케이스들이 다양하고, 이를 구체적으로 정리하려고 마음 먹으면 막막한 마음이 드는건 너무나 자연스러운 현상입니다.
고객의 모든 로그 데이터는 중요합니다. 하지만 꼭 필요하고 측정해야 하는 데이터를 먼저 수집하는 것이 중요합니다. 그렇다면 여기서 말하는 꼭 필요한 데이터란 무엇일까요?
잠깐, 우리 회사 혹은 서비스의 비즈니스 목표를 다시 한번 생각해 봅시다
앞서 글에서 "데이터로그 설계가 왜 필요한지"에 대해서 설명했었습니다. 모든 회사에는 비즈니스 마일스톤이 있고 - 이를 잘 달성하는지 확인하는 용도로서 로그 데이터 수집이 필요하다고 말씀 드렸습니다.
여기에 2가지 사례를 통해, 위에서 이야기 한 "어떤 로그 데이터를 먼저 수집하고 측정해야 하는지" 살펴보겠습니다.
첫번째 사례
A라는 회사의 비즈니스 목표가 [구매 유저의 증대] 라고 가정했을 때, 어떤 로그 설계가 중요할까요?
✔ 유저의 [구매] 라는 행동의 로그기록이 가장 중요하고 필요한 목표 데이터일 겁니다.
두번째 사례
B라는 회사의 비즈니스 목표가 [카카오 회원 가입수 증대] 라고 가정했을 때, 어떤 로그 설계가 가장 중요할까요?
✔ 유저의 [회원 가입] 이라는 행동의 로그기록이 가장 중요하고 필요한 목표데이터일 겁니다.
결국 로그설계는 "비즈니스적으로 우선순위가 높은 목표데이터를 측정하는 것"이 가장 중요하고, 유저가 이 목표를 잘 달성하는지에 대해 체크하는 작업이라고 할 수 있습니다.
마일스톤 기반의 Taxonomy Framework 잡아보기
먼저 들어가기에 앞서 Taxonomy 라는 단어는 Amplitude라는 데이터로그 분석 툴에서 사용하는 관리체계의 명명 방법입니다. 해당 용어는 Tracking plan 등으로도 사용되며, 결국 두 용어 모두 유저의 로그 데이터를 잘 관리하기 위한 관리체계의 한 종류라고 생각하시면 됩니다.
로그설계의 첫번째 과정은 "마일스톤 기반으로 사고하기" 입니다. 서비스 마일스톤을 측정하고자 하는 최종목표 데이터로 두고, 해당 목표를 달성하는 여러가지 경로에 대해서 하나씩 정리를 해본다면 로그 설계의 절반은 달성한 셈 입니다.
위에서 사례로 든 A라는 회사의 비즈니스 마일스톤인 [구매] 라는 행동을 측정하기 위해서, 먼저 유저가 구매를 하는 과정에서 거치는 다양한 경로에 대해 3단계로 구분지어 나열해보도록 하겠습니다.
위에 언급된 행동들은 유저가 [구매 완료]를 수행하기 위해서 반드시 거쳐야 할 퍼널(Funnel)들입니다.
만약 유저가 구매를 하지 않았다면 구매를 하는 행동에 제약이 있거나, 중간로그 혹은 시작로그에 문제가 있을 수 있습니다. 따라서 위에 언급된 여러 행동들은 [구매] 라는 최종목표를 추적하기 위해 반드시 체크해야 할 사전지표이고 꼭 수집해야 하는 데이터들입니다.
우리가 꼭 측정해야할 중요 목표 데이터를 먼저 생각해보고, 이를 거쳐가는 경로들을 하나씩 기입하는 방식으로 로그설계를 진행하면 회사의 목표와 고객의 행동흐름을 쉽게 파악할 수 있습니다.
Taxonomy는 어떻게 작성하나요?
Taxonomy를 작성하는 데 있어서 가장 중요한 것은 아래의 3가지 입니다.
① 일관성 - 이벤트 이름 등을 정리할 때, 관리의 용이성과 더불어 누구나 쉽게 작성할 수 있도록 일관성을 가지고 작성하는 것이 좋습니다.
② 명확성 - 이벤트 이름만 보고도 어떤 이벤트인지 직관적으로 한번에 파악할 수 있어야 합니다.
③ 구체성 - 가능한 자세히, 상세하게 해당 이벤트와 속성값 및 작동조건 등에 대해서 설명해 놓는 것이 좋습니다.
위의 3가지를 기준으로 전사 구성원이 열람할 수 있는 하나의 탬플릿 (스프레드시트, 노션, 액셀 등)을 정해서 체계적으로 관리하는 것이 좋습니다.
어떤 규칙으로 이벤트 이름을 작성할까요?
Taxonomy작성의 8할은 창의성과 노가다입니다. 목표데이터를 측정하기 위한 모든 경우의 수를 고려하여 작성하는 만큼 나름의 시간과 품이 많이 들지만, 아무 기준없이 작성하게 된다면 조직의 레거시로 남을수 밖에 없습니다. 아래의 기준들을 고려하여 일관성, 명확성, 구체성이 반영되도록 이벤트 이름을 작성하는 것이 필요합니다.
첫째. 이벤트 이름 내에서는 Action 의 행동을 명확하게 표현해주세요.
서비스 내에서 크게 유저가 하는 행동은 Click, View, Swipe, Complete, Search 등으로 구분이 됩니다. 이벤트 이름 가장 앞단에는 해당 행동을 명시하여 유저가 어떤 액션을 취했는지 한번에 파악할 수 있도록 하는 것이 중요합니다.
둘째, 이벤트 이름의 일관성을 위해 행동이후 나름의 규칙을 만들어서 적용해주세요.
유저가 해당 액션을 했다고 하면 어디서 그 액션을 했는지에 대해서 확인이 필요합니다. 보통 이벤트 이름 다음에는 어떤 페이지 혹은 화면에서 해당 액션을 수행했는지 기록을 하는 것이 필요합니다. 더불어 유저는 그 화면에서 어떤 요소(대상)에 대해 그 행동을 수행했을 겁니다.
좀더 쉽게 설명하기 위해서 예를들어 어떤 회사의 핵심 비즈니스 목표가 "유저가 홈 화면에서 광고 배너를 클릭한다"라고 가정하고, 해당 로그를 어떻게 기록할지 세가지 규칙을 토대로 작성해봅니다.
위의 기준으로 살펴보면,
① 유저는 클릭(click)이라는 행동을 수행했습니다.
② 유저는 해당 행동을 홈 화면내에서 수행했습니다.
③ 유저는 홈화면에서 광고배너라는 대상을 클릭했습니다.
3가지를 고려하여 이벤트 이름은 다음과 같이 작성할 수 있습니다.
→ click_home_adbanner
정리해본다면, 해당 이벤트 이름은
⏺ [액션] + [화면] + [대상]의 조합으로 구성했으며
⏺ 각 영역의 경우 _ (언더바) 를 통해 구분했습니다
⏺ 이벤트 이름은 모두 소문자로 구성했습니다
⏺ 해당 이벤트는 [동사] + [명사] 의 구조로 작성이 되었습니다
위처럼 이벤트 명명은 조직 내부에서 합의된 일관성 있는 조건으로 작성을 하는 것이 무엇보다 중요합니다. 작은 조직의 경우 해당 업무를 개인 및 소수의 인원이 담당하여 큰 문제가 되지 않겠지만, 조직 규모가 점차적으로 커질 경우 초기에 이런 가이드를 명확히 설정해두지 않는다면 데이터를 관리하는 측면에서도 리소스 낭비가 발생할 수 있습니다.
셋째, 행동의 발생 조건을 구체적으로 명시해주세요
이벤트 이름을 작성했다면, 해당 이벤트가 어떤 조건에서 발생했는지에 대한 구체적인 부연설명이 필요합니다. 이 작업은 어떤 이벤트인지 파악하는 점에서도 중요하지만, 이벤트로그를 실제로 반영하는 개발자분들과 커뮤니케이션 할 때도 꼭 확인이 필요한 사항입니다.
위 예시에서 [click_home_adbanner] 라는 이벤트에 대한 발생 조건을 설명한다고 하면, "유저가 홈 화면에서 광고 배너를 클릭했을 때 해당 이벤트를 수집한다"고 정리할 수 있습니다. 해당 이벤트 설명에서 중요한 부분은 '시점' 이며 배너를 클릭했을 때 해당 로그가 실행된다고 명확하게 명시를 하는 것이 필요합니다.
위 내용들을 정리하여 표로 만든다면 아래와 같이 작성할 수 있습니다.
위와 같은 형태로, 유저가 서비스 내에서 수행한 여러 로그들에 대해 하나의 시트로 취합하여 정리를 해두는 것이 Taxonomy 탬플릿 정리의 시작입니다.
어떤 규칙으로 속성 데이터를 작성할까요?
이벤트 네이밍과 마찬가지로 속성 데이터 작성 또한 위에서 언급한 동일한 기준을 반영하여 진행합니다.
속성 데이터의 경우 이벤트 속성 (Event Property 혹은 Event Parameter) 과 유저 속성 두 가지로 나뉘고 두 가지의 속성 데이터는 구분해서 작성을 진행합니다.
간략하게 이벤트 속성과 유저 속성에 대해 먼저 정리하자면,
이벤트 속성은 이벤트가 발생했을 때에 함께 수집하면 좋은 세부 정보 데이터를 말합니다. 위에서 이야기 한 [click_home_adbanner] 이벤트가 발생했을 때 어떤 정보값을 함께 수집하면 좋을까요?
아래와 같은 정보값을 함께 확인한다면 유저의 행동 분석에 용이할 것 같습니다.
⏺ 광고 배너의 타이틀 - 어떤 광고배너를 유저가 클릭했는지?
⏺ 광고 배너의 아이디 - 해당 광고 배너의 ID값은 무엇인지?
⏺ 광고 배너의 타입 - 해당 광고 배너의 타입 (e.g. 롤링형태, 팝업형태 등) 은 무엇인지?
수집이 필요한 속성 정보값을 정리한 이후에, 이벤트 옆 컬럼에 수집이 필요한 속성값도 함께 기입을 해둡니다. 표를 좀더 다듬는다면 아래와 같이 정리해볼 수 있습니다.
유저 속성은 유저가 특정 이벤트를 할 당시 유저가 가진 상태 데이터 값을 말합니다. 해당 속성값은 보통 두 가지 값으로 구분이 됩니다.
⏺ 이벤트 수행과 상관없이 크게 변동이 없는 속성 데이터
e.g. 도시정보, 국가정보, 디바이스 정보, 회원가입일 등
⏺ 이벤트 수행에 영향을 받고 실시간으로 변동이 필요한 속성 데이터
e.g. 제품 누적 구매횟수, 회원 멤버십 등급 등
도시 정보, 디바이스 정보 등의 변동성이 적은 데이터는 로그 분석툴에서 기본적으로 제공하는 속성 데이터입니다. 다만 유저의 회원 가입일, 멤버십 정보 등은 별도로 수집이 필요하기 때문에 이벤트를 정리한 시트와 동일한 형태로 별도 작성을 진행합니다. 아래와 같은 형태로 정리해볼 수 있습니다.
이벤트 영역과 마찬가지로 위의 표에서도 속성 이름의 규칙성을 적용했습니다.
⏺ 단어 기준으로 _(언더바) 를 통해 구분합니다
⏺ 모든 유저 속성 이름은 소문자로 작성합니다
⏺ 속성값의 경우에도 소문자로 작성되었습니다
위 내용을 정리하면,
⏺ Taxonomy를 정리하기에 앞서 회사의 비즈니스 목표를 먼저 파악하고, 중요 데이터 로그의 우선순위를 높여서 설계를 진행해야 합니다.
⏺ Taxonomy 작성은 초기 가이드 설계가 제일 중요하고 일관성, 명확성, 구체성을 가지고 조직 내부에서 합의된 가이드를 바탕으로 작성되어야 합니다.
⏺ Taxonomy 관리는 하나의 시트에서 작성 및 관리하며 꾸준히 업데이트를 진행합니다.
NEXT
로그 설계 과정에서 발생하는 여러가지 궁금한 점들에 대해 문답형태의 글로 찾아오겠습니다. 아래와 같은 질문들을 주제로 이야기 드리도록 하겠습니다.
⏺ 로그 데이터를 볼 수 있는 여러가지 툴 들이 있던데, 우리 조직에는 어떤 툴을 사용해야 할까요?
⏺ 로그설계 과정은 알겠는데 - 이 과정에서 개발지식은 얼마나 필요할까요?
⏺ 택소노미 시트를 작성했는데 관리가 잘 되지 않는 것 같아요. 어떤 식으로 관리하면 좋을까요?
