앰플리튜드로 DDUX하기_이벤트 설정 전 체크사항
데이터 관리자는 자신의 프로덕트를 가장 잘 아는 사람이어야 합니다.
들어가며
앰플리튜드를 통해 데이터를 보내고 분석하기 전에 가장 중요한 스텝은 어떤 이벤트를 보내고 트래킹 할 것인지를 결정하는 것이다. 훌륭하고 잘 계획된 Data Governance rules 구축은 아무리 강조해도 지나치지 않다. 처음 설정해 둔 Governance 규칙들은 data taxanomy가 클린 하게 유지되는 것을 도와주고 여러 팀원들이 앰플리튜드를 사용할 때 data 구조를 빠르게 이해하고 데이터에서 의미 있는 결과들을 이끌어 낼 수 있게 도와준다.
거버넌스 룰을 정할 때 생각해야 할 사항은 아래와 같다.
- 새로운 데이터가 목표/유용 사례 및 KPI와 일치하는지 확인할 것
- 이벤트 네이밍은 가이드라인에 맞도록 통일된 포맷을 가질 것
- 이벤트 네이밍은 짧게 작성하여 읽기 쉽도록 할 것
무엇보다도 앰플리튜드에서는 이벤트 명칭에 대한 룰을 강조하는데 그 이유는 앰플리튜드에서는 'Checkout Submitted Order'과 'Checkout submitted order'를 서로 다른 이벤트로 생각하기 때문이다. 또한 통일되지 않는 네이밍 규칙은 다른 팀원들에게 혼란을 야기하며 운영, 관리가 어렵다.
오늘은 본격적인 앰플리튜드 이벤트 세팅 전 고려해야 할 사항들에 대해 알아본다.
1) 비즈니스 목적을 정의하자
우리 팀은 무엇을 향해 일하고 있는가? 전체적인 목표는 무엇인가? 왜 우리는 앰플리튜드를 사용하는가?
우리는 위와 같이 짧지만 비즈니스 근본에 있는 질문에 대답할 수 있어야 한다.
대부분의 앰플리튜드를 사용하는 사용자들은 타깃을 재구축하고, 전환율과 재방문율을 높이고, LTV를 증가하는 등의 목표를 가진다. 그러나 이러한 기본적인 목표 말고도 각자가 종사하고 있는 서비스/프로덕트에 따라 갖고 있는 KPI(Key Performance Indicator)가 있다. 프로덕트에서 목표로 하고 있는 것을 data taxanomy를 구축하기 전에 미리 정리한다면 KPI와 목표에 맞는 이벤트를 구축하고 데이터를 트랙킹 할 수 있다.
2) User Journey를 이해하자
피그마 유저저니 템플릿이벤트 텍사노미를 구축할 때 프로덕트(서비스)의 유저 저니(User Journey/고객 여정)가 어떻게 되는지 알아야 한다. 데이터 텍사노미는 3가지의 레벨로 나눌 수 있다.
-Event counters : Daily/monthly average users, total purchase, etc.
이벤트 카운터 : 일/월평균 유저수, 총 구매량 등
- Funnels and conversions : Retention rates, funnel conversion, power curve chart
퍼널/전환 분석 : 리텐션 비율, 퍼널 전환비율, 파워커브 차트
- Behavioral analysis : Impacts of performing actions on your other metrics
행동 분석 : 어떠한 이벤트에 영향을 주는 다른 이벤트의 영향
담당자는 새로운 사용자가 파워유저로 가는 유저 저니가 어떤 모습이어야 하는지 알아야 하며, 유저가 파워유저로 가는 전환에 중요한 이벤트/요인가 무엇인지 알아야 한다. 또한 이러한 저니에 잠재적으로 방해되는 요소는 무엇인지도 파악하고 있어야 데이터 텍사노미를 자세하지만 군더더기 없이 구축하여 필요한 데이터를 놓치지 않고 수집할 수 있다.
3) 프로덕트의 Critical Path 주요 패스를 알고 있어야 한다
각 서비스마다 Critical paths가 있다. 예를 들어 e-commerce 프로덕트에서는
제품 탐색 -> 장바구니에 담기 -> 결제 -> 구매확정의 패스가 중요하다. 이러한 Critical Path들은 서비스의 goal을 성취하는데 중요하다.
게이밍 프로덕트의 경우에는 유저가 앱을 열고 가입을 하고 게임 튜토리얼을 보고 게임을 시작하는 것이 주요 패스가 될 수 있다. 이렇게 중요 패스를 설정하기 위해서는 프로덕트를 잘 이해하고 있어야 하며, 데이터 담당자는 단순히 이러한 패스를 끝낸 사람들의 수를 확인하는 것이 아닌 더 나아가 어떤 요인이 주요 이벤트를 유발하고 이탈시키는가 까지도 알아야 한다.
4) 프로젝트는 최소 두 개를 만들어 관리하자
앰플리튜드에서 프로젝트 생성 화면앰플리튜드에서 프로젝트란 프로덕트에서 수집한 데이터들이 모이는 공간이다. 앰플리튜드 내에서 여러 개의 프로젝트를 만들 수 있고 최소 Test Project, Production Project 두 개의 프로젝트를 만들어야 함을 기억해야 한다.
실제 Productcion Project에 데이터를 구축하고 보내기 전에 반드시 Test Project에서 QA를 진행하고 보내야 하며, 이로써 버그를 빠르게 캐치하고 실제 Production Project의 데이터 관리를 깨끗하고 정확하게 유지할 수 있다. 각각의 프로젝트의 데이터는 독립적으로 구분되어 있기 때문에 데이터 연동이 되거나 머지되지 않는다.
프로젝트의 수는 프로덕트의 성격이 어떠한가, 어떤 데이터를 수집할 것인가에 따라 달라지며 예를 들어 모든 플랫폼 내에서의 사용자 데이터를 얻고 싶다고 할 때에는 IOS/WEB을 하나로 묶어 하나의 프로젝트로 만들 수 있고 (e.g. bom_user) 기기별로 다른 데이터를 받고 싶다면 분리하여 두 개의 프로젝트를 만들 수 있다.(e.g. bom_ios_user, bom_web_user)
여러 프로덕트의 데이터를 받고 싶을 때
플랫폼별 개별적인 데이터를 받고 싶을 때 (web vs mobile)
플랫폼 또는 프로덕트의 각각의 팀의 책임이 달라 개별적으로 프로젝트를 생성하고 싶을 때
하나의 프로덕트 내에서도 여러 개의 프로젝트를 만들 수 있다.
정리하며
앰플리튜드를 통해 보고자 하는 데이터는 각각의 프로덕트에 따라 다르지만 데이터를 설정하기에 앞서 데이터 관리자는 자신의 프로덕트를 가장 잘 알고 있어야 한다.
우리의 프로덕트의 목표는 무엇이고, 이 목표를 위해 유저는 우리가 설정해둔 패스 중 어떤 패스를 이용해야 하며 우리에겐 어떤 유저의 여정이 중요한지를 아는 것이 선행되어야지만 주요 이벤트를 설정하여 원하는 데이터를 수집할 수 있다.
이렇게 글을 읽으면 납득이 되는, 어찌 보면 너무나 당연하고 기본이 되는 단계이지만 일을 하다 보면 눈앞에 당장 해야 할 일에 급급해 이런 기초를 다지지 않고 지나가는 경우가 많다.
앰플리튜드를 사용해 빨리 이벤트를 지정하여 데이터를 받고 싶겠지만 그전에 다시 한번 프로덕트의 목표, 우리 팀의 KPI를 적어 어떤 데이터가 우리에게 필요한지 적어보자.
그리고 그 Business Goal에 맞추어 유저 저니를 진행해보자.
이 단계를 통해 필요한 데이터, 패스가 정해졌다면 이제 앞으로 설정할 Governance Rules을 통해 Clean 한 Data Taxanomy를 구축할 수 있을것이다.
* 이 글은 앰플리튜드 시리즈로 업데이트될 예정입니다.
브런치 구독을 통해 앞으로 업데이트되는 글을 읽고 함께 앰플리튜드를 정복해보아요!
* 참고 글 원문
