‘수억 명의 사용자’ 같은 거대한 목표는 ‘감’으로는 결코 달성할 수 없다
각자가 만들고 있는 제품의 특성에 맞는 올바른 지표(Metric)를 선택하고, 그 지표를 꾸준히 개선해 나가는 것은 J 커브 성장을 달성하기 위한 가장 핵심적인 활동이다. 문제를 모르면 개선할 수도 없기 때문이다. 그런데 이런 고유한 지표를 확인하는 것 자체가 어렵다면 실제 업무에 있어서 활용도가 크게 떨어지기 때문에, 클릭 한번에 확인할 수 있는 ‘대시보드’를 만드는 것이 좋다.
이 활동의 중요성을 알고 있는 로켓펀치는 많은 노력을 들여 로켓펀치만의 지표를 구성하고 쉽게 확인할 수 있는 대시보드를 구성했다. 이 글에서는 그 과정에서 얻었던 지식들을 나누고자 한다.
대시보드 구상 단계
대시보드의 실제 개발에 앞서 실무적으로 고려해야 크게 두 가지다. ‘어떤 데이터를 보여줄 것인지’와 ‘어떤 시간 단위를 사용할 것인지’에 대한 결정이다.
보여줄 데이터에 대한 결정
로켓펀치는 사용자가 생성한 데이터를 재가공하여 또 다른 사용자들과 연결해 주는 ‘사용자 참여형 콘텐츠 플랫폼’이다. 이런 특성을 가지는 서비스의 성장에 가장 중요한 것은 사용자들을 점점 더 서비스에 많이 참여하도록 하는 것이다.
예를 들어 우리가 게시판 기반의 커뮤니티 서비스를 만들고 있다면, 회원 가입 없이 글만 읽던 사용자를 회원 가입을 하게 하고, 글을 쓰게 만드는 것이 참여 수준을 높이는 것이다. 작성되는 글(=콘텐츠)이 많아질 수록 더 많은 사람들이 그 글을 보기 위해 우리 서비스에 방문할 것이기 때문이다.
로켓펀치에는 회원가입 없이 다른 사용자들의 프로필이나 기업 정보, 채용 정보를 보는 ‘방문자’들이 있고, 본인의 프로필을 상세히 업데이트하고 기업 정보와 채용 정보도 기재하는 ‘회원’들이 있다. 로켓펀치가 올바른 방향으로 나아가고 있는지는 방문자들이 회원으로 전환되는 비율을 통해서 알 수 있으므로, 대시보드는 한눈에 사용자들의 ‘참여 수준’을 볼 수 있는 항목들로 구성이 되어야 한다.
예를 들면 아래와 같은 항목들을 한눈에 확인할 수 있는 funnel 분석 그래프를 대시보드에 표시하는 것이다.
– 전체 방문자 수
– 전체 방문자 수 대비 재방문자의 비율
– 전체 방문자 수 대비 회원 가입을 한 비율
– 회원 가입자 중에서 프로필을 상세히 업데이트 한 비율
데이터 처리 시간 단위에 대한 결정
데이터를 대시보드에 표시함에 있어서 ‘시간 단위’는 아주 중요한 요소다.
예를 들어 우리가 ‘메시징 플랫폼’을 만들고 있다고 가정해 보자. 메시징 플랫폼이 사람들에게 제대로 가치를 주고 있다면, 당연하게도 사람들이 하루에도 여러 번 사용해야 한다. 그런데 어떤 외적인 문제가 발생하여 사람들이 하루에 수회 이상 사용하던 경향이 1주에 수회 사용하는 것으로 바뀌어 가고 있다고 생각해보자. 이는 분명 커다란 문제이며 반드시 대응을 해야 한다. 그런데 통계 데이터를 주 단위로 설정해서 보고 있다면, 이런 변화를 인지하기는 어렵다. ‘주’를 단위를 잡았을 때는 그 주에 그 제품을 한 번이라도 사용했다면 ‘활성 사용자’로 표시가 되므로 일 수회 쓰 던 경향이, 주 수회 쓰는 경향으로 바뀌더라도 데이터 상으로는 변화가 없는 것이다. 매일 쓰는 것이 중요한 서비스라면 시간 단위는 ‘주’가 아니라 ‘일’이어야 한다.
다른 예로 ‘여행 상품 제공 플랫폼’을 생각해보자. 우리가 만들고 있는 서비스가 제대로 동작하고 있다면, 사용자가는 얼마 간 여행 상품 구매 활동을 한 후 우리 서비스를 잠시 떠나야 한다. 여행 과정이 완료되었기 때문이다. 일반적인 경제 활동 인구들은 휴가에 맞춰서 일년에 여행을 2~3번 정도 떠나기 때문에, 우리가 만드는 서비스를 통해 여행 상품 구매 활동에 일주일 정도를 쓰고 여행을 다녀온 후, 몇개월이 지나 다시 접속해서 여행 상품을 구매 하는 패턴은 지극히 자연스러운 경향이다. 그런데 이런 서비스를 ‘주’ 단위로 분석한다면 어떻게 될까? 아주 단순화시킨다면, 1주차의 활성 사용자가 2주차부터 24주차(=6개월)까지는 모두 0으로 표시될 것이다. 서비스는 제대로 동작하고 있음에도 불구하고 말이다. 따라서 사용자가 1년에 한두 번 사용해도 충분한 가치를 느낄 수 있는 서비스라면 데이터 분석의 시간 단위는 최소한 월 단위 이상, ‘월, 분기, 반기’ 등이 되어야 할 것이다.
로켓펀치는 스타트업 채용 정보 제공 플랫폼에서 개인과 기업이 비즈니스의 성장에 필요한 다양한 정보를 얻을 수 있는 네트워킹 플랫폼으로 진화하고 있다. 우리는 로켓펀치가 사용자들이 적어도 일주일에 한번씩은 접속하는 서비스가 되어야 한다고 생각하기 때문에, 데이터를 처리하는 기본 시간 단위를 ‘주’로 잡았다.
대시보드 구현 단계
구현 목표와 로켓펀치의 현황, 그리고 방향
필자(=정희동)가 로켓펀치에 합류하는 과정에서 접했던 로켓펀치의 큰 목표 중 하나는 ‘이용자 분석을 제대로 해 보고 싶다’는 것이었다. 매우 흥미로운 과제라고 생각했다. 이용자 분석을 바닥부터 할 수 있는 기회는 그리 흔치 않고, 많은 것을 할 수 있을 것이라 생각했기 때문이다. 구체적으로 이용자들이 얼마나 들어와서 어떤 행동을 하는지 funnel 형태로 보고 싶고, 각각의 행동에 어떤 이유가 있는지 알고 싶었다.
합류 후 곧바로 시스템에 대한 파악을 시작했다. 로켓펀치 웹 서비스의 로그는 Elasticsearch의 제품군들을 비롯한 몇 개의 도구들을 이용해서 저장되고 있었다 (상세 내용은 아래에 설명).
이용자 식별과 이용자들의 행동에 대한 정의를 마친 후 간단한 결과를 빠르게 내는 방향으로 작업을 시작했고, 앞으로의 분석에 걸림돌이 될 부분들을 빠뜨리고 넘어가지 않도록 주의를 기울였다.
기간의 정의
앞서 언급된 이유에 따라 데이터의 기본 지표는 일주일 단위로 생성하기로 했다. 또 로켓펀치 팀에서는 보통 일주일 단위로 새로 추가되거나 개선된 기능을 릴리즈 하기 때문에 일주일이라는 단위는 기본 단위로 적절하다고 생각되었다. 그리고 매주 지표를 생성해서 최근 12주를 비교하기로 했다.
이용자의 행동
정의한 행동은 크게 보았을 때 아래와 같다.
1. 회원 가입
2. 개인정보 입력
3. 사진 등록
4. 학력 및 경력 추가
5. 자기 소개 수정
6. 친구 추가 및 친구 수락
로켓펀치 웹 서비스를 이용할 때 이루어지는 위 행동들은 서로 다른 API 요청 경로(path of request for API)를 가진다. 그리고 해당 로그는 인코딩된 유저 식별자와 함께 저장되므로 로그인 후 어떤 행동을 했는지는 저장된 로그를 이용자별로 모아서 request path를 보는 것만으로 알 수 있었다.
로그가 저장되는 방식
현재 로켓펀치의 로그는 몇 가지 툴을 사용해 아래와 같은 방식으로 저장되고 있다.
1. 웹 서버 디스크에 로그가 저장됨
2. filebeat가 디스크의 로그를 읽어 별도 서버의 redis로 보냄(이 때 redis는 queue처럼 동작함)
3. redis와 같은 서버의 logstash가 redis에 저장된 로그를 읽어 별도 파일로 저장하고, elasticsearch의 인덱스에도 저장함
4. kibana에서 elasticsearch에 저장된 로그를 살펴볼 수 있음
아래는 elasticsearch에 저장된 로그의 모습이다(일부 항목만 표시).
{
“_index” : “rocketpunch”,
“_type” : “logs”,
“_id” : “AVlfyGjraKOw-4GiFG_H”,
“_source” : {
“offset” : 42279229,
“content_length” : “105455”,
“latency” : “0.303436994553”,
“user_id” : “—-“,
“timestamp” : “2017-01-02T15:24:43.584033Z”,
“ip” : “—–“,
“response_code” : “200”,
“referer” : “https://www.rocketpunch.com/,
“user_agent” : “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36”,
“request_id” : “—–“,
“path” : “/api/users/network_request”,
“method” : “GET”,
}
}
이용자별 로그 모아보기
elasticsearch에 저장된 로그는 kibana에서 찾아보기 아주 편하지만, 검색 결과를 원하는 모양으로 만들고 싶다면 결국 query를 사용해야만 했다. elasticsearch에서 공식적으로 지원하는 언어별 client가 몇 가지 있는데, 익숙한 python을 쓰기로 했다. 사실 이 결정을 내리기 전에 bulk api를 써봤는데, 속도가 꽤 느린데다 대용량 처리 중 오류가 나기도 했다.
1주일 동안의 로그를 읽어 아래와 같은 모양으로 만든다.
이용자 식별자, 시간, 행동, … (나머지 정보들)
이용자 식별자와 시간으로 정렬하면 하나씩 읽어 유저가 어떤 행동을 했는지 알 수 있다. 아래는 그 예시이다.
user_1 2017-01-02T18:58:57.356091Z REG
user_1 2017-01-02T18:59:11.388345Z DET
user_1 2017-01-02T19:04:08.287961Z CAR
user_1 2017-01-02T19:05:10.746819Z CAR
user_1 2017-01-02T19:06:28.057567Z CAR
user_1 2017-01-02T19:08:47.662613Z CAR
user_1 2017-01-02T19:12:04.052667Z EDU
user_1 2017-01-02T19:12:26.961197Z EDU
…
user_1은 회원 가입(REG) 직후 개인 정보를 입력했고(DET), 몇 가지 경력사항(CAR)과 학력사항(EDU)를 입력했다. 이처럼 간단하게 유저의 행동을 살펴볼 수 있고 원한다면 행동 패턴을 더 정의하고 다른 정보를 결합해 더 상세한 행동을 관찰할 수도 있을 것이다.
로그인하지 않은 유저들 다루기
지금까지 위에서 다룬 내용은 로그인한 유저의 행동을 로그로부터 알아내는 방법이었다. 하지만 로그인하지 않은 많은 유저들의 방문은 어떻게 살펴볼 수 있을까? 웹 서버에서 세션 key를 발급하고는 있지만 발급된 key의 정보를 오랜 기간 유지해야 하며 사람이 아닌 봇에 대한 처리 또한 간단하지만은 않은 일이다. Google Analytics와 비슷한 기능을 하는 piwik을 사용해보려 했지만 필요한 기능에 비해서 유지 및 관리 비용이 부담스러운 수준이었다. 그래서 예전부터 이용하던 Google Analytics에서 전체 이용자 수와 신규 이용자 수를 가져오기로 했다.
실제 대시보드 만들기
지표를 살펴보기 쉽도록 대시보드의 형태로 funnel 정보를 나타내야 했다. 간단한 표와 그래프를 보여주기 위한 도구로는 jupyter notebook을 골랐고, pandas와 matplotlib를 활용했다.
지금까지 위에서 만든 데이터를 읽어 DataFrame으로 만들고 각각의 이용자 수와 비율을 동시에 표로 나타냈다. 이는 공휴일이나 연말연시같은 이벤트에 이용자 수가 영향을 받기에 반드시 비율을 같이 볼 필요가 있다고 생각했기 때문이다. 그리고 그래프를 그릴 때 전체 이용자 수와 신규 이용자(대부분 비로그인 이용자들)를 같이 나타내면 로그인 이용자들의 수가 비로그인 이용자 수에 비해 매우 적어 로그인한 이용자들의 행동은 그래프에서 아주 작게 나타난다. 그렇기 때문에 로그인 이용자들의 행동만 따로 그래프로 그려야 눈으로 비율의 변화 정도를 확인할 수 있었다. 아래는 그렇게 그린 funnel 분석 그래프이다.
남은 과제들
대시보드의 표와 그래프로 funnel 지표는 살펴보았다. 하지만 다음 과정인 ‘각 단계의 행동을 행하거나 행하지 않은 이유’를 알아내는 것은 아직 수행하지 못했다. 이를 위해서는 로그를 더 자세히 여러 가지 방식으로 살펴봄으로써 funnel의 단계별 행동 이외에도 이용자가 어떤 방식으로 서비스를 이용하는지 알아내는 작업이 필요하다.
그리고 로그인하지 않은 이용자의 행동과 가입 후 한 행동을 연결해야 한다. 로그인 후의 행동을 분석해서 이용자 경험을 개선하는 것도 중요하지만 가입 이전에 무슨 행동을 하다 가입에 이르게 되었는지를 제대로 수집할 수 있다면 신규 이용자들을 가입시키는 과정 또한 개선이 가능할 것이기 때문이다.
덧1) 로켓펀치의 데이터 분석, 성장 전략 노하우가 담긴 책 ‘그로스 해킹 – 성장의 시대를 위한 안내서’가 출간 되었습니다.
덧2) 로켓펀치의 다음 데이터 분석 프로젝트는 ‘스타트업 연봉 분석’입니다.