지표 이상 알림

새 버전을 내보낸 뒤 가입률이나 결제율이 이상하게 떨어지면, allob 이 먼저 알아채고 알려 줘요. 릴리스와 상관없이 어제 숫자가 평소보다 크게 떨어진 것, 늘 오던 결제·가입이 하루 내내 0 인 것(결제 서비스 장애, 측정이 끊긴 것 등)도 알려 줘요.

따로 설정할 것은 없어요. 이벤트·퍼널·매출이 있는 모든 제품에서 자동으로 돌아요. 기준값을 정할 필요도 없어요.

• 알림 종: 화면 위 막대의 종에 열린 알림이 보여요.
• 폰 알림: 릴리스 뒤에 지표가 떨어졌거나 측정이 빠졌을 때, 늘 오던 이벤트가 하루 내내 0 일 때는 폰으로도 와요.
• 변경 타임라인: 그 릴리스의 깃발 옆에 경고가 붙어요.
• 제품 보드: 릴리스 뒤 72시간 동안 릴리스 지켜보는 중 줄에 확인 중·정상·경고가 보여요.

잘못 알리는 것이 조금 늦게 알리는 것보다 나쁘다고 보고, 확실할 때만 알려요. 숫자가 오른 것은 알리지 않아요.

#에이전트에게 맡기기

allob alerts list 로 열린 지표 이상 알림을 보여 줘. 알림마다 allob alerts view <id> 로 자세히 읽고, 무엇이 얼마나 떨어졌는지 한 줄로 정리해 줘. 릴리스 뒤에 떨어진 것이면 그 릴리스에서 바뀐 코드 중 그 단계(가입·결제 등)에 닿는 부분을 찾아 원인 후보를 알려 주고, 고칠 방법을 제안해 줘. 고치기 전에 나에게 먼저 물어봐.

allob alerts list 에 "계측이 빠진 것 같아요" 알림이 있으면, 그 이벤트를 보내던 코드가 새 버전에서 빠졌는지 찾아 줘. 실수로 빠졌으면 다시 넣고, 일부러 뺀 거면 allob schema pull 로 스키마를 받아 그 이벤트를 지우고 allob schema push 해 줘.

#무엇을 보나

제품의 대표 지표 네 가지를 봐요.

#릴리스 뒤

릴리스를 기록하면 그때부터 지켜봐요. 처음 72시간은 1시간마다, 그 뒤 14일째까지는 하루 한 번 봐요.

• 앱: 같은 기간에 새 버전을 쓴 기기와 다른 버전을 쓴 기기를 비교해요. 같은 시간대라 요일이나 광고 영향이 양쪽에 똑같이 닿아요. 공정하게 비교하려고 세 가지를 맞춰요.
  • 새 버전에는 새로 설치한 기기가 많이 몰려요 — 새 기기와 원래 쓰던 기기를 나눠 비교해요.
  • 심사나 단계적 출시로 한 운영체제(예: Android)가 먼저 새 버전을 받아요 — iOS·macOS 와 Android 를 나눠 비교해요.
  • 새 버전 기기는 늦게 들어와 결제까지 갈 시간이 적어요 — 기기마다 첫 단계부터 같은 시간(다른 버전 기기 대부분이 그 단계까지 가는 시간, 1~72시간) 안의 전환만 세요.
• 웹(또는 버전을 모르는 릴리스): 릴리스 뒤와, 몇 주 전(보통 2~5주 전, 4주치)의 같은 요일·같은 시간을 비교해요. 공휴일·명절이 낀 주는 건너뛰고 8주 전까지에서 가까운 주를 골라요. 같은 시간대 비교가 아니라서 기준을 더 높게 잡아요.

앱 버전끼리 비교하려면 릴리스가 어느 앱 버전인지 알아야 해요. 릴리스 이름을 앱 버전과 같게 쓰거나, 다르면 --app-version, OTA 업데이트면 --ota 를 적어요(앱 릴리스). 앱이 이벤트에 버전을 실어 보내야 해요(앱에 측정 넣기). 릴리스가 제품의 앱 플랫폼 중 일부만 덮으면(예: iOS 만 나간 버전) 웹처럼 몇 주 전과 비교해요.

allob release create 1.2.0 -c "ux: new onboarding — watch signup_complete" --platform ios,android

#날마다

매일 한국 시간 오전 9시가 지나면 어제 하루를 지난 4~8주의 같은 요일과 비교해요. 공휴일, 설·추석 연휴 바로 앞날, 12월 24일·31일처럼 사람이 평소와 다르게 오는 날은 어제여도 보지 않고, 비교할 날에서도 빼요. 어제나 그제 릴리스가 있었으면 릴리스 지켜보기에 맡겨요(같은 일을 두 번 알리지 않게). 결제 1건당 낸 돈은 매출을 다 모은 가장 최근 날로 봐요.

날마다 확인은 결제가 끊기거나 측정이 깨진 날 같은 큰 사고를 잡는 그물이에요. 하루 표본만으로도 숫자가 10% 안팎 오르내리니, 반 넘게 떨어진 날을 주로 잡아요(하루 1,000대 제품에서 80% 떨어진 날은 거의 다, 60% 는 넷에 셋 꼴). 작은 떨어짐은 릴리스 지켜보기(앱 버전끼리 비교)가 맡아요.

광고를 켜고 끄거나 예산·타기팅을 바꾸면, 그날 뒤로만 비교해요(광고를 끈 뒤 방문이 줄어든 채로 이어지는 것은 이상이 아니에요). 결제 지표는 할인·가격 변경도 마찬가지예요.

#작은 제품(하루 기기 몇십~몇백 대)

기기가 적으면 숫자가 원래 많이 흔들려서, 큰 제품처럼 "20% 떨어짐"을 하루 만에 가려낼 수는 없어요. 그래서 기기가 적을 때는 표본이 작아도 맞는 정확한 계산으로 바꾸고, 작은 제품에서도 잡히는 확인 두 가지를 더 해요.

• 멈춤: 날마다 오던 이벤트가 어제 하루 0건이면 알려요. 퍼널 단계와, 기기의 20% 넘게 보내는 이벤트 중 지난 8주 동안 하루도 빠짐없이 오던 것만 봐요(payment_failed 같은 드문 이벤트가 0 이 된 건 좋은 소식일 수 있어서 보지 않아요). 기대 수가 적으면 0 이어도 우연일 수 있어서, 같은 요일에 평소 15건쯤 넘게 오던 이벤트부터 확실하게 잡아요(10건쯤이면 셋에 한 번, 5건 아래는 못 잡아요). 새 버전에서만 0 이 된 이벤트는 계측이 빠진 것 같아요 알림이 잡아요.
• 최근 7일: 최근 7일을 앞 4주와 비교해요. 한 주 내내 결제가 거의 멈춘 것은 하루 기기 50대면 반쯤, 100대면 대부분 잡아요. 50% 떨어짐은 하루 200대에서도 일곱 번에 한 번쯤만 잡아요 — 주마다 오르내림을 넉넉히 잡아서 잘못 알리지 않으려는 거예요.

작은 앱에서 가장 잘 잡히는 것은 앱 버전끼리 비교예요. 새 버전 기기가 하루 100대면 50% 떨어짐을 대부분(한 주 안팎), 600대면 사흘쯤 안에 잡고, 새 버전에서 결제가 멈추면 하루 20대여도 잡아요. 하루 20대면 50% 떨어짐은 넷에 하나쯤만 잡아요.

#큰 제품

기기가 아주 많으면 기기 일부(기기 id 로 고른 표본)로 비교해요. 기기 단위라 비율은 그대로예요. 하루 수천 대가 넘는 제품의 날마다 퍼널은 하루 400~500대 표본만큼의 검출력이라, 큰 제품의 퍼널 떨어짐은 앱 버전끼리 비교가 주로 잡아요. 조회가 잘리면 0 으로 읽지 않고 그 확인을 건너뛰어요.

리뷰 평균은 스토어 리뷰의 릴리스 앞뒤 평균을 릴리스 지켜보는 중 줄에 함께 보여 줘요. 따로 알림을 보내지는 않아요.

#언제 이상으로 보나

아래 세 가지를 모두 넘어야 알려요.

1. 충분한 기기: 기준으로 계산한 기대 전환이 5번 이상이어야 해요(그 아래는 0 이어도 우연일 수 있어요). 기기가 100대·전환 20번을 넘으면 보통 계산을, 그 아래면 표본이 작아도 맞는 정확한 계산을 써요. 결제 1건당 매출은 그날 결제가 20건 이상이어야 해요.
2. 충분히 크게 떨어짐: 기준보다 20% 이상 낮아야 해요(웹처럼 몇 주 전과 비교할 때와 최근 7일은 25%). 버전끼리 사용자 구성이 조금씩 다르고 날마다 오르내림이 있어서, 10% 안팎의 차이는 늘 생겨요.
3. 보기 드문 차이: 평소 흔들림으로는 보기 드문 차이여야 해요. 1시간마다 여러 지표를 보면 한 번쯤 우연히 걸리기 쉬워서, 여러 번·여러 지표를 볼수록 기준을 더 엄하게 잡아요. 릴리스 하나를 14일 동안 지켜볼 때 쓰는 기준은 모두 합쳐 1% 를 넘지 않게 나눠 써요. 새 버전이 늦게 퍼지고, 결제까지 반나절 걸리고, 새 버전에 Android 가 몰리는 경우를 넣은 시뮬레이션 168번에서 잘못 알린 것은 0번이었어요.

릴리스는 한 번 걸린다고 바로 알리지 않아요. 바로 다음 확인에서도 걸려야 알려요. 늦게 들어온 이벤트로 잠깐 튄 것을 거르려는 거예요.

#알림 읽기

알림 하나는 세 줄로 읽혀요.

날마다 알림은 "10월 27일(화) 결제 전환율이 평소보다 낮았어요"처럼 그날과, 지난 같은 요일들의 평균·가장 낮았던 날을 같이 보여 줘요. 알림 자세히 보기에서 전후 비교를 누르면 그 릴리스의 전후 비교 화면이 열려요.

#계측이 빠진 것 같아요

스키마에는 있는 이벤트인데, 다른 버전 기기는 보내고 새 버전 기기는 한 대도 보내지 않으면 "떨어짐" 대신 계측이 빠진 것 같아요 알림을 보내요. 새 버전에서 이벤트를 보내는 코드가 빠졌을 가능성이 커요. 퍼널 단계와 기기의 20% 넘게 보내는 이벤트만 보고, 같은 운영체제끼리 비교해요(iOS 에만 있는 이벤트가 Android 새 버전에서 0 인 것은 빠짐이 아니에요). 0 이 되는 게 좋은 이벤트(오류 등)는 스키마에서 "alerts": false 를 적으면 보지 않아요(이벤트 필드).

• 실수로 빠졌으면 다시 넣고 새 버전을 내보내요.
• 일부러 뺐으면 이벤트 스키마에서도 지워요(allob schema push). 지우면 이 알림은 사라져요.

이 이벤트를 쓰는 퍼널 단계는 따로 "떨어짐"으로 알리지 않아요. 같은 일을 두 번 알리지 않게요.

#이상으로 보지 않는 것

#알림 닫기와 나아짐

• 알림 닫기: 알림을 열고 알림 닫기를 누르거나 allob alerts dismiss <id> 를 실행해요. 닫은 릴리스 알림은 다시 열리지 않아요. 날마다·최근 7일 알림은 닫은 뒤 숫자가 나아졌다가 다시 떨어지면 새 알림으로 알려요.
• 나아짐: 떨어진 폭이 10%(웹처럼 몇 주 전과 비교할 때와 최근 7일은 12.5%)보다 작아지면 자동으로 나아짐으로 바뀌어요. 계측 알림은 새 버전 기기 중 그 이벤트를 보내는 비율이 다른 버전 비율의 절반을 넘으면, 멈춤은 다음 날 다시 오면 나아져요.
• 릴리스 지켜보기가 14일로 끝나도 열린 알림은 남아요. 확인한 뒤 닫아요.

allob alerts list               # 열린 알림
allob alerts view <id>          # 자세히 — 비교한 숫자와 이유
allob alerts dismiss <id>       # 알림 닫기

--json 을 붙이면 기계가 읽기 좋은 모양으로 나와요. 에이전트는 MCP 도구로도 같은 목록을 읽어요.

#알림 받기

처음 설정은 이래요. 계정 설정 › 알림의 지표 이상에서 사람마다 바꿀 수 있어요.

알림 종의 숫자는 아직 안 본 알림 수예요. 종을 열면 숫자가 사라지고, 그때 새로 본 알림에는 종을 닫을 때까지 점이 남아요. 알림은 닫거나 숫자가 나아질 때까지 목록에 그대로 있어요. 봤는지는 사람마다 따로예요. 웹에서 종을 열면 같은 메일로 로그인한 폰 앱의 배지도 줄어드는데, 폰 화면에는 앱을 열거나 다음 알림이 올 때 바뀌어요.

폰 알림은 모두, 급한 것만, 받지 않기 중에 골라요. 폰 알림은 금고 › 승인 방법에서 알림을 켠 기기로 와요.

새 결제·환불은 지표 이상과 따로, 결제 한 건마다 바로 폰으로 와요(새 결제 알림).

리뷰·피드백 알림과 같이 묶어서, 계정마다 10분에 한 번 제품마다 알림 하나로 보내요. 알림 글에는 제품 이름·지표·버전만 넣고 사용자 정보는 넣지 않아요. 누르면 그 알림이 열려요.

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