Реалізація Rewarded Ads для мобільної гри

Гравець щойно програв на 10-му рівні — витратив 15 хвилин, злість і бажання кинути. Правильно розміщена Rewarded Ads перетворює цю фрустрацію на дохід без втрати лояльності. Але неправильна інтеграція руйнує баланс економіки та зменшує retention. Ми займаємося rewarded-інтеграцією 5+ років, реалізували 30+ проєктів для iOS та Android — від гіперказуальних до RPG. Один із кейсів: після налаштування continue-after-fail retention зріс на 12%, а eCPM збільшився на 25%. Середній ріст eCPM після нашого налаштування — 25-40% (наприклад, з $6 до $9 для одного з проєктів). Розберемо технічні нюанси та підводні камені.

Як вибрати placement для Rewarded Ads?

Placement — це точка в ігровому циклі, де в гравця виникає потреба, яку він готовий «оплатити» переглядом реклами. Найефективніші:

• Continue after fail — конверсія 30–50% за умови, що гравець не бачив рекламу на цьому екрані раніше. Показуємо після onGameOver, до екрану результатів. Ліміт: 1–2 рази за спробу.
• Daily bonus multiplier — «дивись рекламу — отримай x3 до щоденної нагороди». Не порушує баланс, конверсія стабільно висока.
• Extra currency / chest unlock — конкретна пропозиція: «+50 gems» замість «бонус». Працює в головному меню або після рівня.

Як технічно інтегрувати rewarded на Unity?

Використовуємо SDK AdMob (Google Mobile Ads) або IronSource (LevelPlay). Для AdMob ініціалізація:

private RewardedAd rewardedAd;

public void LoadRewardedAd() {
    var adUnitId = Application.platform == RuntimePlatform.Android
        ? "ca-app-pub-xxx/yyy" : "ca-app-pub-xxx/zzz";
    RewardedAd.Load(adUnitId, new AdRequest(), (ad, error) => {
        if (error != null) { Debug.LogWarning($"Rewarded load failed: {error}"); return; }
        rewardedAd = ad;
        RegisterRewardedAdEvents(rewardedAd);
    });
}

private void RegisterRewardedAdEvents(RewardedAd ad) {
    ad.OnAdFullScreenContentClosed += () => {
        LoadRewardedAd();
    };
}

public void ShowRewardedAd(System.Action<int> onRewarded) {
    if (rewardedAd == null || !rewardedAd.CanShowAd()) {
        Debug.Log("Rewarded not ready");
        return;
    }
    rewardedAd.Show(reward => {
        onRewarded?.Invoke(reward.Amount);
    });
}

IronSource (LevelPlay) вимагає виклику IronSource.Agent.loadRewardedVideo() заздалегідь, а кнопку показувати тільки при IronSource.Agent.isRewardedVideoAvailable() == true.

void Start() {
    IronSource.Agent.loadRewardedVideo();
}

public void OnShowRewardedClicked() {
    if (IronSource.Agent.isRewardedVideoAvailable()) {
        IronSource.Agent.showRewardedVideo();
    }
}

private void OnRewardedVideoAdRewarded(IronSourcePlacement placement) {
    int rewardAmount = placement.getRewardAmount();
    // нарахувати нагороду
}

Чому серверна верифікація (SSV) обов'язкова?

Якщо rewarded дає тверду валюту (gems, crystals) — без SSV нагороди накручуються інструментами типу Frida за кілька хвилин. AdMob SSV обробляє callback швидше за IronSource, що знижує затримку нарахування на 200 мс. Схема:

1. Клієнт передає userId та унікальний nonce у customData при запиті реклами.
2. AdMob/IronSource включають їх у SSV-callback на ваш backend з ECDSA-підписом.
3. Сервер перевіряє підпис, унікальність nonce (щоб один callback не пройшов двічі) та нараховує валюту.

Реалізація клієнта — 0.5 дня, серверна частина — 1 день з тестуванням.

from flask import Flask, request
from ecdsa import VerifyingKey
import json

app = Flask(__name__)

@app.route('/ssv_callback', methods=['POST'])
def ssv_callback():
    data = request.json
    signature = data['signature']
    payload = data['payload']
    vk = VerifyingKey.from_pem(open('public_key.pem').read())
    if vk.verify(signature, payload.encode()):
        # Перевірити nonce в Redis
        return 'OK', 200
    return 'Invalid signature', 400

Які ліміти показів ставити?

Ліміти мають бути на сервері, а не тільки на клієнті (PlayerPrefs скидаються). У проєкті з MMO-грою ми налаштували ліміти через Redis, щоб гарантувати унікальність nonce навіть при високому RPS. Типові: 5–10 rewarded/день для валюти, 1–2/день для continue. Жорсткий ліміт вбиває дохід, м'який — руйнує економіку. Рекомендуємо починати з 8 rewarded/день і A/B-тестувати крок у ±2. A/B-тестування дозволяє знайти баланс між доходом та економікою без ризику.

Як ми інтегруємо rewarded ads: покроковий процес

1. Аудит поточної інтеграції (якщо є) та рекомендації щодо збільшення eCPM.
2. Підбір placement під вашу ігрову економіку.
3. Реалізація на Unity (AdMob, IronSource) або нативних SDK (iOS/Android).
4. Налаштування SSV-бекенду (будь-який стек: Node.js, Python, Go).
5. A/B-тестування placement та лімітів.
6. Документація та 1 місяць підтримки.

Що ви отримуєте в результаті

Після завершення роботи ви отримуєте:

• Робочі rewarded placements з оптимізованим часом показу.
• Серверну верифікацію SSV із захистом від накруток.
• Документацію за ключовими скриптами та конфігами.
• Доступ до бекенд-коду для самостійного доопрацювання.
• 1 місяць технічної підтримки та консультацій.

Строки орієнтовно

Базова інтеграція з 2–3 placement та лімітами — від 2 днів. Із SSV та серверною логікою нагород — від 3 днів. Вартість розраховується індивідуально.

Замовте аудит вашої поточної інтеграції — безкоштовно оцінимо проєкт. Зв'яжіться з нами для консультації.

Монетизація мобільних додатків: IAP, підписки та рекламна медіація

Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку. Наш досвід (більше 7 років у мобільній розробці) показує, що грамотна монетизація збільшує LTV на 30–60% вже в перші три місяці після впровадження. Отримайте консультацію з монетизації вашого додатка — проаналізуємо поточну модель і знайдемо точки зростання.

Чому StoreKit 2 — найкращий вибір для IAP?

StoreKit 2 (iOS 15+) — сучасний API з async/await та верифікованими транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно з StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно надсилати receipt на сервер для базової перевірки.

Але сервер-сайд валідація все одно потрібна для consumable покупок та проти fraud. App Store Server API замінює старий /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дають real-time події: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллінгу.

Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток впав до finishTransaction — покупка висить у черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нарахування.

Як не втратити дохід на підписках?

Підписочна модель вимагає відстеження станів: тріал → активна → grace period → expired → refunded. RevenueCat — фактичний стандарт для керування підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.

Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо дані не повинні залишати інфраструктуру або є нестандартна логіка. Ми гарантуємо, що налаштування webhooks та обробка подій життя підписки виконується без втрат — перевірено на проектах з аудиторією понад 500 тис. DAU.

Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення CPM через bidding

Показувати рекламу через одне джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у декількох мереж і показує найкращу ставку. Google AdMob — основа для banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий де-факто стандарт. MAX використовує In-App Bidding — real-time аукціон без водоспаду. На практиці MAX дає CPM на 15-30% вище класичного waterfall (залежить від гео та аудиторії). У США для rewarded відео CPM може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре закриває азійську аудиторію.

Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не погодилися. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких рев'ю падає.

Як вибрати рекламні мережі для медіації?

Як ми впроваджуємо монетизацію: покроковий процес

1. Аудит поточної моделі — аналіз воронки, paywall, цінових тирів та виявлення вузьких місць.
2. Проектування моделі — вибір типу (subscription, consumable, non-consumable) та оптимізація цінових точок.
3. Інтеграція IAP — налаштування StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
4. Рекламна медіація — підключення 3-6 мереж, налаштування waterfall або In-App Bidding, тестування fill rate.
5. Аналітика та когорти — інтеграція RevenueCat, Amplitude або Firebase для відстеження LTV.
6. A/B тестування paywall — використання Remote Config для експериментів без релізу.
7. Запуск та моніторинг — 2 тижні безкоштовної підтримки після запуску, фікс багів по SLA 24 години.

Freemium: проектування моделі та paywall

Freemium працює коли межа між безкоштовним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) керують доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови тріалу, проводити акції.

Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Жодних перевірок isPremium розкиданих по всьому коду. Досвід показує: такий підхід знижує кількість багів з paywall на 80% (підтверджено на 30+ проектах).

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
• Рекламна медіація — налаштування MAX / AdMob, підключення 3-6 мереж, тестування fill rate.
• Налаштування аналітики — RevenueCat, Amplitude / Firebase, когортний аналіз.
• Документація — опис ентайтлментів, процедура відновлення, чек-лист рев'ю.
• Навчання команди — розбір типових помилок, рекомендації з підтримки.
• Гарантія — безкоштовна підтримка 2 тижні після запуску, фікс багів по SLA 24 години.

Терміни орієнтовно

Вартість розраховується індивідуально. Ми працюємо в цій сфері більше 8 років і реалізували більше 40 проектів з монетизацією — багато з них пройшли App Store Review без жодного блокування. Зв'яжіться з нами для аудиту або замовте консультацію — розповімо, які точки зростання є у вашому додатку.

Джерела: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.