개요

• ‘So What?‘이라는 질문에 답할 수 있는 지표들을 정리했다면, 지표들끼리의 관계를 설정해봅시다.
• North Star Metric을 정하는 것도 중요하지만, 그것에 영향을 미치는 선행지표 설정은 더욱 중요합니다.
• Product 분석은 결국 고객 행동 분석과 같은 의미입니다.

Actionable, 그 이상

지난 포스팅에서는 Product-Led Growth에 대한 이야기를 간략히 꺼내보며, Lean&Agile한 실행이 올바른 방향으로 이뤄지기 위한 커뮤니케이션 방식들을 되짚어보는 시간들을 가졌습니다.

두 차례의 글을 통해 Vanity Metric 소거의 중요성을 파악했다면, 우리의 Actionable Metric이 올바르게 해석되고 실행력을 얻기 위한 방법론에 대해 살펴보겠습니다.

출처 — dorosh’s world

유효하지 않은 지표들을 소거했다면, ‘단일 지표의 실효성’ 보다도 ‘여러 지표 간의 연결관계’를 더 중점적으로 살펴보게 됩니다.

먼저 선행 지표 (Input Metrics) 와 후행 지표(Output Metrics)의 개념을 살펴보자면 아래와 같습니다.

선행 지표 - 우리 비즈니스에 어떤 일이 일어날지 예측하고, 진행상황을 추적하는 데 활용합니다
후행 지표 - 최종적인 결과값에 집중하며, 실험/업데이트 등으로 인한 성공여부를 판별합니다.

인과추론, 상관관계 분석과 같이 꾸준히 논의되는 개념들이 바로 이러한 접근에서 비롯되는 것이며, 지표 간의 관계 설정을 다르게 배치하는 것만으로도 판이한 의사결정이 일어날 수 있습니다.

예를 들면,

출처 — 브런치, 오차의 과학

계곡이나 해변에서 아이스크림 판매가 올라가는 시기에, 물놀이 사고가 증가하는 상황이 발생했다고 가정하자면

선행지표는 아이스크림 판매 증가 , 후행지표는 물놀이 사고 증가 입니다.

둘 사이에 인과관계가 있다고 생각하게 되면 보통 내리는 결론은 ‘아이스크림 판매를 중단한다’ 입니다. 반면, 상관관계를 확인하면서 보여주는 행동은 ‘두 가지 현상의 공통적인 원인, 배경을 찾는다’ ‘사고가 발생하기 시작하는 기온 상승 시점을 파악 후, 그 때 물놀이 사고를 방지할 수 있는 안전수칙/장치들을 마련한다’ 가 되겠습니다.

두 현상 사이의 인과관계가 뚜렷하다면 무언가를 중단하는 즉시, 특정 현상이 연쇄적으로 사라집니다. (어쩌면 이런 이유 때문에 A/B test가 반복되는 것일지도 모르겠습니다) 하지만, 상관성만 높고 인과관계가 없다면 두 현상은 동시성을 지니지 않습니다.

출처 — 브런치, 마케팅에 활용하는 통계 개념

마케터로서 상관관계 분석을 활용하는 것은 항상 딜레마로 다가옵니다.

도달/클릭/페이지뷰 - 매출 간의 상관 지수는 높기 때문에 공격적인 마케팅을 진행해야 할 것 같지만,
정작 광고 비용 - 매출 간의 상관 지수는 극히 낮기 때문에, 
'어떤 유형의 광고를 집행하자'는 결론은 대체로 그 예상을 충족시키지 못합니다.

도달/클릭을 유발하는 다양한 경로들을 고민하지 않게 되면, ‘일단 상관 지수가 높은 지표들을 늘려보자’ 고 결정하며 다시 무작위한 노출을 반복하게 되는 것이죠.

그렇기 때문에 상관관계 도출을 통한 후속 액션 수립보다는,

‘도달은 어떤 사람한테 됐을 때 효과가 좋았던 거야?’ ‘클릭은 어떤 영역을 클릭했을 때 구매 퍼널 마무리가 잘 된거야?’ ‘프로모션같은 단기적인 이슈가 함께 작용했던 것은 아닐까?’

와 같이 지표들에 영향을 미친 다른 요소들을 디테일하게 역추적하는 것이 경험적으로는 더 유익한 분석이었습니다.

‘So What?‘에 대한 대답, Impact Analysis

그렇다면, 올바른 의사결정을 위한 일종의 지름길이 있을지 생각도 해보게 됩니다. 인과/상관관계 여부를 골치아프게 따질 필요도 없이 사후 판별로 대체할 수 있으면서도, 프로덕트 내부의 변화가 미치는 영향을 계량화해서 보여줄 수 있는 방법!

2019년 말~2020년 초부터 Mixpanel과 Amplitude는 Impact Analysis라는 기능을 공개하며 구현된 Feature들의 향후 채택에 대한 영향 측정, 해석 및 신뢰도 계산에 대한 근거를 같이 제공해주고 있습니다.

출처 - Mixpanel

기존에 쌓여있는 데이터를 토대로 앱 업데이트에 따른 실행량의 변화, 특정 기능의 활용으로 인한 D-30 Retention 변화 및 가격 플랜 변경에 따른 구매량 변화 같이 매출과 직결되는 상황까지 기존의 데이터를 토대로 추론해볼 수 있는 방식입니다.

표의 Delta 항목이 양수를 기록하고, Confidence가 95% 이상이라면 실험 결과는 신뢰할 수 있고 우리는 목표에 근접할 수 있는 요인들을 비교적 빨리 알아낼 수 있게 됩니다. 인과적 영향에 대한 계산 기능도 함께 제공해주고 있기 때문에, 모델링에 대한 사후 검증의 염려도 덜 수 있습니다.

출처 - Amplitude

결국 비즈니스 목표에 부합하는 단 하나의 지표를 찾는다면, Impact Analysis의 반복을 통해 가장 높은 영향력을 지닌 선행지표를 찾는 것도 시간문제에 가까워지고 있다고 할 수 있습니다.

성과를 지향하되, OMTM에 매몰되지 않는 방법

Impact Analysis까지 있는데 다시 한번 조심해야 한다고 말을 하는 이유는, 결국 Context에 대한 이해가 함께 수반되어야 하기 때문입니다.

출처 - Thinker-Practitioner

이를테면, engagement를 늘려주는 feature가 무엇인지 검증을 했다 하더라도 우리의 업무 루틴상 단순하게 환원해버릴 여지가 있는 상황이 벌어지기 때문입니다.

• ‘컨텐츠를 큐레이션해주는 페이지가 하나 만들어졌다’
• ‘이 페이지로 인한 참여가 활성화됐다’
• ‘따라서 이 페이지를 사용자들에게 push해줄 수 있는 장치들을 여러 방식으로 만들면 retention도 개선될 것이다’

실험을 통해 계량적으로 증명이 된 것이라 하더라도, 그러한 장치들 안에서 고객이 느낀 가치 & 경험을 함께 생각하지 않는다면 우린 무작정 e-dm/SMS/Push를 많이 하는 루틴만 설계하게 될 가능성이 매우 높습니다.

Vanity Metric과 Actionable Metric을 구분하는 가장 큰 요인 중 하나가 Context의 유무라는 점을 생각하면, 아이러니하게도 또다시 길을 잃을 염려가 남아있다는 것이죠.

Context를 파악하며 Metric의 관계를 설계하려면, ‘명사’ 보다는 ‘동사’의 형태로 프로덕트의 생태계를 정의해보는 것이 좋습니다.

출처 - Amplitude

이렇게 함으로써, ‘우리가 취하는 Action들’이 ‘누구에게 어떤 영향을 주고자 하는 것인지, 이것이 우리의 핵심 전략과 어떻게 이어지는지를 모두가 기억하면서 업무를 수행하는 데에 도움을 줍니다. 특히 North Star를 찾을 때, 오히려 미래 비즈니스 결과의 선행 지표를 찾는 것을 매우 중요하게 여기고 있습니다.

Output Metric을 설정하는 것은 중요하되, 오로지 그것에만 집중하다보면 생기는 문제는 크게 2가지입니다.

1. 프로덕트에 대한 경험 컨디션 관리에 소홀해진다
2. MRR을 올리려 노력하지만, 구매/구독유지에 한해서 모니터링하다보면 반복 접속, 반복 이용률을 놓치게 된다

출처 - Reforge

그래서, Engage를 위한 Input-output metric / Retention을 위한 Input-oupt metric / Monetization을 위한 Input-output metric 설정을 시도하는 방법을 취하기도 합니다. (Output Metric은 잘 바뀌지 않지만 Input Metric은 주기적으로 변경)

3가지 차원의 균형을 맞추지 않은 상태에서 OMTM을 설정해버리게 되면

1. 수익성을 올리기 위해 인앱 광고 영역을 공격적으로 확장했다가, 되려 사람들의 뉴스피드 이용률이 급감해서 조회 자체를 하지 않는 상황
2. 외부 공유를 활성화시키기 위해 repost 높은 게시물만 노출시키다가, 신규 post의 노출이 떨어지며 사용자의 피로도 누적으로 인한 이탈로 이어지는 상황

을 전혀 고려하지 않는 상태가 지속될 수 있습니다.

Input Metric - Output Metric의 짝을 맞추는 것은 우리가 할 수 있는 일이지만, Input Metric의 Trigger는 결국 고객의 손에 달려있습니다.

Marty Cagan 은 비록 PM에 대한 평가, Product Team과 Feature Team의 구분 기준을 찾기 위해 Team Mission을 강조했습니다. PM만의 영역이라고 생각될 소지도 많지만, 분석을 위한 데이터 지식은 결국 문제를 해결하는 Product로의 탈바꿈이라는 Output 을 이끌어내기 위해 우리에게 요구되는 Input이라고 할 수 있겠습니다. 그리고 그 분석을 통해 우리가 갖추게 되는 Product 지식의 최상위엔 결국 User & Customer knowledge가 자리잡고 있습니다.

우리가 설계한 Feature나 Campaign의 흐름은 결국 고객의 인식/행동에 대한 반영인 것이고, ‘일단 만들었는데 실제 고객은 이걸 어떻게 쓰는지 잘 모르겠다’ 는 의문이 조금이라도 든다면 우리에게 필요한 것은 시뮬레이션이 아닙니다.

Product의 근간 그 자체는 살아있는 데이터이고, 당장 오피스를 뛰쳐나가 고객을 만나는 것으로만 해결이 가능할 것입니다.

짧은 글들이었지만, 고객이 원하는 Context와 핵심가치를 담아내고 있는 것들에 집중해야 함을 환기시켜 본업에서의 프로젝트도 실질 Revenue를 QoQ 50% 성장시키는 결과를 함께 얻어볼 수 있었습니다.

그만큼 겉보기엔 별거 아닐 수 있는 이야기들이지만, 막상 나의 하루를 돌이켜보면 실천하지 못하고 있던 작은 습관들이 많았습니다. 제가 누린 Impact를 여러분들도 함께 경험할 수 있기를 바라며 이만 줄입니다 :)