Інтеграція Unity Ads: від ініціалізації до монетизації

Інтеграція Unity Ads: від ініціалізації до монетизації

Ми часто бачимо ситуацію: гра готова, монетизація через AdMob або Appodeal дає жалюгідні $3-5 eCPM на Tier-1, fill rate падає до 40%. Unity Ads — не просто альтернатива. Для ігрових проєктів це основна рекламна мережа з eCPM до $15 і fill rate 95%. Але без правильного налаштування SDK (ініціалізація, плейсменти, медіація) ці цифри залишаться на папері. Розберемо ключові блоки інтеграції та типові помилки.

Чому Unity Ads виграє в іграх?

Unity Ads — рекламна мережа, заточена під ігрову аудиторію. На відміну від універсальних мереж, конкуренція рекламодавців тут вища для ігрового інвентарю. Для rewarded video ставки можуть бути на 20-30% вищими, ніж через AdMob mediation. При цьому fill rate для якісних ігор стабільно >95%, а вартість інсталяції (CPI) для рекламодавців нижча — за рахунок цього власники додатків отримують більше.

Які проблеми вирішує інтеграція Unity Ads?

• Низький fill rate в іграх. Unity Ads спеціалізується на ігровій аудиторії, тому конкуренція рекламодавців вища — fill rate стабільно >95% для rewarded відео, тоді як універсальні мережі дають 60-70%.
• eCPM нестабільний. Через AdMob mediation Unity Ads може показувати ставки на 20-30% вищі, ніж інші мережі, для користувачів із Tier-1 країн (США, Канада, Австралія, Західна Європа). При правильному налаштуванні медіації eCPM зростає на 25%.
• Складність налаштування GDPR. Без коректного consent SDK покаже non-targeted рекламу, eCPM впаде на 40%. Налаштовуємо метадані правильно.
• Проблеми з креативами. Unity Ads використовує автоматичну генерацію креативів, але важливо налаштувати плейсменти під конкретні механіки гри — інакше конверсія падає.

Як правильно налаштувати Unity Ads SDK?

SDK версії 4.x — актуальна. Ініціалізація обов'язкова з тестовим режимом. Код:

UnityAds.initialize(context, "GAME_ID", isTestMode, object : IUnityAdsInitializationListener {
    override fun onInitializationComplete() {
        loadInterstitial()
    }
    override fun onInitializationFailed(error: UnityAds.UnityAdsInitializationError, message: String) {
        Log.e("UnityAds", "Init failed: $message")
    }
})

Тестовий режим обов'язковий на етапі розробки. Без нього можна випадково зараховувати реальні покази — ризик перевищення budget і бан акаунта. Після інтеграції обов'язково переключіть на false та перевірте роботу промо-реклами.

Як інтегрувати підтримку GDPR?

Без згоди користувача Unity Ads показуватиме лише нетарифіковану рекламу, eCPM впаде на 40%. Налаштування GDPR через MetaData:

val metaData = MetaData()
metaData.set("gdpr.consent", true)
UnityAds.setMetaData(metaData)

Або використовуйте UnityAds.setPrivacyConsent(false), якщо згоди немає. Рекомендуємо інтегрувати CMP (наприклад, Google UMP SDK) та передавати сигнал через callback. Для iOS аналогічно через UnityAds.setMetaData. Детальніше в документації Unity Ads.

Rewarded відео — основний формат для ігор

Rewarded video — візитівка Unity Ads. Користувач отримує винагороду лише за повний перегляд. Патерн завантаження та показу:

fun loadAd() {
    UnityAds.load("rewardedVideo", object : IUnityAdsLoadListener {
        override fun onUnityAdsAdLoaded(placementId: String) {
            isAdReady = true
        }
        override fun onUnityAdsFailedToLoad(
            placementId: String,
            error: UnityAds.UnityAdsLoadError,
            message: String
        ) {
            // Спробуйте повторити через 30 секунд
        }
    })
}

fun showAd(activity: Activity) {
    if (!isAdReady) return
    UnityAds.show(activity, "rewardedVideo", object : IUnityAdsShowListener {
        override fun onUnityAdsShowComplete(
            placementId: String,
            state: UnityAds.UnityAdsShowCompletionState
        ) {
            if (state == UnityAds.UnityAdsShowCompletionState.COMPLETED) {
                grantReward()
            }
        }
    })
}

Нараховувати винагороду тільки при COMPLETED — вимога Unity та захист від фроду. Ніколи не нараховуйте винагороду при SKIPPED — це порушення правил і може призвести до бану.

Порівняння форматів реклами Unity Ads

Unity Ads vs AdMob для ігор: що краще?

Процес інтеграції під ключ

Наша команда проводить інтеграцію за 1–3 дні:

1. Аналіз: підбір плейсментів, налаштування eCPM floor, конфігурація mediation. Визначаємо, чи потрібна водоспадна медіація або лише header bidding.
2. Розробка: ініціалізація SDK, реалізація rewarded/interstitial/banner, обробка подій. Пишемо код для передачі подій в аналітику (Firebase, AppsFlyer).
3. GDPR: інтеграція consent flow через MetaData та (опціонально) через CMP. Тестуємо, що при відмові реклама не показується або показується нетарифікована.
4. Тестування: перевірка тестових оголошень, сумісність з різними версіями ОС, коректна передача подій в аналітику. Використовуємо TestFlight та Firebase App Distribution.
5. Деплой: перевірка промо-реклами, моніторинг eCPM через Unity Dashboard. Після запуску слідкуємо за метриками перший тиждень.

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

• Підключений Unity Ads SDK з робочими плейсментами.
• Налаштовану медіацію через AdMob (або іншу платформу).
• Готовий механізм нарахування винагород.
• Коректну передачу GDPR-згоди.
• Документацію з описом інтеграції.

Чому обирають нас

Ми працюємо з мобільною монетизацією 10+ років, реалізували понад 50 проєктів з Unity Ads — від гіперказуальних ігор до MMO. Гарантуємо стабільну інтеграцію відповідно до офіційної документації Unity Ads. Якщо eCPM після інтеграції не зростає — безкоштовно проводимо аудит конфігурації. Наші клієнти відзначають середній ріст eCPM на 40% після правильного налаштування медіації.

Зв'яжіться з нами, щоб отримати консультацію з налаштування Unity Ads. Оцінимо ваш проєкт і запропонуємо оптимальну архітектуру монетизації. Замовте аудит поточної конфігурації — це допоможе виявити вузькі місця та збільшити дохід.

Монетизація мобільних додатків: 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.