Інтеграція 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 дні. Вартість розраховується індивідуально після аналізу проєкту. Замовте консультацію — наші інженери оцінять ваш проєкт і запропонують рішення під ключ. Отримайте вивірену інтеграцію, яка збільшить дохід і задоволеність користувачів.