본문으로 바로 가기
글 목록으로
관점

리텐션과 LTV, 설치 후 첫 몇 분에서 결정돼요

광고보다 큰 레버가 설치 직후 몇 분에 있어요.

목차

광고로 데려온 유저를, 우리 앱은 어떻게 맞이하고 있을까요?

매주 월요일 광고 리포트, 늘 비슷하지 않나요?

“지난주 CPI는 선방했는데 D7 리텐션이 또 떨어졌네.”

“D7 ROAS도 기대만큼 안 나온 것 같은데?”

“소재를 바꿔 보고, 타겟팅을 다시 짜 보자.”

소재와 타겟팅을 다듬는 일은 중요합니다. 어떤 유저를 어떤 메시지로 데려올지가 달라지니까요. 여기에 질문 하나를 더해 보면 어떨까요? 그렇게 데려온 유저를 우리 앱은 어떻게 맞이하고 있을까요?

광고에서 본 상품을 첫 화면에서 바로 찾을 수 있는지, 관심을 가질 만한 혜택이 눈에 들어오는지, 다음에 무엇을 해야 할지 쉽게 알 수 있는지. 앱을 처음 여는 몇 분 동안 유저가 겪는 일입니다. 광고를 보고 들어온 기대를 앱 안에서 이어 주려면 이 경험도 함께 살펴봐야 합니다.

숫자로 생각해 보죠. 광고비 500만 원으로 유저 1,000명을 데려왔다고 가정해 보겠습니다. CPI는 5,000원입니다. 이 중 100명이 설치 7일째 앱을 이용했다면, 총광고비를 이 100명으로 나눈 비용은 1명당 5만 원입니다. 50명이 이용했다면 10만 원이고요.

D7 에 남는 유저 1명당 실질 광고비는 CPI 의 10배에서 20배가 돼요.

이커머스부터 게임, OTT, 핀테크까지, 업종은 달라도 설치 직후의 이탈을 줄이려는 고민은 비슷합니다. 많은 조직이 몇 년째 이 문제를 해결하려고 애쓰고 있고요.

유저마다 맞는 첫 경험을 제공하려면, 그 유저를 알아야 합니다. 그런데 정작 앱을 처음 여는 몇 분에는 그 판단에 쓸 정보가 거의 0에요. 앱 안에서 쌓인 행동 기록이 거의 없으니까요. 그래서 보통은 같은 홈 화면을 보여주거나, 같은 광고로 들어온 유저를 하나의 딥링크 페이지로 안내합니다. 그 안에 결제할 사람과 곧 떠날 사람이 섞여 있어도 말이죠.

Airbridge CUE는 Airbridge가 바로 이 정보의 공백을 메우려고 만든 서비스입니다. 설치 유입 정보와 구매 및 이탈 예측값을 제공해, 앱을 처음 여는 그 몇 분부터 유저를 이해하고 개인화를 시작할 수 있도록 돕습니다.


오랫동안 딥링크가 다리였지만, 유저의 차이까지 담기엔 좁았어요

이 공백을 메우는 데 중요한 역할을 해 온 것이 딥링크예요. 세일 광고를 눌렀으면 세일 페이지가 열리고, 신작 티저를 눌렀으면 그 작품의 상세 페이지가 열리는 식이죠. 광고에서 본 내용을 앱 안의 경험으로 이어 주는 다리입니다. 오랫동안 "앱 설치 직후 개인화"가 이 다리 위에서 돌아갔어요.

문제는 딥링크가 하나의 설정된 링크로 하나의 화면만 열어 준다는 점이에요. 100명이 같은 광고 눌러서 같은 딥링크로 오면, 그 100명이 다 똑같은 페이지를 봐요.

그 100명이 사실 같은 유저가 아닌데도요. 지금 당장 결제할 사람과 둘러보다 나갈 사람이 섞여 있고, 내일 떠날 사람과 한 달 머물 사람이 섞여 있어요. 이 차이를 가장 알아야 하는 순간이 바로 지금, 첫 오픈이에요. 그런데 정작 이 순간에는 앱 안에 쌓인 행동 기록이 거의 없어서 차이를 볼 수 없어요.

그림 02: 같은 화면으로 안내된 100명 안에도, 결제할 사람과 떠날 사람이 섞여 있습니다.

왜 이게 오래 안 바뀌었냐면, 매체에 쌓이는 데이터가 매체 안에 묶여 있어서였어요. 유저가 누구인지 알려면 앱 안에서 뭔가를 해야 하는데, 뭔가를 하기 전엔 모르잖아요. 그 공백을 채워 줄 "설치 전 데이터" 는 매체 쪽에 있지만, 앱이 그걸 첫 오픈 순간에 실시간으로 받아 올 길이 없었어요. 그래서 큰 앱이든 작은 앱이든 결국 "그냥 다 같은 홈 보여줄 수밖에" 로 돌아갔어요.


유저는 설치 전부터 자기가 누구인지 꽤 많이 흘리고 와요

여기 많이 간과되는 사실 하나. 유저는 앱 설치 전부터 자기가 누구인지 꽤 많이 흘리고 와요. 매체 쪽에요.

어떤 매체에서 왔는지, 어떤 소재를 몇 번째 봤을 때 눌렀는지, 그게 세일 광고였는지 브랜드 광고였는지, 클릭하고 설치까지 몇 초 걸렸는지. 다 매체 쪽에 쌓이는 데이터예요.

이게 유저를 얼마나 잘 구분하는지 숫자로 보면 바로 보여요. 릴스 광고 3번 보고 클릭한 유저 와 1번 보고 클릭한 유저. 노출 횟수만 달랐는데 D7 구매율이 4배 차이가 나요. 클릭 후 30초 만에 설치한 유저 와 3분 뒤에 설치한 유저. 설치까지 걸린 시간만 봐도 D7 구매율이 3배 넘게 차이 나요.

생각보다 큰 차이죠. 그런데 앱이 이 두 그룹을 구분하지 못하니까, 지금 대부분의 앱은 두 그룹의 첫 화면을 똑같이 띄워요. 노출 1번 본 유저와 3번 본 유저가 앱을 열면 같은 큐레이션 홈이 뜨고, 같은 쿠폰 배너가 보이고, 같은 CTA 버튼이 뜨는 거예요.

지금까지 이 데이터를 어떻게 썼냐면, 주로 어제자 리포트로 봤어요. "어제 CPI가 올랐네.", "이 소재는 CVR이 좋네." 그렇게 확인한 내용을 이번 주 캠페인 세팅에 반영했죠.

그런데 이 데이터를 써야 할 순간이 하나 더 있어요. 바로 그 유저가 지금 앱을 여는 순간이죠. 지난주 평균 CPI가 광고팀 회의에서 다음 캠페인을 정할 자료라면, 지금 들어온 유저가 어떤 광고를 어떻게 봤는지는 당장 첫 화면을 정할 재료예요. 앱이 그 자리에서 받아 써야 하는 정보인 거죠.

이걸 어제자 리포트 말고 지금 첫 오픈 순간의 앱으로 흘려 보내면, 딥링크가 못 하던 일이 전부 열려요. 자체 데이터팀 없이 그걸 할 수 있다면 더 좋고요.


그래서 Airbridge CUE가 넘기는 건 네 가지 정보예요

유저가 앱을 여는 그 순간, Airbridge CUE 앱 서버에서 개인화에 쓸 정보를 받아요. 여기서 마케터가 주목할 정보는 네 가지예요. 유저 아이디와 설치에 기여한 광고, 구매 가능성과 이탈 가능성이죠. 이 네 가지를 보면 어떤 기준으로 첫 경험을 나눌지부터 그려 볼 수 있어요.

첫째, 유저 아이디. 이 아이디 하나만 넘기면 Braze 에 있는 그 유저, GA4 에 있는 그 유저, 광고 플랫폼에 있는 그 유저가 전부 같은 사람으로 연결돼요. 지금까지 시스템마다 흩어져 있던 유저 데이터가 한 사람 중심으로 묶이는 거예요.

둘째, 앱 설치에 기여한 광고. 매체, 캠페인, 애드그룹, 크리에이티브 이름까지 다 담겨 와요. 세일 광고 보고 들어온 유저에겐 홈을 세일 큐레이션으로. 특정 브랜드 크리에이티브를 보고 들어온 유저에겐 그 브랜드를 상단에. 애드그룹 단위로 CRM 카피를 다르게 보내는 분기도 가능해요.

셋째, 3일 안에 결제할 확률. 높음/중간/낮음 세 등급. 숫자가 아니라 등급으로 넘기는 이유는, 받자마자 바로 쓸 수 있게 하기 위해서예요. 0.73 같은 숫자 받으면 "0.5 이상이면 뭐, 0.7 이상이면 뭐" 기준 결정이 하나 더 생기잖아요. 세 등급이면 바로 세 가지 다른 메시지를 짜면 돼요. 높음이면 프리미엄 오퍼 정면에, 중간이면 쿠폰 배너를 상단 고정으로, 낮음이면 무료 체험부터.

넷째, 3일 안에 떠날 확률. 역시 세 등급. 높음이면 D1 아침 리마인더 푸시 자동 발송. 떠날 확률과 결제 확률이 둘 다 높은 유저는 결제 리마인더로 집중 공략. 떠날 확률 낮은 유저에겐 리마케팅 예산 뺄 수 있어요.

네 개로 끊은 덕에 "어떤 유저에게 어떤 홈을 보여줄까" 를 머릿속에서 바로 그릴 수 있어요. 데이터팀 없이 마케터가 바로 설계할 수 있고요.

한 번 받은 네 가지 정보를, 앱과 CRM, 분석 도구와 광고 플랫폼에 연결.


유저를 몇 개 집단으로 나눌지, 거기서 결과가 갈려요

Airbridge CUE 쓴다는 건 결국 네 필드로 유저를 몇 개 집단으로 나누느냐의 문제예요.

크게 3개나 4개로만 묶을 수도 있어요. "세일 광고로 들어온 결제 확률 높음 그룹", "브랜드 광고로 들어온 이탈 확률 높음 그룹" 식으로. 규칙이 간단하고 각 그룹에 유저가 많이 들어오니 A/B 테스트로 빨리 확인할 수 있어요. 처음 도입할 땐 보통 이쪽을 추천해요.

90개로 쪼갤 수도 있어요. 광고 소재 10개 × 결제 확률 3 × 이탈 확률 3 = 90개. 개인화가 훨씬 더 세밀해져요. 다만 그룹이 많아지는 만큼 각 그룹용 홈 화면과 CRM 메시지를 따로 운영하는 공수가 함께 늘어나요.

4개로 묶으면 운영이 가볍고, 90개로 쪼개면 개인화가 세밀해져요.

실무적으로는 8개에서 16개로 시작해서 성과가 뚜렷한 그룹부터 더 쪼개는 방식을 권장해요. 운영 공수는 통제하면서도, 더 세밀하게 나눌 가치가 있는 그룹이 어디인지 데이터로 확인할 수 있거든요.


하나의 응답 셋트, 쓰고 싶은 곳 어디서든 꺼내 써요

Airbridge CUE 응답이 어디까지 쓰이냐를 보면 많이 간과되는 지점이 있어요. 이 응답은 앱 안뿐 아니라 마케팅 스택 어디서든 꺼내 쓸 수 있어요.

같은 응답으로 Braze 세그먼트를 그 자리에서 만들면, 다음 날 아침 8시에 "어제 본 세일이 오늘 자정 종료" 라는 개인화 푸시가 자동으로 나가요. 광고에서 어떤 세일을 봤는지 Airbridge CUE 가 알려줬기 때문에 가능한 카피예요. 결제 확률 값은 광고 플랫폼 리타겟 오디언스로 올려서, 결제 확률 낮은 유저에겐 리마케팅 더 치고 어차피 돌아올 유저에겐 예산을 빼요. GA4 세션 속성에도 그대로 넣으면 "결제 확률 상위 10% 유저가 어떤 플로우를 거쳤나" 같은 질문이 바로 쿼리로 돌아가요.

응답 한 벌을 한 번 받아 두면, 그 뒤로는 어디에 어떻게 꽂을지는 설계하기 나름이에요. 앱 첫 화면 분기든, Braze 세그먼트든, GA4 세션 속성이든, 광고 리타겟 오디언스든, 같은 응답을 공통 소스로 꺼내 쓸 수 있거든요. 덕분에 마케팅 스택을 원하는 모양으로 설계할 수 있어요. 지금까지는 각 시스템에 쌓이는 유저 뷰를 일치시키는 데 개발팀이 꽤 많은 품을 들여야 했는데, 그 비용이 자연히 줄어들고요.

개발팀에 부탁할 일은 "첫 오픈 때 API 하나 호출" 수준이에요. 응답 받아서 네 필드를 뿌리는 쪽은 각 시스템 (Braze, Amplitude, GA4 등) 의 기존 SDK 그대로 쓰면 되고요. Airbridge 를 이미 쓰고 있으면 설치 가이드 한 장으로 통합이 끝나요.

한 번의 호출로 네 시스템이 동시에 움직여요. 다음 날 아침 CRM 푸시까지 자동으로 이어지고요.


분기별로 돌리던 가설이, 매번 들어오는 유저에게 자동으로 돌아요

마케터라면 리포트 보다가 이런 발견 한 번쯤 한 적 있을 거예요. "세일 광고로 들어온 결제 가능성 높은 유저에게 프리미엄 오퍼를 꽂으면 전환이 꽤 잘 나온다." "이탈 확률 높은 유저는 D1 아침 리마인더 푸시 한 번이면 꽤 살아 돌아온다."

지금까지는 이 발견을 캠페인 하나 돌려서 확인하는 방식이었어요. 가설 세우기 → 캠페인 세팅 → 돌려 보기 → 결과 보기 → 다음에 반영. 발견이 쌓여도, 그걸 매번 캠페인으로 재구성해야 반영돼요.

Airbridge CUE 는 이걸 룰 한 번 걸어 두는 방식으로 바꿔 줘요. "결제 확률 높음 + 세일 유입이면 프리미엄 오퍼 홈" 같은 룰을 한 번 등록해 두면, 그 조건에 맞는 유저가 들어올 때마다 그 홈이 자동으로 열려요. 다음 캠페인 돌릴 때까지 기다릴 필요도, 매번 세팅을 다시 할 필요도 없어요. 결과는 D1, D3, D7 로 쌓이면서 룰을 더 다듬을 수 있고요.

리포트 안에만 있던 성공 공식이, 실시간으로 돌아가는 룰이 되는 거예요.

가설 → 결과까지의 사이클이 눈에 띄게 짧아져요.

여기에 하나 더 있어요. Auto Experiment, 다음 챕터예요.

옵션 이름 몇 개만 등록해 두면, 어떤 유저에게 어떤 옵션을 보여줄지의 선택까지 Airbridge CUE 가 알아서 해 줘요. "프리미엄 오퍼", "무료 체험", "할인 배너" 라고 옵션 라벨 세 개만 등록해 두면, 유저 A 에겐 프리미엄, 유저 B 에겐 무료 체험, 유저 C 에겐 할인 배너를 결과 보면서 자동으로 고르는 식. 어떤 옵션이 어떤 유저에게 통했는지 결과가 쌓이면 그 결과가 다음 유저의 선택에 반영돼요.

지금 네 필드로 시작해 두면 Auto Experiment 가 열릴 때 학습에 쓸 과거 데이터가 이미 쌓여 있어요. 반대로 지금 안 시작하면 Auto Experiment 가 열려도 처음 몇 달은 데이터 쌓는 데 쓰이고요. 큰 앱들이 자체 데이터팀으로 이런 걸 돌릴 때 먼저 쌓은 몇 년치 데이터로 가속받는 이유랑 같아요.


지금 직접 확인해 볼 수 있는 방법

Airbridge CUE 를 지금 당장 쓸 수 있냐 없냐를 떠나서, 오늘 바로 해 볼 수 있는 체크 하나가 있어요. "지금 데려오는 유저가 사실 얼마나 다른지" 를 눈으로 보는 일이에요.

최근 한 달 광고비를 가장 많이 쓴 캠페인 하나를 골라요. 그 캠페인으로 들어온 신규 유저를 세 그룹으로 나눠 봐요. 결제한 유저, 돌아왔지만 결제 안 한 유저, 안 돌아온 유저. 각 그룹의 1인당 매출이 얼마인지 비교해 봐요. 거의 틀림없이 세 그룹 사이에 매출 차이가 몇 배는 벌어져 있어요.

데려오는 광고는 하나였는데 그 안에서 나오는 결과가 몇 배씩 갈린다는 거예요. 그 세 그룹에게 지금 당신 앱이 같은 홈 화면이나 같은 딥링크 페이지를 열어 주고 있다면, 바로 거기에 쓸 수 있는 그로스 레버가 있는 거고요. 지금은 그 레버가 시야 밖에 있는 것뿐이에요.

Airbridge CUE 는 각 앱의 결제 확률과 이탈 확률 모델을 그 앱 데이터로 학습시켜 드려요. 상담 신청 만 하시면 보통 2일에서 3일 안에 네 필드 응답을 쓸 수 있는 상태로 세팅돼요. 통합은 설치 가이드 한 장이면 끝나고요.

Airbridge CUE 에 대해 더 궁금하시다면, Airbridge CUE 소개 페이지 와 Context API 문서 를 둘러보셔도 좋아요.

다음 월요일 광고 리포트에서는 소재와 타겟팅 이야기 뒤에 이 질문도 한 번 꺼내 보세요.

“광고를 보고 들어온 유저를, 우리 앱은 어떻게 맞이하고 있지?”

아이디어를 실행으로 옮겨 보세요.

CUE의 사용 방법을 확인하거나, 우리 서비스에 맞는 활용 방법을 함께 이야기해 보세요.