유저 행동 데이터 설계 및 행동 분석툴 도입 (그로스팀)

시간 is Tik Tac Tok (feat. 실리카겔)

안녕하세요, 전략&그로스 매니저 변성준입니다.

갑자기 추워진 날씨에 놀란 오늘 정신차려보니 어느덧 11월 중순을 지나서 연말이 다가오고 있습니다. 다가오는 연말을 맞아 연간 회고를 준비하던 중 어떤 프로젝트가 가장 기억에 남았나 생각해보니, ‘유저 행동 데이터’ 설계와 분석툴(Mixpanel) 도입 프로젝트가 손에 꼽히는 것 같습니다.

그렇습니다, fromm 사업부의 ‘유저 행동 데이터 설계 및 행동 분석툴 도입기’ 시작합니다. 공유드릴 내용은 다음과 같습니다.

1. PA Tool 도입 과정
2. Tracking Plan 설계 과정
3. 도입 후 효과

라때는 말이야.. (과거의 데이터 분석 방식)

fromm 사업부에 합류전 Wonderwall Class 스쿼드에서는 유저 행동 데이터(로그 데이터)를 AWS S3에 쌓고 있었습니다. 이는 Wonderwall 시리즈A 시기에 쌓인 초기 데이터로 필요한 모든 정보가 하나의 데이터 형식으로 기록되는 방식이었습니다. 이를 최대한 활용하기 위해서 AWS Athena로 해당 로그 데이터를 DB화 하고 이를 추출하여 별도로 분석을 진행하는 방식으로 행동 데이터를 활용했습니다. 지금도 잘 활용하고 있는 AWS QuickSight를 사용한 대시보드 또한 이때 처음으로 스터디 하면서 접하게 되었습니다.

(출처) Analyze Google Analytics data using Upsolver, Amazon Athena, and Amazon QuickSight

해당 구조에서 데이터를 분석하는 과정에서 다음과 같은 어려움이 발생했습니다.

1. 설계되어 있지 않은 Tracking Plan으로 인한 무거운 데이터
2. 1번으로 인한 Athena에서의 데이터 조회시간 증가
3. 이로인한 전반적인 데이터 분석 작업시간 증가

서비스내 각각의 이벤트별로 구분되어 설계된 데이터가 아니었기 때문에, 데이터가 매우 무거웠고 이를 최대한 활용하기 위해 데이터를 정제하는 작업이 매우 까다롭고 분석이 오래걸렸던 기억이 납니다.

Mixpanel 도입기

#01 : 데이터 찾기

사업부 합류 후 처음으로 진행한 업무는 초기 MVP 검증을 지나고 성장기를 맞이한 fromm 서비스의 지속적인 그로스를 위해, 데이터 기반 전략 및 의사결정 체계를 갖추는 것이였습니다. 이에 바로 현재 구축되어 있는 데이터에 대해 파악을 시작했습니다.

(담당 개발자님): “현재 쌓고 있는 로그 데이터는 없습니다..! ㅠㅠ”

서비스 초기에 행동 데이터 설계 및 로깅은 우선순위에서 밀려있었고, 우리는 fromm 서비스의 유저 행동 데이터를 최초로 설계할 수 있는 영광을 얻게되었습니다.

#02 : 행동 데이터 설계와 분석툴 도입 (오히려 좋아~!)

오히려 좋습니다. 데이터 분석가님과 유저 행동 데이터를 설계하기 위해 이전 팀에서의 데이터 분석 방식의 문제점을 보완할 수 있는 요구사항을 아래와 같이 정리하였습니다.

1. 유저 행동 데이터는 비즈니스 목표에 맞춰 설계되어야 한다.
2. 한정된 리소스(그로스 PM 1명, 데이터 분석가 1명)로 전략 및 의사결정을 위해 주기적으로 확인이 필요한 데이터분석은 빠르게 진행할 수 있어야 한다.

1번의 경우 사업부내 주요 KPI와 목표 지표가 명확했기 때문에 설계가 용이했습니다. 하지만 2번의 경우 이전 Wonderwall에서의 경험과 지속적인 신규 기능이 도입되는 fromm의 상황을 보았을 때, 자체 분석 환경 구축보다는 효율성을 높이기 위해 유저 행동 분석툴(PA) 도입이 필요하다는 결론에 이르게 되었습니다.

#03 : 툴 도입에 대한 당위성 검토

fromm message 서비스는 아티스트와 유저간 소통앱으로 아티스트와 일상을 포함한 다양한 콘텐츠를 통해 실시간으로 소통할 수 있는 서비스 입니다. 더불어 다양한 아티스트와 팬 분들이 주요 사용자로 지금까지 약 170개의 국가에서 이용하고 있습니다. 따라서 다양한 변수들을 빠르고 신속하게 분석하기 위해 유저 행동 분석툴(Product Analytics, 이하 PA Tool) 도입이 필수라고 판단했습니다.

하지만, PA Tool은 기존에 사용하던 툴들에 비해 매우 비싼 사용료가 요구되었고, 이에 해당 툴 도입 필요성과 비즈니스 가치에 대한 PA Tool Proposal 작성했습니다.

마침 서비스 DB의 주요 데이터를 분석한 대시보드는 완성되어 서비스의 후행 지표들이 모티터링 되고 있었고, 지표 변화에 대해 여러 팀에서 문의가 들어오고 있는 상황이었습니다. 이 문의들을 활용하여 현재 확인할 수 있는 것과 확인할 수 없는 것을 마케팅팀 및 프로덕트팀의 관점에서 구분하여 정리하였습니다. 아래는 Proposal 중 행동 데이터 설계 및 PA Tool 도입을 통해 데이터 기반으로 확인 및 답변하게 될 수 있는 질문 중 일부입니다.

[마케팅]

1. 마케팅 팀에서 발행하는 콘텐츠를 통해 앱을 설치한 유저가 몇 명인지, 그 중 얼마나 회원가입을 하고 이용권을 구매했는지, 구매하지 않고 중간에 이탈했다면 원인이 무엇이었는지 확인이 가능한가?
2. 아티스트 입점 및 이벤트 진행, 외부 바이럴 및 아티스트 컴백등의 사항들에 대해 서비스의 가입, 이용권 구매, 메시지 활동, 작별결정 등 유저에 대한 영향 분석을 빠른 시간 내에 파악이 가능한가?

[프로덕트]

1. 이용권을 구매하지 않은 유저들은 어떤 아티스트에 관심이 있는지, 어떤 국가의 유저인지, 퍼널 중 어느 지점에서 이탈했는가? 더불어 그들의 국가, 가입시기 등의 변수에 따른 상관 관계는 없는가? 특징은 없는지에 대해 분석이 가능한가?
2. 구독을 해지하고 이탈한 유저들은 그렇지 않은 유저에 비해 어떤 특징이 있는가. 그들은 대조군 대비 얼마나 메시지를 잘 읽고 답변을 하는지, 이용하는 과정에서 주로 사용하는 기능이 있는지, 이탈하지 않은 유저대비 이탈한 유저들의 두드러진 특징이 있는가?
3. 기존 이용권에서 추가 혜택 이용권으로 전환하는 과정의 퍼널에서 전환율을 하락시키는 주요 원인은 무엇인가?

위의 사항들을 포함해 현재 확인할 수 없는 데이터 대해, 유저 행동 데이터 설계 및 빠른 분석을 위한 PA Tool 도입을 통해 얻을 수 있는 이점과 반영하여 제안했고, 최종적으로 PA Tool 도입이 결정되었습니다.

PA Tool은 여러 사항들을 고려하여 Mixpanel을 사용하게되었습니다.

#04 : 자 이제 시작이야!

유저 행동 데이터에 대한 설계는 PA Tool의 데이터 형식과 맞추면 바로 사용하기 좋았습니다. 이에 Mixpanel의 가이드에 따라 데이터 기획을 진행하였습니다. 데이터는 다음과 같이 구성됩니다.

유저/이벤트 분류 체계

• Event : 유저의 행동을 정의하며, 제품 클라이언트 / 서버에서 전송이 가능합니다. 회원 가입 완료, 메인 페이지 배너 클릭, 상품 상세 페이지 조회, 주문 완료 등이 대표적인 예시입니다.
• Event Property : 이벤트에 대한 상세 정보 및 자세한 컨텍스트를 정의합니다. 주문 완료 Event의 Event Property에는 구매자_Id, 구매상품_Id, 결제수단 등의 컨텍스트들이 반영될 수 있습니다.
• User Property : 제품을 사용하는 유저의 정보를 정의합니다. 지역정보, 유입 채널 정보, 가입 날짜, 구독 상품 플랜, 구매 횟수 등이 있습니다.

Mixpanel의 데이터 구성방식 및 예시 (출처: https://docs.mixpanel.com/docs/data-structure/property-reference)

주요 퍼널 및 User_Flow

해당 구조를 가지고이벤트 텍소노미인 Tracking Plan 설계를 위해서는 fromm 서비스의 주요 비즈니스 목표 및 주요 퍼널 즉 User_Flow에 대한 이벤트 설계가 필요합니다.

다만, User_Flow에 대해 정리되어 있는 문서가 존재하지 않아, 서비스에 대한 상세 정책 파악 및 주요 기능에 대한 스터디를 통해 User_Flow_Document를 작성하였습니다. 해당 과정을 통해 fromm 서비스에 대한 주요 기능에 대해 알 수 있었고 OS별 정책에 따른 기능 차이와 같은 파악하기 힘든 부분도 알 수 있게되어 지금 돌이켜봐도 진행하길 잘했다고 생각한 작업입니다.

User_Flow_Document가 필요한 이유

• Tracking Plan 명세서만으로 데이터에 대해 소통하기에는 어려움이 있다. 때문에 화면 및 주요 Flow에 데이터를 매칭하여 커뮤니케이션 코스트를 줄이고자 하였습니다.
• 주요 퍼널 단계에서의 로직파악 및 이 과정에서의 변인들을 파악해야 Event Property를 설계할 수 있기때문에 해당 User_Flow를 작성하였습니다.

주요 퍼널에 대한 User_Flow 예시

Event 네이밍 규칙

더불어 이벤트의 네이밍 규칙을 정해야 했습니다. 네이밍 규칙이 필요한 이유는 다음과 같습니다.

• 네이밍 규칙이 없을 경우 향후 데이터 기획의 과정에서 컨벤션이 규칙없이 작성될 수 있고 이는 곧 데이터에 대한 신뢰도 및 직관적인 파악이 불가하게 될 수 있다.
• 향후 모든 IT 조직 구성원들 모두가 데이터 기반으로 일할 수 있는 데이터 민주화를 목표로 하였을 때 이러한 정형화된 규칙은 필수적이다.

이에따라 서비스 특성을 반영한 네이밍 컨벤션에 따라 현재{event_action}_{object}_{object_name} 규칙으로 네이밍하고 있습니다. 더불어 기획이 진행되며 약속을 통해 일관성을 유지해야 하는 정책들에 대해서는 추가 네이밍 규칙을 통해 관리하게 되었습니다.

• 이벤트 네이밍 규칙
  • {event_action}_{object}_{object_name}
  • snake_case 사용
  • 모든 이벤트/속성은 소문자만 사용

구분	설명	예시
event_action	유저의 주요 행동을 분류	view(조회), click(클릭), complete(완료)
object	행동의 대상을 큰 카테고리로 분류	button(버튼), section(영역), page(페이지)
object_name	행동 대상의 구체적인 이름으로 분류	order(주문), signup(회원가입) 등

• 추가 네이밍 규칙
  • 페이지 조회의 경우 view_page_{페이지 또는 스크린 명} 으로 통일
  • 무결성이 높아야하는 이벤트의 경우, event_action이 complete로 시작하는 이벤트로 수집. (대부분 서버에서 전송) ex. 결제 완료(complete_purchase), 회원가입 완료(complete_signup)
  • 모든 이벤트 속성에는 서비스를 구분하기 위해 service_name이 들어감
    • 현재 message, store, channel 등으로 구분

가장 까다로운 Event Property

주요 퍼널에 대해 Event Property는 비즈니스 목표에 대한 컨텍스트를 확인할 수 있는 중요한 요소입니다. 때문에 이를 기획는 과정이 쉽지 않았습니다. 하지만, 진행하면서 요령이 생겼는데 바로 퍼널의 마지막 이벤트부터 설계하는 것 입니다.

fromm 앱 내 이용권 결제 퍼널 및 Event는 다음과 같습니다.

여기서 Event Property 설계시, 퍼널의 마지막 이벤트인 complete_purchase의 Property를 우선 설계합니다.

4번 퍼널에 설계 후, 해당 이벤트의 바로 상위 이벤트에 대해서는 이전 설계했던 Property에서 가져갈 수 있는 요소들은 그대로 승계하여 가져가게 됩니다. 그 후 상위 이벤트에서 고유로 모니터링해야 할 Property를 추가합니다. 이런식으로 퍼널의 이벤트 마지막부터 역으로 설계하는 방식은 이후 PA Tool을 통한 분석 시, 특정 Event Property 값을 통한 분석에 매우 용이합니다. 특히 최종 퍼널을 기준으로 고정적인 Event_property를 가져가는건 Mixpanel의 Holding Constant 기능을 사용하기 위해서이기도 한데요.

Mixpanel에서 Holding Constant는 데이터 분석 시 특정 변수를 고정하거나 필터링하여 그 변수의 영향을 배제한 상태로 다른 변수 간의 관계를 분석할 수 있도록 해주는 기능입니다. 이는 데이터 비교와 실험에서 특히 유용하며, 특정 세그먼트나 조건 하에서 사용자 행동을 더 정밀하게 이해할 수 있게 도와줍니다.

Holding Constant 기능의 특징

1. 다른 변수의 영향을 배제: 예를 들어, 플랫폼 간(AOS/IOS)의 차이를 비교할 때 플랫폼을 고정하면, 사용자의 다른 행동 패턴에 영향을 주는 요인을 최소화할 수 있습니다.
2. 더 정밀한 비교 가능: 특정 조건을 유지하면서 여러 집단 간의 데이터 분석을 수행하여 의미 있는 결과를 도출할 수 있습니다.
3. A/B 테스트 결과 분석: 특정 변수(예: 인구 통계 데이터나 초기 사용자 행동)를 기준으로 데이터를 고정하여 A/B 테스트의 영향을 더 정확하게 평가할 수 있습니다.

User_Property

User_Property는 유저의 특성을 조건에 따라 업데이트하는 방식으로 관리됩니다. 이를 위해 각 속성들에 대해 비즈니스 상황에 맞게 업데이트 주기를 고민해야 했습니다. 아래는 설계 과정에서 스터디를 위해 가상 서비스를 예시로 기획한 User_Property입니다. 주요 고려 사항을 확인할 수 있습니다.

User_Property 예시

Tracking Plan 설계

위의 항목들에 대해 서비스 주요 퍼널에서 Event 및 Event_Property, 유저들에 대한 User_Property에 대한 설계문서 Tracking Plan 작업이 완료되었습니다. 해당 요소들과 더불어 데이터 개발 및 QA, 향후 프로덕트 변동에 따른 비활성화를 반영할 수 있는 관리 포인트도 점진적으로 추가되었습니다.

fromm Tracking Plan

해당 Tracking Plan을 통해 개발팀과 각 이벤트에 대한 처리 방식 및 그 과정에서의 정책 및 이슈를 확인하면서 개발을 진행했고 QA과정을 거쳐 Event 로깅을 성공적으로 마칠 수 있었습니다.

유저 행동 데이터 및 PA Tool도입 이후의 효과.. 그리고 마무리

Tracking Plan 설계 및 Mixpanel을 통한 빠른 분석이 가능해진 후, 마케팅 및 프로덕트 기획, 서비스 운영 전반의 비즈니스 목표에 따른 액션들에 대한 데이터 기반 회고 및 이를 반영한 전략 수정이 가능하게 되었습니다.

주요 분석사항 및 기여항목

• 국내/해외 사용자의 이용권 구매 퍼널 분석을 통해 가장 높은 이탈률의 퍼널 개선을 통한 결제 전환율 개선
• 사용자 서비스 이용 패턴 분석을 통한 상위 이용권으로의 업셀링 전환 유도
• 아티스트 별 주요 유입 채널 분석 및 특징 분석을 통한 마케팅 전략 고도화
• 구독 사용자들의 이탈 유형 및 패턴 분석을 통한 활성화 및 구독유지율 개선
• 주요 기능 출시 후, 사용자 기능 활용도 분석 및 이를 통한 기능 고도화

이외에도 다양한 업무들의 의사결정을 하는데 많은 도움을 받고 있습니다. 위의 주요 분석사항 및 비즈니스적 효과들은 시간이된다면 추후 자세히 다뤄보도록 하겠습니다.

이전에 많은 시간을 할당해야 했던 분석 업무를 빠른 시간 내에 진행할 수 있었으며, 이를 통해 절약된 리소스를 복잡하고 난이도가 높은 분석과 가설 설정 및 실험 설계에 투자할 수 있었습니다.

해당 프로젝트를 진행하면서 단순 데이터에 대한 설계 및 분석툴에 대한 사용법에 대한 습득뿐만 아니라, fromm의 다양한 비즈니스 목표를 명료하게 확인하고 서비스의 어떤 부분이 비즈니스 목표에 영향을 미칠지 파악할 수 있었습니다.

마지막으로 해당 지면을 통해 급한 우선순위 사항이 있음에도 도입 과정을 도와주신 개발팀, 프로덕트팀, 그로스팀 구성원분들께 감사하다는 말씀을 드리고 싶습니다.

긴 글 읽어주셔서 감사합니다 :)