블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

파이어베이스를 이용한 유니티 게임 로그 분석


조대협 (http://bcho.tistory.com)

모바일 로그 분석

일반적으로 모바일 로그 분석은 클라우드 기반의 무료 솔루션을 이용하다가 자체 구축으로 가는 경우가 많다.

클라우드 기반의 무료 로그 분석 솔루션으로는 구글 애널러틱스, 야후의 플러리, 트위터의 패브릭 그리고 구글의 파이어베이스 등이 있다.

이런 무료 로그 분석 솔루션들을 사용이 매우 간편하고, 핵심 지표를 쉽게 뽑아 줄 수 있으며, 별도의 운영이 필요 없다는 장점을 가지고 있다.

그러나 이런 클라우드 기반의 무료 솔루션의 경우에는 요약된 정보들만 볼 수 있고 또한 내가 원하는 지표를 마음대로 지정을 할 수 없기 때문에, 어느정도 서비스가 성장하고 팀의 여력이 되면 별도의 로그 수집 및 분석 솔루션을 만드는 것이 일반적이다.

오픈 소스 기반의 분석 솔루션

오픈 소스를 조합해서 모바일 로그 수집 시스템을 만들면 대략 다음과 같은 모양이 된다.


API 서버에서 로그를 수집해서 카프카등의 큐를 통해서 로그를 모으고, 실시간은 스파크 스트리밍, 배치는 하둡이나 스파크 스트리밍 프레임웍을 이용합니다. 대쉬 보드는 만드는 곳도 있지만, 주피터 노트북이나 제플린 노트북과 같은 노트북을 이용한다.

요즘은 데이타 저장 및 분석에 ELK (Elastic Search + Logstash + Kibana)와 같은 솔루션도 많이 사용하고 있다.


그런데 이런 오픈 소스 솔루션 기반으로 로그 분석 시스템을 개발하면 몇가지 문제가 발생한다.

  • 개발에 드는 노력
    이런 오픈소스 스택으로 시스템을 개발하려면, 이 프레임웍에 대해서 잘 아는 전문가가 필요합다. 일반적인 스타트업에서는 구하기도 힘들고, 기업이 어느정도 규모가 되더라도 빅데이타 관련 기술을 다룰 줄 아는 엔지니어는 여전히 귀한 엔지니어이고, 이런 엔지니어들이 있다하더라도, 시스템 설계및 구현에는 수개월의 기간이 소요 되게 된다.

  • 시스템 구매와 운영
    다음 문제는 모바일 데이타는 양이 많기 때문에, 위에서 언급한 빅데이타 관련 오픈 소스를 사용하게 되는데, 이러한 시스템은 하드웨어 자원이 수십에서 수백대가 필요하거니와, 이를 설치하고 운영하는 것 역시 쉽지 않다.
    로그를 수집하고 분석하는 로직을 만들어야 하는 엔지니어들이 정작 데이타 분석 보다는 시스템 운영과 유지보수에 많은 시간을 낭비해야 한다는 문제가 발생한다.
    규모가 작은 스타트업이나 엔지니어링 능력이 되지 않는 기업들은 이런 빅데이타 분석은 엄두도 내지 못하는 상황이 되고, 디테일한 데이타 분석을 하지 못하게 되니 자연히 경쟁력이 떨어지게 될 수 있다.

  • 연산 시간
    그리고 수집 수백대의 서버를 가지고 있다하더라도, 데이타 연산 시간은 수십분에서 수시간이 소요된다. 특히 데이타 분석 서버들이 분석을 하고 있을때는 다른 분석을 하고 싶은 사람들은 연산이 끝날때 까지 기다려야 하고, 수시간을 들여서 연산한 결과라도 연산이 잘못되었으면 다시 로직을 수정해서 수시간 동안 다시 연산을 해야 한다.
    비지니스 조직 입장에서는 지표 분석 결과를 얻는데, 수시간이 걸리니 의사 결정의 민첩성이 떨어지게 된다.

클라우드 기반의 분석 솔루션

근래에 이런 빅데이타 분석이 클라우드 컴퓨팅 기술과 만나면서 한번의 큰 변화를 겪게 되는데, 흔히들 빅데이타의 민주화라고 이야기 한다.  빅데이타 분석이 클라우드 컴퓨팅과 만나면서 겪은 큰 변화는 다음과 같다 .

클라우드 스케일의 연산

먼저 스케일이 달라집니다. 클라우드의 대용량 자원을 이용하여, 연산을 하기 때문에, 훨씬 더 빠른 연산을 저 비용에 할 수 있다.

예를 들어 구글의 빅쿼리의 경우에는 1000억개의 문자열(ROW)를  Regular expression을 이용하여 스트링 Like 검색을 하고 이를 group by 로 그룹핑하여 연산 하는 쿼리를 수행할때


“8600개의 CPU, 3600개의 디스크, 350GB의 네트워크 대역폭"


이 사용이 되고, 쿼리 수행 시간은 약 20~30초, 클라우드 사용 비용은 20$ (2만원) 정도가 소요 된다.

오픈 소스 기반으로 왠만한 규모로는 동시에 단일 연산으로 이렇게 수천개의 CPU를 같이 돌릴 수 있는 인프라를 사내에 가지고 있기도 힘들뿐 더러, 이만한 리소스를 20$라는 저렴한 비용에 사용하기란 거의 불가능에 가깝다.

이런 빠른 연산으로 인해서, 현업에서는 연산 결과를 기다리지 않고 바로바로 볼 수 있고, 비용 역시 저렴하기 때문에, 어느정도 자금력과 개발력이 있는 기업이 아니더라도 고성능의 빅데이타 분석 시스템 구현이 가능하게 된다.

NoOPS

다음 장점으로는 운영이 필요 없다는 것인데, 앞에서도 설명했듯이, 오픈 소스를 이용해서 빅데이타 분석 시스템을 직접 구축한 경우에는 시스템 인스톨과, 구성, 그리고 운영에 많은 시간이 소요 되는데, 클라우드 기반의 빅데이타 솔루션은 설정과 운영을 클라우드 서비스 제공자가 대행을 하기 때문에, 엔지니어링 팀은 별도의 설정과 유지보수 없이 본연의 역할인 데이타 분석에만 집중할 수 있게 된다. (아마 직접 하둡이나 스파크 클러스터를 운영해본 사람이라면 이 의미를 잘 이해하리라 본다.)


이렇게 클라우드가 빅데이타 영역에 도입되면서 이제는 빅데이타 분석이 뛰어난 엔지니어링 지식과 자금력이 없더라도 단시간내에 저비용으로 효율적인 데이타 분석이 가능하게 되었기 때문에, 이를 빅데이타의 민주화라고 부른다.

파이어베이스 애널러틱스

파이어베이스는 얼마전에 구글이 인수해서 클라우드 서비스 형태로 제공하고 있는 통합 모바일 개발 프레임웍이다. 웹은 지원하지 않고 모바일만 지원하는 형태의 프레임웍이며, 리얼타임 데이타 베이스, 광고 네트워크 통합, 푸쉬 서비스, 사용자 개인 인증 서비스등 여러가지 기능을 가지고 있는데, 그 중에서, 파이어베이스 애널러틱스는 모바일 빅데이타 분석에 최적화된 시스템이다.

빅쿼리와 파이어베이스의 조합

게임 체인저

파이어베이스는 모바일 데이타 분석에서 거의 게임 체인저라고 할만한 기술인데, 기존의 클라우드 기반의 모바일 데이타 분석 솔루션은 가장 큰 문제점이, 개발자가 정의한 로그 이벤트 (커스텀 로그)를 수집할 수 없다는 문제와  그리고 수집한 원본 데이타를 볼 수 없기 때문에, 원하는 지표를 마음대로 수집하고 분석하는 것이 불가능했다.

그런데 파이어베이스 애널러틱스는 이 두가지 기능을 지원하기 시작하였다.

커스텀 이벤트 정의를 통해서 개발자가 원하는 로그를 손쉽게 정의해서 수집이 가능하고, 또한 수집한 로그는 모두 구글의 빅데이타 저장 및 분석 플랫폼인 빅쿼리에 저장되고 바로 분석이 가능하다.

빅쿼리

파이어베이스 애널러틱스의 데이타는 빅쿼리에 저장이 되는데, 앞에서 예를 든것과 같이, 빅쿼리는 한번 연산에 수천개의 CPU와 디스크를 사용하여, 하둡이나 스파크에서 수시간이 걸리는 연산을 불과 수십초만에 처리가 가능하다.

빅쿼리의 또 다른 장점중의 하나는 이런 연산 속도 뿐만 아니라 RDBMS와는 다르게 JSON과 같이 트리형 (계층 구조를 가지는) 데이타형을 그대로 저장하고 쿼리가 가능하다는 것이다.


빅쿼리에 대한 자세한 설명은

를 참고하기 바란다.

파이어베이스 기반의 로그 분석

파이어베이스 애널러틱스는 뒤로는 빅쿼리 연동을 통해서 모든 원본 데이타의 수집과 분석을 지원하고 앞으로는 파이어베이스 에이전트를 모바일 디바이스에 탑재 하는 방식으로 최소한의 코드 개발로 모바일 앱으로 부터 모든 데이타를 수집할 수 있다.  파이어베이스 애널러틱스는 안드로이드와 iOS 플랫폼을 지원한다.

게임 프레임웍 지원

반가운 소식중의 하나는 파이어베이스 애널러틱스가 이제 유니티3D나, 언리얼(C++) 과 같은 게임 엔진을 지원한다. 현재 두 플랫폼에 대한 지원은 베타로 공개되어 있다.

코드 예제

그러면 파이어베이스 애널러틱스를 이용해서 로그를 수집하는 코드는 어떻게 삽입을 할까? 안드로이드와 유니티 3D의 예를 들어서 보자.

안드로이드 예제 코드

상세한 코드는 http://bcho.tistory.com/1131 를 참고하기 바란다.

코드 부분을 발췌해서 보면 다음과 같다.


//생략

:


import com.google.firebase.analytics.FirebaseAnalytics;


public class MainActivity extends AppCompatActivity {


 // add firebase analytics object

 private FirebaseAnalytics mFirebaseAnalytics;


   public void onSendEvent(View view){

     // 중간 생략

     Bundle bundle = new Bundle();

     bundle.putString(FirebaseAnalytics.Param.ITEM_ID, contentsId);

     bundle.putString(FirebaseAnalytics.Param.ITEM_NAME, contentsName);

     bundle.putString(FirebaseAnalytics.Param.CONTENT_TYPE, contentsCategory);

     mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_CONTENT, bundle);


 }

}



기본적으로 gradle 빌드 스크립트에 파이어베이스 애널러틱스 모듈을 import 하고, FirebaseAnalytics 객체만 선언해주면 기본적인 사용자 로그 (앱 실행, 종료등), 일일 방문자, 동시 접속자, 접속 디바이스 종류, 사용자 연령과 성별들을 모두 수집해준다.

빌드 스크립트 수정 및 소스코드에 한줄의 코드만 추가해주면 된다.

다음으로, 각각의 이벤트를 추가하고자 한다면, 위와 같이 Bundle 객체를 정의해서, 넘기고자 하는 인자를 정의해주고 logEvent라는 메서드를 호출해주면 파이어베이스로 로그가 전달된다.

유니티 3D 예제 코드

유니티 3D에서 파이어베이스에 로그를 남기는 것도 다르지 않다.

다음 코드를 보자


       Firebase.Analytics.Parameter[] param = {

           new Firebase.Analytics.Parameter("sessionid", sessionid),

           new Firebase.Analytics.Parameter("score", (string)ApplicationModel.score.ToString())

       };

       Firebase.Analytics.FirebaseAnalytics.LogEvent(ApplicationModel.EVENT.END_SESSION, param);


Parameter라는 배열로, 파이어베이스에 남길 로그의 인자들을 정의한후에, LogEvent 메서드를 이용하여 이벤트 명과, 앞에서 정의된 인자들 (Parameter)를 남겨주면 로그는 자동으로 파이어베이스로 전달된다.


파이어베이스 애널러틱스를 이용한 모바일 데이타 분석

그러면 파이어베이스를 이용하여 모바일 로그 분석을 어떻게 할 수 있는지 알아보자. 마침 유니티 3D가 얼마전 부터 베타로 지원이 되기 때문에, 간단한 게임을 이용한 로그 수집을 설명한다.

샘플 게임 설명

샘플에 사용한 게임은 간단한 RPG 형태의 게임으로 다음과 같이 구성된다.



시작 화면

시작화면에서는 로그 분석을 위해서, 사용자의 나이와 성별을 입력 받는다.


게임 화면

다음 게임이 시작되면, 화면을 터치하여 토끼 캐릭터를 이동 시키고, 돼지를 클릭하면 돼지를 공격한다.

돼지를 공격할때 마다 데미지는 돼지의 종류에 따라 일정 값 범위내에서 랜덤으로 판정되고, 생명 값이 남아있지 않으면 돼지가 죽게 된다.

맵내에 돼지는 7개가 유지되도록 되어 있으며, 돼지가 줄면, 돼지는 하늘에서 부터 떨어지게 되어 있다.

게임은 120초 동안 진행되며, 120초가 지나면 자동으로 종료된다.

종료 화면

게임이 종료되면 점수를 표시한다.

데이타  분석 지표 디자인

그러면 이 게임으로 어떻게 데이타를 분석할것인지에 대해서 고민해보자.

일일 접속 사용자나 사용자에 대한 사용 시간,횟수등은 파이어베이스 애널러틱스에서 기본적으로 수집이 되기 때문에, 조금 더 의미 있는 데이타를 수집해보도록 한다.

캐릭터 이동 히트맵

이 예제에서 다소 중점을 둔 부분중의 하나는 캐릭터 이동 히트맵이다.

게임에서 난이도 조정등에 사용할 수 있는 정보중의 하나가 NPC 캐릭터의 이동 동선과, 플레이어 캐릭터의 이동 동선이다. 주로 플레이어가 죽는 위치를 데드존 (Dead zone)이라고 하면, 이 데드존 위치를 찾아낼 수 있고, 이 데드존에서 플레이어와 NPC의 타입,레벨 등을 조사하여 난이도를 조정한다거나, 또는 AI(인공지능) 플레이어 캐릭터의 경우에는 이동 동선을 추적함으로써 맵 내에서 AI가 원하는 데로 잘 움직이는지를 추적해볼 수 있다.

아래는 데드존을 기반으로 캐릭터와 NPC의 레벨을 분석해놓은 예제이다.


<그림. 게임맵상에서 데드존의 플레이어와 NPC 캐릭터간의 레벨 분석 >


아래는 흥미로운 분석중의 한예인데, 게임맵에서, 각 위치별로 자주 발생하는 채팅 메세지를 표시한 내용이다.




<그림. 게임맵상에서 자주 사용되는 채팅 메세지 분석>


그림 출처 : http://www.cs.cornell.edu/courses/cs4152/2013sp/sessions/15-GameAnalytics.pdf


이런 시스템 역시 쉽게 개발이 가능한데, 파이어베이스 애널러틱스를 이용하여 채팅 로그를 수집한 후, 자연어 분석 API를 이용하면, 명사와 형용사등을 추출하여 자주 오가는 말들을 통계를 낼 수 있다.

http://bcho.tistory.com/1136 는 구글의 자연어 분석 API를 이용하여 트위터의 내용을 실시간으로 분석한 내용이다.

나이별  점수 분포

다음으로 일반적인 분석 시스템에서 수집되지 않는 커스텀 로그 분석 시나리오중 사용자 나이별 점수대를 분석해본다.

게임실행에서 종료까지 실행한 사용자

마지막으로 유용하게 사용되는 퍼널 분석의 예로 게임을 시작해서 종료할때까지의 도달율을 측정해봤다.

게임을 인스톨하고 시작한다음, 캐릭터를 움직이고, 캐릭터를 이용하여 공격을하고, 2분동안 플레이해서 게임을 종료한 사용자의 비율을 분석해본다.

로그 메세지 디자인

그러면 이러한 게임 로그를 분석하기 위해서 수집할 로그 메세지는 어떤 형태가 될지 디자인을 해보자.

로그 이벤트는 아래와 같이 7가지로 정의한다.

  • START_SESSION,END_SESSION 은 게임을 시작과 끝날때 발생하는 이벤트이다.

  • NPC_CREATE,NPC_MOVE,NPC_DIE 는 NPC(돼지)를 생성하고 이동하고, 그리고 죽었을때 각각 발생하는 이벤트이다. 이동은 이벤트의 수가 많기 때문에, 10초 단위로 수집하였다.

  • PLAYER_MOVE,PLAYER_ATTACK 은 플레이어 캐릭터의 이동과 NPC를 공격하는 이벤트를 수집한다.


각 이벤트를 플레이하는 판과 연결하기 위해서 각 플레이는 고유의 sessionid가 생성되서 게임이 시작될때부터 끝날때 까지 모든 이벤트에 저장된다.



Event name

Param

Key

Value

Type

Note


START_SESSION

This event is triggered when player press “START” button after submitting player’s age & gender

sessionid

Unique session Id for this play

String


age

Player’s age

String


sex

Player’s gender

String

true : man

false : woman

PLAYER_MOVE

It record location of player in game map periodically (every 2sec)

sessionid




Pos_X




Pox_Z




PLAYER_ATTACK

This event is occurred when player attack NPC.

sessionid

Unique session Id for this play



npc_id

Attacked NPC ID



type

Type of NPC



pos_X

NPC location X



pos_Z

NPC location Y



damage

Damage that NPC get in this attack



life

Left life for this NPC



NPC_CREATE

When new NPC is created, this event is logged.

sessionid

Unique session Id for this play



npc_id

Attacked NPC ID



type

Type of NPC



pos_X

NPC location X



pos_Y

NPC location Y



NPC_MOVE

Every 2sec for each NPC, it records the location of NPC.

sessionid

Unique session Id for this play



npc_id

Attacked NPC ID



type

Type of NPC



pos_X

NPC location X



pos_Y

NPC location Y



NPC_DIE

It is triggered when NPC is dead by attack

sessionid

Unique session Id for this play



npc_id

Attacked NPC ID



type

Type of NPC



pos_X

NPC location X



pos_Y

NPC location Y



END_SCENE

It is triggered when game stage(session) is over

sessionid

Unique session Id for this play



score

Score for this play




이렇게 정의된 로그는 파이어베이스 애널러틱스에 의해서 빅쿼리로 자동으로 저장되게 된다.

실시간 디버깅

이런 로깅을 삽입하면, 로그가 제대로 저장이 되는지 확인이 필요한데, 파이어베이스 애널러틱스는 특성상 로그 이벤트가 1000개가 쌓이거나 또는 컨버전 이벤트가 발생하거나 또는 1시간 주기로 로그를 서버에 전송하기 때문에 바로 올라오는 로그 메세지를 확인할 수 없다.

그래서 이번에 새로 소개되니 기능이 “DEBUG VIEW”라는 기능인데, 이 특정 디바이스에 디버깅 옵션을 지정하면, 실시간으로 올라오는 로그를 확인할 수 있다.

로그는 모바일앱에서 업로드한 후 약 10~20초 후에, 화면에 반영된다.



대쉬 보드를 이용한 지표 분석

대쉬 보드는 파이어 베이스 애널러틱스에서 기본으로 제공되는 지표로 모바일 서비스에 공통적으로 필요한 지표들을 분석하여 웹으로 출력해준다.

DAU/WAU/MAU 분석

가장 기본적인 지표로는 월간,주간,일간 방문자 수로를 그래프로 출력해준다.

평균 플레이 시간 분석

다음은 평균 플레이 시간으로, 사용자가 하루에 평균 얼마나 앱을 사용하였는지, 동시 접속자수 (Session)과,  한번 접속했을때 얼마나 오래 앱을 사용 하였는지 (Session duration)등을 분석하여 그래프로 출력해준다.


국가별 접속 내역 분석

다음은 국가별 접속 내용으로, 글로벌 서비스에는 필수로 필요한 분석 내용이다.


사용자 데모그래픽 정보 분석

사용자에 대한 데모 그래픽 정보 즉 성별과, 나이를 분석해주는데, 앱에 별도로 사용자 로그인 기능이 없거나, 사용자 정보를 추적하는 기능이 없더라도, 파이어베이스 애널러틱스는 여러군데에서 수집한 로그를 기반으로 사용자의 성별과 나이를 분석해 준다.



특정 이벤트에 대한 분석

다음은 특정 이벤트에 대한 분석이 가능하다. 게임에서 사용자가 스테이지를 넘어가는 이벤트등 파이어베이스에 정의된 이벤트 이외에도 사용자가 정의한 이벤트에 대한 분석이 가능하다.

또한 이벤트가 발생한 사용자에 대한 데모 그래픽 정보 (연령,성별,국가)를 같이 분석해서 해당 이벤트가 어떤 사용자 층에서 발생하였는지를 분석해 준다.


예를 들어 게임의 보너스 스테이지를 많이 클리어한 사용자의 통계만을 볼 수 있고, 그 보너스 스테이지를 클리어한 사용자의 나이,성별, 국가 정보등을 볼 수 있다.



게임 플레이 완료율에 대한 퍼널 분석

다음은 앞에서 데이타 분석 모델을 정의할때 정의한 문제로 사용자가 게임을 시작해서 플레이를 끝낸 사용자 까지를 퍼널(깔때기) 분석을 적용한 예이다.

해당 시간에 총 93번의 게임이 플레이 되었으며, 캐릭터까지는 이동하였으나, 공격을 하지 않은 플레이는 3번, 그리고 끝까지 게임 플레이를 끝낸 사용자는 총 62번으로 측정되었다.



이외에도 상품 구매에 대한(인앱)에 대한 분석이나, 디바이스 종류, 앱 버전, 그리고 어느 광고 네트워크에서 사용자가 인입되었는지 등의 분석등 다양한 분석이 가능한데, 대쉬보드의 자세한 지표에 대해서는 http://bcho.tistory.com/1132 를 참고하기 바란다.

노트북을 이용한 커스텀 로그 분석

앞에서는 파이어베이스에서 제공되는 로그와 분석 방법에 대해서만 분석을 진행하였다. 이번에는 커스텀 로그와 원본(raw)데이타를 이용한 데이타 분석에 대해서 알아보자.


모든 원본 데이타는 앞에서도 언급했듯이 구글의 빅쿼리에 저장되기 때문에, SQL 쿼리를 이용하여 자유롭게 데이타 분석이 가능하고 그래프로도 표현이 가능하다.

별도의 개발이 없이 자유롭게 쿼리를 실행하고 그래프로 표현할 수 있는 도구로는 노트북이 있는데, 빅쿼리는 주피터 노트북과 제플린이 지원된다. 주피처 노트북 오픈소스를 구글 클라우드에 맞춘 버전은 Google Cloud Datalab이라는 것이 있는데, 여기서는 데이타랩을 이용하여 분석하였다.

캐릭터 이동 히트맵 분석

앞에서 NPC_MOVE와 PLAYER_ATTACK을 이용하여, NPC의 이동 동선과, PLAYER가 공격을 한 위치를 수집하였다.

이를 히트맵으로 그려보면 다음과 같다.


좌측은 NPC가 주로 이동하는 경로이고 우측은 플레이어가 NPC를 주로 공격한 위치로, 많이 간곳일 수록 진하게 칠해진다.

NPC 캐릭터는 전체 맵에 걸쳐서 이동을 하는 것을 볼 수 있고, 주로 우측 나무 근처를 많이 움직이는 것을 볼 수 있다. 오른쪽 사용자가 공격한 위치를 보면 주로 중앙에 모여 있기 때문에 우측 나무 근처로 움직인 NPC는 생존 확률이 높았을 것으로 생각해볼 수 있다.

그리고 NPC 이동 맵에서 중간중간에 진하게 보이는 점은 NPC 가 생성되는 위치이기 때문에, 이동이 많이 관측되었다.

연령별 플레이 점수 분석

다음으로 플레이어 연령별 점수대를 보면, 최고 점수는 30대가 기록하였고, 대략 4900점대인데 반해서, 전체적인 평균 점수는 40대가 높은 것을 볼 수 있다. (이 데이타는 연령별로 수집된 데이타의 양이 그리 많지 않기 때문에 정확하지는 않다. 어디까지나 분석 예제용으로만 이해하기 바란다.)



분석에 사용된 코드는 아래에 있다. 이 코드는 데모용이고 최적화가 되어있지 않기 때문에, 운영 환경에서는 반드시 최적화를 해서 사용하기 바란다.


https://github.com/bwcho75/bigquery/blob/master/GameData/Game%20Data%20Demo.ipynb


참고로, 모든 데이타 분석은 주로 파이썬을 이용하였는데, 근래에 빅데이타 분석용 언어로 파이썬이 많이 사용되기 때문에, 파이썬을 공부해놓으면 좀 더 쉽게 데이타 분석이 가능하다. 또한 파이썬으로 데이타를 분석할때 많이 쓰이는 프레임웍으로는 팬다스 (pandas)와 넘파이 (numpy)가 있는데, 이 둘 역시 같이 익혀놓는것이 좋다.

파이어베이스 노티피케이션 서비스를 통한 이벤트 기반의 푸쉬 타게팅

파이어베이스 애널러틱스와 연계해서 유용하게 사용할 수 있는 기능은 파이어베이스 노티피케이션 이라는 서비스가 있다.


파이어 베이스 노티피케이션 서비스는 파이어베이스에서 제공되는 웹 콘솔을 이용하여 관리자가 모바일 서비스에 손쉽게 푸쉬 메세지를 보낼 수 있는 서비스이다.

푸쉬 타게팅을 위한 별도의 서버 시스템을 개발하지 않고도 마케팅이나 기획자등 비 개발인력이 타게팅된 푸쉬 메세지를 손쉽게 보낼 수 있게 디자인된 서비스인데, 특히 파이어 베이스 애널러틱스와 연계가 되면 세세한 타게팅이 가능하다.


이벤트 로그 기반의 타케팅

푸쉬 타겟을 정할때, 파이어베이스 애널러틱스에서 수집한 이벤트를 조건으로 해서 푸쉬를 타게팅할 수 있다.

예를 들어

  • 게임 스테이지 3 이상을 클리어한 플레이어한 푸쉬를 보낸다.

  • NPC를 10,000개 이상 죽인 플레이어에게 푸쉬를 보낸다.

  • 아이템을 100개이상 구매한 사용자에게 푸쉬를 보낸다.

와 같이 서비스에서 수집된 이벤트에 따라서 다양한 조건을 정의할 수 있다.



<그림. 파이어베이스 노티피케이션에서 특정 사용자 층을 타게팅 해서 보내는 화면 >


이런 타게팅은 파이어베이스 애널러틱스에서 Audience로 사용자 군을 정의한 후에, (로그 이벤트 조건이나 사용자 이벤트 조건 등), 이 조건에 타겟해서 푸쉬를 파이어베이스 노티피케이션 서비스에서 정의한다.

사용자 정보 기반의 타게팅

서비스의 로그 이벤트 정보뿐 아니라, 사용자에 대해서도 푸쉬 타게팅이 가능한데, 특정 성별이나 나이에 대해 푸쉬를 보내거나, 특정 단말을 사용하는 사용자, 특정 국가에 있는 사용자등 다양한 사용자 관련 정보로 푸쉬를 보낼 수 있다.

사용자 정보 역시 앞의 이벤트 로그 정보처럼 개발자가 커스텀 필드를 추가하여 사용자 정보를 로그에 수집할 수 있다.


스케쥴링

이런 타게팅 푸쉬는 바로 웹에서 보낼 수 도 있지만, 특정 시간에 맞춰서 미리 예약을 해놓는 것도 가능하다.  




비용 정책 분석

파이어베이스 애널러틱스에서 원본 데이타를 수집 및 분석 하려면 빅쿼리를 연동해야 하는데, 빅쿼리 연동은 파이어베이스의 무료 플랜으로는 사용이 불가능하다. Blaze 플랜으로 업그레이드 해야 하는데, Blaze 플랜은 사용한 만큼 비용을 내는 정책으로 다른 서비스를 사용하지 않고, 파이어베이스 애널러틱스와 빅쿼리 연동만을 사용할 경우에는 파이어베이스에 추가로 과금되는 금액은 없다. (0원이다.)

단 빅쿼리에 대한 저장 가격과 쿼리 비용은 과금이 되는데,  빅쿼리 저장 가격은 GB당 월 0.02$ 이고, 90일동안 테이블의 데이타가 변하지 않으면 자동으로 0.01$로 50%가 할인된다.

그리고 쿼리당 비용을 받는데, 쿼리는 GB 스캔당 0.005$가 과금된다.


자세한 가격 정책 및, 파이어베이스 애널러틱스에 대한 데이타 구조는 http://bcho.tistory.com/1133 를 참고하기 바란다.

파이어베이스 애널러틱스를 이용한 모바일 데이타 분석

#2-분석 지표와 대쉬 보드 이해하기


조대협 (http://bcho.tistory.com)


파이어베이스 애널러틱스로 지표를 수집하게 되면, 몬가 아름다워(?) 보이는 대쉬 보드와 그래프들을 볼 수 있다. 그러나 정작 각 그래프의 항목과 수치가 무엇을 의미하는지를 이해하지 못한다면 무용 지물이나 다름없다.


비단 파이어베이스 애널러틱스 뿐 아니라, 일반적인 데이타 분석에서도 많이 겪는 실수중에 하나인데, 이번에는 파이어베이스 애널러틱스에 의해서 분석되어 리포트로 제공되는 각종 지표와 이와 연관된 이벤트들에 대해서 알아보도록 한다.

대쉬 보드

파이어베이스 애널러틱스를 사용하게 되면 리포트는 대쉬보드를 통하여 출력되게 된다. 대쉬 보드는 대략 아래와 같이 생겼는데, 각 항목을 살펴보도록 하자



출처 https://support.google.com/firebase/answer/6317517?hl=en&ref_topic=6317489

기준 시간

분석 지표에 대한 이해를 하기 위해서는 먼저 기준 시간에 대한 이해를 할 필요가 있다. 파이어베이스 애널러틱스 콘솔의 우측 상단의 보면 분석 기간을 선택할 수 있다. 분석 기간은 오늘, 어제, 이번주, 지난 7일, 지난 30일 등 미리 정해진 기간이나 Custom을 이용하여, 기간을 정의할 수 있다.


1. Active User (활성 사용자수)

가장 처음에 나오는 지표는 활성 사용자 수 이다. 가장 많이 보는 지표중의 하나인데, 일,월,주별 방문자 수 이다.


  • Monthly Active User (MAU:월별 활성 사용자 수)
    그래프의 X축의 날짜에서 부터 부터 전 30일까지의 앱을 사용한 총 일일 사용자 수.

  • Weekly Active User (WAU:주별 활성 사용자 수)
    그래프의 X축의 날짜에서 부터 전 7일 까지 앱을 사용한 총 일일 사용자의 수

  • Daily Active User (DAU : 주별 활성 사용자 수)
    그래프의 X축 날짜의 앱을 사용한 일일 사용자의 수


위의 그래프를 보면 WAU와 DAU는 수평을 그리고 있는데, 반하여 MAU가 올라가고 있음을 볼 수 있다. 이 그래프는 파이어베이스 애널러틱스를 설치한지 얼마 되지 않는 기간에 뽑은 리포트인데, DAU는 일정하기 때문에, MAU는 누적되서 그래프가 상승 곡선을 띄게 되는 것이다.

예를 들어 8월1일에 설치했다고 했을때, 8월2일의 MAU는 7월3일~8월2일 DAU의 합이 되는데, 8월 1일에 설치를 했기 때문에 7월3일~7월30일까지의 데이타는 없다. 8월 30일의 MAU는 8월1일~8월30일까지 합이고, 8월1~30일까지는 데이타가 있기 때문에 누적되서 상승 곡선을 그리게 된다.

2. Average Revenue (평균 수익)

다음 지표는 수익 지표이다. 크게 ARPU와 ARPPU로 표현되는데 그 내용은 다음과 같다.

  • ARPU (Average revenue per User)
    사용자별 수익률로, 전체 수익을 전체 사용자 수로 나눠서 계산한다.

  • ARPPU (Average revenue per purchased user)
    유료 사용자별 수익률로, 전체수익을 비용을 지불한 사용자로 나눠서 계산한다.

전체 서비스가 유료가 아닌 이상, 커머스의 경우 일부 사용자만 물건을 구매하거나, 게임이나 서비스 앱인 경우에는 일부 사용자만 인앱구매등을 통해서 비용을 지불하기 때문에 다른 두개의 지표가 나온다.

ARPU는 서비스에서 사용자가 증가하는 당 수익률이 어떻게 올라가는지를 알 수 있고, ARPPU는 유료 사용자당 얼마의 금액을 사용하는지를 이해할 수 있다.


이 지표는 파이어베이스 애널러틱스에서  ecommerce_purchase (쇼핑몰 이벤트 중, 구매 이벤트)와 in_app_purchase (일반 이벤트중 인앱 구매) 이벤트에 의해서 추적되기 때문에, ARPU와 ARPPU를 구하고 싶으면, 상품구매나 인앱 구매가 발생하였을때, 위의 이벤트를 통해서 파이어베이스 애널러틱스에 이벤트를 로깅해줘야 한다.  


3. first_open attribution (앱실행 빈도)

다음 지표는 첫 앱 실행을 추적하는 지표이다.

기준 시간 기간 동안 인스톨 또는 재 인스톨이 된후, 처음으로 앱이 실행된 횟수를 추적하는 지표이다.

이 지표는 다양한 의미를 가지고 있는데, 앱 다운로드가 캠페인등을 통해서 많이 일어났다고 하더라도, 앱을 한번도 실행을 해보지 않고 삭제하는 경우도 많기 때문에, 앱 다운로드 대비, 얼마나 많은 사용자가 실제로 앱을 실행했는 가를 추적할 수 있다.

앱 다운로드 횟수는 구글 플레이 스토어나 애플 앱스토어의 사용자 콘솔에서 그 값을 추적할 수 있다.


또한 “NETWORK SETTING”에서 광고 서비스 네트워크를 연동할 수 있는데, 광고 네트워크를 연동하게 되면 앱의 설치가 사용자가 앱스토어에서 그냥 자발적으로 설치를 한것인지 아니면 광고 네트워크의 특정 광고 캠페인을 통해서 인입된 사용자인지를 판단할 수 있다.



<그림 광고 네트워크를 연동하는 화면 >


이를 통해서, 광고 마케팅의 효율과, 성과를 측정하여 효율적인 광고 집행이 가능하다.

앱 첫실행을 기록하는 first_open 이벤트는 개발자가 별도로 코드 상에 정의하지 않더라도 자동으로 로깅 된다.

아래 예제를 보자, 광고 네트워크를 통하지 않고, 앱을 처음 사용한 것이 150K 정도 되고, 다음은 구글을 통해서 들어온 비중이 38K  정도가 된다.



맨뒤에, LTV 라는 수치가 있는데, LTV는 Life Time Value의 약자로 사용자가 앱을 설치 한 후, 초기 120일 동안에 일으킨 매출의 수의 총합이다. 매출은 ARPU와 같이   ecommerce_purchase (쇼핑몰 이벤트 중, 구매 이벤트)와 in_app_purchase (일반 이벤트중 인앱 구매) 이벤트에 의해서 추적된다.

이를 통해서 광고 네트워크별로 얼마만큼의 사용자가 들어오고, 유입된 사용자가 발생 시킨 매출을 추적하여 광고의 효율을 측정할 수 있다.


여기서 포스트백 (PostBack)이라는 기능을 잠깐 짚고 넘어갈 필요가 있는데, 쇼핑몰에서 광고 네트워크를 통해서 광고를 집행하고 있다고 하자, 사용자가 호텔 예약을 하고 싶어하는 니즈를 파악하고 사용자에게 호텔 예약 광고를 계속 내보냈다. 광고를 통해서 사용자는 호텔을 예약했다고 하자. 그렇다면 이제 더이상 해당 사용자에게 호텔 광고가 계속 나가면 안된다. (이미 팔았기 때문에) 이를 막기 위해서 광고 네트워크에 해당 물건을 사용자가 구매했으니, 더 이상 같은 광고를 내보내지 말라고 알려줘야 한다. 이를 포스트 백(Postback)이라고 한다. 파이어베이스 애널러틱스에서 포스트백을 설정하는 방법은 https://support.google.com/firebase/answer/6317518?hl=en&utm_id=ad#postbacks 를 참고하기 바란다.

4. Retention cohort (사용자 잔존율 코호트 분석)

다음 지표는 사용자 잔존율을 코호트 분석을 통해서 분석해낸 결과로, 사용자가 처음 앱을 사용한 후 얼마나 많은 사용자가 지속적으로 남아 있느냐를 나타내는 중요한 지표이다. 주 단위 잔존율을 기준으로 통계를 잡아주는데, 잔존 사용자가 많을 수록, 그래프가 더 진하게 표시 되는데, 다음 예제를 보면, 7월17일~7월23일에 가입한 사용자는 총 19481명으로 첫주에는 100% 사용자가 잔존하였으나, 1주 후에는 23.5%만 남았고, 2 주후에는 12.2%만 남았다가 5주후에는 6.4%만 남았다.

7월31~8월6일에 가입한 사용자의 경우 1주차에 23.7%가 남아 있어서 다른 주 대비 잔존율이 높아서 조금 더 진한 색깔이 그래프로 표현되었다.



5. User engagement (사용자 활동 지표)

사용자 활동 지표란, 사용자들이 기간동안 얼마나 앱을 사용했느냐에 대한 기간과 횟수등을 표현하는 지표들이다. 아래 그래프 예제로 설명하면




  • Daily engagement (총 사용시간)
    통계 기간 (기준 시간 기간) 동안 모든 사용자들이 앱을 사용한 총 시간의 합이다. 위의 예에서는 1년 34일 14시간을 사용한것으로 집게 되었다.

  • Daily engagement per user (사용자당 평균 사용 시간)
    통계 기간중, 사용자 1인당 평균 사용시간이다. Daily engagement를 그 기간 동안 총 활성 사용자 수로 나눈 값이다.

  • Session per user (사용자당 평균 세션 수 )
    사용자당 평균 세션 수 인데, 세션은 사용자가 기간동안 앱을 사용한 횟수로 보면 되다. 위의 예제에서는 사용자당 평균 3.7 회 정도 사용하였다.

  • Avg. session duration (사용자당 평균 세션 길이)
    사용자당 세션의 길이로, 한번 사용할때 평균 얼마 정도의 시간을 사용하느냐인데, 여기서는 사용자당 한번 사용에 7분 8초 정도를 사용한것으로 집게 되었다.


이런 통계 분석에서 주의할점은 이는 어디까지나 평균 값일 뿐이다. 특정 사용자는 기간동안 평균값이 3.7회가 넘는 10회 20회를 사용할 수 도 있고, 어떤 사용자 층은 한번 밖에 사용하지 않을 수 도 있다. 일반적으로 모바일 서비스 앱은 그 사용횟수나 사용 시간에 대한 분포가 특정 사용자군 (헤비유저)에게 몰리는 경향이 있기 때문에, 이러한 평균 지표보다는 정규 분포형의 지표를 따라서 분석하는 것이 조금 더 정확한데, 이를 위해서는 파이어베이스 애널러틱스의 지표만으로는 불가능하고, 원본 데이타를 기반으로 분석을 할 필요가 있다. 이를 위해서 원본 데이타를 빅쿼리에 저장한 후 분석하는 것이 좋은데, 이 방법은 나중에 다시 설명하도록 하겠다.

6. In-App purchase (인앱 구매)

이 지표는 인앱 구매에 대한 지표로, in_app_purchase 이벤트에 의해서 수집된 정보를 기반으로 통계를 계산한다. 총 얼마 만큼의 사용자가, 인앱 구매를 했는지를 출력하고, 이를 통해서 발생된 매출을 출력한다.

아울러 아래 그림과 같이 최고 매출을 일으킨 인앱 구매 상품들을 구매 횟수와 총 매출액을 통계로 표시해준다.



아래의 “VIEW IN-APP PURCHASE DETAILS” 탭을 클릭하면, 모든 인앱 상품의 매출 정보와 판매 추이,  사용자 연령대별 매출 발생 비중등 자세한 정보를 볼 수 있다.


<그림. 인앱 구매 이벤트 집게 화면에서 상세 화면중 성별 및 연령 별 구매 비율 >


7. App version (앱 버전)

통계 기간 동안 모든 사용자가 사용한 앱 버전에 대한 통계를 보여준다. 상위 3개의 버전을 보여주고, 나머지는 Others로 묶어서 통계로 보여준다.


앱 버전 역시 모바일 서비스에서 매우 중요한 지표중의 하나인데, 신기능이나 신규 컨텐츠가 올라가더라도 버전이 옛날 버전이 많이 깔려 있을 경우 신규 기능이나 컨텐츠가 동작하지 않을 수 도 있기 때문에, 얼마나 사용자들이 새 버전으로 업데이트했는지 추적하는 것이 중요한 지표가 되며, 아울러 경우에 따라서 예전 버전이 많을 경우에는 강제 업데이트를 해야 하는 경우도 있기 때문에, 앱 버전에 대한 추적 역시 매우 중요한 지표로 작용하낟.

8. Devices (디바이스)

통계 기간동안에 사용자가 앱을 사용하는데 사용한 주요 디바이스명과, OS 버전에 대한 통계이다.

디바이스명은 테스트 환경을 만들때 사용자들이 주로 어떤 디바이스를 사용하는지를 알면 테스트 디바이스를 준비하기가 편리하기 때문이고, OS version의 경우, 낮은 버전의 OS에서는 특정 SDK나 기능이 작동하지 않을 수 있기 때문에 앱 개발시 어느 OS 버전 부터 지원을 해야 할지, 그리고 사용 빈도가 낮은 OS는 언제 지원을 중단할 수 있을지등을 결정할 수 있는 지표로 활용이 가능하다.


9. Location(위치)

이해는 쉽지만 가장 중요한 지표중의 하나이다. 해당 기간동안 주로 어느 국가에서 앱이 많이 사용되었는 가를 리포팅 해주는 지표이다.


국내나 특정 국가 한정 서비스인 경우가 아닌 글로벌 서비스인 경우 서비스가 어느 나라에서 인기가 있는 가에 따라서, 그 나라에 맞도록 앱을 현지화 하거나, 앱에 대한 마케팅 자원등을 선택과 집중할 수 있다.

10. Demographics (데모그래픽 정보)

데모 그래픽 정보는 사용자의 연령과 성별등을 나타내는 정보이다.

이를 통하여 앱 사용자가 누구인지를 파악할 수 있고, 이를 기반으로 앱 서비스를 타케팅할 수 있는 대상을 식별하여, 제공할 컨텐츠, 마케팅 캠페인 대상등을 정할 수 있다.  



11. Interest (사용자 흥미)

마지막으로 이 앱 서비스를 사용하는 사용자가 어떤 흥미를 가지고 있는지를 분석 해주는 기능인데,

이러한 모바일 분석 플랫폼을 무료로 제공하는 서비스 제공자는 구글뿐아니라 야후, 트위터와 같이 광고를 통해서 수익을 창출하는 경우가 많다. 이러한 사업자등은 자사의 서비스에서 사용자들이 어떤 서비스나 어떤 컨텐츠를 선호 하는지를 분석한 후에, 이를 기반으로 모바일 데이타 분석 플랫폼을 사용하는 앱 개발사들의 사용자들이 어떤 컨텐츠나 서비스를 선호하는지를 추적 분석해주는데, 이것이 Interest 분석이다.


위의 그림과 같이 이 앱을 사용하는 사용자들은 TV나 온라인 비디오에 관심이 많은 사용자들이 7.6%, 그리고 음악에 관심이 있는 사용자들이 6.7%, 카메라나 전자 제품에 관심 있는 사용자들이 3.6% 정도이다.

이를 통해서 앱 사용자들을 대상으로 한 타겟 광고나 서비스 개선등에 활용할 수 있다.


지금까지 간략하게나마 파이어베이스 애널러틱스 대쉬보드의 주요 지표에 대해서 설명하였다.

여기에 나오는 지표들은 파이어베이스뿐 아니라 일반적인 모바일 앱 서비스 분석 지표로도 사용되는 만큼, 잘 이해해놓으면 모바일 서비스 빅데이타 분석에 유용하게 활용할 수 있다.


다음 글에서는 파이어베이스 애널러틱스의 주요 이벤트들에 대해서 설명하도록 하겠다.


쉽게 이해하는 모바일 데이타 분석



조대협(http://bcho.tistory.com)


모바일 서비스 비지니스를 진행함에 있어서 가장 중요한 것중 하나는 지표에 따른 의사 결정과 서비스 개선이다. 이를 위해서, 어떤 지표들이 필요한지 정의하고 어떻게 측정할지에 대한 정확한 이해가 필요한데, 이 글에서는 모바일 서비스 리포팅에 대해 어떤 지표가 있고 어떻게 활용해야 하는지, 그리고 이런 지표를 수집 분석하기 위한 도구들에 대해서 설명하도록 한다.


모바일 서비스에서 단계별 사용자 흐름


먼저 지표를 이해하기 전에, 사용자가 모바일 서비스 가입부터 사용에서 부터 이익을 내줄때 까지 어떤 흐름을 거치는지에 대해서 살펴볼 필요가 있다. 여러 글들이나 서비스들에서 다소 용어 차이는 있지만 대부분 아래와 같이 단계를 정의한다. 





Acquisitions (사용자 획득 단계)


“사용자 획득 단계”는, 사용자가 앱을 설치 하는 단계로 광고/마케팅등을 통해서 사용자가 앱을 인지하고 설치하는 단계인데, 조금 더 세분화 하면, 설치 후 첫번째 실행을 한 단계로 정의하거나 또는 설치 후 회원 가입까지 한 단계를 “사용자가 획득 되었다” 라고 판단할 수 있다.


사용자의 유입은 검색엔지이나 앱스토어의 검색등을 통하거나, TV,온라인 캠페인(인터넷 광고), 오프라인 캠페인등을 통해서 이끌 수 있다. 유입 경로가 다양하기 때문에 모든 경로에 대한 추적은 불가능하지만, 특히 온라인 캠페인(인터넷 광고) (페이스북이나 카톡 등)는 손쉽게 추적이 가능하고 사용자 획득양에 따라서 광고 플랜을 조절할 수 있기 때문에, 이러한 온라인 캠페인은 시작하기 전에 사용자 유입이 비용대비 어떻게 효과가 있는지를 측정할 수 있는 준비 (분석툴등)를 해놓고 시작해야 한다.


Retention (사용자 유지 단계)


마케팅등을 통해서 사용자를 유입시켰으면 이 유입된 사용자를 서비스에 잡아놓아야 하는데, 이를 Retention, 즉 사용자 유지라고 한다. 이 사용자 유지율을 가입한 사용자가 가입한 이후, 얼마나 꾸준히 재 접속을 하는지를 통해서 측정하는 것이 일반적인데, 1일 후 재접속율, 2일..7일 재접속율을 체크하면 된다. 


이 단계에서 이탈을 방지하고 얼마나 사용자를 Lock in 하여 충성도가 높은 사용자층을 유지하는 것이 중요하다.


Engagement (사용자 활동 단계)


사용자가 서비스를 지속적으로 사용하기 시작하면, 서비스와 사용자간의 인터랙션 즉 활동이 시작되는 단계가 된다. 미디어 서비스일 경우 단방향으로 컨텐츠를 보기만 하는 단방향성의 활동보다는 댓글이나 좋아요 버튼등을 통한 양방향 활동등을 유도하여 서비스의 로열티를 높이고, 서비스에 체류하는 시간을 늘려서 장기적으로 수익화할 수 있는 원천으로 삼아야 한다.


Monetize (수익화 단계)


고정 사용자 층이 형성이 되었으면, 이 사용자 층을 이용하여 수익을 창출해야 하는 데, 광고나 게임의 경우 인앱 구매, 쇼핑의 경우 물품의 실제 구매 단계 까지 연결이 되서 최종적으로 수익을 창출하는 단계이다.


사용자의 인터랙션은 앞에서 설명한바와 같이 위의 그림 처럼 깔때기 형태로 이루어지며 최종 수익을 발생하는 사용자를 얼마나 많이 유도 하느냐가 비지니스의 성패가 된다. 


이러한 흐름을 설명하는 것은 보통 모바일 앱 데이타 분석에 있어서 상당히 많은 지표들이 있고, DAU,MAU,Session Time등 각각의 지표만을 모니터링 하고 분석할뿐 전체 지표가 어떻게 연결되는지 연관성에 대한 인사이트가 적은 것이 대부분의 문제라고 생각하기 때문에 사용자의 단계별 활동에 대한 흐름을 설명하였다.


단계별 지표 정의와 의미


이번에는 위에서 서술한 각 단계별로 모니터링 하는 주요 중요 지표에 대해서 알아보도록 하자



Acquisition 


Download

앱을 다운로드해서 설치한 횟수이다. 이때 중요한 것이 이 Download 수와 실제 사용자 수는 일치 하지 않는다는 것이다. 같은 사용자가 기기를 바꿔서 다시 다운로드할 수 도 있고, 여러기기에 다운로드를 할 수 도 있고 혹은 앱을 지웠다가 재 설치할 수 도 있기 때문에 , 다운로드 수와 사용자 수를 혼돈하지 않도록 한다. 이러한 다운로드 수는 별도의 솔루션을 사용하지 않더라도 구글 플레이 스토어나, 애플 앱스토어 등에서 쉽게 모니터링 할 수 있다.



New User

신규 사용자 수이다.  앱을 설치하고 첫번째로 사용하는 사용자의 수로, 실제로 프로모션등으로 인하여 앱을 설치는 하지만, 사용하지도 않고 삭제하는 경우의 수도 많기 때문에, 별도로 측정이 필요하다.


Demographic Info

그외, 사용자에 대한 기본적인 정보를 수집할 수 있는데, 나이, 성별,  지역적인 위치, 사용 단말의 종류, 통신사등 기본적인 인구 통계나 디바이스에 대한 정보를 수집을 통해서 주로 어떤 사용자 층이 서비스를 사용하는지 인지할 수 있다. 



Install tracking

사용자 획득 단계에서 중요한 지표중의 하나가, 이 사용자가 어디를 통해서 들어왔냐는 것이다. 온라인 마케팅을 통해서 들어온건지. 그렇다면 채널이 페이스북인지? 아니면 웹 사이트 광고인지, 어느 웹사이트 인지? 아니면 공유 기능등을 통한 추천으로 들어온것인지 이메일 마케팅을 통해서 앱 인스톨이 유도 된것인지등이 분석이 되어야 한다.

이러한 분석은 안드로이드 앱의 경우 캠페인 관리 기능을 통해서 UTM 정보라는 것을 획득하면, 어느 경로를 통해서 앱 인스톨이 유도 되었는지 추적이 가능하기 때문에, 결과적으로 어느 마케팅 채널을 통해서 사용자 유입이 활발하게 이루어지는지 판단이 가능하고 이를 통해서 효율적인 채널에 마케팅 리소스를 집중할 수 있도록 해준다.


Retension


Retension rate는 신규 사용자의 재 방문율 분석을 통해서 인지할 수 있다. 이런 수치는 Google Analytics나 Yahoo의 Flurry등읗 이용하여 분석이 가능한데, 아래 그림은 Flurry의 Retension 모니터링 화면이다. 


  


가입자가 가입을 한후에, 날짜가 지남에 따라 얼마나 많은 사람이 남아 있는 가를 볼 수 있다. 당연히 Day 0 에는 100% 일테고, 위의 그림을 보면, 1일 차에는 대략 60%의 사용자가 남게 되고, 그후에 40~50% 사용자가 유지되는 것을 볼 수 있다.


Engagement


Engagement 는 서비스에 대한 사용자의 활동량을 측정하는 수치로 서비스의 종류나 특성에 따라 측정해야 하는 수치가 다르다. 예를 들어 신문이나 방송같은 미디어 서비스의 경우 컨텐츠 뷰수가 중요할것이고, 게임같은 경우에는 플레이 시간이나, 레벨업 등이 중요할 것이고, 쇼핑의 경우에는 상품을 보는 수등이 중요할 수 있다.

이런 추가적인 지표는 각 서비스에 맞게 정의하는 것이 중요하지만, 공통적으로 사용할 수 있는 지표를 보면 다음과 같다


User Path

앱 상에서 사용자의 이동 경로로, 메인 화면으로 갔다가 각각의 메뉴로 사용자가 이동하고 각 메뉴별 체류 시간등을 분석해줌으로써 사용자가 주로 어떤 패턴으로 기능을 사용하는지 또한 어떤 기능이 많이 사용되고 안되는지 등에 대해서 분석이 가능하다.



 

Active User

Active User는 단위 시간동안 그 서비스를 사용한 사용자의 수를 뜻한다.

일반적으로 일단위나 주단위, 월단위를 많이 사용하는데 각각을  DAU(Daily Active User), WAU(Weekly Active User), MAU(Monthly Active User)라고 하고 앱의 서비스 규모를 측정하는 가장 일반적인 지표로 많이 사용된다. 


Session

다음으로 중요한 지표중 하나는 세션(Session)인데, 세션은 한명의 사용자가 한번 앱에 접속해서 사용하고 종료할때까지의 기간을 세션이라고 한다. 한명의 사용자가 하루에 여러번 앱을 사용하면 각각이 하나의 세션으로 취급되며, 일반적으로 안드로이드의 경우 하나의 세션을 사용자의 액션이 없을 경우 30분 후에 종료되는 형태로 정의된다. (cf. 웹에서 HTTP Session이 사용자 액션이 없으면 20분 후에 종료되는 것과 같은 종류로 보면 된다) 

이 세션의 수는 일반적으로 현재 앱을 사용하는 동시 접속자 수와 유사하다고 보면 된다. (사용자가 실제 사용을 종료하고도 30분 정도를 동시 사용자로 측정하기 때문에 다소 오차는 있지만, 전체적으로는 동접자 수와 유사하다고 판단한다.)

https://support.google.com/analytics/answer/2731565 는 Google Analytics에서 사용하는 세션의 개념이다.


Session Lenth

한번 접속했을때 사용자가 앱을 사용하는 시간을  Session Length라고 한다. 이 Session Length가 길다는 것은 그만큼 앱을 사용하는 시간이 길다는 의미로 사용자의 활동이 많다고 볼 수 있으나, 앱의 특성에 따라서 Session Length가 가지는 의미는 다르다. 알람 앱같은 경우에는 설정이나 알람이 울릴때만 앱이 사용되기 때문에, Session Length가 길 수 가 없고 짧다. 그래서 Session Length가 긴것 보다는 총  Session의 수가 얼마나 되느냐가 중요한 척도가 된다. 



Viral

근래에 모바일 서비스에서 중요한 지표중의 하나가 바이럴 지표인데, 페이스북과 같은 SNS 서비스를 통해서 공유가 되고, 이 공유를 통해서 들어오는 사용자 유입은 매우 중요하다. 그래서 추가적으로 SNS 매체별 공유 카운트 등을 별도로 추적할 필요가 있다.


Bounce rate

흔히들 놓치는 수치 중에 하나가 이탈율이다. 사용자 Install이 증가함에도 불구하고, 지속적으로 DAU가 늘어나지 않는 이유는 흔히 앱을 설치했다가 삭제하는 이탈 사용자 때문인데, 이러한 이탈율은 Google play store 등에서 쉽게 추적이 가능하다.


<그림. 구글 플레이스토어에서 일일 Uninstall 사용자 추적 예제> 


Loyalty (하루에 몇번 앱을 사용하는가?)

다음으로는 사용자의 충성도를 측정하는 지표인데, 주로 하루에 또는 일주일에 몇번 앱을 사용하는지를 측정한다. 



추가적으로 고민해야 하는 사항들


앞에서 모바일 앱 데이타 분석에서 일반적으로 살펴봐야 하는 지표들에 대해서 알아보았다. 이런 일반 지표 이외에 추가적으로 고려해야 하는 부분은 무엇이 있을까?


코호트  분석 (Cohort analysis)


코호트 분석이란, 분석 결과를 특정 사용자 그룹으로 (나이 또는 성별 등) 나눠서 더 깊게 분석하는 것으로, 집단의 특성에 따른 인사이트를 얻어서 서비스에 반영할 수 있다.

예를 들어서 DAU가 100만으로 꾸준히 유지 되는 서비스가 있다고 가정할때, 이를 연령 층으로 나누었을때 20대 사용자가 증가하고 30대가 감소한다면, DAU 향상을 위해서 30대를 위한 서비스 개선을 생각하거나 또는 서비스의 방향을 20대로 아예 바꿔 버릴 수 도 있다. 앞의 지표를 하나의 숫자로만 보고 분석하면 집단별 특성을 놓칠 수 있지만, 코호트 분석을 통하면 서비스를 사용하는 집단의 특성에 따라 다양한 해석이 가능하기 때문에 그에 따른 다양한 대응역시 가능하게 된다.


퓨넬 분석 (Funnel analysis)


Funnel / 깔때기 분석이라고 하는데, 특정 목표를 달성할때 까지 사용자의 잔존 비율을 단계별로 분석하는 분석 방법이다. 

앞에서 설명한 Acquisitions > Retain > Engagement > Monetization 의 단계도 뒤로 갈수록 사용자가 점점 낮아지는 깔때기 형태로 일종의 퓨넬 분석에 속한다.





위의 그림은 Flurry에서 제공하는 Funnel 분석 결과 화면으로, 자동차를 판매하는 사이트에서, 각 단계별로 넘어가는 사용자 통계로, Choose Car 단계에서 Check In 단계로 넘어갈때, 43.1 %의 사용자만 넘어간것을 볼 수 있다. 다음 단계는 각각 56.4%, 72.6%로 View State 목표를 달성하는 과정중에 사용자가 Check In 단계에서 가장 많이 이탈함을 알 수 있고 이 부분을 우선 개선해야 하는 것을 알 수 있다. 


이러한 퓨넬 분석을 이용하면, 사용자가 최종 목표에 다다르기 까지 어느단계에서 이탈을 하는지 쉽게 판단이 가능하고, 그 단계를 보강함으로써 최종단까지 사용자를 유도하도록 서비스를 개선할 수 있다.

 

지표의 단순화


지금까지 다양한 지표를 살펴봤는데, 비단 모바일 데이타 분석 뿐 아니라 일반적인 데이타 분석에서도 경험상 보면 필요한 핵심 지표의 수는 그리 많지 않다. 오히려 지표가 많을 수 록 혼란이 생기고, 각 지표의 의미를 이해하기 위해서 많은 노력이 들어간다. 그래서 조직에서 그리고 비지니스에서 꼭 필요한 핵심 지표 위주로 지표를 선정하고 집중해서 관리 하는 것이 훨씬 더 효과적이 아닌가 한다.


추가적인 분석 지표


앞서 살펴본 일반적인 지표 이외에도 모바일 서비스에 있어서 중요한 추가 지표들이 있다.


크래쉬 비율


앱의 사용자 유발하고, 앱 평가를 떨어뜨리는 요인중의 하나가  ANR(Application Not responding : 애플리케이션이 멈춰서 응답이 없는 현상) 또는 앱이 비정상 종료 되는 경우인데, 모든 케이스는 아니지만 상당 케이스는 모니터링 도구를 통해서 추적이 가능하다. 구글의 플레이 스토어의 경우에도 개발자 콘솔을 통해서 이 ANR과 DOWN리포팅 및 로그를 받을 수 있고, 아니면 야후 Flurry나 트위터의 Fabric을 통해서도 이 문제에 대한 로그를 수집 및 분석이 가능하다. 




<그림. Fabric 크래쉬 분석 화면>


앱스토어 평가


서비스의 노출을 위한 검색엔진 최적화 만큼이나 중요한것이 모바일 앱에서는 앱스토어 최적화이다. 앱스토어에 올라가는 이미지, 문구, 분류 체계 그리고 검색 노출이 쉽게 하는 기능뿐 아니라, 앱스토어에서 앱에 대한 평점 관리는 대단히 중요한 지표이기 때문에 이 부분 역시 같이 신경써야 한다.



실제 측정을 위한 절차


그러면 이런 지표들을 측정하고 사용하기 위해서는 어떠한 절차를 거쳐야 할까?


정보 모델의 설계


가장 중요한 것은 정보 모델의 설계이다. 서비스 특성을 감안하여 가장 중요한 성장 동력이 되는 지표가 무엇인지, 앞의 퓨넬 모델에서 설명한 사용자의 획득에서 수익 창출 단계까지 이르기 까지 서비스의 특성에 따라서 어떤 지표가 필요한지를 선정하고, 서비스에 맞춰서 각 지표를 정의하는 것이다.


미디어 서비스의 경우 앱 인스톨, 액티브 사용자 비율, 탈퇴 비율등과 같은 정적 지표와

사용자가 메인에서 리스트로 진입해서 컨텐츠를 보고 댓글을 쓰는 동적 이동에 따른 메인 뷰 수, 컨텐츠 뷰수, 체류 시간과 같은 동선에 따른 지표를 정보 모델로 정의할 필요가 있다.


구현 방식 선정


이러한 정보 모델이 정의 되고, 각 대표 지표가 선정이 되었으면, 이를 실제 구현할 수 있는 구현 방법을 결정해야 하는데, 모바일 데이타 분석은 빅데이타 영역에 속하기 때문에 자체 구축을 하려면 하둡이나 스파크같은 복잡한 인프라가 필요하고 대용량 데이타를 저장 및 분석하기 위한 많은 하드웨어와 인력이 필요하다.


근래에는 클라우드 서비스 형태로 제공되는 모바일 앱 분석 서비스들이 많고 광고 플랫폼을 중심으로 앞에서 언급한 구글,야후,트위터들이 무료 분석 플랫폼을 제공하기 때문에 이러한 무료 플랫폼을 이용하는 것도 하나의 방법이 된다. 

개인적으로는 Flurry를 가장 선호하는데, 사용자 수에 대한 제약이 없고 User Path, Funnel 분석등 다양한 기능을 제공한다. Google Analytics의 경우 기능이 막강하고 다양한 커스터마이제이션이 가능은 하지만 사용법 학습등에 많은 노력이 필요하고, 일정 볼륨이 넘어가면 1억원 이상의 비용을 지급하고 유료로 사용해야 하기 때문에 과연 좋은 선택인가에 대해서는 의문이 있다. 




단 이러한 플랫폼의 경우에는 커스터마이징이 어렵고 이로 인하여 대쉬 보드에 원하는 지표를 다 넣을 수 없는 경우가 많기 때문에 만들어놓더라도 각각의 지표가 연결된 의미를 찾지 못해서 무용지물화 되기 쉬운 단점이 있고, 앱스토어나 기타 흩어져있는 시스템들의 정보를 취합하여 보여줄 수 없다.


중간 대안으로는 정보분석 플랫폼을 사용하되, 이러한 분석 플랫폼들은 오픈 API를 제공하고 있고, 앱스토어도 오픈 API를 제공하기 때문에,  이러한 API를 이용하여 여러 소스로 부터 데이타를 모으고, 조직의 데이타 분석 수준이나 뷰에 적절한 대쉬 보드를 직접 구축하면 훨씬 높은 효과를 얻을 수 있다.


이벤트 태그 삽입


구현 방식이 선정되면 앱에서 발생하는 이벤트 (시작, 종료, 메인 페이지 이동, 댓글 등록)를 플랫폼으로 보낼 코드를 삽입하면 된다.


야후 플러리의 경우 간단하게 이벤트 명을 입력하는 것만으로 이벤트를 로깅 할 수 있다.


[Flurry logEvent:@“EVENT_NAME"];


<코드. 야후 플러리 이벤트 로깅 iOS Object C 예제>


이때 솔루션에 따라 이벤트의 개수와 이벤트의 길이에 제약이 있기 때문에, 정보 모델을 설계할때 적절한 이벤트 수를 정하는 것이 중요하다. (플러리의 경우 300개의 이벤트, 이벤트 명은 255자 이하)

이벤트 명을 정의할때는 정보 모델에 따라서 트리 구조로 계층 구조를 갖는게 좋은데 예를 들어


/main

/main/contents/

/main/contents/comment


식의 REST 형식의 리소스 형태를 사용하게 되면, 훨씬 더 직관적으로 이해 쉽다.



맺으며


모바일건 웹이건 근래의 서비스는 경쟁이 심해지고 빠르게 사용자의 니즈를 이해하고 맞춰나가지 않으면 생존하기 힘든만큼 데이타 분석은 선택이 아니라 거의 필수적이다. 


이러한 데이타 분석은 갑자기 튀어난게 아니라 Dataware house, Business Intelligence, OLAP 등으로 예전 부터 전통적으로 존재하고 있는 시스템이고 다만 구현 방식이나 강조되는 포인트들이 다소 변경된것인데, 경험상으로 보면 이런 시스템을 구현하는 데 많은 비용과 노력을 들이지만 100% 잘 사용되는 경우가 드물다. 

 원인을 보면, 시스템을 구축하지만 이 구축된 정보를 얼마나 쉽게 전달할것인가에 대한 고려가 적고 지표에 대한 이해와 시스템 사용 방법에 대한 교육이 없이 한정된 배경 지식만으로 전체 지표를 이해가 불가능 하기 때문이다.

 시스템을 보는 입장에서 최대한 단순하게 만들어야 되는데, 경험상 BI 프로젝트등을 해보면 멋진 대쉬보드를 만들어놓고도 결국 끝에 가서 나오는 말은 액셀로 보내주세요... 이다.

 시스템의 구축이 전체의 30% 이하 정도의 작업이라면 나머지는 필요한 지표의 정의, 정보 모델의 정의, 사용자가 원하는 대쉬보드의 구축, 구성원들에 대한 데이타 분석 및 시스템에 대한 활용 교육이 지속적으로 제공되어야 한다. 큰그림을 이해하지 못한 상태에서 파편만 보다가는 전체 흐름이나 방향을 놓칠 수 있기 때문에 이 부분에 대해서는 몇번을 강조해도 부족함이 없을것이라 본다.