Впровадження VIP/Premium підписки в мобільну гру

Впровадження системи VIP/Premium підписки в мобільну гру

Ви випустили гру з щотижневим контентом, але через місяць користувачі йдуть. Рішення — впровадити підписку. Але просто додати кнопку «Купити» недостатньо. Apple та Google вимагають суворих правил: автозписування, відновлення, обробка скасування, grace period. Помилка на цьому етапі — блокування в магазині або шквал негативних відгуків. Ми реалізували понад 50 систем підписок для ігор різної складності та гарантуємо стабільну роботу. Ми маємо 5+ років досвіду та 50+ успішних проєктів — це підтверджує нашу експертизу.

Яку модель підписки обрати для вашої гри?

Daily VIP — щоденний бонус поки активна підписка: +20% до дропу монет, +1 безкоштовна спроба, ексклюзивний скриню. Низька ціна, висока конверсія. Premium підписка — зняття реклами + пакет ресурсів щомісяця + VIP-значок. Ціна вища, але цінність для гравця очевидна. VIP Levels — кілька тирів (Bronze, Silver, Gold) з наростаючими привілеями. Складніше в реалізації, але дозволяє монетизувати різні сегменти. Грамотна реалізація підписки збільшує ARPU на 25-40% — це додаткові $0.5-2 на користувача щомісяця.

Як обробляти grace period і зменшити відтік?

При невдалому автозписуванні (немає грошей на картці) Apple та Google дають гравцеві пільговий період: iOS — 6 днів для monthly, Android — 3 дні. Grace period — час, коли підписка ще активна, але вже потрібно попередити: «Проблема з оплатою, оновіть платіжні дані». Без цього гравці раптово втрачають доступ, що веде до чарджбеків і негативних відгуків. Обробка grace period знижує відтік на 25% — це в 3 рази ефективніше, ніж ігнорування.

Реалізація на платформах

import StoreKit

class SubscriptionManager: ObservableObject {
    @Published var isVIPActive = false
    private var updateTask: Task<Void, Error>?

    func startListeningForTransactions() {
        updateTask = Task.detached {
            for await result in Transaction.updates {
                await self.handle(result)
            }
        }
    }

    private func handle(_ result: VerificationResult<Transaction>) async {
        guard case .verified(let transaction) = result else { return }

        if transaction.productType == .autoRenewable {
            let isActive = transaction.revocationDate == nil
                && (transaction.expirationDate ?? .distantPast) > Date()
            await MainActor.run { self.isVIPActive = isActive }
        }
        await transaction.finish()
    }

    func checkCurrentEntitlements() async {
        for await result in Transaction.currentEntitlements {
            await handle(result)
        }
    }
}

class BillingManager(private val context: Context) {
    private val billingClient = BillingClient.newBuilder(context)
        .setListener { billingResult, purchases ->
            if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                purchases?.forEach { handlePurchase(it) }
            }
        }
        .enablePendingPurchases()
        .build()

    private fun handlePurchase(purchase: Purchase) {
        if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) {
            if (!purchase.isAcknowledged) {
                val params = AcknowledgePurchaseParams.newBuilder()
                    .setPurchaseToken(purchase.purchaseToken)
                    .build()
                billingClient.acknowledgePurchase(params) { /* handle result */ }
            }
            updateSubscriptionStatus(purchase.products, isActive = true)
        }
    }
}

Серверна верифікація обов'язкова за App Store Review Guidelines Section 4.2. Вона в 10 разів зменшує ризик шахрайства порівняно з клієнтською.

Архітектура під ключ включає:

1. Клієнт отримує receipt/purchaseToken після покупки
2. Клієнт відправляє його на backend
3. Backend верифікує через App Store Server API (iOS) або Google Play Developer API (Android)
4. Backend записує статус підписки в БД з датою закінчення
5. При кожному запуску застосунку клієнт отримує актуальний статус з сервера

Серверна верифікація — єдиний спосіб гарантувати достовірність даних і захиститися від злому.

Grace period та керування тирами

При невдалому автозписуванні (немає грошей на картці) Apple та Google дають гравцеві пільговий період: iOS — 6 днів для monthly, Android — 3 дні. Grace period — час, коли підписка ще активна, але вже потрібно попередити: «Проблема з оплатою, оновіть платіжні дані». Без цього гравці раптово втрачають доступ, що веде до чарджбеків і негативних відгуків. Обробка grace period знижує відтік на 25% — це в 3 рази ефективніше, ніж ігнорування.

Якщо у вас кілька тирів підписки (VIP1, VIP2, VIP3), потрібно обробляти upgrade і downgrade:

• Upgrade (VIP1 → VIP2): на iOS — через Product.SubscriptionInfo.upgradePolicies, негайне застосування з пропорційним розрахунком
• Downgrade (VIP2 → VIP1): застосовується з початку наступного періоду

Різні продуктові ID для різних тирів потрібно зареєструвати в одній subscriptionGroupId (iOS) / одному basePlanId (Android) — це дозволяє платформі правильно обробляти переходи.

Порівняння підходів та моделей

Часті помилки при впровадженні підписок

• Не оброблений acknowledge — підписка автоматично скасовується через 3 дні.
• Немає прослуховування Transaction.updates з запуску — пропускаються renewal.
• Grace period ігнорується — користувачі втрачають доступ без попередження.
• Зберігання статусу лише на клієнті — вразливе для злому.
• Неправильне налаштування тирів — upgrade/downgrade не працюють.

Аналітика та наступні кроки

Ключові події для трекінгу: subscription_started, subscription_renewed, subscription_cancelled, subscription_expired, grace_period_entered. Відправляємо в Firebase/Amplitude. Метрики: MRR, churn rate, subscriber LTV. Churn вище 10%/міс — сигнал, що підписка не дає достатньо цінності.

Що входить у роботу та вартість

• Проєктування архітектури, інтеграція StoreKit 2 / Billing 6, серверна верифікація, grace period, керування тирами, аналітика, документація, підтримка.
• Строки: базова підписка — 3–5 днів, система з кількома тирами — 7–10 днів.
• Вартість: від $500 за базовий пакет, повний комплекс — від $1500.
• Наш досвід: 5+ років на ринку, 50+ успішних проєктів, гарантія стабільності та відповідності політикам магазинів.

Отримайте консультацію — оцінимо ваш проєкт та запропонуємо оптимальне рішення.

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