Реалізація Win-Back кампаній для скасованих підписок у мобільному застосунку

Користувач скасував підписку — і ваш MRR падає. У середньому від 20% до 30% скасувань можна відкотити за допомогою правильно налаштованої win-back-кампанії. Ми маємо 5+ років досвіду та реалізували 15+ проектів з мобільними підписками загальною аудиторією понад 1 млн користувачів. У цьому матеріалі — готовий код, ключові метрики та реальні підводні камені.

Типовий кейс: фітнес-застосунок втрачав 40% підписників після першого місяця. Впровадження win-back з push-повідомленнями та сегментованими оферами підняло LTV реактивованих на 35% за квартал. Ключ — комбінація Apple Win-Back Offers (iOS 18+), Promotional Offers і кастомних paywall.

Без win-back у вас витікає до 10% щомісячного MRR тільки від cancelled subscribers. Системний підхід повертає 15–25% таких користувачів. Однак таймінг офера критичний: push через 3–7 днів після скасування подвоює конверсію порівняно з тижнем бездіяльності. Головне — не набриднути: частота не частіше одного push на 7 днів і повага до вибору користувача. Розгляньмо технічну реалізацію.

Три канали win-back

• Push-повідомлення для підписки з deep link на офер — надсилається через FCM/APNs на пристрої користувачів, які скасували підписку N днів тому.
• In-app офер при наступному відкритті — для тих, хто все ще відкриває застосунок після скасування.
• Apple Win-Back Offers — нативний механізм Apple (iOS 18+), який автоматично показує офери через App Store без серверної інфраструктури.

Як працюють Apple Win-Back Offers?

Новітній інструмент налаштовується в App Store Connect → Subscriptions → Win-Back Offers. Apple сама визначає eligible користувачів (колишні підписники конкретної Subscription Group) і відображає офер на сторінці застосунку в App Store. Докладніше в документації Apple Win-Back Offers. На клієнті потрібно обробити транзакцію, яка надходить при активації:

// Слухаємо Transaction.updates при запуску
for await result in Transaction.updates {
    if case .verified(let transaction) = result {
        if transaction.offerType == .winBackOffer {
            // Користувач повернувся через Win-Back — розблоковуємо
            await restoreSubscriptionAccess(transaction)
            await transaction.finish()

            // Логуємо для аналітики
            Analytics.logEvent("win_back_reactivated", parameters: [
                "offer_id": transaction.offerID ?? "unknown",
                "product_id": transaction.productID
            ])
        }
    }
}

Promotional Offers для win-back (iOS 14+)

Для iOS нижче 18 або для in-app win-back використовуємо Promotional Offers із серверним підписом:

// Визначаємо кандидатів для win-back
func isWinBackCandidate() async -> Bool {
    // Перевіряємо: чи є минула транзакція і немає активної
    var hasExpiredSubscription = false
    var hasActiveSubscription = false

    for await result in Transaction.all {
        if case .verified(let tx) = result,
           tx.productType == .autoRenewableSubscription {
            if tx.expirationDate ?? Date() < Date() {
                hasExpiredSubscription = true
            } else {
                hasActiveSubscription = true
            }
        }
    }
    return hasExpiredSubscription && !hasActiveSubscription
}

// Показуємо win-back paywall при вході в застосунок
func showWinBackOfferIfNeeded() async {
    guard await isWinBackCandidate() else { return }
    guard let offerSignature = try? await apiClient.fetchWinBackSignature() else { return }

    await MainActor.run {
        presentWinBackPaywall(signature: offerSignature)
    }
}

Push-повідомлення для win-back

Серверна логіка: вибираємо користувачів з subscription_expired_at BETWEEN NOW() - 7 DAYS AND NOW() - 3 DAYS і last_app_open > NOW() - 30 DAYS. Надсилаємо push через APNs:

{
    "aps": {
        "alert": {
            "title": "Поверніться до Premium",
            "body": "Спеціальна пропозиція: перший місяць за півціни"
        },
        "badge": 1,
        "sound": "default"
    },
    "deep_link": "app://paywall?offer=win_back_50&utm_source=push&utm_campaign=winback_d7"
}

Deep link відкриває paywall безпосередньо з pre-selected офером. UTM-параметри — для аналітики конверсії.

Чому сегментація критична для win-back?

Офери працюють краще при сегментації користувачів:

Чим довше користувач не повертається, тим агресивніший офер — стандартна модель реактивації підписок.

Порівняння каналів win-back:

Вимірювання ефективності

Обов'язкові метрики:

• Win-back rate: (реактивовані / кандидати на win-back) × 100
• Time to reactivation: медіана днів між скасуванням і поверненням
• LTV reactivated: порівнюємо з LTV користувачів без скасування
• Offer conversion by segment: який офер працює краще для якого сегменту

// Логуємо показ win-back офера
Analytics.logEvent("win_back_offer_shown", parameters: [
    "days_since_cancellation": daysSinceCancellation,
    "offer_type": offerType,
    "segment": userSegment
])

Що входить у роботу

• Визначення win-back кандидатів (клієнт + сервер)
• Apple Win-Back Offers (iOS 18+) або Promotional Offers як fallback
• In-app paywall з win-back офером при наступному відкритті
• Push-нотифікація з deep link на офер
• Сегментація за часом з моменту скасування підписки
• Аналітика: воронка показ → клік → покупка

Терміни та вартість

Базова інтеграція in-app flow з Promotional Offers займає 3–5 днів (від $1,500). З push-інфраструктурою та серверною сегментацією — 5–10 днів (від $3,500). Вартість розраховується індивідуально після аналізу вимог. Зверніться до нас — ми оцінимо ваш проект і підберемо оптимальний стек. Гарантуємо інтеграцію без втрати поточних підписників. Середня економія від win-back кампанії складає до $10,000 на місяць для застосунку з 10,000 підписників.

Зв'яжіться для консультації щодо win-back кампанії — отримайте оцінку та рекомендації для вашого застосунку.

Покрокова інструкція для впровадження win-back кампанії

1. Аналіз поточної бази: визначте кількість скасованих підписок за останні 90 днів та їх сегменти.
2. Налаштування Apple Win-Back Offers: створіть офери в App Store Connect для кожного продукту.
3. Інтеграція клієнтського коду: додайте обробку Transaction.updates з типом .winBackOffer.
4. Налаштування push-кампаній: реалізуйте серверний вибір користувачів та відправку push з deep link.
5. Сегментація та A/B тестування: запустіть різні офери для різних сегментів, виміряйте конверсію.
6. Моніторинг та оптимізація: відстежуйте win-back rate та LTV, коригуйте офери.

Порівняння ефективності каналів win-back

Apple Win-Back Offers ефективніші за Promotional Offers у 1.5 рази завдяки автоматичному відбору. Push-кампанії з deep link ефективніші за звичайні нагадування у 2 рази. Комбінація двох каналів дає найкращий результат: до 35% повернених підписників. Для iOS підписок StoreKit 2 забезпечує швидшу обробку транзакцій, а для Android підписок аналогічну функціональність можна реалізувати через Billing Library.

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