StuDyata.zip

[코드잇 스프린트] 스프린트 미션 09 - Amplitude로 음악 스트리밍 서비스 분석해보기

자유를원해 — Wed, 13 May 2026 22:49:13 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.

음악 스트리밍 서비스 데이터 분석해보기

아홉 번째 스프린트 미션은 Amplitude를 활용해 음악 스트리밍 서비스 데이터를 분석해보는 미션이었다. 이번 미션에서는 Amplitude에서 제공하는 Demo Data 중 Media Streaming - Analytics를 사용하였다. 실제 서비스 데이터는 아니지만, 음악 스트리밍 서비스를 가정한 이벤트와 유저 속성이 제공되어 있었다. 서비스 화면은 따로 제공되지 않았기 때문에 스포티파이나 멜론 같은 음악 스트리밍 서비스를 떠올리면서 분석을 진행해야 했다.

이번 미션의 핵심은 크게 두 가지였다.

첫 번째는 서비스의 현황을 파악하는 것이었다. 유저 규모가 어느 정도인지, 유저들은 어떤 플랫폼이나 요금제를 사용하고 있는지, 하루에 얼마나 자주 접속하고 얼마나 오래 머무는지, 어떤 행동을 많이 하는지, 그리고 서비스를 지속적으로 이용하고 있는지 확인해야 했다.
두 번째는 신규 유저의 온보딩 단계를 개선할 수 있는 방안을 고민하는 것이었다. 신규 유저가 서비스에 가입한 뒤 첫 재생까지 잘 도달하는지, 서비스의 핵심 가치를 느낄 수 있는 행동은 무엇인지, 그리고 온보딩 과정에서 어디에서 이탈이 발생하는지 확인해야 했다.

이전 미션들이 지표 설계와 로그 설계에 가까웠다면, 이번 미션은 실제 Amplitude 차트를 활용해서 서비스 현황을 보고, 퍼널과 리텐션, Journeys, Lifecycle 등을 통해 인사이트를 정리하는 방식이었다. 그래서 지금까지 배운 개념들을 실제 분석 흐름 안에서 연결해보는 것이다.

‍ 분석 목적과 데이터

이번 분석의 목적은 음악 스트리밍 서비스의 이용 현황을 파악하고, 신규 유저가 서비스의 핵심 가치 경험까지 잘 도달하고 있는지 확인하는 것이었다. 분석 기준 월은 설정한 기간 내 최신 월인 2025년 12월로 설정하였다. 따라서 서비스 현황과 신규 유저 온보딩 분석은 대부분 2025년 12월을 기준으로 진행했고, 활성 유저 수처럼 시간 흐름이 중요한 지표는 2025년 1월부터 12월까지의 월별 추이도 함께 확인하였다.

주요하게 활용한 이벤트는 User Sign Up, Main Landing Screen, Search Song or Video, Select Song or Video, Play Song or Video, Favorite Song or Video, Play from Recommendation, Follow Playlist, Upgrade Plan 등이었다. 유저 속성으로는 Platform, PLAN_TYPE, Referer_Domain을 중심으로 사용하였다. 이를 통해 어떤 기기에서 서비스를 이용하는지, 무료 체험 유저와 유료 플랜 유저의 비중은 어떤지, 어떤 유입 채널을 통해 들어왔는지 확인할 수 있었다.

이번 분석에서 잡은 핵심 질문은 다음과 같았다.

첫째, 현재 서비스는 안정적으로 이용되고 있는가?
둘째, 신규 유저는 첫 재생과 즐겨찾기까지 잘 도달하고 있는가?
셋째, 온보딩에서 우선 개선해야 할 구간은 어디인가?

이 질문을 기준으로 서비스 현황 파악부터 신규 유저 온보딩 분석, 개선 방안 도출까지 이어서 정리하였다.

서비스 현황 파악

가장 먼저 서비스의 전체적인 현황을 파악하였다. 유저 규모, 유저 특성, 서비스 이용 빈도와 체류 시간, 주요 이벤트 사용 현황, 리텐션을 순서대로 살펴보았다.

유저 규모 확인

먼저 Any Active Event를 기준으로 활성 유저 수를 확인하였다.

2025년 월별 활성 유저 수는 대체로 약 51만 명에서 60만 명 사이에서 형성되었다. 1월 활성 유저 수는 약 60만 명, 12월 활성 유저 수는 약 53.5만 명으로 연초 대비 약 11.3% 감소하였다. 이를 통해 서비스 규모가 완전히 급격하게 무너지고 있는 상황은 아니지만, 장기적으로는 완만한 하락세가 나타나고 있다는 점을 확인할 수 있었다. 즉, 현재 서비스는 일정 수준의 유저 규모를 유지하고 있지만, 성장세보다는 안정 또는 소폭 감소에 가까운 상태라고 볼 수 있었다.

또한 2025년 12월의 일별 활성 유저 수를 확인했을 때 평균은 약 24.3만 명이었다. 평일에는 약 27만~28만 명대를 유지했지만, 주말에는 약 14만 명대까지 감소하는 패턴이 반복되었다. 이 부분이 조금 이상했다.ㅋㅋ 데이터상으로는 평일 이용이 더 활발하게 나타났다. 물론 데모 데이터여서 그런 것 같았고 일단 적어도 이 데이터 안에서는 평일에 더 자주 이용되는 서비스 패턴이 있었다.

유저 특성 확인

다음으로 2025년 12월 기준 활성 유저의 특성을 확인하였다.

먼저 Platform별 활성 유저 구성을 보면 Web 23.2%, iOS 21.1%, Android 20.4%, Windows 17.7%, tvOS 17.6%로 나타났다. Web 비중이 가장 높기는 했지만, 플랫폼 간 차이가 매우 크지는 않았다. 특정 플랫폼에 과도하게 의존하는 구조라기보다는 여러 플랫폼에서 비교적 고르게 사용되고 있는 서비스라고 볼 수 있었다.

PLAN_TYPE별로는 free trial이 82.3%, paid plan이 17.7%로 나타났다. 즉, 현재 서비스는 무료 체험 유저 기반이 큰 구조였다. 이 부분은 이후 온보딩 분석과도 연결된다고 생각했다. 무료 체험 유저가 많다는 것은 신규 유저가 서비스의 핵심 가치를 빠르게 경험하고, 이후 유료 전환까지 이어질 수 있도록 초기 경험을 잘 설계하는 것이 중요하다는 의미이기 때문이다.

유입 채널인 Referer_Domain 기준으로는 Email 30%, Facebook 25%, Google 20%, Direct 20%, Twitter 5.01% 순으로 나타났다. Email과 Facebook이 주요 유입 채널 역할을 하고 있었지만, 유입 규모가 크다고 해서 반드시 온보딩 성과가 좋은 것은 아니다. 그래서 이후에는 채널별 전환율도 따로 확인해야 한다고 생각했다.

서비스 이용 빈도와 체류 시간 확인

유저들이 서비스를 얼마나 자주 이용하고, 한 번 접속했을 때 어느 정도 머무는지 확인하기 위해 Sessions 차트를 활용하였다.

2025년 12월 기준 유저당 평균 세션 수는 약 3.34회였고, 평균 세션 길이는 약 13분 9초로 나타났다. 일별 추이를 보면 활성 유저 수와 유저당 평균 세션 수는 주말에 낮아지는 패턴이 반복되었지만, 평균 세션 길이는 약 13분 내외에서 비교적 안정적으로 유지되었다. 즉, 이 서비스는 요일에 따라 방문 규모와 방문 빈도에는 차이가 있었지만, 실제 접속한 유저의 콘텐츠 소비 시간은 비교적 일정하게 유지되고 있었다. 이 지표를 보면서 단순히 활성 유저 수만 보는 것보다 세션 수와 세션 길이를 함께 보는 것이 중요하다고 느꼈다. 활성 유저 수가 줄어들더라도 접속한 유저들이 비슷한 시간 동안 콘텐츠를 소비하고 있다면, 서비스 경험 자체가 크게 나빠졌다고 단정하기는 어렵다. 반대로 방문자는 많아도 세션 길이가 매우 짧다면 콘텐츠 소비가 충분히 이루어지지 않고 있을 수도 있다.

주요 이벤트 사용 현황 확인

다음으로 유저들이 서비스 안에서 어떤 행동을 주로 수행하는지 확인하였다.

주요 이벤트별 고착도를 보면 Play Song or Video가 높게 나타났다. 이는 음악 또는 비디오를 재생하는 행동이 단발성 행동에 그치지 않고 반복적으로 수행되고 있음을 보여준다. 음악 스트리밍 서비스에서 재생 행동은 서비스의 가장 핵심적인 행동이기 때문에, 이 행동의 고착도가 높다는 것은 긍정적으로 볼 수 있었다.

Favorite Song or Video도 반복 이용과 연결될 수 있는 행동으로 나타났다. 즐겨찾기는 유저가 단순히 콘텐츠를 한 번 소비하는 것을 넘어, 마음에 드는 콘텐츠를 저장하고 다시 들을 가능성을 만드는 행동이다. 그래서 이후 온보딩 분석에서도 중요한 Lock-in 행동 후보로 보았다.

반면 Follow Playlist는 시간이 지날수록 고착도가 크게 낮아졌다. 플레이리스트 팔로우는 단순 재생이나 즐겨찾기보다 조금 더 관여도가 높은 행동일 수 있다. 사용자가 서비스에 대한 신뢰나 취향 데이터가 어느 정도 쌓인 뒤에야 자연스럽게 이어지는 행동일 가능성이 있다고 생각했다.

이벤트 발생 수와 이벤트별 유저 수를 함께 보면 Main Landing Screen, Search Song or Video, Select Song or Video, Play Song or Video가 모두 높은 수준으로 나타났다. 즉, 유저들이 앱에 진입한 뒤 콘텐츠를 탐색하고, 선택하고, 재생하는 기본 이용 흐름까지는 비교적 안정적으로 도달하고 있었다. 따라서 이 서비스는 기본적인 콘텐츠 소비 흐름은 잘 작동하고 있지만, 추천 재생, 플레이리스트 팔로우, 유료 전환과 같은 더 깊은 행동까지 자연스럽게 이어지는지는 추가로 확인할 필요가 있었다.

리텐션 현황 확인

서비스 현황 파악의 마지막 단계로 리텐션을 확인하였다. 이번 분석에서는 두 가지 기준의 리텐션을 비교하였다. 하나는 서비스 재방문 관점의 Main Landing Screen 기준 리텐션이고, 다른 하나는 핵심 행동 반복 관점의 Play Song or Video 기준 리텐션이었다.

2025년 12월 기준 Main Landing Screen을 경험한 유저는 약 47만 명이었다. 이들의 리텐션은 Day 1 약 97.9%, Day 7 약 87.8%, Day 12 약 79.7%로 나타났다.

Play Song or Video를 수행한 유저는 약 46.7만 명이었고, 콘텐츠 재생 기준 리텐션은 Day 1 약 96.9%, Day 7 약 87.1%, Day 12 약 78.8%였다.

두 리텐션의 차이가 크지 않다는 점이 중요하다고 생각했다. 만약 메인 화면 기준 리텐션은 높은데 재생 기준 리텐션이 낮았다면, 유저가 다시 앱에 들어오기는 하지만 실제 콘텐츠 소비까지는 잘 이어지지 않는다고 볼 수 있다. 그런데 두 수치가 비슷하게 나타났기 때문에, 재방문한 유저가 단순히 앱에 들어오는 것에 그치지 않고 실제 콘텐츠 재생까지 자연스럽게 이어지고 있다고 해석할 수 있었다. 다만 이 데이터는 Amplitude 데모 데이터이기 때문에 리텐션 수치의 절대적인 높고 낮음보다는 이벤트 간 차이와 전체적인 흐름을 중심으로 해석하였다.

✨신규 유저 온보딩 분석

서비스의 전체 현황을 확인한 뒤에는 신규 유저 온보딩 분석을 진행하였다. 온보딩 분석에서 가장 중요한 질문은 '신규 유저가 어떤 행동을 했을 때 서비스의 핵심 가치를 느낀다고 볼 수 있는가?'였다. 음악 스트리밍 서비스에서 핵심 가치는 결국 사용자가 원하는 콘텐츠를 찾고, 실제로 재생하고, 마음에 드는 콘텐츠를 다시 들을 수 있도록 저장하는 경험이라고 생각했다. 그래서 아하 모먼트 후보를 먼저 정의하고, 이후 퍼널 분석을 통해 신규 유저가 해당 행동까지 얼마나 도달하는지 확인하였다.

아하 모먼트 후보 찾기

신규 유저가 어떤 행동을 경험했을 때 서비스에 Lock-in될 가능성이 있는지 확인하기 위해 Engagement Matrix를 활용하였다.

Engagement Matrix에서 Adoption은 해당 행동을 수행한 유저의 범위, Frequency는 행동의 반복 정도를 의미한다. 쉽게 말하면 얼마나 많은 유저가 해당 행동을 했는지, 그리고 그 행동을 얼마나 자주 반복했는지를 함께 보는 차트라고 이해할 수 있었다.

분석 결과 Select Song or Video, Search Song or Video, Main Landing Screen, Start Session은 Adoption과 Frequency가 모두 높은 영역에 위치하였다. 이는 유저들이 앱에 접속한 뒤 콘텐츠를 탐색하고 선택하는 기본 이용 흐름을 자주 수행하고 있다는 의미였다.

온보딩 관점에서는 Play Song or Video, Favorite Song or Video, Play from Recommendation, Follow Playlist를 아하 모먼트 및 Lock-in 행동 후보로 설정하였다. 이 중 Play Song or Video는 콘텐츠 재생이라는 서비스의 핵심 가치를 직접 경험하는 행동이다. 음악 스트리밍 서비스에서 유저가 실제로 노래나 영상을 재생하지 않는다면 서비스의 가치를 제대로 경험했다고 보기 어렵다. 그래서 첫 재생은 1차 아하 모먼트로 볼 수 있다고 판단했다. Favorite Song or Video는 유저의 취향 데이터가 서비스 안에 남는 행동이다. 단순히 한 번 재생하는 것보다 한 단계 더 나아가, 마음에 드는 콘텐츠를 저장하고 다시 들을 가능성을 만드는 행동이다. 그래서 첫 재생 이후의 Lock-in 행동 후보로 보았다. 반면 Play from Recommendation과 Follow Playlist는 첫 이용 단계에서 바로 유도하기보다는, 첫 재생과 즐겨찾기 이후 확장될 수 있는 후속 행동으로 보았다. 추천 재생은 어느 정도 취향 데이터가 있어야 더 설득력 있게 작동할 수 있고, 플레이리스트 팔로우는 단순 재생이나 즐겨찾기보다 더 높은 관여도가 필요한 행동이라고 생각했기 때문이다.

아하 모먼트 후보별 리텐션 비교

아하 모먼트 후보를 정의한 뒤에는 각 행동을 수행한 유저가 이후에도 다시 Play Song or Video로 돌아오는지 비교하였다.

먼저 Play Song or Video를 수행한 유저는 약 46.7만 명이었고, 이후 재생 리텐션은 Day 1 약 96.9%, Day 7 약 87.1%, Day 12 약 78.8%로 나타났다.

Play from Recommendation을 수행한 유저는 약 34.5만 명이었고, 이후 Play Song or Video로 돌아온 리텐션은 Day 1 약 92.4%, Day 7 약 83.7%, Day 12 약 74.1%였다. 추천 재생 기준 리텐션도 낮은 편은 아니었지만, 기본 재생보다 유저 수와 리텐션이 모두 낮았다. 그래서 추천 기능은 신규 유저의 콘텐츠 탐색을 도울 수는 있지만, 온보딩 초반의 핵심 목표라기보다는 첫 재생과 즐겨찾기 이후 확장할 후속 행동으로 보는 것이 더 적절하다고 판단했다.

다음으로 Favorite Song or Video와 Follow Playlist를 비교하였다.

Favorite Song or Video를 수행한 유저는 약 46.1만 명이었으며, 이후 재생 리텐션은 Day 1 약 96.2%, Day 7 약 86.6%, Day 12 약 78.1%로 나타났다. 이는 Play Song or Video 기준 리텐션과 거의 유사한 수준이었다.

반면 Follow Playlist를 수행한 유저는 약 31.8만 명이었고, 이후 재생 리텐션은 Day 1 약 92.8%, Day 7 약 84.0%, Day 12 약 74.6%였다. 리텐션 자체가 낮다고 보기는 어렵지만, 즐겨찾기에 비해서는 수행 유저 수와 리텐션이 모두 낮았다. 이 비교를 통해 Favorite Song or Video는 첫 재생 이후의 Lock-in과 관련이 있을 가능성이 높은 행동으로 볼 수 있었다. 반면 Follow Playlist는 온보딩 초반의 핵심 목표로 두기보다는 첫 재생과 즐겨찾기 이후 자연스럽게 확장할 후속 행동으로 해석하는 것이 적절하다고 생각했다.

신규 유저 첫 재생 퍼널 분석

다음으로 신규 유저가 가입 후 첫 재생까지 얼마나 잘 도달하는지 확인하기 위해 퍼널 분석을 진행하였다. 기본 퍼널은 다음과 같이 설정하였다.

User Sign Up → Main Landing Screen → Select Song or Video → Play Song or Video

추가로 콘텐츠를 직접 탐색하는 흐름을 보기 위해 검색 단계를 포함한 경로도 함께 확인하였다. 전환 기간은 가입 직후의 초기 행동을 보기 위해 1일로 설정하였다. 신규 유저 온보딩은 가입 후 시간이 많이 지난 행동보다, 가입 직후 얼마나 빠르게 핵심 경험까지 도달하는지가 중요하다고 생각했기 때문이다.

User Sign Up → Main Landing Screen → Search Song or Video → Select Song or Video → Play Song or Video

2025년 12월 기준 User Sign Up을 완료한 유저는 208,756명이었다. 이 중 Main Landing Screen까지 도달한 유저는 169,396명으로 전환율은 81.1%였다. 최종적으로 Play Song or Video까지 도달한 유저는 144,598명으로 최종 전환율은 69.2%였다.

검색 단계를 포함한 경로의 최종 전환율은 65.1%로, 기본 경로보다 낮았다. 이를 통해 신규 유저가 첫 재생까지는 비교적 잘 도달하고 있지만, User Sign Up에서 Main Landing Screen으로 넘어가는 구간에서 가장 큰 이탈이 발생하고 있음을 확인했다. 가입 완료 유저 중 약 18.9%가 메인 화면까지 도달하지 못했기 때문에, 가입 직후 첫 화면 진입 과정은 우선적으로 개선이 필요한 구간으로 볼 수 있었다. 이 부분이 이번 분석에서 가장 중요한 발견 중 하나였다. 첫 재생 자체의 전환율만 보면 나쁘지 않아 보일 수 있지만, 그 전에 가입 직후 메인 화면까지 도달하지 못하는 유저가 존재했다. 따라서 온보딩 개선은 첫 재생 버튼을 더 잘 보이게 만드는 것뿐만 아니라, 가입 완료 후 메인 화면까지 자연스럽게 연결되도록 만드는 것에서 시작해야 한다고 생각했다.

첫 재생 이후 Lock-in 행동 전환 분석

첫 재생까지의 흐름을 확인한 뒤에는 첫 재생 이후 즐겨찾기, 플레이리스트 팔로우, 추천 재생과 같은 Lock-in 행동까지 얼마나 이어지는지 확인하였다.

- 첫 재생 후 즐겨찾기 전환 퍼널

먼저 User Sign Up → Play Song or Video → Favorite Song or Video 퍼널을 확인하였다.

User Sign Up → Play Song or Video → Favorite Song or Video

User Sign Up을 완료한 유저 208,756명 중 Play Song or Video까지 도달한 유저는 148,725명으로 첫 재생 전환율은 71.2%였다. 이후 Favorite Song or Video까지 도달한 유저는 108,543명으로 최종 전환율은 52.0%였다. 이는 신규 유저의 절반 이상이 가입 후 1일 이내에 콘텐츠를 재생하고 즐겨찾기까지 수행하고 있음을 보여준다. 그래서 Favorite Song or Video는 신규 유저의 Lock-in과 관련이 있는 주요 행동 후보로 볼 수 있었다. 즐겨찾기는 사용자의 취향이 서비스 안에 남는 행동이기 때문에 개인화 추천에도 활용될 수 있고, 유저가 다시 돌아왔을 때 들을 콘텐츠를 저장해두는 역할도 한다. 따라서 온보딩 단계에서 첫 재생 이후 즐겨찾기까지 자연스럽게 이어지도록 만드는 것이 중요하다고 생각했다.

- 첫 재생 후 플레이리스트 팔로우 전환 퍼널

다음으로 User Sign Up → Play Song or Video → Follow Playlist 퍼널을 확인하였다.

User Sign Up → Play Song or Video → Follow Playlist

User Sign Up을 완료한 유저 208,756명 중 Play Song or Video까지 도달한 유저는 148,725명이었지만, Follow Playlist까지 도달한 유저는 31,001명으로 최종 전환율은 14.9%에 그쳤다. 즐겨찾기 전환율이 52.0%였던 것과 비교하면 플레이리스트 팔로우는 신규 유저 온보딩 초반에 바로 유도하기에는 상대적으로 관여도가 높은 행동으로 보였다. 생각해보면 처음 들어온 유저가 바로 특정 플레이리스트를 팔로우하려면, 그 플레이리스트가 자신의 취향과 맞는지에 대한 어느 정도의 확신이 필요하다. 반면 즐겨찾기는 마음에 드는 곡 하나를 저장하는 비교적 가벼운 행동이다. 그래서 온보딩 초반에는 플레이리스트 팔로우보다 즐겨찾기를 먼저 유도하는 것이 더 자연스럽다고 판단했다.

- 추천 재생 전환 퍼널

추천 기능이 신규 유저의 초기 콘텐츠 소비에 얼마나 기여하는지도 확인하였다. 이를 위해 User Sign Up → Main Landing Screen → Play from Recommendation 퍼널을 구성하였다.

User Sign Up → Main Landing Screen → Play from Recommendation

User Sign Up을 완료한 유저 208,756명 중 Main Landing Screen까지 도달한 유저는 169,396명으로, 메인 화면 진입 전환율은 81.1%였다. 그러나 Play from Recommendation까지 도달한 유저는 63,898명으로, 최종 전환율은 30.6%였다. 이는 신규 유저가 메인 화면에는 비교적 잘 진입하지만 추천 콘텐츠 재생까지 이어지는 비율은 기본 첫 재생 전환율보다 낮다는 것을 의미한다. 따라서 추천 재생은 가입 직후 바로 강하게 유도하기보다는, 첫 재생과 즐겨찾기 이후 취향 데이터가 쌓인 시점에 제안하는 방식이 더 적절하다고 생각했다.

신규 유저 행동 경로 확인

퍼널 분석은 사전에 정의한 경로를 기준으로 전환율을 확인하는 방식이다. 하지만 실제 신규 유저가 어떤 순서로 행동했는지는 퍼널만으로 완전히 알기 어렵다. 그래서 Journeys 차트를 활용해 신규 유저의 실제 행동 경로를 추가로 확인하였다.

2025년 12월 신규 유저의 가장 큰 경로는 다음과 같았다.

User Sign Up → Main Landing Screen → Search Song or Video → Select Song or Video → Play Song or Video

전체 신규 유저의 10.4%가 이 경로를 따랐다. 이 결과를 통해 신규 유저가 추천 콘텐츠를 바로 소비하기보다, 검색과 선택을 거쳐 첫 재생에 도달하는 흐름이 주요하게 나타났음을 확인할 수 있었다. 또한 User Sign Up 이후 바로 Dropped Off로 이어지는 경로도 5.91%로 나타나, 가입 직후 이탈이 일부 발생하고 있다는 점도 다시 확인되었다. 즉, 신규 유저에게 추천 콘텐츠를 바로 소비하도록 유도하기보다, 메인 화면에서 검색, 선택, 재생이 자연스럽게 이어지도록 돕는 것이 중요하다고 볼 수 있었다. 그리고 가입 완료 후 메인 화면까지의 연결 과정도 간단하고 명확하게 설계할 필요가 있었다.

유입 채널별 차이 확인

다음으로 온보딩 이탈이 특정 유입 채널에 집중된 문제인지 확인하였다. User Sign Up → Main Landing Screen → Play Song or Video → Favorite Song or Video 퍼널을 Referer_Domain 기준으로 나누어 살펴보았다.

분석 결과, 유입 채널별 전환율은 전반적으로 거의 비슷한 수준이었다. Main Landing Screen 진입률은 모든 채널에서 약 81% 내외였고, Play Song or Video 전환율은 약 71%, Favorite Song or Video 전환율은 약 52% 수준으로 나타났다. 따라서 신규 유저 온보딩 문제는 특정 유입 채널에 집중된 문제라기보다, 전체 채널에서 공통적으로 나타나는 흐름으로 볼 수 있었다. 이 부분을 통해 개선 방향도 조금 더 명확해졌다. 만약 특정 채널에서만 전환율이 낮았다면 해당 채널의 광고 메시지나 랜딩 경험을 따로 점검해야 했을 것이다. 하지만 모든 채널에서 비슷한 전환율이 나타났기 때문에, 채널별 메시지를 개별적으로 최적화하기보다 가입 이후의 공통 초기 이용 흐름을 개선하는 것이 우선이라고 판단했다.

플랫폼별 차이 확인

유입 채널과 마찬가지로, 특정 플랫폼에서 온보딩 전환율이 낮게 나타나는지도 확인하였다.

동일한 퍼널을 Platform 기준으로 나누어 살펴본 결과, 주요 플랫폼인 Web, iOS, Android는 전환율 차이가 크지 않았다. Main Landing Screen 진입률은 모두 약 81% 수준이었고, Play Song or Video 전환율도 약 71% 수준으로 거의 동일했다. Favorite Song or Video 전환율 역시 51.8%~52.5% 수준으로 큰 차이가 없었다. Windows와 tvOS는 상대적으로 낮게 나타났지만, 주요 플랫폼에 비해 가입 유저 수가 적기 때문에 전체 문제로 일반화하기에는 주의가 필요하다고 보았다. 따라서 특정 플랫폼만 우선적으로 개선하기보다는, 전체 플랫폼에서 공통적으로 적용될 수 있는 온보딩 흐름을 개선하는 것이 더 적절하다고 판단했다.

Lifecycle 관점 분석

마지막으로 Lifecycle 차트를 활용해 신규 유저, 기존 유저, 재활성 유저, 휴면 유저의 흐름을 살펴보았다. 앞선 리텐션 분석에서는 유저들이 서비스에 다시 방문하고 재생 행동까지 이어지는 흐름이 비교적 안정적으로 나타났다. 다만 월별 활성 유저 수는 큰 성장세보다는 일정 범위 안에서 유지되는 모습을 보였다.

Lifecycle 차트를 확인한 결과, 매월 신규 유저와 기존 유저는 일정 규모로 유지되고 있었지만, 재활성 유저 규모는 매우 낮게 나타났다. 반면 휴면 유저는 매월 일정 규모로 발생하고 있었다. 따라서 현재 서비스는 기존 유저의 이용 흐름은 비교적 안정적이지만, 한 번 이탈한 유저를 다시 서비스로 돌아오게 만드는 재활성화 흐름에는 개선 여지가 있다고 볼 수 있었다. 다만 이번 분석의 핵심은 신규 유저 온보딩 개선이었기 때문에, 재활성화 전략은 후속 분석 과제로 두고 이번 보고서에서는 신규 유저가 첫 재생과 즐겨찾기까지 빠르게 도달하는 흐름에 집중하였다.

개선점 도출

퍼널, Journeys, 유입 채널별 차이, 플랫폼별 차이, Lifecycle 분석을 함께 살펴본 결과, 신규 유저 온보딩의 문제는 특정 채널이나 특정 플랫폼에만 집중되어 있지 않았다. 따라서 개선 방향은 특정 세그먼트를 따로 최적화하는 것보다, 전체 신규 유저가 공통적으로 경험하는 초기 이용 흐름을 개선하는 데 초점을 맞추는 것이 적절하다고 판단했다.

우선 개선 과제는 세 가지로 정리할 수 있었다.

첫째, 가입 완료 후 메인 화면 진입까지의 이탈을 줄이는 것이다.
둘째, 신규 유저가 첫 재생까지 빠르게 도달하도록 돕는 것이다.
셋째, 첫 재생 이후 즐겨찾기 행동까지 자연스럽게 이어지도록 유도하는 것이다.

개선 방안 1: 가입 직후 메인 화면 진입 이탈 줄이기

첫 번째 개선 방안은 가입 완료 후 메인 화면까지의 진입 이탈을 줄이는 것이다. 퍼널 분석과 Journeys 분석에서 모두 가입 직후 일부 유저가 메인 화면이나 첫 재생까지 도달하지 못하고 이탈하는 흐름이 확인되었다. 특히 User Sign Up → Main Landing Screen 구간에서 약 18.9%의 이탈이 발생했기 때문에, 이 구간은 우선적으로 개선해야 한다고 생각했다. 가입 완료 직후에는 복잡한 설정이나 과도한 안내를 제공하기보다, 유저가 바로 음악을 탐색하고 재생할 수 있는 화면으로 자연스럽게 연결하는 것이 중요하다. 예를 들어 관심 장르 선택, 알림 권한 요청, 프로필 설정 같은 과정은 한 번에 모두 요구하기보다 최소한의 단계로 줄이고, 필요한 시점에 순차적으로 안내하는 방식이 더 적절할 수 있다. 가입 직후의 목표는 많은 기능을 설명하는 것이 아니라, 유저가 최대한 빠르게 첫 재생까지 도달하도록 돕는 것이기 때문이다.

개선 방안 2: 첫 재생과 즐겨찾기까지의 흐름 강화하기

두 번째 개선 방안은 신규 유저가 첫 재생 이후 즐겨찾기 행동까지 자연스럽게 이어지도록 만드는 것이다. 분석 결과 Play Song or Video는 1차 아하 모먼트로 볼 수 있었고, Favorite Song or Video는 유저의 취향이 서비스 안에 남는 Lock-in 행동 후보로 나타났다. 따라서 온보딩 초반에는 신규 유저가 콘텐츠를 재생하는 데서 끝나지 않고, 마음에 드는 콘텐츠를 저장하는 경험까지 이어지도록 유도할 필요가 있다. 예를 들어 첫 재생 이후 '이 곡이 마음에 들면 보관함에 저장해보세요'와 같은 가벼운 안내를 제공하거나, 하트 버튼을 더 눈에 잘 띄는 위치에 배치하는 방식을 고려할 수 있다. 즐겨찾기 행동은 유저에게는 다시 듣고 싶은 콘텐츠를 저장하는 행동이고, 서비스에게는 취향 데이터를 확보하는 행동이다. 따라서 개인화 추천과 재방문 유도를 위해 온보딩 단계에서 우선적으로 강화할 필요가 있다고 생각했다.

개선 방안 3: 추천 재생과 플레이리스트 팔로우를 후속 행동으로 유도하기

세 번째 개선 방안은 추천 재생과 플레이리스트 팔로우를 첫 이용 단계에서 바로 요구하기보다, 첫 재생과 즐겨찾기 이후의 후속 행동으로 설계하는 것이다. 분석 결과 Play from Recommendation과 Follow Playlist는 기본 재생이나 즐겨찾기에 비해 전환율이 낮았다. 또한 Journeys 분석에서도 신규 유저는 추천 콘텐츠를 바로 소비하기보다 검색과 선택을 거쳐 첫 재생에 도달하는 흐름이 주요하게 나타났다. 따라서 온보딩 초반에는 추천 재생이나 플레이리스트 팔로우를 강하게 유도하기보다, 유저가 먼저 콘텐츠를 재생하고 즐겨찾기하도록 만든 뒤 그 행동을 바탕으로 추천을 제공하는 흐름이 더 자연스럽다고 판단했다. 예를 들어 유저가 특정 장르의 곡을 재생하거나 즐겨찾기하면, '비슷한 곡을 더 들어볼까요?' 또는 '이 곡이 포함된 플레이리스트를 팔로우해보세요'처럼 맥락 있는 추천을 제공할 수 있다. 이렇게 하면 추천 기능이나 플레이리스트 팔로우가 갑자기 등장하는 기능이 아니라, 유저의 행동과 연결된 자연스러운 다음 단계가 될 수 있다.

이번 스프린트 미션에서 남은 것

이번 미션은 Amplitude를 활용해 실제 서비스 분석 흐름을 연습해볼 수 있었던 미션이었다. 처음에는 차트 종류가 많아서 어떤 차트를 어디에 써야 할지 조금 헷갈렸다. 하지만 분석 질문을 먼저 정하고 나니 어떤 차트를 봐야 하는지도 조금씩 정리되었다.

특히 이번에 새롭게 인상 깊었던 것은 Engagement Matrix와 Journeys 차트였다. Engagement Matrix를 통해 단순히 이벤트 발생 수만 보는 것이 아니라, 얼마나 많은 유저가 해당 행동을 하는지와 얼마나 자주 반복하는지를 함께 볼 수 있었다. 덕분에 어떤 행동이 단순히 많이 발생하는 행동인지, 아니면 유저의 반복 이용과 연결될 수 있는 행동인지 더 구조적으로 볼 수 있었다. Journeys 차트도 유용했다. 퍼널 분석은 내가 미리 정한 경로를 기준으로 전환율을 확인하는 방식이라면, Journeys는 실제 유저들이 어떤 순서로 행동했는지를 보여주기 때문에 예상과 다른 흐름을 발견하는 데 도움이 되었다. 이번 분석에서도 신규 유저가 추천 콘텐츠를 바로 소비하기보다 검색과 선택을 거쳐 첫 재생에 도달하는 흐름이 주요하게 나타났고, 이를 통해 온보딩 개선 방향을 더 구체적으로 잡을 수 있었다.

이번 미션 분석 결과, 서비스는 기본적인 방문, 탐색, 재생, 재방문 흐름이 비교적 안정적으로 작동하고 있었다. 월별 활성 유저 수는 일정 범위 안에서 유지되고 있었고, 재방문한 유저가 실제 콘텐츠 재생까지 이어지는 흐름도 자연스럽게 나타났다. 다만 신규 유저 온보딩에서는 가입 직후 메인 화면 진입 구간과 첫 재생 이후 Lock-in 행동으로 이어지는 구간에 개선 여지가 있었다. 신규 유저는 첫 재생과 즐겨찾기처럼 가벼운 행동까지는 비교적 자연스럽게 이어졌지만, 추천 재생이나 플레이리스트 팔로우처럼 서비스에 대한 신뢰와 관심이 더 필요한 행동까지는 바로 이어지지 않았다. 따라서 온보딩의 핵심 방향은 처음부터 많은 기능을 안내하는 것이 아니라, 신규 유저가 서비스의 핵심 가치인 콘텐츠 재생을 빠르게 경험하고, 마음에 드는 콘텐츠를 저장하면서 서비스 안에 자신의 취향을 남기도록 돕는 것이라고 정리할 수 있었다.

이번 미션은 Amplitude에서 배운 차트들을 실제 분석 흐름 안에서 연결해볼 수 있었다는 점에서 의미가 있었다. 특히 서비스 현황 파악에서 끝나는 것이 아니라, 신규 유저 온보딩 개선이라는 구체적인 문제로 이어가면서 분석 결과를 실제 개선 방안으로 연결해보는 연습을 할 수 있었다.

A/B 테스트 | 기본 통계 개념, 가설 검정, A/B 테스트 프로세스 전체 정리

자유를원해 — Wed, 13 May 2026 21:50:23 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

A/B 테스트를 위한 통계 기초와 실험 프로세스 전체 정리

이번 시간에는 성공적인 프로덕트 개선의 핵심인 A/B 테스트와 이를 뒷받침하는 기본 통계 이론을 학습하였다. 직감이나 경험에 의존하는 대신, 실제 유저 데이터를 기반으로 의사결정을 내리기 위해서는 기술 통계와 추론 통계의 개념, 가설 검정, 그리고 체계적인 A/B 테스트 설계 프로세스를 이해해야 한다. 이번 글에서는 통계의 기본 개념부터 시작해 표본 추출, 중심극한정리, 가설 검정의 오류, 그리고 실제 실무에서 적용되는 A/B 테스트의 7단계 프로세스와 지표 설계 방법까지 상세히 정리해 보려고 한다.

기본 통계 개념

1️⃣ 통계의 두 가지 종류

통계는 데이터를 다루는 목적에 따라 크게 기술 통계와 추론 통계로 나뉜다.

기술 통계(Descriptive Statistics): 수집된 데이터를 요약하고 설명하는 통계 기법이다. 평균, 최댓값, 표준편차 등을 이용해 자료의 전반적인 특성을 수치나 그래프로 기술한다.
추론 통계(Inferential Statistics): 수집된 데이터(표본)를 분석하여, 관찰하지 못한 전체 집단(모집단)의 특성을 유추하는 기법이다. 주로 추정(Estimation)과 검정(Testing)을 통해 이루어진다.

2️⃣ 일상생활 속 추론 통계의 비유: 김치찌개?

전체 집단을 모두 조사하는 전수 조사는 시간과 비용이 막대하게 소모되거나 현실적으로 불가능한 경우가 많다. 따라서 우리는 일부 표본을 통해 모집단을 추론한다. 이는 일상에서 김치찌개를 요리할 때 간을 보는 과정과 일치한다.

김치찌개 국물 한 수저: 표본 조사 (Sample Survey)
전체 찌개 맛을 유추 및 평가: 추론 통계 (Inferential Statistics)
표본 조사를 하는 이유: 찌개 전체를 다 먹어봐야 맛을 알 수 있다면, 요리의 목적을 달성할 수 없으며 비용(시간과 노력)이 너무 많이 든다.
표본 추출 시 유의점: 간을 보기 전 찌개를 골고루 잘 섞어야 한다. 즉, 특정 부분의 맛만 보지 않도록 무작위 표본 추출(Random Sampling)이 필수적이다. 이는 추후 A/B 테스트에서 유저를 무작위로 배정해야 하는 이유와 같다.

3️⃣ 모집단과 표본

통계를 정확히 다루기 위해서는 집단과 수치를 나타내는 용어를 명확히 구분해야 한다.

구분	집단 / 수치	설명	기호 및 예시
모집단 (Population)	집단	관찰하고자 하는 대상의 전체 집단	전수 조사 (예: 선거 투표 결과)
모수 (Parameter)	수치	모집단 전체의 특성을 나타내는 요약 값	(모평균), (모표준편차), (모비율)
표본 (Sample)	집단	모집단을 대표하기 위해 추출된 일부 집단	표본 조사 (예: 투표 출구 조사)
통계량 (Statistic)	수치	표본 데이터로부터 계산된 요약 값	x̄(표본평균), (표본표준편차), ̂(표본비율)

4️⃣ 표본 추출 방법 (Sampling)

표본을 추출하는 방식은 개체가 선택될 확률이 동일한지에 따라 확률 표본 추출과 비확률 표본 추출로 나뉜다.

확률 표본 추출 (Probability Sampling)

모집단의 각 개체가 선택될 확률이 동일하게 보장되는 추출 방식이다.

단순 임의 추출(Simple Random Sampling): 어떠한 인위적 개입 없이 무작위로 표본을 추출하는 방식이다. (예: 제비뽑기, 무작위 배정)
층화 임의 추출(Stratified Random Sampling): 모집단을 특정 기준에 따라 서로 겹치지 않는 층(Stratum)으로 나눈 뒤, 각 층의 비율에 맞춰 무작위로 추출한다. (집단 내 동질적, 집단 간 이질적)
체계적 추출(Systematic Sampling): 일정한 체계나 간격을 가지고 표본을 추출하는 방식이다. (예: 명부에서 매 7번째 사람을 선택)
집락 추출(Cluster Sampling): 모집단을 서로 유사한 소그룹(Cluster)으로 나눈 뒤, 무작위로 선택된 소그룹 자체를 전수 조사하거나 그 안에서 표본을 추출한다. (집단 내 이질적, 집단 간 동질적)

비확률 표본 추출 (Non-Probability Sampling)

연구자의 판단이나 편의에 따라 표본을 추출하여, 개체의 선택 확률이 동일하지 않은 방식이다.

편의 표본 추출(Convenience Sampling): 접근하기 쉽고 설문 조사가 용이한 환경에 있는 대상을 표본으로 선정한다.
판단 표본 추출(Purposive Sampling): 연구자가 모집단의 특성을 잘 반영할 것이라고 판단하는 특정 집단을 의도적으로 선정한다.
할당 표본 추출(Quota Sampling): 사전에 연령, 성별 등 집단별 목표 할당 크기를 정해두고, 그 샘플 수에 도달할 때까지만 조사를 진행한 뒤 중단한다.

5️⃣ 표본 크기(n)의 중요성

큰 수의 법칙(Law of Large Numbers): 표본의 크기 n이 커질수록 표본평균이 모집단의 모평균에 한없이 가까워진다. 따라서 표본이 많을수록 추론 통계의 신뢰도가 높아진다. (예: 10,000명 중 1명만 뽑아서 평균 키를 유추할 수 없음)
중심극한정리(Central Limit Theorem, CLT): 모집단의 데이터 분포 형태와 관계없이, 표본의 크기 n이 충분히 커질수록(보통 n ≥ 30) 추출된 표본평균들의 분포는 정규 분포에 근사하다.

면접 Tip: 강사님께서 이력서에 통계를 기재하면 단골로 나오는 질문이라고 소개해주셨다. 많은 지원자가 '표본 자체의 분포가 정규 분포가 된다'고 잘못 대답한다. 핵심은 '표본평균들의 분포(Sampling distribution of the sample mean)'가 정규 분포에 근사한다는 점이다. 면접 전 p-value와 중심극한정리의 정확한 정의는 필수로 숙지해야 한다.

6️⃣ 가설 검정 (Hypothesis Testing)

수집된 데이터를 바탕으로 세운 가설의 타당성을 통계적으로 검증하는 과정이다.

가설의 설정

귀무가설(H₀, Null Hypothesis): 대립가설과 반대되는 부정 명제로, 주로 보수적인 입장을 취한다. '차이가 없다, 효과가 없다, 동일하다'를 의미한다.
대립가설(H₁, Alternative Hypothesis): 실험을 통해 실제로 입증하고 싶은 주장이다. '차이가 있다, 효과가 있다, 동일하지 않다'를 의미한다.
왜 귀무가설을 기각하는 구조일까? 통계적 검정은 기본적으로 '변화나 차이가 없다'는 디폴트 상태(귀무가설)에서 출발하여, 이를 기각할 만한 확실하고 통계적인 증거가 발견되었을 때만 대립가설을 받아들이는 보수적인 방식을 취하기 때문이다.

양측 검정과 단측 검정

양측 검정(Two-sided Test): 방향성에 상관없이 두 집단 간에 차이가 있는지만 검정한다. (H₀: μA = μB, H₁: μA ≠ μB)
단측 검정(One-sided Test): 특정 방향(증가 또는 감소)으로 차이가 있는지를 검정한다.
- 오른쪽 단측 검정: H₁: μA > μB
- 왼쪽 단측 검정: H₁: μA < μB

p-value와 의사결정

p-value(유의확률): 귀무가설이 참이라고 가정했을 때, 관측된 데이터 이상으로 극단적인 결과가 우연히 발생할 확률이다. 즉, 실험 결과가 단순한 우연으로 발생했을 확률을 의미하므로, 이 값이 작을수록 우연이 아닐 가능성이 높다.
유의수준(α, Significance Level): 귀무가설을 기각하기 위한 판단 기준선으로, 일반적으로 5%(0.05)를 사용한다.
판단 기준:
- p-value < α: 귀무가설 기각 (Reject H₀) → 대립가설 채택 (통계적으로 유의미한 차이가 있음)
- p-value ≥ α : 귀무가설 기각 실패 → 차이가 있다고 볼 수 없음

결과 해석 시 주의점: 귀무가설을 기각했다고 해서 대립가설이 100% 진실이라고 확정 짓는 것은 아니다. 엄밀한 통계적 표현으로는 '유의수준 5% 하에서 귀무가설을 기각할 만한 통계적으로 충분한 근거가 있다'와 같이 확률적으로 서술해야 한다.

7️⃣ 가설 검정의 오류

검정 과정에서는 불가피하게 두 가지 종류의 오류가 발생할 수 있다.

데이터의 진실 \ 판단	귀무가설 기각 안 함 (H₀ 유지)	귀무가설 기각 (H₁ 채택)
H₀가 참 (차이 없음)	올바른 결정	제1종 오류 (α)
H₀가 거짓 (차이 있음)	제2종 오류 (β)	올바른 결정 (검정력, β)

제1종 오류(α): 실제로는 차이가 없는데(H₀ 참), 차이가 있다고 잘못 판단하는 오류다. 유의수준 α는 이 제1종 오류를 허용할 최대 확률을 의미한다.
제2종 오류(β): 실제로는 차이가 있는데(H₀ 거짓), 차이가 없다고 놓치는 오류다.
검정력(Power, β): 실제로 효과가 있는 것을 효과가 있다고 올바르게 잡아낼 확률이다. 통상적으로 실무에서는 80% 이상으로 설정한다.
오류 간의 상충 관계(Trade-off): α를 줄이려 엄격하게 기준을 잡으면 β가 증가하여 검정력이 떨어진다. 제1종 오류를 키우지 않고 검정력을 동시에 높이는 유일한 방법은 표본의 크기 n를 늘리는 것이다.

8️⃣ 신뢰 구간 (Confidence Interval, CI)

모수가 특정 범위 안에 존재할 것이라고 예측되는 구간을 특정 확률(신뢰수준)로 나타낸 것이다.

95% 신뢰수준의 의미: 동일한 방식으로 표본을 추출하여 신뢰구간을 100번 생성했을 때, 실제 모집단의 모수가 그 구간 안에 포함되는 횟수가 95번이라는 뜻이다.
일상 예시: 친구에게 '10분에서 20분 정도 늦을 것 같다'고 말할 때, 100번 중 95번은 실제 늦는 시간이 이 범위 내에 포함된다면 95% 신뢰구간이라 볼 수 있다.
선거 여론조사 예시: A 후보 지지율 49%, B 후보 45%이고 표본오차가 ±3%p라면, A의 구간(46~52%)과 B의 구간(42~48%)이 겹치게 된다. 따라서 단순 수치가 높다고 당선을 확정적으로 단정 지을 수 없다.

면접 Tip: 이것도 강사님께서 직접 받은 질문이라 하셨다. 정답이 없는 열린 질문이나 통계적 딜레마 상황(예: '신기술 도입 시 비용은 비싸고 편익이 적다면?')에서는 단답형(O/X)으로 답하기보다, 가설을 점검하고 여러 옵션을 탐색하는 열린 답변을 제시하는 것이 합격률을 높이는 방법이다.

A/B 테스트 (A/B Test)

1️⃣ 성공하는 서비스들의 공통점과 A/B 테스트

성공하는 IT 프로덕트들은 기획자의 직감이 아닌 데이터 기반 의사결정(Data-driven Decision)을 내린다. 새로운 기능을 출시하기 전 실험을 통해 유저의 실제 반응을 파악하고 실패 리스크를 최소화한다.

A/B 테스트란? 기존 안(A안, 대조군)과 개선 안(B안, 실험군)을 유저에게 무작위로 노출하여 어떤 버전이 더 나은 성과를 내는지 정량적으로 비교하는 무작위 대조 실험(Randomized Controlled Trial)이다.
상관과 인과: 상관관계(Correlation)는 단순한 동시 변화 경향성일 뿐, 원인과 결과(Causation)를 보장하지 않는다. A/B 테스트는 유일하게 변화를 준 요인 외의 모든 외부 변수를 통제하므로 인과관계를 추정하는 가장 확실한 방법론이다.

2️⃣ 대조군과 실험군

대조군(Control Group): 기존의 UI나 로직을 유지하는 비교 기준 그룹 (A안)
실험군(Treatment Group): 새로운 변화(독립변수)를 적용하여 효과를 검증하려는 타깃 그룹 (B안)

3️⃣ 올바른 실험을 위한 조건

실험 결과를 신뢰하기 위해서는 테스트 요인 외의 모든 교란 요인(Confounding Factor)을 철저히 통제해야 한다.

동일 시점 진행: 계절성, 요일 효과, 외부 마케팅 프로모션 등의 영향을 통제하기 위해 반드시 동시간대에 테스트를 진행한다.
동질적인 유저 집단: 무작위 할당을 통해 성별, 디바이스, 유입 경로 등 집단 간 특성이 균등하게 분배되도록 맞춰야 한다.

4️⃣ 샘플 사이즈 계산하기 (Sample Size Calculation)

실험을 시작하기 전, 신뢰할 수 있는 통계적 결론을 내리기 위해 사전에 필요한 유저 수와 실험 기간을 계산해야 한다.

Baseline: 현재 서비스의 기준 전환율
MDE(Minimum Detectable Effect, 최소 탐지 효과): 비즈니스적으로 의미가 있다고 판단되는 최소한의 개선 목표치.
계산 예시 주의점: 기존 전환율이 3%이고 계산기를 통해 도출된 MDE가 32.17%라면, 목표 전환율은 3% + 32.17% = 35.17%가 아니다. MDE는 보통 상대적 개선율을 의미하므로, 3 * 1.3217 = 3.96%가 최종 도달해야 할 타깃 전환율이 된다. (만약 단순 덧셈이 성립하려면 단위가 %p여야 함)
결과 활용: 계산기가 산출한 Variation 수치(예: 변인당 4,998명 → 총 9,996명)와 일 평균 방문자 수를 바탕으로 필요한 최소 실험 기간(Required Duration)을 설정한다.

샘플 사이즈 계산기 예시: https://www.abtasty.com/sample-size-calculator/

Sample Size Calculator

Calculate your confidence interval, how long your test should run, and the sample size needed to maintain accuracy, with our ab test calculator!

www.abtasty.com

5️⃣ 좋은 지표와 우선순위 설정

좋은 지표의 조건: 단기간에 측정이 가능하고, 개선 변화에 민감하게 반응하며, 궁극적인 비즈니스 목표와 정렬되어 있어야 한다.
ICE Score 프레임워크: 한정된 리소스에서 어떤 실험을 먼저 할지 결정하는 우선순위 평가 척도다.
ICE Score = Impact(영향도) x Confidence(확신도) x Ease(용이성)

✨A/B 테스트 프로세스 전체 정리

실제 실무에서 진행되는 A/B 테스트는 체계적인 7단계 사이클을 따른다.

목표 설정 → 가설 설정 → A/B 그룹 생성 → 실험 설계 → 실험 진행 → 데이터 분석 → 결론 도출 ( → 반복)

Step 1. 목표 설정 (Goal Setting)

하나의 실험에서는 결과 해석의 혼선을 막기 위해 단 하나의 명확한 목표만 수립한다. (정성적 목표 구체화 및 정량적 수치화)

Step 2. 문제 및 가설 설정 (Problem & Hypothesis)

프로덕트의 현재 상태와 이상적인 목표 간의 간극(Gap)을 문제로 정의하고, 이를 해결할 변경 대상을 설정한다.

가설 작성: '상품을 판매 수량 순으로 보여주면(원인), 노출 대비 구매 전환율이 증가할 것이다(결과).'
주의점: 원인 분석을 명확히 하기 위해 하나의 실험에서는 단 하나의 요소만 변경해야 하며, 지표 변화를 감지할 수 있도록 유저 경험에 큰 임팩트를 주는 요소를 타깃으로 삼아야 한다.

Step 3. 지표 및 로그 정의 (Metrics & Logging Setup)

실험의 성과를 판단할 다각도의 지표를 설계한다.

성공 지표(Primary Metric): 가설 검증의 핵심이 되는 메인 지표 (예: 구매 전환율)
보조 지표(Secondary Metric): 성공 지표를 보완하고 다면적 이해를 돕는 지표 (예: 장바구니 담기율)
가드레일 지표(Guardrail Metric): 실험 성공 여부와 관계없이 절대 훼손되어서는 안 되는 방어 지표 (예: 환불 비율, 에러 발생 건수). 성공 지표가 올라도 가드레일 지표가 무너지면 실패한 실험이다.
로그 설계: 유저 행동을 트래킹하기 위한 데이터 구조를 정의한다. (예: Timestamp | User_ID | Page_Location | Action_Type)

Step 4. 샘플 설정 (Sampling & Allocation)

무작위 할당(Random assignment) 등을 통해 대조군과 실험군으로 유저 트래픽을 균등하게 분할한다.

샘플: 실험 대상으로 선택된 사용자들
샘플링: 전체 서비스 이용자 중에서 일부 사용자를 선택하는 과정
샘플 사이즈 : 전체 모집단을 대표할 수 있는 충분한 규모의 데이터 수
대표적인 샘플링 방법
1. 무작위 할당: 어떠한 특정한 기준 없이 무작위로 배정하는 것
2. 계층적 샘플링: 모집단을 여러 집단으로 나눈 다음, 각 그룹에서 무작위로 샘플을 추출하는 방식
3. 클러스터 샘플링: 모집단을 여러 개의 클러스터로 나눈 다음, 몇 개의 클러스터를 무작위로 선택하는 방식

Step 5. 실험 진행 (Experiment Execution)

정해진 기간 동안 실험을 배포하고 모니터링한다.

첫째, 사용자 로그 분석을 통해 사용자가 중복 참여하지 않도록 한다.
둘째, 내부 직원들의 데이터는 필터링한다.
셋째, 실험 다음 날에 사전에 정의한대로 데이터가 잘 수집되어 있는지 데이터를 추출한다.
넷째, 사전에 계획한대로 실험을 진행하기 위해 성공 지표를 중간에 변경하지 않는다.
다섯째, 가드레일 지표에 심각한 영향이 있다면 실험을 중단한다.
여섯째, 샘플 사이즈가 충족되지 않는다면, 실험 기간을 늘리거나 성공 지표 대신에 보조 지표를 활용한다.

Step 6. 데이터 분석 및 결론 도출 (Analysis & Conclusion)

수집된 데이터를 바탕으로 통계 검정을 수행한다.

판단 로직: B안의 성과 수치가 A안보다 높고, 계산된 p-value가 유의수준 0.05보다 작으면 최종적으로 개선안을 실제 서비스에 반영(Apply)한다. 그렇지 않다면 기존 안으로 롤백(Rollback)한다.

Step 7. 반복 (Iteration)

성공과 실패 여부에 관계없이 실험을 통해 얻은 인사이트를 바탕으로 다음 가설을 수립하고 테스트를 반복하며 프로덕트를 고도화한다.

⚠️ 실험 결과 해석 시 주의사항 및 한계점

1️⃣ 시간 흐름에 따른 심리적 왜곡 효과

초두 효과(Primacy Effect): 기존 유저들이 익숙한 A안을 맹목적으로 선호하여, 더 나은 B안에 대해 초기에 거부감을 나타내는 현상.
신기 효과(Novelty Effect): 기능 개선 때문이 아니라, 단순히 새로워진 디자인에 대한 일시적 호기심으로 B안의 클릭률이 초기에 튀는 현상.
두 효과는 모두 충분한 실험 기간을 확보하여 데이터가 안정화된 이후의 결과를 분석해야 걸러낼 수 있다.

2️⃣ 심층 분석의 필요성

전체 평균 수치가 비슷하게 나오더라도 실험을 그냥 버려서는 안 된다. 유저 세그먼트(성별, 연령, 신규/기존 등)를 세분화하여 분석하면 특정 타깃층에서 유의미한 효과를 발견할 수 있다.

3️⃣ A/B 테스트의 본질적 한계

A/B 테스트는 현재 주어진 조건 안에서 최적의 선택(Local Optimum)을 돕는 도구일 뿐, 혁신적인 신규 프로덕트를 창조하거나 장기적인 브랜딩 가치까지 완벽히 측정할 수는 없다.

마무리

이번 학습을 통해 A/B 테스트가 단순한 화면 비교를 넘어, 철저한 통계적 기반 위에서 작동하는 과학적 검증 기법임을 깨달았다. 중심극한정리와 가설 검정 로직을 통해 왜 샘플 사이즈가 중요한지, 왜 p-value를 확인해야 하는지 그 인과관계를 명확히 연결할 수 있었다. 특히 실무 프로세스에서 가장 인상 깊었던 점은 '가드레일 지표'의 존재와 '실험 도중 지표 변경 금지' 원칙이었다. 데이터를 다루는 분석가로서 단순히 수치를 올리는 것에만 매몰되지 않고, 서비스의 안정성과 전체적인 유저 경험을 보호하는 균형 잡힌 시각을 유지해야 함을 배울 수 있는 시간이었다.

[코드잇 스프린트] Weekly Paper 5 - Amplitude에서 리텐션 분석을 한다면?

자유를원해 — Tue, 12 May 2026 20:35:48 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 위클리 페이퍼 작성 기록입니다.

Q1.

Amplitude에서 리텐션 분석을 진행했더니 신규 가입자의 Day 7 리텐션이 20%로 나왔습니다. 이 수치를 어떻게 해석하겠나요? 리텐션을 개선하기 위해 다음으로 어떤 분석을 추가로 해보겠나요?

신규 가입자의 Day 7 리텐션이 20%로 나왔다는 것의 해석

Amplitude에서 신규 가입자의 Day 7 리텐션이 20%로 나왔다는 것은, 가입한 사용자 100명 중 약 20명만이 가입 후 7일째에도 다시 돌아와 특정 행동을 했다는 뜻으로 해석할 수 있다. 단순하게 말하면 초기 유입은 있었지만, 그중 상당수는 일주일 안에 빠져나갔다는 의미이다. 다만 이 숫자를 볼 때는 20%가 높다, 낮다를 단독으로 바로 판단하기보다 몇 가지를 같이 생각해야 한다.

리텐션의 기준 이벤트가 무엇인지
- 단순 앱 실행인지
- 로그인인지
- 핵심 기능 사용인지
- 구매나 콘텐츠 소비 같은 더 중요한 행동인지
에 따라 같은 20%라도 의미가 달라질 수 있다.
서비스 성격
- 매일 써야 하는 서비스인지
- 필요할 때만 쓰는 서비스인지
에 따라 기대 리텐션 수준이 다르다.
비교 기준의 존재
- 이전 주/이전 월 신규 가입자보다 나아졌는지
- 유입 채널별로 차이가 있는지
- 기기, OS, 캠페인별 차이가 있는지

도 같이 봐야 한다.

내가 이 수치를 해석할 때는, 일단신규 유저가 첫 일주일 안에 서비스에 정착하지 못하고 있을 가능성을 먼저 떠올릴 것 같다. 특히 Day 7은 단순 첫 방문을 넘어서, 사용자가 어느 정도 서비스를 다시 찾을 이유를 느꼈는지를 보여주는 지점이라고 생각한다. 그래서 20%라는 수치는 단순 재방문율이라기보다, 초기 경험이 충분히 매력적이었는가를 점검하게 만드는 숫자라고 느껴진다.

또 리텐션을 볼 때는 클래식 리텐션 / 범위 리텐션 / 롤링 리텐션을 구분하는 것도 중요하다고 생각한다.

클래식 리텐션
- 정확히 Day 7에 돌아왔는지를 본다.
- 가장 엄격한 기준이라 진짜 그날 다시 왔는가를 보는 데 적합하다.
범위 리텐션
- 예를 들어 Day 7~Day 13 사이처럼 특정 구간 안에 다시 왔는지를 본다.
- 사용 주기가 꼭 매일은 아닌 서비스라면 더 현실적인 해석이 가능하다.
롤링 리텐션
- Day 7 이후 한 번이라도 돌아왔는지를 본다.
- 유저가 완전히 떠났는지, 아니면 늦게라도 다시 돌아오는지를 보는 데 의미가 있다.

그래서 만약 내가 본 20%가 클래식 리텐션 기준이라면, 꽤 타이트한 기준에서 본 것이기 때문에 ‘정확히 7일째 다시 온 유저는 적다’는 의미로 해석할 수 있다. 반대로 롤링 리텐션 기준인데도 20%라면, 그건 더 강하게 이탈을 의심해볼 수 있다고 생각한다. 즉, 같은 20%라도 어떤 리텐션 정의로 봤는지에 따라 해석 강도가 달라진다는 것. 정리하면, 나는 이 수치를 다음처럼 해석할 것 같다.

신규 가입자 중 상당수가 첫 일주일 안에 이탈하고 있다
유저가 서비스의 핵심 가치를 빠르게 느끼지 못했을 가능성이 있다
다만 이 수치 하나만으로 판단하지 않고,리텐션 계산 방식 / 기준 이벤트 / 서비스 특성 / 비교 집단을 함께 봐야 한다

리텐션 개선을 위해 다음으로 어떤 분석을 진행하겠는가

내가 다음으로 할 분석은, 단순히 ‘리텐션이 낮다’에서 멈추지 않고 왜 7일까지 남지 못하는지 원인을 좁혀보는 분석이다. Amplitude를 쓴다는 가정이면, 리텐션 차트를 본 다음 바로 퍼널, 세그먼트 비교, 경로, 이벤트 분해 쪽으로 이어서 볼 것 같다.

1. Day 7에 남은 유저와 떠난 유저를 나눠서 비교

가장 먼저 해보고 싶은 건 리텐션된 유저와 이탈한 유저의 행동 차이 비교이다.

예를 들어

Day 7까지 남은 유저는 가입 후 어떤 이벤트를 더 많이 했는지
반대로 떠난 유저는 어떤 단계까지만 하고 멈췄는지
가입 첫날 또는 첫 3일 안에 특정 행동 여부가 리텐션과 연결되는지

이걸 보면 리텐션을 만드는 핵심 행동을 찾을 수 있을 것 같다. 만약 쇼핑몰이라면

회원가입만 하고 끝난 유저
상품 조회까지만 한 유저
장바구니까지 간 유저
첫 구매를 한 유저

이런 식으로 나눠봤을 때, 어떤 행동을 한 유저가 Day 7에 더 잘 남는지 확인할 수 있다. Amplitude에서는 이런 식으로 세그먼트별 비교를 하기 좋기 때문에 단순 평균 리텐션보다 더 실질적인 인사이트가 나올 것 같다.

2. 리텐션 전에 먼저 초기 퍼널이 무너지는지 보기

리텐션 문제라고 해서 꼭 리텐션 차트만 더 보는 건 아니라고 생각한다. 실제로는 초기 온보딩이나 핵심 기능 진입 퍼널이 무너져서, 그 결과로 리텐션이 낮게 나올 수도 있기 때문이다. 그래서 가입 직후 핵심 행동까지 가는 퍼널도 같이 볼 것 같다.

예를 들면

회원가입
관심 상품 조회
찜/장바구니 추가
첫 구매 또는 핵심 기능 사용

이 퍼널을 보면, 애초에 유저가 서비스의 핵심 가치를 경험하기도 전에 빠지는지 알 수 있다. 즉, Day 7 리텐션이 낮은 게 단순 ‘재방문 의지 부족’의 문제가 아니라, 처음부터 서비스 경험이 충분히 형성되지 않았기 때문일 수도 있다는 것이다.

3. 경로 분석 → 남는 유저와 떠나는 유저 흐름 차이 보기

Amplitude를 쓴다면 Pathfinder 같은 경로 분석도 해보고 싶다. 이건 사용자가 특정 이벤트 이후 어떤 흐름으로 움직였는지 보기에 좋아서, 리텐션된 유저는 어떤 경로를 거쳤고, 이탈한 유저는 어디서 끊겼는지를 보기 좋다고 생각한다.

예를 들면

남은 유저는 가입 후 검색 → 상세 조회 → 찜 → 재방문 흐름을 보이는지
떠난 유저는 가입 후 홈만 보고 종료하는지
특정 화면이나 특정 이벤트 이후 급격한 이탈이 생기는지

이런 걸 보면 ‘유저가 남게 만드는 경로’와 ‘유저가 사라지는 경로’를 비교할 수 있다. 나는 리텐션 개선에서 이 부분이 꽤 중요하다고 생각하는데, 단순히 어떤 이벤트를 했느냐보다 어떤 순서와 맥락으로 행동했는지도 중요하기 때문이다.

4. 사용자 특성별로 리텐션 쪼개서 보기

평균 Day 7 리텐션 20%만 보면 다 똑같이 낮은 것처럼 보일 수 있지만, 실제로는 특정 집단만 유독 낮을 수도 있다. 그래서 다음으로는 세그먼트를 쪼개서 리텐션을 다시 확인할 것 같다.

예를 들면

광고 유입 vs 자연 유입
안드로이드 vs iOS
신규 가입 경로별
첫 구매 유저 vs 비구매 유저
특정 기능 사용 유저 vs 미사용 유저

이렇게 나눠보면 ‘전체 평균 20%’ 뒤에 숨어 있는 차이를 발견할 수 있다. 예를 들어 자연 유입 유저는 30%인데 광고 유입 유저는 10%라면, 리텐션 문제라기보다 유입 품질 문제일 수도 있다. 이 경우엔 앱 내부 개선만이 아니라 마케팅 타겟팅도 같이 손봐야 한다.

Amplitude로 하는 프로덕트 데이터 분석 | 주요 차트와 사용자 행동 분석 실습 전체 정리

자유를원해 — Fri, 8 May 2026 19:18:21 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

Amplitude 기초 개념과 주요 차트 정리

이번 시간에는 Amplitude라는 프로덕트 분석 도구를 중심으로, 사용자 행동 데이터를 어떻게 수집하고 분석하는지, 그리고 Amplitude에서 제공하는 주요 차트들이 각각 어떤 분석 목적을 가지는지 학습하였다. Amplitude는 단순히 데이터를 보여주는 도구라기보다는 사용자가 서비스 안에서 어떤 행동을 하는지 이벤트 단위로 기록하고, 그 행동 흐름을 바탕으로 프로덕트 개선에 필요한 인사이트를 찾을 수 있도록 도와주는 도구이다. 이번 글에서는 Amplitude의 기본 개념부터 시작해서 Segmentation, Funnel, Journeys, Data Table, Sessions, Retention, Stickiness, Lifecycle 차트의 개념과 실습 내용을 정리해보려고 한다.

Amplitude란?

Amplitude는 사용자 행동 데이터를 기반으로 프로덕트의 성과를 분석하고, 개선을 위한 인사이트를 도출하는 프로덕트 분석 도구이다.

Amplitude 화면

웹이나 앱 같은 프로덕트에서는 사용자가 다양한 행동을 한다. 예를 들어 쇼핑몰 앱이라면 사용자는 상품을 조회하고, 장바구니에 담고, 쿠폰을 적용하고, 결제를 완료하는 행동을 할 수 있다. Amplitude는 이러한 행동들을 이벤트(Event) 단위로 기록하고, 이를 다양한 분석 기능을 통해 해석할 수 있도록 지원한다. 즉, Amplitude는 사용자의 행동을 데이터로 남기고, 그 데이터를 바탕으로 서비스의 문제점이나 개선 포인트를 찾는 데 활용된다. 예를 들어 Amplitude를 활용하면 다음과 같은 질문에 답할 수 있다.

방문자 수는 얼마나 되는가?
특정 기능은 얼마나 사용되는가?
구매 전환율은 어느 정도인가?
특정 단계에서 사용자가 많이 이탈하는가?
신규 유저가 이후에도 다시 서비스를 사용하는가?

이처럼 Amplitude는 사용자가 서비스 안에서 어떤 행동을 했는지를 중심으로 데이터를 분석하는 도구라고 할 수 있다.

Amplitude의 핵심 특징

Amplitude의 핵심 특징은 다음과 같다.

첫째, 사용자 행동(Event)을 중심으로 데이터를 수집하고 분석할 수 있다. Amplitude에서 가장 중요한 단위는 이벤트이다. 이벤트는 사용자가 서비스 안에서 수행한 행동을 의미한다. 예를 들어 회원가입, 로그인, 상품 상세 페이지 조회, 장바구니 추가, 구매 완료 등이 모두 이벤트가 될 수 있다.

둘째, 주요 핵심 지표를 시각화하여 직관적으로 이해할 수 있도록 지원한다. 유저 수, 전환율, 총 이벤트 수, 평균 행동 횟수 등 다양한 지표를 차트로 확인할 수 있다. 단순히 숫자만 보는 것이 아니라, 시간 흐름에 따른 변화나 그룹 간 차이를 시각적으로 볼 수 있기 때문에 분석 결과를 이해하기 쉽다.

셋째, 별도의 코딩 없이도 UI 기반으로 다양한 데이터 분석을 수행할 수 있다. Amplitude는 분석 도구 안에서 이벤트를 선택하고, 필터를 걸고, 그룹화 기준을 지정하는 방식으로 분석을 진행할 수 있다. 따라서 매번 SQL이나 Python 코드를 작성하지 않아도 원하는 지표를 빠르게 확인할 수 있다.

넷째, Segmentation, Funnel, Journeys와 같은 기능을 통해 다양한 관점에서 사용자 행동을 분석할 수 있다. 사용자 수나 이벤트 수를 비교할 수도 있고, 특정 행동 흐름에서 전환율을 볼 수도 있으며, 사용자가 실제로 어떤 경로를 따라 이동했는지도 확인할 수 있다.

Amplitude를 사용하는 역할

Amplitude는 사용하는 사람의 역할에 따라 다르게 활용된다.

1️⃣데이터 구현자

데이터 구현자는 로그 데이터가 잘 수집될 수 있도록 이벤트를 설계하고, 웹이나 앱에서 발생한 사용자 행동 데이터를 Amplitude로 전송하는 역할을 한다. 예를 들어 사용자가 구매 완료 버튼을 눌렀을 때 Complete Purchase 이벤트가 Amplitude로 전송되도록 구현하는 사람이 데이터 구현자에 해당한다.

2️⃣데이터 관리자

데이터 관리자는 수집되는 데이터의 체계와 일관성을 관리하는 역할을 한다. 이벤트 이름이 제각각이면 분석이 어려워지기 때문에, 어떤 이벤트를 어떤 이름으로 기록할지, 어떤 속성을 함께 보낼지 등을 관리해야 한다. 예를 들어 purchase_complete, complete_purchase, Complete Purchase가 모두 같은 의미로 사용되면 데이터가 흩어질 수 있기 때문에, 이를 일관되게 관리하는 것이 중요하다.

3️⃣데이터 소비자

데이터 소비자는 수집된 데이터를 활용하여 분석을 수행하는 사람이다. 데이터 분석가, PM, 마케터 등이 여기에 해당할 수 있다. 이번 수업에서는 데이터 소비자의 관점으로 Amplitude를 사용하였다. 즉, 직접 로그를 구현하기보다는 이미 수집된 데이터를 바탕으로 차트를 만들고, 지표를 해석하는 관점에서 학습하였다.

Amplitude 기본 화면 구성

Amplitude 회원가입

Amplitude를 사용하려면 먼저 회원가입을 진행하면 된다. Amplitude 화면에서는 다양한 메뉴를 통해 차트를 만들고, 최근에 본 콘텐츠를 확인하고, 즐겨찾기를 관리하고, 분석 결과를 저장할 수 있다. 주요 메뉴는 다음과 같다.

메뉴	설명
Create	차트 및 분석을 시작하는 공간
Recent	최근 조회한 콘텐츠를 확인하는 공간
Favorites	즐겨찾기한 콘텐츠를 모아보는 공간
Spaces	콘텐츠를 저장하고 관리하는 공간

Amplitude 기본 작업 화면

Amplitude에서 차트를 만들 때 화면의 왼쪽 또는 회색 영역은 컨트롤 패널이라고 볼 수 있다. 이곳에서 이벤트, 집계 방식, 세그먼트, 필터, 그룹화 기준 등을 설정한다. 오른쪽에는 설정한 조건에 따라 차트가 시각화된다. Amplitude에서 지표를 만들 때 중요한 구조는 다음과 같다.

지표(Metrics) = 이벤트(Events) + 집계 방식(Measured as)

이벤트는 사용자가 서비스 내에서 수행한 행동이고, 집계 방식은 그 행동을 어떤 기준으로 계산할 것인지를 의미한다. 예를 들어 Complete Purchase라는 이벤트가 있다고 할 때, 이를 고유 유저 수로 볼 수도 있고, 총 발생 횟수로 볼 수도 있고, 평균 횟수로 볼 수도 있다. 이처럼 같은 이벤트라도 어떤 집계 방식을 선택하느냐에 따라 분석 결과가 달라진다. 단, Events or Metrics에서 Metrics를 선택하게 되면 Measured as 영역은 사라진다. 이는 이미 정의된 지표를 사용하는 것이기 때문에 별도로 집계 방식을 설정하지 않는 구조라고 이해할 수 있다.

차트란?

차트란 복잡한 수치를 쉽게 이해하고 분석할 수 있도록 데이터를 시각적으로 표현하는 방법이다. 데이터를 표나 숫자로만 보면 전체 흐름을 파악하기 어려울 수 있다. 하지만 차트를 사용하면 시간에 따른 변화, 그룹 간 차이, 비율, 분포 등을 더 직관적으로 이해할 수 있다. Amplitude에서는 분석 목적에 따라 다양한 차트를 제공한다. 대표적으로 다음과 같은 차트들이 있다.

Segmentation 차트
Funnel 차트
Journeys 차트
Data Table 차트
Sessions 차트
Retention 차트
Stickiness 차트
Lifecycle 차트

각 차트는 분석 목적이 다르기 때문에, 어떤 질문에 답하고 싶은지에 따라 적절한 차트를 선택하는 것이 중요하다.

Segmentation 차트

1️⃣Segmentation 차트란?

Segmentation 차트는 조건에 따라 사용자 또는 이벤트를 나누고, 지표를 비교 분석하는 차트이다. 시간의 흐름에 따른 변화나 그룹 간 차이를 파악하는 데 활용된다. 예를 들어 국가별 구매 유저 수, 브랜드별 상품 조회수, 프로모션별 구매 완료자 수 등을 비교할 때 사용할 수 있다. Segmentation 차트는 Amplitude에서 가장 기본적으로 많이 사용하는 차트 중 하나라고 볼 수 있다. 특정 이벤트가 얼마나 발생했는지, 얼마나 많은 유저가 수행했는지, 어떤 그룹에서 많이 발생했는지 등을 확인할 수 있다.

2️⃣Events: 이벤트 조건 설정하기

Segmentation 차트에서 Events 영역은 분석할 이벤트를 설정하는 곳이다.

Events 영역

예를 들어 구매 완료 유저 수를 보고 싶다면 Complete Purchase 이벤트를 선택하고, 장바구니 추가 수를 보고 싶다면 Add to Cart 이벤트를 선택한다. Events 영역에서는 이벤트에 대해 추가 조건을 설정할 수 있다.

Filter by

Filter by는 이벤트에 대한 속성을 기준으로 필터링하는 기능이다. 예를 들어 구매 완료 이벤트 중에서도 무료 배송 코드를 적용한 구매만 보고 싶다면, 이벤트에 Promo Code Applied = Free Shipping 조건을 걸 수 있다. 즉, Filter by는 '어떤 조건을 만족하는 이벤트만 볼 것인가?'를 설정하는 기능이다.

Group by

Group by는 이벤트를 특정 속성 기준으로 나누어 분석하는 기능이다. 예를 들어 구매 완료 이벤트를 프로모션 코드별로 보고 싶다면 Promo Code Applied를 기준으로 Group by를 설정할 수 있다. 브랜드별 상품 상세 조회수를 보고 싶다면 brand를 기준으로 Group by를 설정할 수 있다. 즉, Group by는 '어떤 기준으로 나누어 비교할 것인가?'를 설정하는 기능이다.

3️⃣Measured as: 집계 방식 선택하기

Measured as는 선택한 이벤트를 어떤 방식으로 집계할 것인지 설정하는 영역이다.

Measured as 영역

Uniques

Uniques는 선택한 이벤트를 수행한 고유 유저 수를 의미한다. Segmentation 차트의 기본값이다. 예를 들어 Complete Purchase 이벤트를 선택하고 Measured as를 Uniques로 설정하면, 구매 완료 이벤트를 한 번 이상 수행한 유저 수를 볼 수 있다.

Events Totals

Events Totals는 선택한 이벤트가 발생한 총 횟수를 의미한다.

예를 들어 한 명의 유저가 구매를 3번 했다면, Uniques에서는 1명으로 집계되지만 Events Totals에서는 3회로 집계된다. 따라서 유저 수를 보고 싶은지, 행동의 총 발생 횟수를 보고 싶은지에 따라 Uniques와 Events Totals를 구분해서 사용해야 한다.

Active %

Active %는 기준 유저 중 특정 이벤트를 발생시킨 유저의 비율을 의미한다. 예를 들어 전체 유저 중 구매 완료 유저의 비율을 보고 싶을 때 사용할 수 있다. 이때 분모는 Segment by에서 정의한 유저군이 되고, 분자는 해당 유저군 중 선택한 이벤트를 수행한 유저가 된다.

Average

Average는 유저당 선택한 이벤트가 평균적으로 몇 번 발생했는지를 보여준다. 예를 들어 평균 구매 완료 횟수를 보고 싶다면 Complete Purchase 이벤트를 선택하고 Average를 사용하면 된다.

Frequency

Frequency는 일정 기간 동안 유저가 이벤트를 얼마나 자주 수행하는지를 보여준다. 예를 들어 유저들이 장바구니 추가를 몇 번 반복하는지, 구매를 몇 번 반복하는지 등을 확인할 때 사용할 수 있다.

Properties

Properties는 이벤트에 포함된 속성을 기준으로 데이터를 세분화하여 분석하는 방식이다. 예를 들어 구매 완료 이벤트에는 매출 금액인 revenue, 상품 ID인 item_id, 브랜드명 등의 속성이 포함될 수 있다. 이 속성을 활용하면 총 매출, 가격대 분포, 구매 상품 다양성 등을 분석할 수 있다.

4️⃣Advanced 집계 기능

Amplitude에서는 기본 집계 외에도 Advanced 집계 기능을 제공한다.

Advanced 집계 기능

Rolling Average

Rolling Average는 이동 평균을 의미하며, 지난 N일간의 평균값을 계산한다. 예를 들어 매출이 평일에는 증가하고 주말에는 감소하는 패턴을 보인다면, 하루 단위 수치만으로는 전체적인 증가 추세인지 감소 추세인지 판단하기 어려울 수 있다. 이때 Rolling Average를 적용하면 단기 변동을 완화하고 전체적인 트렌드를 확인할 수 있다.

Rolling Window

Rolling Window는 지난 N일간의 합산값을 계산하는 방식이다. 예를 들어 최근 7일간 발생한 구매 수나 최근 30일간의 활성 유저 수를 보고 싶을 때 사용할 수 있다.

Cumulative

Cumulative은 누적 집계를 의미한다. 기간이 지날수록 값이 계속 누적되는 형태이기 때문에, 누적 가입자 수, 누적 구매 수, 누적 매출 등을 확인할 때 활용할 수 있다.

5️⃣Segment by: 유저 조건 설정하기

Segment by는 어떤 유저군을 대상으로 분석할 것인지 설정하는 영역이다.

Segment by 유저 조건 설정

Any

Any는 분석 기간 동안 하나 이상의 이벤트를 발생시킨 모든 유저를 의미한다. 기본적으로 가장 넓은 범위의 유저군이라고 볼 수 있다.

Active

Active는 분석 기간 동안 Active 상태로 정의된 이벤트를 최소 한 번 이상 발생시킨 유저를 의미한다. Amplitude에서는 모든 이벤트를 동일하게 보지 않고, 서비스 활성 상태를 나타내는 이벤트를 Active 이벤트로 정의할 수 있다. Active는 이러한 기준에 맞는 유저를 대상으로 분석할 때 사용한다.

New

New는 신규 유저를 의미한다. 분석 기간 내에 처음으로 이벤트를 발생시킨 유저를 의미한다. 예를 들어 회원가입을 완료한 신규 유저 수를 보고 싶다면 Segment by에서 New를 선택할 수 있다.

6️⃣Segment by의 추가 필터링 조건

Segment by 영역

Filter by

Segment by의 Filter by는 유저 속성을 기준으로 필터링하는 방식이다. 예를 들어 미국 유저만 보고 싶다면 Segment by의 Filter by에서 Country = United States를 설정할 수 있다.

In Cohort

In Cohort는 미리 정의된 유저 그룹을 기준으로 필터링하는 방식이다. 예를 들어 VIP 유저, 최근 7일 내 구매 유저, 특정 캠페인 유입 유저 등으로 미리 만들어둔 코호트가 있다면 해당 코호트에 속한 유저만 분석할 수 있다.

Performed

Performed는 특정 이벤트 수행 여부 및 조건을 기준으로 유저를 필터링하는 방식이다. 예를 들어 장바구니 추가를 2회 이상 수행한 유저, 특정 기간 내 상품 상세 페이지를 조회한 유저 등을 대상으로 분석할 수 있다. 즉, 유저 속성을 기준으로 필터링할 때는 Filter by를 사용하고, 유저가 수행한 행동을 기준으로 필터링할 때는 Performed를 사용한다.

7️⃣Segmentation 차트 유형 종류

Segmentation 차트에서는 분석 목적에 따라 여러 시각화 유형을 선택할 수 있다.

차트 유형	설명
Line Chart	시간의 흐름에 따른 지표 변화를 확인할 때 사용
Stacked Area	시간의 흐름에 따라 여러 지표를 누적 형태로 확인할 때 사용
Bar Chart	특정 기간 동안의 전체 수치를 비교할 때 사용
Horizontal Bar	여러 조건으로 그룹을 나눈 경우에도 가독성 있게 비교할 때 사용
Stacked Bar	여러 그룹의 값을 누적된 막대 형태로 표현
Pie Chart	각 그룹이 차지하는 구성 비중을 시각적으로 확인할 때 사용
KPI	특정 지표의 현재 값 또는 핵심 수치를 단일 숫자로 강조하여 보여줄 때 사용

예를 들어 시간 흐름을 보고 싶다면 Line Chart가 적합하고, 브랜드별 조회수처럼 범주별 비교가 필요하다면 Bar Chart가 적합하다. 그룹이 많아 세로 막대가 보기 어렵다면 Horizontal Bar를 사용할 수 있다.

8️⃣기간 설정 및 비교

Amplitude에서는 분석 기간과 시간 단위를 설정할 수 있다.

시간 단위 설정

시간 단위 설정

시간 단위 설정은 데이터를 어떻게 나누어 볼 것인지 정하는 것이다. 선택할 수 있는 단위는 다음과 같다.

Realtime
Hourly
Daily
Weekly
Monthly
Quarterly

예를 들어 하루 단위 추이를 보고 싶다면 Daily를 선택하고, 월별 변화를 보고 싶다면 Monthly를 선택한다.

기간 비교 설정

기간 비교 설정

기간 비교 설정은 현재 기간의 데이터를 무엇과 비교할 것인지 정하는 것이다.

Previous day
Previous week
Previous month
Previous quarter
Previous year

예를 들어 이번 주 구매 수를 지난주와 비교하거나, 이번 달 신규 유저 수를 지난달과 비교할 수 있다.

분석 기간 설정

분석 기간 설정

분석 기간 설정은 언제의 데이터를 볼 것인지 정하는 것이다. 캘린더 모양을 클릭해서 원하는 기간을 선택할 수 있다.

Funnel 차트

1️⃣Funnel 차트란?

Funnel 차트는 특정 이벤트를 수행한 이후 다음 단계의 이벤트로 전환된 사용자의 비율을 파악하기에 적합한 차트이다. 퍼널 분석은 사용자가 서비스 안에서 목표 행동까지 도달하는 과정을 단계별로 나누어 보는 분석이다. 예를 들어 쇼핑몰에서는 다음과 같은 흐름을 퍼널로 볼 수 있다.

상품 상세 페이지 조회 → 장바구니 추가 → 구매 완료

이때 각 단계에서 몇 명이 다음 단계로 넘어갔는지, 어디서 많이 이탈했는지를 확인할 수 있다. Funnel 차트는 클릭률, 구매 전환율과 같은 전환 지표를 분석할 때 기본적으로 활용된다.

CTR: Click Through Rate, 클릭률
CVR: Conversion Rate, 전환율

2️⃣Events: 이벤트 순서 옵션

Funnel 차트에서는 이벤트가 어떤 순서로 발생했는지를 어떻게 정의하느냐에 따라 전환율 계산 방식이 달라진다. Amplitude에서 퍼널 분석을 만들면 기본적으로 이벤트 칸이 2개 있다. 최소 두 단계 이상의 이벤트 흐름을 정의해야 전환율을 계산할 수 있기 때문이다.

Events 영역 이벤트 순서 옵션

this order

this order는 기본값이다. 지정한 이벤트가 정해진 순서대로 발생하기만 하면 전환으로 인정된다. 이벤트 사이에 다른 이벤트가 포함되어도 전환으로 간주된다. 예를 들어 상품 상세 조회 → 장바구니 추가 → 구매 완료 퍼널이 있을 때, 사용자가 중간에 검색이나 리뷰 확인을 했더라도 최종적으로 순서대로 장바구니 추가와 구매 완료를 했다면 전환으로 인정된다. 일반적으로 퍼널 분석에서는 this order를 많이 사용한다고 한다.

any order

any order는 이벤트 발생 순서와 관계없이, 해당 이벤트들을 모두 수행한 경우 전환으로 인정한다. 예를 들어 장바구니 추가와 구매 완료 이벤트를 모두 수행했다면 순서와 관계없이 전환에 포함될 수 있다.

exact order

exact order는 지정한 이벤트가 정확한 순서로 발생해야 하며, 중간에 다른 이벤트가 포함되면 전환으로 인정되지 않는다. this order보다 훨씬 엄격한 옵션이다. 사용자가 정해진 흐름을 정확히 따랐는지 확인하고 싶을 때 사용할 수 있다.

3️⃣Events: 퍼널 단계 정의 기능

퍼널 단계 정의

Compare event

Compare event는 특정 퍼널 단계에서 서로 다른 이벤트를 비교할 때 사용한다. 예를 들어 상품 상세 조회 → 장바구니 추가 → 구매 경로와 상품 상세 조회 → 체크아웃 → 구매 경로를 비교하고 싶을 때 사용할 수 있다.

Combine events inline

Combine events inline은 여러 이벤트를 하나의 단계로 통합할 때 사용한다. 예를 들어 장바구니 추가 또는 체크아웃을 하나의 단계로 보고 싶다면 Add to Cart와 Checkout을 inline으로 합칠 수 있다.

Optional step

Optional step은 특정 단계를 생략해도 전환으로 인정할 수 있도록 설정하는 기능이다. 예를 들어 상품 상세 조회 → 장바구니 추가 → 구매 퍼널에서 장바구니 추가 단계를 Optional step으로 설정하면, 장바구니를 거친 유저와 거치지 않은 유저의 전환을 비교할 수 있다.

4️⃣Funnel 차트의 Measured as

Funnel 차트에서는 전환율뿐만 아니라 다양한 방식으로 퍼널을 분석할 수 있다.

Measured as 영역

Conversion

Conversion은 퍼널 전환율을 의미한다. 첫 번째 단계에서 시작한 유저 중 마지막 단계까지 도달한 유저의 비율을 확인할 수 있다.

Over Time

Over Time은 시간의 흐름에 따른 퍼널 전환율 변화 추이를 보여준다. 예를 들어 이번 달 전환율이 시간이 지날수록 개선되고 있는지, 특정 시점 이후 전환율이 떨어졌는지 등을 확인할 수 있다.

Time to Convert

Time to Convert는 퍼널 전환까지 걸린 시간을 보여준다. 예를 들어 장바구니 추가 후 구매까지 평균적으로 얼마나 걸리는지, 대부분의 유저가 몇 시간 안에 구매를 완료하는지 등을 확인할 수 있다.

Frequency

Frequency는 동일 유저의 퍼널 수행 횟수 분포를 보여준다. 예를 들어 유저들이 장바구니 추가 후 구매로 이어지는 행동을 몇 번 반복했는지 확인할 수 있다.

Improvement

Improvement는 기준 대비 전환율 변화율을 보여준다. A/B 테스트에서 기존안과 개선안을 비교할 때 사용할 수 있다.

Significance

Significance는 전환율 차이의 통계적 유의성을 확인할 때 사용한다. 단순히 두 그룹의 전환율 차이가 보이는 것뿐만 아니라, 그 차이가 통계적으로 의미 있는지 확인하는 데 활용된다.

5️⃣Funnel 차트의 전환 계산 기준

전환 계산 기준 설정

Holding property constant

Holding property constant는 동일한 속성 값을 유지한 경우에만 전환으로 인정하는 옵션이다. 예를 들어 같은 상품을 조회하고 같은 상품을 구매한 경우만 전환으로 보고 싶을 때 사용할 수 있다.

Calculate sum of property for final step

Calculate sum of property for final step은 마지막 단계의 속성 값 합계를 계산하는 기능이다. 예를 들어 퍼널의 마지막 단계가 구매 완료라면, 마지막 단계의 revenue 합계를 계산하여 매출을 확인할 수 있다.

Millisecond resolution

Millisecond resolution은 이벤트 순서를 밀리초 단위로 정밀하게 구분하는 기능이다. 이벤트가 매우 짧은 시간 안에 연속적으로 발생하는 경우, 순서를 더 정확하게 판단하기 위해 사용할 수 있다.

Journeys 차트

1️⃣Journeys 차트란?

Journeys 차트는 사용자의 행동 경로를 파악하기 위해 활용되는 차트이다. Funnel 차트가 미리 정해둔 단계별 전환율을 보는 차트라면, Journeys 차트는 사용자가 실제로 어떤 경로를 따라 이동했는지를 확인하는 데 더 적합하다. 예를 들어 상품 상세 페이지를 조회한 유저가 이후에 장바구니를 추가했는지, 검색을 했는지, 다른 상품을 봤는지, 이탈했는지 등을 확인할 수 있다. Journeys 차트는 Funnel 차트와 함께 사용하면 더 효과적이다. 퍼널 차트로 전환 과정에서 이탈 지점을 확인하고, Journeys 차트로 실제 사용자의 이동 경로를 보면 이탈 원인을 더 구체적으로 탐색할 수 있다.

2️⃣Pathfinder

Pathfinder는 특정 이벤트를 기준으로 이후 또는 이전 행동 흐름이 어떻게 갈라지는지 단계별로 탐색하는 기능이다. 예를 들어 View Item Details를 시작 이벤트로 설정하면, 상품 상세 페이지 조회 이후 유저들이 어떤 행동을 했는지 흐름을 볼 수 있다.

Pathfinder의 두 방식

Pathfinder에서는 Sankey 방식과 Sunburst 방식으로 차트를 볼 수 있다. Sankey 방식에서는 각 단계의 흐름이 선의 굵기와 함께 표현되기 때문에, 어떤 경로로 사용자가 많이 이동하는지 직관적으로 확인할 수 있다. 단계에 있는 more을 클릭하면 그 이후의 여정도 추가로 시각화하여 볼 수 있다.

3️⃣Journey Map

Journey Map

Journey Map은 사용자 행동 경로를 조합별로 보여주어 가장 빈번한 행동 패턴을 파악할 수 있는 기능이다. 즉, 개별 단계의 흐름뿐만 아니라 여러 행동 조합 중 어떤 여정이 자주 발생하는지를 볼 수 있다.

4️⃣Paths 설정

Journeys 차트의 Paths에서는 어떤 기준으로 경로를 볼 것인지 설정할 수 있다.

Paths 영역

starting with

starting with은 특정 이벤트로 시작되는 경로를 확인할 때 사용한다. 예를 들어 상품 상세 페이지 조회 후 유저가 어떤 행동을 하는지 보고 싶다면 View Item Details를 starting with로 설정한다.

ending with

ending with은 특정 이벤트로 끝나는 경로를 확인할 때 사용한다. 예를 들어 구매 완료까지 도달한 유저들이 그 직전에 어떤 행동을 했는지 보고 싶다면 Complete Purchase를 ending with로 설정한다.

between

between은 특정 이벤트와 특정 이벤트 사이의 경로를 확인할 때 사용한다. 예를 들어 상품 상세 페이지 조회와 구매 완료 사이에 어떤 행동들이 있었는지 보고 싶을 때 사용할 수 있다.

5️⃣Journeys 차트의 추가 설정

차트 추가 설정 기능

Group by property

Group by property는 특정 속성을 기준으로 이벤트를 나누어 보고 싶을 때 사용한다. 예를 들어 브랜드별로 행동 경로를 나누어 보거나, 국가별로 유저 경로를 비교할 수 있다.

Exclude specific events by property

Exclude specific events by property는 특정 이벤트를 제외하고 싶을 때 사용한다. 분석에 방해가 되는 이벤트나 너무 자주 발생해서 흐름을 보기 어렵게 만드는 이벤트가 있을 때 제외할 수 있다.

Only show paths that include

Only show paths that include는 특정 이벤트를 포함한 경로만 보고 싶을 때 사용한다. 예를 들어 구매 완료를 포함한 경로만 보고 싶거나, 장바구니 추가를 포함한 경로만 보고 싶을 때 활용할 수 있다.

Data Table 차트

Data Table 차트는 데이터를 표 형태로 보여주는 차트이다. 여러 수치를 한눈에 비교하기 좋으며, 여러 지표를 한 화면에서 비교하거나 하나의 지표를 다양한 그룹으로 나누어 확인할 때 활용된다. 차트 형태는 시각적으로 흐름이나 비율을 보여주는 데 강점이 있지만, 정확한 수치를 비교해야 할 때는 표 형태가 더 적합할 수 있다. 예를 들어 국가별 구매 유저 수, 브랜드별 조회수, 프로모션별 매출 등을 숫자로 비교하고 싶다면 Data Table 차트를 사용할 수 있다.

⏳Sessions 차트

1️⃣Sessions 차트란?

Sessions 차트는 세션 단위 분석을 통해 사용자의 서비스 이용 특성을 파악할 수 있는 차트이다. 세션은 사용자가 서비스를 이용한 하나의 방문 단위로 볼 수 있다. 예를 들어 사용자가 앱에 들어와서 상품을 보고, 장바구니에 담고, 결제를 완료한 뒤 앱을 종료했다면 이것을 하나의 세션으로 볼 수 있다. Sessions 차트를 사용하면 사용자가 얼마나 오래 머무는지, 한 세션 안에서 얼마나 많은 이벤트를 수행하는지, 특정 페이지에서 바로 이탈하는지 등을 분석할 수 있다. 또한 Formula 기능을 활용하면 Bounce Rate, Entry Rate, Exit Rate와 같은 커스텀 지표를 생성하여 보다 다양한 관점에서 분석할 수 있다.

2️⃣Sessions 차트의 Measured as

Measured as 영역

Total Sessions

Total Sessions는 특정 기간 동안 발생한 전체 세션 수를 의미한다.

Time Per User

Time Per User는 유저당 평균 체류 시간을 의미한다.

Avg Length

Avg Length는 평균 세션 길이를 의미한다. 즉, 한 번의 세션이 평균적으로 얼마나 오래 지속되는지를 보여준다.

Distribution

Distribution은 세션 길이의 분포를 의미한다. 예를 들어 대부분의 세션이 1분 이내인지, 5분 이상인지, 특정 구간에 많이 몰려 있는지 확인할 수 있다.

Avg Per User

Avg Per User는 유저당 평균 세션 수를 의미한다. 사용자가 분석 기간 동안 평균적으로 몇 번 서비스를 방문했는지 볼 수 있다.

Total Time

Total Time은 전체 체류 시간을 의미한다. 분석 기간 동안 모든 유저의 세션 시간을 합산한 값이다.

Avg events per session

Avg events per session은 선택한 이벤트가 세션 내에서 평균적으로 몇 번 발생하는지 보여준다. 예를 들어 한 세션 안에서 상품 상세 페이지 조회가 평균 몇 번 발생하는지 확인할 수 있다.

선택한 이벤트의 Distribution

선택한 이벤트가 세션 내에서 몇 번 발생하는지 분포를 확인할 수 있다. 예를 들어 한 세션 안에서 장바구니 추가가 0번, 1번, 2번 이상 발생한 유저가 얼마나 되는지 볼 수 있다.

Total events across sessions

Total events across sessions는 선택한 기간 동안 세션 내에서 발생한 이벤트의 총 횟수를 의미한다.

3️⃣세션 분석 관련 주요 지표

Bounce Rate

Bounce Rate는 반송률을 의미한다. 사용자가 사이트에 진입한 뒤 추가 행동이나 다른 페이지 이동 없이 이탈한 비율이다. 예를 들어 사용자가 특정 페이지에 들어왔지만 아무 행동도 하지 않고 바로 나갔다면 Bounce에 해당할 수 있다.

Entry Rate

Entry Rate는 진입률을 의미한다. 전체 세션 중 특정 페이지에서 시작된 세션의 비율이다. 예를 들어 전체 세션 중 상품 상세 페이지에서 시작된 세션이 얼마나 되는지 볼 수 있다.

Exit Rate

Exit Rate는 종료율을 의미한다. 특정 페이지 조회를 마지막으로 세션이 종료된 비율이다. 예를 들어 결제 페이지에서 Exit Rate가 높다면, 결제 단계에서 사용자가 많이 이탈하고 있을 가능성이 있다.

Retention 차트

1️⃣Retention 차트란?

Retention 차트는 일정 기간 이후 서비스에 다시 방문하거나 특정 행동을 다시 수행하는 사용자의 비율을 파악할 수 있는 차트이다. 리텐션은 서비스의 지속 사용 여부를 확인하는 중요한 지표이다. 신규 유저가 많이 들어오더라도 이후에 다시 돌아오지 않는다면 서비스 성장으로 이어지기 어렵다. Retention 차트는 재방문률, 재구매율, 재이용률 등 다양한 리텐션 지표를 분석하는 데 특화되어 있다.

2️⃣Starting event

Starting event 영역

Starting event는 리텐션 분석을 시작하는 기준이 되는 이벤트이다. 즉, 어떤 행동을 한 유저를 리텐션 분석 대상으로 볼 것인지 정의한다. 예를 들어 회원가입 이후 재방문율을 보고 싶다면 Sign up을 Starting event로 설정할 수 있다. 첫 구매 이후 재구매율을 보고 싶다면 Complete Purchase를 Starting event로 설정할 수 있다.

3️⃣Then the return event

Then the return event 영역

Then the return event는 Starting event 이후, 유저가 다시 돌아왔다고 판단할 기준 행동이다. 예를 들어 회원가입 이후 다시 서비스를 이용했는지 보고 싶다면 return event를 Any Active Event로 설정할 수 있다. 구매 이후 다시 구매했는지 보고 싶다면 return event를 Complete Purchase로 설정할 수 있다. 즉, Starting event는 분석 대상이 되는 시작 행동이고, return event는 리텐션 유지 여부를 판단하는 행동이다.

4️⃣Retention 차트의 Measured as

Measured as 영역

Return On or After

Return On or After는 특정 시점 또는 그 이후에 다시 행동했는지를 보는 방식이다. 예를 들어 Day 7 또는 그 이후에 다시 방문했는지를 확인할 수 있다.

Return On

Return On은 특정 시점에 다시 행동했는지를 보는 방식이다. 예를 들어 정확히 Day 7에 다시 방문한 유저 비율을 확인할 수 있다.

Return On Custom

Return On Custom은 리텐션 측정 기준을 직접 정의하는 방식이다. 분석 목적에 맞게 특정 기간이나 조건을 커스텀하여 사용할 수 있다.

Usage Interval

Usage Interval은 특정 이벤트가 얼마나 자주 발생하는지를 보여준다. 예를 들어 유저가 평균적으로 며칠 간격으로 구매하는지, 얼마나 자주 앱을 사용하는지 확인할 수 있다.

5️⃣Retention 차트의 Shown as

Shown as 영역

Retention

Retention은 리텐션 결과를 히트맵 형태의 표로 제공한다. 코호트별로 시간이 지남에 따라 얼마나 많은 유저가 다시 돌아왔는지를 확인할 수 있다.

Change Over Time

Change Over Time은 시간 흐름에 따른 리텐션 변화 추이를 보여준다. 리텐션이 점점 개선되고 있는지, 특정 시점 이후 낮아지고 있는지 확인할 수 있다.

6️⃣Retention 차트의 Calculated by

Calculated by 영역

24-hour windows

24-hour windows는 시작 이벤트가 발생한 시점을 기준으로 24시간씩 계산하는 방식이다. 예를 들어 어떤 유저가 오후 3시에 회원가입을 했다면, 그 시점부터 24시간을 Day 0 또는 Day 1 기준으로 계산하는 방식이다.

Strict calendar dates

Strict calendar dates는 달력 기준 날짜로 계산하는 방식이다. 즉, 실제 날짜 기준으로 Day 0, Day 1, Day 2를 나누어 계산한다.

Stickiness 차트

Stickiness 차트는 사용자가 서비스를 얼마나 자주 방문하는지, 또는 특정 행동을 얼마나 빈번하게 수행하는지를 파악할 수 있는 차트이다. Stickiness는 말 그대로 사용자가 서비스에 얼마나 '붙어 있는지'를 보는 개념이다. 예를 들어 사용자가 한 달에 한 번만 들어오는 서비스와 매일 들어오는 서비스는 사용자 충성도나 습관화 정도가 다르다. Stickiness 차트를 활용하면 특정 이벤트를 기준으로 사용자가 얼마나 자주 해당 행동을 반복하는지 확인할 수 있다. 예를 들어 음악 앱이라면 음악 재생, 쇼핑몰 앱이라면 상품 조회나 구매, 커뮤니티 앱이라면 게시글 조회나 댓글 작성 등이 Stickiness 분석의 기준 이벤트가 될 수 있다.

Lifecycle 차트

1️⃣Lifecycle 차트란?

Lifecycle 차트는 사용자를 상태에 따라 구분하여 관찰할 수 있는 차트이다. 사용자는 단순히 신규 유저와 기존 유저로만 나뉘는 것이 아니라, 이전에 사용했는지, 최근에도 사용했는지, 다시 돌아왔는지, 이탈했는지에 따라 여러 상태로 나눌 수 있다. Lifecycle 차트에서는 사용자를 다음과 같이 구분한다.

New User
Current User
Resurrected User
Dormant User

이를 통해 사용자 유입, 유지, 이탈, 재활성화 흐름을 체계적으로 분석할 수 있다.

2️⃣Lifecycle 사용자 유형

Lifecycle 차트

과거 언젠가	1주 전	대상 주간	사용자 유형	설명
X	X	O	New User	대상 주간에 서비스를 처음 이용한 유저
	O	O	Current User	직전 주간과 대상 주간에 서비스를 모두 이용한 유저
O	X	O	Resurrected User	직전 주간에는 서비스를 사용하지 않았다가 대상 주간에 다시 돌아온 유저
	O	X	Dormant User	직전 주간에는 서비스를 사용했다가 대상 주간에 돌아오지 않은 유저

New User

New User는 대상 주간에 서비스를 처음 이용한 신규 유저이다. 과거에도 사용한 적이 없고, 직전 주간에도 사용하지 않았지만, 대상 주간에 처음으로 서비스를 이용한 유저가 여기에 해당한다.

Current User

Current User는 직전 주간과 대상 주간에 서비스를 모두 이용한 유지 유저이다. 서비스를 계속 사용하고 있는 유저라고 볼 수 있다.

Resurrected User

Resurrected User는 재활성 유저이다. 과거에 서비스를 사용한 적은 있지만 직전 주간에는 사용하지 않았고, 대상 주간에 다시 돌아온 유저를 의미한다.

Dormant User

Dormant User는 휴면 유저 또는 이탈자로 볼 수 있다. 직전 주간에는 서비스를 사용했지만 대상 주간에는 돌아오지 않은 유저이다.

3️⃣Lifecycle 차트의 Shown as

Shown as 영역

Growth

Growth는 신규 유저와 재활성 유저가 얼마나 증가하고 있는지를 중심으로 보여준다. 서비스가 성장하고 있는지 확인할 때 활용할 수 있다.

Dormant

Dormant는 활동이 줄어들거나 이탈한 유저 규모를 중심으로 보여준다. 이탈 문제가 커지고 있는지 확인할 때 활용할 수 있다.

Pulse

Pulse는 신규, 유지, 재활성, 휴면 등 전체 유저 상태 변화를 함께 보여준다. 서비스의 전체적인 사용자 흐름을 종합적으로 파악할 때 사용할 수 있다.

️ Segmentation 차트 실습 정리

이번 실습은 강사님께서 먼저 한 번 보여주시고 우리가 따라 해본 뒤 다시 설명해주시는 방식으로 진행되었다. 실습 데이터는 Amplitude에서 기본적으로 제공하는 이커머스 데이터를 사용하였다.

Create에서 Segmentation 선택

Segmentation 차트는 Create를 누른 뒤 Chart에서 Segmentation을 클릭하여 만들 수 있다.

Q1. 회원 가입을 완료한 신규 유저 수는?

Q1 실습

회원가입한 신규 유저 수를 보기 위해서는 이벤트로 Sign up을 선택한다. 신규 유저를 보는 것이므로 Segment by에서는 기본값인 Any가 아니라 New를 선택한다. 정리하면 다음과 같다.

Events: Sign up
Segment by: New
Measured as: Uniques

Q2. 무료 배송 코드를 적용한 구매 완료자 수는?

Q2 실습

무료 배송 코드를 적용한 구매 완료자 수를 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 구매 완료자 수, 즉 유저 수를 보는 것이므로 집계 방식은 Uniques이다. 이 문제는 단순 구매 완료자 수가 아니라 '무료 배송 코드를 적용한'이라는 조건이 붙어 있다. 따라서 이벤트에 Filter를 걸어주어야 한다.

Events: Complete Purchase
Measured as: Uniques
Events Filter by: Promo Code Applied = Free Shipping

Q3. 프로모션별 구매 완료자 수는?

Q3 실습

프로모션별 구매 완료자 수를 보기 위해서는 이벤트로 Complete Purchase를 선택하고, 집계 방식은 Uniques를 사용한다.

프로모션 코드별로 나누어 보아야 하므로 그룹화가 필요하다.

Events: Complete Purchase
Measured as: Uniques
Events Group by: Promo Code Applied

즉, Filter by가 특정 조건만 남기는 것이라면, Group by는 특정 기준으로 나누어 비교하는 기능이다.

Q4. 구매 완료하거나 장바구니 담기한 유저 수는?

Q4 실습

이 문제에서는 구매 완료 또는 장바구니 담기를 수행한 유저 수를 구해야 한다. 따라서 이벤트는 Complete Purchase와 Add to Cart 두 가지가 된다. 집계 방식은 유저 수를 보는 것이므로 Uniques이다. 이때 중요한 점은 두 이벤트를 비교하는 것이 아니라, 두 이벤트를 하나로 합쳐서 '구매 완료하거나 장바구니 담기한 유저 수'를 보는 것이다. 따라서 그냥 Add Event를 누르면 안 된다. Add Event는 이벤트를 비교할 때 사용하는 방식이고, 여기서는 두 이벤트를 하나의 조건처럼 합쳐야 하므로 Combine events inline을 사용해야 한다.

Events: Complete Purchase + Add to Cart
추가 방식: Combine events inline
Measured as: Uniques

Q5. 전체 유저 대비 구매 완료 유저 비율은?

Q5 실습

전체 유저 대비 구매 완료 유저 비율을 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 비율을 보는 것이므로 집계 방식은 Active %이다. Active %에서는 분모와 분자가 다음과 같이 구성된다.

분모: Segment by에서 정의한 유저군
분자: Segment by 유저군 중 이벤트를 수행한 유저

즉, 전체 유저 중 구매 완료 이벤트를 수행한 유저의 비율을 계산하는 것이다.

Q6. 평균 구매 완료 횟수는?

Q6 실습

평균 구매 완료 횟수를 보기 위해서는 이벤트로 Complete Purchase를 선택하고, 집계 방식은 Average를 선택한다.

Events: Complete Purchase
Measured as: Average

이를 통해 유저당 평균적으로 구매 완료 이벤트가 몇 번 발생했는지 확인할 수 있다.

Q7. 구매 완료 총 매출은?

Q7 실습

구매 완료 총 매출을 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 총 매출은 단순 이벤트 수가 아니라 구매 이벤트에 포함된 금액 속성을 합산해야 한다. 따라서 집계 방식은 Properties에서 sum of property value를 사용한다. 이때 어떤 속성 값을 합산할지 지정해야 하므로 property value는 revenue로 설정한다.

Events: Complete Purchase
Measured as: Properties → sum of property value
Property value: revenue

Q7 실습

처음 결과처럼 매출이 주말에는 감소하고 평일에는 증가하는 식으로 변동성이 있다면 전체적으로 증가 추세인지 감소 추세인지 파악하기 어려울 수 있다. 이때 Rolling Average를 적용하면 단기 변동을 완화하여 전체적인 증감 트렌드를 확인할 수 있다.

Q8. 구매 완료 상품의 가격대 분포는?

Q8 실습

구매 완료 상품의 가격대 분포를 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 가격대 분포를 보는 것이므로 집계 방식은 Properties에서 distribution을 사용한다. 이때 property value는 가격 또는 매출 금액에 해당하는 revenue로 지정한다.

Events: Complete Purchase
Measured as: Properties → distribution
Property value: revenue

Set buckets에서 구간을 직접 지정할 수 있다.

최소값
최대값
간격

예를 들어 0원부터 100,000원까지 10,000원 단위로 구간을 나누는 방식으로 가격대 분포를 볼 수 있다.

Q9. 유저들의 구매 상품 다양성은?

Q9 실습

유저들의 구매 상품 다양성을 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 구매 상품의 다양성을 보려면 유저가 구매한 서로 다른 상품 ID 수를 확인해야 한다. 따라서 집계 방식은 Properties에서 distinct를 사용하고, property value는 item_id로 지정한다.

Events: Complete Purchase
Measured as: Properties → distinct
Property value: item_id

이를 통해 유저들이 얼마나 다양한 상품을 구매했는지 확인할 수 있다.

Q10. 영국 구매 완료 유저 수는?

Q10 실습

영국 구매 완료 유저 수를 보기 위해서는 이벤트로 Complete Purchase를 선택한다. 유저 수를 보는 것이므로 집계 방식은 Uniques이다. 이 문제는 분석 대상이 되는 유저군을 영국 유저로 한정해야 한다. 따라서 Segment by 영역의 Filter by에서 Country를 선택하고 United Kingdom을 지정한다.

Events: Complete Purchase
Measured as: Uniques
Segment by Filter by: Country = United Kingdom

Q11. 장바구니 추가를 2회 이상 수행한 구매 유저 수는?

Q11 실습

이 문제는 구매 완료 유저 중에서도 장바구니 추가를 2회 이상 수행한 유저 수를 구하는 문제이다. 이벤트는 Complete Purchase, 집계 방식은 Uniques이다. 다만 이 문제는 10번과 달리 국가 같은 유저 속성이 아니라, '장바구니 추가를 2회 이상 수행했다'는 행위 조건을 기준으로 유저군을 한정한다. 유저의 특정 이벤트 수행 여부는 Segment by의 Performed에서 지정할 수 있다.

Events: Complete Purchase
Measured as: Uniques
Segment by Performed: Add to Cart ≥ 2

Performed에서는 기간도 명시할 수 있다. 즉 특정 기간 안에 Add to Cart를 2회 이상 수행한 유저처럼 조건을 더 구체적으로 설정할 수 있다.

Q12. 국가별로 구매 완료한 유저 수는?

Q12 실습

국가별 구매 완료 유저 수를 보기 위해서는 이벤트로 Complete Purchase를 선택하고 집계 방식은 Uniques를 사용한다. 국가별로 본다는 것은 분석 대상 유저군을 국가 기준으로 그룹화한다는 의미이다. 따라서 Segment by 영역의 Group Segment by에서 Country를 선택한다.

Events: Complete Purchase
Measured as: Uniques
Segment by Group Segment by: Country

Q13. 전체 유저 중 구매 완료한 미국 유저의 비율은?

Q13 실습

13번과 14번은 필터 사용 위치에 주의해야 한다. Amplitude에서는 Filter by가 Events에도 있고 Segment by에도 있다. 단순히 절대적인 수치인 Uniques나 Event Total을 사용할 때는 큰 문제가 되지 않을 수 있지만, 비율을 계산할 때는 분모와 분자가 어떻게 필터링되는지에 따라 값이 달라진다. 13번은 전체 유저 중 구매 완료한 미국 유저의 비율이다. 이때 구조는 다음과 같다.

분모: 전체 유저
분자: 구매 완료한 미국 유저

분모는 전체 유저이므로 유저군 자체에는 필터가 필요 없다. 대신 분자인 구매 완료 이벤트에 미국 조건이 걸려야 한다. 따라서 Events의 Filter by에서 Country를 United States로 지정한다.

Events: Complete Purchase
Measured as: Active %
Events Filter by: Country = United States
Segment by: All Users

Q14. 미국 유저 중 구매 완료한 유저 비율은?

Q14 실습

14번은 미국 유저 중 구매 완료한 유저 비율이다. 이때 구조는 다음과 같다.

분모: 미국 유저
분자: 미국 유저 중 구매 완료한 유저

따라서 이번에는 유저군 자체를 미국 유저로 한정해야 한다. 즉, Segment by에 필터가 걸려야 한다.

Events: Complete Purchase
Measured as: Active %
Segment by Filter by: Country = United States

13번과 14번은 모두 미국과 구매 완료가 포함되지만, 질문의 의미가 다르기 때문에 필터 위치가 달라진다.

Q15. 상품 상세 페이지 조회 유저 대비 구매 유저 비율은?

Q15 실습

이 문제에서는 상품 상세 페이지 조회 유저 대비 구매 유저 비율을 구해야 한다. 구조는 다음과 같다.

분모: 상품 상세 페이지 조회 유저
분자: 구매 유저

필요한 이벤트는 다음 두 가지이다.

View Item Details
Complete Purchase

여기서는 두 이벤트를 하나로 합치는 것이 아니라, 각각의 유저 수를 비교하여 비율을 계산해야 한다. 따라서 Q4처럼 Combine events inline을 사용하면 안 되고, 그냥 Add Event로 이벤트를 추가해야 한다. 공식은 Measured as 영역의 Formula에서 작성할 수 있다. Complete Purchase를 A, View Item Details를 B라고 하면 공식은 다음과 같다.

UNIQUES(A) / UNIQUES(B)

% 형식으로 표시하고 싶다면 공식 앞에 %:를 붙이면 된다.

%: UNIQUES(A) / UNIQUES(B)

Q16. 전체 구매 수 중 미국 유저 구매 수 비중은?

Q16 실습

이 문제에서는 전체 구매 수 중 미국 유저의 구매 수가 차지하는 비중을 구해야 한다. 구조는 다음과 같다.

분모: 전체 구매 수
분자: 미국 유저 구매 수

분모인 전체 구매 수는 Event Total로 계산할 수 있다. 미국 유저 구매 수는 미국 유저 세그먼트를 추가해서 계산한다. 이벤트는 Complete Purchase를 추가한다. Segment by에서는 All Users를 그대로 두고, 아래의 Add Segment를 눌러 미국 유저 세그먼트를 추가한다.

A1: All Users
A2: United States 유저

Formula에서는 전체 유저 구매 수 대비 미국 유저 구매 수를 계산해야 하므로 다음과 같이 입력한다.

TOTALS(A2) / TOTALS(A1)

TOTALS는 Event Total 집계 방식이다. % 형식으로 표시하고 싶다면 다음과 같이 입력한다.

%: TOTALS(A2) / TOTALS(A1)

Q17. 유저당 평균 구매 횟수는?

Q17 실습

유저당 평균 구매 횟수를 구하려면 분자는 구매 횟수, 분모는 전체 유저 수가 되어야 한다. 먼저 이벤트로 Complete Purchase를 추가한다. 그리고 Add Event를 눌러 Any Active Event를 추가한다. Any Active Event는 Amplitude에서 자동적으로 생성해주는 이벤트이다. 예시로는 다음과 같은 이벤트가 있다.

Any Event: 모든 이벤트
Any Active Event: Active 상태인 이벤트

Any Active Event는 구매 완료나 상세 페이지 조회처럼 특정 하나의 이벤트를 의미하는 것이 아니다. 어떤 행동이든 한 번 이상 수행한 유저를 집계 대상으로 볼 때 사용할 수 있다. 공식에서 분모는 전체 유저 수, 분자는 구매 횟수이다.

A: Complete Purchase
B: Any Active Event

따라서 Formula는 다음과 같다.

TOTALS(A) / UNIQUES(B)

여기서 UNIQUES(B)는 어떤 이벤트든 하나라도 수행한 유저 수가 된다. 그래서 전체 유저 수를 구하기 위해 Any Active Event를 추가한 것이다.

Q18. 유저당 평균 구매 횟수와 구매자의 평균 구매 횟수는?

Q18 실습

이번에는 두 가지 지표를 함께 구한다. 첫 번째는 유저당 평균 구매 횟수이다.

TOTALS(A) / UNIQUES(B)

두 번째는 구매자의 평균 구매 횟수이다. 구매자의 평균 구매 횟수는 구매 횟수를 구매 유저 수로 나누면 된다.

TOTALS(A) / UNIQUES(A)

Amplitude Formula에서 여러 지표를 함께 명시할 때는 공식 사이에 세미콜론을 넣는다. 따라서 최종 공식은 다음과 같다.

TOTALS(A) / UNIQUES(B); TOTALS(A) / UNIQUES(A)

Q19. 상품 상세 조회수와 장바구니 추가 수의 시간 흐름별 추이는?

Q19 실습

상품 상세 조회수와 장바구니 추가 수의 시간 흐름별 추이를 보기 위해서는 두 이벤트를 추가한다.

View Item Details
Add to Cart

이 경우 두 이벤트를 각각 비교하는 상황이므로 Add Event로 이벤트를 추가한다. 집계 방식은 총 발생 횟수를 보는 것이므로 Event Totals를 사용한다.

Q19 실습

그래프 오른쪽 상단에서 그래프 형식을 Stacked Area로 바꾸면 두 이벤트의 추이를 누적 형태로 볼 수 있다.

Q20. 브랜드별 상품 상세 페이지 조회수 추이는?

Q20 실습

브랜드별 상품 상세 페이지 조회수 추이를 보기 위해서는 이벤트로 View Item Details를 선택한다. 집계 방식은 총 조회수를 보는 것이므로 Event Totals이다. 브랜드별로 보기 위해 Events의 Group by에서 brand를 추가한다.

Events: View Item Details
Measured as: Event Totals
Events Group by: brand

누적해서 보고 싶다면 Stacked Area로 바꿀 수 있다. 하지만 범주가 많으면 차트를 해석하기 어려워질 수 있다.

Q20 실습

이럴 때는 범주별 수치를 비교하기 좋은 Bar Chart로 바꾸면 더 보기 좋다.

Q21. 브랜드별 상품 상세 페이지 조회수 순위는?

Q21 실습

브랜드별 상품 상세 페이지 조회수 순위는 Q20에서 만든 그래프를 기준으로 내림차순 정렬하면 확인할 수 있다. 즉, 같은 설정에서 정렬 기준만 바꿔 브랜드별 조회수 순위를 볼 수 있다.

Q22. 프로모션 코드 조합별 브랜드별 상품 상세 페이지 조회수는?

Q22 실습

이 문제는 브랜드뿐만 아니라 프로모션 코드 조합까지 함께 봐야 한다. Q20에서 Events의 Group by에 brand를 추가한 상태에서, 추가로 Promo Code Applied를 Group by에 넣는다. 그러면 기준이 많아져 일반 Bar Chart로 보기 어려울 수 있다.

Q22 실습

이때는 Horizontal Bar를 사용하면 더 가독성 있게 볼 수 있다.

Q23. 브랜드별 상품 상세 페이지 조회 비중은?

Q23 실습

브랜드별 상품 상세 페이지 조회 비중은 Q20에서 Group by에 brand를 추가한 상태에서 그래프 유형만 Pie Chart로 바꿔주면 된다. Pie Chart는 각 브랜드가 전체 조회수에서 차지하는 비중을 확인할 때 적합하다. 차트 제목은 다음과 같이 설정할 수 있다.

Funnel 차트 실습 정리

Create 에서 Funnel 선택

Funnel 차트는 Create를 누른 뒤 Chart에서 Funnel을 클릭하여 만들 수 있다.

Q1. 장바구니 추가 후 구매로 전환되는 비율은?

Q1 실습

장바구니 추가 후 구매로 전환되는 비율을 보기 위해서는 다음 두 이벤트를 설정한다.

Add to Cart
Complete Purchase

집계 방식은 전환율을 보는 것이므로 Conversion을 선택한다.

Q1 실습

Measured as 영역의 Completed within에서는 해당 이벤트를 어떤 기간 안에 수행해야 전환에 포함할 것인지 지정할 수 있다. Counting by에서는 유저 수를 기준으로 계산할지, 이벤트 기준으로 계산할지 설정할 수 있다. 이벤트 순서 옵션도 중요하다.

this order: 지정한 이벤트가 정해진 순서로 발생하기만 하면 전환으로 인정
exact order: 정확히 이 순서여야만 전환으로 인정
any order: 순서와 관계없이 해당 이벤트를 모두 수행하면 전환으로 인정

Q2. 상품 상세 페이지 확인 → 장바구니 추가 → 구매 전환율은?

Q2 실습

이번에는 이벤트가 하나 더 늘어난다. 퍼널 단계는 다음과 같다.

View Item Details
Add to Cart
Complete Purchase

집계 방식은 Conversion이다. 차트에서 마우스를 올리면 전체 전환율뿐만 아니라 바로 이전 단계에 대한 전환율도 확인할 수 있다. 예를 들어 상품 상세 페이지 조회 후 장바구니 추가로 넘어간 비율, 장바구니 추가 후 구매 완료로 넘어간 비율을 볼 수 있다.

Q3. 상품 상세 페이지 확인 → 장바구니 추가 → 구매 전환율에서 장바구니 추가를 Optional step으로 설정하기

Q3 실습

이 경우 장바구니 추가가 선택적인 단계가 된다. 퍼널 단계는 다음과 같다.

View Item Details
Add to Cart
Complete Purchase

Add to Cart 이벤트 칸에서 점 세 개를 누르면 Optional step을 지정할 수 있다. Optional step으로 지정하면 장바구니를 추가했을 때의 전환율과, 장바구니를 추가하지 않았을 때의 전환율을 비교할 수 있다. 즉, 장바구니 추가 단계가 구매 전환에 어떤 영향을 주는지 확인할 수 있다.

Q4. 다음 두 퍼널 비교하기

비교할 퍼널은 다음 두 가지이다.

상품 상세 페이지 조회 → 장바구니 추가 → 구매
상품 상세 페이지 조회 → 체크아웃 → 구매

Q4 실습

이 경우는 이벤트를 추가했다가 제외하는 문제가 아니라, 특정 단계에 아예 다른 이벤트가 들어오는 상황이다. 먼저 다음 퍼널을 만든다.

View Item Details
Add to Cart
Complete Purchase

그리고 Add to Cart 이벤트 칸 오른쪽 점 세 개를 눌러 Compare Event를 선택한다. Compare Event에 Checkout을 추가하면 다음 두 경로를 비교할 수 있다.

View Item Details → Add to Cart → Complete Purchase
View Item Details → Checkout → Complete Purchase

Compare Event는 같은 단계에서 서로 다른 이벤트를 비교할 때 사용한다.

Q5. 상품 상세 페이지 조회 → 장바구니 추가 또는 체크아웃 → 구매 전환율은?

Q5 실습

이번에는 '또는'이 들어가 있다. 즉, 장바구니 추가와 체크아웃을 서로 다른 경로로 비교하는 것이 아니라, 두 이벤트를 하나의 이벤트처럼 묶어서 봐야 한다. 퍼널은 다음과 같이 구성한다.

View Item Details
Add to Cart 또는 Checkout
Complete Purchase

이때 Add to Cart 이벤트 칸 오른쪽 점 세 개를 눌러 Combine events inline을 선택하고 Checkout을 추가한다. 그러면 Add to Cart와 Checkout이 하나의 단계로 합쳐진다.

Q6. 장바구니 추가 후 3시간 이내에 구매로 이어지는 전환율은?

Q6 실습

장바구니 추가 후 3시간 이내에 구매로 이어지는 전환율을 보기 위해서는 다음 이벤트를 설정한다.

Add to Cart
Complete Purchase

집계 방식은 Conversion이다. Measured as 영역의 Completed within에서 3 hours로 지정하면, 장바구니 추가 후 3시간 이내에 구매를 완료한 경우만 전환으로 계산된다.

Q7. 시간 경과에 따른 구매 퍼널 전환율은?

Q7 실습

상품 상세 페이지 조회 → 장바구니 담기 → 구매 퍼널의 시간 흐름별 전환율을 보기 위해서는 다음 이벤트를 설정한다.

View Item Details
Add to Cart
Complete Purchase

집계 방식은 Over Time으로 지정한다. Measured as 영역 맨 아래 Counting by unique User(s) for에서는 어떤 구간의 전환율을 볼 것인지 선택할 수 있다.

the entire funnel: 전체 퍼널 전환율
1: View Item Details to 2: Add to Cart
2: Add to Cart to 3: Complete Purchase

이를 통해 전체 전환율뿐만 아니라 각 단계별 전환율 변화를 시간 흐름에 따라 확인할 수 있다.

Q8. 장바구니 담기 이후 구매 전환 시간 분포

Q8 실습

장바구니 담기 이후 구매 전환 시간 분포를 보기 위해서는 다음 이벤트를 설정한다.

Add to Cart
Complete Purchase

Measured as에서 집계 방식을 Time to Convert로 선택한다. 이때 Set buckets에서 시간 범위를 지정할 수 있다. 예를 들어 1시간 이내, 3시간 이내, 24시간 이내처럼 구간을 설정하여 유저들이 구매까지 얼마나 걸리는지 분포를 확인할 수 있다.

Q9. 장바구니 이후 구매 퍼널 반복 횟수

Q9 실습

장바구니 이후 구매 퍼널 반복 횟수를 보기 위해서는 다음 이벤트를 설정한다.

Add to Cart
Complete Purchase

집계 방식은 Frequency를 선택한다. Frequency는 빈도를 보는 방식이다. 즉, 동일 유저가 해당 퍼널을 몇 번 반복했는지 분포를 확인할 수 있다.

Q10. 두 그룹 중 어떤 그룹이 더 높은 구매 전환율을 보일까?

Q10 실습

이 문제는 A/B 테스트와 관련된 분석이다. A/B 테스트에서 사용할 수 있는 집계 방식은 다음과 같다.

Improvement
Significance

먼저 다음 이벤트를 설정한다.

Add to Cart
Complete Purchase

집계 방식은 Improvement를 선택한다. 이제 두 그룹을 정의해야 한다. Segment by 영역의 Filter by에서 A/B test: Purchase를 선택한다. 첫 번째 그룹은 Control로 설정한다. Control은 대조군, 즉 기존안을 의미한다. 두 번째 그룹은 Add Segment를 눌러 Variant A로 설정한다. Variant A는 실험군, 즉 개선안을 의미한다. 이렇게 하면 대조군과 실험군의 구매 전환율을 비교할 수 있다.

그래프 상단 오른쪽에서 임의의 기간을 선택한 뒤 아래로 스크롤하면 두 그룹의 차이를 확인할 수 있다.

️Journeys 차트 실습 정리

Create에서 Journeys 클릭

Journeys 차트는 Create를 누른 뒤 Chart에서 Journeys를 클릭하여 만들 수 있다.

Q1. 상품 상세 페이지 조회 후 보통 유저는 어떤 행동 양상을 보일까?

Q1 실습

상품 상세 페이지 조회 후 유저가 어떤 행동을 하는지 보기 위해서는 Paths 영역에서 View Item Details를 starting with로 지정한다. 상품 상세 페이지 조회 '후'의 행동을 보고 싶은 것이기 때문에 starting with를 사용하는 것이다. 그러면 상품 상세 페이지 조회로 시작된 여정을 확인할 수 있다. 집계 방식은 상황에 따라 Uniques로 볼지 Event Totals로 볼지 선택하면 된다.

Uniques: 고유 유저 수 기준
Event Totals: 이벤트 발생 횟수 기준

Group by Property에서는 특정 속성을 기준으로 이벤트를 나누어 볼 수 있다. 제외하고 싶은 이벤트가 있다면 Exclude specific events by property에서 명시하면 된다. 특정 이벤트가 포함된 루트만 보고 싶다면 Only show paths that include에서 해당 이벤트를 지정하면 된다.

Q1 실습

Pathfinder에서는 차트를 Sankey 방식과 Sunburst 방식으로 볼 수 있다. Sankey 방식에서는 단계에 있는 more을 클릭하면 그 이후의 여정도 시각화하여 볼 수 있다.

Q1 실습

Journey Map에서는 여러 가지 조합별로 보았을 때 어떤 여정이나 패턴이 빈번한지 확인할 수 있다.

Q2. 유저들의 구매 전환율을 높이고 싶은데 어떤 단계를 개선하면 좋을까?

Q2 실습

이 문제는 Journeys 차트와 Funnel 차트를 함께 활용하는 방식으로 접근할 수 있다. 먼저 Journeys 차트의 Paths에서 Complete Purchase를 ending with로 설정한다. 구매 완료로 끝나는 경로를 보는 것이기 때문에 ending with를 사용하는 것이다. 그러면 Q1과 다르게 Sankey 차트가 반대 방향으로 생성된다. 즉, 구매 완료 이전에 유저들이 어떤 행동을 했는지 확인할 수 있다.

Q2 실습

여기서 관심 있는 여정을 클릭하면 Create Funnel이 나온다. 이를 클릭하면 해당 여정의 Funnel 차트로 이동할 수 있다.

Q2 실습

반대로 Funnel 차트에서도 Show Journeys를 눌러 Journeys 차트로 이동할 수 있다. 이렇게 Funnel 차트와 Journeys 차트를 오가며 분석하면, 단순히 전환율만 보는 것이 아니라 실제 사용자가 어떤 경로에서 이탈했는지, 어떤 행동이 이탈을 유발했는지 더 구체적으로 확인할 수 있다. 예를 들어 특정 단계에서 이탈이 많이 발생한다면, 해당 화면의 문구, 버튼 위치, 상품 정보, 혜택 안내 등을 개선하여 구매를 독려하는 방향으로 개선안을 세울 수 있다.

마무리

이번 수업에서는 Amplitude의 기본 개념과 주요 차트 유형을 학습하였다. Amplitude는 사용자 행동을 이벤트 단위로 수집하고, 이를 기반으로 프로덕트의 성과와 사용자 흐름을 분석할 수 있는 도구이다. 특히 Segmentation 차트는 사용자나 이벤트를 조건에 따라 나누어 지표를 비교할 때 사용하고, Funnel 차트는 단계별 전환율과 이탈 지점을 확인할 때 사용한다. Journeys 차트는 사용자의 실제 행동 경로를 파악하는 데 유용하며, Funnel 차트와 함께 사용하면 전환 과정에서 어떤 부분을 개선해야 할지 더 구체적으로 볼 수 있다. 또한 Sessions, Retention, Stickiness, Lifecycle 차트는 각각 세션 단위 이용 특성, 재방문 및 재이용률, 사용 빈도, 사용자 상태 변화를 분석하는 데 활용된다. 이번 내용에서 가장 중요하게 느낀 부분은 Amplitude에서 차트를 만들 때 단순히 이벤트만 선택하는 것이 아니라, 이벤트를 어떤 기준으로 집계할 것인지, 필터를 Events에 걸 것인지 Segment by에 걸 것인지, 비교인지 통합인지에 따라 설정 방식이 달라진다는 점이었다. 특히 비율 지표를 만들 때는 분모와 분자가 무엇인지 먼저 명확히 정의해야 한다는 점이 중요했다.

[코드잇 스프린트] 데이터 분석가 부트캠프 Week 9 기록

자유를원해 — Fri, 8 May 2026 19:12:01 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

더 자세한 수업 내용은 '공부 기록'을 참고부탁드립니다.

2026.05.06 수

연휴 끝나고 다시 수업...

5일간의 연휴가 끝났다. 솔직히 말하면 아침에 진짜 수업 듣기 싫었다. 너무너무 쉬고 싶었고 다시 공부 모드로 돌아가는 게 정 귀찮게 느껴졌다. 그래도 어쨌든 다시 시작해야 하니까 힘내서 들어갔다. 이날은 수요일이었지만, 월요일이 공휴일이어서 못 했던 위클리 페이퍼를 1교시에 진행했다. 이번 주 위클리 페이퍼 질문은 두 가지였다. 하나는 신규 가입자는 늘었는데 매출은 정체된 상황에서 퍼널 분석과 코호트 분석 중 무엇을 먼저 볼지에 대한 것이었고, 다른 하나는 쇼핑몰 상세 페이지에서 장바구니 추가, 결제 완료까지의 흐름에서 어떤 이벤트와 속성을 트래킹해야 할지 정의해보는 것이었다.

첫 번째 질문은 대부분 결론이 비슷했다. 그런데 두 번째 질문은 이벤트명이나 속성 네이밍 방식이 사람마다 달라서 그걸 보는 재미가 있었다. 같은 내용을 생각해도 표현하는 방식이 조금씩 다르니까 아 이렇게도 쓸 수 있구나 싶은 부분이 있었다. 그리고 이후에는 팀장님께서 팀 규칙 초안을 만들어오셔서 소개해주셨는데, 그 부분도 되게 감사했다. 누군가 먼저 구조를 잡아주는 게 생각보다 편하다!!

‍ 실습 수업

원래 오늘까지는 여덟 번째 스프린트 미션 데이였다. 그런데 저번 시간에 이미 해설까지 다 끝났고, 이 미션에는 비즈니스 분석 프레임워크 토픽이 직접적으로 들어가 있지 않아서 별도로 퍼널, 코호트, RFM 분석 실습을 진행해야했다. 저번 주에 퍼널 분석 실습은 이미 했기 때문에, 이날은 코호트 분석과 RFM 분석 실습을 진행했다.

코호트 분석 실습에서는 먼저 코호트를 나누는 기준부터 여러 가지로 보여주셨다. 가입 시점, 첫 구매 상품, 연령대와 성별 같은 식으로 코호트를 나누는 예시를 차례대로 보았고, 그다음 실제 코호트 분석용 데이터를 만들고 유지율을 계산하는 과정으로 넘어갔다.

고객별 첫 구매월을 구하고, 그 이후 몇 개월이 지났는지를 계산해서 피벗 테이블을 만든 다음, 초기 고객 수 대비 유지율을 계산하는 구조였다. 코드 흐름 자체는 설명을 들으면서 어느 정도 이해가 됐는데, 막상 혼자 다시 하라고 하면 중간중간 버벅일 것 같다는 생각이 들었다. 특히 첫 구매월, 경과 개월, 코호트 피벗, 유지율 행렬 이런 개념들이 머리로는 이어지는데 손으로 다시 쓰려면 아직 덜 익은 느낌이었다. 그래도 “아 코호트 분석이 이런 식으로 만들어지는 거구나” 하는 건 확실히 보였다. 실습 결과를 보면서는 코호트 분석이 왜 필요한지 조금 더 이해가 됐다. 대부분의 코호트는 시간이 지날수록 유지율이 내려가는데, 어떤 시기에는 유지율이 예상보다 높거나 일시적으로 올라가는 코호트도 있었다. 그런 걸 보면 단순히 “시간이 지나면 다 떨어진다”가 아니라, 특정 시기에 유입된 고객 집단이 왜 더 오래 남았는지를 따로 볼 수 있다는 점이 흥미로웠다. 그냥 전체 평균만 봤으면 놓쳤을 차이를 코호트 단위로 보면 잡을 수 있다는 게 확실히 느껴졌다. 그래서 이건 개념만 외우는 것보다 결과를 실제로 보는 게 훨씬 중요한 분석 같다는 생각이 들었다.

이후에는 RFM 분석 실습을 했다. 개인적으로는 코호트 분석보다 RFM 분석 쪽이 조금 더 직관적으로 느껴졌다. 고객을 최근성, 구매 빈도, 구매 금액 기준으로 나누고, 그걸 바탕으로 점수를 만들어 세그먼트로 나누는 방식이라서 “이걸로 고객을 나눠서 마케팅하겠구나”가 바로 보였다. 실습에서는 먼저 결측치와 이상치를 처리하고, 나이와 구매 금액, 구매 횟수 관련 파생변수를 만들었다. 그리고 Recency, Frequency, Monetary를 각각 등급화한 뒤 최종 RFM 점수를 계산해서 고객 세그먼트를 나눴다. 여기서도 단순히 점수만 계산하는 게 아니라, 세그먼트별 연령대 비중, 품목별 매출 기여도, 프로모션 참여율까지 같이 봤다. 그러니까 “이 고객군은 이런 특징이 있고, 이런 상품을 많이 사고, 프로모션 반응은 이렇다” 같은 식으로 해석이 가능해졌다. RFM 분석을 보면서 느낀 건, 점수 자체보다 그걸 가지고 무슨 행동을 할 건지가 더 중요하다는 점이었다. 단순히 1등급, 2등급, 3등급으로 나누는 게 목적이 아니라, 그 세그먼트를 보고 어떤 고객에게 어떤 전략을 써야 할지를 생각해야 하니까 말이다. 예를 들어 최근성은 낮지만 구매 빈도와 금액이 높은 고객, 혹은 구매는 자주 하지만 금액은 적은 고객은 전부 다른 성향으로 봐야 한다는 게 확실히 이해됐다. 이건 진짜 마케팅이랑 바로 연결될 수밖에 없는 분석이라는 생각이 들었다.

넘 힘들다!!!

이날 수업은 내용 자체가 흥미 없는 건 아니었는데, 중간에 졸기도 많이 졸았다. 안 졸고 들어도 이게 무슨 소리지? 싶은 부분이 조금 있었는데 졸기까지 하니까 더 정신이 없었다. 특히 코호트 분석 쪽은 개념이 익숙하지 않아서 더 그랬던 것 같다. 그래서 이날은 진짜 복습이 많이 필요하겠다고 느꼈다. 그냥 배웠다 수준으로 넘기면 안 될 것 같고, 코호트랑 RFM은 한 번 더 정리하면서 내가 직접 다시 흐름을 써봐야 할 것 같다. 17시부터는 자율학습을 진행했다.

Amplitude 회원가입

그리고 내일부터는 Amplitude라는 걸 사용한다고 하셔서 회원가입도 해두었다. 처음 듣는 툴인데 써보게 된다고 하니까 좀 궁금했다.

마무리

이날은 연휴 끝이라 몸도 마음도 좀 늘어져 있었는데 수업 내용까지 쉽지는 않아서 더 피곤하게 느껴진 하루였다. 그래도 코호트 분석과 RFM 분석을 실제 코드와 함께 보니까 그냥 정의만 볼 때보다 훨씬 더 이해가 됐다. 물론 아직 완전히 편한 수준은 아니다. 특히 코호트 분석은 다시 봐야 할 것 같고, RFM도 계산보다는 해석 쪽을 더 고민해봐야 할 것 같다. 그래도 적어도 이 분석이 왜 필요한지는 조금씩 보이기 시작한 것 같아서 그건 다행이다. 내일부터는 또 새로운 툴도 써보고, 다른 방식으로 데이터를 보게 될 것 같다. 연휴 끝나고 다시 시동 거는 날이었는데 어쨌든 버텼다. 내일도 화이팅.

2026.05.07 목

Amplitude로 하는 프로덕트 데이터 분석

이날은 Amplitude로 하는 프로덕트 데이터 분석 이론 데이였다.

Amplitude 화면

새로운 툴을 배운다고 해서 살짝 긴장했는데 막상 수업을 들어보니 SQL이나 파이썬처럼 직접 코드를 치는 방식이 아니라 UI 기반으로 분석을 하는 도구라서 훨씬 직관적으로 느껴졌다. 솔직히 말하면 이런 류의 툴이 확실히 더 재밌다!! 화면에서 바로바로 바뀌는 걸 보는 맛이 있어서 그런 것 같다.

수업 초반에는 Amplitude가 어떤 도구인지, 뭘 할 수 있는지부터 설명해주셨다. 사용자 행동 데이터를 이벤트 단위로 수집하고, 그걸 바탕으로 프로덕트 성과를 분석하는 도구라고 하셨다. 방문자 수, 특정 기능 사용량, 전환율 같은 걸 비교적 쉽게 볼 수 있고, Segmentation, Funnel, Journeys 같은 기능으로 사용자 행동을 분석할 수 있다고 하셨다. 듣다 보니 결국 핵심은 이벤트였다. 어떤 행동을 이벤트로 잡고, 그걸 어떤 방식으로 집계하느냐에 따라 보고 싶은 숫자가 달라지는 구조였다.

Segmentation 차트 실습

이날은 Segmentation 차트를 중심으로 실습을 진행했다.

Segmentation 차트 선택

조건에 따라 사용자나 이벤트를 나누고 비교하는 차트라고 설명해주셨는데 말보다 직접 해보니까 훨씬 이해가 잘 됐다. 이벤트를 고르고, 필터를 걸고, 그룹을 나누고, 집계 방식을 바꾸면 같은 데이터도 전혀 다르게 보였다. 예를 들어 고유 유저 수를 보느냐, 총 이벤트 수를 보느냐, 특정 속성의 합계를 보느냐에 따라 완전히 다른 질문에 답할 수 있다는 게 꽤 흥미로웠다. 파이썬이나 SQL에서는 내가 직접 다 계산해서 만들어야 했던 걸, 여기서는 UI에서 조합해서 바로 볼 수 있다는 점이 편하고 재밌었다.

실습하면서 제일 인상 깊었던 건 필터를 어디에 거느냐에 따라 결과가 달라진다는 점이었다.

예시

특히 비율 문제에서 그랬다. 예를 들어 전체 유저 중 특정 조건의 구매 유저 비율을 보고 싶은 건지, 특정 조건의 유저들 중 구매 유저 비율을 보고 싶은 건지에 따라 Events 쪽에 필터를 거는지, Segment by 쪽에 필터를 거는지가 달라졌다. 겉으로 보기엔 비슷한 질문 같아도 분모와 분자가 달라지면 완전히 다른 계산이 되는 거라서, 이 부분이 꽤 중요하게 느껴졌다. 이건 그냥 툴 사용법이라기보다 분석할 때 질문을 정확히 이해해야 한다는 얘기랑도 연결되는 것 같았다.

실습은 강사님께서 먼저 보여주시고, 우리가 따로 진행해보고, 다시 설명해주시는 식으로 진행되었다. 기본으로 제공되는 이커머스 데이터를 사용했는데 문제들도 실제로 많이 볼 법한 질문들이라 재밌었다. 신규 가입자 수, 무료 배송 코드 적용 구매자 수, 프로모션별 구매 유저 수, 상세 페이지 조회 대비 구매 비율, 국가별 구매 유저 수, 미국 유저 관련 비율 계산, 상품 상세 조회수와 장바구니 추가 수 추이 같은 것들을 하나씩 해봤다. 이런 식으로 질문이 구체적으로 주어지니까 이럴 때 이 기능을 쓰는구나가 바로 연결돼서 좋았다. 무엇보다 나는 역시 코드만 치는 것보다 이런 툴을 직접 만지는 게 더 재밌다. 화면에서 바로 결과가 보이고, 필터 걸고 차트 바꾸고 하는 과정이 확실히 덜 지루하다!

마무리

배운 내용을 바탕으로 마지막에는 사지선다 6문제를 풀고 수업이 마무리되었다. 문제 수는 적었지만 배운 내용을 가볍게 다시 확인하기에는 괜찮았다. 17시부터는 자율학습 시간이라, 나는 어제 했던 코호트 분석과 RFM 분석 실습 코드를 다시 복습했다. 이날 수업도 있었지만 솔직히 전날 내용이 아직 덜 익숙해서 그냥 넘어가면 안 될 것 같았다. 특히 코호트 분석 쪽은 다시 안 보면 금방 흐려질 것 같아서 한 번 더 보는 쪽을 택했다. 요즘 배우는 양이 많다 보니 새 내용 따라가는 것도 중요하지만 예전 내용 잊어버리지 않게 다시 보는 시간도 꼭 필요한 것 같다.

어쨌든 이날은 예상보다 훨씬 재밌었다. Amplitude는 결국 이벤트를 기준으로 데이터를 보고, 필터와 그룹, 집계 방식과 공식을 조합해서 원하는 지표를 바로 확인할 수 있다는 점이 되게 직관적으로 느껴졌다. 물론 아직은 필터를 어디에 거는지, 공식에서 분모랑 분자를 어떻게 두는지 같은 부분이 살짝 헷갈리긴 한다. 그래도 문제를 하나씩 따라가면서 해보니까 금방 감이 오는 부분도 있었다. 이런 툴은 직접 만져보는 게 제일 중요한 것 같다. 남은 내용은 내일 이어서 나간다고 하셨다. 벌써 금요일이라니 너무 좋다. 내일도 잘 버텨보자!

2026.05.08 금

️이어서 Amplitude

이날도 이어서 Amplitude로 하는 프로덕트 데이터 분석 이론을 나갔다. 어제는 Segmentation 차트를 중심으로 배웠다면, 오늘은 Funnel 차트와 Journeys 차트가 중심이었다. 솔직히 말하면 이날 내용이 개인적으로는 더 재밌었다. 아무래도 전환이나 사용자 행동 경로처럼 '그래서 사람들이 어디서 빠지고, 어디서 이어지는가'를 보는 분석이 훨씬 눈에 잘 들어왔기 때문이다.

Funnel 실습에서 특히 재밌었던 건 특정 단계를 선택적으로 두거나, 두 경로를 비교하거나, 아예 하나의 단계로 합쳐서 볼 수 있다는 점이었다.

Funnel 차트 실습

예를 들어 어떤 단계는 꼭 거쳐도 되고 안 거쳐도 되는 경우가 있는데, 그걸 Optional step으로 둘 수 있다는 게 꽤 유용해 보였다. 그리고 특정 단계에서 어떤 이벤트와 어떤 이벤트가 더 효과적인지도 Compare Event로 비교할 수 있었고, 비슷한 성격의 이벤트를 하나처럼 보고 싶을 때는 Combine events inline을 쓰는 방식도 배웠다. 이런 기능들을 보면서 툴이 진짜 잘 만들어졌네 싶었다. 코드로 직접 짜려면 꽤 번거로울 것 같은 걸 UI에서 바로 설정해서 볼 수 있으니까 확실히 편했다.

이후에는 Journeys 차트를 배웠다. 개인적으로는 Funnel보다 Journeys 차트가 더 재밌었다.

Journeys 차트 실습

사용자의 행동 경로를 시각적으로 보여주니까 확실히 사람들이 이렇게 움직이는구나가 바로 보였다. 특히 재밌었던 건 Funnel과 Journeys를 서로 오갈 수 있다는 점이었다. Journeys 차트에서 특정 경로를 클릭하면 Funnel 차트로 넘어가고, Funnel 차트에서 다시 Journeys를 볼 수도 있었다. 이게 왜 좋냐면, Funnel에서는 여기서 이탈이 크네를 보고, Journeys에서는 그럼 실제로 사람들은 어디로 빠졌지?를 바로 볼 수 있기 때문이다. 그러니까 한쪽은 전환율을 보고, 다른 한쪽은 실제 행동 경로를 보는 역할이라고 느껴졌다. 이 부분에서 아 이게 진짜 프로덕트 분석 툴이구나 싶은 생각이 들었다. 단순히 예쁜 그래프가 아니라, 문제를 찾고 원인을 추적하는 데 쓰는 도구라는 게 더 잘 보였다.

Funnel과 Journeys 차트 실습이 끝난 뒤에는 Data Table, Sessions, Retention, Stickiness, Lifecycle 차트도 간단히 봤다. 이건 오늘처럼 하나하나 문제를 풀면서 깊게 실습하진 않았고, 강사님께서 차트 만드는 걸 보여주시면서 이런 것도 있다 식으로 소개해주셨다. 그래서 그런지 솔직히 이쪽은 아직 감이 잘 안 잡힌다.

Amplitude 끝!

Amplitude 이론도 끝이 났다. 아직 완벽히 다 안다고 할 수는 없지만, 적어도 이제는 Segmentation, Funnel, Journeys 차트는 어떤 상황에서 쓰는지, 대충 어떻게 설정하는지는 알게 된 것 같다. 무엇보다 '또 하나의 툴을 배웠다'는 사실 자체가 꽤 기분 좋았다.
예전에는 그냥 들어본 적도 없는 툴이었는데 이제는 실제로 직접 만져봤고 기본적인 기능은 써볼 수 있는 사람이 된 거니까 그게 나름 뿌듯했다! 이론이 다 끝난 뒤에는 강사님께서 지금까지 배운 Amplitude 이론을 한 번 전체적으로 정리해주셨다. 그리고 17시부터 자율학습 시간이 주어졌는데 나는 또 어제처럼 파이썬으로 했던 비즈니스 분석 실습 내용을 다시 복습했다...ㅋㅋ

마무리

이날은 Amplitude 이론 중에서도 특히 재미있게 들은 날이었다. Funnel 차트와 Journeys 차트는 숫자랑 행동 경로를 같이 볼 수 있다는 점에서 확실히 매력적이었다. 특히 퍼널에서 전환이 떨어지는 구간을 보고, 저니에서 실제로 어디로 빠지는지를 같이 보는 방식이 되게 인상적이었다. 아직 다른 차트들은 감이 덜 오지만, Segmentation, Funnel, Journeys는 어느 정도 손에 익기 시작한 것 같다. 다음 주 월, 화요일에는 이걸로 스프린트 미션도 진행한다고 하셔서 조금 기대된다. 실제로 내가 직접 문제를 풀어보면 더 잘 익을 것 같기 때문이다. 이번 주도 고생 많았다!

데이터 분석가 부트캠프 Week 9 마무리

Week 9는 연휴가 끝난 뒤 다시 공부 흐름을 잡아가는 주였다... 초반에는 코호트 분석과 RFM 분석을 실습하면서 고객을 단순히 전체 평균으로 보는 것이 아니라, 유입 시점과 구매 행동 기준으로 나누어 해석하는 방법을 배웠다. 아직 코호트 분석은 다시 봐야 할 만큼 낯설었지만, 유지율을 직접 계산하고 시각화해보면서 왜 이 분석이 필요한지는 확실히 느낄 수 있었다.

그리고 이번 주의 가장 큰 내용은 Amplitude였다. 처음 써보는 툴이라 걱정도 있었지만, 막상 사용해보니 이벤트, 필터, 그룹, 집계 방식을 조합해서 원하는 지표를 바로 볼 수 있다는 점이 꽤 직관적이었다. 특히 Segmentation, Funnel, Journeys 차트를 실습하면서 사용자 행동 데이터를 어떻게 분석하고, 어디서 전환이 떨어지는지, 사용자가 실제로 어떤 경로로 이동하는지를 보는 과정이 재미있었다. 이번 주는 내용도 많고 중간중간 피곤하기도 했지만, 그래도 새로운 분석 방법과 새로운 툴을 하나 더 배웠다는 점에서 꽤 의미 있는 한 주였다. 아직 완벽하게 익숙한 건 아니지만, 다음 주 스프린트 미션에서 직접 Amplitude를 더 써보면 조금 더 손에 익을 것 같다. Week 9도 어찌저찌 잘 버텼다!

[코드잇 스프린트] 스프린트 미션 08 - 커머스 앱 화면을 보고 로그 설계해보기

자유를원해 — Thu, 7 May 2026 23:20:44 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.

디자인 화면을 보고 로그 설계해보기

여덟 번째 스프린트 미션은 앞서 배운 사용자 행동 로그 설계 내용을 바탕으로 가상의 커머스 앱 화면을 보고 직접 로그를 설계해보는 미션이었다.

가상 커머스 앱 화면

스타일샵(Styleshop)이라는 가상의 커머스 앱이 주어졌다. 화면은 크게 메인 페이지와 카테고리 페이지로 구성되어 있었고, 각 화면에서 사용자가 어떤 행동을 할 수 있는지 확인한 뒤 필요한 지표를 계산할 수 있도록 Tracking Plan을 설계해야 했다. 실제로 로그 설계는 화면 개발이 완료된 뒤가 아니라 개발 전에 디자인 파일을 보면서 미리 진행되는 경우가 많다고 한다. 그래서 이번 미션에서도 완성된 앱을 사용하는 것이 아니라, 개발 예정인 화면 이미지를 보고 어떤 로그가 필요할지 직접 정의하는 방식으로 진행되었다.

처음에는 필요한 지표가 꽤 많아 보여서 복잡할 것 같았다. 메인 페이지 방문자 수, 인당 방문 빈도, 배너 클릭률, 카테고리 퀵메뉴 클릭률, 영역별 상품 클릭률, 인기 브랜드 더 보기 버튼 클릭률, 오늘의 인기 코디 배너 클릭률 등 확인해야 할 지표가 많았다. 카테고리 페이지에서도 페이지 방문자 수, 카테고리별 방문자 수, 상품 클릭률 등을 확인해야 했다. 하지만 미션 안내를 천천히 읽어보니 반복되는 구조가 많았다. 결국 핵심은 사용자가 페이지를 방문했는지, 특정 영역을 봤는지, 클릭했는지, 스크롤했는지를 로그로 남기고, 나중에 이 로그를 배너 정보나 상품 정보와 결합해서 분석할 수 있도록 설계하는 것이었다.

로그 설계에서 먼저 생각한 점

이번 미션을 하면서 가장 먼저 생각한 것은 나중에 어떤 지표를 계산해야 하는가였다. 로그는 단순히 사용자의 행동을 많이 남긴다고 좋은 것이 아니라 필요한 지표를 계산할 수 있도록 설계되어야 한다. 예를 들어 메인 배너 클릭률을 계산하려면 단순히 배너 클릭 로그만 있으면 부족하다. 클릭률은 클릭 수를 노출 수로 나누어 계산하기 때문에, 배너가 사용자에게 노출된 로그도 함께 필요하다.

상품 클릭률도 마찬가지이다. 상품 클릭 수만 있으면 어떤 상품이 많이 클릭되었는지는 알 수 있지만, 노출 대비 얼마나 클릭되었는지는 알 수 없다. 따라서 상품 클릭률을 계산하려면 상품 노출 로그와 상품 클릭 로그가 모두 필요하다.

메인 페이지 로그 설계

메인 페이지는 사용자가 앱에 들어왔을 때 처음 마주하는 화면이다. 따라서 메인 페이지에서는 사용자가 페이지에 얼마나 자주 방문하는지, 어떤 영역에 관심을 보이는지, 어떤 상품이나 배너를 클릭하는지 확인하는 것이 중요하다고 생각했다. 메인 페이지에는 위의 사진처럼 크게 메인 배너 영역, 카테고리 퀵메뉴 영역, 오늘 핫한 브랜드 영역, 인기 브랜드 더 보기 버튼, 오늘의 인기 코디 영역이 있었다.

메인 페이지 방문 로그

가장 기본적으로 필요한 로그는 메인 페이지 방문 로그이다.

메인 페이지 방문

이 로그는 사용자가 메인 페이지에 진입했을 때 발생하도록 설계할 수 있다. 이벤트 이름은 main.pageview로 정의하였다. 이 로그를 통해 메인 페이지 방문자 수와 인당 방문 빈도를 계산할 수 있다.

기본 요구사항 지표인 메인 페이지 방문자 수는 특정 기간 동안 메인 페이지를 한 번 이상 방문한 고유 사용자 수로 측정할 수 있다. 예를 들어 하루 동안 main_page_view 로그가 발생한 사용자 중 중복을 제거한 사용자 수를 계산하면 일간 메인 페이지 방문자 수를 알 수 있다. 인당 방문 빈도도 전체 메인 페이지 방문 횟수를 고유 방문자 수로 나누어 계산할 수 있다. 예를 들어 하루 동안 메인 페이지 방문 로그가 3,000건 발생했고, 고유 방문자가 1,000명이라면 인당 방문 빈도는 3,000 ÷ 1,000 = 3회가 된다. 이 지표를 통해 메인 페이지가 사용자에게 얼마나 자주 활용되는지 확인할 수 있다. 방문자 수가 많지만 인당 방문 빈도가 낮다면 많은 사용자가 한 번씩만 방문하고 있는 상태일 수 있고, 방문자 수와 방문 빈도가 모두 높다면 메인 페이지가 반복적으로 사용되는 핵심 진입 화면이라고 볼 수 있다.

메인 배너 노출 및 클릭 로그

메인 페이지 상단에는 3~5개 사이의 배너가 롤링되는 메인 배너 영역이 있다. 이 영역의 성과를 확인하기 위해서는 메인 배너 노출 로그와 메인 배너 클릭 로그가 필요하다.

메인 배너 영역 노출, 메인 배너 클릭

배너 노출 로그는 특정 배너가 사용자 화면에 노출되었을 때 발생하도록 설계할 수 있다. 이벤트 이름은 main.banner_impression으로 정의하였고, 속성에는 배너 순서와 배너 ID를 포함하였다. 배너 클릭 로그는 사용자가 배너 이미지를 클릭했을 때 발생하도록 설계할 수 있다. 이벤트 이름은 main.banner_click으로 정의하였고, 속성도 똑같이 배너 순서와 배너 ID를 포함하였다.

이 두 로그를 활용하면 메인 배너 클릭률을 계산할 수 있다. 계산 방식은 메인 배너 클릭 수를 메인 배너 노출 수로 나누고 100을 곱하는 방식이다. 예를 들어 특정 배너가 10,000번 노출되었고, 그중 800번 클릭되었다면 해당 배너의 클릭률은 800 ÷ 10,000 × 100 = 8%가 된다. 이 지표는 배너별 성과를 비교하는 데 사용할 수 있다. 노출 수는 많지만 클릭률이 낮은 배너는 이미지나 문구가 사용자의 관심을 충분히 끌지 못했을 수 있다. 반대로 노출 수는 적어도 클릭률이 높은 배너는 사용자 반응이 좋은 배너일 수 있으므로 더 앞 순서에 배치하거나 비슷한 콘텐츠를 추가로 기획할 수 있다. 또한 배너 순서도 함께 남기는 것이 중요하다고 생각했다. 메인 배너는 롤링 형태이기 때문에 첫 번째로 보이는 배너와 뒤쪽 순서에 있는 배너는 노출 기회가 다를 수 있다. 따라서 단순 배너 ID만 보는 것이 아니라 배너 순서별 노출 수와 클릭률도 함께 확인해야 한다.

카테고리 퀵메뉴 노출 및 클릭 로그

메인 페이지에는 상의, 팬츠, 원피스, 아우터, 기타와 같은 카테고리 퀵메뉴가 있었다. 사용자가 이 퀵메뉴를 클릭하면 해당 카테고리 페이지로 이동하는 구조였다. 이 지표를 계산하기 위해서는 카테고리 퀵메뉴 노출 로그와 카테고리 퀵메뉴 클릭 로그가 필요하다.

'카테고리 선택' 영역 노출, 카테고리 퀵메뉴 클릭

이벤트 이름은 main.category_menu_impression, main.category_menu_click로 정의하였고, 속성에는 카테고리 ID를 포함시켰다. 카테고리 퀵메뉴 클릭률은 카테고리 퀵메뉴 클릭 수를 퀵메뉴 노출 수로 나누어 계산할 수 있다. 예를 들어 노출이 5,000회 발생했고, 그중 상의 카테고리 퀵메뉴 클릭이 700회 발생했다면 상의 카테고리 퀵메뉴 클릭률은 700 ÷ 5,000 × 100 = 14%가 된다. 이 지표를 통해 사용자가 어떤 카테고리에 가장 관심을 보이는지 확인할 수 있다. 특정 카테고리 클릭률이 높다면 해당 카테고리의 상품 수요가 높다고 볼 수 있고, 클릭률이 낮은 카테고리는 아이콘이나 카테고리명, 위치를 개선할 필요가 있을 수 있다.

영역별 상품 노출 및 클릭 로그

메인 페이지에는 오늘 핫한 브랜드 영역과 오늘의 인기 코디 영역처럼 상품이 노출되는 영역이 있었다. 이 영역들은 좌우 스크롤 방식으로 상품을 탐색하는 구조였기 때문에 단순히 상품 클릭 여부만 보는 것이 아니라 상품이 몇 번째 위치에 있었는지도 함께 확인해야 한다고 생각했다.

상품 노출 로그, 상품 클릭 로그

상품 노출 로그는 상품 카드가 사용자 화면에 노출되었을 때 발생하도록 설계할 수 있다. 이벤트 이름은 main.item_impression으로 정의하였고, 속성에는 영역, 상품 ID, 상품 위치(순서), 무료배송 여부, 번개배송 여부, 할인율을 포함시켰다. 상품 클릭 로그는 사용자가 상품 카드나 상품명을 클릭했을 때 발생하도록 설계할 수 있다. 이벤트 이름은 main.item_click으로 정의하였고, 똑같이 속성엔 영역, 상품 ID, 상품 위치(순서), 무료배송 여부, 번개배송 여부, 할인율을 포함시켰다.

영역별 상품 클릭률은 특정 영역에서 발생한 상품 클릭 수를 해당 영역의 상품 노출 수로 나누어 계산할 수 있다. 예를 들어 오늘 핫한 브랜드 영역에서 상품 카드가 총 20,000번 노출되었고, 그중 1,600번 클릭되었다면 해당 영역의 상품 클릭률은 1,600 ÷ 20,000 × 100 = 8%가 된다. 이 지표를 영역별로 비교하면 어떤 영역이 상품 탐색 성과가 높은지 확인할 수 있다. 예를 들어 오늘 핫한 브랜드 영역의 클릭률은 높고 오늘의 인기 코디 영역의 클릭률은 낮다면, 사용자는 코디 콘텐츠보다 브랜드 상품 리스트에 더 관심을 보인다고 해석할 수 있다. 또한 상품 위치 번호를 남기면 좌측에서 우측으로 스크롤되는 상품 리스트에서 후순위 상품까지 얼마나 탐색되는지도 확인할 수 있다. 예를 들어 1번, 2번 상품의 클릭률은 높지만 5번 이후 상품의 노출 수와 클릭률이 급격히 낮아진다면 사용자가 충분히 스크롤하지 않고 앞쪽 상품만 보고 있다는 의미일 수 있다. 이 경우 상품 배치 순서를 개선하거나, 후순위 상품의 노출을 늘릴 수 있는 UI 개선을 고민할 수 있다.

이후 상품 클릭률을 계산할 때 무료배송 상품과 무료배송이 아닌 상품을 나누어 클릭률을 비교할 수 있다. 계산 방식은 동일하게 상품 클릭 수를 상품 노출 수로 나누는 방식이다. 예를 들어 무료배송 상품이 10,000번 노출되고 900번 클릭되었다면 클릭률은 9%이고, 무료배송이 아닌 상품이 10,000번 노출되고 600번 클릭되었다면 클릭률은 6%가 된다. 이 경우 무료배송 배지가 있는 상품이 더 높은 클릭률을 보였다고 해석할 수 있다. 번개배송도 같은 방식으로 비교할 수 있다. 번개배송 배지가 있는 상품과 없는 상품의 노출 수, 클릭 수, 클릭률을 비교하면 빠른 배송 정보가 사용자의 클릭 행동에 영향을 주는지 확인할 수 있다. 다만 이때 주의할 점은 무료배송이나 번개배송 여부만으로 클릭률 차이를 단정하면 안 된다는 점이다. 상품 이미지, 가격, 할인율, 브랜드 인지도, 노출 위치 등 다른 요인도 함께 영향을 줄 수 있기 때문에, 배지 여부는 상품 위치나 할인율과 함께 분석하는 것이 더 적절하다고 생각했다.

할인율은 할인율 구간을 나누어 클릭률을 비교할 수 있다. 예를 들어 0~10%, 10~30%, 30~50%, 50% 이상과 같이 할인율 구간을 나누고, 각 구간별 상품 노출 수와 클릭 수를 집계해 클릭률을 계산할 수 있다. 계산 방식은 할인율 구간별 상품 클릭 수를 할인율 구간별 상품 노출 수로 나누는 방식이다. 예를 들어 30~50% 할인 상품이 8,000번 노출되고 1,000번 클릭되었다면 해당 구간의 클릭률은 1,000 ÷ 8,000 × 100 = 12.5%가 된다. 반면 0~10% 할인 상품의 클릭률이 5%라면 할인율이 높은 상품이 더 많은 클릭을 유도했을 가능성을 생각해볼 수 있다. 이 지표는 할인 정책이나 상품 노출 전략을 개선하는 데 활용할 수 있다. 높은 할인율 상품의 클릭률이 확실히 높다면 할인 상품을 더 앞쪽에 배치하는 전략을 생각해볼 수 있고, 할인율이 높아도 클릭률이 낮다면 상품 이미지나 브랜드, 가격대 등 다른 요인을 함께 확인해야 한다.

오늘의 인기 코디 배너 노출 및 클릭 로그

오늘의 인기 코디 영역은 상단에 코디 배너가 있고, 하단에는 해당 코디와 관련된 상품들이 노출되는 구조였다. 배너가 롤링되면 하단 상품 카드도 함께 변경되는 형태였다. 이 영역에서는 코디 배너 노출 로그와 코디 배너 클릭 로그가 필요하다.

'오늘의 인기 코디' 배너 영역 노출, '오늘의 인기 코디' 배너 클릭

이벤트 이름은 main.today_outfit_banner_impression, main.today_outfit_banner_click로 정의하였다. 속성에는 배너 순서, 코디 ID를 포함하였다. 오늘의 인기 코디 배너 클릭률은 코디 배너 클릭 수를 코디 배너 노출 수로 나누어 계산할 수 있다. 예를 들어 특정 코디 배너가 6,000번 노출되고 420번 클릭되었다면 클릭률은 420 ÷ 6,000 × 100 = 7%가 된다. 이 지표를 통해 어떤 코디 콘텐츠가 사용자의 관심을 많이 받는지 확인할 수 있다. 또한 코디 배너 클릭률과 하단 코디 상품 클릭률을 함께 보면, 사용자가 코디 자체에 관심이 있는지, 아니면 코디에 포함된 상품 구매에 더 관심이 있는지도 비교할 수 있다.

카테고리 페이지 로그 설계

카테고리 페이지는 사용자가 메인 페이지의 퀵메뉴 등을 통해 특정 카테고리로 이동했을 때 보게 되는 화면이다.

카테고리 페이지 로그 설계

화면 상단에는 카테고리 선택 영역이 있고, 실시간 랭킹 영역과 상품 리스팅 영역이 있었다. 카테고리 페이지에서는 특히 어느 카테고리 페이지가 가장 인기 있는지, 그리고 카테고리별 상품 탐색 성과가 어떻게 다른지 확인하는 것이 중요하다고 생각했다.

카테고리 페이지 방문 로그

카테고리 페이지 방문 로그는 사용자가 특정 카테고리 페이지에 진입했을 때 발생하도록 설계할 수 있다.

카테고리 페이지 방문

이벤트 이름은 category.pageview로 정의하였고 속성은 카테고리 ID를 포함시켰다. 이 로그를 통해 카테고리 페이지 방문자 수와 인당 방문 빈도를 계산할 수 있다. 카테고리 페이지 방문자 수는 특정 기간 동안 카테고리 페이지를 한 번 이상 방문한 고유 사용자 수로 측정할 수 있다. 특히 카테고리 ID를 함께 남기면 상의, 팬츠, 원피스, 아우터 등 카테고리별 방문자 수를 비교할 수 있다. 예를 들어 하루 동안 상의 카테고리 페이지 방문자가 2,000명, 팬츠 카테고리 페이지 방문자가 1,200명, 원피스 카테고리 페이지 방문자가 800명이라면 상의 카테고리의 인기가 가장 높다고 볼 수 있다. 인당 방문 빈도는 카테고리 페이지 전체 방문 횟수를 고유 방문자 수로 나누어 계산할 수 있다. 또한 카테고리별로도 계산할 수 있다. 특정 카테고리의 인당 방문 빈도가 높다면 사용자가 해당 카테고리를 반복적으로 탐색하고 있다는 의미로 볼 수 있다.

영역별 상품 노출 및 클릭 로그

카테고리 페이지의 상품에서는 위의 메인 페이지에서의 속성들과 상품이 어느 영역에서 노출되었는지, 상품의 카테고리가 무엇인지가 중요하다고 생각했다.

상품 노출, 상품 클릭

상품 노출 로그와 상품 클릭 로그의 이벤트명은 category.item_impression, category.item_click으로 정의하였고 속성은 카테고리 ID, 영역, 상품 ID, 상품 위치(순서), 무료배송 여부, 번개배송 여부, 할인율을 포함했다.

영역별 상품 클릭률은 상품 리스팅 영역에서 발생한 상품 클릭 수를 상품 노출 수로 나누어 계산할 수 있다. 예를 들어 팬츠 카테고리의 상품 리스팅 영역에서 상품이 30,000번 노출되고 2,100번 클릭되었다면 클릭률은 2,100 ÷ 30,000 × 100 = 7%가 된다. 이 지표를 카테고리별로 비교하면 어떤 카테고리의 상품 탐색 성과가 높은지 확인할 수 있다. 예를 들어 상의 카테고리의 클릭률은 높고 아우터 카테고리의 클릭률은 낮다면, 아우터 상품의 이미지나 가격, 시즌성, 상품 정렬 방식 등을 점검해볼 수 있다.

심화 지표로 추가로 고민한 부분

기본 요구사항을 생각보다 빠르게 완료해서 심화 요구사항도 조금 더 고민해보았다. 기본 요구사항에서는 주어진 지표를 계산할 수 있도록 로그를 설계하는 것이 핵심이었다면, 심화에서는 화면의 탐색 과정과 이탈을 더 잘 파악할 수 있는 지표를 추가하는 방향으로 생각했다.

메인 페이지 이탈률

메인 페이지 이탈

메인 페이지 이탈률은 사용자가 메인 페이지에 진입한 뒤 다른 페이지로 이동하거나 클릭 행동을 하지 않고 세션을 종료한 비율로 측정할 수 있다. 계산 방식은 메인 페이지 방문 후 추가 행동 없이 이탈한 세션 수를 메인 페이지 방문 세션 수로 나누는 방식이다.

예를 들어 하루 동안 메인 페이지 방문 세션이 2,000개였고, 그중 500개 세션이 배너 클릭, 상품 클릭, 카테고리 이동 등 추가 행동 없이 종료되었다면 메인 페이지 이탈률은 500 ÷ 2,000 × 100 = 25%가 된다. 이 지표를 보면 메인 페이지가 사용자의 다음 행동을 충분히 유도하고 있는지 확인할 수 있다. 이탈률이 높다면 메인 배너, 카테고리 퀵메뉴, 상품 영역 등의 매력도가 낮거나 사용자가 원하는 정보를 바로 찾지 못했을 가능성이 있다.

카테고리 페이지 이탈률

카테고리 페이지 이탈

카테고리 페이지 이탈률은 사용자가 카테고리 페이지에 진입한 뒤 상품 클릭, 카테고리 전환, 스크롤 등 추가 탐색 행동 없이 이탈한 비율로 측정할 수 있다. 계산 방식은 카테고리 페이지 방문 후 추가 행동 없이 종료된 세션 수를 카테고리 페이지 방문 세션 수로 나누는 방식이다. 이 지표는 카테고리 페이지가 사용자의 상품 탐색을 잘 유도하고 있는지 확인하는 데 도움이 된다. 특정 카테고리의 이탈률이 높다면 해당 카테고리의 상품 구성, 랭킹 영역, 정렬 방식, 상품 이미지, 가격대 등을 점검할 필요가 있다. 예를 들어 상의 카테고리의 이탈률은 15%인데 아우터 카테고리의 이탈률은 40%라면, 아우터 카테고리에서 사용자가 원하는 상품을 찾지 못하고 빠르게 이탈하고 있을 가능성을 생각해볼 수 있다.

상품 리스트 스크롤 깊이

상품 리스트 스크롤

상품 리스트 스크롤 깊이는 사용자가 상품 리스팅 영역을 어느 정도까지 탐색했는지 확인하기 위한 지표이다. 무한 스크롤 방식에서는 단순히 페이지 방문 여부만으로는 사용자가 상품을 얼마나 봤는지 알기 어렵다. 첫 화면에 보이는 상품만 보고 나갔는지, 여러 번 스크롤하면서 많은 상품을 탐색했는지 구분하기 위해 스크롤 로그가 필요하다.

이벤트 이름은 category.item_scroll로 정의하였고, 속성에는 카테고리 ID, 영역, 스크롤 깊이를 포함하였다. 스크롤 깊이는 25%, 50%, 75%, 100%와 같은 구간으로 측정할 수도 있고, 마지막으로 노출된 상품 위치 번호를 기준으로 측정할 수도 있다. 예를 들어 사용자가 상품 리스트에서 30번째 상품까지 봤다면 max_product_position_viewed = 30과 같이 남길 수 있다. 이 지표를 통해 사용자가 상품 리스트를 얼마나 깊게 탐색하는지 확인할 수 있다. 많은 사용자가 1~10번 상품까지만 보고 이탈한다면 앞쪽 상품 배치가 매우 중요하다고 볼 수 있고, 반대로 30번 이후 상품까지 보는 사용자가 많다면 상품 탐색 의도가 강한 사용자들이 많다고 해석할 수 있다.

이번 스프린트 미션에서 남은 것

이번 미션은 처음에는 필요한 지표가 많아 보여서 어려울 것 같았지만, 실제로 작업해보니 생각보다 빠르게 기본 요구사항을 완성할 수 있었다. 기존 요구사항을 완수하는 데 2시간 정도밖에 걸리지 않아서 조금 당황스러웠다. ㅋㅋ 물론 미션이 쉬웠다기보다는, 강사님과 함께 진행했던 실습 자료를 참고하면서 하다 보니 로그 설계의 기본 구조가 조금씩 익숙해진 것 같았다.

완성한 Tracking Plan

이번 미션을 통해 페이지 방문, 배너 노출, 배너 클릭, 카테고리 클릭, 상품 노출, 상품 클릭, 스크롤, 이탈과 같은 행동을 어떻게 이벤트로 정의할 수 있는지 정리해볼 수 있었다. 또한 각 이벤트에 어떤 속성을 포함해야 나중에 원하는 지표를 계산할 수 있는지도 함께 고민해볼 수 있었다. 로그 설계는 단순히 사용자가 클릭했다를 기록하는 것이 아니라, 이후에 어떤 분석을 할 것인지까지 고려해야 하는 작업이었다. 어떤 지표를 보고 싶은지에 따라 필요한 이벤트와 속성이 달라지고, 속성이 하나 빠지면 나중에 분석할 수 있는 범위도 제한될 수 있다. 이번 미션을 하면서 지표 설계와 로그 설계가 서로 연결되어 있다는 것을 느꼈다. 지난 미션에서는 AARRR 프레임워크를 통해 서비스 단계별로 어떤 지표를 볼지 고민했다면, 이번 미션에서는 그 지표를 실제로 계산하기 위해 어떤 로그가 필요한지 고민했다. 결국 데이터 분석은 데이터를 받은 뒤에만 시작되는 것이 아니라, 어떤 데이터를 남길지 설계하는 단계에서부터 시작된다는 것을 알 수 있었다. 이번 미션은 코드를 많이 작성하는 미션은 아니었지만, 실제 서비스 분석에서 필요한 사고방식을 연습할 수 있었던 미션이었다.

사용자 행동 로그 설계 | 문제 정의부터 Event, Attribute, Trigger, Tracking Plan까지 전체 정리

자유를원해 — Thu, 7 May 2026 00:40:37 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

‍♀️사용자 행동 로그 설계 정리

이 글은 사용자 행동 로그 설계 이론을 정리한 글이다. 프로덕트 데이터 분석에서 로그 데이터는 사용자의 행동을 이해하고, 기능 개선이나 지표 분석을 하기 위해 매우 중요한 데이터이다. 하지만 로그 데이터는 서비스 운영 과정에서 자동으로 항상 분석하기 좋게 쌓이는 데이터가 아니다. 분석에 필요한 데이터를 얻기 위해서는 어떤 행동을 기록할 것인지, 어떤 속성을 함께 남길 것인지, 언제 로그를 발생시킬 것인지 미리 설계해야 한다.

이번 글에서는 프로덕트 데이터 분석 프로세스에서 로그 설계가 어떤 위치에 있는지, 로그 설계가 왜 필요한지, 로그 설계를 하기 위해 알아야 하는 기초 지식은 무엇인지, 그리고 실제 이벤트 로그를 설계할 때 필요한 User Property, Event Property, Event, Attribute, Trigger, Tracking Plan까지 정리해보려고 한다.

프로덕트 데이터 분석 프로세스

프로덕트 데이터 분석 프로세스는 크게 다음과 같은 흐름으로 진행된다.

로그 및 문제 정의
데이터 조회
데이터 분석 및 인사이트 도출
데이터 시각화

각 단계의 역할은 다음과 같다.

단계	설명
로그 및 문제 정의	분석의 목적과 질문을 정의하는 단계
데이터 조회	어떠한 데이터가 필요한지 파악하고 핵심 지표를 선별하는 단계
데이터 분석 및 인사이트 도출	다양한 방법론과 도구를 활용하여 의미 있는 정보를 도출하는 단계
데이터 시각화	효과적인 결과 전달을 위해 데이터를 이해하기 쉽게 표현하는 단계

프로덕트 데이터 분석은 단순히 데이터를 조회하고 차트를 그리는 것으로 시작하지 않는다. 가장 먼저 해야 할 일은 무엇을 알고 싶은지, 어떤 문제를 해결하고 싶은지, 어떤 지표를 확인해야 하는지를 정의하는 것이다. 즉, 분석의 출발점은 데이터 자체가 아니라 문제 정의이다.

- 문제 정의가 중요한 이유

문제 정의는 분석의 방향을 결정한다. 문제가 명확하지 않으면 어떤 데이터를 봐야 하는지 알 수 없고, 어떤 지표를 계산해야 하는지도 정하기 어렵다. 또한 분석을 해도 결과가 실제 의사결정으로 연결되지 않을 가능성이 높다. 예를 들어 단순히 '사용자가 줄었다'라고만 생각하면 너무 막연하다. 하지만 이를 다음과 같이 나누면 분석 방향이 훨씬 명확해진다.

신규 사용자가 줄어든 것인가?
기존 사용자의 재방문이 줄어든 것인가?
특정 채널에서 유입이 줄어든 것인가?
특정 기능 사용 이후 이탈이 증가한 것인가?
결제 전환 단계에서 문제가 생긴 것인가?

이처럼 문제를 구체화해야 어떤 데이터를 확인해야 하는지 정할 수 있다. 따라서 로그 설계에서도 문제 정의는 매우 중요하다. 로그 데이터는 그냥 많이 쌓는 것이 아니라, 분석 목적에 맞게 필요한 행동을 기록하기 위해 설계하는 것이기 때문이다.

️로그 및 문제 정의 단계

로그 데이터는 그냥 적재하는 것이 아니다. 적재를 위한 로그 설계 작업을 먼저 거쳐야 한다. 로그 및 문제 정의 단계에서는 분석의 목적과 질문을 정의한다. 이때 문제를 구조적으로 정리하기 위해 여러 프레임워크를 사용할 수 있다. 대표적인 문제 정의 프레임워크는 다음과 같다.

MECE
Logic Tree
So What?
Why So?

이 프레임워크들은 문제를 빠짐없이 나누고, 원인을 구조화하고, 결론과 근거를 정리하는 데 사용된다.

MECE

MECE는 Mutually Exclusive Collectively Exhaustive의 줄임말이다. 한국어로는 상호 배타적이고 전체를 포괄하는 것을 의미한다. 조금 더 쉽게 말하면, 어떤 대상을 여러 그룹으로 나눌 때 다음 두 가지 조건을 만족해야 한다는 뜻이다.

Mutually Exclusive
각각의 분류가 서로 겹치지 않아야 한다.
Collectively Exhaustive
모든 분류를 합쳤을 때 전체를 빠짐없이 포함해야 한다.

즉, MECE하게 나눈다는 것은 중복 없이, 누락 없이 나누는 것이다.

- MECE 예시

고객을 나이 기준으로 나눈다고 하면 다음과 같이 나눌 수 있다.

구분	설명
0~14세	어린이와 청소년
15~24세	청소년 및 청년
25~44세	성인
45~64세	중년 및 장년
65세 이상	노년층

이 경우 각 나이대가 서로 겹치지 않고, 전체 연령대를 빠짐없이 포함한다. 따라서 MECE한 분류라고 볼 수 있다. 반대로 다음과 같이 나누면 MECE하지 않을 수 있다.

구분	분류 기준	MECE하지 않은 이유
10대	연령 기준	청소년과 범위가 겹칠 수 있다.
청소년	생애주기 기준	10대와 범위가 겹칠 수 있고, 법적·사회적 기준에 따라 범위가 달라질 수 있다.
대학생	신분 기준	연령 기준이 아니기 때문에 10대, 청소년, 직장인과 겹칠 수 있다.
직장인	직업 기준	연령 기준이 아니기 때문에 대학생과도 겹칠 수 있고, 다른 분류와 기준이 섞인다.

이 경우 10대와 청소년은 겹칠 수 있고, 대학생과 직장인도 연령 기준이 아니라 직업/상태 기준이기 때문에 분류 기준이 섞여 있다. 또한 전체 고객을 모두 포괄한다고 보기도 어렵다. 로그 설계나 지표 설계에서도 MECE는 중요하다. 예를 들어 유입 채널을 나눌 때도 검색, 광고, 추천, 직접 유입 등으로 중복과 누락이 없도록 기준을 잡아야 한다.

Logic Tree

Logic Tree는 문제를 정의할 때 MECE 관점을 기반으로 Tree 형태로 정리하는 방법이다. 문제를 큰 덩어리에서 작은 덩어리로 나누면서 원인을 파악하고, 현상을 분석하고, 해결책을 구체화할 때 유용하다. 예를 들어 '새로운 마케팅 전략'을 세운다고 하면 다음과 같이 나눌 수 있다.

새로운 마케팅 전략
├─ 고객 분석
│  ├─ 세그먼트
│  └─ 니즈와 선호
├─ 경쟁 분석
│  ├─ 경쟁사의 전략
│  └─ 시장 점유율
└─ 내부 자원
   ├─ 예산
   └─ 인력과 기술

이렇게 정리하면 막연한 문제를 여러 하위 요소로 나누어 볼 수 있다. Logic Tree를 사용할 때 중요한 점은 단순히 가지를 많이 뻗는 것이 아니라, 각 항목이 가능한 한 MECE하게 나뉘어야 한다는 점이다. 그래야 원인이나 해결책을 빠짐없이 검토할 수 있다.

‍♂️So What? Why So?

So What? Why So?는 핵심을 추려내고, 요점의 타당성을 증명하기 위한 프레임워크이다. 분석 결과를 해석할 때 단순히 숫자만 나열하면 의미 있는 인사이트가 되기 어렵다. 이때 그래서 무엇을 의미하는가?와 왜 그렇게 볼 수 있는가?를 반복해서 질문하면 결론과 근거를 더 명확히 정리할 수 있다.

- So What?

So What?은 분석 결과에서 핵심 결론을 뽑아내기 위한 질문이다. 다음과 같은 질문을 던질 수 있다.

결론은 무엇인가?
그래서 무엇인가?
무엇을 해야 하는가?
말하고자 하는 요점은 무엇인가?

예를 들어 '상품 상세 페이지 조회 수가 증가했다'라는 분석 결과가 있다고 하자. 여기서 So What?을 적용하면 다음과 같이 생각할 수 있다.

상품 상세 페이지 조회 수가 증가했다.
→ 그래서 무엇인가?
→ 사용자가 상품에 관심을 가지는 비율이 높아졌을 수 있다.
→ 무엇을 해야 하는가?
→ 상세 페이지 이후 장바구니 담기와 구매 전환율도 함께 확인해야 한다.

즉, So What?은 단순한 사실을 실제 의사결정으로 연결하기 위한 질문이다.

- Why So?

Why So?는 결론의 근거를 확인하기 위한 질문이다. 다음과 같은 질문을 던질 수 있다.

왜 그런가?
어떤 근거로 그렇게 말할 수 있는가?
다른 원인은 없는가?
더 이상 Why에 대한 생각이 나지 않을 때까지 질문할 수 있는가?

Why So?에서는 흔히 5 Why 방식도 사용할 수 있다. 5 Why는 어떤 현상의 원인을 파악하기 위해 왜?를 반복해서 묻는 방식이다. 예를 들어 구매 전환율이 낮아졌다는 문제가 있을 때 다음과 같이 질문할 수 있다.

구매 전환율이 낮아졌다.
→ 왜 낮아졌는가?
→ 장바구니에서 결제 페이지로 넘어가는 비율이 낮아졌다.
→ 왜 낮아졌는가?
→ 배송비가 결제 직전에 노출되고 있었다.
→ 왜 문제가 되는가?
→ 사용자가 예상하지 못한 추가 비용을 보고 이탈했을 가능성이 있다.

이처럼 Why So?는 결론이 단순한 추측이 아니라 근거를 가진 분석이 되도록 도와준다.

로그 설계

- 로그 설계란?

로그 데이터는 미리 데이터를 체계적으로 기록해 두어야 분석할 때 사용할 수 있다. 프로덕트 로그 설계는 쉽게 말해 일지의 형식을 정하고, 사용자 행동을 체계적으로 기록할 수 있도록 계획하는 것이다. 예를 들어 일기를 쓴다고 해도 아무 형식 없이 쓰면 나중에 원하는 정보를 찾기 어렵다. 반대로 날짜, 장소, 행동, 감정, 결과처럼 일정한 형식으로 기록하면 나중에 특정 패턴을 찾기 쉬워진다.

로그 데이터도 마찬가지이다. 사용자가 어떤 화면에 들어왔는지, 어떤 버튼을 눌렀는지, 어떤 상품을 봤는지, 어떤 경로로 결제했는지 등을 분석하려면 처음부터 기록 형식을 잘 설계해야 한다.

- 로그 설계와 로그 개발

로그 데이터를 전송하기 위한 개발은 그 앞단에서 기획 과정이 선행되어야 한다. 즉, 로그 설계는 로그 데이터 개발을 위한 기획 단계이다. 흐름은 다음과 같다.

로그 설계 → 로그 개발

로그 설계 단계에서는 분석가나 PM/PO가 어떤 로그가 필요한지 정의한다. 이후 개발자는 해당 설계를 바탕으로 실제 로그가 수집되도록 구현한다. 따라서 로그 설계가 명확하지 않으면 개발자가 어떤 시점에 어떤 데이터를 전송해야 하는지 알기 어렵다. 또한 나중에 데이터가 쌓이더라도 분석에 활용하기 어려운 형태가 될 수 있다.

️분석에 활용할 수 있는 데이터

분석에 활용할 수 있는 데이터는 크게 두 가지로 나눌 수 있다.

서비스 운영용 데이터
사용자 행동 데이터

구분	설명	예시
서비스 운영용 데이터	서비스가 제대로 돌아가기 위해 반드시 기록되어야 하는 데이터	회원 가입 정보, 상품명, 가격, 구매 정보
사용자 행동 데이터	사용자가 서비스 안에서 남기는 행동과 관련된 데이터	페이지 방문 정보, 버튼 클릭 정보, 배너 노출 정보

두 데이터는 모두 분석에 활용될 수 있지만, 생성되는 방식과 목적이 다르다.

- 서비스 운영용 데이터

서비스 운영용 데이터는 서비스가 제대로 돌아가기 위해 반드시 기록되어야 하는 정보이다. 이 데이터가 기록되지 않으면 서비스 자체가 정상적으로 작동하기 어렵다. 따라서 데이터 분석을 위해 별도로 요청하지 않아도 서비스 운영 과정에서 자연스럽게 데이터베이스에 저장된다. 예시는 다음과 같다.

고객의 회원 가입 정보
고객의 이름, 이메일, 가입일
상품의 이름과 가격
상품 재고 정보
고객의 상품 구매 정보
주문 번호
결제 금액
배송 상태

예를 들어 사용자가 상품을 구매했는데 구매 정보가 저장되지 않으면 주문 처리를 할 수 없다. 상품 가격이 저장되지 않으면 결제 금액을 계산할 수 없다. 회원 정보가 저장되지 않으면 로그인을 처리할 수 없다. 따라서 서비스 운영용 데이터는 서비스가 운영되기 위해 필수적으로 저장된다.

- 사용자 행동 데이터

사용자 행동 데이터는 사용자가 서비스 내에서 돌아다니면서 남기는 행동과 관련된 정보이다. 이 데이터는 서비스 운영 자체에는 반드시 필요하지 않을 수 있다. 하지만 사용자가 서비스를 어떻게 이용하는지 분석하기 위해서는 매우 중요하다. 예시는 다음과 같다.

고객의 페이지 방문 정보
특정 버튼 클릭 정보
상품 상세 페이지 조회 정보
배너 노출 정보
배너 클릭 정보
검색어 입력 정보
장바구니 담기 정보
특정 화면에서 이탈한 정보

사용자 행동 데이터는 다음과 같이도 불린다.

사용자 행동 로그
유저 로그 데이터
로그 데이터

사용자 행동 데이터는 데이터 분석을 원하는 사람이 별도로 기록을 요청해야 하는 경우가 많다. 즉, 분석을 위해 따로 설계하고 적재해야 하는 데이터이다.

- 서비스 운영용 데이터와 사용자 행동 데이터의 차이

두 데이터의 차이는 다음과 같이 정리할 수 있다.

구분	서비스 운영용 데이터	사용자 행동 데이터
목적	서비스 운영	사용자 행동 분석
저장 여부	서비스 운영을 위해 자연스럽게 저장	분석을 위해 별도 설계와 개발 필요
저장 위치	주로 데이터베이스	로그 수집 시스템, 데이터 레이크, 데이터 웨어하우스 등
예시	회원 정보, 상품 정보, 주문 정보	페이지 방문, 클릭, 노출, 스크롤, 검색
특징	없으면 서비스 운영이 어려움	없어도 서비스는 돌아가지만 분석이 어려움

서비스 운영용 데이터만으로도 매출, 주문 수, 회원 수 같은 전반적인 비즈니스 현황은 분석할 수 있다. 하지만 웹이나 앱의 구체적인 화면과 기능을 개선하고 싶다면 사용자 행동 데이터가 필요하다. 예를 들어 매출이 줄었다는 사실은 주문 데이터를 보면 알 수 있다.
하지만 왜 매출이 줄었는지, 사용자가 어느 화면에서 이탈했는지, 어떤 버튼을 누르지 않았는지, 어떤 배너가 클릭되지 않았는지는 사용자 행동 로그가 있어야 알 수 있다.

- 사용자 행동 데이터를 분석한다는 것

사용자 행동 데이터를 분석한다는 것은 로그 데이터를 활용하여 유저의 행동을 파악하고, 이를 바탕으로 프로덕트를 개선하는 것을 의미한다. 예를 들어 다음과 같은 질문에 답할 수 있다.

사용자는 어떤 경로로 유입되는가?
어떤 화면을 가장 많이 보는가?
어떤 버튼을 많이 클릭하는가?
어떤 단계에서 가장 많이 이탈하는가?
어떤 상품이 많이 노출되지만 클릭은 적은가?
어떤 배너가 클릭률이 높은가?
회원가입 과정 중 어느 단계에서 포기하는가?
장바구니에 담은 뒤 결제까지 이어지는 비율은 어느 정도인가?

이러한 질문에 답하려면 사용자의 행동이 기록되어 있어야 한다. 따라서 로그 데이터를 잘 활용하려면 미리 데이터를 체계적으로 기록해 두어야 한다.

- 로그 데이터 적재가 필요한 이유

서비스 운영용 데이터만으로도 전반적인 비즈니스 현황은 분석할 수 있다. 하지만 구체적인 화면이나 기능을 개선하고 싶다면 로그 데이터가 필요하다. 로그 데이터 적재가 필요한 이유는 크게 두 가지이다.

첫째, 로그 설계를 하지 않으면 자연스럽게 로그 데이터 전송을 위한 개발도 이루어지지 않는다. 사용자 행동 데이터는 서비스 운영에 필수적인 데이터가 아니기 때문에, 따로 요청하지 않으면 개발되지 않을 수 있다.

둘째, 로그 설계 없이 아무렇게나 데이터를 쌓으면 분석에 활용하기 어렵다. 로그 데이터를 어떻게든 전송하기만 하면 된다고 생각하고 체계 없이 개발하면, 이벤트 이름이나 속성 이름이 제각각이 되거나, 필요한 정보가 빠지거나, 같은 행동이 서로 다른 방식으로 기록될 수 있다.

예를 들어 같은 상품 클릭 이벤트가 다음처럼 제각각 쌓이면 분석이 어려워진다.

product_click
click_product
productClick
prd_click
item_click

이 경우 같은 행동을 의미하는 로그인데도 이벤트명이 다르기 때문에 데이터를 다시 정리해야 한다. 따라서 로그는 처음부터 목적과 기준을 가지고 설계해야 한다.

로그 설계 프로세스

로그 설계 프로세스는 다음 순서로 진행된다.

지표 기획
로그 설계
로깅, 로그 개발
QA

- 지표 기획

지표 기획은 특정 기능과 성과를 확인하기 위해 어떤 지표가 필요할지 기획하는 단계이다. 예를 들어 이커머스 앱의 메인 페이지 개편 효과를 확인하고 싶다면 다음과 같은 지표를 생각할 수 있다.

메인 페이지 방문 수
배너 노출 수
배너 클릭 수
배너 클릭률
상품 노출 수
상품 클릭 수
상품 클릭률
장바구니 담기 수
구매 전환율

지표를 먼저 정해야 어떤 로그가 필요한지도 정할 수 있다. 예를 들어 상품 클릭률을 계산하려면 상품 클릭 로그만 있어서는 부족하다. 클릭률은 보통 클릭 수 / 노출 수로 계산하기 때문에 상품 노출 로그도 필요하다.

- 로그 설계

로그 설계는 지표 기획을 바탕으로 어떤 로그를 어떻게 찍을지 계획하고 구조를 짜는 단계이다. 이 단계에서는 다음과 같은 내용을 정의한다.

어떤 이벤트를 기록할 것인가?
이벤트 이름은 무엇으로 할 것인가?
어떤 속성을 함께 기록할 것인가?
로그는 어느 시점에 발생시킬 것인가?
어떤 플랫폼에서 수집할 것인가?
어떤 버전부터 적용할 것인가?
기존 로그와 명명 규칙이 일관적인가?

로그 설계 단계에서는 Event, Attribute, Trigger를 정의하고, 이를 바탕으로 Tracking Plan을 작성한다.

- 로깅, 로그 개발

로깅 또는 로그 개발은 로그가 실제로 수집되도록 개발하는 단계이다. 로그 설계 문서가 만들어지면 개발자는 해당 문서를 기준으로 웹, 앱, 서버 등에 로그 수집 코드를 구현한다. 예를 들어 메인 페이지 상품 클릭 로그를 설계했다면, 개발자는 사용자가 메인 페이지에서 상품 영역을 클릭했을 때 해당 이벤트가 전송되도록 구현한다.

- QA

QA는 데이터가 로그 설계 단계에서 의도한 대로 잘 찍히는지 확인하는 단계이다. QA에서는 다음과 같은 내용을 확인할 수 있다.

이벤트가 의도한 시점에 발생하는가?
이벤트명이 설계 문서와 일치하는가?
필요한 속성이 빠지지 않고 들어오는가?
데이터 타입이 맞는가?
웹, Android, iOS 등 플랫폼별로 동일하게 수집되는가?
중복으로 찍히거나 누락되는 로그는 없는가?
특정 조건에서만 발생해야 하는 로그가 모든 상황에서 찍히고 있지는 않은가?

로그 QA는 매우 중요하다. 로그가 잘못 쌓이면 이후 분석 결과도 잘못될 수 있기 때문이다.

- 로그 설계 단계별 주체

각 단계별 주요 주체는 다음과 같다.

단계	주요 주체
지표 기획	데이터 분석가, PM/PO
로그 설계	데이터 분석가, PM/PO
로깅, 로그 개발	개발자
QA	PM/PO, QA팀

물론 실제 업무에서는 회사 구조에 따라 역할이 조금씩 달라질 수 있다. 다만 일반적으로 분석가와 PM/PO는 어떤 지표와 로그가 필요한지 정의하고, 개발자는 실제 수집을 구현하며, QA팀은 설계대로 동작하는지 확인한다.

로그 설계에 필요한 기초 지식

로그 설계를 잘하려면 어떤 데이터가 어디에서 발생하는지 이해해야 한다. 그래야 어떤 개발자에게 요청해야 하는지, 수정이 필요한 경우 얼마나 빠르게 반영할 수 있는지 파악할 수 있다. 로그 설계에 필요한 기초 지식은 다음과 같다.

클라이언트와 서버
웹과 앱
웹뷰
데이터베이스와 파일
데이터 레이크와 데이터 웨어하우스
ETL

- 클라이언트와 서버

클라이언트와 서버는 다음과 같은 구조로 이해할 수 있다.

클라이언트 → 요청 Request → 서버
서버 → 응답 Response → 클라이언트

클라이언트는 사용자가 직접 보는 화면이고, 서버는 클라이언트의 요청을 받아 처리한 뒤 응답을 내려주는 역할을 한다.

- 클라이언트

클라이언트는 사용자들이 직접 상호작용하는 앱이나 웹 화면을 의미한다. 즉, 유저 인터페이스에 해당한다. 화면 내에서 발생하는 사용자 행동과 관련된 데이터는 보통 클라이언트에서 발생한다. 예시는 다음과 같다.

사용자가 어떤 화면에 진입했는지
사용자가 어떤 버튼을 클릭했는지
사용자가 어떤 배너를 봤는지
사용자가 어떤 상품 영역을 클릭했는지
사용자가 스크롤을 어디까지 내렸는지

클라이언트는 보통 다음 개발자가 담당한다.

프론트엔드 개발자
웹 개발자
Android 개발자
iOS 개발자

따라서 화면에서 발생하는 사용자 행동 로그를 설계할 때는 해당 화면을 담당하는 클라이언트 개발자와 협업하는 경우가 많다.

- 서버

서버는 사용자의 눈에 직접 보이지는 않지만, 클라이언트의 요청을 받아 응답을 내려주는 역할을 한다. 예를 들어 사용자가 앱에서 상품 상세 페이지를 열면, 클라이언트는 서버에 해당 상품 정보를 요청한다. 서버는 상품명, 가격, 할인율, 재고 상태 등의 정보를 응답으로 내려준다. 상황에 따라 화면에 표시되는 정보가 달라지는 경우, 대부분 클라이언트에서 서버를 통해 받아온 정보이다. 예시는 다음과 같다.

계속 변동하는 상품의 할인가 정보
사용자별 추천 상품 목록
로그인 여부에 따라 달라지는 화면 정보
사용자 등급에 따라 달라지는 혜택 정보
재고 상태에 따라 달라지는 구매 가능 여부

서버는 보통 백엔드 개발자가 담당한다.

- 웹뷰 WebView

웹뷰는 앱 안에서 웹으로 구현된 페이지를 띄우는 개념이다. 즉, 사용자는 앱을 사용하고 있다고 느끼지만, 실제 특정 화면은 웹 페이지로 구현되어 앱 안에서 보여질 수 있다. 웹뷰는 앱 안에서 웹으로 구현된 페이지를 띄우는 개념이므로, 보통 웹 개발자에 의해 구현된다. 로그 설계 시 웹뷰 여부를 확인하는 것이 중요한 이유는 다음과 같다.

해당 화면을 앱 개발자가 담당하는지 웹 개발자가 담당하는지 달라질 수 있다.
로그 수집 방식이 네이티브 앱 화면과 다를 수 있다.
수정 반영 속도도 달라질 수 있다.

따라서 어떤 화면의 로그를 설계할 때, 그 화면이 네이티브 앱 화면인지 웹뷰인지 확인하는 것이 좋다.

- 웹과 앱

클라이언트는 보통 웹과 앱으로 나뉜다. 웹은 일반적인 웹 사이트를 의미하고, 앱은 Android나 iOS 어플리케이션을 의미한다.

데이터가 어디에서 발생하는지 알아둬야 하는 이유는 배포의 용이성 때문이다. 데이터가 어디에서 발생하는지 알면 다음을 파악할 수 있다.

어떤 개발자에게 요청해야 하는지
로깅 이슈가 있을 때 어디를 수정해야 하는지
수정 사항을 얼마나 빠르게 반영할 수 있는지
플랫폼별로 로그 수집 방식이 달라지는지

- 웹, 서버, Android, iOS의 수정 반영 속도

웹과 서버는 상대적으로 재배포가 수월한 편이다. 반면 Android나 iOS와 같은 앱은 사용자가 앱 업데이트를 해야 하거나 앱스토어 심사 과정을 거쳐야 하므로 빠르게 수정하기 어렵다. 특히 iOS는 Android보다 승인이 엄격한 편이다.

구분	수정 반영 특징
웹	빠른 수정 가능
서버	빠른 수정 가능
Android	상대적으로 느린 수정 반영
iOS	느린 수정 반영

이 차이는 로그 설계와 QA에서도 중요하다. 예를 들어 웹 로그에 문제가 있으면 비교적 빠르게 수정할 수 있지만, 앱 로그에 문제가 있으면 수정 버전을 배포하고 사용자가 업데이트해야 하기 때문에 데이터 오류가 더 오래 남을 수 있다. 따라서 앱 로그는 설계와 QA 단계에서 더 신중하게 확인해야 한다.

데이터베이스와 파일

- 데이터베이스

서비스 운영 목적의 데이터는 보통 데이터베이스에 저장된다. 데이터베이스는 체계적으로 구조화되어 있어서 데이터를 빠르게 기록하고 조회할 수 있다. 회원 정보, 주문 정보, 상품 정보처럼 서비스 운영에 직접 필요한 데이터는 데이터베이스에 저장되는 경우가 많다. 흐름은 다음과 같다.

데이터 → 데이터베이스

해당 데이터는 주로 서비스 운영용 데이터이다. 예시는 다음과 같다.

회원 정보
상품 정보
주문 정보
결제 정보
배송 정보

- 파일

서비스 운영과 직접 관련이 없는 데이터는 일단 파일 단위로 쌓이는 경우가 많다. 로그 데이터는 대량으로 발생하고, 형식이 유연하게 변할 수 있으며, 서비스 운영용 데이터처럼 즉시 조회되어야 하는 데이터가 아닐 수 있다. 따라서 일단 파일 단위로 저장한 뒤, 이후 분석에 적합한 형태로 정리할 수 있다. 흐름은 다음과 같다.

데이터 → 파일 → 데이터 레이크

해당 데이터는 주로 서비스 운영과 관련 없는 데이터, 즉 로그 데이터이다.

- 데이터 레이크

데이터 레이크는 구조화되지 않은 대량의 데이터 파일을 쌓아둘 수 있는 보관소 개념이다. 로그 데이터는 처음부터 완전히 정제된 테이블 형태로 들어오기보다는, 파일 형태로 쌓인 뒤 나중에 정리되는 경우가 많다. 이때 원천 데이터를 보관하는 공간을 데이터 레이크라고 이해할 수 있다.

- 데이터 웨어하우스

데이터 웨어하우스는 분석에 활용하기 좋도록 정리된 데이터를 저장하는 공간이다. 서비스 운영과 관련 없는 로그 데이터는 보통 다음과 같은 흐름을 거칠 수 있다.

데이터 → 파일 → 데이터 레이크 → 데이터 웨어하우스

즉, 로그 데이터가 처음에는 파일 단위로 데이터 레이크에 보관되고, 이후 일정한 시간 주기로 정리되어 데이터 웨어하우스로 옮겨진다.

- ETL

데이터 레이크에 쌓인 데이터를 데이터 웨어하우스로 옮길 때 ETL 과정이 일어난다. ETL은 다음의 줄임말이다.

용어	의미	설명
Extract	추출	필요한 데이터를 꺼내는 단계
Transformation	변환	분석하기 좋은 형태로 가공하는 단계
Load	적재	변환한 데이터를 목적지에 저장하는 단계

즉, ETL은 데이터를 추출하고, 변환하고, 적재하는 과정이다. 로그 데이터는 보통 발생량이 많고 원천 형태가 복잡할 수 있기 때문에, 분석에 활용하려면 ETL 과정을 통해 정리하는 것이 중요하다.

️이벤트 로그 설계하기

- User Property와 Event Property

로그 데이터는 크게 두 가지 정보를 담는다.

어떤 특성의 유저가
어떤 행동을 했는가

예시는 다음과 같다.

어떤 특성의 유저가	어떤 행동을 했는가
20대 로그인 유저가	주문 배송 페이지를 조회했다
페이스북 광고를 통해 유입된 유저가	A 상품의 상세 페이지를 조회했다
VIP 등급의 여성 유저가	3번 프로모션 배너를 조회했다

여기서 '어떤 특성의 유저가'에 해당하는 정보는 User Property이고, '어떤 행동을 했는가'에 해당하는 정보는 Event Property와 연결된다.

- User Property

User Property는 사용자의 특성을 나타내는 정보이다. 예시는 다음과 같다.

유저 ID
나이
성별
멤버십 등급
가입일
로그인 여부
유입 채널
기기 정보
앱 버전

User Property는 크게 두 가지로 나누어 생각할 수 있다.

첫째, 서비스 운영용 데이터에 이미 저장되어 있는 사용자 특성이다. 예를 들어 유저의 나이, 성별, 멤버십 정보 등은 회원 정보나 고객 정보 테이블에 이미 저장되어 있을 수 있다. 이런 정보는 로그 설계 시 매번 새롭게 고민할 필요가 적다.

둘째, 시점별로 달라질 수 있는 사용자 특성이다. 예를 들어 사용자가 특정 시점에 로그인 상태였는지, 어떤 유입 채널을 통해 들어왔는지, 어떤 앱 버전을 사용하고 있었는지는 이벤트 발생 시점에 함께 기록되어야 분석에 유용하다.

즉, User Property는 단순히 고정된 회원 정보만 의미하는 것이 아니라, 이벤트가 발생한 시점의 사용자 상태를 설명하는 정보까지 포함할 수 있다.

- Event Property

Event Property는 사용자가 어떤 행동을 했는지 설명하는 정보이다. Event Property는 육하원칙 중 다음 구조를 바탕으로 설계할 수 있다.

누가
언제
어디서
무엇을
어떻게

예시는 다음과 같다.

누가	언제	어디서	무엇을	어떻게
123번 유저가	6/18 2시 31분에	A 페이지에서	X 버튼을	클릭했다
451번 유저가	6/18 3시 17분에	B 페이지에서	Y 버튼을	확인했다

이벤트 로그는 사용자의 행동을 기록하는 데이터이므로, 최소한 누가, 언제, 어디서, 무엇을, 어떻게 했는지 설명할 수 있어야 한다.

- 이벤트 로그가 갖춰야 할 공통 정보

이벤트 로그에서 '누가'와 '언제'는 모든 데이터에 기록되어야 하는 공통 정보이다.

구분	예시
누가	User ID, Device ID
언제	클라이언트 접근 시각, 서버 접근 시각

'누가'와 '언제'는 신규 화면이나 기능을 만들 때마다 매번 새롭게 설계할 필요는 없다. 모든 로그에 공통적으로 들어가야 하는 정보이기 때문에, 필수 적재 규칙으로 관리하는 것이 좋다. 예를 들어 실제 로그에는 다음과 같은 공통 정보가 들어갈 수 있다.

user_id
device_id
device
app_version
os
client_access_timestamp
server_access_timestamp

이러한 공통 정보가 있어야 특정 행동을 어떤 사용자가 언제 했는지 분석할 수 있다.

Event, Attribute, Trigger

Event Property를 설계할 때에는 크게 세 가지를 고려해야 한다.

Event
Attribute
Trigger

- Event

Event는 어떤 행위에 대한 로그인지를 의미한다. 즉, 사용자가 한 행동의 이름이다. 예시는 다음과 같다.

상품 노출
상품 클릭
페이지 방문
배너 클릭
검색 실행
장바구니 담기
주문 완료

영문 이벤트명으로는 다음과 같이 표현할 수 있다.

pageview
visit
click
impression
view
add_to_cart
purchase

Event는 분석의 가장 기본 단위가 된다. 따라서 이벤트 이름은 어떤 행동을 의미하는지 명확해야 한다.

- Attribute

Attribute는 Event의 부가 속성이다. 즉, 해당 이벤트와 관련해서 함께 저장해야 하는 정보이다. 예를 들어 '상품 클릭' 이벤트가 발생했을 때 단순히 상품을 클릭했다는 사실만 저장하면 분석에 한계가 있다. 어떤 상품을 클릭했는지, 어떤 화면에서 클릭했는지, 몇 번째 위치의 상품을 클릭했는지 함께 저장해야 더 유용하다. 예시는 다음과 같다.

Event	Attribute 예시
상품 노출	상품 ID, 상품명, 카테고리, 노출 위치, 할인율
상품 클릭	상품 ID, 클릭 위치, 페이지명, 섹션명
배너 클릭	배너 ID, 배너명, 배너 위치, 랜딩 URL
검색 실행	검색어, 검색 결과 수, 필터 적용 여부
장바구니 담기	상품 ID, 수량, 가격, 옵션

Attribute는 이벤트를 분석 가능한 수준으로 구체화하는 역할을 한다.

- Trigger

Trigger는 해당 로그 데이터를 어느 시점에 발생시킬 것인지를 의미한다. 즉, '언제 로그를 찍을 것인가?'에 대한 기준이다. 예를 들어 상품 노출 로그를 설계할 때 다음과 같이 모호하게 작성하면 문제가 생길 수 있다.

상품이 유저에게 보이면 노출 로그를 찍어주세요.

이 문장만으로는 기준이 명확하지 않다. 다음과 같은 질문이 생길 수 있다.

상품 이미지가 100% 보이면 전송해야 하는가?
상품 이미지가 1%라도 보이면 전송해야 하는가?
화면에 0.1초만 보여도 노출로 볼 것인가?
사용자가 빠르게 스크롤해서 지나간 것도 노출로 볼 것인가?
같은 상품이 다시 보이면 노출을 다시 찍을 것인가?

따라서 Trigger는 구체적으로 정의해야 한다. 예를 들어 다음과 같이 작성할 수 있다.

상품 이미지 영역의 60% 이상이 화면에 노출되었을 때 상품 노출 로그를 전송한다.

이렇게 작성하면 개발자와 분석자가 같은 기준으로 로그를 이해할 수 있다.

- Event, Attribute, Trigger 예시

항목	설명	예시
Event	어떤 행위에 대한 로그인지	product_impression
Attribute	이벤트와 함께 저장할 부가 정보	product_id, page_name, section_name
Trigger	로그가 발생하는 시점	상품 이미지의 60% 이상이 화면에 노출된 경우

정리하면 Event는 행동의 이름, Attribute는 행동에 대한 부가 정보, Trigger는 행동이 기록되는 시점이다.

대표적인 이벤트 로그

대표적인 이벤트 로그에는 다음이 있다.

방문
클릭
노출

- 방문 이벤트

방문 이벤트는 사용자가 특정 페이지나 화면에 진입했을 때 발생하는 로그이다. 예시는 다음과 같다.

pageview
visit
screen_view

방문 이벤트는 사용자가 어떤 화면에 얼마나 들어왔는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

메인 페이지 방문 수
상품 상세 페이지 방문 수
카테고리 페이지 방문 수
결제 페이지 진입 수
특정 화면까지 도달한 사용자 수

- 클릭 이벤트

클릭 이벤트는 사용자가 버튼, 배너, 상품, 메뉴 등 특정 요소를 클릭했을 때 발생하는 로그이다. 예시는 다음과 같다.

click
product_click
banner_click
button_click

클릭 이벤트는 사용자가 실제로 어떤 요소에 관심을 보였는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

배너 클릭률
상품 클릭률
CTA 버튼 클릭률
메뉴 클릭 수
필터 클릭 수

클릭률을 계산하려면 클릭 로그뿐만 아니라 노출 로그도 필요할 수 있다.

클릭률 = 클릭 수 / 노출 수

따라서 클릭 이벤트를 설계할 때는 해당 클릭의 기준이 되는 노출 이벤트도 함께 고려해야 한다.

- 노출 이벤트

노출 이벤트는 특정 요소가 사용자 화면에 보여졌을 때 발생하는 로그이다. 예시는 다음과 같다.

impression
view
product_impression
banner_impression

노출 이벤트는 사용자가 어떤 요소를 볼 기회가 있었는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

상품 노출 수
배너 노출 수
추천 영역 노출 수
노출 대비 클릭률
노출 대비 구매 전환율

노출 이벤트는 Trigger 기준이 특히 중요하다. 어디까지를 '보였다'고 볼 것인지 명확히 정의하지 않으면 플랫폼이나 개발자마다 다르게 구현될 수 있기 때문이다.

- 서비스 도메인에 따라 달라지는 이벤트

이벤트 명칭은 회사나 서비스마다 달라질 수 있다. 또한 서비스 도메인에 따라 자주 사용하는 이벤트도 달라진다. 예를 들어 이커머스 서비스에서는 다음과 같은 이벤트를 자주 사용할 수 있다.

이벤트	예시 이벤트명
상품 찜	save_product
장바구니 담기	add_to_cart
상품 클릭	product_click
상품 노출	product_impression
주문 완료	purchase
결제 시작	begin_checkout

반면 콘텐츠 서비스에서는 콘텐츠 재생, 구독, 좋아요, 댓글 작성 등의 이벤트가 더 중요할 수 있다. 따라서 이벤트 로그는 서비스의 목적과 도메인에 맞게 설계해야 한다.

이벤트 로그 설계 시 고려할 점

로그를 설계할 때는 크게 세 가지를 고려해야 한다.

목적성
유용성
통일성

- 목적성

목적성은 해당 로그가 어떤 지표 계산에 사용될지 고려하는 것이다. 로그는 많이 쌓는다고 무조건 좋은 것이 아니다. 불필요하게 많은 로그를 남기면 저장 비용과 관리 비용이 증가하고, 분석할 때도 복잡해진다. 반대로 너무 적은 로그만 남기면 필요한 지표를 계산할 수 없다. 따라서 로그를 설계할 때는 먼저 분석 목적과 지표를 명확히 해야 한다. 예를 들어 목표가 '할인율별 상품 클릭률 비교'라면 필요한 데이터는 다음과 같다.

상품 노출 로그
상품 클릭 로그
상품별 할인율 정보

이때 상품 클릭 로그만 있으면 클릭률을 계산할 수 없다. 클릭률을 계산하려면 분모인 노출 수가 필요하기 때문이다.

상품 클릭률 = 상품 클릭 수 / 상품 노출 수

또한 할인율별로 비교하려면 상품별 할인율 정보도 필요하다. 따라서 목적에 맞는 로그와 속성을 함께 설계해야 한다.

- 유용성

유용성은 로그가 분석에 활용하기 쉬운 형태로 설계되어야 한다는 의미이다. 유용한 로그는 다음 조건을 만족해야 한다.

이름이 이해하기 쉬워야 한다.
추출하기 쉬워야 한다.
가공하기 쉬워야 한다.
너무 복잡한 형태로 전송하지 않아야 한다.
이벤트명과 속성명이 의미를 명확히 담고 있어야 한다.

좋지 않은 예시는 다음과 같다.

product_interaction
123_product_click

product_interaction은 상품과 관련된 상호작용이라는 뜻은 있지만, 클릭인지 노출인지 장바구니 담기인지 명확하지 않다. 123_product_click은 이벤트명 앞에 숫자가 붙어 있어 의미를 파악하기 어렵고, 관리하기에도 좋지 않다. 더 명확한 이벤트명은 다음과 같이 작성할 수 있다.

product_click
product_impression
add_to_cart
main_banner_click

이처럼 로그 이름은 분석가, PM, 개발자가 모두 이해할 수 있도록 명확해야 한다.

- 통일성

통일성은 로그 설계 기준을 정하고, 전사적으로 일관된 방식으로 로그를 관리하는 것이다. 로그가 기능별, 팀별, 플랫폼별로 제각각 설계되면 분석이 매우 어려워진다. 예를 들어 같은 의미의 이벤트가 다음처럼 다르게 기록될 수 있다.

product_click
productClick
click_product
prd_click

이 경우 데이터를 합치거나 비교하기 위해 추가 작업이 필요하다. 따라서 로그 설계에서는 다음과 같은 기준을 정해야 한다.

이벤트명은 snake_case를 사용할 것인지 camelCase를 사용할 것인지
페이지명은 어떤 기준으로 작성할 것인지
클릭 이벤트는 어떤 접미사를 사용할 것인지
노출 이벤트는 impression으로 통일할 것인지 view로 통일할 것인지
속성명은 product_id로 할 것인지 item_id로 할 것인지
플랫폼별로 동일한 이벤트명을 사용할 것인지

예를 들어 명명 규칙을 snake_case로 정했다면 다음처럼 일관되게 작성해야 한다.

main_pageview
main_banner_impression
main_banner_click
main_product_impression
main_product_click

통일성을 위해서는 Event Plan이나 Event Taxonomy를 만들 수 있다. 이러한 문서는 전사적으로 로그 설계 기준을 맞추는 데 도움을 준다.

Tracking Plan

- Tracking Plan이란?

Tracking Plan은 전사적인 로그 통일성을 지키기 위해 로그 설계 내용을 체계적으로 정리해두는 문서이다. Tracking Plan은 다음과 같이도 불린다.

Event Taxonomy
이벤트 정의서
로그 기획서
로그 명세서

Tracking Plan은 주로 다음 도구를 사용해서 정리한다.

Google Sheet
Notion
Amplitude
Mixpanel 등의 프로덕트 분석 솔루션

Tracking Plan은 단순히 로그 목록을 적어두는 문서가 아니다. 어떤 이벤트를, 어떤 이름으로, 어떤 속성과 함께, 어떤 시점에, 어떤 플랫폼에서 수집할 것인지 정리하는 기준 문서이다.

- Tracking Plan이 필요한 이유

Tracking Plan이 필요한 이유는 크게 두 가지이다.

전사적인 로그의 통일성 유지
효율적인 데이터 탐색 가능

Tracking Plan이 없으면 같은 기능을 두고도 사람마다 다른 이름으로 로그를 설계할 수 있다. 또한 나중에 데이터를 분석하려고 할 때 어떤 이벤트가 무엇을 의미하는지 파악하기 어렵다. Tracking Plan이 있으면 다음과 같은 장점이 있다.

이벤트의 의미를 쉽게 확인할 수 있다.
어떤 속성이 함께 들어오는지 알 수 있다.
로그 발생 시점을 확인할 수 있다.
플랫폼별 수집 여부를 확인할 수 있다.
버전 변경 이력을 관리할 수 있다.
개발자와 분석가가 같은 기준으로 소통할 수 있다.

- Tracking Plan을 작성해야 하는 시점

Tracking Plan은 다음과 같은 시점에 작성해야 한다.

신규 기능을 출시할 때
기존 기능 중 로깅이 되어 있지 않은 부분에 대해 새로 로깅이 필요할 때
기존에 있던 기능을 수정하거나 삭제할 때

신규 기능을 출시할 때는 해당 기능의 성과를 측정하기 위해 어떤 로그가 필요한지 미리 정의해야 한다. 기존 기능에 로깅이 없다면 분석을 위해 새롭게 로그를 추가해야 한다. 기존 기능을 수정하거나 삭제할 때는 기존 로그도 함께 수정하거나 더 이상 사용하지 않도록 관리해야 한다. 기능은 바뀌었는데 로그는 그대로 남아 있으면, 데이터 해석에 오류가 생길 수 있다.

- Tracking Plan 작성 시 공통 정보 처리

'누가', '언제'와 같이 모든 로그에 공통적으로 들어가야 하는 정보는 Tracking Plan에 매번 별도로 정리하지 않아도 된다. 대신 필수적으로 적재하도록 규칙을 정해 둔다. 예를 들어 다음과 같은 정보는 공통 정보로 관리할 수 있다.

user_id
device_id
device
app_version
timestamp
client_access_timestamp
server_access_timestamp

따라서 Tracking Plan에서는 주로 event와 event_attribute를 중심으로 설계한다. event와 event_attribute만 잘 설계해도 실제 유저의 이벤트 로그에는 공통 정보와 이벤트 정보가 함께 적재된다.

✏️Tracking Plan 작성 항목

Tracking Plan을 작성할 때는 보통 다음과 같은 항목을 정리한다.

항목	설명
이벤트 설명	어떤 이벤트인지 설명
기획서 혹은 디자인 문서	관련 문서 링크
event	이벤트명
event_attribute	이벤트 속성
Description	이벤트 속성 설명
Trigger	로그 발생 시점
State	상태
Platform	플랫폼
Last Update Version	마지막 업데이트 버전

각 항목을 자세히 보면 다음과 같다.

- 이벤트 설명

이벤트 설명은 해당 이벤트가 어떤 사용자 행동을 의미하는지 적는 항목이다. 예를 들어 main_banner_click이라는 이벤트가 있다면, 이벤트 설명에는 '메인 페이지에서 배너를 클릭했을 때 발생하는 이벤트'라고 작성할 수 있다.

- 기획서 혹은 디자인 문서

기획서 혹은 디자인 문서 항목에는 해당 이벤트와 관련된 문서 링크를 넣는다. 로그 설계는 보통 화면 개발 전에 진행되므로, 디자인 파일이나 기획서를 보면서 어떤 화면 요소에 로그를 심을지 결정한다. 관련 문서 링크가 있으면 개발자나 QA 담당자가 어떤 화면의 어떤 요소를 의미하는지 쉽게 확인할 수 있다.

- event

event는 이벤트명을 의미한다. 예시는 다음과 같다.

main_pageview
main_banner_impression
main_banner_click
main_product_impression
main_product_click
category_pageview
category_quick_menu_click

event는 사용자의 행동을 대표하는 이름이므로 명확하고 일관되게 작성해야 한다.

- event_attribute

event_attribute는 이벤트와 함께 수집할 속성이다. 예를 들어 main_product_click 이벤트라면 다음과 같은 속성을 함께 수집할 수 있다.

product_id
product_name
product_category
product_price
product_discount_rate
section_name
product_index

속성이 있어야 이벤트를 더 세부적으로 분석할 수 있다. 상품 클릭 수만 아는 것보다 어떤 상품이 클릭되었는지, 어떤 위치의 상품이 클릭되었는지 아는 것이 훨씬 유용하다.

- Description

Description은 event_attribute가 무엇을 의미하는지 설명하는 항목이다. 예를 들어 product_id라는 속성이 있다면 Description에는 '클릭한 상품의 고유 ID'라고 작성할 수 있다. 속성명만 보고 의미가 명확하지 않을 수 있으므로 Description을 함께 작성하는 것이 좋다.

- Trigger

Trigger는 이벤트가 발생하는 시점이다. 예를 들어 다음과 같이 작성할 수 있다.

event	Trigger
main_pageview	사용자가 메인 페이지에 진입했을 때
main_banner_impression	배너 영역의 60% 이상이 화면에 노출되었을 때
main_banner_click	사용자가 메인 페이지 배너를 클릭했을 때
main_product_click	사용자가 메인 페이지 상품 영역을 클릭했을 때

Trigger는 개발자가 실제 로그를 구현할 때 기준이 되므로 구체적으로 작성해야 한다.

- State

State는 해당 로그의 상태를 의미한다. 예를 들어 다음과 같이 관리할 수 있다.

기획 완료
개발 중
개발 완료
QA 중
QA 완료
배포 완료
삭제 예정
사용 중단

State를 관리하면 현재 로그 설계와 개발 진행 상황을 파악하기 쉽다.

- Platform

Platform은 해당 로그가 수집되는 플랫폼을 의미한다. 예시는 다음과 같다.

Web
Android
iOS
Server
WebView

플랫폼별로 로그 수집 여부가 다를 수 있기 때문에, Tracking Plan에 플랫폼을 명확히 적어두는 것이 좋다.

- Last Update Version

Last Update Version은 마지막으로 업데이트된 버전을 의미한다. 앱 서비스에서는 버전별로 로그가 다르게 동작할 수 있다. 따라서 어떤 버전부터 해당 로그가 적용되었는지 관리해야 한다. 버전 정보를 관리하면 특정 기간의 로그 누락이나 변경 사항을 추적할 때 유용하다.

Tracking Plan 예시

예를 들어 메인 페이지와 카테고리 페이지를 대상으로 Tracking Plan을 작성한다면 다음과 같은 이벤트를 정의할 수 있다.

- 메인 페이지 이벤트 예시

이벤트 설명	event	Trigger
메인 페이지 진입	main_pageview	사용자가 메인 페이지에 진입했을 때
메인 페이지 배너 노출	main_banner_impression	메인 배너가 기준 이상 화면에 노출되었을 때
메인 페이지 배너 클릭	main_banner_click	사용자가 메인 배너를 클릭했을 때
메인 페이지 상품 노출	main_product_impression	메인 페이지 상품이 기준 이상 화면에 노출되었을 때
메인 페이지 상품 클릭	main_product_click	사용자가 메인 페이지 상품을 클릭했을 때

- 카테고리 페이지 이벤트 예시

이벤트 설명	event	Trigger
카테고리 페이지 진입	category_pageview	사용자가 카테고리 페이지에 진입했을 때
카테고리 페이지 배너 노출	category_banner_impression	카테고리 배너가 기준 이상 화면에 노출되었을 때
카테고리 페이지 배너 클릭	category_banner_click	사용자가 카테고리 배너를 클릭했을 때
카테고리 페이지 퀵메뉴 노출	category_quick_menu_impression	퀵메뉴가 기준 이상 화면에 노출되었을 때
카테고리 페이지 퀵메뉴 클릭	category_quick_menu_click	사용자가 퀵메뉴를 클릭했을 때

- 실제 이벤트 로그 적재 예시

event와 event_attribute를 설계하면 실제 이벤트 로그에는 공통 정보와 이벤트 정보가 함께 적재된다. 공통 정보 예시는 다음과 같다.

user_id
device
app_version
client_access_timestamp

이벤트 정보 예시는 다음과 같다.

event
event_attribute

예를 들어 실제 로그에는 다음과 같은 이벤트가 들어올 수 있다.

main_pageview
main_banner_impression
main_product_impression
main_product_click

이때 각 이벤트에는 user_id, device, app_version, timestamp 같은 공통 정보가 함께 붙는다.

- Tracking Plan을 더 세분화한 예시

Tracking Plan을 더 세분화해서 작성할 수도 있다. 예를 들어 이벤트명을 하나로만 관리하는 대신, page, action, target 등으로 쪼개서 관리할 수 있다. Tracking Plan에 포함될 수 있는 항목은 다음과 같다.

page
action
target
target_section
target_value
target_index
Trigger
State
Platform
Version
Update Date

실제 이벤트 로그에는 다음과 같은 항목이 들어올 수 있다.

user_id
device
app_version
timestamp
page
action
target
target_section
target_value
target_index

예를 들어 메인 페이지의 첫 번째 배너 클릭 로그라면 다음과 같이 기록할 수 있다.

항목	값 예시
page	main
action	click
target	banner
target_section	top_banner
target_value	spring_sale
target_index	1

이렇게 세분화하면 이벤트명을 너무 많이 만들지 않고도 구조적으로 로그를 관리할 수 있다.

데이터 타입을 표현하는 용어들

Tracking Plan을 작성할 때는 속성이 갖는 데이터 타입을 미리 규정해 두는 것이 좋다. 데이터 타입이 통일되어야 나중에 데이터를 조회하고 가공할 때 오류를 줄일 수 있다.

유형	용어	설명
정수	INT, INTEGER	1, 2, 3 등 정수 형태의 데이터를 표현할 때 사용하는 용어
소수	FLOAT	0.1, 1.2 등 소수 형태의 데이터를 표현할 때 사용하는 용어
숫자	NUMBER	정수와 소수 구분 없이 숫자 형태를 표현할 때 사용하는 용어
문자	VARCHAR, STR, STRING	“안녕”, “hi” 등 문자 형태의 데이터를 표현할 때 사용하는 용어
날짜	DATE	YYYY-MM-DD 형식의 날짜 데이터를 표현할 때 사용하는 용어
시간	TIME	HH:MM:SS 형식의 시간 데이터를 표현할 때 사용하는 용어
날짜와 시간	DATETIME	YYYY-MM-DD HH:MM:SS 형식으로 날짜와 시간을 모두 포함한 데이터를 표현할 때 사용하는 용어
리스트	LIST	[1, 2, 3], [“a”, “b”, “c”]처럼 여러 항목이 대괄호 안에 나열된 형태
불리언	BOOL, BOOLEAN	True/False 두 가지 값만 가지는 형태

예를 들어 product_id는 문자열로 관리할 수도 있고 숫자로 관리할 수도 있다. 이 기준이 명확하지 않으면 어떤 플랫폼에서는 숫자로 들어오고, 어떤 플랫폼에서는 문자로 들어올 수 있다. 따라서 Tracking Plan에서 속성별 데이터 타입을 정해두는 것이 좋다.

로그 설계 시 주의할 점

1. 지표에서 출발해야 한다

로그 설계는 '무엇을 다 기록할까?'가 아니라 '어떤 지표를 계산해야 할까?'에서 출발해야 한다. 예를 들어 배너 성과를 보고 싶다면 다음 지표가 필요할 수 있다.

배너 노출 수
배너 클릭 수
배너 클릭률
배너 클릭 후 구매 전환율

이 지표를 계산하려면 배너 노출 로그, 배너 클릭 로그, 구매 로그와 연결 가능한 정보가 필요하다.

2. 이벤트명은 명확해야 한다

이벤트명은 어떤 행동을 의미하는지 바로 알 수 있어야 한다. 좋지 않은 예시는 다음과 같다.

interaction
click_event
event_01
product_action

이런 이름은 구체적으로 무엇을 의미하는지 알기 어렵다. 더 명확한 예시는 다음과 같다.

product_click
banner_impression
category_pageview
add_to_cart

3. Attribute는 분석에 필요한 수준으로 남겨야 한다

Attribute가 너무 적으면 분석할 수 있는 범위가 좁아진다. 반대로 너무 많으면 관리가 복잡해진다. 예를 들어 상품 클릭 이벤트에 최소한 다음 정보는 필요할 수 있다.

product_id
page
section
index

상품별 클릭률을 보고 싶다면 product_id가 필요하고, 영역별 성과를 보고 싶다면 section이 필요하다. 위치별 성과를 보고 싶다면 index가 필요하다.

4. Trigger는 모호하지 않아야 한다

Trigger가 모호하면 개발자마다 다르게 구현할 수 있다. 예를 들어 '상품이 보이면'이라는 표현은 너무 모호하다. 다음처럼 구체적으로 작성하는 것이 좋다.

상품 이미지 영역의 60% 이상이 화면에 노출되었을 때

또는 클릭 이벤트라면 다음처럼 작성할 수 있다.

사용자가 상품 카드 영역을 클릭했을 때

Trigger는 로그의 기준이 되기 때문에 최대한 구체적으로 작성해야 한다.

5. 플랫폼별 차이를 고려해야 한다

웹, Android, iOS는 로그 수정 반영 속도가 다르다. 특히 앱은 배포와 업데이트 과정이 필요하기 때문에 로그 오류를 빠르게 고치기 어렵다. 따라서 앱 로그는 설계 단계에서 더 꼼꼼하게 확인하고, QA도 충분히 진행해야 한다.

6. 통일된 명명 규칙이 필요하다

명명 규칙이 없으면 로그가 제각각 쌓인다. 예를 들어 어떤 팀은 productClick을 쓰고, 다른 팀은 product_click을 쓰면 나중에 데이터를 합치기 어렵다. 따라서 다음과 같은 기준을 정해야 한다.

snake_case를 사용할 것인가?
camelCase를 사용할 것인가?
페이지명은 어떻게 쓸 것인가?
클릭 이벤트는 _click으로 끝낼 것인가?
노출 이벤트는 _impression으로 끝낼 것인가?
상품은 product로 부를 것인가 item으로 부를 것인가?

이 기준은 Tracking Plan에 함께 정리해두는 것이 좋다.

마무리

사용자 행동 로그 설계는 프로덕트 데이터 분석을 위한 기초 작업이다. 서비스 운영용 데이터만으로도 매출, 주문 수, 회원 수 같은 전반적인 비즈니스 현황은 볼 수 있다. 하지만 사용자가 실제로 서비스 안에서 어떤 행동을 했는지, 어떤 화면을 봤는지, 어떤 버튼을 클릭했는지, 어느 단계에서 이탈했는지를 분석하려면 사용자 행동 로그가 필요하다. 로그 설계는 단순히 데이터를 많이 쌓는 일이 아니다. 분석 목적과 지표를 먼저 정의하고, 그 지표를 계산하기 위해 필요한 이벤트와 속성을 설계하는 일이다. 전체 흐름은 다음과 같다.

문제 정의 → 지표 기획 → 로그 설계 → 로그 개발 → QA → 데이터 분석

로그 설계에서 중요한 개념은 다음과 같다.

개념	설명
User Property	어떤 특성의 유저인지 설명하는 정보
Event Property	사용자가 어떤 행동을 했는지 설명하는 정보
Event	어떤 행위에 대한 로그인지
Attribute	이벤트와 함께 저장할 부가 정보
Trigger	로그가 발생하는 시점
Tracking Plan	로그 설계 내용을 체계적으로 정리한 문서

특히 Event Property를 설계할 때는 Event, Attribute, Trigger를 명확히 정의해야 한다. 이벤트명은 이해하기 쉬워야 하고, 속성은 분석에 필요한 수준으로 포함되어야 하며, Trigger는 개발자가 동일하게 이해할 수 있도록 구체적이어야 한다. 또한 로그는 한 번 잘못 쌓이면 나중에 수정하기 어렵다. 특히 앱 로그는 배포와 업데이트 과정이 필요하기 때문에 처음 설계와 QA가 중요하다. 결국 좋은 로그 설계란 다음 조건을 만족하는 것이다.

분석 목적이 명확하다.
필요한 지표를 계산할 수 있다.
이벤트명과 속성명이 이해하기 쉽다.
Trigger가 구체적이다.
플랫폼별 차이를 고려했다.
전사적으로 통일된 기준을 따른다.
Tracking Plan으로 관리된다.

사용자 행동 로그는 프로덕트 개선의 근거가 된다. 따라서 로그 설계는 데이터 분석을 하기 전 단계이지만, 실제 분석의 품질을 결정하는 매우 중요한 과정이라고 볼 수 있다.

데이터 기반 프로덕트 개선 프로세스 | 지표 진단부터 A/B 테스트까지

자유를원해 — Thu, 7 May 2026 00:10:32 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

데이터로 프로덕트를 개선하는 과정

이번 글에서는 데이터 기반 프로덕트 개선 프로세스에 대해 정리해보려고 한다. 프로덕트 데이터 분석은 단순히 데이터를 확인하는 것에 그치지 않고, 데이터를 근거로 프로덕트의 현재 상태를 진단하고, 문제를 발견하고, 원인을 탐구한 뒤, 개선안을 실제 서비스에 반영하고 그 성과를 다시 평가하는 과정까지 포함한다.

프로덕트가 점점 다양해지고 서비스 구조도 복잡해지면서 단순히 경험이나 직관만으로 의사결정을 내리는 방식에는 한계가 생긴다. 사용자가 어떤 기능을 사용하는지, 어느 단계에서 이탈하는지, 어떤 개선안이 실제 성과로 이어지는지 확인하기 위해서는 객관적인 데이터가 필요하다. 따라서 프로덕트를 개선하기 위해서는 데이터를 기반으로 문제를 바라보고, 지표를 통해 상태를 판단하며, 실험을 통해 개선 효과를 검증하는 과정이 중요하다.

이번 내용은 크게 두 부분으로 나눌 수 있다. 첫 번째는 프로덕트 데이터 분석이 무엇인지에 대한 내용이고, 두 번째는 프로덕트 성장을 위해 데이터를 어떻게 활용하는지에 대한 프로세스이다.

프로덕트 데이터 분석이란?

- 프로덕트란?

프로덕트란 고객의 문제 상황을 해결해줄 수 있는 서비스를 의미한다. 대표적으로 웹 서비스와 앱 서비스가 있다. 예를 들어 사용자가 음악을 듣고 싶을 때 사용하는 스트리밍 앱, 영상을 보고 싶을 때 사용하는 동영상 플랫폼, 운동 기록을 관리하기 위해 사용하는 헬스케어 앱, 업무를 관리하기 위한 협업 툴 등이 모두 프로덕트에 해당할 수 있다. 즉, 프로덕트는 단순히 만들어진 앱이나 웹사이트를 의미하는 것이 아니라, 사용자가 겪는 불편함이나 필요를 해결하기 위해 제공되는 서비스라고 볼 수 있다. 사용자가 어떤 문제를 가지고 있고, 그 문제를 서비스가 어떤 방식으로 해결해주는지가 프로덕트의 핵심이 된다.

예를 들어 운동 관리 앱이 있다면 사용자의 문제는 '혼자서는 운동 계획을 세우기 어렵다', '운동 기록을 꾸준히 관리하기 어렵다', '내 상태에 맞는 운동 루틴을 찾기 어렵다'와 같은 것일 수 있다. 이때 운동 관리 앱은 사용자의 운동 목표를 입력받고, 현재 상태를 확인하고, 맞춤형 플랜을 제안함으로써 사용자의 문제를 해결하는 프로덕트가 된다.

- 프로덕트 데이터란?

프로덕트 데이터란 프로덕트의 사용성과 성과를 분석하기 위해 수집된 데이터를 말한다. 사용자가 웹이나 앱 서비스를 이용하는 과정에서는 다양한 행동 데이터가 발생한다. 예를 들어 사용자가 어떤 화면에 들어왔는지, 어떤 버튼을 클릭했는지, 어느 단계에서 이탈했는지, 회원가입을 완료했는지, 결제를 했는지와 같은 정보가 모두 프로덕트 데이터가 될 수 있다. 프로덕트 데이터의 예시는 다음과 같다.

구분	예시
방문 데이터	사용자가 서비스에 접속한 횟수, 방문 경로, 유입 채널
행동 데이터	버튼 클릭, 화면 조회, 검색, 스크롤, 특정 기능 사용
전환 데이터	회원가입 완료, 구독 신청, 결제 완료, 문의 제출
이탈 데이터	특정 단계에서 나간 사용자 수, 장바구니 이탈, 온보딩 중단
유지 데이터	재방문율, 재구매율, 구독 유지율, 리텐션
성과 데이터	매출, 결제 전환율, 유료 회원 수, 활성 사용자 수

이러한 데이터를 분석하면 사용자가 프로덕트를 어떻게 사용하고 있는지 파악할 수 있다. 예를 들어 사용자가 특정 화면에서 많이 이탈한다면 그 화면이 복잡하거나 다음 행동이 명확하지 않을 수 있다. 특정 버튼 클릭률이 낮다면, 버튼 위치나 문구가 사용자의 행동을 유도하기에 적절하지 않을 수 있다. 회원가입 전환율이 낮다면, 회원가입 과정이 길거나 사용자가 회원가입의 필요성을 충분히 느끼지 못하고 있을 수 있다. 결국 프로덕트 데이터는 사용자의 행동을 수치로 확인하게 해주는 자료이며 프로덕트의 문제를 발견하고 개선 방향을 찾는 근거가 된다.

- 프로덕트 데이터 분석이란?

프로덕트 데이터 분석이란 데이터를 기반으로 프로덕트를 개선하고 의사 결정하는 것을 말한다. 서비스가 단순했던 과거에는 경험과 직관만으로도 어느 정도 의사결정을 할 수 있었을 수 있다. 그러나 현재의 프로덕트는 기능도 다양하고, 사용자 그룹도 세분화되어 있으며, 경쟁 서비스도 많다. 이런 상황에서 단순히 '이 기능이 좋아 보인다', '이 화면이 더 예쁜 것 같다', '사용자들이 아마 이렇게 행동할 것 같다'와 같은 감에만 의존하면 잘못된 결정을 내릴 가능성이 커진다.

데이터 기반 의사결정이 중요한 이유는 경험과 직관에 의존한 의사결정이 가져다주는 리스크와 비용이 커졌기 때문이다. 하나의 기능을 잘못 개선하면 개발 리소스가 낭비될 수 있고, 사용자의 불편을 키울 수 있으며, 매출이나 전환율에도 부정적인 영향을 줄 수 있다. 따라서 프로덕트 데이터 분석은 단순히 데이터를 보는 일이 아니라, 데이터를 바탕으로 다음과 같은 질문에 답하는 과정이라고 볼 수 있다.

질문	데이터 분석을 통해 확인할 수 있는 내용
사용자는 어떤 기능을 많이 사용하는가?	핵심 기능 사용률, 클릭률, 화면 조회 수
사용자는 어느 단계에서 이탈하는가?	퍼널 단계별 이탈률, 전환율
어떤 사용자 그룹에서 문제가 두드러지는가?	세그먼트별 전환율, 리텐션, 행동 차이
개선안이 실제로 효과가 있었는가?	A/B 테스트 결과, 개선 전후 지표 변화
프로덕트가 비즈니스 목표에 기여하고 있는가?	매출, 유료 전환율, 회원가입 수, 유지율

즉, 프로덕트 데이터 분석은 프로덕트를 더 나은 방향으로 개선하기 위한 근거를 제공하는 역할을 한다.

프로덕트 데이터 분석의 역할

프로덕트 데이터 분석은 크게 세 가지 역할을 한다. 첫 번째는 프로덕트 방향성 설정, 두 번째는 프로덕트 성과 수치화, 세 번째는 비용 절감 및 업무 효율성 향상이다.

- 프로덕트 방향성 설정

프로덕트 데이터 분석은 앞으로 프로덕트를 어떤 방향으로 개선해야 하는지 판단하는 데 도움을 준다. 예를 들어 사용자가 특정 기능을 많이 사용한다면, 해당 기능은 프로덕트 내에서 중요한 가치가 있을 가능성이 높다. 반대로 사용자가 거의 사용하지 않는 기능이 있다면, 기능 자체가 필요 없거나, 사용자가 해당 기능을 발견하지 못하거나, 사용 방법이 어렵게 설계되어 있을 수 있다. 또 특정 화면에서 사용자가 많이 이탈한다면, 그 화면은 개선이 필요한 지점일 수 있다. 이처럼 데이터를 보면 사용자가 프로덕트 안에서 어떤 행동을 하는지 알 수 있고, 이를 바탕으로 어떤 기능을 강화해야 하는지, 어떤 부분을 줄이거나 수정해야 하는지 판단할 수 있다.

예를 들어 온보딩 과정에서 사용자가 중간에 많이 이탈한다면, 온보딩 단계가 너무 길거나 복잡할 수 있다. 이 경우 프로덕트 팀은 온보딩 단계를 줄이거나, 설명을 더 명확하게 만들거나, 사용자가 서비스의 가치를 더 빨리 이해할 수 있도록 화면을 개선하는 방향을 고려할 수 있다.

- 프로덕트 성과 수치화

프로덕트 데이터 분석은 프로덕트의 성과를 감이나 느낌이 아니라 수치로 확인하게 해준다.

예를 들어 '이번에 바꾼 화면이 더 좋아진 것 같다'라고 말하는 것만으로는 실제 성과를 판단하기 어렵다. 하지만 개선 전후의 회원가입 전환율, 클릭률, 결제 전환율, 재방문율 등을 비교하면 실제로 성과가 좋아졌는지 확인할 수 있다. 성과를 수치화할 수 있는 대표적인 지표는 다음과 같다.

지표	의미
회원 가입자 수	일정 기간 동안 회원가입을 완료한 사용자 수
회원가입 전환율	서비스에 들어온 사용자 중 회원가입을 완료한 비율
결제 전환율	상품이나 서비스를 본 사용자 중 결제를 완료한 비율
클릭률	특정 버튼이나 배너를 본 사용자 중 클릭한 비율
이탈률	특정 단계에서 다음 단계로 넘어가지 않고 나간 비율
재방문율	한 번 방문한 사용자가 다시 방문한 비율
리텐션	일정 기간이 지난 후에도 서비스를 계속 사용하는 비율

이처럼 프로덕트 성과를 수치화하면 현재 상태를 객관적으로 파악할 수 있고, 개선 전후의 변화를 비교할 수 있다. 또한 팀원들이 같은 지표를 기준으로 논의할 수 있기 때문에 의사소통도 더 명확해진다.

- 비용 절감 및 업무 효율성 향상

데이터를 기반으로 의사결정을 하면 불필요한 시도나 잘못된 방향의 개선을 줄일 수 있다. 프로덕트를 개선할 때는 기획, 디자인, 개발, 배포, 마케팅 등 여러 리소스가 들어간다. 만약 명확한 근거 없이 기능을 만들거나 화면을 수정한다면, 많은 시간과 비용을 들였음에도 성과가 나지 않을 수 있다.

반대로 데이터를 활용하면 우선순위를 정하기 쉬워진다. 예를 들어 여러 문제 중에서 어느 지점의 이탈률이 가장 높은지, 어떤 기능이 매출에 더 큰 영향을 주는지, 어떤 사용자 그룹에서 문제가 심각한지 확인할 수 있다. 이를 통해 가장 먼저 해결해야 할 문제를 정하고, 리소스를 더 효율적으로 사용할 수 있다. 즉, 프로덕트 데이터 분석은 단순히 데이터를 확인하는 활동이 아니라, 잘못된 의사결정으로 인한 비용을 줄이고 업무 효율성을 높이는 역할을 한다.

️데이터 기반 의사 결정

- 데이터 기반 의사 결정이란?

데이터 기반 의사 결정, 즉 Data-Driven Decision Making은 의사 결정의 효율성을 위해 직관이나 경험보다 객관적인 데이터를 기반으로 의사 결정하는 방식을 말한다.

물론 경험과 직관이 항상 의미 없는 것은 아니다. 경험이 많은 사람은 사용자의 문제를 빠르게 감지하거나 좋은 가설을 세울 수 있다. 하지만 최종 의사결정은 가능한 한 객관적인 데이터로 확인하는 것이 중요하다. 예를 들어 다음과 같은 두 가지 의사결정 방식이 있다고 할 수 있다.

구분	설명
직관 기반 의사결정	'이 디자인이 더 좋아 보인다', '사용자가 이 기능을 좋아할 것 같다'처럼 감이나 경험을 중심으로 판단
데이터 기반 의사결정	실제 사용자의 클릭률, 전환율, 이탈률, 재방문율 등을 확인하고 판단

데이터 기반 의사결정은 실제 사용자 행동을 근거로 하기 때문에 의사결정의 설득력을 높일 수 있다. 또한 의사결정 이후에도 결과를 다시 측정할 수 있기 때문에, 개선이 실제로 효과가 있었는지 확인할 수 있다.

- 데이터 기반 의사결정이 필요한 이유

데이터 기반 의사결정이 필요한 이유는 다음과 같다.

첫째, 사용자의 실제 행동은 예상과 다를 수 있다. 팀 내부에서는 좋은 기능이라고 생각했지만, 실제 사용자는 거의 사용하지 않을 수 있다. 반대로 사소해 보이는 기능이 사용자에게는 매우 중요한 기능일 수도 있다.

둘째, 서비스가 복잡해질수록 문제의 원인을 직관만으로 파악하기 어렵다. 회원가입 수가 줄었다고 해서 단순히 온보딩 화면만 문제라고 단정할 수 없다. 유입 사용자가 줄었을 수도 있고, 특정 기기에서 오류가 발생했을 수도 있으며, 특정 단계의 설명이 부족했을 수도 있다.

셋째, 데이터는 팀 내 의사소통의 기준이 된다. 데이터를 기준으로 논의하면 “내 생각에는”이 아니라 “지표를 보면”이라는 방식으로 논의할 수 있다. 이를 통해 의사결정 과정에서 불필요한 의견 충돌을 줄이고, 더 명확한 기준을 세울 수 있다.

‍♂️프로덕트 성장을 위한 데이터 활용 프로세스

프로덕트 성장을 위한 데이터 활용 프로세스는 다음과 같은 흐름으로 진행된다.

지표 기반 상태 진단
문제 발견
데이터 기반 원인 탐구
해결 방안 도출
기능 구현
배포
개선안의 성과 평가

이 과정에서 필요한 경우 로그 설계 후 로깅을 진행하고, 분석 결과를 다시 서비스에 반영한다. 이 흐름은 한 번 진행하고 끝나는 것이 아니라 반복되는 구조이다. 개선안을 배포한 뒤 성과를 평가하고, 그 결과를 다시 다음 개선 과정에 반영하면서 프로덕트를 점진적으로 성장시킨다.

프로세스 1 - 지표 기반 상태 진단

- 지표란?

지표, 즉 Metric은 비즈니스와 프로덕트의 상태를 나타내는 정량적 수치이다.

프로덕트의 상태를 제대로 이해하기 위해서는 핵심 지표를 설정하고, 이를 지속적으로 모니터링해야 한다. 지표를 보면 현재 프로덕트가 정상적으로 작동하고 있는지, 어떤 부분에서 문제가 발생하고 있는지, 개선이 필요한 지점이 어디인지 빠르게 파악할 수 있다.

대표적인 지표는 다음과 같다.

지표	설명
신규 유입자 수	새롭게 서비스에 들어온 사용자 수
회원 가입자 수	회원가입을 완료한 사용자 수
회원가입 전환율	유입 사용자 중 회원가입까지 완료한 비율
구매 전환율	상품을 본 사용자 중 구매까지 완료한 비율
클릭률	특정 버튼이나 배너를 본 사용자 중 클릭한 비율
이탈률	특정 단계에서 다음 단계로 이동하지 않은 비율
재방문율	서비스를 다시 방문한 사용자 비율
리텐션	일정 기간 이후에도 계속 서비스를 사용하는 사용자 비율

지표 기반 상태 진단은 프로덕트 개선 프로세스의 출발점이다. 현재 상태를 정확히 알아야 문제를 발견할 수 있고, 문제를 발견해야 원인을 탐구하고 개선안을 만들 수 있기 때문이다.

- 핵심 지표를 정하는 방법

핵심 지표를 정할 때는 다음 두 가지를 고려해야 한다.

첫째, 기능이 잘 작동하는지 판단하는 기준이 되는가?

둘째, 비즈니스의 핵심 목표와 연결되는가?

여기서 중요한 것은 단순히 보기 좋은 숫자를 선택하는 것이 아니라, 해당 기능의 성과를 판단할 수 있고 비즈니스 목표와도 연결되는 지표를 선택해야 한다는 점이다. 예를 들어 어떤 지표가 높아졌다고 해서 무조건 좋은 것은 아니다. 그 지표가 실제 비즈니스 목표와 관련이 없다면 핵심 지표로 보기 어렵다. 반대로 비즈니스 목표와 연결되어 있더라도 특정 기능의 성과를 판단하기 어렵다면, 해당 기능의 핵심 지표로 적절하지 않을 수 있다. 핵심 지표를 정할 때는 다음과 같이 생각해볼 수 있다.

질문	의미
이 지표가 기능의 성공 여부를 설명할 수 있는가?	기능이 잘 작동하는지 판단할 수 있어야 한다
이 지표가 비즈니스 목표와 연결되는가?	서비스 성장, 매출, 유지율 등 핵심 목표와 관련 있어야 한다
사용자의 행동 변화를 반영하는가?	사용자의 실제 행동이 지표에 나타나야 한다
개선 전후 비교가 가능한가?	개선안의 효과를 평가할 수 있어야 한다

온보딩 기능 예시로 보는 핵심 지표 선정

- 온보딩 기능이란?

온보딩은 사용자가 서비스를 처음 접했을 때, 서비스의 핵심 가치를 이해하고 주요 행동까지 이어지도록 돕는 과정이다. 예를 들어 운동 관리 앱의 온보딩 과정은 다음과 같이 구성될 수 있다.

신규 유입
환영 인사
운동 목표 설정
현재 상태 확인
플랜 설정
회원 가입 완료

온보딩의 목적은 단순히 사용자를 여러 화면에 통과시키는 것이 아니라, 사용자가 서비스의 가치를 이해하고 계속 사용할 수 있도록 만드는 것이다. 따라서 온보딩 기능을 평가할 때는 사용자가 온보딩을 끝까지 완료했는지, 회원가입까지 이어졌는지, 이후에도 서비스를 사용하는지 등을 확인할 수 있다.

- 핵심 목표: 유료 회원 증가를 통한 수익 극대화

온보딩 기능에 관심이 있고, 프로덕트의 핵심 목표가 유료 회원 증가를 통한 수익 극대화라고 가정해볼 수 있다. 이때 어떤 지표를 핵심 지표로 정하면 좋을지 고민해야 한다. 후보 지표는 다음과 같다.

후보 지표	설명
정보 수집량	온보딩 과정에서 사용자에게 입력받은 정보의 양
신규 유입자 수	새롭게 서비스에 들어온 사용자 수
회원 가입자 수	온보딩 후 회원가입을 완료한 사용자 수

이 세 가지 지표는 모두 의미가 있어 보이지만, 핵심 지표로 적절한지는 따로 판단해야 한다.

- 정보 수집량

정보 수집량은 온보딩 과정에서 사용자에게 얼마나 많은 정보를 입력받았는지를 의미한다. 운동 관리 앱이라면 사용자의 성별, 나이, 운동 목표, 운동 경험, 현재 체중, 선호 운동 방식, 운동 가능 시간 등 다양한 정보를 입력받을 수 있다. 많은 정보를 수집하면 사용자에게 더 정교한 추천을 제공할 수 있다는 장점이 있다.

하지만 정보 수집량을 늘리기 위해 온보딩 과정이 복잡해지면 오히려 사용자가 중간에 이탈할 수 있다. 사용자는 아직 서비스의 가치를 충분히 경험하기 전이기 때문에, 너무 많은 정보를 요구받으면 부담을 느낄 수 있다. 따라서 정보 수집량은 온보딩 기능의 핵심 목표인 유료 회원 증가를 직접적으로 반영하기 어렵다. 정보 수집량이 많다고 해서 반드시 유료 회원이 증가하는 것은 아니며, 오히려 전환율을 낮출 수도 있다. 즉, 정보 수집량은 참고 지표로는 볼 수 있지만, 온보딩 기능의 핵심 지표로 삼기에는 한계가 있다.

- 신규 유입자 수

신규 유입자 수는 서비스에 새롭게 들어온 사용자의 수를 의미한다. 신규 유입자 수가 많다는 것은 서비스에 관심을 가진 사용자가 많다는 의미일 수 있다. 하지만 신규 유입자 수는 온보딩 기능 자체가 잘 작동하는지 판단하기에는 어렵다.

예를 들어 광고를 많이 집행하거나 외부 이벤트를 진행하면 신규 유입자 수는 증가할 수 있다. 하지만 사용자가 온보딩을 잘 완료하는지, 회원가입까지 이어지는지, 유료 회원으로 전환되는지는 별개의 문제이다. 즉, 사용자가 많이 들어왔다고 해서 온보딩이 잘 설계되었다고 볼 수는 없다. 신규 유입자 수는 마케팅이나 유입 채널의 영향을 크게 받을 수 있기 때문에, 온보딩 기능의 성과를 판단하는 핵심 지표로는 부족하다.

- 회원 가입자 수

회원 가입자 수는 온보딩 기능의 핵심 지표로 적절해 보인다. 온보딩 과정의 목적이 사용자를 서비스에 정착시키고 회원가입까지 연결하는 것이라면, 회원 가입자 수는 기능의 성과와 비즈니스 목표를 함께 반영할 수 있다. 특히 유료 회원 증가가 최종 목표라면, 회원가입은 유료 전환으로 이어지기 위한 중요한 중간 단계이다. 사용자가 회원가입을 완료해야 이후 구독, 결제, 플랜 선택 등 다음 행동으로 이어질 가능성이 생기기 때문이다.

다만 회원 가입자 수만 보면 전체 유입자 수의 영향을 받을 수 있으므로, 함께 보면 좋은 지표는 회원가입 전환율이다. 회원가입 전환율은 다음과 같이 볼 수 있다.

회원가입 전환율 = 회원가입 완료자 수 / 신규 유입자 수

예를 들어 신규 유입자가 1,000명이고 회원가입 완료자가 200명이라면 회원가입 전환율은 20%이다. 이 지표를 보면 단순히 회원가입자 수가 많고 적은 것뿐만 아니라, 들어온 사용자 중 얼마나 많은 사용자가 회원가입까지 도달했는지를 확인할 수 있다. 따라서 온보딩 기능을 분석할 때는 회원 가입자 수와 회원가입 전환율을 핵심 지표로 볼 수 있다.

프로세스 2 - 문제 발견

문제 발견은 지표를 지속적으로 모니터링하다가 이상 징후를 확인하는 단계이다. 예를 들어 온보딩 기능을 분석하는 상황에서 회원 가입자 수가 감소하거나, 회원가입 전환율이 떨어진다면 온보딩 과정에 문제가 있을 수 있다고 판단할 수 있다. 문제 발견 단계에서 중요한 것은 단순히 숫자가 낮아졌다는 사실만 보는 것이 아니다. 어떤 지표에서 이상이 발생했는지, 언제부터 변화가 나타났는지, 특정 사용자 그룹에서만 문제가 발생했는지 등을 함께 확인해야 한다.

예를 들어 회원가입 수가 줄었다고 해서 곧바로 온보딩 화면을 수정해야 하는 것은 아니다. 회원가입 수가 줄어든 이유는 신규 유입자 수가 줄었기 때문일 수도 있고, 특정 유입 채널의 품질이 낮아졌기 때문일 수도 있으며, 실제로 온보딩 과정에서 이탈이 증가했기 때문일 수도 있다. 따라서 문제를 발견할 때는 다음과 같은 질문을 해볼 수 있다.

질문	확인해야 할 내용
어떤 지표가 하락했는가?	회원가입 수, 전환율, 클릭률, 리텐션 등
언제부터 하락했는가?	특정 날짜, 배포 이후, 캠페인 종료 이후 등
전체 사용자에게 나타나는 문제인가?	전체 평균 기준 문제인지 확인
특정 그룹에서만 나타나는 문제인가?	연령대, 기기, 유입 채널, 신규/기존 사용자 등
다른 지표도 함께 변했는가?	유입 수, 이탈률, 결제율 등 연관 지표 확인

이처럼 문제 발견은 이후 원인 탐구를 위한 출발점이 된다.

️프로세스 3 - 데이터 기반 원인 탐구

- 데이터 기반 원인 탐구란?

데이터 기반 원인 탐구란 가설을 세우고 문제의 원인을 탐구하는 과정이다. 지표를 통해 문제가 발견되었다고 해서 곧바로 해결책을 만들면 안 된다. 문제의 원인을 제대로 파악하지 않고 개선안을 만들면, 실제 원인과 맞지 않는 방향으로 개선할 가능성이 있기 때문이다.

예를 들어 회원 가입자 수도 감소하고, 회원가입 전환율도 감소하는 경우 온보딩 기능에 문제가 있을 수 있다고 진단할 수 있다. 하지만 이때 바로 화면을 줄이거나 문구를 바꾸는 것이 아니라, 왜 사용자가 회원가입까지 도달하지 못하는지 원인을 탐구해야 한다. 데이터 기반 원인 탐구에서는 정량 데이터 분석을 먼저 활용할 수 있다. 하지만 정량 분석만으로 원인을 완전히 알기 어려운 경우에는 유저 인터뷰와 같은 정성 조사를 함께 활용할 수 있다.

- 원인 탐구를 위한 질문

회원가입 전환율이 떨어졌다면 다음과 같은 질문을 해볼 수 있다.

서비스에 대한 소개가 부족한가?
온보딩 화면이 너무 많은가?
최근에 디자인을 바꿔서 사용자가 혼란을 느끼는가?
특정 사용자 그룹에서만 전환율이 떨어지는가?
특정 단계에서 이탈이 많이 발생하는가?
사용자가 다음 행동을 이해하지 못하는가?
입력해야 하는 정보가 너무 많거나 부담스러운가?
회원가입을 해야 하는 이유가 충분히 전달되지 않았는가?

이 질문들은 모두 가설이 될 수 있다. 예를 들어 '최근 디자인 변경 이후 사용자가 혼란을 느껴 전환율이 떨어졌을 것이다'라는 가설을 세울 수 있고, 실제로 디자인 변경 시점 전후의 지표를 비교해볼 수 있다. 또 '특정 연령대에서 온보딩 과정이 복잡하게 느껴져 전환율이 낮아졌을 것이다'라는 가설을 세우고, 연령대별 전환율을 비교할 수도 있다.

즉, 원인 탐구 단계에서는 데이터를 통해 문제의 원인을 추정하고, 가설을 세우고, 그 가설을 검증하는 과정이 필요하다.

원인 탐구 방법

데이터 기반 원인 탐구는 여러 가지 방법으로 진행할 수 있다. 대표적으로 다음 네 가지 방법이 있다.

시간의 흐름에 따른 변화 확인
세그멘테이션을 통한 그룹별 비교
퍼널 분석
유저 인터뷰

- 시간의 흐름에 따른 변화 확인

시간의 흐름에 따른 변화 확인은 핵심 지표가 시간에 따라 어떻게 변화했는지 보는 방법이다.

예를 들어 회원가입 전환율을 일별, 주별, 월별로 확인하면 특정 시점부터 지표가 하락했는지 확인할 수 있다. 만약 UI 변경 시점 이후 회원가입 전환율이 하락했다면, 최근 디자인 변경이 원인인지 의심해볼 수 있다. 이 방법은 특정 이벤트나 변경 사항이 지표에 영향을 주었는지 확인할 때 유용하다. 예를 들어 다음과 같은 상황에서 사용할 수 있다.

상황	확인할 수 있는 내용
UI 변경 이후 전환율 하락	디자인 변경이 사용자 행동에 영향을 주었는지 확인
가격 정책 변경 이후 결제율 변화	가격 변경이 구매 행동에 영향을 주었는지 확인
광고 캠페인 시작 이후 유입 증가	캠페인이 신규 유입에 영향을 주었는지 확인
배포 이후 오류 증가	특정 배포가 문제를 만들었는지 확인

다만 시간의 흐름에 따른 변화만으로 원인을 확정할 수는 없다. 같은 시점에 다른 요인도 함께 작용했을 수 있기 때문이다. 따라서 시간 흐름 분석은 원인을 의심하는 출발점으로 활용하고, 다른 분석 방법과 함께 보는 것이 좋다.

- 세그멘테이션을 통한 그룹별 비교

세그멘테이션은 사용자를 여러 그룹으로 나누어 비교하는 방법이다. 전체 평균만 보면 문제가 잘 보이지 않을 수 있다. 특정 사용자 그룹에서는 문제가 심각하지만, 다른 그룹에서는 문제가 없어서 전체 평균으로는 변화가 작게 보일 수 있기 때문이다. 따라서 사용자를 여러 기준으로 나누어 지표를 비교하면 문제가 발생한 구체적인 대상을 찾을 수 있다. 세그멘테이션 기준은 다음과 같을 수 있다.

세그멘테이션 기준	예시
인구 통계학적 특성	연령대, 성별, 지역
유입 시점	신규 사용자, 기존 사용자
유입 채널	검색, 광고, SNS, 추천
행동 특성	특정 기능 사용 여부, 구매 경험 여부
기기/환경	모바일, PC, iOS, Android, 브라우저
고객 상태	무료 회원, 유료 회원, 휴면 사용자

예를 들어 회원가입 전환율을 봤을 때 전체적으로는 큰 변화가 없어 보이지만, 40대 이상 사용자 그룹에서 전환율이 크게 떨어졌다면 해당 연령대가 사용하기에 온보딩 과정이 너무 복잡할 수 있다. 또 모바일 사용자에게서만 이탈률이 높다면 모바일 화면에서 버튼이 잘 보이지 않거나, 입력 과정이 불편할 수 있다. 특정 광고 채널에서 유입된 사용자만 전환율이 낮다면, 광고에서 기대한 내용과 실제 서비스 첫 화면이 다를 수 있다.

즉, 세그멘테이션을 통한 그룹별 비교는 전체 평균만으로는 찾기 어려운 문제를 발견하는 데 유용하다.

- 퍼널 분석

퍼널 분석은 사용자가 특정 목표에 도달하기까지의 과정을 여러 단계로 나누고, 각 단계별 사용자 수와 전환율을 확인하는 분석 방법이다. 온보딩 과정에서는 다음과 같이 퍼널 단계를 나눌 수 있다.

신규 유입
환영 인사
운동 목표 설정
현황 체크
플랜 설정
회원 가입 완료

각 단계별 사용자 수가 다음과 같다고 가정할 수 있다.

단계	사용자 수	이전 단계 대비 전환율
신규 유입	1,000명	-
환영 인사	800명	80%
운동 목표 설정	400명	50%
현황 체크	300명	75%
플랜 설정	200명	67%
회원 가입 완료	100명	50%

이 표를 보면 어느 단계에서 사용자가 많이 이탈하는지 확인할 수 있다. 예를 들어 신규 유입에서 환영 인사로 넘어가는 전환율이 80%라면, 처음 진입한 사용자 중 20%는 다음 단계로 넘어가지 않은 것이다. 운동 목표 설정 단계로 넘어가는 전환율이 50%라면, 환영 인사 단계 이후 절반의 사용자가 이탈한 것이다.

퍼널 분석의 핵심은 전체 회원가입 완료자 수만 보는 것이 아니라, 어느 단계에서 이탈이 많이 발생하는지를 보는 것이다.

예를 들어 환영 인사 단계에서 다음 단계로 넘어가는 전환율이 낮다면, 첫 화면이 사용자의 관심을 충분히 끌지 못했을 수 있다. 서비스의 가치가 잘 전달되지 않았거나, 다음 버튼이 눈에 잘 띄지 않았거나, 사용자가 왜 이 과정을 진행해야 하는지 이해하지 못했을 수 있다. 또 플랜 설정 단계에서 이탈이 많다면, 사용자가 플랜의 차이를 이해하지 못했거나, 가격 정보가 부담스럽게 느껴졌거나, 서비스에 대한 정보가 충분하지 않았을 수 있다.

이처럼 퍼널 분석은 사용자가 목표 행동에 도달하기까지의 흐름을 단계별로 살펴보고, 병목 지점을 찾는 데 유용하다.

- 유저 인터뷰

유저 인터뷰는 데이터만으로 원인을 파악하기 어려울 때 활용할 수 있는 정성 조사 방법이다. 정량 데이터는 사용자가 어디에서 이탈했는지는 알려줄 수 있지만, 왜 이탈했는지는 명확하게 알려주지 못할 때가 많다. 예를 들어 퍼널 분석을 통해 플랜 설정 단계에서 이탈이 많다는 것을 알 수는 있지만, 사용자가 가격이 비싸다고 느꼈는지, 서비스 설명이 부족하다고 느꼈는지, 선택지가 너무 많아서 어려웠는지는 데이터만으로 알기 어렵다. 이때 유저 인터뷰를 통해 사용자의 실제 의견을 들을 수 있다. 예를 들어 사용자가 다음과 같이 말할 수 있다.

환영 인사가 너무 밋밋해서 서비스가 무엇을 해주는지 잘 모르겠다.
플랜 설정 단계에서 서비스에 대한 정보가 충분하지 않았다.
어떤 선택을 해야 하는지 이해하기 어려웠다.
입력해야 하는 정보가 많아서 부담스러웠다.
회원가입을 해야 하는 이유가 잘 느껴지지 않았다.

이러한 의견을 바탕으로 구체적인 해결책을 고민할 수 있다. 예를 들어 환영 인사가 너무 밋밋하다는 의견이 있다면, 단순한 환영 메시지 대신 서비스의 핵심 가치와 사용자가 얻을 수 있는 이점을 보여주는 안내 화면을 추가할 수 있다. 플랜 설정 단계에서 서비스 설명이 부족하다는 의견이 있다면, 각 플랜의 차이와 추천 기준을 더 명확하게 보여줄 수 있다.

즉, 유저 인터뷰는 정량 데이터에서 발견한 문제를 더 깊이 이해하기 위한 방법이다. 데이터 분석과 유저 인터뷰를 함께 활용하면 문제의 위치와 원인을 더 정확하게 파악할 수 있다.

프로세스 4 - 해결 방안 도출

원인을 탐구한 뒤에는 문제를 해결하기 위한 개선안을 도출한다. 해결 방안은 반드시 앞에서 발견한 문제와 원인에 연결되어야 한다. 단순히 '화면을 예쁘게 바꾸자', '단계를 줄이자'처럼 막연하게 접근하는 것이 아니라, 어떤 원인을 해결하기 위한 개선안인지 명확해야 한다.

예를 들어 온보딩 과정에서 사용자가 서비스의 가치를 충분히 이해하지 못하고 이탈한다면, 단순한 환영 인사 대신 서비스의 핵심 기능과 장점을 설명하는 안내 화면을 추가할 수 있다. 또 특정 단계가 너무 복잡해서 이탈이 발생한다면, 입력 항목을 줄이거나 단계를 간소화할 수 있다. 사용자가 어떤 선택을 해야 할지 몰라서 이탈한다면, 추천 옵션을 제공하거나 예시를 보여줄 수 있다. 특정 연령대에서 전환율이 낮다면, 해당 그룹이 이해하기 쉬운 문구와 화면 구조로 개선할 수 있다. 문제 원인과 해결 방안을 연결하면 다음과 같이 정리할 수 있다.

발견된 문제	추정 원인	해결 방안
환영 인사 단계에서 이탈이 많음	서비스 가치가 충분히 전달되지 않음	서비스 안내 화면 추가
운동 목표 설정 단계에서 이탈이 많음	선택지가 많고 기준이 모호함	추천 옵션 제공, 설명 문구 추가
플랜 설정 단계에서 이탈이 많음	플랜 차이를 이해하기 어려움	플랜별 혜택 비교표 추가
40대 이상 사용자 전환율 하락	화면이나 입력 과정이 복잡함	단계 간소화, 문구 명확화
모바일 사용자 이탈률 증가	모바일 화면에서 사용성이 낮음	버튼 위치, 입력 UI 개선

해결 방안을 도출할 때는 개선안의 목적도 함께 정리해야 한다. 예를 들어 '환영 인사 화면을 서비스 안내 화면으로 변경한다'는 개선안의 목적은 '사용자가 서비스의 가치를 더 빠르게 이해하게 하여 다음 단계 전환율을 높이는 것'이다. 이렇게 목적을 명확히 해야 이후 성과 평가 단계에서 어떤 지표를 봐야 하는지도 정할 수 있다.

️프로세스 5 - 기능 구현

해결 방안이 정해지면 실제 기능을 구현한다. 기능 구현 단계에서는 기획한 개선안을 실제 프로덕트에 반영할 수 있는 형태로 만든다. 예를 들어 온보딩 화면을 수정하거나, 서비스 안내 문구를 추가하거나, 단계 수를 줄이거나, 버튼 위치를 바꾸거나, 입력 항목을 조정할 수 있다. 하지만 이 단계에서 중요한 것은 단순히 기능을 만드는 것만이 아니다. 이후 개선안의 성과를 측정할 수 있도록 로그 설계와 데이터 수집 방식도 함께 고려해야 한다. 예를 들어 온보딩 화면을 개선했다면 다음과 같은 로그를 수집할 수 있어야 한다.

로그	설명
온보딩 시작	사용자가 온보딩을 시작했는지 확인
각 단계 진입	사용자가 어떤 단계까지 도달했는지 확인
다음 버튼 클릭	단계별 전환 행동 확인
이탈 발생	어느 단계에서 이탈했는지 확인
회원가입 완료	최종 목표 행동 완료 여부 확인
플랜 선택	사용자가 어떤 플랜을 선택했는지 확인

로그가 제대로 설계되어 있지 않으면 개선안을 배포한 뒤 성과를 평가하기 어렵다. 예를 들어 사용자가 어느 단계에서 이탈했는지 로그가 없다면, 개선 후에도 어떤 단계가 좋아졌는지 확인할 수 없다. 따라서 기능 구현 단계에서는 '무엇을 만들 것인가'뿐만 아니라 '무엇을 측정할 것인가'도 함께 생각해야 한다.

프로세스 6 - 배포

기능 구현이 완료되면 사용자에게 개선안을 배포한다. 배포는 개선된 기능을 실제 사용자가 사용할 수 있도록 서비스에 반영하는 단계이다. 다만 모든 사용자에게 바로 배포하기보다는, 먼저 일부 사용자에게만 적용하거나 A/B 테스트를 통해 성과를 확인할 수 있다. 특히 프로덕트 개선안이 사용자 행동이나 매출에 큰 영향을 줄 수 있는 경우에는 전체 배포 전에 신중하게 검증하는 것이 좋다. 개선안이 반드시 좋은 결과를 낸다는 보장은 없기 때문이다. 오히려 기존보다 전환율이 낮아지거나, 사용자가 혼란을 느끼거나, 예상하지 못한 문제가 발생할 수도 있다. 따라서 배포 단계에서는 다음과 같은 방식을 고려할 수 있다.

배포 방식	설명
일부 사용자 대상 배포	전체 사용자가 아니라 일부 사용자에게만 먼저 적용
A/B 테스트	기존안과 개선안을 나누어 성과 비교
단계적 배포	일정 비율의 사용자에게 순차적으로 확대
전체 배포	검증이 끝난 개선안을 모든 사용자에게 적용

배포는 단순히 기능을 공개하는 단계가 아니라, 개선안이 실제 환경에서 잘 작동하는지 확인하기 위한 과정이기도 하다.

프로세스 7 - 개선안의 성과 평가

- A/B 테스트란?

개선안의 성과를 평가하기 위해 A/B 테스트를 진행할 수 있다. A/B 테스트란 기능을 전체 유저에게 배포하기 전에, 기존안을 A안, 개선안을 B안으로 설정하고 유저를 랜덤하게 배정하여 두 안의 차이를 비교하는 방식이다. 예를 들어 온보딩 환영 인사 화면을 개선한다고 가정할 수 있다.

구분	설명
A안	기존 환영 인사 화면
B안	서비스 안내가 추가된 개선 화면

이때 일부 사용자는 A안을 보고, 일부 사용자는 B안을 보게 된다. 그리고 두 그룹의 회원가입 전환율, 다음 단계 전환율, 이탈률 등을 비교한다. A/B 테스트에서 사용자를 랜덤하게 배정하는 이유는 두 안의 차이 외 다른 요인의 영향을 최소화하기 위해서이다. 만약 A안은 기존 사용자에게만 보여주고, B안은 신규 사용자에게만 보여준다면 두 그룹의 차이가 화면 때문인지 사용자 특성 때문인지 알기 어렵다. 따라서 A/B 테스트에서는 가능한 한 두 그룹이 비슷한 조건을 가지도록 무작위로 나누고, 두 안의 성과 차이를 비교한다.

- A/B 테스트에서 확인할 지표

A/B 테스트를 할 때는 어떤 지표를 기준으로 성과를 판단할지 미리 정해야 한다. 온보딩 개선안이라면 다음과 같은 지표를 볼 수 있다.

지표	확인 목적
다음 단계 전환율	사용자가 다음 온보딩 단계로 넘어가는지 확인
회원가입 전환율	최종적으로 회원가입까지 이어지는지 확인
단계별 이탈률	어느 단계에서 이탈이 줄었는지 확인
유료 전환율	회원가입 이후 유료 결제로 이어지는지 확인
온보딩 완료율	온보딩 전체 과정을 완료했는지 확인

개선안의 목적이 '서비스 가치를 더 잘 전달해 회원가입 전환율을 높이는 것'이라면, 핵심 지표는 회원가입 전환율이 될 수 있다. 만약 개선안의 목적이 '첫 화면에서 다음 단계로 넘어가는 사용자를 늘리는 것'이라면, 첫 단계의 다음 단계 전환율이 핵심 지표가 될 수 있다. 중요한 것은 실험을 시작한 뒤에 마음대로 지표를 바꾸는 것이 아니라, 실험 전에 핵심 지표를 정하고 그 기준으로 결과를 판단하는 것이다.

- A/B 테스트 결과에 따른 의사결정

A/B 테스트 결과에 따라 다음과 같은 의사결정을 할 수 있다.

전체 유저 대상 배포
기존안으로 롤백
재실험

- 전체 유저 대상 배포

개선안인 B안이 기존안인 A안보다 더 좋은 성과를 보인다면, B안을 전체 유저에게 배포할 수 있다. 예를 들어 B안에서 회원가입 전환율이 더 높아졌다면, 개선안이 효과가 있다고 판단할 수 있다. 이 경우 기존 환영 인사 화면보다 서비스 안내가 추가된 화면이 사용자에게 더 도움이 되었을 가능성이 있다. 전체 유저 대상 배포는 개선안이 실제 지표 개선에 기여한다고 판단될 때 선택할 수 있는 방식이다.

- 기존안으로 롤백

개선안인 B안이 기존안보다 성과가 좋지 않다면 기존안으로 되돌릴 수 있다. 예를 들어 B안을 적용한 사용자 그룹에서 회원가입 전환율이 오히려 낮아졌다면, 개선안이 문제를 해결하지 못했거나 새로운 문제를 만들었을 가능성이 있다. 서비스 안내를 추가했지만 화면이 길어져 사용자가 더 부담을 느꼈을 수도 있고, 문구가 오히려 혼란을 주었을 수도 있다. 이 경우에는 개선안을 전체 배포하지 않고 기존안으로 롤백하는 것이 적절하다. 롤백은 실패가 아니라, 데이터를 통해 효과가 낮은 개선안을 걸러내는 과정이라고 볼 수 있다.

- 재실험

A안과 B안의 성과 차이가 명확하지 않거나 결과가 애매한 경우에는 재실험을 진행할 수 있다. 예를 들어 B안의 전환율이 조금 더 높아 보이지만 차이가 매우 작거나, 실험 기간이 짧아 충분한 데이터가 쌓이지 않았거나, 특정 사용자 그룹에서는 효과가 있었지만 전체적으로는 차이가 뚜렷하지 않을 수 있다. 이럴 때는 개선안을 다시 수정하거나, 실험 기간을 늘리거나, 다른 사용자 그룹을 대상으로 다시 테스트할 수 있다. 재실험이 필요한 경우는 다음과 같다.

상황	재실험 방향
결과 차이가 거의 없음	개선안의 차이를 더 명확하게 수정
데이터가 부족함	실험 기간 연장 또는 대상 확대
특정 그룹에서만 효과 있음	세그먼트별로 나누어 추가 분석
예상과 다른 결과 발생	원인 가설을 다시 세우고 실험 재설계

재실험은 더 정확한 의사결정을 하기 위한 과정이다. 한 번의 실험으로 모든 답을 얻기 어렵기 때문에, 실험 결과를 바탕으로 다시 가설을 세우고 개선 과정을 반복할 수 있다.

데이터 활용 프로세스 전체 흐름 정리

데이터 기반 프로덕트 개선 프로세스는 다음과 같은 흐름으로 정리할 수 있다.

단계	의미	예시
지표 기반 상태 진단	핵심 지표를 통해 현재 프로덕트 상태를 확인한다	회원가입 수, 전환율, 이탈률 모니터링
문제 발견	지표의 하락이나 이상 현상을 통해 문제를 찾는다	회원가입 전환율 감소 확인
데이터 기반 원인 탐구	문제의 원인을 데이터와 유저 인터뷰로 파악한다	퍼널 분석, 세그먼트 분석, 인터뷰 진행
해결 방안 도출	원인에 맞는 개선안을 만든다	서비스 안내 화면 추가, 단계 간소화
기능 구현	개선안을 실제 기능으로 만든다	온보딩 화면 수정, 로그 설계
배포	사용자에게 개선안을 적용한다	일부 사용자 대상 배포, A/B 테스트
개선안의 성과 평가	A/B 테스트 등을 통해 개선 효과를 확인한다	전체 배포, 롤백, 재실험 결정

이 과정은 한 번만 진행되는 것이 아니라 반복된다. 개선안을 배포하고 성과를 평가한 뒤, 다시 지표를 모니터링하고 새로운 문제를 발견하며 다음 개선으로 이어진다. 즉, 데이터 기반 프로덕트 개선은 다음과 같은 순환 구조를 가진다.

지표 확인 → 문제 발견 → 원인 분석 → 개선안 도출 → 구현 및 배포 → 성과 평가 → 다시 지표 확인

프로덕트는 한 번에 완성되는 것이 아니라, 데이터를 바탕으로 계속 개선되면서 성장한다.

마무리

마지막으로 이번 내용을 핵심 개념 중심으로 정리하면 다음과 같다.

개념	설명
프로덕트	고객의 문제 상황을 해결해줄 수 있는 서비스
프로덕트 데이터	프로덕트의 사용성과 성과를 분석하기 위해 수집된 데이터
프로덕트 데이터 분석	데이터를 기반으로 프로덕트를 개선하고 의사 결정하는 것
데이터 기반 의사결정	직관이나 경험보다 객관적인 데이터를 근거로 의사 결정하는 방식
지표	비즈니스와 프로덕트의 상태를 나타내는 정량적 수치
핵심 지표	기능의 성과와 비즈니스 목표를 판단하는 데 중요한 지표
문제 발견	지표의 변화나 이상 현상을 통해 개선이 필요한 지점을 찾는 과정
원인 탐구	가설을 세우고 데이터를 통해 문제의 원인을 찾는 과정
세그멘테이션	사용자를 그룹별로 나누어 지표를 비교하는 방법
퍼널 분석	사용자가 목표에 도달하기까지의 단계를 나누어 분석하는 방법
유저 인터뷰	정량 데이터만으로 알기 어려운 사용자의 생각과 이유를 파악하는 정성 조사
A/B 테스트	기존안과 개선안을 나누어 성과를 비교하는 실험 방법
롤백	개선안의 성과가 좋지 않을 때 기존안으로 되돌리는 것
재실험	결과가 명확하지 않을 때 실험 조건이나 개선안을 수정해 다시 실험하는 것

데이터 기반 프로덕트 개선 프로세스는 프로덕트의 상태를 지표로 진단하고, 문제의 원인을 데이터로 분석한 뒤, 개선안을 만들고 실험을 통해 효과를 검증하는 과정이다.

[코드잇 스프린트] Weekly Paper 4 - 쇼핑몰 앱의 구매 전환 문제 분석과 이벤트 설계 방안

자유를원해 — Wed, 6 May 2026 23:59:47 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 위클리 페이퍼 작성 기록입니다.

Q1.

쇼핑몰 앱을 운영하는데, 신규 가입자 수는 늘었지만 전체 매출은 정체 중입니다. 이 상황을 분석하기 위해 퍼널 분석과 코호트 분석 중 어떤 분석을 먼저 해보겠나요? 이유를 설명해 보세요.

어떤 분석을 먼저 해보겠는가 → 퍼널 분석

신규 가입자 수가 늘고 있다는 것은, 일단 유입 자체는 잘 되고 있다는 뜻으로 볼 수 있다. 그런데도 전체 매출이 정체되어 있다면, 문제는 유입 이후 구매 전환 과정 어딘가에서 발생하고 있을 가능성이 크다.

지금 먼저 봐야 하는 것은

사람이 왜 안 들어오지?가 아니라
들어온 사람이 왜 돈을 쓰지 않지?”니까!

퍼널 분석을 먼저 보는 이유

퍼널 분석은 사용자가 서비스 안에서 어떤 흐름으로 움직이는지, 그리고 어느 단계에서 많이 이탈하는지를 확인하는 데 적합하다.

예를 들어 아래와 같은 흐름을 볼 수 있다.

회원가입
상품 상세 페이지 조회
장바구니 추가
결제 완료

이 흐름에서

예시 1. 상품 상세 페이지까지는 많이 보는데 장바구니 추가가 적다
- 결제 시스템 문제라기보다는, 상품 가격이 애매하거나, 상세 설명이 부족하거나, 후기 신뢰도가 낮거나, 상품 자체가 매력적으로 안 보이는 문제일 수 있음
예시 2. 장바구니까지는 가는데 결제 완료가 잘 안 된다
- 배송비가 갑자기 부담되거나, 쿠폰 적용이 복잡하거나, 결제 수단이 불편하거나, 결제 직전에 회원 인증 같은 귀찮은 과정이 있을 수도 있음

이런 식으로 병목 구간을 빠르게 찾을 수 있다.

코호트 분석은?

코호트 분석은 특정 시점에 유입된 사용자들이 시간이 지나면서

얼마나 다시 방문하는지
얼마나 재구매하는지
유지율이 어떤지

를 보는 데 강점이 있다. 즉 장기적인 유지나 재구매 패턴을 보기에는 좋다. 하지만 지금 상황은 그 이전 단계인 현재 구매 전환 구조 자체에 문제가 없는지를 먼저 확인해야 하는 상태라고 생각한다. 쉽게 말하면

코호트 분석은 들어온 사람이 나중에도 남는가를 보는 데 적합하고
퍼널 분석은 지금 어디서 빠지고 있는가를 보는 데 적합하다.

이 상황에서는 후자가 더 급하다고 본다.

Q2.

온라인 쇼핑몰의 '상품 상세 페이지 → 장바구니 추가 → 결제 완료' 흐름에서 트래킹할 이벤트를 3가지 정의해 보세요. 각 이벤트명과 함께 수집해야 할 속성(property)을 2~3개씩 제안해 주세요.

view_product_detail (상품 상세 페이지)

사용자가 상품 상세 페이지를 본 시점이다. 퍼널의 시작점이기 때문에 이후 장바구니 전환율, 구매율을 계산할 때 기준이 된다.

수집할 속성

product_category
- 어떤 카테고리에서 상세 조회 후 이탈이 많은지 보기 위해
- 카테고리별 차이를 볼 수 있음
discount_rate
- 할인률이 사용자 반응에 영향을 주는지 보기 위해
- 할인이 관심을 만든 건지, 아니면 진짜 구매 의도까지 만들었는지를 볼 수 있음
scroll_depth
- 상세 페이지를 어느 정도까지 읽었는지 보기 위해
- 상세 페이지에 들어왔다고 해서 다 읽는 건 아니기 때문임
- 단순 조회 수보다는 더 입체적으로 해석할 수 있음

상세 조회는 많은데 장바구니 추가가 적다면, 상품 설명, 가격, 후기, 상세 페이지 구성 등의 문제를 의심해볼 수 있다.

add_cart (장바구니 추가)

사용자가 상품을 장바구니에 담은 시점이다. 단순 관심을 넘어서, 구매 의도가 생긴 단계라고 볼 수 있다.

수집할 속성

page_section
- 어디에서 장바구니 담기가 일어났는지 보기 위해 (ex. 검색 결과 / 추천 영역 / 상세 페이지 / 카테고리)
total_price
- 장바구니 총액이 구매 결정에 어떤 영향을 주는지 보기 위해
- 무료배송 기준과 가까운가, 장바구니 총액이 클수록 결제 진행이 느려지는가
stock_status
- 품절 임박 같은 재고 정보가 행동에 영향을 주는지 보기 위해

어떤 유입 경로에서 장바구니 전환이 잘 일어나는지, 무료배송 기준이나 재고 압박이 구매 심리에 작용하는지 해석할 수 있다.

purchase_complete (결제 완료)

사용자가 결제를 최종 완료한 시점이다. 실제 매출이 발생하는 가장 중요한 이벤트이다.

수집할 속성

payment_method
- 어떤 결제 수단이 많이 쓰이는지, 특정 수단에서 이탈이 있는지 보기 위해
- 선호 수단 분석도 가능하지만 특정 결제 수단에서 유독 실패가 많거나 이탈이 많은지 확인하는 데에 도움
coupon_code
- 어떤 할인/혜택이 실제 구매 전환으로 이어졌는지 보기 위해
- 단순 쿠폰 발급 수보다 실제 사용 기여도가 중요하기 때문
days_since_signup
- 가입 후 결제까지 걸린 시간을 보기 위해
- 바로 구매하는 편인지 아니면 며칠 고민하다가 사는지를 볼 수 있음

결제 수단 문제, 쿠폰 효과, 신규 가입자의 첫 구매 속도 등을 파악할 수 있다. 특히 days_since_signup는 신규 유저가 얼마나 빨리 첫 구매를 하는지를 보는 데 도움이 된다.

비즈니스 분석 프레임워크 | 퍼널 분석, 코호트 분석, RFM 분석 실습까지 전체 정리

자유를원해 — Wed, 6 May 2026 23:53:12 +0900

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

비즈니스 분석 프레임워크 정리

이번 이론 데이에서는 비즈니스 분석 프레임워크와 데이터 기반 프로덕트 개선 프로세스를 배웠다. 데이터 분석을 할 때는 단순히 데이터를 불러오고 그래프를 그리는 것에서 끝나는 것이 아니라, 현재 비즈니스 상황에 맞는 분석 방법을 선택하고, 그 분석 결과를 실제 서비스 개선 방향으로 연결하는 것이 중요하다. 이번 시간에는 데이터 분석 및 인사이트 도출 단계에서 자주 사용되는 대표적인 분석 프레임워크인 퍼널 분석, 코호트 분석, RFM 분석을 중심으로 학습하였다.

세 가지 분석은 모두 고객 행동을 이해하기 위한 방법이지만, 각각 바라보는 관점이 다르다. 퍼널 분석은 사용자가 목표 행동에 도달하기까지의 단계별 흐름을 분석한다. 즉, 사용자가 어느 단계에서 많이 이탈하는지를 확인하는 데 적합하다. 코호트 분석은 특정 기준으로 묶인 사용자 집단이 시간이 지나면서 어떻게 행동하는지를 분석한다. 즉, 시간이 흐른 뒤에도 사용자가 계속 남아 있는지, 이탈하는지를 확인하는 데 적합하다. RFM 분석은 고객의 최근 구매 시점, 구매 빈도, 구매 금액을 기준으로 고객 가치를 평가하고 세분화하는 분석이다. 즉, 어떤 고객이 더 가치 있는 고객인지 구분하고, 고객군별 마케팅 전략을 세우는 데 적합하다. 이번 글에서는 이 세 가지 분석 방법을 각각 정리하고, 실습 코드 흐름까지 함께 기록해보려고 한다.

퍼널 분석(Funnel Analysis)

퍼널 분석이란?

퍼널 분석이란 사용자가 특정 목표를 달성하기까지의 경로를 단계별로 나누어 분석하는 방법이다. 서비스 안에서 사용자는 보통 하나의 행동만 하고 끝나는 것이 아니라, 여러 단계를 거쳐 최종 목표 행동에 도달한다. 예를 들어 커머스 서비스에서 구매까지의 흐름을 생각해보면 다음과 같다.

상품 조회 → 장바구니 담기 → 구매

이때 모든 사용자가 상품을 조회한 뒤 장바구니에 담고, 다시 구매까지 이어지는 것은 아니다. 어떤 사용자는 상품만 보고 나가고, 어떤 사용자는 장바구니까지 담았지만 구매하지 않고 이탈할 수 있다.

퍼널 분석은 바로 이 지점을 보기 위한 분석이다. 즉, 사용자가 목표 행동까지 가는 과정에서 어느 단계에서 가장 많이 줄어드는지, 어느 단계의 전환율이 낮은지, 어느 단계의 개선이 최종 전환율 향상에 가장 큰 영향을 줄 수 있는지를 확인한다. 퍼널 분석의 목표는 최종 전환율을 높이는 것이다. 이를 위해서는 크게 두 가지 방향을 생각할 수 있다.

첫 번째는 단계별 전환율을 높이는 것이다. 예를 들어 상품 조회에서 장바구니 담기로 넘어가는 비율이 낮다면 상품 상세 페이지의 정보, 가격, 배송 혜택, 리뷰, 할인 메시지 등을 개선할 수 있다.

두 번째는 퍼널 단계 자체를 줄이는 것이다. 사용자가 구매까지 가는 과정이 너무 길거나 복잡하다면, 불필요한 단계를 줄여 이탈 가능성을 낮출 수 있다.

아래 실습에서는 화장품 커머스 데이터를 사용하여 사용자의 구매 흐름을 다음과 같은 퍼널로 정의하였다.

view → cart → purchase

각 이벤트의 의미는 다음과 같다.

view: 사용자가 상품을 조회한 단계
cart: 사용자가 상품을 장바구니에 담은 단계
purchase: 사용자가 상품을 구매한 단계

이번 퍼널 분석의 핵심 목표는 고객의 구매 행동을 촉진하기 위해 어느 단계에서 이탈이 많이 발생하는지 확인하는 것이다.

‍♀️ 퍼널 분석 실습

분석에 사용할 라이브러리 불러오기

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns
import plotly.express as px

데이터 불러오기

url = "https://bakey-api.codeit.kr/api/files/resource?root=static&seqId=10713&version=1&directory=/cosmetic.csv&name=cosmetic.csv"
cosmetic_df = pd.read_csv(url)

이 코드는 온라인에 저장된 cosmetic.csv 데이터를 불러오는 코드이다. 첫 번째 줄에서는 CSV 파일 주소를 url 변수에 저장한다. 두 번째 줄에서는 pd.read_csv(url)을 사용해서 해당 주소의 CSV 파일을 읽어오고, 이를 cosmetic_df라는 데이터프레임에 저장한다.

cosmetic_df.head()

데이터의 앞부분 5행을 확인하는 코드이다. 데이터를 처음 불러온 뒤에는 컬럼이 어떻게 구성되어 있는지, 값이 어떤 식으로 들어가 있는지 먼저 확인해야 한다.

cosmetic_df.info()

데이터프레임의 전체적인 정보를 확인하는 코드이다. 전체 행 개수, 컬럼 개수, 컬럼명, 결측치가 아닌 값의 개수, 데이터 타입 등을 확인할 수 있다. 퍼널 분석에서는 사용자의 행동 순서가 중요하기 때문에 event_time 컬럼이 날짜/시간 타입인지 확인하는 것이 중요하다.

cosmetic_df['event_time'] = pd.to_datetime(cosmetic_df['event_time'])

event_time 컬럼을 날짜/시간 타입으로 변환하는 코드이다. 날짜 데이터가 문자열 형태로 되어 있으면 시간 순서 정렬이나 날짜 계산을 정확하게 하기 어렵기 때문에 pd.to_datetime()을 사용해 datetime 타입으로 변환한다.

cosmetic_df['event_time'].min(), cosmetic_df['event_time'].max()

데이터에서 가장 이른 이벤트 시간과 가장 늦은 이벤트 시간을 확인하는 코드이다. 이를 통해 데이터가 어느 기간 동안 수집되었는지 확인할 수 있다.

cosmetic_df['event_type'].unique()

event_type 컬럼에 어떤 이벤트 종류가 있는지 확인하는 코드이다. 퍼널 분석에서는 행동 단계를 정의해야 하므로, 어떤 이벤트가 존재하는지 먼저 확인해야 한다.

cosmetic_df['event_type'].value_counts()

이벤트 종류별로 데이터가 몇 개씩 있는지 확인하는 코드이다. 데이터에는 대략 다음과 같은 이벤트가 존재한다.

view
cart
remove_from_cart
purchase

분석 흐름상 이벤트는 다음과 같이 볼 수 있다.

view → cart → remove_from_cart → purchase

하지만 이번 퍼널 분석에서는 핵심 구매 흐름을 보기 위해 다음 단계만 사용한다.

view → cart → purchase

remove_from_cart는 장바구니에서 상품을 제거하는 행동이므로, 기본 구매 전환 퍼널에서는 제외한다.

퍼널 분석용 데이터 준비

퍼널 분석에서는 행동의 순서가 중요하다. 따라서 먼저 데이터를 사용자, 상품, 시간 순서대로 정렬한다.

cosmetic_df = cosmetic_df.sort_values(by=['user_id', 'product_id', 'event_time'])

정렬 기준은 다음과 같다.

user_id
product_id
event_time

즉, 같은 사용자가 같은 상품에 대해 어떤 행동을 어떤 시간 순서로 했는지 확인할 수 있도록 정렬하는 것이다. 예를 들어 같은 사용자가 같은 상품에 대해 다음과 같은 순서로 행동했다면 자연스러운 구매 흐름으로 볼 수 있다.

view → cart → purchase

반대로 어떤 데이터가 다음처럼 시작한다면, 이번 분석의 기준인 view → cart → purchase 흐름으로 보기 어렵다.

cart → purchase

따라서 사용자-상품 조합별로 첫 이벤트가 무엇인지 확인하고, 첫 이벤트가 view인 경우만 남긴다.

temp = cosmetic_df.groupby(['user_id', 'product_id']).first()

같은 사용자와 같은 상품 조합별로 가장 첫 번째 이벤트를 가져오는 코드이다. groupby(['user_id', 'product_id'])는 한 사용자가 특정 상품에 대해 남긴 행동 기록 단위로 데이터를 묶는다. 앞에서 이미 event_time 기준으로 정렬했기 때문에 first()를 사용하면 해당 사용자-상품 조합에서 가장 먼저 발생한 이벤트를 가져올 수 있다.

target_index = temp.query("event_type == 'view'").index

사용자-상품 조합 중에서 첫 이벤트가 view인 경우만 찾는 코드이다.

이번 퍼널은 view → cart → purchase 흐름을 기준으로 하기 때문에, 첫 행동이 상품 조회인 경우만 분석 대상으로 남긴다.

cosmetic_df = cosmetic_df.set_index(['user_id', 'product_id']).loc[target_index].reset_index()

전체 데이터에서 첫 이벤트가 view인 사용자-상품 조합만 남기는 코드이다. 조금 나누어 보면 다음과 같다. set_index(['user_id', 'product_id'])는 기존 데이터프레임의 인덱스를 사용자 ID와 상품 ID로 변경한다. .loc[target_index]는 앞에서 구한 첫 이벤트가 view인 사용자-상품 조합만 선택한다. .reset_index()는 인덱스로 설정했던 user_id, product_id를 다시 일반 컬럼으로 되돌린다. 이 과정을 통해 상품 조회에서 시작한 행동 흐름만 남기고, 더 자연스러운 퍼널 분석을 진행할 수 있다.

단계별 사용자 수 집계

이제 본격적으로 퍼널 단계별 사용자 수를 계산한다.

user_counts = cosmetic_df.groupby(['event_type', 'product_id'])['user_id'].nunique()

이벤트 타입과 상품별로 고유 사용자 수를 계산하는 코드이다. groupby(['event_type', 'product_id'])는 이벤트 타입과 상품 ID를 기준으로 데이터를 그룹화한다. 예를 들면 다음과 같은 단위로 묶인다.

view 이벤트 - 상품 A
cart 이벤트 - 상품 A
purchase 이벤트 - 상품 A
view 이벤트 - 상품 B
cart 이벤트 - 상품 B
purchase 이벤트 - 상품 B

그중에서 user_id 컬럼을 선택하고, nunique()를 사용해 중복을 제외한 고유 사용자 수를 계산한다. 같은 사용자가 같은 상품을 여러 번 조회했더라도 1명으로 계산하기 때문에, 단순 이벤트 횟수가 아니라 각 단계에 도달한 실제 사용자 수를 볼 수 있다.

user_counts = user_counts.groupby('event_type').sum().reset_index()

앞에서 상품별로 나뉘어 있던 사용자 수를 이벤트 타입별로 다시 합산하는 코드이다.

즉, view, cart, purchase 단계별 전체 사용자 수를 확인할 수 있게 된다.

user_counts = user_counts.rename(columns={'user_id': 'users'})

앞에서 user_id 컬럼을 기준으로 고유 사용자 수를 계산했기 때문에, 결과 컬럼에는 사용자 수가 들어 있다. 컬럼명이 그대로 user_id이면 의미가 헷갈릴 수 있으므로 users로 변경한다.

user_counts = user_counts.query("event_type != 'remove_from_cart'")

이번 퍼널 분석에서는 핵심 흐름이 view → cart → purchase이므로, 장바구니에서 상품을 제거하는 행동인 remove_from_cart는 제외한다.

user_counts = user_counts.sort_values(by='users', ascending=False)

퍼널에서는 일반적으로 첫 단계에서 사용자 수가 가장 많고 이후 단계로 갈수록 사용자 수가 줄어든다. 따라서 사용자 수가 많은 순서대로 정렬하면 보통 view → cart → purchase 순서가 된다.

user_counts

최종적으로 퍼널 단계별 사용자 수가 어떻게 집계되었는지 확인한다.

퍼널 차트 시각화

px.funnel(user_counts, x='users', y='event_type')

Plotly를 사용해서 퍼널 차트를 그리는 코드이다. px.funnel()은 퍼널 차트를 만드는 함수이다.

user_counts: 시각화에 사용할 데이터프레임
x='users': x축에는 각 단계별 사용자 수를 넣는다.
y='event_type': y축에는 이벤트 타입을 넣는다.

퍼널 차트를 보면 view, cart, purchase 단계로 갈수록 사용자 수가 얼마나 줄어드는지 직관적으로 확인할 수 있다.

이전 단계 대비 전환율과 이탈률 계산

퍼널 분석에서는 단순히 단계별 사용자 수만 보는 것이 아니라, 이전 단계에서 다음 단계로 얼마나 넘어갔는지를 확인해야 한다.

user_counts['conversion_rate(%)'] = user_counts['users'] / user_counts['users'].shift(1) * 100

이전 단계 대비 현재 단계의 전환율을 계산하는 코드이다. user_counts['users']는 현재 단계의 사용자 수이다. user_counts['users'].shift(1)은 이전 행의 사용자 수를 가져온다. 예를 들어 데이터가 다음과 같다고 하면,

view 1000
cart 125
purchase 46

shift(1)을 적용하면 다음과 같이 한 칸씩 아래로 밀린다.

view NaN
cart 1000
purchase 125

따라서 cart 단계에서는 cart 사용자 수 / view 사용자 수를 계산할 수 있고, purchase 단계에서는 purchase 사용자 수 / cart 사용자 수를 계산할 수 있다. 즉, 이 코드는 다음 두 전환율을 계산한다.

view → cart 전환율
cart → purchase 전환율

첫 번째 단계인 view는 이전 단계가 없기 때문에 전환율이 NaN으로 나온다.

user_counts['churn_rate(%)'] = 100 - user_counts['conversion_rate(%)']

단계별 이탈률을 계산하는 코드이다. 전환율은 이전 단계에서 다음 단계로 넘어간 비율이다. 이탈률은 반대로 다음 단계로 넘어가지 않은 비율이다.

이탈률 = 100 - 전환율

user_counts

최종 결과를 확인하면 단계별 사용자 수, 전환율, 이탈률을 함께 볼 수 있다. 이 결과를 통해 상품 조회에서 장바구니로 넘어가는 비율, 장바구니에서 구매로 넘어가는 비율, 각 단계에서 얼마나 많은 사용자가 이탈하는지 확인할 수 있다.

view 100% 기준 전환율 분석

앞에서 계산한 전환율은 바로 이전 단계 대비 전환율이다. 이번에는 view를 100%로 두고, 각 단계가 전체 상품 조회 대비 어느 정도까지 도달했는지 확인한다. 즉, 다음을 계산한다.

view 기준 cart 도달률
view 기준 purchase 도달률

user_counts.iloc[0, 1]

user_counts 데이터프레임에서 첫 번째 행, 두 번째 열의 값을 가져오는 코드이다. 앞에서 사용자 수가 많은 순서대로 정렬했기 때문에 첫 번째 행은 보통 view 단계이고, 두 번째 열은 users 컬럼이다. 즉, 이 코드는 view 단계의 사용자 수를 가져오는 코드이다.

user_counts['conversion_rate_total'] = user_counts['users'] / user_counts.iloc[0, 1]

view 단계 사용자 수를 기준으로 각 단계의 도달률을 계산한다.

view: 1, 즉 100%
cart: view 대비 장바구니 도달률
purchase: view 대비 구매 도달률

fig = px.funnel(user_counts, x='conversion_rate_total', y='event_type')
fig.update_traces(texttemplate="%{value:.2%}")

view 기준 전환율을 퍼널 차트로 시각화하는 코드이다. fig.update_traces(texttemplate="%{value:.2%}")는 차트 위에 표시되는 숫자를 퍼센트 형식으로 바꿔준다. 예를 들어 0.125는 12.50%로 표시된다. 분석 결과, 상품 조회 후 장바구니까지 이어지는 비율은 약 12.5%, 상품 조회 후 구매까지 이어지는 비율은 약 4.6%로 해석할 수 있다. 즉, 상품을 본 사용자 중 대부분은 장바구니 단계로 넘어가지 않고 이탈하고 있었다.

가격대별 퍼널 분석

전체 퍼널 분석을 통해 view → cart 단계에서 이탈이 크게 발생한다는 것을 확인했다. 이번에는 상품 가격대에 따라 전환율에 차이가 있는지 확인한다. 가격이 낮은 상품과 높은 상품은 사용자의 구매 의사결정 방식이 다를 수 있다. 가격이 낮은 상품은 부담 없이 장바구니에 담거나 구매할 수 있지만, 가격이 높은 상품은 구매 전 고민이 더 길어질 수 있다. 먼저 상품별 가격 정보를 정리한다.

temp = cosmetic_df[['product_id', 'price']].drop_duplicates()

상품 ID와 가격 컬럼만 선택한 뒤 중복을 제거한다. 같은 상품이 여러 이벤트로 등장할 수 있기 때문에 상품별 가격 정보를 확인할 때는 중복을 제거해야 한다.

temp['price'].quantile([0.25, 0.5, 0.75])

상품 가격의 25%, 50%, 75% 지점을 확인하는 코드이다. 분위수를 참고하여 가격대를 나눌 수 있다. 이번 실습에서는 가격대를 다음과 같이 나누었다.

~3
3~5
5~8
8~

가격대 분류 함수를 만든다.

def group_price(x):
    if x <= 3:
        return '~3'
    elif x <= 5:
        return '3~5'
    elif x <= 8:
        return '5~8'
    else:
        return '8~'

이 함수는 가격 값 x를 입력받아 가격대 그룹으로 분류한다.

가격이 3 이하이면 ~3
가격이 3보다 크고 5 이하이면 3~5
가격이 5보다 크고 8 이하이면 5~8
가격이 8보다 크면 8~

cosmetic_df['price_range'] = cosmetic_df['price'].apply(group_price)

각 상품의 가격을 가격대 그룹으로 변환해서 price_range 컬럼을 새로 만드는 코드이다. 이제 가격대별 퍼널 분석을 진행한다.

price_funnel = cosmetic_df.groupby(['price_range', 'event_type', 'product_id'])['user_id'].nunique()

가격대, 이벤트 타입, 상품 ID별로 고유 사용자 수를 계산하는 코드이다. 예를 들어 다음과 같은 단위로 그룹화된다.

~3 가격대 - view - 상품 A
~3 가격대 - cart - 상품 A
3~5 가격대 - view - 상품 B
5~8 가격대 - purchase - 상품 C

price_funnel = price_funnel.groupby(['price_range', 'event_type']).sum().reset_index()

상품별로 나뉘어 있던 사용자 수를 가격대와 이벤트 타입 기준으로 합산하는 코드이다.

price_funnel = price_funnel.rename(columns={'user_id': 'users'})

고유 사용자 수를 계산한 결과이므로 컬럼명을 users로 변경한다.

price_funnel = price_funnel.query("event_type != 'remove_from_cart'")

이번 가격대별 퍼널 분석에서도 핵심 흐름은 view → cart → purchase이므로 remove_from_cart는 제외한다.

price_funnel = price_funnel.groupby('price_range').apply(
    lambda x: x.sort_values(by='users', ascending=False)
).reset_index(drop=True)

각 가격대 안에서 사용자 수가 많은 이벤트 순서대로 정렬하는 코드이다. 가격대별 전환율을 계산하려면 각 가격대 안에서 첫 번째 단계가 view여야 한다. 따라서 사용자 수가 많은 순서대로 정렬하여 보통 view → cart → purchase 순서가 되도록 한다.

price_funnel['conversion_rate'] = price_funnel['users'] / price_funnel.groupby('price_range')['users'].transform('first')

각 가격대 안에서 view를 기준으로 전환율을 계산한다. price_funnel.groupby('price_range')['users'].transform('first')는 각 가격대 그룹에서 첫 번째 사용자 수를 가져온다. 앞에서 사용자 수가 많은 순서대로 정렬했기 때문에 첫 번째 값은 보통 view 단계의 사용자 수이다. 따라서 이 코드는 가격대별로 다음을 계산한다.

각 단계 사용자 수 / 해당 가격대의 view 사용자 수

즉, 가격대별로 view를 100%로 두고 cart와 purchase까지 얼마나 전환되는지 계산한다. 가격대별 퍼널 차트를 그린다.

fig = px.funnel(
    price_funnel,
    x='conversion_rate',
    y='event_type',
    facet_col='price_range',
    color='price_range',
    category_orders={'price_range': ['~3', '3~5', '5~8', '8~']}
)
fig.update_traces(texttemplate="%{value:.2%}")

가격대별 퍼널 차트를 그리는 코드이다.

x='conversion_rate': x축에는 가격대별 view 기준 전환율을 넣는다.
y='event_type': y축에는 이벤트 타입을 넣는다.
facet_col='price_range': 가격대별로 차트를 나누어 보여준다.
color='price_range': 가격대별로 색상을 다르게 표시한다.
category_orders: 가격대가 원하는 순서대로 나오도록 지정한다.
fig.update_traces(texttemplate="%{value:.2%}"): 차트에 표시되는 값을 퍼센트 형식으로 바꾼다.

이 시각화를 통해 가격대가 높아질수록 구매까지 이어지는 전환율이 낮아지는지 확인할 수 있다.

가격대별 단계 전환율 자세히 보기

앞에서는 각 가격대별로 view 기준 도달률을 확인했다. 이번에는 가격대별로 다음 두 가지 전환율을 따로 계산한다.

view → cart 전환율
cart → purchase 전환율

먼저 가격대별 이벤트 사용자 수를 피벗 테이블로 만든다.

pivot_temp = price_funnel.pivot(index='price_range', columns='event_type', values='users')

pivot()은 데이터를 행과 열 구조로 재배치한다.

index='price_range': 행에는 가격대를 넣는다.
columns='event_type': 열에는 이벤트 타입을 넣는다.
values='users': 각 셀에는 사용자 수를 넣는다.

결과적으로 다음과 비슷한 형태의 표가 만들어진다.

event_type    cart    purchase    view
price_range
~3
3~5
5~8
8~

이렇게 바꾸면 view, cart, purchase 사용자 수를 이용해 단계별 전환율을 쉽게 계산할 수 있다.

pivot_temp['view_to_cart'] = pivot_temp['cart'] / pivot_temp['view'] * 100
pivot_temp['cart_to_purchase'] = pivot_temp['purchase'] / pivot_temp['cart'] * 100

첫 번째 줄은 가격대별 view → cart 전환율을 계산한다.

view_to_cart = cart 사용자 수 / view 사용자 수 × 100

즉, 상품을 본 사용자 중 몇 퍼센트가 장바구니에 담았는지 계산한다. 두 번째 줄은 가격대별 cart → purchase 전환율을 계산한다.

cart_to_purchase = purchase 사용자 수 / cart 사용자 수 × 100

즉, 장바구니에 담은 사용자 중 몇 퍼센트가 실제 구매까지 이어졌는지 계산한다.

pivot_temp.reindex(index=['~3', '3~5', '5~8', '8~'])

가격대 순서를 원하는 순서로 다시 정렬하는 코드이다. 낮은 가격대부터 높은 가격대까지 자연스럽게 비교하기 위해 ~3 → 3~5 → 5~8 → 8~ 순서로 정렬한다.

퍼널 분석 결과 해석

이번 퍼널 분석에서는 고객의 구매 흐름을 다음과 같이 정의하였다.

view → cart → purchase

분석 결과, 상품을 조회한 사용자가 장바구니에 담는 비율은 약 12.5% 수준으로 나타났다. 즉, 상품을 본 사용자 중 대부분은 장바구니 단계로 넘어가지 않고 이탈하고 있었다. 또한 상품을 조회한 사용자 중 실제 구매까지 이어지는 비율은 약 4.6% 수준으로 나타났다. 이를 통해 구매 전환 과정에서 가장 큰 개선 포인트는 view → cart 단계에 있음을 확인할 수 있다. 가격대별로 살펴보면 가격대가 높은 상품일수록 구매까지 이어지는 전환율이 낮게 나타났다. 특히 가격이 높아질수록 view → cart 전환율이 낮아지는 경향이 확인되었다.

반면 cart → purchase 전환율은 3 이하 가격대와 3 초과 가격대 사이에는 차이가 있었지만, 3 초과 가격대끼리는 큰 차이가 나타나지 않았다. 즉, 가격대가 높은 상품의 경우 사용자가 상품을 보고도 장바구니에 담기 전 단계에서 고민하거나 이탈하는 비중이 크다고 해석할 수 있다.

퍼널 분석 개선 방향

가격대가 높은 상품은 사용자가 상품을 본 뒤 장바구니에 담도록 유도하는 전략이 필요하다. 예를 들어 상품 상세 페이지에서 다음 요소를 더 명확하게 보여줄 수 있다.

할인 혜택
무료 배송
쿠폰
적립금
리뷰
상세 설명
인기 상품 문구

가격대가 낮은 상품은 cart → purchase 전환율이 상대적으로 높게 나타났기 때문에, 장바구니에 담긴 상품에 대해 알림이나 추천 메시지를 제공하면 구매 전환을 더 끌어올릴 수 있다. 즉, 가격대가 높은 상품은 장바구니 진입 유도가 중요하고, 가격대가 낮은 상품은 장바구니 이후 구매 유도가 중요하다고 볼 수 있다.

코호트 분석(Cohort Analysis)

코호트 분석이란?

코호트 분석이란 특정 시점이나 이벤트를 기준으로 그룹화된 사용자 집단인 코호트를 추적하여, 시간 경과에 따른 행동 변화를 분석하는 방법이다. 여기서 코호트란 동질 집단을 의미한다. 즉, 특정 기간 동안 유사한 특성을 공유한 사용자 집단이라고 볼 수 있다. 예를 들어 다음과 같은 사용자들을 하나의 코호트로 묶을 수 있다.

2024년 1월 가입 사용자
2024년 2월 첫 구매 사용자
특정 상품을 처음 구매한 사용자
특정 캠페인을 통해 유입된 사용자
같은 연령대와 성별을 가진 사용자

코호트 분석은 특정 기간 동안 특정 경험을 공유한 집단 간의 행동 패턴을 비교하고 분석하는 방법이다. 예를 들어 올해 신규로 가입한 사용자의 시간별 행동 패턴을 분석하면, 서비스가 고객에게 지속적으로 사용되고 있는지 확인할 수 있다. 코호트 분석을 하는 이유는 데이터를 쪼개면 유의미한 패턴을 발견하기 쉽기 때문이다.

전체 데이터를 한 번에 보면 보이지 않는 특성이, 사용자 집단을 나누어 보면 드러날 수 있다. 강의에서는 이와 관련해 심슨의 역설(Simpson’s Paradox)도 언급되었는데 심슨의 역설은 집단 통계가 개별 그룹의 통계와 모순될 수 있음을 보여주는 현상이다. 전체 데이터를 보면 좋아 보이는 결과도, 그룹별로 나누어 보면 전혀 다른 결과가 나타날 수 있다. 그래서 분석에서는 데이터를 통으로만 보는 것이 아니라, 적절한 기준으로 나누어 보는 것이 중요하다. 분석에서의 “분”은 나눌 분, “석”은 쪼갤 석이라고 한다. 즉, 분석이란 데이터를 통으로 보는 것이 아니라 적절한 기준으로 나누고 쪼개서 보는 과정이라고 이해할 수 있다.

코호트 분석 관련 용어

코호트 기간(Cohort Period)

코호트 기간은 코호트를 추적하는 시간 단위이다.

시간 단위는 일, 주, 월 등으로 설정할 수 있다. 예를 들어 월 단위 코호트 분석이라면 1개월 후, 2개월 후, 3개월 후의 행동 변화를 확인할 수 있다.

유지율(Retention Rate)

유지율은 코호트 내에서 일정 기간 후에도 계속해서 서비스를 사용하는 고객의 비율이다.

예를 들어 1월 가입자 100명 중 2월에도 40명이 서비스를 사용했다면, 1개월 후 유지율은 40%라고 볼 수 있다.

이탈률(Churn Rate)

이탈률은 일정 기간 후에 서비스를 더 이상 사용하지 않게 된 고객의 비율이다.

이탈률은 유지율의 반대 개념이다.

이탈률 = 100% - 유지율

리텐션 플래토(Retention Plateau)

리텐션 플래토는 유지율 그래프에서 그래프의 기울기가 평평해지는 구간을 의미한다.

하나의 코호트 안에서 기간에 따른 유지율 추이를 보면서 유지율이 안정화되는 지점을 찾을 수 있다.

리텐션 플래토가 존재하는 경우, 프로덕트가 어느 정도 성공한 것으로 판단하기도 한다. 시간이 지나도 일정 비율의 사용자가 계속 남아 있다는 의미이기 때문이다.

코호트 분석의 활용 예시

코호트 분석은 여러 상황에서 활용될 수 있다.

첫 번째는 고객의 행동 패턴 파악이다. 시간에 따라 고객의 행동 패턴이 어떻게 변하는지를 파악하면 시장 수요에 더 잘 반응할 수 있다. 두 번째는 유지율 개선 및 이탈률 감소이다. 코호트별로 고객 유지에 기여하는 요소를 강화하고, 이탈을 초래하는 요소에 대응할 수 있다. 세 번째는 고객 맞춤형 마케팅 전략 수립이다. 코호트 간 행동 패턴이 다르다면, 각 코호트에 맞는 타겟 마케팅 전략을 세울 수 있다. 이를 통해 고객 만족도를 높이고, 마케팅 효율도 개선할 수 있다.

코호트 분석 프로세스

코호트 분석 프로세스는 다음과 같다.

1. 목표 설정
2. 데이터 수집 및 정제
3. 코호트 그룹 정의하기
4. 코호트 그룹별 분석
5. 결과 해석 및 전략 수립
6. 전략 실행 및 반응 피드백

먼저 분석 목표를 설정한다. 예를 들어 고객 유지율 향상, 고객 이탈률 감소, 재구매율 개선 등이 목표가 될 수 있다. 그다음 데이터를 수집하고 정제한다. 코호트 분석에서는 일반적으로 로그 데이터를 사용하며, 사용자 ID, 가입 날짜, 구매 날짜, 주문 금액 등의 데이터가 포함될 수 있다. 이후 코호트 그룹을 정의한다. 코호트 그룹은 시간 기반, 행동 기반, 인구 통계학적 특성 기반 등으로 나눌 수 있다. 그다음 코호트별 유지율, 이탈률, 행동 패턴, 매출액 등을 분석한다. 마지막으로 결과를 해석하고 전략을 수립한 뒤, 실제 전략을 실행하고 반응을 피드백한다.

코호트 분석 결과 해석 방법

코호트 분석 결과는 보통 행과 열로 구성된 표나 히트맵으로 표현된다. 해석 방식은 다음과 같다.

가로축: 시간의 경과
세로축: 각기 다른 코호트 그룹
셀의 값: 해당 코호트 그룹이 특정 시간 경과 후 보여주는 지표 값

예를 들어 첫 구매월 기준 코호트 분석이라면, 세로축에는 첫 구매월이 들어가고, 가로축에는 첫 구매 후 경과 개월이 들어간다. 셀의 값에는 해당 코호트의 유지율이 들어갈 수 있다.

리텐션 측정 방식

리텐션은 측정 방식에 따라 다르게 계산될 수 있다.

클래식 리텐션

클래식 리텐션은 가장 일반적인 유지율 계산 방식이다.

유지의 기준으로 삼은 행동이 발생한 첫날을 기준으로, N일 후의 특정한 날에 다시 행동하는 사용자의 비율을 계산한다.

예를 들어 가입일로부터 정확히 7일 후에 다시 방문한 사용자의 비율을 계산할 수 있다.

범위 리텐션

범위 리텐션은 특정 기간 범위 내에서 단 한 번이라도 행동할 경우, 그 사용자는 해당 기간 동안 유지되었다고 보는 방식이다.

예를 들어 가입 후 7일 이내에 한 번이라도 방문하면 유지된 사용자로 보는 식이다.

롤링 리텐션

롤링 리텐션은 사용자가 마지막 행동을 한 날을 기준으로, 그 이전의 모든 날을 행동한 것으로 간주하는 방식이다.

예를 들어 어떤 사용자가 30일차에 마지막으로 행동했다면, 1일차부터 30일차까지는 유지된 것으로 보는 방식이다.

코호트 분석 실습

코호트 분석 실습은 크게 두 부분으로 나뉜다. 첫 번째는 코호트 기준 예시이다.

시간 기반 코호트
행동 기반 코호트
인구 통계학적 코호트

두 번째는 실제 코호트 분석이다.

첫 구매월 기준 코호트 정의
첫 구매 후 경과 개월 계산
코호트별 고객 수 집계
피벗 테이블 생성
유지율 계산
히트맵 시각화

여기서 핵심은 코호트란 공통된 기준을 가진 사용자 집단이라는 점이다.

시간 기반 코호트 예시

시간 기반 코호트는 가입일, 첫 방문일, 첫 구매일처럼 특정 시점을 기준으로 고객을 묶는 방식이다. 예를 들어 가입 날짜를 기준으로 하면 다음과 같은 코호트를 만들 수 있다.

2023년 1월 가입 고객
2023년 2월 가입 고객
2023년 3월 가입 고객

먼저 라이브러리를 불러온다.

import numpy as np
import pandas as pd
import random
from datetime import datetime, timedelta

시간 기반 코호트 예시를 위한 가상 데이터를 만든다.

np.random.seed(42)

data = {
    'customer_id': range(1, 501),
    'signup_date': random.sample(
        pd.date_range(start='2023-01-01', periods=500, freq='D').tolist(),
        500
    ),
    'total_payment': np.random.randint(100, 500, 500)
}

df = pd.DataFrame(data)
df.head()

이 데이터에는 다음 컬럼이 들어간다.

customer_id: 고객 ID
signup_date: 가입 날짜
total_payment: 총 결제 금액

np.random.seed(42)는 랜덤 결과를 고정하는 코드이다. 같은 코드를 여러 번 실행해도 같은 랜덤 결과가 나오도록 하기 위해 사용한다. pd.date_range(start='2023-01-01', periods=500, freq='D')는 2023년 1월 1일부터 하루 단위로 날짜 500개를 생성한다.

random.sample(..., 500)은 생성된 날짜 목록에서 500개를 랜덤하게 뽑는다. 날짜가 총 500개이고 그중 500개를 모두 뽑기 때문에, 날짜의 순서가 랜덤하게 섞인다고 볼 수 있다. np.random.randint(100, 500, 500)은 100 이상 500 미만의 정수 500개를 생성한다.

df.info()

데이터프레임 정보를 확인한다. 여기서는 signup_date가 날짜 타입인지 확인하는 것이 중요하다. 가입 날짜에서 년월을 추출하여 코호트 컬럼을 만든다.

df['signup_based_cohort'] = df['signup_date'].dt.to_period('M')

dt는 날짜/시간 타입의 컬럼에서 날짜 관련 기능을 사용할 수 있게 해주는 접근자이다. to_period('M')은 날짜를 월 단위 기간으로 변환한다. 예를 들어 다음과 같이 변환된다.

2023-01-15 → 2023-01
2023-02-27 → 2023-02
2023-05-03 → 2023-05

즉, 가입 날짜를 월 단위로 묶어 시간 기반 코호트를 만드는 코드이다.

df.head()

signup_based_cohort 컬럼이 잘 생성되었는지 확인한다.

행동 기반 코호트 예시

행동 기반 코호트는 사용자가 한 특정 행동을 기준으로 고객을 묶는 방식이다. 예를 들어 다음과 같은 기준으로 코호트를 만들 수 있다.

첫 구매 상품
첫 구매 여부
쿠폰 사용 여부
특정 상품 구매 여부
장바구니 담기 여부

이번 실습에서는 첫 구매 상품을 기준으로 행동 기반 코호트를 만든다. 먼저 가상 주문 데이터를 생성한다.

np.random.seed(42)

data = {
    'customer_id': np.random.randint(1, 101, 500),
    'order_date': random.sample(
        pd.date_range(start='2023-01-01', periods=500, freq='D').tolist(),
        500
    ),
    'product_id': [np.random.choice([101, 102, 103, 104, 105]) for i in range(500)],
    'total_payment': np.random.randint(100, 500, 500)
}

df = pd.DataFrame(data)
df.head()

이 데이터에는 다음 컬럼이 들어간다.

customer_id: 고객 ID
order_date: 주문 날짜
product_id: 상품 ID
total_payment: 결제 금액

customer_id는 1부터 100 사이의 값으로 생성된다. 주문 데이터에서는 한 고객이 여러 번 주문할 수 있기 때문에 같은 고객 ID가 여러 번 등장할 수 있다. product_id는 101, 102, 103, 104, 105 중 하나를 랜덤하게 선택한다.

고객별 첫 구매 날짜를 구한다.

first_purchase = df.groupby('customer_id')['order_date'].min().reset_index()
first_purchase = first_purchase.rename(columns={'order_date': 'first_purchase_date'})
first_purchase.head()

groupby('customer_id')는 고객별로 데이터를 묶는다. ['order_date'].min()은 각 고객의 가장 이른 주문 날짜를 구한다. 주문 날짜 중 가장 빠른 날짜가 첫 구매 날짜이다. reset_index()는 그룹화 결과의 인덱스를 다시 일반 컬럼으로 되돌린다. rename()을 사용해 order_date 컬럼명을 first_purchase_date로 변경한다. 이제 첫 구매 날짜에 해당하는 상품 정보를 원본 주문 데이터에서 가져온다.

first_product = pd.merge(
    first_purchase,
    df,
    left_on=['customer_id', 'first_purchase_date'],
    right_on=['customer_id', 'order_date'],
    how='left'
)

pd.merge()는 두 데이터프레임을 합치는 함수이다. 여기서는 고객 ID와 첫 구매 날짜를 기준으로 원본 주문 데이터와 연결하여, 고객이 첫 구매 시점에 어떤 상품을 구매했는지 가져온다. 첫 구매 상품만 남기고 컬럼명을 바꾼다.

first_product = first_product[['customer_id', 'product_id']]
first_product = first_product.rename(columns={'product_id': 'first_product_cohort'})
first_product.head()

이제 각 고객은 처음 구매한 상품 ID를 기준으로 코호트가 정해진다. 원본 데이터에 첫 구매 상품 코호트 정보를 붙인다.

df = pd.merge(df, first_product, on='customer_id', how='left')
df.head()

이렇게 하면 주문 데이터의 각 행에 해당 고객의 첫 구매 상품 코호트가 추가된다.

인구 통계학적 코호트 예시

인구 통계학적 코호트는 나이, 성별, 지역 등 사용자 특성을 기준으로 고객을 묶는 방식이다. 이번 실습에서는 연령대와 성별을 결합하여 코호트를 만든다.

np.random.seed(42)

data = {
    'customer_id': range(1, 501),
    'age': np.random.randint(10, 70, 500),
    'gender': [np.random.choice(['M', 'F']) for i in range(500)],
    'total_payment': np.random.randint(100, 500, 500)
}

df = pd.DataFrame(data)
df.head()

이 데이터에는 고객 ID, 나이, 성별, 총 결제 금액이 들어간다. 나이를 연령대 구간으로 나눈다.

df['age_group'] = pd.cut(
    df['age'],
    bins=[0, 20, 30, 40, 50, 60, 70],
    labels=['10s', '20s', '30s', '40s', '50s', '60s']
)

pd.cut()은 연속형 숫자 데이터를 구간으로 나누는 함수이다. 여기서는 나이를 10대, 20대, 30대, 40대, 50대, 60대로 나눈다. 연령대와 성별을 합쳐 코호트 컬럼을 만든다.

df['cohort'] = df.apply(lambda x: f"{x['age_group']}_{x['gender']}", axis=1)

apply()를 사용해 각 행마다 age_group과 gender를 합친 값을 만든다. 예를 들어 20대 여성은 20s_F, 40대 남성은 40s_M과 같은 코호트로 표현될 수 있다.

df.head()

age_group과 cohort 컬럼이 잘 추가되었는지 확인한다.

실제 코호트 분석: 첫 구매월 기준 유지율 분석

앞에서는 코호트를 어떤 기준으로 나눌 수 있는지 예시를 보았다. 이제 실제 코호트 분석을 수행한다. 이번 분석에서는 첫 구매월을 기준으로 코호트를 정의하고, 이후 몇 개월 뒤에도 다시 구매했는지 확인한다. 즉, 다음과 같은 질문에 답하는 분석이다.

2024년 1월에 처음 구매한 고객은 1개월 후, 2개월 후, 3개월 후에도 얼마나 남아 있을까?
2024년 2월에 처음 구매한 고객은 이후 기간 동안 얼마나 재구매할까?

먼저 가상 구매 데이터를 생성한다.

np.random.seed(0)

n_customers = 500
start_date = datetime(2024, 1, 1)
end_date = datetime(2024, 12, 31)
date_range = (end_date - start_date).days

data = {
    'customer_id': np.random.choice(range(1, n_customers + 1), size=1000),
    'purchase_date': [
        start_date + timedelta(days=np.random.randint(date_range))
        for _ in range(1000)
    ],
    'purchase_amount': np.random.uniform(100, 1000, size=1000)
}

df = pd.DataFrame(data)
df.head()

이 데이터에는 다음 컬럼이 들어간다.

customer_id: 고객 ID
purchase_date: 구매 날짜
purchase_amount: 구매 금액

n_customers = 500은 전체 고객 수를 500명으로 설정한다. start_date는 구매 데이터의 시작 날짜를 2024년 1월 1일로 설정한다. end_date는 구매 데이터의 종료 날짜를 2024년 12월 31일로 설정한다. date_range = (end_date - start_date).days는 시작일과 종료일 사이의 일수를 계산한다. np.random.choice(range(1, n_customers + 1), size=1000)은 1번부터 500번까지 고객 중 1000개의 고객 ID를 랜덤하게 선택한다. 한 고객이 여러 번 구매할 수 있으므로 같은 고객 ID가 여러 번 등장할 수 있다. purchase_date는 시작일에 랜덤한 일수를 더해 구매 날짜를 만든다. purchase_amount는 100 이상 1000 미만의 구매 금액을 랜덤하게 생성한다.

구매월 컬럼 생성

df['purchase_month'] = df['purchase_date'].apply(lambda x: x.replace(day=1))

구매 날짜를 월 단위로 맞추는 코드이다. 예를 들어 2024-03-17은 2024-03-01로 바뀐다. 월 단위 코호트 분석에서는 정확한 일자보다 어느 월에 구매했는지가 중요하기 때문에 모든 날짜를 해당 월의 1일로 맞춘다.

고객별 첫 구매월 계산

df['first_purchase_month'] = df.groupby('customer_id')['purchase_date'].transform('min').apply(
    lambda x: x.replace(day=1)
)

고객별 첫 구매 날짜를 구한 뒤, 그 날짜를 월 단위로 변환하는 코드이다. groupby('customer_id')['purchase_date'].transform('min')은 고객별 가장 이른 구매 날짜를 구한다. transform()을 사용했기 때문에 결과가 원래 데이터프레임의 행 개수에 맞게 들어간다. 이후 apply(lambda x: x.replace(day=1))을 사용해 첫 구매 날짜도 월 단위로 맞춘다.

첫 구매월 이후 경과 개월 계산

df['months_since_first_purchase'] = (
    (df['purchase_month'].dt.year - df['first_purchase_month'].dt.year) * 12
    + (df['purchase_month'].dt.month - df['first_purchase_month'].dt.month)
)

첫 구매월 이후 몇 개월이 지났는지 계산한다. 연도 차이에 12를 곱하고, 월 차이를 더한다. 예를 들어 첫 구매월이 2024년 1월이고 현재 구매월이 2024년 4월이면 경과 개월은 3개월이다.

(2024 - 2024) × 12 + (4 - 1) = 3

즉, 이 컬럼은 각 구매가 첫 구매 이후 몇 개월 뒤에 발생했는지를 나타낸다.

코호트별 고객 수와 구매 금액 집계

cohort_data = (
    df.groupby(['first_purchase_month', 'months_since_first_purchase'])
    .agg(
        n_customers=('customer_id', 'nunique'),
        total_purchase=('purchase_amount', 'sum')
    )
    .reset_index()
)

첫 구매월과 경과 개월을 기준으로 고객 수와 총 구매 금액을 집계한다.

first_purchase_month: 코호트 기준
months_since_first_purchase: 첫 구매 후 경과 개월
n_customers: 해당 시점에 구매한 고유 고객 수
total_purchase: 해당 시점의 총 구매 금액

nunique()를 사용했기 때문에 같은 고객이 같은 기간에 여러 번 구매했더라도 한 명으로 계산된다.

코호트 피벗 테이블 생성

cohort_pivot = cohort_data.pivot_table(
    index='first_purchase_month',
    columns='months_since_first_purchase',
    values='n_customers'
)

피벗 테이블은 코호트 분석 결과를 보기 좋은 형태로 바꾸는 과정이다.

행: 첫 구매월
열: 첫 구매 후 경과 개월
값: 고객 수

이렇게 하면 각 코호트가 시간이 지나면서 얼마나 유지되는지 한눈에 볼 수 있다. 예를 들어 2024년 1월 첫 구매 고객이 0개월 차에 몇 명이었고, 1개월 후에는 몇 명이 다시 구매했으며, 2개월 후에는 몇 명이 다시 구매했는지를 표 형태로 확인할 수 있다.

유지율 계산

cohort_size = cohort_pivot.iloc[:, 0]

각 코호트의 초기 고객 수를 구한다. iloc[:, 0]은 첫 번째 열을 의미한다. 코호트 분석에서 첫 번째 열은 보통 경과 개월 0개월 차이며, 해당 코호트의 초기 고객 수를 의미한다.

retention_matrix = np.round(cohort_pivot.divide(cohort_size, axis=0) * 100, 2)

코호트별 유지율을 계산한다. cohort_pivot.divide(cohort_size, axis=0)은 각 코호트의 고객 수를 해당 코호트의 초기 고객 수로 나눈다. 그다음 * 100을 해서 퍼센트로 바꾸고, np.round(..., 2)를 사용해 소수점 둘째 자리까지 반올림한다. 즉, 유지율 계산식은 다음과 같다.

유지율 = 특정 경과 개월의 고객 수 / 코호트 초기 고객 수 × 100

유지율 히트맵 시각화

plt.figure(figsize=(12, 6))
sns.heatmap(retention_matrix, annot=True, fmt='.2f', cmap='Blues')
plt.title('Cohort Retention Rate')
plt.xlabel('Months Since First Purchase')
plt.ylabel('First Purchase Month')
plt.show()

코호트 유지율을 히트맵으로 시각화하는 코드이다. plt.figure(figsize=(12, 6))은 그래프 크기를 설정한다. sns.heatmap()은 히트맵을 그리는 함수이다.

retention_matrix: 시각화할 유지율 데이터
annot=True: 각 셀에 숫자를 표시한다.
fmt='.2f': 숫자를 소수점 둘째 자리까지 표시한다.
cmap='Blues': 파란색 계열 색상으로 표시한다.

히트맵을 사용하면 코호트별 유지율을 직관적으로 확인할 수 있다. 보통 색이 진할수록 유지율이 높은 것으로 해석할 수 있다.

코호트 분석 결과 해석

코호트 분석에서는 각 첫 구매월 코호트가 시간이 지나면서 얼마나 유지되는지를 확인할 수 있다. 일반적으로 시간이 지날수록 유지율은 낮아지는 경향이 있다. 첫 구매 직후에는 많은 고객이 존재하지만, 시간이 지나면서 재구매하지 않는 고객이 늘어나기 때문이다. 하지만 모든 코호트가 같은 패턴을 보이는 것은 아니다. 어떤 코호트는 다른 코호트보다 유지율이 높게 나타날 수 있다. 이 경우 해당 시기에 유입된 고객의 특성, 당시 진행한 프로모션, 상품 구성, 서비스 경험 등을 함께 살펴볼 수 있다. 예를 들어 3월 첫 구매 고객의 유지율이 유독 높다면, 3월에 진행한 프로모션이나 상품 구성이 좋은 고객을 유입시켰는지 확인해볼 수 있다. 반대로 특정 월 코호트의 유지율이 낮다면, 해당 시기에 유입된 고객의 품질이 낮았거나, 첫 구매 이후 재구매를 유도하는 장치가 부족했을 가능성을 생각해볼 수 있다. 코호트 분석의 핵심은 전체 고객을 한 번에 보는 것이 아니라, 고객을 일정 기준으로 쪼개고 시간에 따른 변화를 확인하는 것이다.

️ RFM 분석

RFM 분석이란?

RFM 분석은 고객 가치를 평가하는 대표적인 분석 방법이다. RFM은 다음 세 가지 요소를 의미한다.

R = Recency
F = Frequency
M = Monetary

각각의 의미는 다음과 같다. Recency는 고객이 얼마나 최근에 구매했는지를 의미한다. 최근에 구매한 고객일수록 다시 구매할 가능성이 높다고 볼 수 있다. Frequency는 고객이 얼마나 자주 구매했는지를 의미한다. 구매 빈도가 높은 고객일수록 서비스에 대한 충성도가 높거나 반복 구매 가능성이 높다고 볼 수 있다. Monetary는 고객이 얼마나 많은 금액을 구매했는지를 의미한다. 구매 금액이 큰 고객일수록 매출 기여도가 높다고 볼 수 있다.

즉, RFM 분석은 고객이 최근에, 자주, 많이 구매했는지를 기준으로 고객을 평가하고 세분화하는 방법이다. 예를 들어 최근에 구매했고, 자주 구매하며, 구매 금액도 큰 고객은 가치가 높은 고객으로 볼 수 있다. 반대로 오래전에 한 번만 구매했고, 구매 금액도 낮은 고객은 상대적으로 낮은 가치의 고객으로 분류될 수 있다.

RFM 분석의 기본 아이디어

RFM 분석의 기본 아이디어는 파레토 법칙과 연결된다. 파레토 법칙은 상위 20%의 고객이 전체 수익의 80%를 만든다는 관점이다.

물론 모든 서비스에서 정확히 20대 80으로 나타나는 것은 아니지만, 많은 비즈니스에서 일부 핵심 고객이 전체 매출의 큰 비중을 차지하는 경우가 많다. 따라서 RFM 분석은 전체 고객을 똑같이 보는 것이 아니라, 구매 데이터에 기반하여 우수 고객을 찾아내고, 해당 고객군에 맞는 전략을 세우는 데 활용된다.

RFM 점수 부여 방식

RFM 점수는 여러 방식으로 만들 수 있다.

합계 방식

합계 방식은 각 요소별 점수를 더해서 총점을 만드는 방식이다. 예를 들어 다음과 같이 계산할 수 있다.

고객 A: R 5점 + F 2점 + M 5점 = 12점
고객 B: R 4점 + F 4점 + M 2점 = 10점

이 방식은 계산이 단순하다는 장점이 있다. 하지만 R, F, M 각각의 조합이 가진 의미가 뭉개질 수 있다는 한계가 있다. 예를 들어 총점이 같더라도 어떤 고객은 최근 구매 점수가 높고, 어떤 고객은 구매 금액 점수가 높을 수 있다. 이 경우 단순 총점만 보면 고객의 특성을 세밀하게 구분하기 어렵다.

Cell 방식

Cell 방식은 R, F, M 점수를 각각 따로 조합하여 보는 방식이다. 예를 들어 5, 2, 5와 같이 표현할 수 있다. 이 방식은 고객의 특성을 더 세밀하게 볼 수 있다. Recency는 높지만 Frequency가 낮은 고객, Frequency와 Monetary는 높지만 Recency가 낮은 고객 등을 구분할 수 있기 때문이다.

RFM 분석 프로세스

RFM 분석 프로세스는 다음과 같다.

1. RFM 요소별 기준 정의 및 데이터 수집
2. 분포 시각화 및 등급 개수 결정
3. RFM 점수 부여
4. RFM 모델 및 가중치 설정
5. 고객 세그먼트 분류
6. 세그먼트별 특성 분석
7. 전략 수립

먼저 RFM 요소별 기준을 정의하고 데이터를 수집한다. 그다음 Recency, Frequency, Monetary의 분포를 확인하고, 몇 개 등급으로 나눌지 결정한다. 특정 범위에 데이터가 몰려 있다면 등급 개수를 조정하거나 구간 기준을 다시 잡아야 할 수 있다. 이후 RFM 점수를 부여하고, 분석 목적에 따라 가중치를 설정한다. 마지막으로 고객 세그먼트를 분류하고, 세그먼트별 특성을 분석한 뒤 전략을 수립한다.

RFM 모델과 가중치

RFM의 각 요소별 중요도는 도메인에 따라 다르다. 따라서 RFM 모델을 만들 때는 가중치를 반영할 수 있다.

RFM 모델 = a × R + b × F + c × M

여기서 각 가중치의 의미는 다음과 같다.

a: Recency 가중치
b: Frequency 가중치
c: Monetary 가중치

예를 들어 유통업, 보험, 자동차처럼 오프라인 또는 장기 재구매가 중요한 산업에서는 Recency가 중요할 수 있다. 온라인 SNS, 통신업, 서비스업처럼 지속적인 사용 빈도가 중요한 산업에서는 Frequency가 중요할 수 있다. 금융업처럼 고객이 사용하는 금액 규모가 중요한 산업에서는 Monetary가 중요할 수 있다. 즉, RFM 분석에서 가중치는 정답이 정해져 있는 것이 아니라, 서비스의 특성과 분석 목적에 맞게 설정해야 한다.

RFM 집계 기간

RFM 분석에서 집계 기간은 보통 6개월에서 1년 정도를 사용하지만, 서비스마다 사용 주기가 다르기 때문에 무조건 정해진 기간이 있는 것은 아니다. 동일한 서비스 안에서도 유저 집단마다 사용 주기가 다를 수 있다. 예를 들어 쿠팡에서는 식료품 구매 유저와 일반 상품 구매 유저의 구매 주기가 다를 수 있다. 식료품은 자주 구매할 수 있지만, 일반 상품은 구매 주기가 상대적으로 길 수 있다. 또 무신사처럼 시즌성이 있는 서비스에서는 SS/FW 시즌에 따라 판매 상품군과 가격대가 달라질 수 있다. 따라서 RFM 분석에서는 도메인과 고객 특성을 고려하여 적절한 집계 기간을 설정해야 한다.

RFM 분석의 한계

RFM 분석에는 한계가 있다.

고객군의 한계

RFM 분석은 구매 데이터를 기반으로 한다. 따라서 구매하지 않은 대다수의 고객은 분석 대상에서 제외될 수 있다. 예를 들어 방문은 했지만 구매하지 않은 사용자, 장바구니에 담았지만 구매하지 않은 사용자 등은 RFM 분석만으로 충분히 설명하기 어렵다.

신뢰성의 한계

도메인에 따라 RFM 요소별 중요도가 다르고, R, F, M 요소 간 상호 독립성이 보장되지 않는다. 예를 들어 구매 빈도(F)가 높은 고객은 보통 총 구매 금액(M)도 높을 가능성이 크다. 이 경우 Frequency와 Monetary가 완전히 독립적인 요소라고 보기 어려울 수 있다.

예측의 한계

RFM 분석은 과거 데이터를 바탕으로 고객을 분류하는 방법이다. 따라서 새롭게 등장할 고객에 대한 예측에는 한계가 있다. 즉, RFM 분석은 현재 고객을 이해하고 세분화하는 데 유용하지만, 미래 행동을 정교하게 예측하기 위해서는 추가적인 모델링이나 다른 분석 방법이 필요할 수 있다.

RFM 분석 실습

RFM 분석 실습의 흐름은 다음과 같다.

데이터 불러오기
→ Monetary 컬럼 생성
→ Frequency 컬럼 생성
→ Recency / Frequency / Monetary 등급화
→ RFM 점수 계산
→ 고객 세그먼트 분류
→ 가중치 조정
→ 세그먼트별 특성 분석

전처리 자체보다는 RFM 분석에 필요한 핵심 변수 생성과 점수화, 세그먼트 분석 흐름을 중심으로 정리한다.

라이브러리 불러오기

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns

RFM 분석에 필요한 라이브러리를 불러온다.

pd.set_option('display.max_columns', None)

pandas 출력 옵션을 설정하는 코드이다. 데이터 컬럼이 많을 때 기본 설정으로는 중간 컬럼들이 생략될 수 있다. RFM 분석에서는 여러 컬럼을 확인해야 하므로 모든 컬럼이 보이도록 설정한다.

customer_df = pd.read_csv('/content/customer_data.csv', sep='\t')
customer_df.head()

고객 데이터를 불러온다. sep='\t'는 데이터가 쉼표가 아니라 탭으로 구분되어 있다는 의미이다.

Monetary 컬럼 생성

RFM에서 Monetary는 고객이 얼마나 많은 금액을 썼는지를 의미한다. 실습에서는 여러 품목별 구매 금액을 모두 더해서 총 구매 금액인 amount_total을 만든다.

data_amount_total = (
    customer_df['amount_alcohol']
    + customer_df['amount_fruit']
    + customer_df['amount_meat']
    + customer_df['amount_fish']
    + customer_df['amount_snack']
    + customer_df['amount_general']
)

각 컬럼의 의미는 다음과 같다.

amount_alcohol: 주류 구매 금액
amount_fruit: 과일 구매 금액
amount_meat: 육류 구매 금액
amount_fish: 수산물 구매 금액
amount_snack: 과자 구매 금액
amount_general: 잡화 구매 금액

이 금액들을 모두 더하면 고객별 총 구매 금액을 구할 수 있다.

index_amount_general = customer_df.columns.get_loc('amount_general')
index_amount_general

amount_general 컬럼이 데이터프레임에서 몇 번째 위치에 있는지 확인하는 코드이다. get_loc()은 특정 컬럼의 위치를 반환한다.

customer_df.insert(
    loc=index_amount_general + 1,
    column='amount_total',
    value=data_amount_total
)

customer_df.head()

amount_general 컬럼 바로 뒤에 amount_total 컬럼을 추가하는 코드이다. insert()는 원하는 위치에 새 컬럼을 추가할 때 사용한다.

loc: 컬럼을 추가할 위치
column: 새 컬럼명
value: 새 컬럼에 들어갈 값

이렇게 해서 RFM 분석에서 Monetary로 사용할 고객별 총 구매 금액 컬럼이 만들어진다.

Frequency 컬럼 생성

RFM에서 Frequency는 고객이 얼마나 자주 구매했는지를 의미한다. 실습에서는 웹 구매 횟수, 오프라인 매장 구매 횟수, 할인 구매 횟수를 모두 더해서 총 구매 횟수인 num_purchase_total을 만든다.

num_purchase_total = (
    customer_df['num_purchase_web']
    + customer_df['num_purchase_store']
    + customer_df['num_purchase_discount']
)

각 컬럼의 의미는 다음과 같다.

num_purchase_web: 웹 구매 횟수
num_purchase_store: 매장 구매 횟수
num_purchase_discount: 할인 구매 횟수

이 세 구매 횟수를 모두 더하면 고객별 총 구매 횟수를 구할 수 있다.

index_num_purchase_discount = customer_df.columns.get_loc('num_purchase_discount')
index_num_purchase_discount

num_purchase_discount 컬럼의 위치를 확인하는 코드이다.

customer_df.insert(
    loc=index_num_purchase_discount + 1,
    column='num_purchase_total',
    value=num_purchase_total
)

customer_df.head()

num_purchase_discount 컬럼 바로 뒤에 num_purchase_total 컬럼을 추가하는 코드이다. 이제 RFM 분석에서 사용할 Monetary와 Frequency 기준 컬럼이 만들어졌다.

RFM 등급화

RFM 분석에서는 각 요소를 등급으로 나누어 점수화한다. 이번 실습에서는 각 요소를 3개 등급으로 나누었다.

num_grades = 3

등급 개수를 3개로 설정하는 코드이다.

grade_labels = list(range(1, num_grades + 1))
grade_labels

range(1, num_grades + 1)은 1부터 num_grades까지의 숫자를 만든다. num_grades가 3이므로 결과는 다음과 같다.

[1, 2, 3]

RFM에서 점수가 높을수록 좋은 고객으로 볼 수 있다. 다만 Recency는 주의해야 한다. Recency는 최근 구매일로부터 얼마나 지났는지를 의미한다. 따라서 값이 작을수록 최근에 구매한 고객이다. 즉, Recency 값은 작을수록 좋다. 그래서 Recency 등급을 만들 때는 라벨을 역순으로 사용한다.

grade_labels[::-1]

[1, 2, 3]을 뒤집어 [3, 2, 1]로 만든다.

Recency 등급화

customer_df['recency_grade'] = pd.qcut(
    x=customer_df['recency'],
    q=num_grades,
    labels=grade_labels[::-1]
)

recency 값을 3개 구간으로 나누고 등급을 부여하는 코드이다. pd.qcut()은 데이터를 분위수 기준으로 나누는 함수이다.

x=customer_df['recency']: 등급화할 데이터
q=num_grades: 3개 구간으로 나눈다.
labels=grade_labels[::-1]: Recency는 값이 작을수록 좋으므로 높은 점수부터 부여한다.

즉, 최근에 구매한 고객일수록 높은 Recency 등급을 받는다.

customer_df['recency_grade'].value_counts()

Recency 등급별 고객 수를 확인한다.

Frequency 등급화

customer_df['frequency_grade'] = pd.qcut(
    x=customer_df['num_purchase_total'],
    q=num_grades,
    labels=grade_labels
)

num_purchase_total 값을 기준으로 Frequency 등급을 부여하는 코드이다. Frequency는 구매 횟수가 많을수록 좋은 고객이다. 따라서 값이 클수록 높은 등급을 부여한다.

customer_df['frequency_grade'].value_counts()

Frequency 등급별 고객 수를 확인한다.

Monetary 등급화

customer_df['monetary_grade'] = pd.qcut(
    x=customer_df['amount_total'],
    q=num_grades,
    labels=grade_labels
)

amount_total 값을 기준으로 Monetary 등급을 부여하는 코드이다. Monetary는 총 구매 금액이 클수록 좋은 고객이다. 따라서 값이 클수록 높은 등급을 부여한다.

customer_df['monetary_grade'].value_counts()

Monetary 등급별 고객 수를 확인한다. Monetary 등급별 매출 기여도를 확인한다.

groupby_monetary_grade = customer_df.groupby('monetary_grade').sum(numeric_only=True).reset_index()
groupby_monetary_grade

Monetary 등급별로 수치형 컬럼의 합계를 계산한다.

groupby_monetary_grade['amount_total'].plot(
    kind='pie',
    autopct='%.1f%%',
    labels=[f"{x}등급" for x in grade_labels],
    title='Monetary 등급별 매출 기여도',
    ylabel=''
)
plt.show()

Monetary 등급별 매출 기여도를 파이차트로 시각화한다. amount_total은 총 구매 금액이므로, 높은 Monetary 등급이 전체 매출에서 얼마나 큰 비중을 차지하는지 확인할 수 있다.

RFM 모델 1: 동일한 가중치 적용

먼저 Recency, Frequency, Monetary를 모두 같은 중요도로 보고 RFM 점수를 계산한다.

weight = {}
weight['recency'] = 1 / 3
weight['frequency'] = 1 / 3
weight['monetary'] = 1 / 3
weight

세 가중치의 합은 1이다. 즉, Recency, Frequency, Monetary를 모두 동일한 비중으로 반영한다.

customer_df.info()

RFM 점수를 계산하기 전에 데이터 타입을 확인한다. pd.qcut()으로 만든 등급 컬럼은 category 타입일 수 있다. 계산을 하려면 숫자형으로 변환해야 하므로 데이터 타입 확인이 필요하다.

customer_df['rfm_score'] = (
    weight['recency'] * customer_df['recency_grade'].astype('int')
    + weight['frequency'] * customer_df['frequency_grade'].astype('int')
    + weight['monetary'] * customer_df['monetary_grade'].astype('int')
)

RFM 점수를 계산하는 코드이다. 계산식은 다음과 같다.

RFM 점수
= Recency 등급 × Recency 가중치
+ Frequency 등급 × Frequency 가중치
+ Monetary 등급 × Monetary 가중치

가중치가 모두 1/3이므로 세 등급의 평균값처럼 계산된다. astype('int')는 등급 컬럼을 숫자형으로 변환하는 코드이다. 등급 컬럼이 category 타입이면 바로 계산하기 어려울 수 있기 때문에 정수형으로 변환한다.

customer_df.head()
customer_df['rfm_score'].describe()

rfm_score 컬럼이 잘 추가되었는지 확인하고, RFM 점수의 기초 통계량을 확인한다.

RFM 세그먼트 분류

RFM 점수는 1에서 3 사이의 값을 가진다. 각 등급이 1, 2, 3 중 하나이고, 가중치의 합이 1이기 때문이다. 따라서 1부터 3까지의 범위를 세 구간으로 나누어 고객을 1등급, 2등급, 3등급 세그먼트로 분류한다.

def rfm_segment_bins(x):
    if x < 5 / 3:
        return 1
    elif x < 7 / 3:
        return 2
    else:
        return 3

이 함수는 RFM 점수를 기준으로 고객을 1, 2, 3등급 세그먼트로 나눈다.

RFM 점수가 5/3보다 작으면 1등급 세그먼트
RFM 점수가 7/3보다 작으면 2등급 세그먼트
그 외에는 3등급 세그먼트

customer_df['rfm_segment'] = customer_df['rfm_score'].apply(rfm_segment_bins)
customer_df.head()

apply()를 사용해 각 고객의 rfm_score에 세그먼트 분류 함수를 적용한다.

customer_df['rfm_segment'].value_counts()

세그먼트별 고객 수를 확인한다. 세그먼트별 매출 기여도를 확인한다.

groupby_rfm_segment = customer_df.groupby('rfm_segment').sum(numeric_only=True).reset_index()
groupby_rfm_segment

RFM 세그먼트별로 수치형 컬럼의 합계를 계산한다.

groupby_rfm_segment['amount_total'].plot(
    kind='pie',
    autopct='%.1f%%',
    labels=[f"{x}등급" for x in grade_labels],
    title='RFM 세그먼트별 매출 기여도',
    ylabel=''
)
plt.show()

RFM 세그먼트별 매출 기여도를 파이차트로 시각화한다. 이를 통해 어떤 RFM 세그먼트가 전체 매출에 가장 많이 기여하는지 확인할 수 있다.

RFM 모델 2: 가중치 조정

처음에는 R, F, M을 모두 같은 중요도로 보았다. 하지만 도메인에 따라 더 중요하게 봐야 하는 요소가 달라질 수 있다. 실습에서는 Frequency와 Monetary를 더 중요하게 보기 위해 가중치를 다음과 같이 조정하였다.

weight = {}
weight['recency'] = 0.2
weight['frequency'] = 0.4
weight['monetary'] = 0.4
weight

이 경우 최근 구매 여부보다 구매 빈도와 구매 금액을 더 중요하게 반영한다. 조정된 가중치로 RFM 점수를 다시 계산한다.

customer_df['rfm_score'] = (
    weight['recency'] * customer_df['recency_grade'].astype('int')
    + weight['frequency'] * customer_df['frequency_grade'].astype('int')
    + weight['monetary'] * customer_df['monetary_grade'].astype('int')
)

세그먼트도 다시 분류한다.

customer_df['rfm_segment'] = customer_df['rfm_score'].apply(rfm_segment_bins)
customer_df.head()

가중치를 조정하면 같은 고객이라도 세그먼트가 달라질 수 있다. 예를 들어 최근 구매는 했지만 구매 빈도와 구매 금액이 낮은 고객은 동일 가중치에서는 높은 점수를 받을 수 있지만, Frequency와 Monetary를 더 중요하게 보는 모델에서는 낮은 점수를 받을 수 있다. 따라서 RFM 분석에서는 도메인과 분석 목적에 맞게 가중치를 정하는 것이 중요하다.

세그먼트별 연령대 고객 비중 분석

RFM 세그먼트를 나눈 뒤에는 세그먼트별 특성을 분석해야 한다. 먼저 세그먼트별로 어떤 연령대 고객이 많은지 확인한다.

customer_df['age_group'] = pd.cut(
    customer_df['age'],
    bins=[0, 20, 30, 40, 50, 60, 70, 100],
    labels=['10대 이하', '20대', '30대', '40대', '50대', '60대', '70대 이상']
)

나이를 연령대 구간으로 나누는 코드이다. pd.cut()은 연속형 숫자 데이터를 구간형 범주로 변환할 때 사용한다. 세그먼트와 연령대별 고객 수를 집계한다.

groupby_rfm_segment_age_group = (
    customer_df.groupby(['rfm_segment', 'age_group'])
    .agg(num_customers=('age', 'count'))
    .reset_index()
)

groupby_rfm_segment_age_group

RFM 세그먼트와 연령대를 기준으로 고객 수를 계산한다.

groupby(['rfm_segment', 'age_group']): 세그먼트와 연령대를 기준으로 그룹화한다.
agg(num_customers=('age', 'count')): 각 그룹의 고객 수를 계산한다.
reset_index(): 결과를 데이터프레임 형태로 정리한다.

세그먼트별로 연령대 고객 비중을 파이차트로 시각화한다.

for i_segment in range(1, num_grades + 1):
    age_group_dist = groupby_rfm_segment_age_group[
        groupby_rfm_segment_age_group['rfm_segment'] == i_segment
    ]
    
    age_group_dist['num_customers'].plot(
        kind='pie',
        autopct='%.1f%%',
        labels=age_group_dist['age_group'].unique(),
        title=f'{i_segment}등급 세그먼트 연령대별 고객 비중',
        ylabel=''
    )
    plt.show()

1등급부터 3등급까지 반복하면서, 각 세그먼트 안에서 연령대별 고객 비중을 파이차트로 보여준다. 분석 결과, 매출 기여도가 높은 3등급 세그먼트에 집중하여 마케팅을 전개한다면 젊은 세대보다는 중장년층을 타겟으로 하는 것이 효과가 더 클 가능성이 있다고 해석할 수 있다.

세그먼트별 품목별 매출 기여도 분석

이번에는 RFM 세그먼트별로 어떤 품목에서 매출이 많이 발생하는지 확인한다.

groupby_rfm_segment = customer_df.groupby('rfm_segment').sum(numeric_only=True).reset_index()
groupby_rfm_segment

세그먼트별로 수치형 컬럼의 합계를 계산한다. 분석에 사용할 품목별 금액 컬럼을 선택한다.

selected_columns = [
    'rfm_segment',
    'amount_alcohol',
    'amount_fruit',
    'amount_meat',
    'amount_fish',
    'amount_snack',
    'amount_general'
]

세그먼트별 품목별 매출 데이터를 따로 추출한다.

segment_amount = groupby_rfm_segment[selected_columns]
segment_amount = segment_amount.set_index('rfm_segment')
segment_amount

set_index('rfm_segment')를 사용해 RFM 세그먼트를 인덱스로 설정한다. 이렇게 하면 그래프를 그릴 때 세그먼트별 비교가 더 자연스럽다.

segment_amount.plot(kind='bar', stacked=True, figsize=(10, 6))
plt.title('RFM 세그먼트별 품목별 매출 기여도')
plt.xlabel('RFM 세그먼트')
plt.ylabel('구매 금액')
plt.show()

RFM 세그먼트별 품목별 매출 기여도를 누적 막대그래프로 시각화한다. 이를 통해 각 세그먼트가 어떤 품목에서 매출을 많이 발생시키는지 확인할 수 있다. 예를 들어 3등급 세그먼트에서 육류나 주류 구매 금액이 높게 나타난다면, 해당 세그먼트를 대상으로 관련 상품 추천이나 묶음 상품 프로모션을 기획할 수 있다.

세그먼트별 프로모션 참여율 분석

마지막으로 RFM 세그먼트별로 프로모션 참여율이 어떻게 다른지 확인한다.

groupby_rfm_segment = customer_df.groupby('rfm_segment').mean(numeric_only=True).reset_index()
groupby_rfm_segment

세그먼트별로 수치형 컬럼의 평균을 계산한다. 프로모션 참여 여부 컬럼이 0과 1로 되어 있다면, 평균은 참여율로 해석할 수 있다. 예를 들어 promotion_1의 평균이 0.25라면, 해당 세그먼트 고객 중 25%가 promotion_1에 참여했다는 의미이다.

groupby_rfm_segment.columns

프로모션 컬럼명을 확인하는 코드이다. 프로모션 참여율 분석에 사용할 컬럼 목록을 만든다.

selected_columns = [
    'rfm_segment',
    'promotion_1',
    'promotion_2',
    'promotion_3',
    'promotion_4',
    'promotion_5',
    'promotion_6'
]

세그먼트별 프로모션 참여율 데이터만 따로 추출한다.

avg_promotion = groupby_rfm_segment[selected_columns]
avg_promotion = avg_promotion.set_index('rfm_segment')
avg_promotion

프로모션 참여율을 막대그래프로 시각화한다.

avg_promotion.plot(kind='bar', figsize=(10, 6))
plt.title('RFM 세그먼트별 프로모션 참여율')
plt.xlabel('RFM 세그먼트')
plt.ylabel('프로모션 참여율')
plt.show()

이 그래프를 보면 어떤 세그먼트가 어떤 프로모션에 더 잘 반응하는지 확인할 수 있다. 이를 바탕으로 세그먼트별 맞춤 프로모션 전략을 세울 수 있다.

RFM 분석 결과 해석

이번 RFM 분석에서는 고객 데이터를 기반으로 다음 과정을 수행하였다.

1. 고객별 총 구매 금액을 계산하여 Monetary 컬럼을 만들었다.
2. 고객별 총 구매 횟수를 계산하여 Frequency 컬럼을 만들었다.
3. Recency, Frequency, Monetary를 각각 3개 등급으로 나누었다.
4. 동일 가중치로 RFM 점수를 계산하였다.
5. RFM 점수 기준으로 고객 세그먼트를 분류하였다.
6. Frequency와 Monetary를 더 중요하게 보는 가중치로 RFM 점수를 다시 계산하였다.
7. 세그먼트별 연령대, 품목별 매출 기여도, 프로모션 참여율을 분석하였다.

RFM 분석은 고객을 구매 데이터 기반으로 세분화할 수 있다는 점에서 유용하다. 단순히 전체 고객의 평균 구매 금액을 보는 것보다, 어떤 고객군이 더 가치가 높은지, 어떤 고객군에 마케팅을 집중해야 하는지 판단하는 데 도움이 된다. 특히 매출 기여도가 높은 세그먼트를 확인한 뒤, 해당 세그먼트의 연령대, 주 구매 품목, 프로모션 반응을 함께 보면 더 구체적인 마케팅 전략을 세울 수 있다. 예를 들어 3등급 세그먼트가 매출 기여도가 높고, 중장년층 비중이 높으며, 특정 품목 구매 금액이 높게 나타난다면 해당 고객군을 대상으로 맞춤형 상품 추천이나 프로모션을 설계할 수 있다.

퍼널 분석, 코호트 분석, RFM 분석 비교

이번에 배운 세 가지 분석은 모두 고객 행동을 이해하기 위한 분석 방법이다. 하지만 각각의 분석 목적은 다르다.

퍼널 분석

퍼널 분석은 사용자가 목표 행동에 도달하기까지의 단계별 흐름을 분석한다. 사용하면 좋은 상황은 다음과 같다.

회원가입 전환율이 낮을 때
장바구니에서 구매로 이어지지 않을 때
결제 단계에서 이탈이 많을 때
서비스 내 특정 목표 행동까지의 경로를 개선하고 싶을 때

핵심 질문은 다음과 같다.

사용자는 어느 단계에서 가장 많이 이탈하는가?

즉, 퍼널 분석은 사용자의 행동 흐름 중 막히는 지점을 찾는 데 적합하다.

코호트 분석

코호트 분석은 특정 기준으로 묶인 사용자 집단이 시간이 지나면서 어떻게 변화하는지 분석한다. 사용하면 좋은 상황은 다음과 같다.

신규 가입자의 재방문율을 보고 싶을 때
첫 구매 고객의 재구매율을 보고 싶을 때
특정 기간에 유입된 고객의 유지율을 비교하고 싶을 때
서비스 개선 이후 유입된 고객이 더 오래 남는지 보고 싶을 때

핵심 질문은 다음과 같다.

특정 시점이나 행동을 공유한 고객들은 시간이 지나도 유지되는가?

즉, 코호트 분석은 시간에 따른 고객 행동 변화를 확인하는 데 적합하다.

RFM 분석

RFM 분석은 구매 고객의 가치를 평가하고 세분화하는 분석이다. 사용하면 좋은 상황은 다음과 같다.

우수 고객을 찾고 싶을 때
고객 등급을 나누고 싶을 때
고객군별 마케팅 전략을 세우고 싶을 때
구매 데이터 기반으로 고객 가치를 평가하고 싶을 때

핵심 질문은 다음과 같다.

최근에, 자주, 많이 구매한 고객은 누구인가?

즉, RFM 분석은 고객을 가치 기준으로 나누고 세그먼트별 전략을 세우는 데 적합하다.

마무리

이번 이론을 배우면서 가장 크게 느낀 점은 분석 방법을 단순히 외우는 것보다 상황에 맞는 분석 방법을 선택하는 것이 훨씬 중요하다는 점이었다.

퍼널 분석은 사용자의 흐름에서 어디가 막히는지 찾는 데 적합하다. 코호트 분석은 시간이 지나면서 고객이 얼마나 남는지 확인하는 데 적합하다. RFM 분석은 구매 고객을 가치 기준으로 나누고, 세그먼트별 전략을 세우는 데 적합하다. 즉, 세 분석은 서로 대체 관계라기보다는 문제 상황에 따라 다르게 활용되는 도구라고 볼 수 있다. 예를 들어 신규 가입자는 늘고 있는데 전체 매출이 정체되어 있다면, 먼저 퍼널 분석으로 어느 단계에서 구매 전환이 막히는지 확인할 수 있다. 그다음 특정 시기에 유입된 고객들이 시간이 지나면서 얼마나 유지되는지 보고 싶다면 코호트 분석을 사용할 수 있다. 그리고 실제 구매 고객 중 어떤 고객군에 집중해야 할지 판단하고 싶다면 RFM 분석을 사용할 수 있다.

앞으로 실제 프로젝트를 할 때도 단순히 그래프를 많이 만드는 것보다, 먼저 문제 상황을 정의하고 그 상황에 맞는 분석 프레임워크를 선택하는 연습이 필요하다고 느꼈다. 결국 데이터 분석이 비즈니스 개선으로 이어지려면 '어떤 분석을 왜 하는지'를 설명할 수 있어야 한다. 이번 이론은 퍼널, 코호트, RFM이라는 각각의 분석 개념도 중요했지만, 결국 데이터 분석이 실제 의사결정으로 이어지기 위해서는 분석 목적과 방법론이 잘 연결되어야 한다는 점을 다시 생각하게 해준 수업이었다.