우리 서비스 데이터 분석을 잘하는 방법 - GA4, 믹스패널, 앰플리튜드

믹스패널 이벤트 설계, GA4 강의 듣는다고 해결될까?

"이번 달 매출은 나오는데, 정작 고객이 왜 사고 왜 안 사는지는 모르겠다."

사업을 어느 정도 키운 사장님들이 공통으로 하는 말입니다. 매출, 가입자 수, 방문자 수 같은 결과 지표는 대시보드에 잘 나오는데, 그 결과가 나오기까지의 "과정"은 안 보이는 경우가 많습니다. 고객이 어디서 이탈했는지, 어떤 버튼을 누르고 안 눌렀는지, 어떤 알림에 반응했는지 같은 것들이요.

이 과정을 들여다보는 도구가 믹스패널(Mixpanel) 같은 행동 분석 툴입니다. 그런데 이 도구를 쓴다고 바로 답이 나오는 게 아닙니다. 진짜 문제는 "이벤트 설계"입니다.

믹스패널/앰플리튜드의 PA 툴과 GA4, 뭐가 다른가요

구글 애널리틱스(GA4)는 "몇 명이 왔다, 어느 페이지를 봤다" 같은 트래픽 중심 지표에 강합니다. 반면 믹스패널 같은 PA 툴은 "이 유저가 장바구니에 담고 → 얼마 후에 → 결제까지 갔는지" 같은 한 사람의 행동 흐름(퍼널)과, "우리 고객 중 몇 %가 재구매 고객인지" 같은 고객 세그먼트를 보는 데 더 강합니다.

둘 다 쓰는 회사도 많고, 둘 중 하나만 정교하게 쓰는 회사도 많습니다. 중요한 건 도구 선택보다 그 다음 단계입니다.

찜은 늘어나는데 왜 매출은 안 오를까요

찜하기 버튼 클릭 수는 꾸준히 늘어나는데 매출은 그대로인 경우, 대부분 "찜 → 상세조회 → 장바구니 → 결제"로 이어지는 퍼널 전체를 안 보고 찜 수치 하나만 보고 있어서입니다. 각 단계 이벤트를 다 설계해놔야 어느 구간에서 이탈하는지 정확히 짚을 수 있습니다. 이 퍼널을 제대로 쪼개려면 우리 서비스의 화면 구조와 사용자 흐름(IA)을 정확히 이해하고 있어야 합니다. 도구 사용법이 아니라 기획 역량이 필요한 지점입니다.

재방문율이 팀마다 다르게 나오는 이유

"재방문"의 기준을 앱 실행으로 볼지, 로그인으로 볼지, 특정 활동(구매·글쓰기 등)으로 볼지 먼저 정하지 않으면, 같은 데이터를 두고 팀마다 다른 숫자를 말하게 됩니다. 지표를 보기 전에 정의부터 합의해야 하는 대표적인 케이스입니다.

알림을 보내면 매출이 오르는 것 같은데, 확신이 안 서는 이유

푸시 알림을 '보냈다'는 로그와, 유저가 그 알림을 '탭해서 들어왔다'는 로그는 완전히 다른 이벤트입니다. 이 둘을 구분해서 설계해야 "알림 효과"라는 걸 숫자로 증명할 수 있습니다. 많은 회사가 이 구분 없이 알림을 보내고, 효과가 있는지 없는지도 모른 채 계속 보내고 있습니다. 그리고 이 값이 우리 DB(서버) 어디에 이미 있고, 어디는 새로 클라이언트에서 잡아야 하는지 구분하는 건 DB 구조를 아는 사람만 정확히 짚어낼 수 있습니다.

VIP 고객을 감으로만 파악하고 있다면

'구매해본 유저', '재구매 유저', '특정 카테고리를 좋아하는 유저' 같은 세그먼트를 유저 속성(User Property)으로 미리 설계해두면, 나중에 타겟 마케팅이나 리텐션 캠페인을 할 때 감이 아니라 숫자로 대상을 골라낼 수 있습니다.

이벤트 이름을 그때그때 지었다가 나중에 관리가 안 되는 이유

초기에는 개발자가 편한 대로 이벤트 이름을 짓는 경우가 많습니다. 문제는 팀이 커지고 대시보드가 늘어날수록, 이름이 제각각이라 같은 행동을 다른 이벤트로 중복 집계하거나, 아예 못 찾는 일이 생긴다는 겁니다. 처음부터 하나의 체계(택소노미)로 설계해두는 회사와, 나중에 전부 다시 설계하는 회사의 차이가 여기서 갈립니다. 이걸 개발자가 실제로 구현할 수 있게 문서로 남기는 것까지가 설계의 끝입니다.

그래서 왜 GA4 강의만 들어서는 안 되는가

위 다섯 가지 사례를 다시 보면 공통점이 있습니다. 전부 "믹스패널 사용법"을 몰라서 생긴 문제가 아니라, 다음 세 가지 중 하나가 빠져서 생긴 문제입니다.

1. 서비스 기획 구조를 모른다 — 화면과 사용자 흐름을 정확히 쪼갤 줄 몰라서, 퍼널 단계를 놓칩니다.

2. DB 구조를 모른다 — 이미 서버에 있는 값과, 클라이언트에서 새로 잡아야 하는 값을 구분하지 못해서, 있는 데이터를 중복으로 만들거나 없는 데이터를 있다고 착각합니다.

3. 개발자와 협업하는 구조를 모른다 — 설계를 문서로 명확히 못 남겨서, 만들어놓은 이벤트가 실제로는 다르게 구현되거나 시간이 지나면 유지보수가 안 됩니다.

믹스패널이든 GA4든 앰플리튜드든, 툴 자체는 결국 그릇입니다. 그 그릇에 무엇을 담을지 정하는 일은 마케팅 툴 강의로 배울 수 있는 게 아니라, 기획·DB·개발이라는 세 영역을 동시에 볼 줄 아는 사람이 해야 하는 일입니다.

마무리

노피랩스는 서비스기획자 출신이 데이터 설계를 맡습니다. 화면 구조와 사용자 흐름을 기획자 관점에서 읽고, DB 구조를 이해해서 어떤 값이 이미 서버에 있는지 파악하고, 개발자와 실제로 협업하며 설계서를 문서로 남기는 것까지 — 이 세 가지가 같이 있어야 이벤트 설계가 "쓸 수 있는" 결과물이 됩니다. 이 구조로 여러 프로젝트의 이벤트·KPI 설계를 진행해왔습니다.

이런 설계를 혼자 다 하기 부담스럽다면, 처음부터 전체 이벤트 택소노미와 KPI 구조를 같이 잡아드리는 것도 방법입니다.

자주 묻는 질문

Q. 믹스패널과 GA4를 둘 다 써야 하나요? 꼭 둘 다 필요한 건 아닙니다. 트래픽·마케팅 성과 중심이면 GA4, 유저 개개인의 행동 흐름과 리텐션·세그먼트 분석이 중요하면 믹스패널 쪽이 더 유리합니다. 둘을 병행하며 이벤트명을 호환되게 설계해두는 회사도 많습니다.

Q. 이벤트 설계는 개발자가 알아서 하면 되지 않나요? 개발자는 "어떻게 수집할지"는 잘 정합니다. 문제는 "무엇을, 왜 수집해야 하는지"는 비즈니스 목표와 KPI를 아는 사람이 같이 정해야 한다는 점입니다. 그래서 이벤트 설계는 기획·데이터·개발이 같이 앉아서 정리하는 게 맞습니다.

Q. 마케터나 그로스해커한테 맡기면 안 되나요? 마케팅 관점의 KPI 설계는 할 수 있지만, 그 지표를 실제로 "잡을 수 있는 데이터인지"를 판단하려면 화면 구조와 DB 구조를 같이 봐야 합니다. 이 부분이 빠지면 설계는 그려지는데 실제 구현에서 절반이 빠지는 경우가 많습니다.

Q. 서비스를 이미 운영 중인데, 지금 와서 이벤트 설계를 다시 해도 될까요? 가능하고, 오히려 실제 사용 데이터가 있는 상태라 설계가 더 정확해집니다. 기존 이벤트를 다 버리는 게 아니라, 빠진 부분과 중복·모순된 부분을 정리하는 방식으로 진행하면 됩니다.