PM이 꼭 알아야 하는 데이터 분석 프레임워크 실전편│서비스 기획자의 인사이트

오늘 알려드리는 이 방법으로

나는 동료들을 설득할 수 있었고,

내가 고민하고 기획한 방향으로 프로젝트를 리딩할 수 있었다.

 

마케터, PM이 실무에서 어떤 관점에서 데이터를 활용하게 되는지?

문제를 다루는 관점은 물론, 

바로 적용할 수 있는 전술적인 프레임워크까지 다!

 

<데이터로 일하고 임팩트 있게 성과를 측정하는 PM>  <<<이 되고 싶어요(전략).

 

PM의 핵심은 비즈니스 문제해결능력이다.

따라서 실무에서의 데이터 분석은 문제상황의 진단과 어떤 데이터를 어떤 관점에서 분석할지 결정하는 것에서부터 시작한다.

 

01 우리 회사의 장기목표를 이해하라

왜 실무자가 데이터를 활용하기 위해 회사의 목표, 즉 큰 그림을 볼 줄 알아야 할까?

모든 기업은 비즈니스 생존과 성장을 목표로 한다.

<<<전략 - 모스를 만들어보니 생존과 성장을 목표로 할 수밖에 없더라. 어느 정도까지의 성장을 한 후 계속 이 시장에서의 생존을 하려면, ~할 수 밖에 없다고 생각했기 때문이다.

 

[북극성 지표]

북극성 지표

 

실무자들이 실무 단에서 고민하는 주제는 파편화되어 있기는 하지만,

 

 

결국에는 어떤 요인이 우리 기업의 성장에 인과관계를 갖는지 파악하고,

>> (전략) 모스, 사업화로부터 참 많이 성장한 것 같아요. 제가 포트폴리오를 목적으로 처음 사이드프로젝트를 경험해보았을 때는, 그저 유저의 여정과 니즈, 페인포인트에만 집중한, 기획자같았는데,

처음으로 돈을 벌 사업화를 추진하다보니, 비즈니스적인 게 보이더라구요.

결과적으로는 네, 모스는 아직 유저확보에 힘을 쏟고 있는 단계입니다.

하지만, 정말 많이 성장한 것 같아요.

 

 

이 요인을 개선하기 위해 실무자들이 데이터를 분석하는 것이다.

 

따라서 실무자들은 비즈니스 성장이라는 회사의 최종목표를 이해하고

본인 업무의 목표 또한 이와 동일 선상에 두어야 합니다.

이때 성장의 의미는 회사가 속한 상황에 따라 다르고

이에 따라 회사의 영업방향이나 마케팅 전략이 결정된다.

 

[비즈니스 라이프 사이클]

상대적으로 신생 회사의 경우, 비즈니스 라이프 사이클 상 도입기에 있기 때문에

양적 성장을 목표로 적자를 감수하면서 출혈 프로모션을 전개할 수도 있고,

>>전략, 모스는 비즈니스 라이프 사이클 상 도입기에 있기 때문에 ~를 했고, ~~

어느정도 시장 내 점유율을 확보한 성숙한 기업의 경우

수익 창출 뿐만 아니라 영업 이익률 개선과 같은 질적 성장을 지표로 삼을 수도 있다.

 

그러므로 우리 회사가 속한 도메인의 특징과 비즈니스 목표를 이해하고,

그 방향성 속에서 각자의 문제를 정의하고 솔루션을 도출해야 한다.

 

EX. 마케터는 동일한 비용으로 신규 고객을 획득하기 위한 웰컴 프로모션을 수행할 수도,

       기존 고객의 재구매율을 높이는 로열티 프로그램을 진행할 수도 있다.

=> 이 때 선택의 기준이 되는 것이 바로 '우리 회사의 성장에 미치는 영향도'가 된다.

 

그러므로, 내가 우리 회사의 경영진이라고 생각하고 '지금 우리 회사에는 어떤 종류의 성장이 필요할까?'를 고민해보자.

'무엇이 이 성장을 저해하고 있을까?', '어떻게 하면 더 임팩트 있게 성장할 수 있을까?'

내가 담당하고 있는 영역에서 업무의 우선순위와 방향성을 정하는 데 도움이 될 것이다.

 

 

 

02 문제진단 프레임워크

여러 문제 속에서 우선순위를 정했다고 가정해보면,

EX.

B2C 화장품 회사 마케터

Task : 온라인 자사몰에서 A 브랜드 매출 증대

또한 이왕이면 단기적인 일회성 매출 증대보다는, 고객들을 충성 고객화하여 앞으로도 지속적인 매출을 발생시킬 수 있는 프로모션을 기획하고 싶다.

화장품은 매우 경쟁적인 시장으로, A 브랜드의 성장을 위해 충성 고객 확보가 중요한 요인이라고 생각하기 때문이다.

 

[문제진단 프레임워크 - MECE하게 사고하라]

그렇다면 곧바로 A 브랜드의 할인 프로모션을 기획할 게 아니라,

task를 다차원적으로 쪼개서 접근하는 것이 좋다.

 

문제상황을 MECE 하게 요소별로 나누어 분류하고,

이들 중 문제를 발생시키는 핵심이 되는 key driver와, 중요하지 않은 non-key를 파악하여 제거하는 것이다.

 

MECE는 세계적인 컨설팅 기업 McKinsey & Company에서 활용하는 사고훈련 기법인데,

Mutually Exclusive and Completely Exhaustive,

즉 모든 요소들은 중복되지 않도록 분명하게 분리되어 있으면서도, 

이 요소들의 합집합은 이슈를 누락하지 않고 모두 포괄해야 한다는 의미다.

결국 PM이 명확한 진단과 실효성 있는 솔루션을 도출하기 위해 반드시 탑재해야 하는 출발점이다.

 

이 접근법을 이 task에 적용해보자면,

- task : 온라인 자사몰에서 A 브랜드 매출 증대

- 매출 = 구매자 수 * 객단가

  구매자 수 = (1) 신규 구매자 + (2) 재구매자

  로, 매출을 구성하는 요소와 구매자 수의 요소는 이렇게 나누어 볼 수 있다.

=> 따라서 A 브랜드의 신규 구매자 수가 절대적으로 부족한 상황은 아닌지,

     그게 아니라면 고객의 구매 여정 도중에 이탈이 발생하고 있는지,

     혹은 기존 고객의 재구매율이 떨어지고 있는지 확인해볼 수 있다.

 

이렇게 하나의 결과에 영향을 미치는 여러 요소가 있음을 이해하고,

이 요소들을 파악해서 가장 효과적인 솔루션을 도출하는 이 사고훈련법은

어떤 지표를 눈여겨 보아야 할지 가이드라인을 제시하는 접근법이다.

 

 

03 분석 모델 프레임워크

MECE한 접근법을 통해 어떤 지표를 확인해야 할지 큰 틀이 잡혔다면,

추가적으로 활용할 수 있는 퍼널 분석 모델로 AARRR 프레임워크가 있다.

 

[분석 모델 프레임워크 - (1) AARRR 퍼널]

고객의 구매 여정을 Acquisition(고객 획득), Activation(고객 활성화), Retention(고객 유지), Revenue(구매), Referral(추천)

단계로 나누어 각각의 퍼널을 분석하는 모델이다.

(이 프레임워크 역시 Revenue 라는 매출을 달성하기 위해 필요한 전 과정을 MECE하게 분리한 프레임워크로 이해할 수도 있다.)

 

이 프레임워크를 활용하면 업무에서의 KPI를 단일하게 설정하는 것이 아니라,

각 단계별로 세분화해서 관리할 수 있다는 장점이 있다.

 

이때 고객의 정의는 회사의 비즈니스 모델에 따라 적용해야 한다.

우리 비즈니스가 웹 트래픽에 따라 광고 매출이 발생하는 SNS 플랫폼 회사라면 

고객은 우리 플랫폼에 회원가입을 한 유저가 될 수 있고,

제품을 만들어서 판매하는 제조회사라면

실제로 돈을 내고 제품을 구매한 paid user 를 고객으로 정의할 수 있다.

또한 오픈마켓 비즈니스의 경우, 제품을 구매하는 구매자와 상품을 판매하는 판매자 모두를 고객으로 정의해야 한다.

 

또한 이 모델의 다섯 단계는 이론적으로는 순차적인 퍼널 형태로 구성돼 있지만,

실제로는 무조건 저 순서대로 고객의 구매가 이루어지는 것이 아니라,

이렇게 각 요소들이 서로에게 영향을 미치며 돌아간다.

 

 

 

[분석 모델 프레임워크 - (2) Amazon의 Flywheel 모델]

두 번째로 소개하는 퍼널 모델은 아마존의 유명한 플라이휠 모델이다.

 

규모가 작은 업무 한 건 한 건에 적용하기 보다는

회사의 비즈니스 모델 전체에 적용해서 활용하는 경우가 많다.

 

하나의 프로덕트 성공을 구성하는 핵심 요소들을 뽑아내고 요소들 간의 역학관계를 조사한다는 점에서

Flywheel 역시 데이터 분석의 기준이 될 수 있는 프레임워크다.

 

나는 이 예시들을 참고해서 모스의 비즈니스 모델에 어떤 Flywheel이 필요한지 고민해보기도 했었다.

 

 

04 솔루션 의사결정 프레임워크

[솔루션 의사결정 프레임워크 - (1) Scenario Analysis]

문제를 진단한 이후에는 문제 상황을 해결하기 위한 솔루션을 다양하게 아이데이션 하게 된다.

그러나 현실적으로 모든 솔루션을 전부 다 운영하기는 어렵다.

 

보통 마케팅 부서에서 할당되는 예산과 기간은 정해져있기 때문에

주어진 리소스 내에서 가장 효과적은 솔루션을 선택하고

그 솔루션에 대한 세부적인 KPI를 세워서 퍼포먼스를 검증해야 한다.

즉, 어떤 솔루션이 가장 효과적일지에 대한 우선순위 설정이 필요하다.

 

여러 솔루션 중 하나의 솔루션을 선택해야 하는 상황이라면

각 솔루션을 통해 기대되는 퍼포먼스를 현실적인 Base scenario 부터

Best / Worst scenario 를 나누어서 예측해보는 것을 추천한다.

그리고 Base scenario 의 기대결과가 가장 높은 솔루션을 선택하는 것이다!

 

(실제 Scenario Analysis 는 Finance 분야에서 주로 사용하지만,

나는 이 개념을 프로덕트 리딩에 차용해 활용한다.)

 

 

물론, 상황별 시나리오를 작성하기 위해서는 경험적인 근거와 과거 실제로 수행했던 업무의 성과를 baseline 지표로 활용해서 근거로 삼아야 한다.

EX. 과거의 유사한 프로모션 진행 경험을 미루어 보았을 때

재구매 사이클이 도달한 고매에게 재구매시 할인 오퍼를 보내면

고객이 수용할 가능성, 즉 반응률은 평균적으로 20% 수준이었다.

 

반면, 신규 고객에게 3개월 내 사용 가능한 전용 쿠폰을 발급함으로써

추가로 획득된 고객은 평균적으로 10% 수준이었다.

 

이때 다른 모든 조건(비용)이 동일하다면

재구매 할인 오퍼 솔루션을 채택하고 집중 운영하는 것이 효율적이라고 판단할 수 있다.

 

그러나 이 방식은 동일한 기준으로 솔루션들을 비교하기 어렵다는 한계가 있다.

이 한계를 극복할 수 있는 프레임워크로 ICE scoring이 있다.

 

 

[솔루션 의사결정 프레임워크 - (2) ICE scoring]

그로스(growth) 아이디어에 우선순위를 매기는 방법론인데,

Impact / Confidence / Ease 세 가지 기준으로 솔루션 아이디어들을 평가한다.

Impact : 이 솔루션이 성공할 경우 얼마나 사업 성장에 큰 영향을 미칠 것인지,

Confidence : 이 솔루션의 성공 가능성을 얼마나 확신하는지,

Ease : 리소스 투입 시 얼마나 쉽고 효율적으로 달성 가능한 솔루션인지 이다.

 

이 세 가지 영역별로 점수를 매기고, 그 총합이 가장 높은 솔루션을 선택하면 된다.

아이스 스코어링의 예시와 각 요소별 측정의 주의사항은 다음 영상에서 더 자세하게!

 

 

물론 아직 기획 단계에 있는 아이디어의 사업적 임팩트나 성공 가능성을 객관적으로 정량화하는 것은 어려운 일이다.

따라서 각 항목의 계산식을 도출하기 위해서는

기존에 시행했던 사내의 유사한 테스트 사례 결과나 외부사례 등의 근거가 필요하다.

 

빠르게 시장 실험을 진행하고 그 결과를 회고하여 정량적인 경험으로 축적해야 하는 이유다.

<< 전략, 너 이거 왜 이렇게 했어! 이거 의미 없잖아! 할 때 변명할 말로써!

 

 

05 직접적인 성과비교

[직접적인 성과비교 - A/B 테스트]

만약 조금 더 운영 리소스에 여유가 있는 팀이라면

두 가지 이상의 솔루션을 선택해서 퍼포먼스를 비교하는 A/B 테스트를 진행해 볼 수도 있다.

A/B 테스팅은 장기적으로도 우리 비즈니스의 경험으로 쌓이기 때문에

앞으로의 프로모션을 기획할 떄 참고할 수 있는 좋은 baseline이 될 수도 있다.

 

EX. 우리 비즈니스에서는 신규 고객을 획득하는 비용보다

이탈 고객을 재활성화하는 비용이 더 효율적인 경향이 있다는 사실을 알게 된다면

솔루션 하나를 선택해야 할 때, 이탈 고객 재활성화 전략을 선택할 수 있다.

 

그리고 A/B 테스팅에는 통계적으로 유의미성을 확보하기 위해

충분히 큰 샘플 고객에게 테스트를 진행해야 한다.

(여러 샘플 사이즈 계산기를 이용할 수 있는데, 대표적인 Evan Miller의 샘플 사이즈 계산기 Sample Size Calculator (Evan’s Awesome A/B Tools) (evanmiller.org)도 좋다.)

Sample Size Calculator

 

 

(별도 영상으로 A/B 테스팅 준비!)

 

 

 

 

도움받은 글 ────

• 유튜브 곰사원은 곰대표 ; PM이 꼭 알아야 하는 데이터 분석 프레임워크 실전편