[그로스 해킹] 지표와 A/B 테스트

04. 지표

1. 지표 활용하기

1) 지표의 속성 이해하기

지표를 속성에 따라 분류하면 스톡(Stock) 형태의 지표와 플로(Flow) 형태의 지표로 구분할 수 있다. 스톡은 저량 지표라고도 하는데, 간단히 말하면 특정 시점의 스냅숏(snapshot)에 해당하는 지표를 의미한다. 즉, 시작과 끝이라는 갠며이 없고 특정한 찰나(일반적으로는 현재 시점)에 관찰할 수 있는 누적된 값이다.

스톡이 저량이라면 반대로 플로는 유량이라고 할 수 있다. 플로는 시작과 끝에 대한 시간 범위가 존재하며, 일정한 시간 동안의 변화량을 나타내는 지표다.

일반적으로는 플로 형태의 지표가 스톡 지표에 비해 더 많은 정보를 가지고 있다.

핵심 지표를 선정하거나 그로스 실험의 성과를 측정할 때는 목표로 하는 지표가 스톡인지 플로인지를 정확히 구분해서 활용해야 한다. 지표의 속성에 따라 모니터링 방식이나 대시보드 설계 등이 전혀 달라질 수 있기 때문이다.

 

2) 지표를 명확하게 정의하기

‘우리 서비스의 MAU가 얼마인가요?’

 

데이터 분석팀에서 가장 난감했던 경우는 ‘모호한’지표를 확인해 달라는 요청을 받는 것이다. MAU를 묻는 질문도 ‘난감한’ 질문 중 하나에 속한다. MAU(Monthly Active User)의 개념적 정의는 명확하지만 실제로 MAU를 측정하는 구체적인 조작적 정의가 명확하지 않다면 어떤 기준으로 MAU라는 숫자를 구해야 하는지가 불분명하기 때문이다.

이 단계에서 필요한 것은 원칙을 세우는 것이다.

즉, 전사적으로 지표를 어떤 방식으로 측정해서 관리할지에 대한 공감대를 형성하고 모든 구성원이 동의할 수 있는 명확한 측정 기준을 정의해야 한다.

지표를 기반으로 성장 실험을 할 때는 해당 지표를 어떻게 정의하고 측정할 것인가를 반드시 짚고 넘어가야 한다. 모호한 지표는 모호한 액션을 이끌 수밖에 없기 때문이다.

 

3) 허무 지표에 빠지지 않기

좋은 지표가 가져야 할 조건 중 하나는 그 지표를 바탕으로 행동할 수 있어야 한다(actionalble)는 것이다.

반대로 행동을 이끌어내지 못하는 의미 없는 지표는 허무 지표(Vanity metric) 혹은 허상 지표라고 한다. 단순히 시간이 흐르면서 자연스럽게 높아지는 지표, 예를 들어 누적 다운로드 수와 누적 앱 설치와 같은 지표를 뜻한다.

일반적인 사례는 ‘주간 업무 보고’다. 많은 조직에서 주간 업무 보고 문서를 정리하기 위해 많은 시간과 노력을 투자하지만 단순히 ‘우리가 이번주에 놀지 않았다’는 것을 보여 주기 위해 작성하는 식이다.

 

4) 전체 관점에서의 최적화

지표를 활용할 때 또 한 가지 주의해야 하는 점은 지표를 개선하기 위한 행동이 부분 최적화가 아닌 전체 관점에서의 최적화에 초점을 맞춰야 한다는 점이다. 예시로 특정 페이지의 CTR에만 집중하다가 전체 퍼널에서의 전환율이 떨어지거나 퍼포먼스 광고의 CPC(Cost Per Click)에만 집중하다가 전체 광고의 성과가 낮아지는 것 등을 들 수 있다.

결국 마케팅의 성과를 전체 관점에서 측정하고 최적화하려면 한두 개의 지표 움직임으로 판단하는 것이 아니라 해당 마케팅을 통해 우리 서비스의 신규 고객 유치나 매출 상승에 어떤 효과가 있었는지를 여러 시나리오와 지표를 바탕으로 종합적으로 판단하고 의사결정하는 것이 필요하다.

 

5) 심슨 패러독스(Simpson’s Paradox)

코호트 분석, A/B 테스트, 퍼널 분석 등 데이터를 통해 유의미한 인사이트를 찾아내는 방법에는 공통점이 있다. 바로 데이터를 ‘쪼개서’ 살펴본다는 점이다. 전체 데이터를 놓고 보면 잘 드러나지 않는 특성들이 쪼개진 상태에서는 명확하게 드러나는 경우가 많은데 이처럼 로 데이터를 분석 과정에서 어떤 식으로 가공하느냐에 따라 데이터에서 얻는 인사이트가 완전히 달라질 수 있다.

통계학에서 ‘심슨 패러독스’라고 부르는 개념이 있는데 쪼개진 데이터에서 성립하는 관계가 합쳐진 데이터에서는 반대로 나타나는 현상을 말한다.

예를 들어 1973년 UC 버클리 입시 결과를 보면 알 수 있다. 이하 생략

 

6) 대푯값을 사용할 때 주의해야 할 점

분석 대상 데이터 세트에 아웃라이어가 있거나 분포를 알 수 없는 경우라면 중앙값(median)을 대푯값으로 사용하는 것을 적극적으로 고려해 볼 필요가 있다. 중앙값은 평균보다 훨씬 더 안정적(robust)이며, 몇 개의 아웃라이어가 있다고 해도 흔들리지 않는다.

데이터의 대푯값을 정하기에 앞서 그 분포를 확인하는 것은 굉장히 중요하다. 실제로 많은 사람들이 데이터 시각화는 모든 분석이 다 끝나고 예쁜 보고서를 만들 때 필요한 것이라고 오해하는 경우가 많은데, 실제 데이터 시각화는 분석을 막 시작하는 시점에 해당 데이터셋이 어떻게 구성돼 있는지 확인하는 탐색적 분석 과정에서 훨씬 더 유용하게 활용된다.

 

7) 생존자 편향(survivorship bias) 피하기

데이터를 분석하기에 앞서 꼭 체크해야 하는 점은 ‘수집된 데이터가 분석하려는 목적에 적합한가?’다. 데이터 분석 분야에서 흔히 사용되는 용어 가운데 ‘Garbage In Garbage Out’이라는 말이 있는데, 말 그대로 잘못된 데이터를 가지고 분석한 결과는 신뢰할 수 없다는 의미다.

잘못된 데이터 활용의 대표적인 사례는 생존자 편향(Survivorship bias)이다. 이하 생략

분석 목표에 맞는 데이터를 신중하게 수집하고 가공하는 단계가 잘 진행되지 않으면 그다음에 진행하는 어떤 고도화된 알고리즘이나 분석 방법도 의미가 없다는 점을 반드시 기억하자.

 

2. OMTM(One Metric That Matters)

1) 지금 가장 중요한 지표는 무엇인가?

OMTM(One Metric That Matters)

지표를 잘 활용하기 위해 가장 우선적으로 고려해야 하는 것은 ‘지금 가장 중요한 지표가 무엇인가?’라는 질문에 답하는 것이다.

가장 중요한 지표는 시기에 따라 달라질 수 있다. 외부 환경이나 서비스 성장 단계, 내부 역량, 사용자들의 서비스 이용 패턴 등을 고려했을 때 집중해야 하는 지표는 매번 다를 수 있다. 그로스 해킹에서는 지금 가장 중요한 지표를 지칭하는 용어로 OMTM(One Metric That Matters)이라는 용어를 사용한다. 이를 북극성 지표(NSM, North Star Metric)라고 부르기도 하는데, 의미는 동일하다.

OMTM의 가치는 구성원들이 바라보는 방향성을 일치시키고 자원을 집중하는 데서 나온다.

OMTM을 정의하기 위한 질문

가장 중요한 핵심 지표를 정하기 위해서는 현재 우리 서비스의 상태나 목표, 서비스 성장 단계 등의 요소를 종합적으로 고려해야 한다.

OMTM을 설정할 때 흔히 하는 실수 중 하나는 매출을 OMTM으로 정하는 것이다. 매출을 OMTM으로 정하는 것은 크게 두 가지 이유에서 부적절한데 우선, 많은 경우 매출은 서비스의 핵심 가치가 사용장에게 잘 전달됐는지와 비례해서 증가하지 않는다. 즉, 매출이 늘어나고 줄어드는 것은 서비스의 성장과 항상 일치하지 않는다.

두 번째 이유는 매출이 완벽한 후행지표라는 점이다. 매출은 어떤 원인에 의해 결과적으로 드러나는 성적표에 가깝다. 즉, 매출이 오르거나 떨어진다고 해서 그것을 바탕으로 무언가를 할 수 있는 것은 아니다. OMTM은 이를 바탕으로 의사결정을 하고 행동할 수 있는(actionable) 지표로 정의해야 한다는 점을 기억하자.

 

2) OMTM & KPI & OKR

OMTM vs. KPI

OMTM은 성장을 목표로 하는 지표다. 중요한 것은 OMTM을 바탕으로 어떤 의사결정을 하고 이에 따라 전사적인 리소스를 어떻게 배분할 것인가를 결정하는 것이다.

반면 KPI는 일반적으로 평가를 위해 활용하는 지표다.

모든 부서가 KPI(Key Performance Index)를 달성했다면 서비스가 고속 성장하고 있어야 할 것 같은데 실제로는 그렇지 않은 경우를 굉장히 많이 목격한다. 반면 OMTM으로 설정한 지표가 원하는 방향으로 움직이고 있다면 그것은 그 서비스가 올바른 방향으로 성장하고 있음을 의미한다.

그런 의미에서 OMTM은 그 자체로 서비스가 진짜 잘 되고 있는지를 알려주는 중요한 지표라고 할 수 있다.

OMTM vs. OKR

OKR(Objectives & Key Results)은 구글이 도입한 목표 관리 체계로 널리 알려져 있다. OKR은 3~5개의 목표(Objectives)와 목표당 3~5개 정도의 핵심 결과(Key Results)로 구성된다.

OKR과 OMTM은 비슷한 점이 많다. 굳이 구분하자면 OMTM은 중요한 지표 그 자체를 강조하는 것에 조금 더 초점이 맞춰진 반면, OKR은 그 지표를 개선하기 위한 구체적인 액션 플랜에 가깝다는 차이 정도일 것이다.

적절한 목표를 정의하고 모두가 한 마음으로 여기에 집중하는 것은 성장에 있어서 가장 기본적인 요소다.

 

05. 그로스 해킹 시작부터 성장 실험까지

1. 그로스해킹 시작하기

1) 작은 회사에서 그로스 해킹을 할 수 있을까?

우리는 아직 초기 단계라서 그로스 해킹을 할 리소스가 없어요.

 

그로스 해킹은 개발 조직이 탄탄한 큰 회사에서 하는 거 아닌가요?

우리 회사에는 아직 전문적인 그로스 해커가 없어요.

 

그렇다면 그로스 해킹은 모든 리소스가 잘 갖춰진 큰 회사에서만 할 수 있을까? 당연히 그렇지 않다. 누구나 적용할 수 있는 그로스 해킹의 시작에 대해 살펴보자.

시작부터 한꺼번에 많은 리소스를 사용할 수 없는 환경이라면 다음과 같이 한 단계씩 차근차근 실천해가는 것을 권장한다.

1단계: 데이터를 활용할 수 있는 업무 환경 만들기

2단계: 데이터 파이프라인 구축하기

3단계: 데이터 활용을 위한 역량과 문화 갖추기

4단계: 성장 실험

 

2) 데이터를 활용할 수 있는 업무 환경 만들기

‘우리 회사는 데이터의 중요성을 모든 구성원이 공감하고 있어요’라고 이야기하는 회사는 많다. 하지만 ‘데이터의 중요성을 공감한다’와 ‘데이터를 기반으로 업무를 진행하는 프로세스와 역량을 갖추고 있다’는 전혀 다른 차원의 이야기다.

최근에 빠르게 성장하고 있는 클라우드 분석 환경, ETL 자동화 서비스, BI 서비스를 잘 조합하면 최소한의 엔지니어링 리소스만으로도 데이터를 활용할 수 있는 업무 환경을 비교적 손쉽게 구축할 수 있다.

 

클라우드 분석 환경

하둡, 스파크 등 널리 알려진 분산처리 시스템이 있지만 막상 분석 환경을 직접 구축하다 보면 여러 대의 서버와 오픈소스 스택을 관리하는 과정에서 갖가지 난관과 장애를 만나게 된다.

최근에는 클라우드 분석 환경이 눈부시게 발전하면서 인프라 구축을 위한 엔지니어링이 크게 간소화됐다. 아마존의 EMR(Elastic MapReduce), 구글의 GCP(Google Cloud Platform), 마이크로소프트의 Azure 등이 대표적인 클라우드 플랫폼으로 알려져 있다.

아마존의 레드시프트(Redshift), 구글 빅쿼리(BigQuery) 등 클라우드 데이터베이스의 성능도 훌륭한 편이다.

 

ETL 자동화 서비스

데이터 분석을 하기 위해서는 ETL(Extract, Transform, Load)이라는 프로세스가 선행돼야 한다. Fivetran, Stitch 등의 ETL 자동화 서비스는 수십 가지의 광고플랫폼, 어트리뷰션, CRM, 기타 데이터 분석 서비스와의 연동을 통해 필요한 형태로 데이터를 적재하고 전처리하는 과정을 굉장히 쉽고 편리하게 구축해 준다.

 

BI(Business Intelligence) 서비스

최근에는 태블로(Tableau)나 구글 데이터 스튜디오(Google Data Studio) 등의 데이터 시각화 및 대시보드 구축 서비스가 빠르게 발전하고 있고, 수퍼셋(Superset)이나 리대시(Redash) 등 오픈소스를 기반으로 한 BI(Business Intelligence) 서비스도 속속 등장하고 있다.

 

2. 데이터 파이프라인 만들기

데이터 파이프라인이 잘 구축돼 있다면 어떤 것들을 할 수 있을까? 대표적으로 사용자 행동 기반의 로그 분석을 들 수 있다. 실제로 구글 애널리틱스나 앰플리튜드(Amplitude) 등의 데이터 분석 툴을 잘 활용하려면 행동 로그 분석을 위한 파이프라인이 잘 구축돼 있어야 한다.

 

1) 행동 로그 분석을 위한 데이터 파이프라인

사용자가 남기는 로그는 서비스 로그와 행동 로그로 구분된다.

서비스 로그는 트랜잭션(transaction)의 결과를 기록하는 로그다. 반면 행동 로그는 트랜잭션에 이르기까지 사용자가 서비스에서 하는 하나하나의 액션에 대한 로그를 의미한다.

회원가입이나 구매 등을 기록하는 서비스 로그는 기본적인 서비스 운영을 위해 필수적으로 관리해야 하므로 이 데이터를 쌓고 활용하는 데는 큰 문제가 없다.

반면 행동 로그의 경우 데이터의 양도 훨씬 많고 설계하는 과정에서의 자유도도 높아서 수집이나 활용이 상대적으로 까다로운 편이다.

 

2) 이벤트와 속성

행동 로그 설계의 핵심은 이벤트의 속성(property)을 어떤 수준으로 함께 남길 것인가를 정의하는 부분이다.

이벤트 속성은 특정 이벤트가 발생했을 때 함께 남길 수 있는 세부정보라고 생각하면 된다.

 

3) 행동 로그 설계하고 적재하기

이벤트를 어떤 기준으로 쌓아서 볼 것인지 정의하는 문서를 이벤트 스키마 설계서라고 한다.

이벤트 스키마 설계서에는 어떤 화면의 어떤 이벤트를 기록할지, 그 이벤트가 발생하는 정확한 조건이 무엇인지, 이벤트와 함께 기록해야 하는 속성에는 어떤 것이 있는지, 각 속성의 데이터 타입은 어떤 타입으로 기록해야 하는지, 그리고 해당 이벤트가 처음 기록되기 시작한 시점은 언제인지 등을 포함해야 한다.

수집하는 이벤트의 수가 많아지면 이후 QA(Quality Assurance)와 유지보수가 그만큼 힘들어진다. 많은 회사가 겪는 문제는 이벤트 로그가 없어서가 아니라 이벤트 로그가 있지만 필요한 내용이 없거나 데이터 정합성을 신뢰할 수 없기 때문에 발생한다.

발생하는 모든 이벤트를 기록해야 한다는 생각을 버리고 분석에 필요한 이벤트를 정확하게 적재하는 것이 이 단계의 핵심이다.

 

3. 데이터 활용을 위한 역량과 문화 갖추기

BI 서비스를 이용하게 사내 구성원들을 독려하는 것과 사내 교육이나 스터디를 진행해보는 것도 좋은 방법이다.

데이터 활용과 관련된 사내 교육을 진행할 때 두 가지 유의할 점은 첫 번째, 꾸준히 정기적으로 진행해야 한다는 점이고 두번째는 교육을 통해 배운 지식들을 실제 업무에 바로바로 적용할 수 있는 환경을 만들어 주고 이를 활용하는 것을 독려해야 한다.

 

4. 성장 실험: A/B 테스트

1) A/B 테스트란?

A/B 테스트란 두 개의 변형 A와 B를 사용하는 종합 대조 실험(controlled experiment)으로, 통계적 가설 검정 또는 2-표본 가설 검정의 한 형태다.

간단해보이지만 실제로 A/B 테스트를 잘 진행하려면 생각보다 고려해야 할 점이 많다.

 

2) A/B 테스트 설계하기

A/B 테스트를 설계하려면 우선 다음과 같은 기초적인 개념들을 이해할 필요가 있다.

 

가설

A/B 테스트의 출발점은 가설이다. A/B 테스트가 의미 있으려면 실험을 통해 무엇을 확인하고 싶은지가 명확해야 한다. (’10% 더 높을 것이다’처럼 구체적인 목표 수준을 포함하는 것도 좋다. 실험에 필요한 샘플 크기를 구하려면 가설 수립 단계에서 목표 수준을 정해야 한다.)

 

실험 집단/통제 집단

전체 모수 중 실험 조건에 할당되는 사용자들을 어떤 기준으로 구분하고, 어떤 비율로 할당할 것인지 정의해야 한다. 무엇보다 중요한 절차는 통제 변수 관리와 엄격한 기준에 따른 샘플링이다.

 

독립 변수

설명 변수 또는 예측 변수라고도 한다. 인과 관계에서 원인이 되는 변수, 즉 종속 변수에 영향을 줄 거라고 기대되는 변수다.

 

종속 변수

독립 변수에 의해 영향을 받을 것으로 기대되는 변수다. 인과 관계에서 결과가 되는 변수로서, 일반적으로는 종속 변수의 변화량에 따라 실험의 성과를 판별할 수 있다.

종속 변수는 당연히 측정 가능해야 하며, 구체적으로 어떤 기준으로 측정할 것인지에 대한 조작적 정의가 사전에 명확하게 돼 있어야 한다.

 

통제 변수

실험 결과에 영향을 미칠 수 있기 때문에 실험 집단/통제 집단 모두에서 동등한 조건을 가져야 하는 변수를 의미한다. 즉, 독립 변수가 아니지만 종속 변수에 영향을 미칠 수 있는 제3의 변수라고 볼 수 있다. A/B 테스트 경험이 풍부하지 않으면 보통 통제 변수를 정의할 때 어려움을 겪는다.

(정확히 말하면, 통제 변수를 제대로 설정하지 않아서 실험 집단과 통제 집단을 잘못 나누는 경우가 흔히 발생한다.)

사실 A/B 테스트의 성패는 통제 변수를 얼마나 잘 관리하느냐에 달린 경우가 많다.

 

샘플 크기

가설 검증에 필요한 실험 참가자의 숫자를 의미한다. 통계적 유의도를 확보하기 위한 숫자를 고려해서 실험 전에 미리 정해야 한다.

 

실험 기간

샘플 크기를 고려했을 때 가설 검증을 위한 데이터를 수집하는 데 필요한 기간을 정의해야 한다. 특별한 이유가 없다면 진행 중인 실험을 임의로 중단하고 중간에 결론을 내려서는 안 된다.

3) A/B 테스트 설계 시 유의사항

A/B 테스트 설계의 성패는 실험 집단과 통제 집단을 적절하게 나누고 통제 변수 관리를 얼마나 잘 했느냐에 달려 있다.

 

실험 집단과 통제 집단 샘플링

실험 집단을 선별할 때 공정한 샘플링을 위해 랜덤 추출을 생각하기 쉬운데, 많은 사람들이 랜덤 추출과 편의 추출을 혼동한다.

랜덤 추출은 통제 변수가 잘 관리된 것을 전제로 모든 표본이 동일한 확률을 가진 상태에서 뽑는 무작위 추출을 의미한다. 즉, 통제 변수 관리가 잘 되지 않은 상태라면 랜덤 추출이라는 말을 써서는 안 된다.

제3의 변수가 종속 변수에 영향을 미칠 수 있다고 판단되면 이를 통제 변수에 포함해서 샘플링 과정에 반영함으로써 종속 변수에 미치는 영향을 차단해야 한다.

이처럼 A/B 테스트를 진행하는 과정에서 회원 번호나 결제 번호 등을 홀/짝으로 나눈 것으로 실험 집단을 랜덤하게 구분했다고 오해하는 경우가 많은데, 통제 변수를 깊이 고민하지 않은 상태에서 단순히 홀/짝 구분을 한다고 해서 랜덤 샘플링이 잘 됐다고 볼 수는 없다.

테스트하고 싶은 독립 변수 외에 종속 변수에 영향을 미치는 나머지 요소들을 얼마나 잘 식별하고 통제하느냐가 A/B 테스트를 설계하는 과정에서 대단히 중요하다는 점을 꼭 기억하자.

 

순차 테스트와 동시 테스트

순차 테스트는 A 조건으로 일정 기간 테스트를 한 다음, B 조건으로 바꿔서 연이어 테스트를 진행하고 이 두 가지 조건의 결과를 비교하는 식으로 진행하는 테스트다. 엄밀히 이야기하면 순차 테스트는 A/B 테스트가 아니다. 순차 테스트의 가장 큰 문제는 제대로 된 통제 변수 관리를 할 수 없다는 점이다. 실험 기간이 달라짐에 따라 기대하지 못한 외부 효과가 개입할 여지가 있기 때문이다.

 

샘플 크기

A/B 테스트를 진행하는 과정에서 유의해야 하는 점 중 하나는 실험을 시작하기 전에 샘플 크기를 미리 정해야 한다는 점이다. 샘플 크기에 대한 고려 없이 실험을 진행하면 이후에 설명할 엿보기 & 조기 중지의 함정에 빠질 수 있다. 샘플 크기 계산기는 온라인 상에서 쉽게 찾아볼 수 있는데, 일반적으로 검증하고자 하는 가설, 검정력, 유의수준 등 실험 설계 조건을 입력하면 실험에 필요한 샘플 수를 계산해준다.

 

4) A/B 테스트 결과를 분석하는 방법

p-value에 대한 이해

실험의 유의 수준을 판단하기 위한 통계학에서 사용하는 기준은 p값이다.

물론 p값만 체크한다고 해서 실험 결과를 정확하게 분석할 수 있는 것은 아니다. 우선 많은 사람들이 p값의 의미를 잘못 이해하고 있다는 점에 주의하자. (95% 신뢰수준에서 A 조건의 클릭율이 B 조건의 클릭율보다 유의미하게 높다 → A 조건의 클릭율이 B 조건의 클릭율보다 높을 확률이 95%라는 의미로 해석하면 절대 안 된다! 앞의 두 문장은 서로 전혀 다른 의미를 갖는다.)

p값은 귀무가설 하에서 관찰된 검정통계량만큼의 극단적인 값이 관찰될 확률을 의미한다.

 

A/B 테스트 계산기

복잡한 통계 패키지를 사용하지 않더라도 여러 사이트에서 제공하는 A/B 테스트 계산기를 활용하면 A/B 테스트의 통계적 유의성을 간단하게 확인할 수 있다.

 

테스트 비용과 효과 크기

p값이 A/B 테스트의 결과를 판단하는 단 하나의 절대적인 기준은 아니다. 애초에 표본 크기가 커지면 p값은 낮아지는 특성이 있기 때문에 실험 집단의 규모가 매우 크다면 p값이 가지는 의미가 왜곡될 수 있기 때문이다.

• 통제조건(조건 A) → 구매 전환율 3%
• 실험조건(조건 B) → 구매 전환율 3.5%
• p < .01, 즉 99% 유의수준에서 통계적으로 의미 있는 결과

p값이 0.01보다 낮은 결과가 나왔으니 엄청나게 인상적인 실험일까?

이 실험을 진행한 서비스의 DAU가 1천 명, ARPPU가 1만 원이라고 가정해 보자. 이 경우 조건 B에 따라 구매전환율이 0.5% 개선되면 일 5만 원(1,000 x 0.005 x 10,000)의 추가 매출이발생한다. 반면 DAU가 100만 명, ARPPU가 1만 원인 서비스라면 똑같은 실험을 통해 일 5,000만 원(1,000,000 x 0.005 x 10,000)의 추가 매출이 발생할 수 있다. 즉, A/B 테스트의 가치는 단순히 테스트 자체의 결과로 인해 얻어지는 p값 외에 실험이 실질적으로 효과를 미치는 크기나 영향력을 고려해서 판단해야 한다.

 

5) A/B 테스트 진행 시 주의사항

대표적으로 하는 A/B 테스트의 실수는 다음과 같다.

 

무가설

A/B 테스트의 출발점은 가설이며, 통제 집단 관리나 독립 변수와 종속 변수 정의 등 모든 실험 설계는 가설에 근거해서 진행된다는 점을 꼭 기억하자.

 

통제 변수 관리 실패

A/B 테스트가 실패하는 가장 큰 원인은 통제 변수를 식별하지 못했거나 찾아낸 통제 변수를 잘 관리하지 못하는 것이다. 가설에서 정의한 독립 변수 외에 종속 변수에 영향을 미칠 수 있는 다른 변수가 없는지 신중하게 판단하고 실험 집단 샘플링을 진행해야 한다.

 

단순 평균 비교

A/B 테스트에 따른 종속 변수를 단순히 평균 비교하면 우연에 의한 결과와 실제 효과를 혼동할 수 있다. A/B 테스트 결과는 종속 변수의 평균 비교 외에도 분포, 유의수준, 효과 크기 등을 종합적으로 고려해서 판단해야 한다.

 

엿보기 + 조기 중지

A/B 테스트에서의 엿보기와 조기 중지(peeking)란 실험을 진행하는 동안 계속 p값의 변화를 살펴보고 있다가 p값이 0.05 이하로 내려가는 시점에 갑자기 실험을 중단해 버리는 것을 의미한다. 통계적으로는 유의미한 차이가 있는 것처럼 보이겠지만 이는 명백한 어뷰징 행위다. 특히 실험 초기 p값이 안정화되지 않은 시점에 테스트를 조기 중지하면 실제로는 없는 효과를 있는 것처럼 판단할 수 있다.

 

시간의 흐름에 따른 차이를 살펴보지 않는 것

A/B 테스트 기간 전체에 대한 종속 변수 평균을 비교하는 것도 중요하지만 시간의 흐름에 따라 종속 변수가 어떻게 변화했는지를 보는 것도 굉장히 중요하다. 실제로 실험 초기에는 조건별 차이가 나는 것 같다가 후반부에는 조건별 차이가 없는 경우, 혹은 그 반대의 경우가 종종 발생한다.

이 경우 실험 집단 샘플링에 실패했거나, 특정 시점에 기능 오류가 발생했거나, 혹은 데이터 수집 과정에서의 오류일 수 있으므로 실험 과정을 시간의 흐름에 따라 꼼꼼하게 재확인하는 것이 필요하다.

 

과거의 A/B 테스트 경험을 지나치게 신뢰하는 것

잘 설계한 A/B 테스트를 통해 의미 있는 결과가 나왔다고 해서 ‘앞으로도 계속 그 결과가 유효할 것이다’라고 보장할 수는 없다. 시장의 변화, 계절의 변화 등 다양한 요인에 의해 A/B 테스트 결과는 얼마든지 달라질 수 있다. 한 번 진행된 A/B 테스트 결과가 만고불변의 진리라고 믿어서는 안 된다. 어제의 최적화는 오늘의 레거시일 수 있다는 점을 기억하자.

 

국지적 최적화의 함정

A/B 테스트는 기본적으로 주어진 조건 안에서 성과를 비교하는 실험이다. A/B 테스트는 A와 B라는 조건 중 B가 더 좋다는 점을 알려줄 수 있지만 B가 모든 경우에서 가장 좋은 최적의 조건이라는 것을 말하지는 않는다. 즉, 애초에 A와 B라는 조건 자체가 최선이 아니었다면 전역 최적화(Golobal Optimization)가 아닌 국지적 최적화(Local Optimization)를 찾는 실험이라는 점을 유의해야 한다.

 

06. 그로스 조직과 업무 프로세스

1. 그로스 조직 만들기

1) 그로스 해커는 없다

그로스 해킹은 다양한 직군의 사람들이 각자의 전문성을 발휘하면서 협업하는 프로젝트성 업무에 가깝다.

우리에게는 그로스 해커가 아닌 그로스 해킹 팀이 필요하다.

 

2) 그로스 조직의 목표

그로스 해킹 팀은 일반적으로 두 가지 목표를 갖는다. 가장 중요한 목표는 핵심 지표를 개선하는 것이다. 다음으로 가져야 할 목표는 그로스 조직이 회사에 성장 DNA를 전파하는 조직이 돼야 한다는 점이다.

 

3) 그로스 조직 구성원

일반적으로 그로스 해킹 조직은 다음과 같이 직군별 스페셜리스트의 집단으로 구성하는 것을 권장한다.

• 그로스 PM(Growth PM)
• 그로스 엔지니어(Growth Engineer)
• 그로스 마케터(Growth Marketer)
• 그로스 디자이너(Growth Designer)
• 그로스 데이터 분석가(Growth Data Analyst)

하지만 현실적으로 이 모든 직군으로 구성된 팀을 만들 수 있는 회사는 많지 않다. 그로스 조직을 만들기 위한 최소한의 요건은 성장 실험을 할 수 있는 멤버를 보유한 팀이라고 생각된다.

즉, 1) 실험을 설계하고 2) 실험 환경을 구축하고 3) 실험 결과 데이터를 분석할 수 있는 멤버를 보유한 조직이면 된다.

UX 디자이너로 불리길 원한다면 단순한 마인드셋 정도가 아니라 실제로 사용자를 중심에 놓고 일하는 프로세스와 사용자 데이터를 획득하고 분석해서 업무에 활용할 수 있는 역량을 갖춰야 한다.

마찬가지로 직군에 ‘그로스’를 붙이려면 그에 맞게 일하는 프로세스와 역량을 갖춰야 한다는 점을 기억하자.

 

4) 그로스 조직 구조

전사적인 관점에서 그로스 조직을 어떻게 구성할 수 있을까? 이를 위해서는 리포팅 라인, 전담 인력 구성, 협업 구조에 대한 전사 관점에서의 의사결정이 필요하다.

• 리포팅 라인: 그로스 조직의 상위 의사결정권자가 누구인가?
• 전담 인력 구성: 그로스 업무만 전담해서 진행하는 인력을 얼마나 배치할 것인가?
• 협업 구조: 사내 다른 조직과 어떤 구조로 커뮤니케이션하는가?

크로스펑셔널 팀 구조(Cross Functional Team Structure)

크로스펑셔널 팀 구조에서는 기능 조직에 소속된 각 직군별 담당자들이 모여서 그로스 해킹을 하는 목적 조직을 구성하게 된다. 이 구조에서는 그로스 조직의 실질적인 그로스 PM이 맡은 역할이 매우 중요하다.

 

독립 팀 구조(Independent Team Structure)

독립 팀 구조는 기존의 기능 조직과는 별개로 독립된 그로스 조직을 새롭게 만드는 형태로 이뤄진다. 전사적으로 그로스 조직에 크게 힘을 싣는 구조라고 볼 수 있다. 그로스 조직에 대한 CEO의 의지가 강력하거나 그로스 조직을 이끌 임원이 새롭게 영입되는 경우 이런 조직 구조를 가져가는 경우가 많다.

 

복합 구조(Mixed Structure)

복합 구조는 크로스펑셔널 팀 구조와 독립 팀 구조의 장점과 단점을 절충한 형태다. 별도 조직을 구성하지만 일부 인원은 파견이나 겸직 발령 형태로 기존의 기능 조직 형태를 유지한다. 복합 구조는 그로스 조직에 어느 정도 힘을 실으면서도 동시에 기존 조직과의 커뮤니케이션 복잡도를 크게 높이지 않는 절충안이라고 볼 수 있다.

 

2. 그로스 조직이 일하는 방식

3. 성장을 위한 문화

1) 그로스는 톱-다운 (Top-down)

2) 제품개발(Production)과 성장(Growth)의 조화

3) 데이터 접근성 높이기

4) 협업 문화 만들기

5) 그로스 해킹은 언제부터 하면 될까?