[dongglehada]

무엇을 찾았나

"리뷰가 안 달린다"의 원인은 두 달 전과 지금이 다르다.

1.2.0이 앱스토어에 떠 있던 8~9월에는 요청이 아예 안 나갔다. GA4에서
review_prompt_requested가 6주 내내 0건이다. 이벤트 코드는 1.2.0에도 있었으니
안 보낸 게 아니라 조건(완료 5개 + 쓴 날 2일 + 설치 후 3일)이 한 번도 안 찬 것이다.

1.4.0에서 문턱을 낮춘 뒤로는 요청이 나가고 있다. 10월 1~24일에 11건, 10명
(1.4.0 1, 1.4.1 5, 1.5.0 1, 1.5.2 4). 같은 기간 할 일을 완료한 사람이 44명이니
넷에 한 명꼴로 묻고 있다. 조건이 빡빡해서 못 묻는 상태가 아니다.

그런데 평점은 그대로 3개(전부 5점), 글이 달린 리뷰는 2개이고 마지막 것이
9월 29일이다. 누적 최초 다운로드 104 대비 평점 2.9%. 10월에 요청 11건이 나가는
동안 평점은 한 개도 안 늘었다.

문제는 그 다음부터를 우리가 모른다는 것이다. requestReview()는 조건이 안
맞으면 아무 말 없이 아무것도 안 띄우는데, 코드는 "요청을 냈다"까지만 적고 "창이
떴다"는 적지 않았다. 그래서 떴는데 다들 닫았다와 한 번도 안 떴다를 가를 수가
없다. 둘은 고칠 곳이 완전히 다르다.

숫자와 경위는 docs/REVIEW_PROMPT.md에 전부 적었다.

무엇을 고쳤나

창이 실제로 떴는지를 본다. 시스템 리뷰창은 별도 UIWindow로 올라오므로, 요청
직전과 1.5초 뒤의 창 목록을 비교한다(Shared/ReviewPromptWindows.swift). 완료 직후
같이 올라올 수 있는 키보드 창은 이름으로 거른다. 애플이 창을 어떻게 올리는지는
공개된 약속이 아니라 어디까지나 어림이고, 그래서 사람에게 보이는 것은 아무것도
여기 걸지 않았다 — 다음에 언제 다시 물을지에만 쓴다. 틀려도 손해가 "한 번 더
물어본다"에서 멈춘다.

안 뜬 요청에 90일을 태우지 않는다. 예전엔 요청 직후에 버전 자국과 90일 간격을
한꺼번에 적었다. 아무것도 안 보여준 채로 그 사람을 분기째 잃는 셈이다. 이제 창이
떴을 때만 그렇게 하고, 안 떴으면 버전 자국 없이 일주일만 비워둔다.

지표를 넷으로 갈랐다. review_prompt_requested는 그대로, 여기에
review_prompt_shown / review_prompt_unseen / review_prompt_skipped(reason).
매개변수가 아니라 이름을 나눈 것은 이 GA4 속성에 맞춤 측정기준이 하나도 등록돼
있지 않아 매개변수로는 못 쪼개기 때문이다.

"쓴 날"을 앞으로 나올 때마다 센다. registerLaunch()를 부르는 자리가
runStartup() 하나뿐이었는데 그건 프로세스가 새로 뜰 때만 돈다. iOS가 앱을 며칠씩
들고 있으므로, 매일 여는 사람도 앱이 안 죽으면 쓴 날이 1에서 안 올라갔다.

1.2.0 시절의 자국을 한 번 지운다. 1.4.0 전 코드는 요청을 내기 전에 기회를
썼다고 적었다. 그 기간 요청이 0건이었으니 그 자국은 뜬 적 없는 창의 것이다.

문턱은 안 건드렸다. 넷에 하나에게 이미 묻고 있다. 더 낮추면 막 깔아본 사람에게
묻게 된다.

확인

xcodebuild ... -scheme App test 통과 — 313개 중 새 테스트 12개가 함께 돈다
(창 판정 3개, 안 뜬 뒤 재요청 3개, 쓴 날 세기 1개, 옛 자국 2개, 깃발 1개, 기존 수정 2개).
tools/i18n_check.py도 통과(문구는 안 건드렸다).

시뮬레이터로 직접 띄워 본 것은 없다. 창 판정은 실기기/시뮬레이터에서 실제로 리뷰창이
뜨는 상황을 재현하기 어려워 콘솔에서 비율로 검증할 수밖에 없다 — 2주 뒤에
shown과 unseen의 비가 나오면 그때 판정이 맞았는지도 같이 드러난다.

사용자가 정할 것 (코드 밖)

• 2주 뒤에 무엇을 볼지. shown이 requested에 가까운데 평점이 안 늘면 창은
  뜨고 사람들이 닫는 것이고, 그러면 고칠 것은 순간과 문구다. unseen이 많으면
  시스템이 막고 있는 것이고, 그때는 요청을 가장 좋은 자리 하나(하루를 다 끝낸 순간)로
  줄이는 쪽이 맞다.
• 시스템 창 앞에 한 번 더 물을지. "쓰시기에 어떤가요?" 같은 자체 시트를 먼저
  띄워 긍정인 사람에게만 시스템 창을 올리는 방식이 흔하다. 한도를 아끼는 데는
  확실히 유리하지만 화면과 문구가 새로 필요하고, 잘못 만들면 성가신 앱이 된다.
  시안을 보고 정할 일이라 이 PR에서는 손대지 않았다.
• 설정의 '앱 평가하기'를 더 잘 보이게 할지. 이 길은 연 3회 한도를 안 쓰고 누른
  것도 확실히 안다. 지금은 설정 안쪽에 있어 스스로 찾아온 사람에게만 닿는다.
• 스토어 페이지 쪽. 평점 3개는 전환율에도 불리하다. 리뷰를 늘리는 것과 별개로
  제품 페이지에서 손볼 것이 있는지는 따로 볼 문제다.

🤖 Generated with Claude Code