Настройка In-App Review для iOS и Android: нативные запросы отзывов

Пользователи редко сами заходят в App Store или Google Play, чтобы оставить отзыв. In-App Review решает эту проблему: нативный диалог появляется внутри приложения, и конверсия в оценку вырастает в 3–5 раз по сравнению с кастомными формами с deeplink. Но неправильная интеграция сжигает квоту и раздражает. За 5+ лет работы с In-App Review в 40+ проектах мы накопили практику, как заставить его работать эффективно.

Apple Developer Documentation — SKStoreReview показывает, что грамотная настройка способна увеличить количество оценок на 50% без затрат на рекламу. Экономия маркетингового бюджета при этом может достигать 40% за счёт органических отзывов.

Почему In-App Review лучше кастомных форм?

Кастомные формы с переходом в магазин дают конверсию 0.5–1% от числа пользователей, увидевших предложение. In-App Review — 3–5%. Разница в 3–10 раз. При этом нативный диалог не требует дополнительных разрешений и выглядит доверенно. Единственный минус — квоты, которые нужно учитывать.

Интеграция In-App Review на iOS с SKStoreReviewRequest

import StoreKit // iOS 16+
func requestReviewIfAppropriate() {
    guard let scene = UIApplication.shared.connectedScenes
        .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene else {
        return
    }
    SKStoreReview.requestReview(in: scene)
}

Apple строго лимитирует показы: не более 3 раз за 365 дней. Вызов сверх лимита проходит без ошибки, но диалог не отображается. Симулятор не подчиняется квоте — это только для разработки. Запрос на реальном устройстве тратит драгоценные показы. Учитывайте это при тестировании: используйте симулятор для проверки логики вызова, а реальное устройство — только для финальной верификации.

Интеграция In-App Review на Android

class MainActivity : AppCompatActivity() {
    private lateinit var reviewManager: ReviewManager

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        reviewManager = ReviewManagerFactory.create(this)
    }

    fun requestInAppReview() {
        val request = reviewManager.requestReviewFlow()
        request.addOnCompleteListener { task ->
            if (task.isSuccessful) {
                val reviewInfo = task.result
                val flow = reviewManager.launchReviewFlow(this, reviewInfo)
                flow.addOnCompleteListener { /* диалог завершён (возможно, не показан) */ }
            }
        }
    }
}

Google использует внутреннюю квоту — не чаще раза в 30 дней. Проверить её состояние нельзя. Для тестирования применяйте FakeReviewManager. В DEBUG-сборке он всегда показывает диалог без ограничений. В PRODUCTION автоматически подставляйте реальный ReviewManagerFactory.create(). Не забудьте добавить зависимость play-core-ktx в build.gradle.

Как интегрировать In-App Review с минимальными рисками?

Чтобы избежать перерасхода квоты, следуйте пошаговой инструкции:

1. Определите 2–3 ключевых события в приложении (например, завершение уровня, покупка, 7-дневная активность).
2. Реализуйте вызов API после каждого события, но с флагом hasRequestedReview в UserDefaults/SharedPreferences — чтобы не срабатывать чаще одного раза в 7 дней.
3. Используйте симулятор iOS и FakeReviewManager Android для отладки.
4. Перед релизом протестируйте на реальных устройствах с включённой квотой — проверьте, что диалог появляется ровно столько раз, сколько позволяет лимит.
5. В production мониторьте частоту показов через аналитику: если за неделю диалог не появился ни разу при выполнении условий, вероятно, квота выбрана. В таком случае подключите fallback deeplink.

Сравнение платформ: квоты и тестирование

Как выбрать момент для запроса?

Самые частые ошибки: запрос при первом запуске, после ошибки или при выходе. Конверсия в таких случаях падает до 1%. Проверенный подход — триггер после значимого действия: завершение уровня, успешная покупка, 7-дневная серия. В приложении для чтения мы увеличили количество оценок на 50%, добавив вызов после третьей прочитанной книги.

Что делать после исчерпания квоты?

Отметим: когда квота кончилась, нативный диалог не появится. Альтернатива — deeplink на страницу отзыва:

let appID = "123456789"
let url = URL(string: "https://apps.apple.com/app/id\(appID)?action=write-review")!
UIApplication.shared.open(url)

val uri = Uri.parse("market://details?id=${packageName}") startActivity(Intent(Intent.ACTION_VIEW, uri)) 

Используйте deeplink только для пользователей с высокой лояльностью — это сохранит позитивный опыт. Nice-to-have: показывать кастомное окно с предложением оставить отзыв, но с низкой конверсией.

Практические рекомендации по избеганию перерасхода квоты

• Устанавливайте минимальный интервал между запросами (например, 7 дней).
• Используйте флаг hasRequestedReview в UserDefaults/SharedPreferences, чтобы не вызывать API при каждом значимом событии.
• A/B-тестируйте триггеры на небольшой выборке, прежде чем раскатывать на всех.
• Мониторьте частоту показов через аналитические события — если за неделю диалог не появился ни разу при выполнении условий, проверьте квоту.

Что входит в работу

• Анализ пользовательского флоу и выбор 2–3 триггеров с учётом квот.
• Интеграция In-App Review на iOS и Android (код + fallback).
• Настройка FakeReviewManager для QA.
• Документация и код-ревью.

Ориентировочные сроки

Точное время зависит от сложности логики. Свяжитесь с нами для оценки вашего сценария. Мы поможем подобрать оптимальные триггеры и избежать перерасхода квот. Закажите консультацию по интеграции In-App Review.