지표 보기

allob 이 받은 이벤트로 퍼널, 방문 기기, 리텐션, 유입 경로를 계산해요. 웹에서는 제품의 지표 탭에서 보고, 에이전트에게는 숫자를 읽고 해석해 달라고 부탁하면 돼요.

#에이전트에게 맡기기

allob metrics board --days 30 --json 으로 지난 30일 지표를 보고 요약해 줘.
퍼널에서 가장 많이 떠나는 단계, 지난주 대비 방문 기기 변화, 기록된 릴리스·마케팅 변경 중 숫자가 크게 움직인 시점을 알려 줘.

특정 변경의 효과가 궁금하면 이렇게 물어요.

allob metrics impact 1.4.0 으로 1.4.0 릴리스 전후 7일을 비교해서, 결제 단계 비율이 어떻게 바뀌었는지 알려 줘. 같은 기간에 다른 변경도 있었다면 함께 알려 줘.

#지표 탭 항목

• 매출·광고 숫자 옆의 ▲▼ 도 요즘 흐름과 같은 기준(최근 7일과 그 전 7일)이에요. 좋은 방향이면 초록, 나쁜 방향이면 빨강이고(±8% 안은 회색), 광고비처럼 좋고 나쁨이 없는 숫자는 회색이에요. CAC 는 내려가면 초록이에요.
• 사람 수는 기기 기준이에요. 같은 사람이 휴대폰과 노트북으로 오면 둘로 세요.
• 날짜는 한국 시간 기준이에요.
• 기간은 1~90일을 고를 수 있어요. 계산 결과는 5분 동안 저장해 두고, 바로 다시 계산하려면 --fresh 를 붙여요. 웹에서는 지표 탭을 켜 두면 5분마다, 다른 탭에 갔다 돌아오면 1분이 지났을 때 새 숫자를 받아요. 기간 옆 "12:03 기준"이 숫자를 계산한 시각이고, 다시 계산을 누르면 바로 새로 계산해요.
• 데이터가 아주 많아서 숫자가 실제보다 작게 나올 수 있거나 추정값이면 화면에 그렇다고 표시해요.

#매출

매출 연결이 있으면 allob 이 몇 시간마다 날마다 매출을 모아요. 지표 탭의 매출 카드와 CLI 에 같은 숫자가 나와요.

allob revenue view                         # 최근 30일 — 합계, 출처마다, 최근 7일, 출처마다 언제 모았나
allob revenue view --currency KRW --days 7
allob revenue setup --currency KRW --vendor-number 87654321
allob revenue setup --vendor-number none   # 공급업체 번호 지우기
allob revenue setup --play-bucket gs://pubsite_prod_rev_01234567890987654321   # Google Play 보고서 버킷
allob revenue collect                      # 지금 모으기(제품마다 10분에 한 번)

• 날마다 원래 통화로 남겨 두고, 볼 때 한 통화로 바꿔요. 환율은 그날의 유럽중앙은행(ECB) 기준 환율(frankfurter.dev)이에요. ECB 가 고시하지 않는 통화(30여 개 통화 밖 — 예: TWD·VND)는 fawazahmed0 currency-api의 같은 날 환율을 써요. 주말·공휴일처럼 그날 환율이 없으면 7일 안의 가장 가까운 앞 날 환율을 써요. 어느 환율로 바꿨는지는 매출 카드와 allob revenue view 아래에 적혀 있어요.
• 환율은 allob 이 매시간 미리 채워 둬요. 그래도 환율이 없는 통화는 합계에서 빼고 그렇다고 알려 줘요. 장부(세금 신고 준비)는 이 환율이 아니라 한국수출입은행 매매기준율을 써요(장부).
• 결제한 사람 수와 1인당 금액은 allob 이 직접 받은 결제(결제 기록하기)에서 세요. 광고 수익이나 결제 알림을 받지 않는 출처는 1인당 금액에 들어가지 않아요.
• 받는 돈은 손님이 낸 돈에서 환불과 수수료를 뺀 금액이에요. Dodo 는 결제 수수료를 지급할 때 떼고, 결제 목록에는 수수료가 없어요. 그래서 Dodo 결제가 있는 날과 합계의 받는 돈은 "모름"으로 둬요(일부만 더한 합계는 총매출과 맞지 않으니까요). 받는 돈을 모르는 결제가 없는 날은 그날 받는 돈을 보여 줘요.
• RevenueCat 은 App Store 구매도 함께 세요. 그래서 RevenueCat 이 연결돼 있으면, RevenueCat 이 모은 날부터는 App Store 판매 보고서를 합계에서 빼고(같은 구매를 두 번 세지 않게) 출처마다에만 보여 줘요. 그 앞 날은 App Store 판매 보고서로 세요.
• Dodo 결제가 많아 한 번에 다 못 읽으면 기간을 나눠 다시 읽어요. 하루 안에서도 다 못 읽으면 그 출처는 "못 모았어요"로 남기고, 덜 센 숫자로 덮지 않아요.
• 처음 모을 때 App Store 는 7일을 거슬러 봐요(날마다 따로 불러야 해서요). 그 뒤로 모을 때마다 7일씩 더 거슬러 올라가 30일을 채워요. Dodo·RevenueCat·AdMob 은 처음부터 30일이에요.
• 며칠 못 모았다가 다시 되면, 마지막으로 모은 날부터 어제까지 한 번에 다시 모아요(30일까지).
• RevenueCat 이 아직 덜 셌다고 알려 주는 최근 날은 남겨 두지 않고, 다음에 모을 때 다시 가져와요. 그동안 그날 막대는 흐리게 보여요. RevenueCat 키에 Charts 읽기 권한이 없으면(Overview 읽기만 있으면) 최근 10일만 날마다 따로 모으고, 지표 카드와 연결 화면에 그렇다고 알려 줘요. 키 권한에 Charts 읽기를 추가하면 다음 모으기부터 30일을 한 번에 채워요.
• 출처마다 마지막으로 모은 때, 오류, 오래됐는지(하루 넘게 못 모음)를 카드와 allob revenue view 에서 보여 줘요. 못 모은 출처가 있으면 그 연결을 확인해 주세요.
• App Store 공급업체 번호는 App Store Connect › 결제 및 재무 보고서 화면 왼쪽 위에 있어요. 제품 › 설정의 매출 카드에서도 넣을 수 있어요.
• Google Play 매출은 Play Console 이 Cloud Storage 에 올리는 달마다 판매 보고서에서 읽어요. 보고서 버킷은 Play Console › 보고서 다운로드 › 재무에서 'Cloud Storage URI 복사'를 누르면 나와요. 버킷은 Play 개발자 계정에 하나라서 Google Play Console 연결에 넣고, 그 연결을 쓰는 제품이 모두 같이 써요(연결 › Google Play Console 관리, 또는 allob revenue setup --play-bucket).
• 서비스 계정이 보고서를 읽으려면 Play Console › 사용자 및 권한에서 '재무 데이터 보기'를 계정 전체로 줘야 해요(앱별 권한으로는 못 읽어요). 이 권한은 사람이 직접 줘요. 준 직후에는 하루쯤 지나야 읽히기도 해서, 그동안은 "못 모았어요"로 보이고 allob 이 계속 다시 모아요.
• 판매 보고서에는 구글 수수료가 없어요. 그래서 같은 버킷의 달마다 수익 보고서(earnings/)에서 구글이 실제로 뗀 수수료를 주문마다 가져와 받는 돈을 채워요. 15%·30% 중 어느 쪽인지 짐작하지 않고 구글이 뗀 금액 그대로예요. 수익 보고서는 다음 달 초에 나와서 이번 달 받는 돈은 "모름"으로 두고, 카드와 allob revenue view 에 언제까지 아는지와 다음 달 초에 채워진다는 것을 알려 줘요. 수익 보고서는 파일이 바뀌었을 때만(새로 나오거나 조정 파일이 더 올라왔을 때) 다시 받아요. 읽다 실패하면 이미 채운 받는 돈은 그대로 두고 매출은 그대로 모아요. 수익 보고서가 너무 크면(압축 20MB·압축을 푼 80MB 넘음) 그 달 받는 돈은 비워 두고 매출 카드에 그렇다고 알려 줘요. 그날 주문 중 하나라도 수수료를 아직 모르면 그날 받는 돈도 "모름"이에요. 까닭은 둘이에요 — 환불한 주문의 돌려받은 수수료가 다음 보고서에 올 때처럼 나중에 채워지는 날, 결제와 환불이 다른 날에 걸쳐 수수료를 그날로 나눌 수 없거나, 결제 다음 달보다 늦게 환불해 돌려받은 수수료를 그 주문에 맞출 수 없을 때처럼 채워지지 않는 날. 카드와 allob revenue view 가 둘을 따로 알려 줘요. 환불만 있는 날도 받는 돈을 모르면 "모름"이에요(환불을 빼지 않은 받는 돈이 부풀지 않게). 같은 권한(재무 데이터 보기)으로 읽어서 따로 설정할 것은 없어요.
• 판매 보고서에서는 주문 번호·날짜·결제 시각·제품·통화·금액·상태·구매자 나라만, 수익 보고서에서는 주문 번호·거래 종류·제품·구매자 통화·금액만 읽어요. 주문 번호는 두 보고서를 연결하는 데만, 결제 시각과 나라는 장부에서 한국 날짜와 한국·해외 매출을 나누는 데만 쓰고 남기지 않아요. 구매자 도시·우편번호 같은 다른 정보는 읽지 않아요.
• 결제 알림을 받는 결제 서비스(Dodo·RevenueCat)는 받은 결제와 그 서비스가 보고한 매출을 비교해요. 둘 다 아는 날만 봐요 — 기간 첫날, 결제 알림을 연결한 다음 날, 그 서비스에서 매출을 모으기 시작한 날 중 늦은 날부터 모은 마지막 날(어제까지)까지예요. 맞으면 한 줄로, 다르면 경고와 결제 알림 설정으로 가는 링크를 보여 줘요. 결제 알림을 연결하지 않았거나 비교할 날이 없으면 아무 말도 하지 않아요.
• RevenueCat 은 USD 로 바꾼 금액만 알려 줘서 건수는 비교하지 않고, 환율 차이로 2% 까지는 맞는 것으로 봐요. 날짜 기준이 조금 달라서 마지막 날 하루는 비교에서 빼요. 0원 결제(쿠폰 100% 등)는 양쪽 모두 건수에 넣지 않아요.
• 결제가 아주 많아(5,000건 넘게) 한 번에 다 읽지 못하면 요약과 광고로 온 결제는 최근 5,000건으로 세고 그렇다고 알려 주고, 결제 채널 비교는 하지 않아요.
• AdMob 의 노출 수도 함께 모아요. eCPM 은 수익과 노출을 둘 다 아는 날만 합쳐 계산하고, 노출을 모르는 날이 있으면 매출 섹션의 앱 광고 수익 묶음 아래에 그렇다고 알려 줘요.
• Google Play 의 낸 돈은 손님이 실제로 낸 금액(Charged Amount)에서 세금(Taxes Collected)을 뺀 값이에요. 무료 체험을 시작한 줄처럼 낸 돈이 0 인 줄은 매출로도 건수로도 세지 않아요. 환불은 보고서의 환불·지급 거절 줄로 세요. 보고서에 패키지 이름 열(Package ID)이나 Charged Amount 열이 없으면 "못 모았어요"로 남겨요. 보고서 모양이 예상과 달라 어느 날 합이 0 아래로 나오면 그 출처는 "못 모았어요"로 남기고, 음수 매출은 쓰지 않아요.
• RevenueCat 프로젝트에 그 Play 앱이 있으면 Google Play 판매 보고서도 App Store 처럼 RevenueCat 이 모은 날부터 합계에서 빼요(같은 구매를 두 번 세지 않게). RevenueCat 에 Play 앱이 없으면 그대로 세요.
• RevenueCat 의 받는 돈(proceeds)은 RevenueCat 이 추정한 금액이에요. App Store 앱은 RevenueCat 에 Apple Small Business Program 가입일이 없으면 수수료를 30% 로 셈해요(Google Play 는 15% 를 RevenueCat 이 알아서 적용해요). RevenueCat 은 이 설정을 API 로 알려 주지 않아서, allob 이 스토어마다 같은 날의 실제 받는 돈과 비교해요 — App Store 는 판매 보고서, Google Play 는 수익 보고서예요. RevenueCat 차트를 스토어별로 걸러 읽어서 App Store 와 Google Play 가 같이 있는 프로젝트도 따로 비교해요. 스토어별 차트는 비교할 스토어(App Store 공급업체 번호·Play 보고서 버킷)가 이어져 있을 때만, 제품마다 하루 한 번 읽어요. 읽다 실패해도 RevenueCat 매출은 그대로 모아요.
• 손님이 낸 돈부터 RevenueCat 과 스토어가 5% 넘게 다르면(RevenueCat 에 없는 옛 구독자, 환불 시점, 세금 셈 등) 받는 돈 차이를 수수료 탓으로 볼 수 없어서 판단하지 않아요. 낸 돈이 맞고 App Store 결제가 20건 넘게 쌓였는데 RevenueCat 받는 돈이 실제의 76~88%(30% 와 15% 의 차이만큼)면 "Apple Small Business Program 에 가입했다면 RevenueCat 에도 가입일을 넣어 주세요"라고 알려 줘요. 가입하지 않았다면 그대로 두면 돼요. 가입일은 RevenueCat 프로젝트 › Apps › App Store 앱 › Apple Small Business Program 에 넣어요. RevenueCat 이 지난 차트도 하루 안에 다시 계산해요.

#결제 한 건 한 건

지표 › 매출의 결제 보기를 누르면 결제 알림으로 받은 결제를 날마다 묶어 새것부터 보여 줘요(결제 기록하기). 기간(7·30·90일)과 종류(전체·결제·환불·구독)를 고를 수 있어요.

• 위에는 기간 요약이 있어요 — 결제 건수(구독 갱신은 따로), 받은 돈(통화마다, 환불을 뺀 금액), 환불 건수, 광고로 온 결제 건수.
• 줄마다 금액, 시각, 상품, 결제 서비스가 나오고, 전액·일부 환불과 구독 시작·갱신은 꼬리표로 붙어요.
• 광고로 온 결제는 "광고 · 실험 이름 · 그룹"으로 보이고, 누르면 광고 화면에서 그 실험을 열어요. 광고 실험이 아닌 utm 으로 왔으면 "utm · 출처/캠페인"으로 보여요.
• 시험 결제와 0원 결제, 무료 체험 시작은 빼요. 뺀 기기·운영자 계정의 결제는 제외 꼬리표를 달고 받은 돈에만 넣어요(내 결제 빼기). 손님 id·기기·나라 같은 손님 정보는 보이지 않아요. 50건씩 보여 주고 더 보기로 이어서 봐요.

#무료 체험

무료 체험이 들어온 적 있는 제품은 기간 요약 아래에 무료 체험이 보여요. 이 기간에 시작한 체험만 묶어서 세요. 비율은 이미 끝난 체험(유료로 바뀌었거나, 체험이 끝났다는 알림이 왔거나, 체험 기간이 지나고 이틀이 더 지난 체험)만으로 계산하고, 아직 진행 중인 체험은 따로 "진행 중 N명"으로 적어요. 진행 중인 체험을 넣으면 체험이 막 시작된 기간의 비율이 낮게 나오니까요. 체험이 끝난 뒤 이틀은 결제 알림이 늦게 올 수 있어서 기다려요.

• 숫자마다 "N명 중 M명"으로 표본 수를 같이 보여 줘요. 표본이 20명보다 적은 비율(나눠 보기 줄도)에는 표본 적음을 붙이고, 크게 바뀔 수 있다고 알려 줘요.
• 나눠 보기로 체험 길이(일)·상품·스토어마다 체험 시작·끝남·체험 전환율·체험 중 해지율을 봐요. 둘 이상으로 나뉘는 것만 보여요.
• 체험 하나는 구독 하나예요(같은 결제 서비스·같은 구독). 시험 체험과 뺀 기기·운영자 계정의 체험은 세지 않아요.
• 스토어를 기록하기 전에 들어온 앱 체험은 스토어가 "알 수 없음"으로 나와요. 웹 결제(Dodo) 체험은 "웹 결제"예요.
• 체험이 아주 많아 다 읽지 못하면 앞쪽 체험만 세고 그렇다고 알려 줘요.

#퍼널 나눠 보기

allob metrics funnel                         # 나눠 볼 수 있는 것
allob metrics funnel --by utm_source         # 유입 소스별
allob metrics funnel --by prop:entry_write.mood --days 14
allob metrics funnel --by exp:pricingCopy     # 제품 안 A/B — 그룹마다

기기마다 그 값을 처음 보냈을 때의 값으로 묶어요. utm·나라·언어는 퍼널 첫 단계 이벤트의 값이에요. 이벤트 속성은 퍼널 단계 이벤트의 속성 중 고를 수 있어요. 기기가 많은 묶음 6개를 보여 주고, 나머지는 "기타"로 합쳐요. 값이 없는 기기는 "값 없음"으로 묶여요. utm 은 유입 소스(utm_source)·매체(utm_medium)·캠페인(utm_campaign)·소재(utm_content)로 나눠 볼 수 있어요. 매체는 SDK 가 utm_medium 도 보내기 시작한 뒤에 들어온 기기부터 보여요(그 전 기기는 "값 없음").

#제품 안 A/B 결과

스키마 experiments 에 적은 실험은 "실험: 이름"으로 나눠 볼 수 있어요(제품 안 A/B).

• 실험 화면을 본 기기만 세요. 기기의 그룹은 처음 본 때의 그룹이에요. 보기 전에 한 단계(들어옴·쓰기처럼 첫 단계)는 본 때에 한 것으로 치고, 전환(마지막 단계)은 본 뒤에 했을 때만 세요.
• 그래서 실험 결과의 전환 수는 전체 퍼널과 조금 다를 수 있어요. 전체 퍼널은 단계마다 처음 한 때로 순서를 보고, 실험 결과의 전환은 본 뒤 마지막으로 한 때로 봐요(보기 전에 이미 결제한 기기가 다시 결제해도 전환으로 세요).
• 기간은 실험의 시작일(startedAt)부터 끝난 날(endedAt)까지로 잘라요. 끝난 실험은 끝난 날을 기준으로 고른 기간만큼 봐요.
• 그룹마다 본 기기, 끝 단계까지 간 기기, 전환율을 보여 주고, 첫 그룹(기준)과 얼마나 다른지 알려 줘요. 차이가 작아 우연일 수 있으면 그렇다고 알려 줘요.
• 그룹마다 본 기기가 100대, 전환이 20건이 안 되면 "아직 판단하기 일러요"로 보여요. 막지는 않아요. 언제 끝낼지는 직접 정해요.
• 로그인한 사용자에게 setUserId 를 부르면 그룹은 사용자 id 로 정해져서 웹·앱·다른 기기에서도 같아요. 그래도 결과는 기기마다 세요 — 같은 사람이 두 기기로 봤으면 두 대로 세요.
• 차이가 우연인지는 그룹 둘을 한 번 비교할 때의 셈이에요. 그룹이 셋 이상이거나 결과를 여러 번 들여다보며 끝낼 때를 고르면 우연한 차이가 진짜처럼 보일 수 있어요(보정하지 않아요). 끝낼 날을 미리 정해 두는 게 좋아요.
• 두 그룹 이상으로 기록된 기기가 있으면 몇 대인지 알려 주고, 처음 그룹으로만 세요.
• 그룹이 설정한 비율과 많이 다르게 나뉘었거나, 스키마에 없는 그룹으로 기록된 기기가 있으면 노출을 보내는 코드를 확인하라고 알려 줘요.
• 앱이 버전을 보내면(앱 SDK version) 그룹마다 앱 버전별로도 나눠서 본 기기·끝 단계까지 간 기기·전환율을 보여 줘요(--json 의 groups[].versions). 기기의 버전은 처음 본 때의 앱 버전(빌드 번호는 빼고)이에요. 실험 중에 새 버전이 나가면 그룹끼리 버전 비율이 같은지 여기서 확인해요.

#이벤트 하나 자세히 보기

이벤트 하나를 날마다·나라·언어·앱 버전·속성 값으로 묶어 볼 수 있어요. 이벤트에 숫자 속성(column: "double1" — 걸린 시간, 점수, 금액)이 있으면 묶음마다 합·평균·중앙값(p50)·95% 지점(p95)·최댓값도 보여 줘요.

allob metrics events net_lag                 # 날마다 이벤트 수·기기 수·p50·p95
allob metrics events game_end --by mode      # 속성 값마다
allob metrics events purchase --by country --days 7

• --by 를 빼면 날마다(한국 날짜)예요. 이벤트가 없던 날은 0 으로 보여요.
• 속성은 글자 필드 속성(column: "blob8"·"blob9")과 값 목록 속성 중 앞쪽 것을 고를 수 있어요. 고를 수 있는 것은 결과 끝의 Group by 줄에 나와요.
• 날마다가 아니면 이벤트가 많은 묶음 20개를 보여 주고 나머지는 [other] 로 합쳐요(이벤트 수·합만). [all] 은 전체예요.
• 같은 이벤트를 다시 보낸 것은 한 번으로 세요. 기기 ID 는 보여 주지 않아요.

#aha 찾기와 북극성 지표

오래 쓰는 사용자들이 처음 며칠 동안 공통으로 한 행동을 찾아 줘요. 예를 들어 "처음 3일 안에 스티커를 5개 저장한 사람은 한 달 뒤에도 절반이 돌아오는데, 그러지 않은 사람은 12%만 돌아온다" 같은 것이에요. 이런 행동을 흔히 aha 모먼트라고 불러요. 하나를 골라 북극성 지표로 정해 두면, 그 뒤엔 실험과 기능을 "처음 며칠 안에 그 행동까지 가는 새 사용자 비율"을 올리는 쪽으로 맞출 수 있어요.

allob metrics aha --json 으로 처음 3일 안의 행동 중 30일 뒤에도 돌아오는 사용자를 가장 잘 가르는 것을 찾아 줘.
믿을 만한 후보가 있으면 그 행동·기준 횟수·돌아오는 비율 차이를 쉬운 말로 알려 주고, 그 행동까지 더 많은 새 사용자가 가게 할 실험을 하나 제안해 줘.

allob metrics aha                                   # 처음 3일 · 30일째쯤 다시 오나
allob metrics aha --window 7d --retained 7d         # 막 출시한 앱이면 더 빨리 보기
allob metrics north-star "milestone[kind=assets,at=5]" --window 3d --label "3일 안에 스티커 5개"
allob metrics north-star                            # 지금 북극성 지표
allob metrics north-star --clear

어떻게 셈하나요?

• 새 기기를 처음 방문한 날로 묶고, 그날부터 --retained 일째(기본 30일)부터 7일 안에 다시 방문한 기기를 "남은 기기", 나머지를 "떠난 기기"로 나눠요. 그 7일이 다 지난 기기만 세요 — 30일이면 37일보다 전에 처음 방문한 기기예요. 이벤트는 약 3개월만 남아서 출시한 지 얼마 안 됐으면 --retained 7d 로 먼저 봐요.
• 처음 --window 일(기본 3일) 안에 한 행동을 이벤트마다, 속성 값마다 봐요. 값 목록 속성이 꼭 두 개인 이벤트(예: milestone 의 kind·at)는 두 값을 같이 본 것도 행동이에요 — milestone[kind=assets,at=5] 는 "재료를 5개째 저장함"이에요.
• 행동마다 1·2·3·5·10번… 이상 한 기기와 그러지 않은 기기의 돌아온 비율을 비교하고, 가장 잘 가르는 횟수 하나를 골라 보여 줘요. 차이의 범위(95%)도 같이 보여 줘요.
• 어느 쪽이든 기기가 30대가 안 되면 "기기가 적어 믿기 어려워요"로 표시하고, 기기가 넉넉하고 범위가 0 보다 위일 때만 믿을 만한 후보로 쳐요. 갓 출시한 앱은 대부분 아직 믿기 어려움으로 나와요.
• 후보를 많이 비교하기 때문에 우연히 갈라지는 것도 섞여요. 그리고 "같이 간다"이지 "그 행동 때문에 남는다"는 아니에요 — 맨 위 후보는 그 행동까지 가게 돕는 실험으로 확인한 뒤에 믿어요.
• 기기가 아주 많으면 기기의 일부만 읽어요(비율은 그대로예요). 그렇게 했다면 몇 %를 읽었는지 알려 줘요.

북극성 지표를 정하면 이렇게 같이 보여요.

• 지표 탭 — 고른 기간에 처음 방문한 새 기기 중 처음 며칠 안에 그 행동까지 간 비율(처음 방문한 주마다도). 아직 며칠이 다 지나지 않은 기기는 따로 세요.
• 전후 비교 — 앞 기간과 뒤 기간에 처음 방문한 새 기기의 비율.
• 제품 안 A/B — 그룹마다, 처음 본 날부터 며칠 안에 그 행동까지 간 비율과 기준 그룹과의 차이.
• 광고 실험 보고서 — 실험 그룹마다, 그 그룹 광고로 처음 들어온 기기 중 며칠 안에 그 행동까지 간 비율.

#전후 비교

allob metrics impact 1.4.0                              # 릴리스 버전
allob metrics impact ch_20261017_1400_ab12 --days 14    # 마케팅 변경 ID

릴리스를 낸 시각이나 변경을 기록한 시각을 기준으로, 전과 후를 같은 날 수(기본 7일, 최대 28일 — 화면에서는 7·14·28일 중 골라요)만큼 비교해요.

• 하루 평균 방문 기기
• 하루 평균 매출(낸 돈)·광고비·결제 수, ROAS(매출 ÷ 광고비, 통화가 같을 때만), 결제 1건당 광고비 — 매출이나 광고 계정이 연결돼 있을 때만. 날 단위 숫자라 바꾼 날은 빼고 앞뒤로 다 지난 날만 세요. 바꾼 날은 숫자마다 그 날짜로 빼요(매출은 결제 서비스 날짜 UTC, 광고비는 광고 계정 시간대, 결제 수는 한국 날짜). 아직 모르는 날(매출은 모으기 전·일부 결제 서비스만 모은 날·결제 서비스 시간대로 아직 안 끝난 날, 광고비는 처음 읽은 날 전과 마지막으로 읽은 날·그 뒤)은 0 이 아니라 평균에서 빼고(매출을 아는 첫날이나 광고비를 처음 읽은 날이 앞 기간 첫날보다 늦으면 앞 기간을 며칠만 셌는지 그 아래에 알려 줘요), ROAS·결제 1건당 광고비는 두 값을 다 아는 날만으로 셈해요
• 퍼널 단계별 비율(그 기간에 첫 단계를 한 기기 기준)
• 이벤트별로 그 이벤트를 한 기기의 비율(방문 기기 대비)

릴리스를 비교할 때는 그 릴리스의 "새로운 기능" 글도 언어별로 함께 보여 줘요(릴리스 기록하기).

같은 기간에 다른 릴리스나 변경이 있었다면 함께 보여 줘요. 숫자가 바뀐 이유가 하나가 아닐 수 있기 때문이에요. 기준 시점 뒤로 아직 그만큼의 날이 지나지 않았다면 지난 날까지만 비교하고 그렇다고 표시해요.

#앱 릴리스는 버전별로 비교해요

앱은 스토어가 업데이트를 조금씩 퍼뜨리고 사용자도 늦게 업데이트해요. 그래서 릴리스 시각 전후만 나누면 새 버전과 옛 버전 사용자가 섞여요. 앱 릴리스(플랫폼이 iOS·Android·macOS 이거나 --app-version·--ota 를 적은 릴리스)는 전후 비교 아래에 버전별 비교를 함께 보여 줘요.

• 같은 기간(릴리스 뒤 7일 등)에 이 버전을 쓴 기기와 다른 버전을 쓴 기기를 나눠서 퍼널 단계별 비율, 이벤트를 한 기기 비율, 하루 평균 기기를 비교해요. "다른 버전"은 이 버전이 아닌 모든 버전이에요 — 이전 버전뿐 아니라 뒤에 나온 버전(핫픽스 등)도 들어가요.
• 퍼널은 기기마다 첫 단계를 한 버전 하나로 세요. 첫 단계를 이전 버전에서 하고 업데이트한 뒤 끝낸 기기는 다른 버전 쪽에 들어가요.
• 하루 평균 기기와 이벤트를 한 기기 비율은 그 이벤트를 보낸 버전으로 세요. 기간 중에 업데이트한 기기는 양쪽에 들어가요.
• 결제처럼 서버가 보내는 이벤트에는 버전이 없어서, 퍼널에서는 그 기기가 그때 쓰던 버전으로 세요. 이벤트를 한 기기 비율에는 버전이 실린 앱 이벤트만 들어가요(결제는 퍼널로 봐요).
• 이 버전을 쓰는 기기가 0대면 릴리스의 앱 버전이 앱이 보내는 버전과 다를 수 있어요. --app-version 을 확인해요.
• 날마다 앱 기기 중 이 버전을 쓰는 비율(업데이트가 얼마나 퍼졌는지)과 많이 쓰는 버전을 보여 줘요.
• 버전은 릴리스 버전 이름으로 찾아요(1.2.0 이면 1.2.0 의 모든 빌드). 앱 버전이 릴리스 이름과 다르면 --app-version, OTA 업데이트면 --ota 로 적어요(릴리스 기록하기).
• 앱이 버전을 보내야 볼 수 있어요(앱에 측정 넣기). 버전이 담긴 이벤트가 아직 없으면 그렇다고 알려 주고 전후 비교만 보여 줘요. 웹 릴리스와 마케팅 변경은 전후 비교만 해요.

릴리스 뒤 지표가 크게 떨어지면 전후 비교를 열지 않아도 allob 이 먼저 알려 줘요(지표 이상 알림).

#설치 확인

이벤트를 처음 넣었을 때는 지표 탭보다 이 명령이 빨라요.

allob ingest events

최근 24시간 동안 받은 이벤트의 이름, 건수, 기기 수가 나와요. 1분 정도 늦게 보여요.

#봇·시험·내 방문 빼기

자동으로 걸러지는 것과 내가 해야 하는 것이 있어요. 제품 설정 › 데이터 거르기에서 지난 24시간 동안 걸러진 이벤트를 까닭별로 볼 수 있어요.

자동으로 걸러져요

• 봇: 확인된 봇, 봇 브라우저, 브라우저 정보가 빈 요청, 데이터센터·애플 망에서 온 요청(웹사이트에 측정 넣기)
• 개발 주소: localhost 같은 내 컴퓨터 주소에서 온 웹 이벤트
• 다른 사이트: 제품 사이트 주소가 있으면 그 사이트 밖(미리보기 배포 등)에서 온 웹 이벤트. 사이트 주소를 정하고 7일 동안은 세기만 해요. 앱 안 웹뷰는 보지 않아요
• 앱 개발 빌드: 앱 SDK 가 처음부터 보내지 않아요
• 시험 결제: 테스트 모드 결제, RevenueCat 의 운영 환경이 아닌 결제, 서버 이벤트의 test: true

직접 해 주세요

1. 제품에 사이트 주소를 넣어요. 넣지 않으면 개발 주소만 걸러지고 미리보기 배포는 그대로 쌓여요. 다른 도메인에서도 측정해야 하면 스키마 tracking.allowedHosts 에 넣어요.
2. 내 브라우저마다 데이터 거르기 › 이 브라우저 빼기를 한 번 눌러요(내 방문 빼기).
3. 내 폰·테스트 기기는 앱에서 setExcluded(true) 로 빼고, 기기 ID 를 데이터 거르기에 넣어요(내 기기 빼기).
4. 내가 결제해 보는 계정이 있으면 운영자 계정에 넣어요(내 결제 빼기).
5. 이미 설치된 옛 앱 버전을 내 서버가 넘기고 있다면 서버 키를 넣어요(이미 설치된 옛 앱 버전).

뺀 기기는 빼기 전에 쌓인 이벤트도 모든 지표에서 빠져요. GA4 는 allob 이 거르지 않아요. GA4 숫자에서도 내 방문을 빼려면 GA4 의 내부 트래픽 필터를 쓰세요.

마크다운으로 보기 · llms.txt · 개인정보 처리방침 · 이용약관