데이터를 통해 서비스를 보다.
아마존에서는 데이터가 모든 것을 지배한다(Data is King at Amazon).
데이터가 ‘지배하는’ 회사는 많다고 할 수는 없겠지만, 많은 회사들이 A/B 테스트나 지표 분석 등을 통해 서비스를 개선하고 있습니다.
제가 속해 있는 회사에서도 꾸준히 데이터 기반으로 프로덕트를 만들어나가려는 움직임이 있었는데요.
그 중심에서 제가 담당하는 서비스도 지표를 통해 성과를 측정하고자 하여 대시보드의 필요성이 생기고, 데이터 분석을 할 수 있는 사람이 (제가..) 대시보드를 제작해 보기로 했습니다.
이번 대시보드 제작기 시리즈를 통해 어떻게 데이터를 기반으로 서비스 지표를 정의했는지, 해당 지표를 기반으로 대시보드를 만들 때 어떤 점들을 고려했는지, 그 과정에서의 어려운 점 등을 이야기 해보려고 합니다.
1편은 기본적인 사용자 행동 데이터에 관한 설명과 서비스 지표에 대한 개념을 주로 설명합니다.
*기본적으로 데이터 분석에 대한 개념이 있지만 현업 경험이 없는 독자에게 맞춰진 글이긴 하지만, 데이터 분석에 대해 아예 개념이 없는 분들도 이해할 수 있게 쉬운 예시를 추가한 글입니다.
어떤 데이터를 봐야 하나요?
특정 서비스가 유저에게 어느 정도의 임팩트를 지니는지, 지난주 대비 이번주의 성과는 어떻게 변화했는지 등 내가 담당하고 있는 서비스의 건강 상태를 알고 싶습니다.
이때 우리는 어떤 데이터를 가지고, 어떻게 지표를 정의하고, 그 지표를 해석해야 할까요?
사용자 행동 데이터
어떤 쇼핑몰이 있다고 가정해 봅시다.
사용자의 장바구니에 담긴 상품 리스트, 실제 구매 내역, 리뷰뿐만 아니라 사용자가 검색한 이력, 스크롤하면서 노출된 상품들, 클릭한 상품, 특정 상품 페이지에 얼마나 체류했는지 등 다양한 행동 데이터를 수집할 수 있습니다.
이러한 데이터를 사용자 행동 데이터라고 부릅니다. (또는 이벤트 로그 데이터 등 다양한 이름으로도 불려요)
사용자 행동 데이터는 보통 서비스의 백엔드에서 관리하는 주문 DB, 상품 DB 등과 다르게 각 서비스의 특성이나 정책에 따라 다양한 방식으로 이벤트 데이터를 설계하게 됩니다.
이 과정에서 얼마든지 데이터가 유실되거나, 중복 집계되거나, 의도하지 않은 대로 적재될 수 있어요.
회사 내 데이터 문화 성숙도에 따라 사용자의 검색 이력은 적재하고 있지만, 사용자가 스크롤하면서 보게 되는 상품에 대한 정보는 남지 않을 수도 있죠.
혹은 장바구니 담기한 상품은 남지만, 상품을 담은 경로는 기록되지 않을 수도 있어요.
더 자세히 예를 들자면, 직접 검색해서 담은 상품인지, 아니면 이전 구매 내역에서 다시 선택해서 담은 상품인지 구분할 수 없을 수 있어요.
그래서 내가 담당하고 있는 서비스에 따라 어떤 지표를 개선 목표로 정할 것인지부터 정의해야 해요.
어떤 지표가 필요한지 알아야 다양한 행동 중 어떤 사용자 행동 기록이 필요한지 알 수 있어요.
그 기록을 데이터로 적재할 수 있도록 설계하고 실제 개발자가 설계에 따라 데이터를 저장해야 합니다.
지표를 정의하고, 이벤트 로그 데이터를 보강하다
그래서 서비스 대시보드를 만들기 위한 첫 삽으로 기획자분들과 모여서 엄청난 회의와 논의와 소통을 통해 …
우리 서비스에서 지속적으로 확인해야 할 지표를 정하는 것부터 시작했습니다.
지표란 ‘복합적이고 추상적인 사회현상을 쉽게 설명하기 위해 관련되는 지수나 척도로 개념화한 것(통계청)’이라고 하는데요.
서비스 지표란 서비스의 성과를 측정하고, 원하는 목표에 도달하기 위한 척도라고 이야기할 수 있겠습니다.
사실 이커머스 앱이나 웹 서비스에서 보는 지표는 거의 정해져 있습니다.
그럼에도 불구하고 많은 논의가 필요했던 이유는 해당 지표를 상세하게 정의해야 나중에 서로 다른 기대치를 가지지 않기 때문이었어요.
자세히 논의를 하더라도 수식을 다르게 생각하고 있을 수도 있고, 봐야하는 기간을 1일이나 7일 단위로 다르게 생각할 수도 있고, …
얼마든지 다르게 이해하는 부분이 생길 수도 있었습니다.
그래서 지표를 구하기 위한 쿼리를 어떻게 짜야할지 정도의 수준까지 자세하게 논의를 진행했습니다.
추후에 미스 커뮤니케이션으로 추가 비용이 발생하지 않게 하기 위해 초반에 많은 힘을 썼다고 할 수 있겠죠?
논의를 진행하는 과정에서 추가 또는 업데이트가 필요한 이벤트 로그 데이터가 있다면 개발자 분께 부탁해서 해당 이벤트 로그를 보강하는 작업도 꾸준히 진행했습니다.
화면 전환시 유실된 이벤트, 분석을 위해 추가되어야 하는 프로퍼티, 실제 값이 예상하지 못한 값으로 들어있거나 Null 로 오는 경우 등 다양한 케이스를 발견하고 이슈를 리포트했어요.
이 과정에서 정말 많은 분들이 빈 데이터를 메꾸기 위해 노력해주신 덕분에 풍부한 데이터를 바탕으로 지표를 추출할 수 있게 되었어요.
어떤 지표를 기준으로 서비스를 개선할까요?
그럼 위에서 치열하게 논의했다고 한 지표를 간단하게 소개해볼까 합니다.
회사마다 상세한 정의는 다를 수 있지만, 이커머스 도메인에서는 퍼널 분석의 관점에서 주로 ‘전환율’을 지표로서 확인합니다.
퍼널 분석과 전환율
우선 퍼널 분석에 관해 간단히 설명해볼게요.
아래 그림처럼 깔때기(퍼널) 모양 처럼 사용자가 이커머스 서비스에 진입하고 상품을 구매하는 과정까지 점점 줄어든다고 해서 퍼널 분석이라고 말해요.
또한 이 과정의 단계마다 전환이 일어난다고 표현하는데요.
예를 들면 검색을 한 사용자 중 검색 결과에서 상품을 클릭한 사용자는 전환이 일어났다고 해요.
이렇게 단계마다 얼마나 많은 사용자가 전환되는지 전환율을 구할 수 있겠죠?
위 퍼널을 예시로 보면, 검색한 유저 대비 상품 상세 조회 전환율, 장바구니 담기 전환율, 구매 전환율을 지표로 정의할 수 있겠네요.
이렇게 퍼널을 쪼개서 서비스를 살펴보면 어떤 부분에서 개선해야할지 그 지점을 찾기가 더 쉬워집니다.
예를 들어 상품을 조회하는 사용자는 많은데 장바구니 담기 단계로의 전환이 적다고 한다면 상품 자체의 매력도가 떨어지지는 않는지, 장바구니 담기 버튼이 찾기 어려운 UI인지 확인해볼 수 있겠죠?
그 외 지표들
서비스 지표로서 퍼널 분석을 기반으로 한 전환율 외에도 다양한 지표를 정의할 수 있습니다.
사용자 수, 실제 매출액, 서비스 체류 시간 등 성과를 측정하기 위해 필요한 지표는 서비스의 특성마다 다르게 정의될 수 있어요.
지표를 테이블로 만들다 (데이터 마트 구축)
우리 서비스 말고도 다른 모든 서비스의 이벤트 로그가 담긴 원천 테이블로부터 우리가 보고 싶은 데이터만 추출합니다.
그리고 지표를 구하기 쉬운 형태로 각 전환 이벤트를 조인한 1차 테이블을 만들어요.
1차 테이블을 통해 위에서 정의한 모든 지표를 구한 결과를 최종 테이블로 만들었습니다.
이 모든 과정은 일 단위 배치로 동작하도록 파이프라인을 구축했습니다.
그리고 언젠가 과거 시점과 비교할 때를 대비해 특정 시점부터 과거의 서비스 지표를 모두 백필합니다.
(백필이란 특정 과거 기간의 데이터를 모두 채워 넣는다고 생각하시면 됩니다.)
이제서야 준비를 마치다.
와우 이제야 대시보드를 만들 모든 준비를 마쳤습니다.
서비스와 관련된 사용자 이벤트 로그를 점검하고, 보강하고, 우리가 성과를 측정하기 위한 지표를 정의하고, 정의한 지표를 원천 이벤트 로그 데이터로부터 집계하여 테이블로 만들었습니다.
이제 이 테이블로 사용자 친화적인 그래프나 테이블 형태로 대시보드를 만들면 됩니다.
이 이후의 이야기는 2편에서 계속됩니다!
'데이터 분석 (DA)' 카테고리의 다른 글
[인과추론] 데이터의 편향 제거하기; Propensity Score란? (0) | 2024.11.24 |
---|---|
[SQL] 유저 데이터 분석에서 유용한 ROW_NUMBER, LAG 함수 (0) | 2024.01.21 |