대부분의 인디 iOS 앱에는 평점 문제가 있습니다. 사용자가 불만을 느껴서가 아니라, 평점 요청 프롬프트가 잘못된 순간에 뜨거나 아예 뜨지 않기 때문입니다.

이는 대부분의 개발자가 생각하는 것보다 훨씬 중요합니다. 평점은 단순한 사회적 증거가 아닙니다. 평점은 여러분의 키워드 랭킹을 지킬 만한 가치가 있는지를 Apple이 판단하는 데 사용하는 전환 신호입니다.

추측에 의존하지 않고, Apple의 규칙도 어기지 않으면서 이 문제를 해결하는 방법을 소개합니다.

평점 문제는 여러분이 생각하는 그것이 아닙니다

대부분의 개발자는 두 가지 극단 중 하나를 따르는 본능을 가지고 있습니다. 리뷰를 한 번도 요청하지 않고 자연스럽게 모이기를 기대하거나, 사용자가 무언가를 하고 있는 도중에 끼어드는 팝업으로 끈질기게 부탁하거나입니다.

둘 다 잘 작동하지 않습니다.

문제는 타이밍과 맥락입니다. 앱을 처음 실행했고 아직 아무것도 하지 않은 사용자는 평점을 매길 준비가 되어 있지 않습니다. 방금 오류를 만난 사용자라면 더더욱 준비가 되어 있지 않습니다. 반면 운동, 퀴즈, 또는 어떤 마일스톤처럼 의미 있는 일을 막 완료한 사용자야말로 적절한 순간의 적절한 대상입니다.

Marteso의 현재 앱 데이터를 보면, Pi Digits는 미국에서 5점 평점 1건을 가지고 있습니다. RowTally와 CalcBlitz는 각각 평점 0건입니다. 이들은 나쁜 앱이 아닙니다. 단지 프롬프트 타이밍 문제를 아직 해결하지 못한 앱일 뿐입니다.

Apple의 규칙을 솔직하게 정리합니다

Apple이 제공하는 정당한 도구는 단 하나입니다. SKStoreReviewController.requestReview()입니다. 이를 코드에서 호출하면, 프롬프트의 모양과 응답 처리는 Apple이 제어합니다. 닫기 동작을 재정의할 수 없습니다. 리뷰를 대가로 보상을 줄 수도 없습니다. 폼이나 거래 안에서 요청할 수도 없습니다.

Apple은 이를 기기당 연간 3회로 제한합니다. 이 상한선은 높게 들리지만, 대부분의 인디 앱이 온보딩 직후나 세션 도중처럼 나쁜 순간에 1~2회를 허비하고, 3번째는 유용한 맥락에서 끝내 나타나지 않는다는 현실을 깨닫고 나면 이야기가 달라집니다.

연간 3회라는 것은 곧 3번의 의도적인 결정을 할 수 있다는 뜻입니다. 각각을 유한한 자원처럼 다루세요.

효과가 있는 두 가지 타이밍 창

리뷰 요청이 긍정적인 응답을 얻을 가능성이 충분히 높은 순간은 두 가지가 있습니다.

첫 번째는 ‘첫 사용의 감동’ 순간입니다. 이는 사용자가 그 앱이 만들어진 핵심 과업을 처음으로 달성한 때입니다. 온보딩 튜토리얼이 아닙니다. 진짜 그 일 말입니다. Pi Digits라면 원주율 암송 챌린지를 완료했을 때, RowTally라면 완료한 코 수를 저장했을 때, CalcBlitz라면 시간 측정 계산을 끝냈을 때입니다.

사용자는 그 앱이 자신이 필요로 하던 일을 해준다는 것을 방금 확인했습니다. 바로 그 순간이 적절한 순간입니다.

두 번째는 ‘마일스톤’ 순간입니다. 이는 사용자가 연속 기록, 개인 최고 기록, 또는 완료 횟수 같은 의미 있는 진척 지점에 도달했을 때입니다. Pi Digits라면 처음으로 10자리를 암송했을 때일 수 있습니다. 습관 형성 앱이라면 7일 연속 기록일 수 있습니다.

마일스톤이 효과적인 이유는 사용자가 이미 긍정적인 감정 상태에 있기 때문입니다. 여러분은 그들을 방해하는 것이 아닙니다. 그들이 방금 해낸 일을 인정해 주는 것입니다.

콜드 스타트, 오류 상태, 또는 사용자가 아무것도 하지 않은 첫 세션에서 요청하는 것은 피하세요.

평점 획득 속도가 키워드 랭킹으로 이어지는 이유

이 부분은 대부분의 ASO 가이드가 건너뛰는 내용입니다.

평점은 App Store를 둘러보는 사용자에게 주는 신뢰 신호일 뿐만이 아닙니다. Apple에게는 전환 품질 신호이기도 합니다. Apple이 어떤 키워드로 여러분의 앱을 랭킹할 때, 그 검색을 통해 앱을 찾은 사용자가 실제로 다운로드하는지를 관찰합니다. 다운로드하지 않으면 랭킹은 침식됩니다.

평점이 1건인 앱은 비슷한 점수에 평점이 200건인 앱보다 신뢰하기 어렵습니다. 잠재 사용자가 여러분의 제품 페이지에 도착해 평점이 하나뿐인 것을 보면, 그 심리적 저항은 실재하며, Apple은 그것을 전환 데이터에서 관찰할 수 있습니다.

경쟁이 치열한 키워드를 노리는 인디 앱에게는, 그 저항이 종종 랭킹의 보이지 않는 천장이 됩니다. 키워드 작업은 제대로 되어 있습니다. 메타데이터도 제대로 되어 있습니다. 하지만 제품 페이지가 순위를 유지할 만큼 충분히 잘 전환되지 않는 것입니다.

신뢰할 만한 평점 수, 단 20~50건이라도 거기에 도달하면 그 저항을 의미 있게 줄일 수 있습니다.

실용적인 프롬프트 구현

대부분의 인디 앱에 제가 추천하는 구조는 다음과 같습니다.

앱 안에서 감동 이벤트를 하나 정하세요. 이는 사용자가 진짜 가치를 얻었다는 것을 의미하는 인앱 액션입니다. 코드를 작성하기 전에 먼저 이것을 적어두세요.

소프트 카운터를 구현하세요. 사용자가 그 이벤트에 몇 번 도달했는지를 셉니다. 3번째 또는 5번째 발생 시점에 requestReview()를 호출하세요. 첫 세션에서는 프롬프트를 띄우지 마세요.

마일스톤 트리거를 추가하세요. 연속 기록, 개인 최고 기록, 완료 횟수 같은 진척 마일스톤을 하나 골라, 그곳에 두 번째 requestReview() 호출을 추가하세요. 이렇게 하면 연간 3회 할당량을 모두 소진하지 않으면서, 사용자 한 명당 맥락적으로 적절한 순간을 두 개 확보할 수 있습니다.

플로우 도중에 절대 요청하지 마세요. 리뷰 프롬프트는 게임이 끝난 후, 운동이 저장된 후, 경로가 완료된 후처럼 자연스러운 휴지점에서만 나타나야 합니다. 과업 도중에는 절대 안 됩니다.

하지 말아야 할 것

리뷰를 사지 마세요. Apple은 그 패턴을 감지해 삭제합니다. 가짜 리뷰로 인한 랭킹 신호는 일시적이지만, 페널티 위험은 일시적이지 않습니다.

리뷰를 요청하는 푸시 알림을 보내지 마세요. 이는 Apple 가이드라인에 위반되며, 사용자가 여러분의 알림을 음소거하도록 길들입니다.

사용자를 App Store 프롬프트로 보내기 전에 걸러내는 서드파티 리뷰 게이팅 서비스를 사용하지 마세요. Apple의 가이드라인은 긍정적인 감정을 가진 사용자만 프롬프트로 유도하는 것을 금지합니다.

설정 메뉴에 상시 노출되는 “평가하기” 버튼 하나를 추가하고 그것을 전략이라고 부르지 마세요. 그것은 전략이 아닙니다. 어차피 평가했을 사용자를 위한 보조 수단일 뿐입니다.

결과가 나오기까지 얼마나 걸릴까

평점 수는 천천히 쌓이는 것입니다. 그것을 가장 빠르게 가속하는 방법은 위에서 설명한 타이밍 창을 정확하게 잡고, requestReview()를 올바르게 호출하는 빌드를 출시하는 것입니다.

대부분의 인디 앱에서 평점을 0건에서 20건으로 늘리는 데는, 활성 사용자 수에 따라 다르지만 며칠이 아니라 몇 주가 걸립니다. 하지만 그 복리 효과가 중요합니다. 평점 수가 늘면 제품 페이지 전환이 개선되고, 그것이 랭킹된 키워드의 전환 신호를 개선하며, 그 결과 그 순위를 유지하기가 더 쉬워집니다.

ASO 시스템은 일관성에 보상합니다. 평점은 그 시스템의 일부입니다.