Data Taxonomy 살펴보기 (2)
분석가와 마케터를 위한 종합 가이드
Data taxonomy에 대한 기본 내용에 대해 궁금하다면 해당 글<Data Taxonomy 살펴보기 (1)>을 먼저 읽고 오기를 권장합니다.
이번 글에서는 Amplitude에서 Data taxonomy를 구축할 때 고려되야 할 주요 항목과 고려해야 할 주요 포인트들에 대해서 살펴볼 예정입니다.
추가로 Taxonomy 구축은 1회로 끝나는 작업이 아니며, 구축 이후에도 지속적인 유지 관리가 필요한 항목입니다. 여시나 Amplitude를 통해서 구축된 Taxnomy의 관리(Data governance)에 대해서 살펴보고자 합니다.
데이터 텍소노미의 구성요소
Event & Property
데이터 텍소노미를 구축한다는 것은 Amplitude가 데이터를 이해하는 구조를 만드는 것을 의미하며 이는 Event & Event property & User property를 구성하는 것을 의미합니다.
단순한 커머스 비즈니스라고 하더라도 다양한 기능들이 존재하기 때문에 각 기능들을 분석 시 이해하고 선택할 수 있는 직과적인 이름을 정의하는 것은 분석의 편의성을 높이는 중요한 고려사항입니다.
1. Event
1) 이벤트 이름 지정(명명법)
Event의 이름을 지을 때는 명확하고 아래와 같은 일관된 명명법을 사용해야 합니다.
소문자 & 대문자 통일화
시제 표현 통일화
언더바(_), (대시(-), 닷(.) 등 컨벤션 통일화
사용자의 행동을 명확히 표현
e.g. login -> click login button, view login page, complete login
단순 login이라는 이벤트 명은 명확한 유저 행동의 상태를 정의하기 어렵기 때문에 해당 이벤트를 사용하는 사용자에 따라 다른 의미로 이벤트 수치를 받아들일 수 있습니다. 따라서 명확하기 login 버튼을 클릭 한 상태인 건지(click login button) 로그인 페이지에 도달한 상태인 건지(view login page) 등으로 명확한 행동과 상태를 정의해 줄 필요가 있습니다.
2) Event name / Display name 사용
Amplitude를 포한한 솔루션의 경우 개발 특성상 영문 Taxonomy 설계가 더 좋습니다. 다만 영문의 경우에도 Amplitude 사용자마다 다르게 받아들이거나 익숙하지 않을 수 있기 때문에 한글로 변경하는 작업을 할 수 있습니다. 이때 사용하는 기능이 Display name입니다.
Display name을 통해서 설계 시에는 영문으로 설계하되 실제 사용 시에는 한글명으로 된 이벤트를 보면서 좀 더 직관적으로 사용할 수 있습니다.
Display name을 사용하는 또 다른 방법은, 영문 설계 시의 명명법에 오류가 있을 경우입니다. Amplitude의 경우에는 한번 설계된 이름으로 수집된 이벤트명을 바꾸더라도 소급적용되지 않도록 구현되어 있습니다. 따라서 원시데이터의 명명법에 오류가 있다면 원시데이터를 건드리지 않고 Display name으로 업데이트하여 사용할 수 있습니다.
3) Page view vs Click
같은 이벤트를 추적하더라도 사용자의 행동이벤트를 추적할지, 사용자의 로드페이지를 추적할지에 따라 각각 수집되는 이벤트의 분석 장단점이 존재합니다.
다만, 동일한 이벤트에 있어서 Page view와 Click 두 가지 관점이 중복으로 설계되지 않게 하는 게 Data point 관리 차원에서 주요하며, 하나의 기준으로 동일 퍼널의 이벤트가 설계되어야 퍼널 분석 시 동일한 기준으로 전환 분석에 활용할 수 있습니다.
1. 중복 트래킹 방지를 위해 하나만 설계
2. 퍼널 분석을 위해 Critical path or User path에서는 동일한 기준으로 설계
Page view의 특징
장점 : 사용자가 페이지 사이를 어떻게 이동하는지에 대한 인사이트 제공
페이지에 도달되는 순간 트리거되기 때문에 해당 페이지에 도달 가능한 다양한 경로가 존재하는 경우 경로별 비율과 특징에 대해서 살펴볼 수 있습니다.
단점 : 이벤트 볼륨의 증가, 분석 노이즈 발생
해당 페이지로 이동시키는 클릭 이벤트 중 하나만 추적하는 방식 대비 경로에 대한 필터가 되지 않기 때문에 상대적으로 이벤트 볼륨이 큰 편입니다.
페이지로 들어오는 다양한 경로로 인한 분석 노이즈가 발생하며, 이로 인한 데이터 전처리 과정이 필요합니다.
단일 페이지 뷰 vs 페이지별 독립적 뷰
단일 페이지 뷰 특징
1. 여러 페이지에서 하나의 일반 이벤트를 측정하고 이벤트 속성으로 구분
e.g.
Event(이벤트) : view product list
Event property(속성) : page name
2. 개별 Event를 차트에 추가하지 않더라도 Event property에서 그룹화 기준을 설정하고 서로 다른 이벤트의 분석 결과를 볼 수 있음
3. 퍼널 경로 설정 시 유사한 기능을 하는 페이지뷰로 묶어서 설정하기 유효
페이지별 독립적 뷰 특징
1. 사용자가 어떻게 페이지 간에 이동하는지 쉽게 확인 가능
2. Pathfinder / Pathfinder Users 리포트 활용성 높음
3. 경로별 성과 분석이 중요하고 경로별로 다른 기능적 특징을 가질 때 유효한 방식
4. 이들 이벤트를 그룹화하는 커스텀 이벤트 생성을 하면 단일 페이지와 유사하게 활용 가능
추적하는 페이지 뷰의 특성에 따라 두 가지 방법을 혼합하여 사용 가능합니다.
다만, 어떤 방식이 좋을지 선택하기 어렵다면, 쪼개서 수집하고 Custom event로 그루핑 하는 방식이 추후 분석 확장성이 높음 → 단, 이벤트가 그룹핑되었을 때 그룹바이로 쪼갤 속성이 미리 들어가 있어야 합니다.
2. Property
User property(사용자 속성) : 각 개별 사용자의 context를 제공
Event property(이벤트 속성) : 각 이벤트에 대한 context를 제공
서비스에서 사용자의 이벤트 흐름을 이해하는 것도 중요하지만, 이벤트와 사용자의 다양한 상태를 쿼리 하지 못하면 분석은 단순하지고 일차원적인 분석만 가능합니다. 세분화된 수준에서 데이터를 이해하고 분석결과를 얻고 싶다면 이벤트 &사용자 속성을 활용해다 합니다.
속성값은 이벤트에 매칭시키는 작업을 초기에 하지 않더라도 이후에 업데이트 가능합니다.
Amplitude SDK를 사용하는 경우 기본적으로 추적하는 사용자 속성이 존재합니다.
기본 User properties
Platform, Device type, Country, City, Region, Start version, Version, Carrier, OS, Language, Library
1) Property 사용 권장 사항
Event Property 권장 사항
Funnel의 holding constant 조건을 이용하기 위해선 funnel에 정의될 모든 이벤트에 holding constant 조건으로 사용할 이벤트 속성이 동일하게 포함되 있어야 합니다. 즉, 퍼널 내에 존재하는 이벤트의 속성 설계 시 이를 고려한 통일화 작업이 필요합니다.
User Property 권장 사항
1. 소문자 표기
2. 속성의 값이 문자열이 아닌 경우 속성의 값 유형을 이름에 반영
e.g.
is subscriber = true/falce (boolen 값을 is라는 표현으로 name에 표기)
num of purchases = [1.2.3] (숫자 값을 num이라는 표현으로 name에 표기)
Data Governance
1. 데이터 거버넌스
데이터 거버넌스 프레임워크 동영상 / Amplitude 데이터 구조 동영상
1) 데이터 거버넌스란 무엇이며 왜 중요한가
정의 : 회사가 수집하고 있는 데이터를 유지 관리하는 시스템
왜 중요한가? : 시간이 갈수록 데이터의 가치를 더해줄 수 있는 방법
2) Amplitude Data(구. Govern)
Amplitude data 기능은 단일 인터페이스 내에서 Amplitude 데이터를 관리하는 다양한 방법 제공하면서 Amplitude에서 수집된 데이터와 관련된 다양한 governance 기능을 제공하고 있습니다.
이벤트 승인, 차단, 삭제 등의 데이터 관리 도구
Unexpected Error 관리 가능
Uncategorized Events / Missing Descriptions 이벤트에 대한 관리 가능
이벤트 유형, 이벤트 속성 및 사용자 속성에 대한 총계와 사용량 관리
이미지 클릭 시 GIF 전체 확인 가능3) 이벤트 미사용의 다양한 종류
이벤트 및 속성의 Active & Visibility & Block & Delete의 차이점
Visibility
이벤트와 속성이 쿼리 하는 것은 원하지 않지만 해당 이벤트와 속성을 데이터를 수집하고 싶다면 Visible → Hidden을 수정하는 것이 유효
즉, 데이터는 수집하지만 리포트에서 활용 X
이벤트와 속성은 instrumentation limit에 적용됨
Active
Active user를 정의할 때 혹은 Any Active Event 측정항목의 할당에서 특정 이벤트를 제외시키고 싶을 때 Active → Inactive 변경
단, New user 정의에서는 계산됨
해당 이벤트를 Inactive 하는 경우 즉시 소급적용 되기 때문에 과거 데이터의 변경 여부를 고려
Inactive Event도 Data point 소진(정상 수집) volume에 포함됨
Block
특정 이벤트 또는 속성을 차단하여 데이터를 수집하지 못하도록 하는 기능
블락이 되기 이전에 수집된 데이터를 통한 쿼리와 차트 사용 가능. 즉, 해당 이벤트에 대한 소급적용은 되지 않음
특정 이벤트로 인해 월별 이벤트 볼륨 제한에 도달한 경우에 유효
Delete
더 이상 필요하지 않은 이벤트나 속성을 삭제
instrumentation limit 관리에 효과적
Block과 다르게 삭제된 이벤트나 속성은 쿼리나 차트에서 사용 불가
이벤트 관리의 케이스 별 수집 & 활용 여부데이터 텍소노미 Best practice
지금까지 Taxonomy 구성을 위한 다양한 방법들을 같이 살펴보았습니다. 다만, 처음부터 모든 Taxonomy를 구성하는 것은 아무리 공부를 하고 연습을 한다고 하더라도 쉬운 일은 아닙니다.
이러한 어려움을 고려해서 Amplitude는 다양한 산업군 별로 Taxonomy에 대한 가이드와 Best practice를 구성해 놓았습니다. 특히 각 산업군별 워크북은 어떤 식으로 이벤트를 구성해야 하는지 구성 아이디어에 대한 여러 아이디어를 제공하기 때문에 해당 가이드를 바탕으로 내 서비스에 맞는 Custom 한 taxnomy 구성에 많은 참고가 될 수 있습니다.
Taxonomy를 잘 구성하는 왕도는 없습니다. 또한 완벽한 Taxonomy 또한 없습니다. 우리 서비스를 왜 분석해야 하고 무엇을 분석할지를 끊임없이 고민해서 좋은 Taxnomy를 구성하는 게 중요하지만 너무 많은 고려 때문에 설계에 많은 시간이 들어간다면 분석 준비 때문에 분석을 하지 못하는 본말이 전도된 문제가 발생하게 되는 것입니다. 가장 중요한 것은 우선 시작하는 것입니다.
시작하면서 배우고 거기서 얻은 인사이트로 수정 개선해 나가는 Growth mind가 Taxnomy 구성의 가장 중요한 best practice라고 생각됩니다.
참조
https://help.amplitude.com/hc/en-us/articles/360043750992
https://help.amplitude.com/hc/en-us/articles/360047138392
https://help.amplitude.com/hc/en-us/articles/115002380567
https://help.amplitude.com/hc/en-us/articles/360047138392
https://help.amplitude.com/hc/en-us/articles/5078704508571
https://help.amplitude.com/hc/en-us/articles/5447814048795
https://help.amplitude.com/hc/en-us/articles/235777567
https://amplitude.com/blog/holding-constant
https://help.amplitude.com/hc/en-us/categories/5078631395227
