In-App Review API в Android: как просить оценку, не раздражая пользователя

Большинство предложений «оцените нас» в Android — это кастомный диалог с двумя кнопками: одна открывает страницу приложения в Play Store, другая закрывает окно. Они появляются при запуске приложения или после произвольного числа сессий и прерывают то, чем пользователь на самом деле занимался. Тот, кто нажимает «оценить», покидает ваше приложение, попадает в Play Store и теперь должен написать отзыв с нуля — это трение убивает большую часть только что пойманного намерения. Тот, кто нажимает «не сейчас», ничего вам не сказал, и вы, скорее всего, всё равно спросите его снова на следующей неделе.

In-App Review API от Google решает механическую половину этой проблемы: нативный лист оценки появляется поверх вашего приложения, позволяет пользователю выбрать звёзды (и, по желанию, написать пару слов), не покидая приложение, и возвращает его точно туда, где он был. UX-половину API не решает — момент запуска всё равно важнее способа — но убирает оправдание для ошибок в этом самом «способе».

Как это работает на самом деле

API — часть Play Core (com.google.android.play:review-ktx). Вы заранее запрашиваете объект ReviewInfo, а затем запускаете поток, когда готовы его показать:

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo)
            .addOnCompleteListener {
                // The flow is finished — you don't get a signal on
                // whether the user actually rated. Treat this as "done,"
                // not "succeeded."
            }
    }
}

Есть два момента, на которых спотыкаются. Во-первых, requestReviewFlow() может незаметно завершиться неудачей или вернуться, ни разу не показав диалог, — Google ограничивает, как часто один и тот же пользователь видит этот лист (примерно раз в год на приложение, без точной документации и вне вашего контроля), поэтому большинство вызовов при тестировании завершатся, ничего не показав. Во-вторых, колбэк завершения срабатывает независимо от того, оценил ли пользователь приложение, пропустил ли запрос или квота вовсе заблокировала диалог. Никакого onRatingSubmitted не существует — намеренно, чтобы приложения не могли блокировать функции или донимать пользователя в зависимости от результата.

Что действительно важно: момент

То, что API не создаёт трения, не поможет, если запускать его в неподходящий момент. Самая частая ошибка, которую я вижу, — вызывать requestReviewFlow() сразу после onCreate(), из соображения, что больше показов значит больше отзывов. Происходит обратное: вы спрашиваете до того, как у пользователя вообще появилось какое-то мнение, и делаете это в самый разгар той задачи, ради которой он в тот день открыл приложение.

Момент, который работает, — сразу после того, как приложение наглядно выполнило свою задачу. При разработке Mintly это момент сразу после завершения фокус-сессии, когда пользователь видит, как растёт его серия, — не первая сессия, а та, к которой приложение уже успело заслужить немного доверия. Несколько конкретных правил, которые работают вне зависимости от категории приложения:

• Запускайте по завершённому позитивному результату, а не по фиксированному числу сессий. Бюджетное приложение — после того как пользователь чисто закрыл месяц, трекер привычек — после вехи в серии, приложение-напоминалка — после реально полезного спасения, а не «пятая сессия».
• Никогда не запускайте на пути ошибки. Если что-то только что не удалось или пользователь только что вышел из процесса, это худший момент для запроса.
• Ограничивайте себя сами, даже если API уже ограничивает вас. Квота Google приводит к тому, что большинство запросов незаметно ничего не делают, но ваша собственная логика запуска всё равно должна избегать срабатывания на каждом подходящем событии — как только поток завершился для пользователя, не вызывайте его снова месяцами, даже если ваш собственный трекинг не может подтвердить, действительно ли лист показался.
• Никогда не сочетайте его с собственным предварительным запросом. Кастомный диалог вроде «вам нравится приложение?», фильтрующий доступ к настоящему запросу, заново вводит то самое двухшаговое трение, ради устранения которого существует API, и позволяет вам отбирать, кто увидит настоящий запрос, — а это именно та манипуляция, которую правила Play прямо запрещают.

Чего он не может, и что люди всё равно пытаются сделать

Вы не можете узнать, действительно ли пользователь оставил оценку, прочитать значение звёзд или перенаправить недовольных пользователей в сторону от потока, а довольных — в него. Последнее — распространённая просьба, и она прямо противоречит политике разработчиков Play: весь смысл API в том, что каждый, кто его запускает, видит один и тот же нефильтрованный лист. Если вам нужен канал поддержки вроде «что-то не так?», сделайте его отдельной, честной ссылкой обратной связи — а не развилкой перед запросом отзыва.

Ещё одно ограничение, которое стоит знать: API работает только с Play. На других магазинах приложений Android эквивалентной гарантии нет, и там вы возвращаетесь к ручной ссылке «оцените нас» или собственному механизму магазина.

Тестирование без траты квоты

Поскольку реальная квота непрозрачна, тестируйте через инструменты тестирования Play Core, а не через production-сборку — тестовый артефакт com.google.android.play:review-ktx и внутренние треки распространения приложения позволяют запускать поток многократно, не дожидаясь реального ограничения от Google. Подключите триггер к отладочному меню на время разработки, чтобы запускать его по требованию, а перед релизом уберите этот ярлык. В продакшене относитесь к каждому вызову как к «отправил и забыл»: запросите, запустите, двигайтесь дальше — и позвольте собственной логике Google решать, кто на самом деле увидит лист.