Інтеграція рекламної мережі AppLovin (MAX) у мобільний додаток

Уявіть, що fill rate впав до 72%, а eCPM скаче від $2 до $8 — бюджет монетизації нестабільний. Це типова ситуація для waterfall: мережі перебираються по черзі, і bid не бере участі в аукціоні. Ми інтегруємо AppLovin MAX — медіатор з in-app bidding. MAX проводить аукціон між усіма мережами одночасно, обирає максимальну ставку — і оголошення показується відразу. Fill rate підіймається до 95%+, eCPM стабілізується. Наприклад, при переході з waterfall на MAX наш клієнт збільшив дохід від реклами на 25% за місяць. З MAX ви заробляєте від $8 до $15 за кожний rewarded показ — waterfall часто дає менше ніж $6.

Стек: iOS (Swift 5.9+, SwiftUI), Android (Kotlin, Jetpack Compose), Flutter (Dart 3.x). MAX SDK єдиний для всіх платформ. Управління медіацією — через Dashboard. Підтримуємо Google AdMob, Meta Audience Network, Unity Ads, IronSource, Vungle та інші. Для кожної мережі — окремий adapter. У build.gradle підключаємо як runtime dependency. Версії адаптерів синхронізуємо з MAX SDK.

Чому MAX вигідніше за waterfall?

SDK ініціалізація

// Android — AppLovin SDK
AppLovinSdk.initializeSdk(this) { sdkConfig ->
    // SDK ініціалізовано, можна завантажувати оголошення
    initializeAds()
}

// Опціонально — передаємо User ID для server-side verification rewarded
AppLovinSdk.getInstance(context).settings.userIdentifier = currentUser.id

Ключ sdk_key прописується в AndroidManifest.xml як meta-data. На iOS — в Info.plist.

Підключувані мережі в MAX

MAX підтримує 20+ рекламних мереж: Google AdMob, Meta Audience Network, Unity Ads, IronSource, Vungle, Mintegral, Pangle та інші. Кожна мережа підключається через окремий adapter:

// build.gradle — приклад підключення адаптерів
implementation 'com.applovin.mediation:google-adapter:23.x.x'
implementation 'com.applovin.mediation:facebook-adapter:6.x.x'
implementation 'com.applovin.mediation:unityads-adapter:4.x.x'

Кожен adapter потрібно ініціалізувати згідно з вимогами мережі (App ID, Placement ID). Версії адаптерів мають бути сумісні з версією MAX SDK — оновлювати потрібно разом. Ми перевіряємо сумісність і оновлюємо адаптери при кожному релізі.

Rewarded interstitial — формат із найбільшим eCPM

val rewardedAd = MaxRewardedAd.getInstance("YOUR_AD_UNIT_ID", activity)
rewardedAd.setListener(object : MaxRewardedAdListener {
    override fun onAdLoaded(ad: MaxAd) { isReady = true }
    override fun onAdLoadFailed(adUnitId: String, error: MaxError) {
        // MAX автоматично retry — не потрібно вручну
    }
    override fun onUserRewarded(ad: MaxAd, reward: MaxReward) {
        grantReward(reward.amount, reward.label)
    }
    override fun onAdHidden(ad: MaxAd) {
        rewardedAd.loadAd() // Завантажуємо наступний заздалегідь
    }
})
rewardedAd.loadAd()

MAX автоматично керує retry-логікою при помилках завантаження — не потрібно реалізовувати власний exponential backoff.

Як налаштувати Server-Side Verification?

MAX підтримує SSV (Server-Side Verification) для rewarded реклами: після перегляду MAX надсилає POST на вказаний сервер із зашифрованими параметрами (user_id, reward, timestamp, підпис HMAC). Сервер верифікує підпис і нараховує нагороду. Це захищає від клієнтського фроду: користувач не може нарахувати собі нагороду без реального перегляду. Ми налаштовуємо SSV endpoint та гарантуємо коректну обробку.

A/B тестування та аналітика

AppLovin Dashboard показує eCPM по кожній мережі в медіації, win rate bidding-аукціону, DAU×eCPM. Вбудований A/B тест дозволяє порівнювати конфігурації медіації без деплою. Ми використовуємо його для оптимізації: наприклад, змінюємо частку трафіку на нову мережу і дивимося eCPM. Детальніше — у MAX SDK documentation.

Що входить в інтеграцію MAX

• SDK ініціалізація — підключення MAX SDK з коректним sdk_key, налаштування конфігурації (User ID, consent, GDPR).
• Підключення 3–5 рекламних мереж — встановлення адаптерів, налаштування Placement ID, тестування.
• Налаштування Server-Side Verification — endpoint на сервері, верифікація підписів.
• Інтеграція всіх форматів — rewarded, interstitial, banner, native. Оптимізація таймінгів показу.
• A/B тестування — порівняння конфігурацій медіації.
• Документація та навчання — чек-лист для публікації в сторах, рекомендації щодо оновлення.
• Підтримка — моніторинг fill rate та eCPM, оперативне вирішення проблем.

Процес роботи

1. Аналіз — збираємо поточні метрики монетизації, визначаємо цільовий fill rate та eCPM.
2. Інтеграція — підключаємо MAX SDK, налаштовуємо адаптери мереж, реалізуємо SSV.
3. Тестування — тестуємо на реальних пристроях через TestFlight та Firebase App Distribution, перевіряємо тестові Ad Unit IDs.
4. Деплой — публікуємо оновлення в App Store та Google Play.
5. Моніторинг — слідкуємо за performance, підкручуємо конфігурацію.

Терміни: від 2 до 5 днів залежно від кількості мереж та складності SSV. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо план інтеграції та розрахуємо вартість.

Досвід нашої команди — понад 5 років у монетизації мобільних додатків, 50+ проєктів з рекламними SDK. Гарантуємо стабільний fill rate 95%+ та відповідність App Store Review Guidelines (Section 4.2, 5.1). Напишіть — обговоримо деталі.

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