프로덕트 애널리틱스란? PM이 알아야 할 핵심 개념과 툴 비교

프로덕트 애널리틱스란?
프로덕트 애널리틱스는 사용자가 제품 안에서 남긴 행동 기록, 곧 이벤트를 모아 퍼널, 리텐션, 코호트 단위로 분석하고 제품을 어떻게 고칠지 판단하는 근거로 삼는 방식이다.

대시보드는 늘었는데, 답은 안 나온다

분기 리뷰 자리에서 이런 질문을 받아본 PM이 많다. "지난 분기에 낸 기능이 실제로 지표를 움직였나요?" 답하려고 자료를 뒤지면 데이터는 분석 툴과 스프레드시트, 설문 결과, 슬랙 스레드에 흩어져 있다. 대시보드에 숫자는 가득한데, 정작 의사결정으로 이어지는 숫자가 없다.

MAU가 줄었다는 사실 정도는 웹 애널리틱스로도 안다. 하지만 어떤 행동을 한 사용자가 남고, 어디서 이탈했는지는 거기서 답이 나오지 않는다. 세션과 페이지뷰를 중심으로 데이터를 쌓으면 분석의 단위가 사람이 아니라 방문이 되기 때문이다. 프로덕트 애널리틱스는 그 단위를 사용자와 행동으로 바꾼다.

핵심 개념: 이벤트, 사용자, 시간

1) 이벤트 기반 데이터 모델

프로덕트 애널리틱스의 최소 단위는 페이지가 아니라 이벤트다. "회원가입 완료", "장바구니 담기", "결제 성공"처럼 행동 하나하나에 이름을 붙이고, 그 행동이 일어난 맥락을 속성으로 함께 기록한다. 어떤 요금제를 쓰는 사용자인지, 어떤 기기에서 눌렀는지, 몇 번째 시도인지가 속성에 들어간다. 이 구조를 미리 잡아둬야 "iOS 신규 가입자 중 첫날 장바구니를 만든 사람의 7일 리텐션" 같은 질문에도 곧바로 답이 나온다.

2) 퍼널: 어디서 새는가

퍼널은 순서대로 일어나는 행동의 전환율을 본다. 온보딩 4단계 중 3단계에서 절반이 빠져나간다면, 그 화면이 다음 스프린트의 후보다. 전환율 숫자 자체보다 단계와 단계 사이의 낙차가 어디에 있는지가 중요하다.

3) 리텐션: 남는가

리텐션 커브가 시간이 지나도 평평해지지 않고 계속 떨어진다면, 제품이 아직 시장에서 자리를 못 찾았다는 신호로 본다. 반대로 커브가 어느 지점에서 눕기 시작하면 그 아래에 핵심 사용자층이 있다.

4) 코호트: 누가 다른가

같은 기간에 가입했더라도 첫 주에 특정 기능을 써본 그룹과 그렇지 않은 그룹은 잔존율이 갈린다. 이 차이를 찾아내는 작업이 코호트 분석이다. 여기서 나온 가설이 온보딩 설계와 활성화 지표로 이어진다.

실전: PM이 먼저 세팅할 4단계

1. 핵심 행동 정의: 사용자가 제품에서 가치를 느낀 순간을 이벤트 하나로 정한다. 협업 툴이라면 "첫 문서 공유", 커머스라면 "첫 구매 완료"가 후보다.
2. 트래킹 플랜 작성: 이벤트 이름 규칙과 속성 목록, 담당자, 검증 방법을 문서로 고정한다. 이 단계를 건너뛰면 6개월 뒤 비슷한 이름의 이벤트가 서른 개씩 쌓인다.
3. 지표 트리 연결: 북극성 지표 아래에 활성화, 유지, 수익화 지표를 붙이고, 각 지표를 움직이는 이벤트를 그 아래에 연결한다.
4. 주간 리듬 만들기: 퍼널과 리텐션을 매주 같은 요일에 보고, 변화가 보이면 세그먼트를 쪼개 원인을 좁혀 들어간다.

순서를 바꾸면 대개 실패한다. 툴부터 붙여놓고 이벤트는 나중에 정리하겠다는 팀이 이 문제를 가장 자주 겪는다.

툴 비교: 무엇을 기준으로 볼 것인가

기능이 많은 도구가 곧 좋은 도구는 아니다. 도입 3개월 뒤에 실제로 몇 명이 스스로 툴을 열어보는지가 진짜 성공 기준이다. 아래 표에는 2026년 8월 기준으로 각 사 공식 문서에 공개된 내용을 정리했다. 요금과 플랜 정책은 자주 바뀌니, 도입을 검토하는 시점에 공식 페이지를 다시 확인하는 편이 안전하다.

GA4의 샘플링 기준과 데이터 보관 정책은 구글 공식 고객센터 문서에 나와 있다. 여기서 오해가 자주 생긴다. GA4는 애초에 트래픽 소스와 광고 성과를 보라고 만든 마케팅 도구다. 제품 안에서 사용자가 왜 떠났는지를 묻기 시작하면 샘플링에 걸리고, 반영은 늦고, 로데이터는 열어볼 길이 없다. 서로 보완할 관계가 아니라, 다음 단계의 도구가 필요한 지점이다.

도입이 성공했다는 건 무슨 뜻인가

국내 한 이커머스 팀의 상황을 시나리오로 옮겨본다. 이 팀은 분석 요청이 데이터팀 한 곳으로 몰려 평균 대기 시간이 3일이었다. 이벤트 정의를 다시 잡고 비개발 직군이 직접 퍼널을 만드는 환경으로 옮긴 뒤, 주간 분석 요청 건수는 줄고 기획자가 직접 만든 리포트는 늘었다. 정작 크게 달라진 건 숫자가 아니라 회의 풍경이다. 근거를 들고 오는 사람이 분석가 한 명에서 팀 전체로 넓어졌다.

티맵모빌리티의 데이터 책임자는 공개 인터뷰에서 "자판기에서 버튼 누르듯 데이터가 나오는 환경"을 목표로 꼽았다고 한다. 도구 도입의 결과를 기능 목록이 아니라 조직의 습관으로 정의한 표현이다. 분석가에게 쿼리를 부탁하고 며칠씩 기다리던 구조가 바뀌면, 의사결정 속도도 따라 바뀐다.

2026년의 변화: 묻기 전에 알려주는 분석

사람이 대시보드를 열어보는 방식에서, 시스템이 이상 징후를 먼저 알려주는 방식으로 무게중심이 옮겨간다. KPI가 흔들린 아침에 원인을 직접 찾아 헤매는 대신 알림이 먼저 도착한다. 슬랙이나 노션에서 자연어로 분석 질문을 던지는 환경도 늘고 있다. 여기에 AI 에이전트가 사람 대신 제품을 호출하는 트래픽까지 섞이면서, 사람의 클릭만 가정한 트래킹 설계에는 사각지대가 생긴다는 지적이 나온다.

다만 언어 모델이 데이터를 읽어내더라도 비즈니스 맥락까지 읽지는 못한다. 그럴듯한 답과 맞는 답을 가르는 건 결국 이벤트 설계의 정확도다.

자주 묻는 질문

GA4가 있는데 프로덕트 애널리틱스 툴이 따로 필요한가?

목적이 다르다. GA4는 어떤 채널에서 몇 명이 들어왔는지를 잘 답한다. 반면 가입하고 3일 안에 떠난 사용자가 직전에 무엇을 했는지, 어떤 행동을 한 코호트가 오래 남는지 같은 질문 앞에서는 샘플링과 반영 지연, 집계 중심 구조가 발목을 잡는다. 프로덕트 애널리틱스 툴은 그 "왜"를 파고들라고 만든 도구다.

이벤트는 몇 개부터 시작하는 게 좋은가?

10개 안팎이면 충분하다. 가입, 활성화, 핵심 기능 사용, 결제처럼 지표 트리에 곧장 연결되는 행동만 먼저 정의한다. 처음부터 100개를 붙이면 검증이 안 된 이벤트가 쌓여 데이터 신뢰도가 떨어진다.

데이터 분석가가 없는 팀도 쓸 수 있나?

가능하다. 판단 기준은 두 가지다. SQL 없이 퍼널과 코호트를 만들어볼 수 있는 UI인가, 마케터나 기획자가 도입 3개월 뒤에도 스스로 그 화면을 여는가. 도구를 고를 때 기능 개수보다 이 둘을 먼저 확인하는 편이 낫다.

마무리

프로덕트 애널리틱스는 툴 이름이 아니라 질문하는 방식이다. 무엇이 일어났는지에서 멈추지 않고 누가, 언제, 왜 그렇게 행동했는지까지 따라가는 습관이 자리 잡으면 로드맵의 근거가 달라진다. 이벤트 열 개를 제대로 정의하는 일부터 시작해보자. Nitrox 블로그에서 관련 가이드 더 보기