마케터로 일하면서 "데이터 기반으로 판단한다"고 입버릇처럼 말했는데,
오늘 강의를 들으면서 사실 데이터의 표면만 긁고 있었다는 걸 깨달았습니다.
ROAS 보고, CTR 보고, 전환율 보는 것과 PM이 데이터를 다루는 방식은 결이 다르더라구요
PM은 숫자를 읽는 게 아니라, 숫자가 만들어지는 구조 자체를 설계한다는 차이가 선명하게 보였습니다.
데이터와 지표, 같은 말 아닌가요?
처음엔 데이터랑 지표를 거의 같은 말로 쓰고 있었는데, 오늘 제대로 구분했습니다.
| 구분 | 정의 | 예시 |
| 데이터 (Data) | 수집된 원시 사실 | 사용자 클릭 기록, 페이지 체류 시간 |
| 지표 (Metric) | 데이터를 가공해 의미를 부여한 것 | 전환율, DAU, 이탈률 |
데이터는 재료고, 지표는 그 재료로 만든 요리!
로그 설계: PM이 데이터를 '만드는' 사람인 이유
마케터 시절엔 GA나 픽셀이 알아서 데이터를 수집해준다고 막연히 생각했는데,
사실 그 데이터가 쌓이려면 누군가 로그를 설계해야 합니다. 그 누군가가 PM이었습니다.
로그란? 사용자가 서비스에서 취하는 모든 행동을 기록한 것
로그의 주요 용도:
- 문제 해결 및 디버깅: 결제 오류가 어느 단계에서 발생했는지 파악
- 사용자 행동 분석: 어떤 페이지에서 이탈하는지, 어떤 버튼을 누르는지 추적
- 성과 측정: KPI 달성 여부 확인
마케터 때 "왜 이 이벤트 데이터가 안 잡히죠?"라고 카페24 어플리케이션 개발 담당자분한테 물어본 적이 여러 번 있었는데,
혹시 그게 로그 설계가 안 돼 있어서였떤걸까요..
PM이 미리 버튼 클릭 로그 남겨달라고 요청해야 나중에 분석이 가능한 구조였을지도..
데이터 분석 방법론: 퍼널, AARRR, A/B테스트
퍼널 분석 (Funnel Analysis)
사용자가 목표에 도달하기까지의 여정을 단계별로 추적하는 방법입니다.
방문 → 상품 조회 → 장바구니 → 결제 시도 → 구매 완료
각 단계에서 몇 %가 이탈하는지 보고, 이탈률이 높은 구간을 집중 개선합니다.
이커머스에서 "결제 페이지 이탈률이 높다"고 판단하는 건 UX 개선의 시작점이 됩니다.
AARRR 프레임워크
| 단계 | 의미 | 핵심 질문 |
| Acquisition | 획득 | 어떻게 유저를 데려오는가? |
| Activation | 활성화 | 첫 경험이 좋았는가? |
| Retention | 유지 | 다시 돌아오는가? |
| Revenue | 수익 | 돈을 내는가? |
| Referral | 추천 | 주변에 알리는가? |
마케터 시절엔 Acquisition에만 집중했던 것 같습니다.
퍼포먼스 마케팅이 그 영역이니까요. 근데 PM은 5단계 전체를 봐야 한다는 게 오늘 느낀 가장 큰 차이였습니다.
A/B 테스트
두 가지 버전을 동시에 테스트해서 어떤 것이 더 효과적인지 데이터로 검증하는 방법입니다.
실제 사례: 리디북스 AI 도서 추천
이론이 아니라 실제 PM이 어떻게 데이터로 의사결정하는지를 보여줬습니다.
- 문제 정의: AI 도서 추천 기능을 론칭하기 전, 어떤 사용자에게 먼저 보여줄 것인가?
- 가설 수립: 기존 알고리즘 추천 섹션("이 책을 구매한 분들의 선택")의 장르별 구매 기여도를 보면, AI 추천이 효과적인 사용자 그룹을 예측할 수 있을 것이다.
- 검증: 장르별로 알고리즘 추천 섹션의 구매 기여 점수를 분석 → 일반도서·만화 독자에게 효과적, 로맨스·장르물 독자는 효과 낮음
- 결과 적용: 일반도서·만화 독자를 대상으로 먼저 AI 추천 론칭
여기서 배운 포인트는 두 가지입니다.
- 프록시 지표 활용: 새 기능의 효과를 직접 측정하기 어려울 때, 유사한 기존 기능의 데이터로 예측할 수 있다
- 노출 위치도 데이터로 결정: 홈 화면은 PV가 높지만 구매 비중 낮음 → 개인화 추천 적합 / 도서 상세 페이지는 구매 비중 높음 → 맥락 기반 추천 적합
구글 애널리틱스: 마케터가 PM처럼 보는 법
GA는 마케터 시절부터 써왔는데, 오늘 PM 관점에서 다시 보니 읽는 방식이 달랐습니다.
마케터 시절 내가 보던 것: 광고 유입수, 전환율, ROAS
PM이 보는 것:
- 세션당 평균 참여 시간 → UX가 사용자를 붙잡고 있는가
- 이탈 페이지 → 어디서 경험이 끊기는가
- 활성 사용자당 참여 세션 수 → 재방문이 일어나는가
같은 툴인데, 보는 관점이 완전히 다르다는 걸 오늘 처음 실감했습니다.
배운 걸 바로 써먹다: 뷰티/헬스 트렌드 소싱 대시보드 만들기
강의에서 데이터 기반 의사결정을 배우고 나니, 평소 관심 있던, 몸담고 있떤 헬스앤뷰티 리테일 도메인에 직접 적용해보고 싶어졌습니다. 그래서 오늘 바이브코딩으로 간단한 툴을 하나 만들어봤습니다.
만든 것: 뷰티/헬스 트렌드 소싱 대시보드
핵심 기능:
- 네이버 데이터랩 API 연동해서 키워드별 검색량 트렌드 자동 수집, 시각화
- 2026 올리브영 공식 트렌드 키워드(FULLMOON) 기반으로 카테고리 구성
- 검색량 상승 키워드에 맞는 브랜드 후보 카드 표시 + 입점 여부 수동 체크
만들면서 배운 것:
오늘 강의에서 "데이터는 의사결정의 근거"라고 배웠는데, 직접 만들어보니 그게 더 선명하게 느껴졌습니다. 예를 들어 멜라토닌 키워드를 1년치로 보니 매년 6~7월에 검색량이 피크를 찍는 계절성이 보였습니다. 이걸 알면 소싱 타이밍을 데이터로 결정할 수 있는 거죠.
동시에 데이터의 한계도 직접 부딪혔습니다. 검색량이 왜 떨어지는지는 이 데이터만으로 알 수 없었습니다. 실제 구매 데이터와 교차해야 정확한 판단이 가능한데, 그게 없으니 "트렌드가 꺾인 건지, 소비자가 브랜드를 이미 알아서 검색 없이 바로 구매하는 건지" 구분이 안 됐습니다. 오늘 강의에서 배운 것처럼, 데이터는 맥락과 함께 읽어야 한다는 걸 직접 체감했습니다.
AI 브랜드 분석 기능도 붙여봤는데, 소규모 브랜드는 AI가 틀린 정보를 그럴듯하게 생성하는 할루시네이션 문제가 있었습니다. 결국 "AI가 어디까지 믿을 수 있고, 어디서부터 사람이 판단해야 하는가"를 직접 경험으로 배웠습니다.
'PM 기록' 카테고리의 다른 글
| 내일배움캠프 TIL: '그 사람 참 좋은 PM이었지..' 소리 듣는 방법? (0) | 2026.06.08 |
|---|---|
| 내일배움캠프 사전캠프 TIL: PM이 문서를 못 쓰면 개발자가 야근한다 (0) | 2026.06.05 |
| 내일배움캠프 TIL: API 키 3개 날리고 배운 것 .... 바이브 코딩 2일차 (0) | 2026.06.01 |
| 내일배움캠프 TIL: 코드 한 줄 못 짜는 내가 API 3개 연동한 투자 앱을 만들다? (0) | 2026.05.29 |
| 내일배움캠프 TIL: "기능을 추가하면 경험이 좋아진다"는 착각, 마켓컬리와 올리브영에서 배운 것 (0) | 2026.05.28 |