10x 프로덕트 데이터 분석 수업 후기

1. 프론트엔드 개발에서 프로덕트 데이터 분석으로

프론트엔드 개발자로 일하며 제품의 화면과 기능을 만들었다. 코드를 구현하다 보니 한 걸음 더 나아가 제품이 어떤 방향으로 가야 할지 고민하는 프로덕트 일에도 관심이 생겼다.

관심은 사용자 분석으로 이어졌다. 내가 만든 제품을 사람들이 어떻게 쓰는지, 어떤 기능에 반응하는지 데이터로 직접 확인하고 싶었다. 그동안은 기획자가 정해준 이벤트를 GA에 연결하는 일이 대부분이었다. 이제는 어떤 행동을 추적해야 궁금한 점에 답할 수 있을지부터 직접 설계해보고 싶었다.

그런 마음으로 10x 프로덕트 데이터 분석 수업에 지원했다. 분석 도구 사용법을 익히는 데 그치지 않고, 내가 만든 제품의 사용자 데이터를 읽어 개선으로 이어가는 방법을 배우고 싶었다.

2. 수업에서 배운 것: 제품 질문을 지표와 분석으로 연결하기

처음에는 분석 도구를 다루는 법을 주로 배울 거라고 생각했다. 그런데 수업에서 먼저 한 일은 제품에 관한 궁금증을 질문으로 만들고, 답을 찾는 데 필요한 지표와 데이터를 고르는 것이었다. 데이터를 모으는 데 그치지 않고 제품의 결정을 돕는 데 써야 한다는 점도 배웠다. 도구를 열기 전, ‘이 결과로 무엇을 판단하고 싶은가’를 먼저 생각하게 됐다.

AARRR로 사용자 흐름 보기

1주차에는 AARRR 프레임워크를 배웠다. 사용자의 흐름을 다섯 단계로 나눠 살펴보는 방법이다.

• 획득 (Acquisition)

• 활성화 (Activation)

• 유지 (Retention)

• 수익 (Revenue)

• 추천 (Referral)

제품 전체를 한꺼번에 보기보다 지금 확인할 행동이 어느 단계에 있는지 정리할 때 쓸 수 있다. 사용자 유입과 핵심 기능을 처음 쓰는 건 서로 다른 행동이다. 어느 구간을 개선할지 정하면 필요한 지표와 분석 질문도 또렷해진다. AARRR은 제품 점수표라기보다 다음에 살펴볼 곳을 찾는 틀에 가까웠다.

트래킹 플랜 설계

트래킹 플랜은 지금까지 해온 일과 특히 맞닿아 있었다. 나는 기획자가 정한 이벤트를 GA에 연결하는 경우가 많았다. 교안에서는 사용자 행동을 기록하기 전에 다음을 따져 이벤트와 속성, 기록 조건을 정리했다.

• 누가, 언제, 어디서, 무엇을, 어떻게 했는지

• 어떤 이벤트와 속성이 필요한지

• 어떤 시점에 기록할지

분석으로 답하고 싶은 질문을 먼저 정해야 필요한 데이터도 고를 수 있었다. 이벤트를 많이 추가하기보다 각 이벤트의 의미와 기록 시점을 분명히 하는 게 우선이다. 그래야 팀원마다 같은 행동을 다르게 해석하거나 필요한 조건이 빠져 분석하지 못하는 상황도 줄어든다.

Amplitude와 A/B 테스트

2주차에는 Amplitude에서 세그먼트와 차트를 만들고 여러 분석 방법을 다뤘다.

• 퍼널: 단계가 이어지는 동안 사용자가 어디서 줄어드는지 살펴본다.

• 사용자 여정: 사용자가 제품 안에서 어떤 흐름으로 움직이는지 본다.

• 리텐션: 일정 시간이 지난 뒤 다시 돌아오는지 확인한다.

• 코호트: 공통 조건을 가진 사용자를 묶어 행동을 비교한다.

A/B 테스트도 배웠다. 화면이나 기능을 비교하려면 먼저 가설과 성공 지표를 정해야 한다. 무엇을 바꿀지보다 어떤 사용자 행동이 달라지길 바라는지부터 분명히 해야 했다.

3. 실전 미션 수행 과정: 사용자 행동 로그 설계와 트래킹 플랜

이번 미션에서는 주어진 이벤트를 분석하는 대신 기록할 사용자 행동부터 설계했다. 메인 페이지와 카테고리 페이지에서 사용자의 흐름을 다음 순서로 정리했다.

1. 페이지 진입

1. 배너·상품 노출

1. 배너·상품 클릭

페이지에 들어온 사용자가 무엇을 보고 어떤 요소를 선택하는지 이벤트로 따라가도록 페이지별 행동을 묶었다.

이벤트 이름과 기록 시점

이벤트 이름은 페이지와 행동을 마침표로 나누고, 각 단어는 snake_case로 적었다. 이름만 봐도 어디서 어떤 행동이 일어났는지 알 수 있도록 했다.

• main.pageview: 메인 페이지가 사용자에게 표시될 때

• main.banner_click: 사용자가 메인 배너를 클릭할 때

• category.product_click: 사용자가 카테고리 페이지에서 상품 카드를 클릭할 때

배너와 상품 카드의 노출은 페이지가 열렸다는 이유만으로 기록하지 않았다. 실제 사용자 화면에 표시됐을 때 impression 이벤트로 남기도록 정의했다. 클릭 이벤트만으로 알 수 있는 건 눌린 횟수뿐이고, 그 전에 얼마나 노출됐는지는 알 수 없다. 노출과 클릭을 함께 기록해야 영역이나 상품별 반응을 비교할 기반이 생긴다.

이벤트에 필요한 속성

이벤트만 기록하면 어떤 상품이나 영역에 대한 반응인지 알기 어려워, 분석에 필요한 속성도 함께 정리했다. 속성은 이벤트에 덧붙는 맥락 정보다. 같은 상품 클릭이라도 어느 영역에서 발생했는지 구분할 수 있다.

• 상품 노출·클릭: section(영역), productid(상품 ID), productindex(화면 내 순서)

• 배너 노출·클릭: bannerid(배너 ID), bannerindex(노출 순서)

• 카테고리 페이지: category_id(카테고리 식별자)

미션을 하며 배운 점

트래킹 플랜은 이벤트 이름만 모아놓은 표가 아니었다. 어떤 행동을 이벤트로 볼지, 언제 기록할지, 결과를 해석하는 데 필요한 속성은 무엇인지까지 정하는 일이었다.

전에는 전달받은 이벤트를 GA에 연결하는 일이 중심이었다. 이번 미션을 하며 분석 질문에서 출발해 필요한 로그를 먼저 제안하는 역할도 내가 맡을 수 있겠다고 느꼈다. 개발할 때 이벤트 이름과 속성, 발생 시점을 함께 정리해두면 데이터가 쌓인 뒤 분석하기도 편하다. 다음에는 제품을 만들면서부터 측정할 행동을 함께 고민해보고 싶다.

4. 받지 못한 피드백과 미션에서 얻은 점

내가 정한 이벤트와 속성이 실제 제품을 분석하기에 충분한지 현직자에게 확인받고 싶었다. 특히 아래 내용을 실무자의 시선으로 점검받고 싶었다.

• 어떤 행동을 각각의 이벤트로 나눌지

• 기록 시점을 언제로 할지

• 분석에 필요한 속성을 빠뜨리지는 않았는지

혼자 쓰다 보면 놓치는 조건이 생기기 마련이라, 실제 팀에서 기획·분석·개발이 어떤 기준으로 합의하는지도 궁금했다.

📝 가장 아쉬웠던 점수업을 듣던 중 급성 편도염으로 아파 과제를 기한 안에 제출하지 못했다. 그래서 기대했던 피드백도 받지 못했다. 내가 세운 기준이 실무에서도 괜찮은지 확인하고 싶었기에, 현직자의 의견을 들을 기회를 놓친 점이 특히 아쉽다.

피드백을 받지는 못했지만, 미션을 하며 개발자도 사용자 행동에서 출발해 필요한 이벤트와 트래킹 플랜을 제안할 수 있겠다고 느꼈다. 다음에는 분석에 필요한 로그를 제품을 만드는 단계부터 함께 설계해보고 싶다.

5. 배운 내용을 내 제품에 적용해보기

배운 내용을 써보려면 먼저 개발 중인 커플 여행 지도 앱을 완성해야 한다. 이후 트래킹 플랜을 짜서 사용자가 지도에서 어떤 행동을 하는지 기록해보고 싶다.

가장 궁금한 건 지도에 사진을 채우는 방식이다. 선택한 지역에만 사진을 보여주는 A안과, 사진이 없는 주변 영역까지 채우는 B안 가운데 어느 쪽에서 지도 저장 완료율이 높아지는지 알아보고 싶다. B안은 사진 한 장이 인접한 여러 시 영역에 이어져 보이는 방식이다.

• A안: 선택한 지역에 등록된 사진으로 지도 채우기

• B안: 사진이 없는 영역까지 채워 지도 채우기

A안과 B안의 차이를 보여주는 콘셉트 예시 이미지예요. 실제 앱 화면이 아닌 설명용 시안입니다.

실험에서 우선 확인할 지표는 두 가지다.

• 주 지표: 실험에 노출된 사용자 중 지도를 저장한 비율

• 함께 볼 지표: 노출 사용자 1명당 등록한 사진 수

사진이 인접 지역까지 이어지는 B안에서 지도 저장 완료율이 더 높아질 거라고 예상한다. 저장은 완성한 지도를 간직하려는 행동이고, 사진 등록은 지도에 콘텐츠를 더하는 행동이다. 두 지표를 함께 보면 사진을 채우는 방식이 각 행동에 어떤 차이를 만드는지 살펴볼 수 있다.

두 안을 제대로 비교하려면 노출과 이후 행동을 함께 기록해야 한다.

• 어떤 안(A안 또는 B안)을 보여줬는지

• 저장을 완료했는지

• 노출된 사용자 중 저장을 완료한 비율이 얼마인지

• 사용자별 사진 등록 수가 얼마인지

저장 클릭 수만 비교하면 각 안을 본 사용자 수가 다를 때 결과를 제대로 해석하기 어렵다. AARRR 흐름에서 저장과 사진 등록을 어느 단계의 행동으로 볼지도 정리해보고 싶다.

6. 이런 사람에게 추천하고 싶다

🎯 이런 개발자에게 추천해요내가 만든 제품의 사용자 데이터를 직접 보고 싶거나, 화면과 기능이 실제로 어떻게 쓰이는지 확인하고 싶은 사람에게 잘 맞는다. 기획자가 정한 이벤트를 분석 도구에 연결하는 데서 더 나아가, 어떤 행동을 기록할지부터 고민해보고 싶다면 특히 추천한다.

AARRR부터 Amplitude 분석, 트래킹 플랜과 실험 설계까지 제품 데이터를 살펴보고 활용하는 흐름을 배울 수 있었다. 아직 커플 여행 지도 앱에 적용하진 못했다. 앱을 완성하고 실제로 실험해본 뒤 결과와 배운 점을 이 후기에 덧붙이고 싶다.