앱 출시 후 첫 90일, 무엇을 측정해야 하나
출시 직후 다운로드 수를 성과로 읽으면 안 되는 이유
출시 첫 주의 다운로드 수는 성과가 아니라 관심의 크기입니다. 그 관심은 대부분 지인, 사내 공유, 개시 시점의 홍보에서 나옵니다. 제품이 쓸 만한지는 알려 주지 않습니다. 첫 90일에 확인할 것은 몇 명이 받았느냐가 아니라, 받은 사람 가운데 몇 명이 다시 열었느냐입니다.
다운로드 수가 유독 매력적으로 보이는 이유는 단순합니다. 스토어 콘솔에 기본으로 찍히고, 계측을 붙이지 않아도 보이고, 숫자가 크고, 위로 올라가기만 합니다. 누적값이라 절대 내려가지 않으니 매주 보고서에 넣기에 이만한 숫자가 없습니다. 그러나 내려가지 않는 지표는 상태를 알려 주지 못합니다. 제품이 나빠져도 그래프는 계속 오릅니다.
같은 1,000건의 설치라도 어디서 왔느냐에 따라 의미가 완전히 다릅니다. 사내 공지로 받은 설치는 조직의 지시를 반영할 뿐 제품 선호를 반영하지 않습니다. 행사장에서 QR로 받은 설치는 현장 분위기의 산물이고, 대체로 그날 저녁이면 화면에서 사라집니다. 광고로 들어온 설치는 소재가 만든 기대를 안고 들어오는데, 그 기대가 앱과 어긋나면 첫날 이탈이 크게 납니다. 세 경우를 한 줄로 합쳐 놓으면 아무것도 읽히지 않습니다.
그래서 다운로드는 성과가 아니라 분모로 다뤄야 합니다. 분모로 쓸 때는 유용합니다. 이번 주 설치 중 몇 퍼센트가 온보딩을 끝냈는지, 몇 퍼센트가 이튿날 돌아왔는지를 계산하려면 분모가 필요합니다. 분모를 성과로 착각하는 순간 팀 전체가 유입만 늘리는 방향으로 움직이고, 정작 새는 바닥은 그대로 남습니다.
출시 직후에도 다운로드보다 먼저 볼 만한 숫자가 하나 있습니다. 스토어 페이지 노출 대비 설치 전환율입니다. 이 비율은 제품이 아니라 스토어 리스팅의 품질을 말해 줍니다. 아이콘, 첫 스크린샷 두 장, 제목과 첫 줄 설명이 여기서 대부분을 결정합니다. 전환율이 낮은데 광고비를 올리면 새는 통에 물을 더 붓는 셈이 됩니다.
한 가지 더 짚고 싶은 점이 있습니다. 출시 첫 2주는 데이터가 가장 왜곡되는 구간입니다. 개발팀과 내부 테스터, 관계사, 초기 홍보에 반응한 사람들이 섞여 들어옵니다. 이 시기의 코호트를 기준선으로 삼으면 이후 모든 판단이 어긋납니다. 내부 계정과 테스트 기기는 처음부터 분리해 두고, 기준선은 3주 차 이후 코호트에서 잡는 편이 안전합니다.
리텐션을 먼저 보는 이유: D1, D7, D30이 말해 주는 것
리텐션은 제품이 약속을 지켰는지 알려 주는 지표입니다. D1은 첫인상, D7은 반복 사용의 씨앗, D30은 제품이 일상에 자리 잡았는지를 봅니다. 세 숫자는 서로 다른 구간에서 서로 다른 종류의 실패를 가리킵니다. 그래서 하나만 보면 숫자가 낮다는 사실은 알아도 어디를 고쳐야 하는지는 알 수 없습니다.
먼저 정의를 팀 안에서 합의해야 합니다. D1 리텐션이라고 말할 때 설치 다음 날 정확히 그날 다시 연 비율을 뜻하는지, 다음 날 이후 언젠가 돌아온 비율을 뜻하는지에 따라 숫자가 크게 달라집니다. 도구마다 기본값이 다르고, 도구를 바꾸면 과거 숫자와 비교가 끊깁니다. 정의를 한 문서에 적어 두고 계측 코드와 대시보드가 같은 정의를 쓰는지 확인하는 일이, 숫자를 올리는 일보다 먼저입니다.
D1이 낮다면 원인은 대체로 진입 구간에 있습니다. 회원가입 강제, 과도한 권한 요청, 첫 화면에서 무엇을 해야 하는지 모르는 상태, 그리고 광고가 약속한 것과 앱이 실제로 주는 것의 불일치입니다. 이 구간은 제품의 깊이와 거의 무관합니다. 아무리 좋은 기능이 안쪽에 있어도 유저는 거기까지 가지 않습니다.
D7이 낮다면 다시 열 이유가 없다는 뜻입니다. 한 번 쓰고 목적이 끝나는 유틸리티라면 이 숫자가 낮은 게 자연스럽고, 그런 제품은 리텐션 대신 재방문 주기와 완료율로 평가해야 합니다. 반면 반복 사용을 전제로 설계한 제품에서 D7이 무너지면 핵심 루프가 없다는 신호입니다. 알림이 부족한 문제로 보이기 쉽지만, 알림은 이유를 만들어 주지 못합니다. 이유가 있어야 알림이 작동합니다.
D30이 낮다면 초기 흥미는 있었지만 지속 가치가 없었다는 뜻입니다. 콘텐츠가 금방 바닥나거나, 처음 한 번 설정하고 나면 더 할 일이 없거나, 데이터가 쌓여도 유저에게 돌아오는 것이 없는 경우입니다. 이 구간의 개선은 대체로 기능 추가가 아니라 축적된 데이터를 유저에게 되돌려 주는 설계에서 나옵니다.
업계 평균 리텐션이 몇 퍼센트라는 식의 숫자는 이 글에서 쓰지 않겠습니다. 출처를 명확히 댈 수 없는 벤치마크는 판단을 돕기보다 안심시키는 데 쓰이기 쉽고, 앱의 성격에 따라 기대치가 근본적으로 다르기 때문입니다. 대신 자기 자신과 비교하십시오. 이번 달에 들어온 코호트가 지난달 코호트보다 나아졌는지, 온보딩을 바꾼 뒤 들어온 코호트가 바꾸기 전 코호트보다 나아졌는지가 훨씬 신뢰할 수 있는 기준입니다.
사용 주기가 다르면 기대치도 달라야 합니다. 근태를 기록하는 앱이라면 근무일마다 열리는 것이 정상이므로 일 단위 리텐션이 의미를 갖습니다. 여우비가 운영하는 onSpots가 이런 성격의 서비스입니다. 반대로 구인구직 서비스는 구직 기간에 집중적으로 쓰이고 취업하면 자연스럽게 멀어집니다. Job Connect VN 같은 서비스에 일 단위 리텐션을 들이대면 잘못된 결론이 나옵니다. 우리 앱의 정상 사용 주기를 먼저 정의하고, 그 주기에 맞는 창으로 리텐션을 봐야 합니다.
마지막으로 리텐션은 반드시 쪼개서 봐야 합니다. 획득 채널별, 운영체제별, 기기 성능대별, 그리고 다국어 제품이라면 로케일별로 나눕니다. 한국어와 베트남어와 영어를 함께 지원하는 랭토리 같은 구조에서는 로케일마다 유입 경로와 사용 맥락이 다르기 때문에, 전체 평균 하나로는 어느 쪽이 문제인지 보이지 않습니다. 평균은 서로 다른 두 개의 진실을 덮는 데 능합니다.
활성화 지점을 정의하기: 유저가 가치를 처음 느끼는 순간
활성화는 유저가 제품의 핵심 가치를 처음 체감하는 순간입니다. 이 순간을 하나의 이벤트로 정의해 두지 않으면 리텐션이 왜 낮은지 설명할 수 없습니다. 가입 완료나 튜토리얼 시청은 여기에 해당하지 않습니다. 정의는 팀의 가설에서 출발해도 되지만, 90일 안에 데이터로 검증하고 필요하면 다시 써야 합니다.
정의하는 방법은 의외로 단순합니다. 이 앱이 존재하는 이유를 한 문장으로 적고, 그 문장이 실제로 일어났다고 증명할 수 있는 최소한의 행동을 고릅니다. 근태 앱이라면 첫 출근 기록이 오류 없이 저장된 시점입니다. 학습 매칭 서비스라면 프로필을 채우고 상대에게 첫 연락을 보낸 시점입니다. 구인 서비스라면 첫 지원서를 제출한 시점입니다. 공통점은 유저가 무언가를 받았다는 것이지, 우리가 무언가를 얻었다는 것이 아닙니다.
그래서 회원가입 완료는 활성화가 아닙니다. 가입은 우리 편의를 위한 절차이고, 유저 입장에서는 비용입니다. 프로필 사진 등록, 알림 허용, 튜토리얼 시청도 마찬가지입니다. 이런 항목을 활성화로 잡아 두면 숫자는 쉽게 오르지만 리텐션은 따라오지 않고, 팀은 왜 그런지 설명하지 못합니다.
활성화 지점을 정했다면 두 가지를 같이 측정합니다. 하나는 도달률, 즉 신규 유저 중 그 이벤트에 도달한 비율입니다. 다른 하나는 도달까지 걸린 시간입니다. 도달률이 낮으면 경로가 막힌 것이고, 도달률은 높은데 시간이 길면 경로가 굽어 있는 것입니다. 두 문제는 처방이 다릅니다.
정의가 맞는지 검증하는 방법도 있습니다. 활성화에 도달한 유저와 도달하지 못한 유저의 D7 리텐션을 비교하십시오. 격차가 뚜렷하게 벌어진다면 그 정의가 실제 가치 지점을 짚었다는 증거입니다. 격차가 미미하다면 정의가 틀린 것이고, 다른 행동을 후보로 놓고 같은 비교를 반복해야 합니다. 이 검증은 첫 90일 안에 반드시 한 번은 돌려야 합니다.
경로는 3단계에서 5단계 정도로 쪼개는 편이 적당합니다. 단계가 너무 적으면 어디서 막혔는지 보이지 않고, 너무 많으면 노이즈가 커져 판단이 흐려집니다. 각 단계의 이탈률을 보되, 가장 큰 이탈 구간 하나만 골라 고치고 다음 코호트에서 결과를 확인하는 방식이 안전합니다. 여러 곳을 동시에 바꾸면 무엇이 효과였는지 알 수 없습니다.
기술적으로 가장 중요한 준비는 출시 전에 끝내야 합니다. 이벤트 이름 규칙, 필수 속성, 유저 식별자 정책을 문서로 정하고 개발과 기획이 같은 표를 보는 상태로 출시하십시오. 계측을 나중에 붙이면 소급이 되지 않습니다. 첫 90일 데이터는 다시 만들 수 없고, 초기 코호트는 이후 어떤 코호트로도 대체되지 않습니다. 자체 제품을 직접 만들어 운영해 보면 이 순서를 어겼을 때 잃는 것이 무엇인지 분명해집니다. 개발이 끝나고 나서 지표를 고민하면 이미 늦습니다.
90일 안에 답해야 할 네 가지 질문
첫 90일의 목적은 성장이 아니라 학습입니다. 누가 남는가, 무엇을 하고 남는가, 어디서 떠나는가, 어떤 비용으로 데려왔는가. 이 네 가지에 근거를 갖고 답할 수 있으면 다음 분기의 의사결정이 추측에서 벗어납니다. 답이 없으면 예산을 늘리든 기능을 늘리든 결과를 해석하지 못한 채 운에 맡기게 됩니다.
첫째, 누가 남는지 봅니다. 잔존한 유저의 공통 속성을 찾는 작업입니다. 유입 채널, 지역, 기기, 직군, 사용 언어로 나눠 리텐션을 비교합니다. 특정 세그먼트만 뚜렷하게 남는다면 그 세그먼트가 지금 이 제품의 실제 시장입니다. 기획 단계에서 상정한 타깃과 다를 수 있고, 다르다면 그쪽이 맞습니다. 90일 뒤에 조정할 것은 유저가 아니라 우리의 타깃 정의입니다.
둘째, 무엇을 하고 남는지 봅니다. 잔존 유저가 반복해서 여는 화면과 반복해서 쓰는 기능의 분포를 확인합니다. 여기서 자주 발견되는 어긋남이 있습니다. 개발 공수를 가장 많이 넣은 기능이 사용 상위에 없고, 부수적으로 만든 기능이 상위에 올라와 있는 경우입니다. 이 신호를 무시하지 마십시오. 다음 분기의 로드맵을 다시 쓸 근거가 여기서 나옵니다.
셋째, 어디서 떠나는지 봅니다. 퍼널 단계별 이탈에 더해, 이탈한 유저의 마지막 세션에서 마지막으로 본 화면을 확인합니다. 그리고 기술 품질을 이 질문 안에 포함시켜야 합니다. 크래시, 응답 없음, 특정 기기에서만 느린 화면, 네트워크가 불안정한 환경에서의 실패는 별개의 엔지니어링 이슈가 아니라 리텐션이 낮은 직접적인 원인입니다. 저사양 기기 비중이 높은 시장이라면 이 항목의 가중치를 더 높여야 합니다.
넷째, 어떤 비용으로 데려왔는지 봅니다. 채널별 획득 비용은 반드시 채널별 리텐션과 나란히 놓고 봐야 의미가 생깁니다. 저렴하게 데려온 유저가 이튿날 전부 사라진다면 그 채널이 가장 비싼 채널입니다. 이 비교를 하려면 설치 시점에 채널 정보를 코호트에 태깅해 두어야 하고, 그 준비 역시 출시 전에 끝나 있어야 합니다.
같은 기간에 하지 말아야 할 일도 분명합니다. 대규모 광고 집행과 대대적인 기능 확장입니다. 지표 체계가 서기 전에 유입을 크게 늘리면 결과 해석이 불가능해지고, 기능을 한꺼번에 늘리면 어떤 변화가 무엇을 움직였는지 영영 알 수 없게 됩니다. 90일은 확장하는 기간이 아니라 좌표를 잡는 기간입니다.
운영 리듬도 정해 두십시오. 주 1회 같은 요일에 같은 형식으로 코호트를 검토하고, 상시로 보는 지표는 세 개에서 다섯 개로 제한합니다. 대시보드를 수십 개 만들어 두면 아무도 열지 않습니다. 매주 같은 세 숫자를 같은 자리에서 보는 팀이, 매주 다른 화려한 화면을 보는 팀보다 훨씬 빨리 배웁니다.
지표가 없으면 마케팅 예산을 쓸 수 없다
마케팅 예산은 좋은 제품을 빠르게 알리는 도구이지, 남지 않는 제품을 남게 만드는 도구가 아닙니다. 리텐션과 활성화가 검증되지 않은 상태에서 예산을 쓰면 떠날 사람을 비용을 들여 데려오는 셈이 됩니다. 유입이 늘수록 손실도 정확히 같은 속도로 늘어납니다. 계측이 먼저이고, 채널 확대는 그다음입니다.
순서는 어렵지 않습니다. 계측을 붙이고, 활성화 정의를 데이터로 검증하고, 코호트 간 리텐션이 흔들리지 않는 것을 확인한 뒤, 채널을 소규모로 나눠 테스트하고, 살아남은 채널만 키웁니다. 이 순서를 건너뛰면 예산은 학습이 아니라 소모가 됩니다. 반대로 순서를 지키면 같은 예산이 훨씬 오래 갑니다.
초기에는 유저 생애 가치를 알 수 없습니다. 데이터가 쌓이지 않았기 때문입니다. 그러면 획득 비용의 상한도 정할 수 없다는 뜻인데, 실무에서는 대리 지표로 판단합니다. 채널별 활성화 도달률과 30일 시점의 잔존이 그 역할을 합니다. 어떤 채널이 활성화까지 잘 데려오고 한 달 뒤에도 남아 있다면, 생애 가치를 정확히 모르더라도 그 채널에 더 쓸 근거가 됩니다.
크리에이티브와 제품의 일치도 지표로 관리할 수 있습니다. 광고 문구가 과장되면 클릭과 설치는 오르고 첫날 리텐션은 떨어집니다. 이 두 숫자를 같은 표에서 보는 순간 마케팅과 제품이 같은 대화를 하게 됩니다. 설치당 비용만 보는 조직에서는 이 대화가 일어나지 않고, 제품팀은 마케팅이 데려온 유저의 질을 탓하고 마케팅팀은 제품의 완성도를 탓하는 구도가 반복됩니다.
지표에는 주인이 있어야 합니다. 한 사람이 매주 같은 정의로 숫자를 뽑고 같은 형식으로 공유하고, 정의가 바뀌면 바뀐 시점을 기록합니다. 이 역할이 비어 있으면 몇 주 뒤에 같은 이름의 지표가 두 개의 값을 갖게 되고, 회의는 숫자를 해석하는 대신 숫자를 맞추는 데 쓰입니다.
90일이 지난 뒤 남는 것은 다운로드 그래프가 아닙니다. 우리 앱이 누구를 위해 무엇을 해 주는 물건인지에 대한, 데이터로 뒷받침된 답 하나가 남습니다. 그 답이 있으면 예산을 어디에 쓸지, 다음 분기에 무엇을 만들지, 어떤 요청을 거절할지가 자연히 정해집니다. 여우비 인터랙션이 자체 제품을 만들어 직접 운영하면서 동시에 고객사 개발을 하는 이유도 여기에 있습니다. 출시 이후에 던져야 하는 질문은 개발 단계의 질문과 다르고, 운영해 본 팀만 그 차이를 미리 설계에 넣을 수 있습니다.
출시를 앞두고 있다면 지금 점검할 것은 기능 목록이 아니라 이벤트 목록입니다. 이미 출시했다면, 오늘 기준으로 활성화 지점을 한 문장으로 적어 보십시오. 그 문장이 바로 나오지 않는다면 첫 90일에 할 일 중 가장 급한 일이 무엇인지도 함께 정해진 셈입니다.
