경찰과 도둑 앱 지표를 골라 매일 모으기로 한 이유

어드민 지표 대시보드를 만든 과정을 일곱 편으로 나눠 적었다. 이 글은 1편이다.

1. 경찰과 도둑 앱 지표를 골라 매일 모으기로 한 이유
2. 인스타그램 API로 경찰과 도둑 앱 하루치 지표를 구해 디스코드로 보내기
3. 서비스 계정으로 경찰과 도둑 앱의 Google Play 통계 CSV 받기
4. App Store Connect API로 경찰과 도둑 앱 다운로드와 노출 수 받기
5. GA4 Data API로 경찰과 도둑 앱과 웹사이트 지표 모으기
6. AdMob API 갱신 토큰으로 경찰과 도둑 앱 광고 지표 매일 받기
7. Supabase로 경찰과 도둑 앱 지표 대시보드 만들기

사업계획서 숫자 모으기

9월 말, 창업아이템 경진대회 사업계획서를 쓰고 있었다. 우리 팀은 '경찰과 도둑'이라는 앱을 만든다. 여럿이 밖에서 경찰과 도둑으로 나뉘어 뛰는 놀이를, 지도와 위치로 도와주는 앱이다.

계획서에는 숫자가 들어가야 했고, 숫자마다 출처가 필요했다. 그래서 서비스별 관리 화면인 콘솔을 하나씩 열어 파일을 받았다. App Store Connect에서는 나라별 노출수와 다운로드를, Play Console에서는 노출수와 설치 기기 수를 표 파일(CSV)로 받았다. AdMob 보고서와 서버에 저장된 기록(DB)에서 내보낸 users, game_results도 모았다.

여기까지는 괜찮았는데, 막상 AdMob 파일을 엑셀로 열어 보니 글자가 다 깨졌다. 글자를 저장하는 방식(인코딩)이 UTF-16이었고, 칸은 탭으로 나뉘어 있었다. 나중에 받은 Play 통계 파일도 UTF-16이었다(3편).

인코딩을 맞추고 나니 이번엔 날짜가 문제였다. 파일 세 개는 날짜를 적는 방식이 셋 다 달랐고, 설치라는 말도 파일마다 뜻이 달랐다. 계획서에 넣을 표 하나 맞추는 데 한참 걸렸다.

맞춰 놓고 나서도 막막했다. 콘솔마다 지표는 많은데, 그중 무엇이 우리 앱에 의미 있는 숫자인지부터 알기 어려웠다. 그래프로 그리는 것도 일이었다. 계획서에 넣을 차트 하나를 그리려 해도 날짜 칸부터 다시 맞춰야 했다.

그런데 이렇게 모아 놓고 보니, 광고비를 한 푼도 안 썼는데 App Store 노출 1위 나라가 일본이었다. 6월 29일~9월 26일 동안 일본이 4,270회로, 한국(2,585회)보다 많았다.

7월 4일 서울게임타운 행사 때 가입한 68명이 그 뒤 4주 동안 연 게임은 4판뿐이었다. 둘 다 원래부터 콘솔 어딘가에 있던 숫자였지만, 아무도 모아서 보지 않았다.

'다음 계획서 쓸 때 이걸 또 손으로 모아야 하나?' 싶었다. 그래서 흩어진 숫자를 팀만 들어가는 관리자 페이지(어드민) 한 화면에 모으기로 했다.

다섯 군데에 흩어진 숫자

여기에 우리 서버 DB의 가입자, 판 수, 참가 인원까지 있었다. 보려면 필요한 권한이 다 달라서 평소에는 잘 안 보게 됐다. 부스 다음 날 설치가 얼마나 늘었는지, 인스타 이벤트 게시물이 실제 다운로드로 이어졌는지처럼 두 곳 이상을 같이 봐야 하는 질문에는 답을 못 했다.

그래서 목표는 두 개로 잡았다. 하나는 마케터와 개발자가 같은 화면에서 같은 숫자를 보는 것이었고, 다른 하나는 콘솔이 기본으로 보여 주는 숫자 대신 우리 앱에 맞게 고른 지표를 보는 것이었다.

화면에서 바로 부르려던 처음 생각

처음에는 단순하게 생각했다. '다섯 곳 다 공식 API가 있겠지. 어드민 페이지가 열릴 때 API 불러서 차트로 그리면 끝.'

각 서비스에 프로그램으로 숫자를 요청하는 API만 연결하면 될 것 같아서, 걸리는 시간은 2~3주로 봤다. 그런데 공식 문서를 하나씩 확인해 보니 이 생각은 절반쯤 틀렸다.

설치 수 API가 없는 Google Play

Play Developer Reporting API라는 게 있길래 당연히 설치 수도 받을 수 있을 줄 알았다. 그런데 열어 보니 비정상 종료율, ANR 같은 품질 지표만 있었다.

설치와 스토어 통계는 파일을 보관하는 Cloud Storage 버킷에서 매일 갱신되는 월별 CSV로만 받아야 했다. 게다가 3~7일 늦게 채워졌고, 스토어 노출수는 이 CSV에 아예 없었다.

'API 불러서 차트로 그리면 끝'이라던 계획은 Play에서 시작부터 막혔다. 화면이 열릴 때 부를 API 자체가 없었다.

기다리면 사라지는 데이터

파일을 따로 받아야 하는 것만 문제는 아니었다. 인스타 계정 하루 지표는 한 번에 최근 30일까지만 물을 수 있고, 90일이 지나면 인사이트에서도 사라진다. App Store 분석 리포트 파일은 35일 뒤 지워진다.

화면을 열 때마다 API를 부르는 구조라면, 석 달 전 행사 주간을 보고 싶을 때 이미 데이터가 없다. 작년 같은 행사 때와 비교하려 해도 숫자를 받을 수 없다.

며칠 동안 바뀌는 숫자

게다가 처음 받은 숫자가 그대로 확정되는 것도 아니었다.

실제로 받아 보니 인스타 게시물 숫자는 2~3일이 지나야 거의 멈췄다(2편). 그래서 어제 숫자를 한 번 받고 끝내면, 나중에 바뀐 숫자는 반영하지 못한다.

하루치를 안 주는 인스타

원래는 이벤트 게시물의 오늘 조회수를 보고 싶었다. 그런데 인스타 게시물 인사이트는 누적값만 줬다. 문서에 기간이 lifetime으로 고정이고 바꿀 수 없다고 적혀 있었다.

그래서 하루치를 알려면 매일 같은 시각에 누적값을 기록해 두고 전날 값을 빼야 했다(계산 예시는 2편). 기록하지 않은 날의 숫자는 나중에 다시 받을 수 없다.

매일 모아 쌓는 구조

네 가지를 확인하고 나니 답이 하나로 좁혀졌다. 매일 정해진 시각에 모아서 우리 DB에 쌓기로 했고, 화면은 외부 API를 부르지 않고 우리 DB만 읽게 했다.

실제로는 이렇게 돌아가게 만들었다.

GitHub Actions (하루 한 번, 예약 실행)
  → 우리 웹 서버(Vercel)의 수집 주소를 부른다
      → 각 소스 API에서 숫자를 받는다
      → Supabase(Postgres) 테이블에 저장한다
어드민 화면
  → Supabase에서 읽는다
  → 실제 판 수만은 화면을 여는 순간 게임 서버에 묻는다(어드민 토큰이 있어야 열리는 기록이라)

예약 실행을 맡는 워크플로와 숫자를 저장하는 테이블은 7편에 적었다.

숫자가 며칠 동안 바뀔 수 있어서, 매번 최근 7일을 다시 받아 덮어쓰기로 했다. 가장 늦게 확정되는 Play가 7일이라서였다. 받은 기간의 줄을 지우고 새로 넣는 방식이라 몇 번을 다시 돌려도 결과가 같다.

어느 날 수집이 실패해도, 다음 날 수집에서 그날 숫자까지 다시 채운다. 호출 수는 늘지만 하루 한 번이라 각 API 한도에 한참 못 미친다.

화면에서 API를 부르려던 처음 생각에는 키 문제도 있었다. API를 부르려면 권한을 증명하는 키가 필요한데, 브라우저에서 부르면 그 키가 브라우저로 내려간다. 그러면 개발자 도구만 열어도 누구나 키를 볼 수 있다. 그래서 숫자를 모아 오는 코드(앞으로 수집기라고 부른다)는 서버에서만 돌리고, 키도 서버에만 두기로 했다.

수집기를 둘 곳은 이미 있었다. 노션 글을 우리 사이트로 옮기는 블로그 동기화가 같은 방식으로 돌고 있어서, 그 웹 저장소에 뒀다. 팀이 이미 아는 구조였고 게임 서버와 게임 DB에 부하가 가지 않는다. 대신 데이터가 게임 DB와 지표를 쌓는 Supabase 두 곳으로 나뉘는 건 받아들이기로 했다.

이 결정으로 실시간 숫자는 포기했다. 그래서 어드민 화면 맨 위에 "매일 아침 모은 어제까지의 숫자예요"라고 적어 뒀다.

더할 수 없는 숫자들

모으는 구조를 정하고 나서 무엇을 보여 줄지 고민했다. 처음엔 총 설치 수 카드 하나를 크게 두고 싶었다. App Store 다운로드, Play 설치, GA4 첫 실행을 더하면 될 줄 알았다. 그런데 세 곳이 설치로 세는 순간이 다 달랐다.

무엇을 세는지도 다른데 하루의 기준까지 달랐다. GA4는 속성에 정해 둔 시간대(우리는 한국)를 따랐다. App Store는 판매 리포트가 한국 날짜와 맞았고, 분석 리포트는 UTC(세계 표준시)를 썼다(4편). 인스타와 Play는 미국 서부 날짜를 썼다(2편, 3편).

이 숫자들을 더하면 무엇을 센 값인지 설명하기 어려웠다. 그래서 총 설치 수 하나로 보여 주는 대신, 소스별로 나란히 두고 카드마다 무엇을 셌는지 한 줄씩 적었다.

다만 App Store 첫 다운로드와 Play 최초 설치는 둘 다 처음 받은 것만 세서 "스토어 최초 설치"로 더하고, 그 아래에 스토어별 숫자를 같이 적었다. GA4 첫 실행은 더하지 않았다(7편).

이름은 같고 뜻은 다른 지표

설치만 그런 게 아니었다. 지표의 뜻을 확인하려고 공식 정의를 하나씩 대조해 보니, 이름만 보고 생각했던 것과 다른 경우가 더 있었다.

App Store 전환율은 앱을 본 고유 기기 수(고유 노출)를 분모로 삼은 값이었다. 그런데 인터넷에 도는 벤치마크는 대부분 페이지 조회를 분모로 쓰고 있어서, 우리 콘솔 숫자와 나란히 놓을 수 없었다(4편).

Play의 전환율은 2026년 6월에 클릭률로 바뀌었다. 7월에는 방문자 세는 방식도 바뀌어서, 6월 전후를 한 그래프에 이으면 같은 기준으로 비교하기 어렵다. 수집기가 받는 파일에는 아직 옛 지표가 들어 있는데, 이 이야기는 3편에 쓴다.

인스타 profile_links_taps는 주소, 전화, 이메일 버튼을 누른 횟수였다. 이름만 보면 프로필 링크 클릭 같지만, 그 값은 profile_activity를 쪼갠 bio_link_clicked에 있었다.

AdMob의 fill rate도 노출률이 아니라 매치율의 다른 이름이었다(자세한 건 6편에 쓴다). 이름만 보고 썼으면 틀릴 뻔했다.

우리 앱에 맞는 지표 고르기

지표의 뜻을 확인하고 나니, 이번에는 어떤 숫자를 앞에 둘지 골라야 했다. 처음엔 하루 사용자(DAU), 한 달 사용자(MAU), 처음 온 뒤 1일, 7일째에 다시 온 비율(D1, D7 리텐션)처럼 다들 보는 지표를 그대로 쓰려고 했다.

그런데 출처를 따라가 보니 아무 앱에나 맞는 기준이 아니었다. 하루 사용자를 한 달 사용자로 나눈 값(DAU/MAU)이 20%면 좋다는 말은 연구 결과가 아니라 업계 통념이었다. 그 지표를 퍼뜨린 Andrew Chen도 띄엄띄엄 쓰는 제품에는 안 맞는다고 직접 썼다. D1, D7 벤치마크는 매일 켜는 휴대폰 게임 기준이었다.

미국 벤처 투자사 a16z는 다운로드와 누적 가입자를 보기에만 좋은 숫자, 이른바 허영 지표의 대표로 꼽는다. 사업이 줄어도 쌓인 숫자는 줄지 않으니, 그래프는 계속 오른쪽 위로 올라간다.

우리 앱은 혼자서는 쓸 수 없다. 최소 세 명이 같은 시간에 같은 곳에 모여야 한 판이 열린다. 매일 하는 것도 아니고 친구들끼리 약속을 잡아 가끔 한다. 그래서 단위부터 다시 잡았다. 사용자 한 명보다 성사된 한 판을 단위로 보기로 했다.

가장 위에 두고 팀이 함께 볼 숫자(북극성 지표)로 주간 플레이 인원을 제안했다. 그 주에 3명 이상이 시작해서 끝까지 간 판에 참여한 인원의 합이다. 나눠 보면 판 수 × 판당 인원이다.

고를 때는 Amplitude가 북극성 지표 안내서에 적어 둔 조건에 맞춰 봤다. 이 숫자는 사용자가 실제로 친구와 뛴 경험을 그대로 센다. 판이 끝날 때 광고가 나가니, 이 숫자가 먼저 움직이고 수익은 그 뒤를 따른다.

마케터처럼 개발을 하지 않는 사람도 알아듣는 숫자이고, 팀이 버튼 하나로 바로 바꿀 수 있는 숫자도 아니다. 다만 아직 제안 단계라 팀이 같이 보고 확정해야 한다. 행사가 있는 주에는 평소보다 많이 늘어나는 숫자라, 그 주까지 네 주의 평균(4주 이동평균)과 행사 판을 뺀 값을 같이 보기로 했다.

그다음에는 주간 플레이 인원에 영향을 주는 숫자로 다섯 개를 골랐다. 팀 안에서 쓰는 지표 설계 문서에 적은 그대로다.

이 다섯 개는 설계로 정한 목록이다. 지금 요약 탭의 핵심 비율에는 사이트 전환율, 활성화율(첫 실행 후 7일 안에 게임에 참가한 비율), 다음 날 다시 온 비율, Android 삭제 비율이 나온다(7편). 판 성사율과 방장 전환율은 계산하기 전에, 시작하지 못한 방과 방장이 서버 기록에 남는지부터 확인해야 했다.

추정 대신 세는 행사 효과

우리 팀은 오프라인 행사를 자주 나간다. 이번 행사에 효과가 있었는지 답하려고 처음엔 CausalImpact 같은 통계 도구를 찾아봤다.

그런데 하루 가입이 몇 명 수준이면 이런 도구는 아주 큰 효과만 잡아낸다. 광고비 변화와 성과를 함께 분석하는 마케팅 믹스 모델(Meridian, Robyn)은 2~3년치 데이터와 광고비 변화가 필요하다. 우리 광고비는 처음부터 0원이라, 바뀐 적이 한 번도 없었다.

우리 규모에는 맞지 않는 도구였다. 그래서 처음부터 어디서 왔는지 나눠 세도록 설계하기로 했다. 행사와 자리마다 링크를 따로 만들고, 링크마다 어디서 온 방문인지 표시하는 꼬리표(UTM)를 다르게 붙인다. 그 링크로 QR을 뽑는 방식이다.

예전에 이런 용도로 많이 쓰던 Firebase Dynamic Links는 2025년 8월에 종료돼서 쓸 수 없었다. 그래서 QR은 우리 사이트의 /download로 보낸다. 이 페이지가 폰에 맞는 스토어로 넘기면서 꼬리표를 이어 준다.

아이폰은 App Store 캠페인 토큰(ct)으로, 안드로이드는 Play 설치 리퍼러로 꼬리표가 넘어간다(5편). 그래서 사이트 방문과 스토어로 넘어간 수를 링크별로 나눠 볼 수 있고, 안드로이드는 첫 실행까지 구분할 수 있다.

행사 링크 등록 칸

그런데 막상 링크를 만들려니 조금 번거로웠다. 꼬리표를 붙이려면 /download?utm_source=...&utm_medium=...&utm_campaign=...를 손으로 이어 붙여야 했다. 주소가 길면 QR 점이 촘촘해져 멀리서 잘 안 읽힌다. 영어 꼬리표 규칙을 아는 사람만 만들 수 있었고, App Store는 출처, 캠페인, 구분을 이은 이름이 30자를 넘으면 잘라 버린다.

그래서 어드민에 링크를 등록하는 칸을 만들었다(#171). 어디에 쓰는지(부스, 포스터, 블로그 등)와 무슨 일정인지만 고르면 영어 꼬리표와 짧은 주소 copsandrobbers.app/q/<코드>가 자동으로 정해진다. 만들면 인쇄용 QR이 바로 내려받아지고, 목록에는 그 링크로 온 방문, 스토어로 이동, 안드로이드 첫 실행이 같이 나온다.

이 글에도 실제 QR을 하나 넣었다. 이 연재를 블로그에 올리는 날을 홍보 일정으로 달력에 넣고, 그 일정에 맞춰 블로그용 링크를 만들었다. 꼬리표는 쓸 곳(blog)과 일정 번호에 따라 자동으로 정해졌다.

이 QR을 찍으면 폰에 맞는 스토어로 간다. 그 방문은 어드민의 이 링크 줄에 블로그에서 온 방문으로 따로 잡힌다.

다만 아이폰은 앱 안에서 어느 링크로 왔는지 아직 알 수 없다. 그래서 가입 화면에서 행사 코드를 받도록 설계까지 했지만, 앱에는 아직 넣지 못했다.

부스별, 업데이트별 성적

링크를 나눠 세도, 숫자가 갑자기 바뀐 날은 그 이유를 따로 찾아야 했다. 우리 팀은 부스를 열고 축제에 나가는 일이 잦아서, 그날 행사가 있었는지 앱 업데이트를 냈는지부터 확인해야 했다. 처음 설계에는 없던 부분인데, 지표 화면을 쓰다 보니 필요해서 일정을 더했다.

일정은 행사, 홍보, 출시, 테스트, 기타로 나눠 달력에 넣는다. 앱 업데이트 날짜는 수집기가 스토어에서 버전이 바뀐 날을 찾아 자동으로 넣고(3편, 4편), 나머지는 달력에서 직접 넣는다. 넣은 일정은 모든 차트 위에 성격별 색 마름모로 표시된다. 링크를 만들 때 고른 일정도 같이 저장돼서, 어느 행사의 QR인지 목록에서 바로 보인다.

부스 하나하나는 행사 성적표로 본다. 달력에서 행사 날을 누르면 그날 열린 게임이 장소별로 묶여 나오고, 그중 우리 부스 게임을 고른다. 9월 19일처럼 반포와 어린이대공원 두 곳에서 같은 시간에 행사를 한 날도 지도에서 나눠 고를 수 있다.

고르고 나면 그 행사에서 몇 판을 했고 방문객을 몇 명 만났는지, 그날 설치와 가입이 평소보다 어땠는지가 한 장에 나온다. 행사가 주말에 몰려서, 평소 숫자는 바로 앞 같은 요일 네 번의 평균으로 잡았다. 다만 행사와 같은 날 나온 숫자라는 것만으로 행사 효과라고 단정하지는 않는다.

예상과 다른 첫 퍼널

이 설계로 수집기와 화면을 만들고 나서, 신규 사용자가 앱을 처음 연 뒤 7일 안에 어디까지 가는지 단계마다 남은 사람 수를 퍼널로 그려 봤다. 처음 만든 날은 10월 6일이었다. 9월 8~21일에 처음 연 한국 사람만 넣어 보니 이랬다.

구글이나 애플 로그인을 거쳐야 해서 로그인 단계에서 많이 빠질 줄 알았는데 92%가 넘어갔다. 가장 많이 줄어든 건 다음 주에도 플레이하는 단계였다. 게임을 한 51명 중 다음 주에도 플레이한 사람은 4명이었다. 행사에서 한 번 하고 끝나는 경우가 많았다.

그런데 나라를 다 넣은 지금 화면에서는 로그인 단계로 78%만 넘어가, 첫 네 단계 중 여기서 가장 많이 빠진다. 어느 나라를 넣느냐에 따라 많이 빠지는 단계가 달라 보여서, 화면 위 나라 버튼으로 골라 본다.

숫자를 보고 나니 마케팅으로 사람을 더 데려오기 전에, 한 번 온 사람이 다시 하게 만드는 게 먼저일 것 같았다. 이 퍼널을 만들기 전에, 안드로이드 첫 실행의 절반 가까이가 사람이 아니었다는 것도 알게 됐다. 그 이야기는 5편에 쓴다.

매일 모아 쌓기로 하고 화면을 만든 뒤에야, 흩어져 있던 숫자를 나란히 볼 수 있었다.

미리 걸어 둘 권한

2편부터는 소스마다 실제로 접근 권한을 연결하고 숫자를 받아 온 과정을 지금 화면 기준으로 적는다. 권한을 연결하는 순서는 이렇게 하는 걸 추천한다.

App Store는 분석 리포트를 신청하고 첫 파일을 받기까지도 1~2일이 걸렸다(4편). 기다리는 시간이 긴 것부터 신청해 두면 개발하는 동안 권한이 생기고 데이터가 쌓인다. 특히 Play는 초대하고 하루 넘게, 접근이 거부됐다는 403만 보며 기다렸다. 그 이야기는 3편에 쓴다.

어디서 무엇을 받을지, 그리고 그중 무엇을 볼지까지는 정했다. 다만 북극성 지표로 제안한 주간 플레이 인원은 아직 팀과 확정하지 못했다. 그래서 가장 먼저 손댄 건 마케터가 다음 날부터 바로 쓸 수 있는 인스타였다. 인스타 숫자는 시간이 지나면 사라지기도 했다. 다음 편에는 인스타 숫자를 받아 디스코드로 리포트를 보내기까지의 과정을 적었다.

다음 편: 2편 인스타그램 API로 경찰과 도둑 앱 하루치 지표를 구해 디스코드로 보내기