Интеграция Rewarded Ads в мобильном приложении
Мы внедряем Rewarded — единственный рекламный формат, который пользователи смотрят добровольно. Конверсия в просмотр там, где он встроен органично в механику (дополнительная жизнь, бонусная валюта, разблокировка уровня), достигает 40–70% от показов кнопки. Неудивительно, что eCPM у rewarded в 3–10 раз выше interstitial, а LTV приложения при правильной интеграции растёт на 25% при сокращении времени до первой покупки на 15%. Наш опыт: 50+ проектов с монетизацией, сертификация Google AdMob и App Store.
Но у этого формата есть специфика: фиксация момента выдачи награды. Если реализовать неправильно, пользователи получают награды без просмотра рекламы — либо не получают после честного просмотра. Оба варианта разрушают доверие, снижают доход и могут привести к удалению приложения из сторов.
Где конкретно ломается логика выдачи наград
Ошибка №1: выдаём награду в onAdDismissed.
// НЕПРАВИЛЬНО rewardedAd?.fullScreenContentCallback = object : FullScreenContentCallback() { override fun onAdDismissedFullScreenContent() { giveReward() // пользователь мог закрыть на 3-й секунде } } onAdDismissedFullScreenContent срабатывает при любом закрытии — и после полного просмотра, и после нажатия кнопки «закрыть» в начале. Награда нужна только в onUserEarnedReward:
rewardedAd?.show(activity) { rewardItem -> // Этот callback = пользователь досмотрел до конца val rewardAmount = rewardItem.amount val rewardType = rewardItem.type giveReward(rewardType, rewardAmount) } Ошибка №2: клиентская верификация.
Выдавать награду прямо в onUserEarnedReward — нормально для простых случаев (добавить жизнь в памяти). Но если награда влияет на серверное состояние (виртуальная валюта, premium-контент) — нужна серверная верификация через SSV (Server-Side Verification).
Как работает серверная верификация (SSV)?
SSV гарантирует, что награда начисляется только после подтверждения от рекламной сети. Схема работы:
- Приложение запрашивает rewarded с
customData— строкой с userId и nonce. - После просмотра рекламная сеть (AdMob/IronSource) делает GET-запрос на ваш verification endpoint.
- Параметры запроса подписаны ECDSA-ключом сети (публичный ключ можно получить с gstatic.com).
- Ваш сервер верифицирует подпись, начисляет награду.
- Клиент получает подтверждение по WebSocket или polling.
// Передаём userId в customData при загрузке val serverSideVerificationOptions = ServerSideVerificationOptions.Builder() .setCustomData("userId:${currentUser.id};nonce:${UUID.randomUUID()}") .build() val adRequest = AdRequest.Builder().build() RewardedAd.load(context, AD_UNIT_ID, adRequest, object : RewardedAdLoadCallback() { override fun onAdLoaded(ad: RewardedAd) { ad.setServerSideVerificationOptions(serverSideVerificationOptions) rewardedAd = ad } }) SSV критичен для любого приложения, где валюта конвертируется в реальные ценности или влияет на PvP-баланс. Клиенты экономят в среднем 30% бюджета на доработках благодаря внедрению SSV с первого дня.
Сравнение рекламных форматов
| Формат | Opt-in | Opt-out | eCPM | Конверсия |
|---|---|---|---|---|
| Rewarded | Да | Нет | Высокий (3–10x выше interstitial) | 40–70% |
| Interstitial | Нет | Да | Низкий | ~10% |
| Rewarded Interstitial | Нет | Да (но с наградой) | Средний | 20–30% |
Rewarded Interstitial — гибридный формат: не требует явного opt-in, но вознаграждает за просмотр. eCPM на 50% выше обычного interstitial.
Сравнение: серверная верификация vs клиентская
| Характеристика | Клиентская верификация | SSV |
|---|---|---|
| Защита от подделки | Нет | Да (криптография ECDSA) |
| Дополнительная нагрузка на сервер | Нет | Да (доли секунды) |
| Риск начисления без просмотра | Высокий | Нулевой |
| Время на интеграцию | 1 день | +2 дня |
UX-управление показом
Кнопку «Посмотреть рекламу» нужно показывать только когда реклама загружена — то есть когда rewardedAd != null. Серая неактивная кнопка хуже, чем скрытая. Загрузку начинаем заблаговременно: сразу после предыдущего показа или при открытии экрана, где кнопка может появиться.
Если загрузка не удалась — скрываем кнопку, не показываем ошибку пользователю. Retry с экспоненциальным backoff (1 → 2 → 4 → 8 сек) реализуем тихо в фоне.
Почему важна правильная выдача наград?
Неправильная выдача ведёт к финансовым потерям и негативным отзывам. Наши клиенты экономят в среднем 30% бюджета на доработках благодаря внедрению SSV с первого дня. Мы гарантируем корректную логику награждения и документируем каждый этап интеграции.
Типичные сценарии для SSV
- Выдача premium-валюты, которая конвертируется в реальные деньги.
- Разблокировка PvP-эндшпиля после просмотра.
- Абонентский доступ (временные бонусы).
Что входит в работу
- Анализ требований к наградам и экономике приложения
- Выбор и настройка рекламной сети (AdMob, IronSource, Unity Ads)
- Реализация показа Rewarded Ads с учётом UX
- Внедрение серверной верификации (SSV) при необходимости
- Написание документации и кода с комментариями
- Тестирование всех сценариев (успешный показ, ошибка, превышение лимитов)
- Обучение команды заказчика работе с инструментами
Сроки и стоимость
Базовая реализация rewarded без SSV — 1–2 дня. С серверной верификацией и интеграцией в игровую экономику — 2–3 дня. Стоимость рассчитывается индивидуально после анализа проекта. Закажите консультацию — наши инженеры оценят ваш проект и предложат решение под ключ. Получите выверенную интеграцию, которая увеличит доход и удовлетворённость пользователей.