[ParkMazorika]

관련 이슈

• NM-427

변경 요약

사진 확정부터 분석 결과까지 사용자가 기다린 시간을 계측하고, 로딩 중 이탈을 셀 수 있게 분모 이벤트를 추가한다. 함께 의미가 없어진 limit_source 를 제거한다.

변경 내용

분석 대기시간

• pill_identify_started 신규 — 사진을 확정해 분석에 들어간 순간.
• pill_identify_result 에 analysis_ms(Int) · analysis_bucket(String) 추가.
• analysis_ms 는 온디바이스 세그멘테이션 + 서버 왕복을 포함한다. outcome 과 무관하게 실패에도 붙인다 — "얼마나 빨리 실패하는가"도 봐야 하기 때문.

왜 시작 이벤트가 필요한가

로딩 화면(PillLoadingVC)은 back 버튼을 숨겨 나갈 방법이 없다. 그래서 대기 중 이탈은 앱 강제 종료뿐인데, 그 순간엔 이벤트 전송이 보장되지 않아 이탈 시점에 직접 찍을 수가 없다. 분모를 남겨 빼는 방식이 유일하다.

로딩 이탈률 = 1 − (pill_identify_result 수 ÷ pill_identify_started 수)

성공률의 분모도 원래 이쪽이 맞다. pill_identify_result 는 결과가 나와야 찍히므로 이탈한 시도가 빠져 있다.

왜 버킷을 함께 보내는가

Int 는 GA4 측정항목으로만 등록되어 평균은 보이지만 분류 축으로 쓰면 전부 (not set) 이 된다. 분포를 보려면 문자열 구간이 필요하다.

unknown
00:00-00:03  00:03-00:05  00:05-00:10
00:10-00:15  00:15-00:20  00:20-00:30
00:30-01:00  01:00+

앞구간을 촘촘히 나눈 건 대기 이탈이 앞쪽에서 갈리기 때문이다 — 3초와 5초의 차이는 체감이 크지만 40초와 50초는 이미 "너무 느림" 한 덩어리다. 라벨이 mm:ss 고정자리인 이유는 GA4가 문자열을 사전순 정렬해서, 단위를 섞으면(30초-1분·1-2분) 정렬이 시간순과 어긋나기 때문.

limit_source 제거

NM-426 이후 이 파라미터가 가질 수 있는 값은 exhausted 하나뿐이다. 상수 축은 이벤트 수를 세는 것과 같은 정보를 되풀이할 뿐이라 맞춤 정의 슬롯만 먹는다.

옛 값(gate·server)과 구분해야 한다면 남길 이유가 있었지만, 아직 출시 전이라 구버전 앱이 없다. 전환기 자체가 존재하지 않는다.

GA4 한도 도달 지점 맞춤 측정기준도 dev·prod 양쪽에서 보관 처리했다. QA 기간에 쌓인 gate·server 값은 이걸로 버려졌다(팀 합의).

테스트

• 로컬 빌드/실행 확인 (tuist build App Build Succeeded)
• 정상·에러 케이스 확인

실측 (2026-09-02, 시뮬레이터)

05:20:07.705  pill_identify_started
05:20:20.575  pill_identify_result
                  analysis_ms     = 12869
                  analysis_bucket = 00:10-00:15
                  outcome = success, pill_count = 25

로그 간격 12.870초 vs analysis_ms 12.869초 — 1ms 차이.

pill_limit_reached 는 파라미터 없이 나가는 것을 os_log 로 확인했다.

측정값은 시뮬레이터 1건이라 실기기 분포는 배포 후 리포트로 봐야 한다.

체크리스트

• PR 제목이 [NM-XXX] 요약 형식
• 브랜치명 <type>/NM-XXX-요약 형식
• 커밋 메시지 [NM-XXX] type: 요약 형식
• 셀프 리뷰 완료