[개념노트] AARRR 을 책으로 배웠습니다 #1 : 고객유치(Acquisition)

* 이번 포스팅은 양승화님의 "그로스 해킹" 책을 읽고 정리한 내용을 담았습니다.

 

0. 들어가며

이번 포스팅은 분석가로서 필요한 도메인과 분석방법론에 대한 지식을 획득하는 것을 목적으로 한 게시글입니다.
현재 근무중인 회사에서는 이런 업무를 하고있지 않아 지식 및 경험이 많이 부족한 상태인데요.
'부족한 경험을 어떻게 채워볼까?' 라는 생각을 하다 '일단은 개념부터 알고 가자!' 라는 생각에 포스팅을 진행하게 되었습니다.
그 첫 번째 내용은 AARRR 에 관한 이야기입니다.
많이 부족하겠지만 수정할 부분이나 보완할 부분, 추천할만한 참고 내용이 있으시면 언제든 댓글 남겨주세요😊

1. AARRR 이란?

AARRR 은 각각의 단어 첫 글자를 따와 만들어진 지표 관리 방법입니다.

A : Acquisition (고객 유치)
= 사용자들을 어떻게 데려올것인가?

A : Activation (활성화)
= 사용자들이 우리 서비스의 핵심 기능을 잘 사용하는가?

R : Retention (리텐션)
= 사용자들이 우리 서비스에 지속적으로 방문하는가?

R : Revenue (수익화)
= 사용자들이 우리 서비스의 핵심 기능을 사용하기 위해 결제를 하는가?

R : Referral (추천)
= 사용자들이 우리 서비스를 주변 지인들에게 소개, 추천하는가?

AARRR 그림

AARRR 프레임워크를 그림으로 나타내면 이렇게 깔대기처럼 밑단이 좁아지는 모습으로 나타낼 수 있습니다.
이는 아래단계로 갈수록 남아있는 사용자의 수가 적어진다는 의미입니다.
AARRR은 각각의 단계에서 핵심이 되는 지표를 발굴하고 이를 측정/개선하여 최대한 많은 고객을 획득·유지·전환하는데 목적이 있습니다.

 

1.1 AARRR 등장 배경

이러한 AARRR 지표가 왜 등장했는지를 잠시 이야기를 해봅시다.
지표를 바라보는 관점은 크게 과업 기반(Task-Based), 프레임워크 기반(Framework-Based) 관점으로 나눌 수 있습니다.

과업 기반 (Task-Based) 관점
각 조직별로 담당하는 업무를 우선 정의한 후 해당 업무를 통해 발생하는 수치들을 지표화해서 관리.
하나의 서비스에서 각 부서별로 담당하는 업무가 다르기 때문에 각 부서별 활동 내용에 대한 지표를 수립하여 평가를 함.

과업기반 관점

과업기반 관점은 전체적인 서비스 관점에서 무엇이 중요한 지표인지 판단이 어렵다는 단점이 있습니다.
이러한 단점을 해결하기 위해 나온 관점이 프레임워크 기반 지표관리이며 대표적으로 AARRR 이 있습니다.

프레임워크 기반(Framework-Based) 관점
서비스의 이용 흐름에 따라 단계별로 주요 지표를 전체 서비스관점에서 정함.

프레임워크 기반 관점

프레임워크 기반 관점은 지표로부터 과업을 수행합니다.
서비스 이용흐름에 따라 핵심 퍼널과 지표를 정의하고, 해당 지표를 개선하기 위한 과업을 수행하는 것이죠.

그래서 기억을 해둘 부분은 이렇습니다.

1. AARRR는 프레임워크 기반(Framework-Based)의 지표 관리방법
2. "사용자의 서비스 이용 흐름"에 따라 단계별 주요 지표를 전체 서비스 관점에서 정의
3. 해당 지표를 개선하기 위한 과업을 수행

 

1.2. 주의할 점

AARRR 그림을 보면 A→A→R→R→R 순서대로 진행하는 것 처럼 보이지만 실제로는 그렇지 않습니다.
실제로 AARRR 이라는 개념을 선보인 Dave McClure 가 진행한 프레젠테이션에서는 AARRR에 대해 아래와 같은 그림을 보여줬습니다.

AARRR 

위 그림을 보면 5-Step 이라고 되어있지만 실상은 순차적인 Step을 밟아감이 아니라는 것을 알 수 있습니다.
AARRR은 단계적인 흐름이 아닌 서비스와 사용자의 관계적인 상황을 범주화시켜둔 것에 가깝습니다.
그러니 진행하고 있는 서비스에 맞게끔 우선순위를 두고 진행해야합니다.
스타트업의 경우 '활성화'와 '리텐션'에 높은 우선순위를 두고 그 후에 '고객유치', '추천', 마지막으로 '수익화' 순서를 추천한다고 합니다.

이렇게 AARRR에 대해 전반적인 내용을 살펴보았는데요.
이젠 각 단계별로 어떤 지표를 발굴하고 어떻게 관리를 하는지 구체적으로 살펴보겠습니다.

---

 

2. "A"ARRR : Acquisition, 고객 획득

AARRR 에 대해서 대략적으로 알아봤으니 AARRR 중 첫 번째 "A" 인 고객획득(Acquisition) 부분부터 살펴봅시다.

고객 획득 (Acquisition)
사용자를 우리의 서비스로 데려오는 것과 관련된 활동.

일반적인 서비스의 경우 고객 유치를 위해 다양한 마케팅 채널을 활용하고, 여러 개의 캠페인을 동시에 진행합니다.
이러한 경우 각 채널별, 캠페인별 성과를 측정하고, 이를 기반으로 전체적인 마케팅 전략 수립 및 예산 배분을 하게 됩니다.
여기서는 '다양한 환경 중에서 고객이 유입하게 된 요인이 뭐지?' 라는 질문에 답을 찾는 것이 고객 유치과정의 핵심이라고 할 수 있습니다.

고객 유치 과정의 핵심
고객 유치에 기여한 채널의 성과를 판단할 수 있는 모델 구축.

그러므로 고객 획득 단계에서는 채널의 성과를 측정할 수 있는 지표를 정의하고, 해당 지표 개선을 위한 과업을 수행하게 됩니다.

그럼 고객 획득 단계에서의 지표를 정의해보도록 합시다.
우선 출발은 유입된 사용자를 구분하는 것에서 시작합니다.

Organic 고객
: 자발적으로 우리 서비스를 찾아온 고객
→ 자발적으로 우리 서비스를 찾아온 고객이 얼마나 많은가?

Paid 고객
: 마케팅 활동을 통해 우리 서비스를 찾아온 고객
→ 유료 마케팅 채널을 얼마나 효율적으로 사용했는가?

구글 애널리틱스나 앱스플라이어 같은 서비스에선 이 두 가입자의 비중을 확인할 수 있습니다.
하지만 서비스마다 Organic/Paid 고객의 정의가 조금씩 다르기 때문에 사용하는 서비스의 고객 정의를 잘 이해한 뒤 분석에 활용해야합니다.
(유입 출처를 분류할 수 없는 고객의 경우에도 Organic 으로 분류해버리는 경우가 있습니다.)

정리하면 고객 획득 단계에서 중점으로 다뤄야하는 내용은 이렇습니다.

- 어떻게 하면 사용자의 유입 채널을 최대한 누락 없이 정확하게 추적할 수 있을까?
& 미식별(UnKnown) 유입을 어떻게 줄일 수 있을까?

- 추적한 데이터를 기반으로 어떻게 각 채널별 성과를 정확히 판단할 수 있을까?

 

2.1. 핵심 지표 : 고객 획득 비용 (CAC, Customer Acqusition Cost)

고객 유치 과정에서 채널별 성과를 측정하기 위한 지표로 고객 획득 비용을 들 수 있습니다.

고객 획득 비용 (Customer Acqusition Cost, CAC)
: 한 명의 사용자를 데려오기 위해 지출하는 평균 비용

고객 획득 비용을 계산하는 가장 기본적인 수식은 '마케팅에 사용한 비용/가입한 유저 수' 입니다.
이 기본이 되는 수식과 채널, 캠페인, 날짜, 광고 등을 함께 고려하여 고객 획득 비용이라는 지표를 구합니다.
이를 통해 어느 채널에, 얼마의 기간동안, 어떤 캠페인으로, 얼마의 예산을 집행할 것인가? 라는 질문에 대답할 수 있게 됩니다.

사실 이 질문에 대답하기 위해서는 각 채널별, 캠페인별, 광고별로 얼마의 예산을 집행했고, 각 경로를 통한 유입이 정확이 어떻게 되는지를 정확하게 추적해야하는데요.
그런 추적을 도와주는 도구로 웹에서는 "UTM 파라미터", 앱에서는 "어트리뷰션"이 있습니다.
하나씩 살펴보죠.

2.1.1. UTM 파라미터

웹에서 사용자, 방문자를 추적할 땐 'UTM 파라미터'가 추적을 도와줍니다.

UTM 파라미터 (Urchin Tracking Module 파라미터)
서비스로 유입된 트래픽이 어느 경로를 통해 들어왔는지 그 출처를 알 수 있도록 URL 뒤에 추가한 파라미터

UTM 파라미터는 생각보다 간단합니다.
구글에서 UTM builder 라고 검색한 뒤 구글에서 제공하는 UTM builder 를 이용하면 됩니다.

UTM Builder

저도 들어가서 제 블로그 주소에 UTM 파라미터를 붙힌 주소를 만들어봤습니다.

<예시>
https://schatz37.tistory.com/#utm_source=Kakao_link&utm_medium=univ_friends_chat&utm_campaign=Blog_PR

위 UTM파라미터는 제가 마음대로 생각나는대로 만들었는데 의미는 다음과 같습니다.

내 블로그 주소를 대학교 친구들이 있는 단톡방에 뿌렸다. 카카오톡을 통해 링크를 줬고 목적은 내 블로그를 홍보하기 위함이었다.

이 의미가 위 주소에 담겨있는데 하나하나를 뜯어보면서 UTM 파라미터에 대해 이해를 해봅시다.

* https://schatz37.tistory.com/#
링크를 클릭했을 때 이동되는 페이지의 주소입니다. 여기서는 제 블로그 메인으로 이동합니다.

* utm_source=KaKao_link
페이지 소스(Source) : 어디에서 왔는지?
어떤 곳(카카오톡 링크)에 뿌려진 링크를 타고 이 블로그로 왔는지를 체크해주는 파라미터입니다.
보통은 Facebook, Google, Naver 와 같은 사이트 이름을 적어줍니다.

* utm_medium=univ_friends_chat
매체(medium) : 어떤 매체를 통해 왔는지?
어떤 매체(카카오톡 단톡방)를 통해 이 블로그로 들어오게 되었는지를 체크해주는 파라미터입니다.
보통은 email, banner, cpc 와 같은 광고 방식을 적어줍니다.

* utm_campaign=Blog_PR
캠페인(Campaign) : 어떤 이벤트를 보고 왔는지?
어떤 이벤트(내 블로그 PR하는 카톡 메세지)를 보고 이 블로그로 왔는지를 체크해주는 파라미터입니다.
보통은 진행하고 있는 행사나 캠페인의 이름(빅스마일데이, 설/추석 이벤트,블랙프라이데이 등)을 적어줍니다.

이런식으로 구성된 URL 을 각각의 채널별로 만들어 뿌려준다면 어떤 채널에서, 어떤 캠페인을 보고, 어떤 매체를 통해 들어오는지를 상세히 알 수 있게 됩니다.

2.1.2. 모바일 앱 어트리뷰션(Attribution)

모바일 앱의 유입자 추적하는 것은 UTM 파라미터를 이용하는 것 처럼 간단하지 않습니다.
모바일 앱은 링크를 클릭한 후 앱스토어로 이동한 다음에 앱을 설치하고 실행하는 과정이 필요한데, 이 과정에서 UTM 파라미터가 유실되기 때문입니다.
UTM 파라미터 대신 모바일 앱에서 유입 기여를 살펴보기 위해 사용되는 것이 어트리뷰션(Attribution) 입니다..

어트리뷰션(Attribution)
: 사용자가 앱을 설치하고 사용하는데 어떤 채널이 기여했는지 식별하여 모바일 앱의 마케팅 성과를 판단하는 과정
앱스플라이어, 애드저스트, 브랜치, 에어브릿지, 에드브릭스 등의 서비스가 존재합니다.

앱 어트리뷰션 프로세스

사용자(스누피)가 네이버에서 무신사 광고를 보고 앱을 설치하고 실행하는 과정입니다.
이 경우 기본적인 어트리뷰션 룰에 따라 네이버 광고가 앱을 설치하는 데 기여한 것으로 인정받습니다.
하지말 사실 위 과정을 들여다보면 생각보다 고려해야할 점이 많고 복잡하다는 것을 알게됩니다.
이러한 복잡한 어트리뷰션을 이해하기 위해 필요한 개념이 있는데요, 그 개념을 먼저 알아봅시다.

---

• 어트리뷰션 윈도우

어트리뷰션 윈도우(Attribution Window)
기여 이벤트가 발생 후 발생한 전환에 대해 어트리뷰션을 인정할 기간
"어트리뷰션 윈도우를 N일로 한다." 라는 일반적인 규칙은 없으며 채널별로 각각 기준에 따라 정의해야 합니다.

스누피 예시를 다시 보겠습니다.

빨간 스누피 : 성과가 인정된 경우

빨간 스누피의 경우 어트리뷰션 이벤트(광고클릭) 발생 후, 앱 설치 & 실행까지 지정한 어트리뷰션 윈도우 기간 안에 완료하였습니다.
이 경우 네이버 광고가 앱을 설치하는 데 기여한 것으로 인정받습니다.

노랑 스누피 : 성과가 인정되지 않은 경우

노랑 스누피의 경우 앱 설치 & 실행을 하긴 했지만 어트리뷰션 윈도우 기간 안에 앱 설치 & 실행을 하지 않았습니다.
이 경우 네이버 광고는 앱 설치에 기여한 것으로 인정받지 못합니다.

어트리뷰션 윈도우 기간은 서비스의 특성, 광고 채널의 특성을 고려하여 정의하는 것이 핵심이라고 할 수 있습니다.

---

• 어트리뷰션 모델

위의 경우와 달리 여러 개의 광고를 본 뒤 앱을 설치 & 실행하는 경우에는 어떻게 어트리뷰션을 인정할까요?
이 때 사용하는 개념이 어트리뷰션 모델입니다.

어트리뷰션 모델 (Attribution Model)
여러 개의 어트리뷰션 접점이 발생하는 경우 어떻게 기여도를 판단할지 결정하는 모델

여러 어트리뷰션의 접점이 일어난 경우

이러한 경우에 사용하는 어트리뷰션 모델 중 대표적인 몇 가지를 소개하겠습니다.

• 싱글 터치 어트리뷰션(Single-touch Arrtibution) 모델
  1. 퍼스트 클릭(First-Click) 모델 
     • 어러 건의 기여 이벤트가 발생했을 때, 첫 번째 매체의 성과를 100% 인정하는 방식의 어트리뷰션
     • 위 예시에서는 광고A에 100% 성과를 인정해줍니다.
  2. 라스트 클릭(Last-Click) 모델
     • 어러 건의 기여 이벤트가 발생했을 때, 마지막 매체의 성과를 100% 인정하는 방식의 어트리뷰션
     • 위 예시에서는 광고E에 100% 성과를 인정해줍니다.
       

싱글 터치 어트리뷰션(Single-touch Arrtibution) 모델의 장단점
장점 : 단순하고 기준이 명확하여 계산하기 쉽다.
단점 : 지나치게 단순화한 방식이기 때문에 간접접으로 기여하는 다른 채널들의 성과를 전혀 반영하지 못한다.
→ 결과의 왜곡이 발생할 수 있다.

이러한 단점을 보완하기 위해 멀티 터치 어트리뷰션(Multi-touch Arrtibution) 모델이 등장했습니다.

• 멀티 터치 어트리뷰션 모델(Multi-touch Arrtibution)
  1. 선형(Linear) 어트리뷰션 모델
     • 어트리뷰션 접점이 발생한 모든 매체에 동일한 가중치를 부여하는 방식의 어트리뷰션
     • 위 예시에선 광고A ~ 광고E 가 모두 20%의 기여를 인정받습니다.
  2. 타임 디케이(Time-Decay) 어트리뷰션 모델
     • 시간의 흐름을 고려하여 채널의 기여도를 판단하는 방식의 어트리뷰션
       최근에 발생한 이벤트일수록 높은 가중치를 줍니다.
     • 위 예시에서는 광고A가 가장 낮은 기여를, 광고E가 가장 높은 기여를 인정받습니다.
  3. U자형 어트리뷰션 모델
     • 가장 먼저 발생한 기여 이벤트와 가장 마지막(최근)에 발생한 기여 이벤트에 동일한 가중치를 부여합니다.

이렇게 다양한 모델이 중 서비스의 특성에 따라 기준을 세우고 그에 맞는 어트리뷰션 모델을 선택해야합니다.

---

• 딥링크(Deep Link)와 디퍼드 딥링크(Deferred Deep Link)

딥링크는 웹에서 앱으로 전환되는 과정에서 사용되는 링크입니다.

딥링크(Deep Link)
모바일 앱 안의 특정 화면으로 이동하는 링크
모바일 앱을 설치한 사용자가 딥 링크를 클릭하면 웹 브라우저가 아닌 앱에서 적합한 랜딩 페이지로 이동합니다.
* 랜딩 페이지(Landing Page) : 광고, 검색엔진 등을 경유하여 접속하는 이용자가 최초로 보게되는 페이지. 고객에게 다양한 정보를 주고 니즈(needs)를 자극하여 액션을 취하도록 돕는 도구.

장점 : 웹 → 앱 전환 과정에서 맥락(Context)이 유지되어 전환율을 크게 향상시킬 수 있다.
단점 : 링크를 클릭하는 사람의 휴대폰에 앱이 설치가 되어있을 때만 작동한다.

이런 단점은 디퍼드 딥링크(Deferred Deep Link)를 사용하여 해결할 수 있습니다.

디퍼드 딥링크(Deferred Deep Link)
앱 설치유무와 상관없이 사용할 수 있는 딥링크

<디퍼드 딥링크 프로세스>
1. 디퍼드 딥링크 클릭
2.1. (앱 설치가 된 경우) 일반적인 딥링크처럼 작동 (4번으로 이동)
2.2. (앱 설치가 되지 않은 경우) 앱스토어의 설치 화면으로 이동
3. 설치 완료 후 앱 실행
4. 앱의 첫 화면이 아닌 미리 정의한 딥링크의 랜딩페이지로 이동

장점 : 사용 맥락이 유지된 채로 자연스럽게 앱으로 진입할 수 있어 사용자 경험(UX) 측면에서 긍정적이다.
딥링크 생성 시 적절한 파라미터를 추가해 사용자 유입을 추적할 수 있다. (UMT파라미터와 유사)

 

3. 정리하면.

이렇게 AARRR 에서 고객 유입(Acqusition)의 내용에 대해 살펴보았습니다.
특히 사용자의 유입을 추적하기 위한 개념들을 공부하면서 느낀점은 '정답이 없다'였습니다.
어트리뷰션을 정의하다보면 각각의 항목에 대해 기준을 정의해야하는데, 정답이 없으니 우리는 기준에 대한 '명확한 원칙'을 세워야 합니다.
아주 많고 다양한 기준들이 존재하겠지만, 몇 가지 기준을 살펴보죠.

* 각 채널의 어트리뷰션 윈도우 기간을 얼마나 길게 할 것인지?
* 동일한 사용자의 웹 어트리뷰션 로그와 앱 어트리뷰션 로그가 모두 남아있는 경우 기여도를 어떻게 판단할 것인가?
* 마케팅 캠페인의 성과 판단 기준은 무엇이 되어야 할까?
* 모바일 웹 어트리뷰션 윈도우와 동일한 형태로 웹 UTM 에 대해서도 어트리뷰션 윈도우를 인정할 것인가?
...

사실 경험해보지못한 부분이라 위 질문들을 봤을 때 감도 안오는 상태인데요..
그래도 위와 같은 기준에 대해 원칙을 세울 때 고려해야 할 부분을 스스로 생각을 해봤습니다.
이 생각을 정리하면서 이번 포스팅을 마치려합니다. (추가할 내용이 있으면 댓글로 남겨주세요🤭)

1. 서비스의 성격, 고객을 고려해야한다.
서비스에 따라 고객의 정보, 특성이 달라지기 때문에 이러한 부분을 고려해야 하고,
고객의 특성을 파악하고 어떤 방식으로 고객과의 관계를 유지할 수 있을지 고려하여 원칙을 세워야합니다.
결국은 서비스는 고객을 위한 것이고 고객이 없으면 서비스가 존재할 수 없으니깐요.

이 부분은 어느정도 이전 사례나 유사 서비스 사례를 기반으로 기준을 정할 수 있을거라 생각이 듭니다.
원칙을 세우는 직접적인 경험을 할 수 없다면 Case Study를 통한 원칙 설정 사례를 공부해보는 것도 하나의 방법이라고 생각합니다.

2. 지표를 통해 확인하려는 목적을 항상 염두해야한다.
각 기준들에 대한 원칙을 정할 때 '왜 이 지표가 필요하지?'라는 생각을 하며 지표 측정의 목적을 벗어나지 않는 원칙을 세우는 것이 중요합니다.
아마도 지표는 결국 '고객 이해'를 위해 측정·관리되는 경우가 많을테니 늘 고객 중심적인 사고를 기반으로 원칙을 정하는 것이 좋을 것 같다는 생각이 듭니다.

3. 직접 그 서비스를 이용하면서 기준에 대한 원칙을 잡아본다.
스스로가 한 명의 고객이 되어 서비스를 경험해보고 사용 패턴을 살펴보는 것은 아주 좋은 방법이라고 생각합니다. 스스로 서비스를 경험해보면 지표에서 보이지 않는 전체적인 흐름도 다시 살펴볼 수 있으니깐요!

결국 정리를 해보니 "고객"이라는 단어로 귀결되네요.
일상 속에서도 '스스로를 고객이자 내가 서비스 담당자라면 어떨까? 라는 생각을 해봐야겠다'는 다짐을 하며 포스팅을 끝마칩니다.

---

다음 포스팅은 AARRR 의 나머지 단계에 대해 이야기하도록 하겠습니다!