※ 이 글은 국내 최초 BI 커뮤니티 Vizable의 1기 멤버 양혜리 님이 콜라보레이터로서 게재해주신 글입니다. Vizable에 대한 자세한 이야기는 vizable.online에서 만나실 수 있습니다.

Active vs. Inactive Dashboard

안녕하세요! 비저블 1기 양혜리 입니다 : ) 오늘은 비저블 멤버로 활동하며 설계한 비즈니스 시나리오 대시보드를 소개해드리고자 합니다.

오늘 소개해드릴 ‘Active vs. Inactive Dashboard’는 게임 내 활성유저와 이탈유저를 분류하고 이들의 행동패턴을 비교분석하는 대시보드 입니다. Retention 개선을 위해 활성유저(Active) → 이탈유저(Inactive)로 가는 여정을 막고 이탈원인을 파악해 개선하는 목적을 가지고 있습니다.

이 대시보드의 가장 큰 장점은 바로 대시보드 사용자의 Self Service가 가능하다는 점인데요. 대시보드 사용자마다 적절한 이탈기준의 관점이 다를 수 있다는 점을 고려해 매개변수를 이용한 상단필터로 적절한 이탈 기준(연속 미접속 기간 n일)을 조정할 수 있습니다. 이를 통해 사용자가 직접 이탈기준을 지정하여 이탈유저를 분류하고, 이들의 게임 플레이 패턴을 비교해보며 인사이트를 얻으실 수 있습니다.

💡 Key question : 왜 이탈 유저 관리가 필요할까요?

신규 유저 Acquisition은 수많은 서비스에서 핵심 성과 지표로 모니터링 되고 있는 만큼, 서비스 성장성을 평가하기 위한 중요한 척도입니다. 그러나 단순히 신규 유입 유저수가 많다고 해서 해당 서비스의 성장성이 높다고 할 수 있을까요? 만약 신규 유입된 유저들 중 90% 상당이 첫 유입 후 재방문을 하지 않는다면 어떨까요?

이렇듯 단순 신규 유저 유치를 넘어, 지속적으로 방문하고 싶은 서비스의 가치를 만들어 내기 위해서는 Retention을 높이고 Drop-off를 최소화하는 것이 핵심입니다. 신규 고객 유치 전략과 함께 리텐션 마케팅 전략이 적절하게 병행될 때, 보다 지속적이고 안정적인 서비스의 원동력을 가질 수 있습니다. 이러한 이유로 실제 이탈 가능성이 높은 유저를 미리 분류하고 사전에 이탈을 막기 위한 Retention 전략을 수립한다면, 장기적 관점에서 서비스의 성장을 가속화하는데 도움을 줄 수 있을 것 입니다.

비즈니스 시나리오

Vizable game company는 하반기 핵심 목표 성과 지표로 Retention N% 증가를 설정하였습니다.

• Retention 개선을 위해서는 활성 유저(Active) → 이탈유저(Inactive)로 가는 여정을 막고, 이탈 원인을 찾아내 개선하는 것이 필요해보입니다.
• 그러나 현재 이탈 유저가 누군지, 몇 명인지 정의할 수 있는 지표가 없습니다. 따라서 이탈유저에 대해 객관적으로 진단할 수 없는 상황이며 어떠한 이유로 유저들이 이탈하는지 전혀 알지 못하는 상황입니다.

이러한 배경을 바탕으로 사업부는 다음과 같은 분석을 요청했습니다.

” 활성유저와 이탈유저를 파악하고, 이탈의 원인이 어디서 비롯되는지 확인하고 싶어요.”

문제 정의

활성유저와 이탈유저의 구분을 위해서는 ‘이탈’의 기준을 설정해야합니다. 그렇다면 이탈을 정의하기 위한 적절한 기준은 무엇일까요?

단순히 코호트별 해당일자에 접속한 유저를 활성 유저, 미접속한 유저를 이탈 유저로 설정한다면 유저들의 분류도 매번 달라질 것입니다. 또한 장기적인 관점으로 보았을 때 이들의 행동을 모니터링 하기도 쉽지 않습니다. 이러한 한계를 보완하고자 이탈의 기준을 연속 미접속한 유저를기준으로 설정한다면, 실제 이탈 가능성이 높은 유저들을 효과적으로 분류할 수 있는데요. 마지막 접속이 한참 지난 유저는 재유입을 위한 캠페인 등 이벤트가 없는 한, 다시 돌아올 가능성이 매우 희박하기 때문입니다.

이러한 아이디어를 바탕으로 이탈 기준을 정의하기 위한 가설은 다음과 같습니다.

“N일 연속으로 미접속한 유저는 이탈 유저일 것이다.”

위 가설에서 N값이 클수록 정확한 이탈의 정의가 가능해집니다. 그러나 활용 차원에서 볼 때, 너무 넓은 time frame을 적용할 경우 분석결과를 활용하기 어렵다는 단점이 있습니다. 즉, 이탈기준 N값이 무조건 크다고 좋은 것은 아닙니다.

예를 들어 한 달에 한 번 업데이트하는 게임의 경우, N값을 60일로 선정한다면 업데이트 주기가 약 30일임에도 불구하고 이탈 유저를 파악하기 위해서는 최소 60일을 기다려야합니다. 따라서 적절한 time frame을 설정하여, 최근 N일 내 연속 미접속한이력이 있는 유저의 비율을 확인하고 특정 N의 구간을 파악해 이를 적절한 이탈 기간으로 정의하고자 합니다.

데이터

• 2019.09.01 – 2019.10.26 기간동안 로깅된 로그 데이터로, 총 804,558개의 row와 5개의 column으로 이루어져 있습니다.
• 접속 이력이 있는 유니크 유저 수는 80,890명 입니다.
• Community/Daily/Special로 나누어진 총 3가지 게임 미션이 제공됩니다
  
  
  

시트 구성

주어진 데이터 time frame이 약 2달로 한정적이라, 해당 기간을 모두 활용해 이탈 기준을 정의하겠습니다.

1. N일 동안 연속으로 미접속한 이력이 있는 비중 계산 (=누계)

[ N일별 연속 미접속 유저 비중 ] 을 행으로, 미접속 기간 [ days from last event ] 을 열로 두어 비중 누계차트를 만들겠습니다. 누계차트를 사용한 이유는 누적비율이 완만해지는 부분을 직관적으로 파악하여, 이탈 기준 N일을 손쉽게 선정할 수 있기 때문입니다.

유저별 마지막 접속 일자

[ last event date per user ]
{FIXED[User ID]:MAX([Event Time])}

마지막 접속일로부터 N일 (미접속 기간)

[ days from last event ]
DATEDIFF('day',[last event per user],[Max event date])

[ 최근 N일 이내 접속한 유저 비중 ]
ATTR({FIXED [days from last event]:COUNTD([User ID])})/ATTR({FIXED :COUNTD([User ID])})

하지만 사람마다 ‘이탈 기준 N일을 언제로 하느냐’의 관점이 다를 수 있습니다. 따라서 대시보드 이용자가 직접 적절한 N일을 설정할 수 있도록, 미접속 기간 N일에 매개변수 [이탈기준 day] 를 생성하였습니다.

매개변수를 바탕으로 분류된 Active/Inactive를 하이라이트를 위해 [ Active type ]이라는 필드를 생성합니다. 이탈기준 N일보다 작으면 활성(active)유저, N일 이상이면 이탈(inactive)유저가 되도록 설정하였습니다.

[ active type ]
IF [days from last event] < [이탈 기준 days] then 'active' ELSE 'inactive' END

2. 유형별(acitive/inactive) 유저 수/플레이 횟수

먼저 유형 별 active/inactive 유저 수를 집계하기 위한 필드를 생성하겠습니다.

[ active user 수 ]
COUNTD(IF [active type]='active' then [User ID] END)

[ inactive user 수 ]
COUNTD(IF [active type]='inactive' then [User ID] END)

전체 유저 중 active/inactive 유저를 비중을 파악하기 위한 필드도 생성합니다.

[ active user % ]
[active user 수]/COUNTD([User ID])

[ inactive user % ]
[inactive user 수]/COUNTD([User ID])

플레이 횟수 및 비중 필드를 계산 할 때는 COUNTD([User ID]) 대신 COUNT([Event Time])식을 넣고, 위와 동일한 방식으로 만들어주시면 됩니다.

유형별(acitive/inactive) 플레이 횟수 필드를 생성합니다.

[ active play ]
COUNT(IF [active type]='active' then [Event Time] END)

[ inactive play ]
COUNT(IF [active type]='inactive' then [Event Time] END)

전체 플레이 횟수 중 active/inactive 유저의 플레이 횟수 비중을 파악하기 위한 필드를 생성합니다.

[ active play % ]
[active play]/count([Event Time])

[ inactive play % ]
[inactive play]/count([Event Time])

여기까지 활성유저와 이탈유저의 분류를 위한 작업을 거쳤다면, 이제는 유저 유형별 게임 플레이 패턴에 차이가 있는지 비교하기 위해 다음과 같은 두 가지 분석 사항을 수행하겠습니다.

• 유저들은 대체로 3가지 미션(Daily/Community/special) 중 몇 가지 미션을 수행할까?
• 어떤 미션 조합을 많이 수행할까?

3. 플레이한 미션 개수별 active/inactive 유저 수

Active/Inactive 유저들은 대체로 3가지 게임 미션(daily, community, special) 중 몇 가지 게임을 플레이하는지 알아보기 위해, [ 플레이한 미션 개수 ] 라는 필드를 생성하여 유형별 유저수를 확인해보겠습니다.

Active

Inactive

[ 플레이한 미션 개수 ]
STR({FIXED[User ID]:COUNTD([Selected Mission])}) + '가지'

4. 미션 수행 유형별 유저수 분포

다음으로는 미션 수행 유형별 유저 수를 살펴보겠습니다. 미션 수행 유형은 아래와 같이 7가지 항목으로 나눌 수 있습니다.

아래 사진과 같이 유저별 플레이한 미션들이 다른 row로 분리되어 있어, multiple rows를 하나로 합친 후 미션 수행 유형을 매칭해야합니다.

1) 1가지 미션만 수행한 유저 (only daily, only community, only special) : 유저가 [ 플레이한 미션 개수 ] 필드 값이 1이며, [ selected Mission ]이 각각 daily, community, special에 매칭할 경우

IF [미션실행 수] = 1 AND [Selected Mission] = 'daily_mission' THEN 'only daily'
ELSEIF [미션실행 수] = 1 AND [Selected Mission] = 'community_mission' THEN 'only community'
ELSEIF [미션실행 수] = 1 AND [Selected Mission] = 'special_mission' THEN 'only special'

2) 2가지 미션만 수행한 유저 (daily&community, daily&special, community&special) : 유저가 [ 플레이한 미션 개수 ] 필드 값이 2이며, [ selected mission ]의 최초 및 마지막 실행 미션이 유저의 해당 2가지 미션 값으로 매칭될 경우

+) 유저의 최초 및 마지막 실행 미션을 매칭할 필드를 먼저 만들어 준비해주세요!

유저별 최초 실행 미션

[ min mission ]
{FIXED[User ID]:MIN([Selected Mission])}

유저별 마지막 실행 미션

[ max mission]
{FIXED[User ID]:MAX([Selected Mission])}

ELSEIF [미션실행 수] = 2
AND (([min mission]='daily_mission'AND[max mission]='community_mission') OR ([min mission]='community_mission' AND [max mission]='daily_mission'))
THEN 'daily & community'
ELSEIF [미션실행 수] = 2
AND (([min mission]='daily_mission' AND [max mission]='special_mission') OR ([min mission]='special_mission' AND [max mission]='daily_mission'))
THEN 'daily & special'
ELSEIF [미션실행 수] = 2
AND (([min mission]='community_mission' AND [max mission]='special_mission') OR ([min mission]='special_mission' AND [max mission]='community_mission'))

3) 3가지 미션 모두 수행한 유저 (All) : 유저의 [ 플레이한 미션 개수 ] 필드 값이 3이며, [ selected Mission ]에 daily, community, special가 모두 포함될 경우

ELSEIF [미션실행 수] = 3
AND [Selected Mission] in ('daily_mission','community_mission','special_mission') THEN 'all'

💡 Question

2가지 미션 수행유형을 구할 때, 3가지 미션 모두 수행한 유형에서 로직처럼 [field] in (‘mission1′,mission2’)를 사용하지 않고 min, max를 사용한 이유는?

[Selected Mission]in ('community_mission','special') then 'community&special'  
[Selected Mission]in ('daily','community_mission') then 'daily&community'  
[Selected Mission]in ('daily','special') then 'community&special'  

다음과 같은 순서로 로직을 구성했다고 가정해봅시다. 사실 아래의 2461 유저 같은 경우, 두 row 모두 daily&community가 나와야하는게 정상이지만, 해당 계산된 필드의 식이 순차적으로 적용되게 되어 각각 community&special, daily&community로 레이블링 될 수 있으므로 해당 로직을 사용하지 않습니다.

최종 Field View

마지막으로 각 유저 별 미션 수행 유형이 알맞게 매칭되었는지 확인해보겠습니다.

잘 매칭되었군요!! 👏🏻

Active

Inactive

만들어 둔 [ 미션 수행 유형 ] 필드를 바탕으로 각각 active/inactive 유저 수를 집계한 후, 퀵 테이블 계산을 통해 구성비율로 변경하였습니다.

인사이트

상단필터를 통해 이탈기준(연속 미접속기간) N일을 조정할 수 있으며, 월별로 지표를 확인할 수 있습니다. 상단필터를 통해 이탈기준(연속 미접속 기간)을 11일로 선택한 상태입니다.

1) Active/Inactive 유저 수, 플레이 횟수 지표

활성/이탈 유저 수 :

• 활성 유저 수(62,644명)는 이탈 유저 수(18,246명)에 비해 약 3.43배 높습니다. 또한 전체 유저 중 이탈 유저수의 비중(22.56%)에 비해, 이탈 유저의 플레이 수 비중은 7.69%로 매우 낮은 수준입니다.

인당 플레이 수 : Inactive user의 인당 플레이 횟수 역시 매우 낮은 상황입니다.

• Active user → 742,695/62,644 = 11.86 (회)
• Inactive user → 61,863/18,246 = 3.39 (회)

2) 플레이한 미션 개수별 유저 수 분포

• 활성 유저는 3가지 미션을 모두 플레이하는 비중이 높은 반면, 이탈 유저는 1가지 미션만 플레이 하는 비중이 매우 높습니다.
  → 특정 1가지 미션을 플레이 하는 과정에서 이탈이 많아지는 것으로 예상됨

어떤 미션에서 이탈이 생기는지 확인하기 위해 [미션 플레이 유형 별 유저 수 분포]를 확인해보겠습니다.

3) 미션 플레이 유형별 유저 수 분포

• 이탈 유저의 경우, 활성 유저 플레이 유형에 비해 only daily mission(37.69%)이나 only community mission(9.70%)만 플레이 하는 비중이 매우 높습니다.
  → daily mission 또는 community mission만 플레이하는 과정에서 이탈이 높은 것을 보아, 두 mission 내에서 개선해야 할 포인트를 찾을 수 있습니다. (난이도가 문제일까? 아니면 리워드 지급이 더 필요한가? 등등)

• 활성 유저의 경우 3가지 미션을 주로 수행하는 것으로 보아, 추후 1가지 미션만 플레이 하는 유저들은 이탈 확률이 높으므로 (=이탈 위험군) 다른 미션 플레이를 유도하는 넛지를 주는게 좋아보입니다.
  

이번 포스팅에서는 활성유저 vs 이탈유저 비교분석 대시보드를 함께 살펴 보았습니다. 물론 사용한 데이터의 정보가 구체적이지 않아 모든 유저가 9월 1일에 가입했다는 가정을 설정했는데요.

더 다양한 가입일의 유저 데이터, 더 넓은 time frame의 접속 세션이력을 통해 ‘연속 미접속일’을 판별한다면, 더 정확하고 세밀하게 이탈 위험 유저를 분류할 수 있을 것입니다.

앞으로도 비저블 활동을 통해 더욱 알차고 다양한 비즈니스 인사이트를 공유드릴 수 있도록 노력하겠습니다.

지금까지 비저블 1기 양혜리였습니다. 감사합니다 : )