선형 회귀 분석에서 분석 데이터의 적합성 여부를 항상 고려해야 한다. 

적합성 여부를 확인하는 방법 중 먼저 "결정계수(Coefficient of Determination, R-Square, R-제곱값, R2, R^2)"를  알아보자~

결정계수는 "수식이 얼마나 X와 Y의 관계를 잘 표현하고 있는지" 나타내는 기준이다.  

결정계수 (r-square)

일반적으로 결정계수는 0과 1사이의 값을 갖는데, 관계가 높을 수록 1에 가까운 값을 갖는다. 

즉, 0에 가까워질수록, 수식에 데이터 분포를 제대로 표현하지 못하는 것이며, 

1에 가까워지면 모든 데이터가 해당 수식에 접근한다는 것을 나타낸다. 

결정계수를 나타내는 수식을 보면 다음과 같다. 

SSR, SST, SSE?? 처음 접할 경우, 용어를 모르기 때문에 어렵게 느껴질 것이다. 

자세히 풀어서 설명할 것이니 끝까지 한번 읽어보기 바란다. 

모집단과 표본집단

만약 대통령 선거의 예측을 위한 여론조사를 한다고 생각해보자. 

전체 유권자를 대상으로 여론조사를 할 수 없기 때문에, 연령별 또는 지역별로 대상을 선정해서 여론조사를 하게 된다. 

이 경우, 전체 유권자를 대상으로 하는 것을 '모집단', 연령별 또는 지역별로 대상을 선정하는 것을 '표본집단'이라 한다. 

회귀 모형에서도, 전체 데이터 (모집단)를 대상으로 할 수 없는 경우가 대부분이므로 

선거 여론조사와 마찬가지로 표본집단을 대상으로 회귀식을 만들게 된다. 

즉, 선형 회귀식에서 모집단 전체에 대한 α와 β를 찾는 것이 실제로 불가능하기 때문에, 

α와 β를 추정하기 위해 표본으로부터 구한 자료를 사용하는 것이다. 

이제 Y값은 모집단과 표본집단에서 가져온 두 가지 경우가 있게 된다. 

보통 모집단에서 가져온 Y값을 '측정치', 표본집단에서 가져온 Y값을 '예측치'라고 한다. 

SSR, SSE, SST

예측치와 실제값 사이의 차이를 편차라고 한다. 

그리고 분산을 구하듯이 이 차이를 제곱해서 합하면 변동을 알 수 있다. 

(제곱하지 않고 더하면 0이 되기 때문에 분산과 같이 편차를 계산할 때는 보통 제곱해서 더하게 된다.)

먼저 예측치와 실제값 사이의 편차를 생각할 수 있다. 

표본집단에서 예측치를 구할 수 있고, 실제값은 추후 알게 되므로 이 편차는 구할 수 있다. 

그래서 '설명된 변동'이라고도 하며, 회귀 제곱의 합 즉, SSR(Sum of Square Regression)이라 한다. 

그리고 표본을 활용함으로써 모집단의 측정치와 표본집단의 예측치의 차이가 발생할 수 있다. 

측정치와 예측치 사이의 편차를 구한 것이 SSE(Sum of Square Error)가 된다. 

만약 SSE가 0이면, 표본의 회귀식이 모집단의 모든 내용이 표본 회귀식 내에 있다고 할 수 있다. 

결정계수 공식에 SSE를 0으로 대입해보면, 무조건 1이 나오게 된다. 

그러므로 결정계수가 1이면 모든 데이터가 해당 수식에 접근하다는 것이다.

마지막으로 SST(Sum of Square Total)은 모집단의 측정치와 실제값 사이의 편차이다. 

이것은 SSR과 SSE의 합한 것과 동일하다. 

이를 정리하면 다음과 같다. 

SSR: Sum of Square Regression, 회귀 제곱의 합, 회귀변동, 설명된 변동

SSE: Sum of Square Error, 오차 제곱의 합, 잔차변동, 설명 안된 변동

SST: Sum of Square Total, 총 제곱의 합,  총변동

수식으로 표현하면 다음과 같다. (Y값의 의미를 생각하면 금방 이해될 것이다.)

마치면서

정리하면, 결정계수는 총 변동 중에서 회귀선에 의해 설명이 되는 변동이 차지하는 비율이라 할 수 있다. 

이것은 0과 1사이의 값을 가지며, X와 Y의 관계가 클수록 결정계수는 1에 가까워진다. 

결정계수의 값이 0에 가까울수록 회귀선은 쓸모가 없으며, 클수록 (보통 R2>=0.65) 쓸모 있는 회귀식이 된다. 

그러나 결정계수가 적합성 검증에 절대적인 것은 아니다. 

실제로 결정계수에 대한 검정 방법이 없으므로, 결정계수로 회귀모형의 적합성을 설명하는 것은 위험하다. 

단지 독립변수들을 설명하는 것으로 활용해야 하며, 회귀모형의 적합성은 보통 F검정으로 해야한다. 

그래서 다음에는 F검정에 대해서 정리해 보려고 한다. 

엑셀을 활용하여 선형 회귀 분석을 만드는 방법을 살펴봤다. 

분산형 차트를 통해 선형 그래프를 그릴 수 있었다. 

아래 그림을 보면, y= 0.002x - 0.6 이라는 수식이 보인다. 

이것이 선형 회귀 분석에서 가장 필요로 하는 기본 수식이다. 

선형 회귀 분석은 새로운 X 값이 주어졌을 때, Y 값을 예측하는 용도로 주로 사용한다. 

위 예제는 "노출에 따른 클릭 수"로서 

"만약 노출이 1500번 일어났다면, 클릭은 몇번 일어날까?" 같은 질문에 답을 줄 수 있다. 

위 수식에서 x 대신 1500을 대입하면 된다. 

y = 0.002 x 1500 - 0.6 = 2.4

즉, 1500번 노출이 발생하면 2.4의 클릭이 일어날 것이라고 할 수 있다. 

이런 수식을 선형 회귀 분석에서는 어떻게 구할까? 

"최소 자승법"이라는 것을 활용한다고 하는데, 그래프와 각 점의 차이(오차)를 제곱해서 구한다고 한다. 

여기에서는 용어보다는 활용에 초점을 맞추기로 하자. 

회귀 분석을 통해 주어진 점들을 기반으로 이러한 수식을 구하면, 

새로운 x 값이 주어질 때, y 값을 예측할 수 있게 되는 것이다. 

그런데 수식 아래에 보면 r-제곱값이 나온다.  

이 값을 "결정계수"라고 하는데, 

수식이 얼마나 x와 y의 관계를 잘 표현하고 있는지 나타내는 기준이라고 보면 된다. 

r-제곱은 0과 1사이의 값을 갖는데 관계가 높을 수록 1에 가까운 값을 갖는다. 

즉, 0에 가까워질수록, 수식에 데이터 분포를 제대로 표현하지 못하는 것이며, 

1에 가까워지면 모든 데이터가 해당 수식에 접근한다는 것을 나타낸다. 

"노출에 따른 클릭 수" 예제에서는 r-제곱 값이 0.9876이므로 

데이터가 수식을 잘 표현하고 있다는 것을 알 수 있다. 

데이터 분석을 활용해 생성된 데이터를 보면 "결정계수", "Y절편", "X1" 값을 확인할 수 있다. 

y = 0.002x - 0.6 수식과 함께 보면 

X1이 기울기 값을 나타내고, -0.6이 Y절편을 나타내는 것을 알 수 있을 것이다. 

데이터 분석으로 요약을 만들어진 정보를 활용하면, 다음과 같은 형태로 노출 값이 주어졌을 때, 클릭을 예측할 수 있을 것이다. 

맨 아래 보면 X1, Y절편을 활용해 노출에 따른 클릭 값을 계산한 것을 확인 할 수 있다. 

엑셀은 장부 정리와 같은 기본적인 스타일시트 툴로 잘 알려져 있지만, 분석(Analysis) 측면에서도 정말 괜찮은 프로그램이다. 

오늘은 엑셀을 이용해서 선형 회귀 분석을 수행하는 방법을 정리해 보려고 한다. 

선형 회귀 분석(Linear Regression)… 

말이 어려워 보일 뿐, 중고등학교 시절 수학 시간에 배운 X축, Y축의 선형 그래프를 생각해 보면 된다. 

엑셀로 선형 회귀 분석을 하기 위해서 간단한 데이터를 만들어 보자. 

광고 노출과 클릭간의 관계를 살펴볼 수 있는 데이터를 가상으로 구성한다. 

(다음 글에서 실제 광고 노출/클릭 데이터를 가지고 회귀분석을 해 볼 계획이다.)

다음과 같은 결과를 만드는 것이 최종 목표이다. 

분산형 차트 활용 

먼저 엑셀에서 출력할 위 데이터를 모두 선택한 후, "삽입" > "분산형" 그래프를 선택한다. 

아래 그림과 같은 분산형 차트가 생성될 것이다. 

메뉴에서 "차트도구"의 "레이아웃" > "추세선" > "기타 추세선 옵션"을 선택한다. 

이 "추세션"이 바로 엑셀 회귀 분석의 핵심이다. 

여기에서 "선형"을 선택하고, 하단의 "수식을 차트에 표시", "R-제곱 값을 차트에 표시"를 체크하도록 하자. 

그리고 난 후, 그래프를 보면 다음과 같다. 

위 데이터에 대한 선형 회귀 분석을 통한 방정식이 하나 만들어 졌고, 결정계수(R-제곱) 값도 구한 것이다. 

데이터 분석 활용

대부분 엑셀에 "데이터 분석"이라는 메뉴가 있는 것을 모를 것이다. 

왼쪽 상단의 로고를 선택한 후, "Excel 옵션"을 실행하자. 

그리고 왼쪽 메뉴에서 "추가 기능"을 선택하고, 우측 하단의 "이동" 버튼을 클릭한다. 

여기에서 "분석 도구"를 체크하고 "확인" 버튼을 적용한다. 

이제 "데이터" > "데이터 분석"이 있는 것을 볼 수 있다. 

"데이터 분석"을 선택하고, "회귀 분석"을 지정한 후, "확인"을 누른다. 

X축, Y축을 지정하면 해당 데이터에 대한 회귀 분석 결과를 아래와 같이 만들어 준다. 

선형 회귀 분석 데이터를 요약해서 보여준다. 

선형 회귀 분석의 데이터를 이해하고 활용하는 부분은 다음 글에서 설명하기로 하자...

카프카(Kafka)는 대용량 실시간 처리를 위해 사용하는 메시징 시스템으로 Pub-Sub 구조로 되어 있다. 

LinkedIn, Twitter, Netflix, Tumblr, Foursquare 등 대용량을 다루는 업체들이 주로 카프카를 사용하고 있다. 

물론 카프라 단독으로 실시간 처리를 구성하지 않고, 스톰(Storm) / 하둡(Hadoop) / HBase 등과 연동해서 활용하는 것이다. 

아직까지 국내에서 카프카를 실제 서비스에 많이 활용하고 있지는 않고

오히려 레디스(Redis)와 같은 메모리(In-Memory) 기반의 메시지 큐나 멤캐쉬(memcached)를 더 많이 사용하는 것 같다.  

하지만 전세계 40여개가 넘는 대용량을 다루는 업체들이 어떻게 카프카(Kafka)를 사용하고 있는지 한번 정리해 보기로 한다. 

카프카(Kafka) 개요

비즈니스 소셜네트워크로 유명한 링크드인(LinkedIn)은 메시징 및 로깅 처리를 위해 ActiveMQ와 Splunk를 사용하고 있었다. 

하지만 링크드인이 점차 글로벌 서비스로 성장하면서 데이터 양이 늘어남에 따라 기존의 기술들은 확장성이 떨어졌다. 

그래서 플럼(Flume)이나 스크라이브(Scribe)와 같은 기술도 검토했지만 결국 확성이 높고 신뢰할 수 있는 시스템을 만들기로 결정했다. 

이렇게 시작된 카프카는 링크드인에서 빠른 처리 속도를 보장하는 분산 메시지 큐로서의 역할을 하게 된다.  

이후 아파치 탑 프로젝트(Apache Top Project)로 등록되면서 버전 0.8임에도 불구하고 점차 사용하는 회사를 늘어나게 된다. 

카프카(Kafka) 구성요소

카프카의 가장 큰 특징은 다른 메시징 시스템과 달리 파일시스템을 이용한다는 점이다. 

메모리에 저장하는 구조가 아니기 때문에 데이터 자체의 휘발성이 없으며 효율적으로 데이터를 보관할 수 있다. 

또한 시스템 자체가 프로듀서(Producer) / 컨슈머(Consumer) / 브로커(Broker)로 매우 간단하게 구성되어 있다. 

프로듀서는 데이터를 카프카로 전달하는 역할을 하고

컨슈머는 카프카에 저장된 데이터를 가져오는 역할을 한다. 

위 그림에서와 같이 여러개의 프로듀서와 컨슈머를 구성할 수 있다. 

이것은 데이터의 수집을 여러 곳에서 할 수 있고 

해당 데이터를 처리하는 것도 활용 범위에 따라 여러개 만들어서 처리할 수 있다는 것이다. 

프로듀서와 컨슈머에 대한 API를 제공함으로써 어떤 서비스와도 잘 결합되게 만들어져 있다는 점도 특징이다. 

특히 빅데이터 분석에 많이 사용하는 하둡(Hadoop/HBase)과 해당 컨슈머를 구성해서 바로 연동할 수 있다. 

카프카에서는 토픽(Topic)을 설정해서 데이터를 전송하고, 각 토픽을 기준으로 파티션(Partition)을 구성해 저장한다. 

각 파티션에 들어온 순서대로 저장하고 순차적으로 컨슈머에게 전달해 처리하게 된다. 

물론 파트션에 저장하는 정보의 양도 설정값으로 조정할 수 있다. 

파티션 구조를 효과적으로 사용하고 신뢰성있는 시스템을 구성하기 위해서 카프카 클러스터(Kafka Cluster)를 구성해야 한다. 

카프카 클러스터를 구성하는 장점에 대해 링크드인의 엔지니어인 준 라오(Jun Rao)는 다음과 같이 이야기한다. 

The benefits of Kafka replication

- A producer can continue to publish messages during failure and it can choose between latency and durability, depending on the application

- A consumer continues to receive the correct messages in real time, even when there is failure

마지막으로 카프카 클러스터를 관리하기 위해서 주키퍼(Zookeeper)를 사용해서 각 노드를 모니터링한다.

카프카를 설치하면 주키퍼도 함께 설치되는 것을 확인할 수 있다. 

카프카 서버 구성

실제 카프카를 활용하려고 할 때 클러스터를 구성하는 방법에 대해서 자료가 부족한 것이 사실이다. 

아래 카프카 클러스터를 통해 개념만 한번 정리해 보자. 

위 그림은 카프카 클러스터로 서버 3대를 사용하고 있으며, 주키퍼로 모니터링 하고 있다. 

"zerg.hydra"라는 토픽으로 데이터를 전송하고 있고 파티션은 2개를 사용하고 있다. 

브로커1(broker1)을 보면 P0/R1이 진하게 표시된 것을 알 수 있는데, 이것은 브로커1이 파티션0의 리더(leader)임을 나타내는 것이다. 

정상적인 경우라면 파티션0의 데이터를 읽기 위해서 리더인 브로커1의 데이터를 활용하게 된다. 

만약 브로커1에 문제가 발생한다면, 파티션0가 복제(Replication) 되어 있는 브로커2(broker2)의 데이터를 사용하게 될 것이다. 

이러한 브로커2와 같이 복제 되어 있는 서버를 팔로워(follower)라고 한다. 

그렇다면 이러한 복제(Replication)을 어떻게 구성해야 할까?

구글의 글로벌 분산데이터베이스인 스패너(Spanner)나 아파치의 주키퍼(Zookeeper)는 "Quorum Based" 방식으로 복제(Replication)을 구성하고 있다. 

이 방식은 리더가 모든 팔로워(복제 대상 서버)에 데이터가 전송될 때까지 기다리지 않고,

대부분의 팔로워가 데이터를 수신하면 바로 리더에서 데이터를 처리하도록 한 것이다. 

만약 데이터 처리 중 리더에서 오류가 발생하면, 복제가 완료된 팔로워들 중 하나를 새로운 리더로 추천하는 것이다. 

이렇게 함으로써 모든 팔로워에 복제가 완료될때까지 기다리는 것보다 복제 대기시간을 줄일 수 있게 된다. 

카프카를 제대로 활용하고자 한다면, 데이터 양과 위와 같은 사항들을 잘 고려해서 구성해야 할 것이다. 

현재 빅데이터 관련 기술로 Hadoop이 주로 활용되고 있습니다. 

그러나 최근 실시간 처리에 대한 요구가 늘어나면서 점차 In-Memory 기술에 대한 관심도 증가하고 있습니다. 

과거 실시간 처리를 위한 OLTP로서 데이터베이스를 주로 사용했지만, 

빅데이터 환경에서는 빠르게 생성되는 데이터 스트림을 처리하기 위해서 새로운 접근법이 필요한 것이죠. 

빅데이터 분석 기술에 대한 정리 에서도 Hadoop이외의 다른 기술들을 살펴보면서, 

구글에서는 Dremel을 통해 짧은 시간내에 수많은 데이터를 처리하기도 한다고 이야기했었습니다. 

처리하는 영역은 조금씩 다르지만 실시간이라는 이슈를 위해 주로 사용되는 기술들에 대해서 정리해 보도록 하겠습니다. 

Redis 

Redis는 "Remote dictionary System"의 약자로 BSD 기반의 오픈소스이며, VMWare가 인수해서 업그레이드를 하고 있습니다. 

In-Memory 기술로서 Key/Value Store로 구성되어 있어 NoSQL Database로 분류하기도 합니다. 

하지만 Message Queue, Shared Memory 용도로 사용될 수 있어 인스타그램, Stack Overflow, Digg와 같은 기업들이 

실시간 데이터 스트리밍 처리를 위해 활용하기도 합니다. 

다음은 node.js와 Redis를 활용한 아키텍처를 나타내고 있습니다. (출처: http://simonhampshire.wordpress.com/)

In-Memory 기술이라는 점에서 memcached와 유사하기는 하지만 

데이터를 디스크에 저장할 수 있는 Snapshotting과 AOF 방식 등으로 Persistance를 유지할 수 있습니다. 

다음에 설명할 Kafka와 유사하게 Message Queue뿐만 아니라 Pub/Sub 메시징 시스템도 지원하고 있네요. 

Apache Kafka

Kafka는 링크드인(LinkedIn)의 로그와 트래킹 시스템을 개선하기 위해 만들어진 것으로 Apache 프로젝트로 진행중입니다. 

분산 Pub/Sub 메시징 시스템으로 Hadoop과 연계해서 개발할 때 유용하게 활용된다고 합니다. 

최근 DEVIEW 2013의 발표를 보니 Netflix에서도 Kafka를 활용해서 데이터 로그를 처리한다고 하네요. 

Esper

Real-Time, In-Memory 기술로는 역시 CEP(Complex Event Processing)이 화두가 아닐까 합니다. 

Oracle, SAP 등 대기업들도 이러한 기술에 역량을 집중하고 있는데요. 

오픈소스인 Esper도 EPL이라고 하는 SQL과 유사한 스크립트 언어를 제공하는 등 잘 구성되어 있는 것 같습니다. 

CEP 기술은 수많은 이벤트에서 지정된 이벤트를 찾아내어서 필터링 할 수 있는 기술로 

흔히 이야기 하는 Event-Driven Architecture로 실시간 이벤트 처리 기술이라고 할 수 있습니다. 

Esper도 In-Memory 기술로 다음과 같은 아키텍처로 구성되어 있습니다. 

Esper로 데이터를 가져오기 위해서는 Storm을 함께 활용하기도 한다고 합니다. 

더 나은 의사결정의 효과를 어떻게 측정할 수 있을까요? 

데이터 통합에 따른 가치 창출 효과는 어떨까요?

고객의 행동패턴 분석을 통한 인사이트 발굴의 가치는 어떻게 계산할까요?  

이와같이 대부분의 분석의 가치는 유형이 아닌 무형 자산이기 때문에 측정하는 것 자체가 쉽지 않습니다. 

하지만 분석 전문가들에 따르면, 분석은 비즈니스를 수행하는데 있어, 경쟁 우위를 선점하기 위한 필수 사항이라고 이야기 하고 있습니다.  

실제로 제품을 개선하고, 프로세스를 최적화하고, 성과를 측정하고, 파트너를 관리하고, 변화에 빠르게 대응하기 위해서 Analytics를 사용하고 있다고 합니다. 

분석을 처음 도입할 때의 주 목적은 비용 절감과 생산성 향상이었다고 합니다.  

국내에서도 여러 개의 모바일 게임을 개발하는 업체들과 이야기를 해봤는데요. 

각 게임별로 통계를 각자 처리하기 때문에, 서비스 하는 게임 수만큼 비용이 낭비되고 있었습니다. 

통합적으로 통계를 관리할 수 있다면, 이런 비용들은 쉽게 절감될 수 있을 것입니다. 

그러나 진정한 분석의 가치는 스마트한 의사결정, 성능 향상, 그리고 전략적 목표를 달성하는데 있다고 볼 수 있습니다. 

이러한 내용은 징가의 사례를 통한 분석의 가치에서도 이야기 했었습니다. 

또한 분석을 통해서 과거 일에 대한 대응(Reactiving)에서 선제 대응(Proactiving)으로 전환할 수 있습니다. 

다음 그림은 각각의 분석 카테고리가 어떤 역할을 하는지 잘 설명해 주고 있습니다. 

그리고 분석을 전략적인 목적으로 사용하는 것은 그 효과는 크지만 경우의 수가 많지 않습니다. 

만약 분석을 전사적으로 도입한다면 운영적인 측면에서도 분석을 적용해서 활용도를 높이는 부분도 필요할 것입니다. 

운영적인 측면에서 분석 활용은 파급효과는 조금 적더라도, 분석의 활용범위가 넓어지는 장점이 있기 때문입니다. 

마지막으로 단순히 분석 플랫폼을 도입한다고 해서 이런 가치들을 얻을 수 있는 것은 아닙니다. 

바로 분석을 적절하게 수행할 수 있도록 구축해야 하는데요. 

이런 부분에 대해서는 다음 기회에 다시 한번 정리하도록 하겠습니다. 

분석(Analytics)이 실제로 얼마나 활용가치가 있을지, 세계적인 온라인 게임 업체인 징가(Zynga)의 사례를 살펴보도록 하죠..  

Analytics의 정의, Analytics의 필요성, Analytics의 성숙도 모델에 대해서는 이전 글을 참고하기 바랍니다.  

Analytics 접근방식

게임은 모바일 뿐만 아니라 인터넷 산업에서 가장 성공한 비즈니스 중의 하나입니다. 

하지만 분석 측면에서 보면, 게임 산업은 아직도 "fly blind" 즉 실제 통계 정보들에 의존하지 않고 새로운 게임을 감각적으로 만드는 경향이 있다고 합니다.

영화를 예로 들면, 좋은 시나리오 작가와 유명한 배우들, 그리고 훌륭한 감독을 선정해서 영화를 만든 다음, 

충분한 시장조사와 사전 분석 없이 그저 대박을 기대하면서 전세계로 상영을 시작하는 것과 비슷하다고 할 수 있습니다. 

하지만, 징가(Zynga)의 CEO인 Mark Pincus는 기존 게임산업의 방식에서 탈피해서 분석에 기반한 새로운 접근방법을 사용하고 있다고 합니다.

현재 징가의 게임 설계자들은 사용자들이 게임을 어떻게 이용하는지에 대한 분석 결과를 계속해서 받아서 반영하고 있습니다. 

그래서 징가의 게임은 영화보다는 TV 시트콤에 비유를 많이 합니다. 

즉, 시청자들의 피드백에 따라 시나리오나 인물들이 변화하는 것과 유사하다는 것이지요. 

징가는 사용자의 행동패턴을 추적함으로써, 게임을 더욱 재미있고 즐길 수 있도록 만들 뿐만 아니라, 

사용자의 충성도를 높이고 결과적으로 수익 향상까지 가져오고 있다고 합니다. 

그럼 실제로 분석을 어떻게 활용하고 있는 간단하게 살펴보도록 하겠습니다. 

Analytics 활용 사례

징가는 주로 다음 세가지 부분에 대해서 Analytics를 사용하고 있다고 합니다. 

• 실시간으로 앱의 상태를 모니터링
• 게임 설계 방향 결정
• 게임 플레이어의 경험을 개인화해서 제공 

실시간 모니터링

먼저 실시간으로 게임 데이터를 모니터링하여, 게임 실행의 비정상적인 패턴을 살펴본다고 합니다.

예를 들어, 새로운 버전 게임을 배포한 후, 모니터링을 통해 일별 방문자 수(DAU)와 같은 중요한 지표가 감소하고 있다는 것을 파악합니다.

이 경우, 가장 먼저 게임을 이전 버전으로 되돌리고 난 후, 왜 이런 일이 발생했는지 내부적으로 검토를 한다고 합니다. 

게임 설계 방향 결정

징가는 사용자들이 무엇을 하고, 얼마나 오래 하고, 얼마나 자주 사용하는지에 대한 분석을 통해 향후 방향을 결정한다고 합니다. 

실제 새로운 게임을 오픈할 때, 처음 몇 주동안 사용자들이 관심을 가질만한 일부 컨텐츠만을 제공한다고 합니다. 

그리고 사용자들의 패턴을 분석해서 결과를 확인하고, 어떤 게임 요소들을 추가하고 수정할지를 결정해 나간다고 하네요. 

게임 플레이어의 경험을 개인화 

마지막으로 사용자의 게임 경험치를 분석해서 개인화에 활용한다고 합니다. 

만약 사용자에게 다른 사람들을 추천할 때, 그들의 게임을 하는 성향등을 분석해서 함께 게임할 수 있는 사람들을 추천해 준다고 하네요.  

단순히 페이스북 친구들을 추천하는 것에서 벗어나서, 실제 게임을 함께 공유하면서 즐길 수 있는 사람들을 추천해주는 방식이라고 합니다. 

다른 게임회사는 어떻게 해야 할까?

물론 징가는 이미 게임으로 많은 수익을 창출하고 있고, 

내부적으로 수학자와 통계학자 등 데이터 분석 전문가들을 보유하고 있습니다. 

만약 일반 게임회사들이 이런 분석을 하려면 어떻게 해야 할까요? 

바로 전문적인 분석 플랫폼을 활용하면 됩니다. 

다양한 분석 플랫폼들 중에서 자신에게 맞는 것을 찾아서 활용하면 되겠죠. 

제가 진행하고 있는 모바일 분석 플랫폼인 Fingra.ph도 다가오는 8월 15일 완전 개편해서 새롭게 서비스를 시작합니다. 

지난 1년 동안의 서비스 경험을 토대로 다른 분석 서비스보다 이해하기 쉽게 통계 정보를 제공하도록 재구성했네요.

모바일 관련 회사라면 이미 1,500여만명의 사용자를 통해 검증된 Fingra.ph를 한번 활용해 보기 바랍니다. 

핑그래프(Fingra.ph)를 사용하면, 모바일 환경에서 징가와 같은 분석과 활용을 쉽게 할 수 있습니다. 

Analytics에 대해서 좁은 의미와 넓은 의미로 정리를 했었는데요. 

이번에는 Analytics IQ를 측정할 수 있는 성숙도 모델(Maturity Model)에 대해서 정리해 보도록 하겠습니다. 

소프트웨어공학에서는 업무능력과 성숙도를 평가하기 위해, CMMI(Capability Maturity Model Integration) 인증을 하기도 하는데요. 

빅데이터 시대에는 분석 능력을 평가하기 위한 인증도 나오지 않을까 하는 생각도 드네요. ^^

분석에 대한 성숙도 모델은 2010년 Harvard Business Press에서 Thomas Davenport, Jeanne Harris, Robert Morison이 쓴 

"Analytics at Work: Smarter Decisions, Better Results"에서 다음과 같이 나옵니다. 

현재 스스로가 어느 단계에 속하는지 한번 생각해 보시기 바랍니다. 

기술적인 관점에서는 다음 사항들을 진행해야 한다고 합니다. 

그러나 가장 중요한 것은 기술이 아니라 바로 리더쉽이라고 이야기 하고 있습니다. 

• 데이터를 통제하고 조정할 수 있어야 한다. 
• 주요 프로세스를 모니터링하고 관리할 수 있도록 리포트나 대시보드가 제공되어야 한다. 
• 데이터 분석가나 통계 담당자가 데이터를 확인하고 모델을 수립할 수 있는 권한이 있어야 한다. 
• 이러한 모델이 비즈니스르 수행할 수 있도록 핵심 운영 프로세스로 적용되어야 한다. 

다음 이미지는 "Secrets of Analytical Leaders"의 저자인 Wayne Eckerson의 Analytical IQ입니다. 

4가지 지표를 측정해서 오른쪽 상단에 위치하면 가장 좋다는 것이죠.. 

실제 이 책의 다른 Leader들의 이야기를 보면, Netflix, Zynga, Nokia 등이 "Analytical Competitor"라고 하고 있습니다. 

저도 현재 수행하고 있는 Fingra.ph를 기반으로 스스로 측정해봤습니다. ^^

Analytical Maturity 측면에서 보면, 

대시보드 이상의 Fingra.ph만의 몇몇 모델을 제시하고, 가설을 통해 검증해서 활용하므로 "Modeling" 이라고 할 수 있습니다.

Data Maturity 측면에서는, 

빅데이터 처리를 위한 데이터 수집/분석/시각화를 위한 인프라를 구성했기 때문에 "Big Data Ecosystem"이 맞겠네요

Analytical Culture 측면에서는,

Fingra.ph의 향후 비전, 가치, 전략을 실제 데이터를 통해서 수립했으므로 "Strategic resource"라고 할 수 있습니다. 

Scale and Scope 측면에서는, 

올해 8월 부터 본격적으로 고객들에게도 Fingra.ph의 주요 서비스를 제공할 예정이므로 

아직은 "Enterprise+"가 아닌 "Enterprise"라고 해야 할 것 같습니다. 

성공적인 Analytics를 위해서는 데이터를 가끔식 분석해서 사용하는 형태가 아니라 계속적으로 확인하고 분석해야 한다고 합니다. 

Fingra.ph도 8월 새로운 개편 이후, 새로운 데이터들을 토대로 계속 분석하고 모델을 세우고 검증해 나가야 경쟁력을 유지할 수 있을 것이라 생각합니다. 

여러분도 현재 하는 업무의 Analytics IQ를 스스로 측정해 보시기 바랍니다. 

모바일 분야의 신규 비즈니스를 위해 모바일 앱을 만들 때 어떤 점들을 고려해야 할까요?

먼저 훌륭한 기획이나 전략이 필요할 것입니다. 

당연히 직관적인 디자인과 안정적인 개발은 필수 항목이겠죠. 

그런데 사용자의 실행 형태를 측정하고, 모바일 앱을 통해 얻고자 하는 가치를 확인하는 것 또한 매우 중요합니다. 

실제로 스마트폰이 우리 생활 깊숙이 들어오면서, 마케터나 개발자들이 사용자의 행태를 분석하기 위해 지속적인 노력을 기울이고 있는 상황입니다. 

모바일 비즈니스는 시작된지 얼마 안되었지만 서로 좋은 앱으로 경쟁하려는 플랫폼이나 서비스들이 많기 때문에, 

모바일 앱 분석을 통한 사용자 행태를 파악해서 경쟁력을 갖는 것이 무엇보다 중요하게 된 것입니다. 

이제 모바일 비즈니스에서 Mobile App Analytics는 선택이 아닌 필수가 되었다고 할 수 있겠죠. 

이런 관점에서 Ryan Matzner가 이야기한 Get the most out of mobile app analytics with these 8 tips를 기반으로 정리 해보도록 하겠습니다. 

1. 앱을 마켓에 등록하기 전에 Analytics를 사용하라. 

모바일 분석 플랫폼을 언제 부터 사용해야 할까요? 

제가 Fingra.ph라는 모바일 앱 분석 플랫폼을 운영하면서 보면, App을 마켓에 등록하고 난 이후에 적용하는 경우를 많이 봤습니다. 

하지만 사용자의 행태 분석이라는 측면에서 보면, 

베타 테스트 더 나아가 내부에서만 테스트하는 시점부터 모바일 앱 분석을 사용하는 것이 좋습니다. 

실제로 베타 테스트를 진행하면서 디자인을 비롯한 개발 요소들을 많이 변경하기도 합니다. 

이럴때 단순히 회사 동료나 친구들의 의견만 듣고 수정하는 것보다는 

실제 사용 패턴을 확인하고 반영하는 것이 보다 좋은 앱을 만들 수 있을 것입니다. 

만약 신규 앱을 기획하고 개발하고 있다면, 

초기부터 모바일 앱 분석을 적용해서 사용자들의 패턴을 확인해 보시기 바랍니다.  

2. 사용자는 개발자가 의도한 대로 앱을 사용하지 않는다. 

모바일 앱을 만들기 위해 와이어프레임과 같은 기획을 할 때, 사용자의 흐름을 잘 설계해서 만들어 놓습니다. 

그런데 충분한 고민과 시간을 들여서 사용자의 동선을 기획했건만, 

대부분의 경우 사용자는 처음 기획했던 방식대로 앱을 사용하지 않습니다. 

만약 주변 친구나 가족들에게 테스트해보라고 하면, 특히 국내 환경에서는 않좋은 점 보다는 그저 괜찮다고만 할 뿐이죠. 

그래서 선입관이 없는 일반 사용자들로부터 피드백을 받는 것이 매우 중요합니다. 

그러나 잘 알지도 못하는 사람들에게서 이런 사용 후기를 받는 것은 쉽지 않습니다. 

그렇기 때문에 모바일 분석을 활용해야 합니다. 

모바일 분석 플랫폼을 사용하면, 사용자의 방문 횟수나 사용 시간, 재방문율 등 많은 정보를 알아낼 수 있습니다. 

이러한 정보들을 다양한 측면에서 해석해 보면, 사용자가 어떻게 사용하고 있는지 판단할 수 있을 것입니다. 

그러므로 개발자는 초기부터 다양한 사용자로부터 테스트 결과를 수집하도록 노력해야 합니다. 

그리고 사용하는 형태가 초기 기획의도와 맞는지 검토해보고 반영해 나가야 겠죠. 

3. 대상 고객에 적합한 KPI를 세워라

모바일 앱이 다양한 것만큼 모두 동일한 목표를 가지고 있는 것은 아닙니다. 

어떤 앱은 콘텐츠를 무료로 제공하면서 광고 수익을 얻으려고 하는 것도 있고, 어떤 앱은 앱내 결제를 통해 수익을 만들어 내려고 합니다. 

또한, 어떤 앱은 수익이 목표가 아니라 브랜드를 홍보하기만 하면 되는 것도 있습니다. 

이렇듯 컨텐츠 제공, 소셜 네트워크, 유틸리티, 전자상거래, 게임과 같이 대부분의 앱들은 서로 다른 KPI를 가지고 있습니다. 

만약 새로운 모바일 앱을 만든다면, 얻고자 하는 것을 먼저 명확하게 정의해야 합니다. 

그리고 나서 모바일 분석 플랫폼을 통해서 해당 KPI에 적합한 지표들을 중심으로 살펴보는 것이 바람직 합니다. 

실제로 사용하지도 않는 심지어 알지도 못하는 숫자들로 가득 찬 분석은 아무런 의미가 없습니다. 

정확한 정보를 필요한 시점에 제공할 수 있는 모바일 분석 플랫폼이야말로, 

모바일 비즈니스에 있어 인사이트를 주고, 실행할 수 있는 포인트를 제공해주는 것이겠죠.. 

4. 다양한 종류의 모바일 분석 플랫폼들이 있다.

모바일 비즈니스가 확장함에 따라 다양한 모바일 분석 플랫폼들이 계속해서 나오고 있는 상황입니다.

각각의 모바일 분석 플래폼들은 자기만의 영역을 구축하면서 발전하고 있습니다. 

광고 모델을 기반으로 하고 있는 것도 있고, 소셜 미디어 분석에 집중하는 것도 있고, 마켓 데이터 분석을 위주로 하는 것도 있습니다. 

또한 모바일 게임을 위한 분석 플랫폼을 제공하는 것도 있고, 콘텐츠를 전달하는 앱에 적합한 분석 플랫폼도 있습니다.

앞서 이야기한 대로 자신의 KPI를 확인하고, 본인에게 적합한 모바일 분석 플랫폼을 찾아서 선택하는 것이 중요하다고 생각합니다. 

5. 마켓 데이터 분석을 통해 경쟁자들의 이전 실수를 피하라. 

모바일 분석 플랫폼들은 마켓 데이터들을 분석하여 제공하기도 합니다. 

정보 보호 이슈로 경쟁자 앱에 대한 정보를 바로 제공하는 경우는 거의 없지만, 관련 카테고리와 같은 기준으로 경쟁자들의 동향과 비교해 볼 수 있습니다. 

이런 기능을 통해서 경쟁자들이 했던 실수들을 확인하고 피해 갈 수도 있고, 현재 내 앱의 위치가 어느 정도 되는지도 파악하는데 도움이 될 것입니다. 

모바일 분석 플랫폼들이 제공하는 마켓 분석이나 다른 데이터들을 참고해서 최선의 의사 결정을 해 보시기 바랍니다. 

6. 분석 플랫폼을 적절하게 적용하라. 

분석 플랫폼은 사용자 통계를 얻어서 분석하고 비즈니스에 활용하기 위해 사용하는 것입니다. 

그런데 모바일 분석 플랫폼을 사용할 때, 이런 목표로 사용하면서 SDK를 적절하게 적용하지 않는 경우가 많이 있습니다. 

실제로 대부분의 모바일 분석 플랫폼은 SDK와 함께 설치 메뉴얼을 제공합니다. 

반드시 설치 메뉴얼을 잘 확인해보고, 이해가 안되는 부분은 문의를 해서라도 정확하게 연동해야 합니다. 

그래야 정확한 사용자 통계를 얻을 수 있고 제대로 활용할 수 있기 때문이죠. 

또한 SDK를 정확하게 적용하지 않을 경우, 앱의 실행과 관련하여 영향을 줄 수도 있습니다. 

실제 Fingra.ph SDK를 설계할 때도 가장 중요한 것은 어떤 경우에도 앱에 영향을 주지 않아야 한다는 것이었습니다. 

반드시 SDK의 설치 메뉴얼을 확인하고 적용하고, 필요할 경우 플랫폼 제공사에 문의해서 확실하게 사용하기 바랍니다. 

7. 함께 성장할 수 있는 분석 플랫폼을 선택하라. 

모바일 분석 플랫폼을 제공하는 회사들은 모바일 비즈니스에 대해 많은 정보를 가지고 있습니다. 

또한 모바일 앱에 대한 개발 경험도 충분히 가지고 있기도 합니다. 

그래서 모바일 비즈니스를 확장하려고 할 때, 모바일 분석 플랫폼이 도움이 되는 경우가 많습니다. 

예를 들어, 앱 광고로 수익을 올려보고자 할 때 어떤 광고가 효과가 높은지를 분석 플랫폼을 통해서 확인할 수 있고, 

프로모션을 진행할 때, 어떤 채널을 확인하면 좋을지 등에 대한 정보들을 제공할 수가 있습니다. 

8. 모바일 앱 분석이 여러분의 모바일 비즈니스의 끝이 아니다. 

모바일 비즈니스를 진행하면서 페이스북, 트위터와 같은 SNS와 각종 온라인 광고등을 활용하기도 합니다. 

그래서인지 요즘 모바일 앱 분석이 앱 자체를 분석하는 것은 기본이고, 

SNS나 광고에서 발생하는 다른 데이터들도 통합해서 보여주기도 합니다. 

모바일 비즈니스를 위해서 모바일 앱 분석 뿐만 아니라 별도의 소셜 네트워크 분석을 활용해 보거나 

아니면 이러한 것들이 통합되어 있는 플랫폼을 사용하는 것도 필요할 것입니다. 

단, 가장 중요한 것은 앞에서도 이야기 한 것처럼 의미없는 데이터만 많은 것이 아니라 

정말 필요한 데이터를 구해서 활용하는 것임을 기억하기 바랍니다. 

결론

모바일 비즈니스 시장이 빠르게 확대되고 있기 때문에, 

앱 분석을 통해 현재 상태를 바로 확인하고 미래를 예측해서 비즈니스를 수행하는 것이 필요합니다. 

모바일 분석을 통해서 누구나 할 수 있는 많은 실수들을 사전에 예방할 수도 있을 것입니다. 

Fingra.ph 서비스를 작년 8월 15일에 베타 버전을 오픈하면서 사용자 행태 분석에 초점을 두고 진행했었습니다. 

신규 사용자 수, 사용자 수, 방문수, 사용시간, 사용빈도, 시간대별 사용자수, 국가별 사용자수와 같은 다양한 지표들을 보여줬습니다. 

이러한 사용자 행태를 분석하는 것은 대부분의 모바일 분석 플랫폼에 있어서 기본적인 항목이기는 합니다. 

솔직히 분석 플랫폼을 오랫동안 했던 구글등 경쟁사와 비교하면 기능적으로 더 낫다고 볼 수는 없겠죠. 비슷한 기능을 제공할 뿐이었습니다. 

하지만 미국, 중국등의 전시회에서 발표하면서 사용자들의 다음과 같은 점을 확인했습니다. 

즉, 기존의 분석 플랫폼들이 너무 많은 정보를 보여주려고 하면서, 소위 데이터 사이언티스트라고 하는 전문가의 도움 없이는 

제공해주는 통계를 해석할 수 없다는 것입니다. 

그래서 올해 8월 15일 정식 오픈하는 Fingra.ph는 이러한 통계를 보다 쉽게 제공하는데 중점을 두고 있습니다. 

이를 위해 App Profile이라고 하는 주요 지표를 한눈에 확인할 수 있는 기능을 개발하기도 했고, 

현재 App의 지표들을 카테고리의 최고 앱과 비교해서 보여주기도 하고, 

전체적인 상승과 하락을 직관적으로 확인할 수 있는 디자인도 제공할 계획입니다. 

또한 프로모션 분석에 초점을 맞추어 마케터들을 위한 기능들을 별도로 제공하려고 준비하고 있습니다. 

그리고 한국어, 영어, 중국어, 일본어 등으로 서비스할 예정이므로 영어로 된 통계에 힘들어했던 국내 사용자들에게도 도움이 될 것입니다. 

새롭게 준비하고 있는 모바일 분석 플랫폼인 Fingra.ph를 많이 기대해 주시기 바랍니다. 

감사합니다. 

빅데이터의 등장과 함께 Analytics에 대한 관심도 높아지고 있습니다. 

넓은 의미의 Analytics는 의사 결정권자에게 실행할 수 있는 인사이트를 제공해주는 것이라 할 수 있습니다. 

좁은 의미로는 사용자에게 데이터로부터 패턴을 파악해서 제공할 수 있는 기술이나 프로세스를 말합니다. 

일반적으로 IT와 관련된 용어들은 여러가지 측면에서 의미를 부여할 수 있습니다.

보통 비즈니스 측면과 기술적 측면으로 나눠 볼 수 있는데요. 

Analytics도 넓은 의미는 비즈니스 측면이고 좁은 의미는 기술적인 측면이라고 말 할 수 있겠죠. 

넓은 의미의 Analytics

일반적으로 데이터를 분석하는 목표는 비즈니스를 성공적으로 이끌어내기 위함입니다. 

즉, 넓은 의미의 Analytics는 비즈니스 자체에 목적을 두고 있다고 봐야 합니다. 

그래서 수많은 데이터에서 인사이트를 발견하고 이를 실제로 실행할 수 있도록 제공하는 것을 Analytics라고 이야기 할 수 있습니다. 

여기서 중요한 것은 바로 실행입니다. 

비즈니스의 성공을 위해서 기존의 데이터를 분석해 의사결정하고 행동에 옮길 수 있어야 한다는 것이죠. 

지난번 Harvard Business Review에 나온 의사결정에 숨어있는 함정에서도 이야기 한 것처럼 

단순히 직관에 의한 결정이 얼마나 큰 문제가 되는지 알 수 있을 것입니다. 

즉, Analytics를 통해 데이터에 기반을 둔 의사 결정을 할 수 있다는 것이 바로 최근 Big Data 측면에서의 Analytics라고 할 수 있습니다. 

다음 그림을 보면 Analytics 이전에도 이미 이런 움직임은 많이 있었습니다. 

90년대 초반의 Data Warehousing, 2000년대 초반의 Business Intelligence와 Performance Management 등이 여기에 해당한다고 할 수 있습니다. 

Data Warehousing에서는 데이터를 가져오는 것이 중요했고, 

Business Intelligence에서는 이런 데이터를 비즈니스에 사용하는 것이 목표였습니다. 

그리고 Performance Management에서는 이런 데이터의 활용으로 비즈니스를 개선하는 것이었죠. 

Analytics는 이런 과정을 거쳐서 비즈니스의 추진력을 높여주는 것이라고 이해할 수 있습니다. 

좁은 의미의 Analytics

좁은 의미로 살펴보면, Analytics는 데이터를 분석하기 위해 사용하는 기술이라고 이야기할 수 있습니다. 

데이터를 분석하기 위한 기술로는 주로 리포팅 툴과 분석 툴을 사용합니다. 

리포팅 툴의 예로 대시보드와 같은 것을 생각하면 됩니다. 

리포팅 툴을 활용하면 주요 현황을 모니터링 할 수 있고, 주어진 문제에 대한 해결책 등을 찾아낼 수 있습니다. 

반면, 분석 툴은 패턴, 트랜드, 또는 이상 징후를 찾아내기 위해 데이터를 탐구해 보는 것이라고 할 수 있습니다. 

즉, 데이터를 모니터링하기 위해서는 리포팅 툴을 사용하고, 데이터를 연구하기 위해서는 분석 툴을 사용한다고 볼 수 있겠죠. 

다음 그림은 이러한 흐름을 잘 보여주고 있습니다. 

Reporting과 Monitoring이 리포팅 툴을 이야기 하고 있는데요. 

Reporting은 과거에 일어난 일을 이야기하고, Monitoring은 현재 일어나고 있는 일을 살펴보는 것입니다. 

그리고 Analysis와 Prediction은 분석 툴로 간주할 수 있습니다. 

Analysis는 왜 일어났는지를 살펴보고, Prediction은 앞으로 일어날 일을 예측하는 것이 되겠죠. 

현재 저는 분석 플랫폼인 핑그래프(http://fingra.ph)를 진행하고 있습니다. 

작년 8월에 공개한 베타 버전이 리포팅 툴이었다면, 지난 미국 SXSW와 홍콩 ICT 엑스포에서 발표한 내용이 분석 툴에 해당한다고 할 수 있습니다. 

최종적으로 올해 8월 정식 버전은 넓은 의미의 Analytics인 의사 결정을 위한 플랫폼을 구축해 보려고 합니다. 

앞으로 기회가 되면 Analytics와 관련된 글들도 올려보도록 하지요..