Настройка Introductory Offers в iOS: привлечение новых подписчиков

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Настройка Introductory Offers в iOS: привлечение новых подписчиков
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Реализация Introductory Offers (скидка на первый период) в мобильном приложении

Introductory Offers — мощный инструмент в StoreKit для привлечения новых подписчиков. Apple App Store Review Guidelines (Section 4.2 и 5.1) регулируют их применение. Без корректной реализации пользователь не увидит оффер, а значит — снижается конверсия. При грамотной настройке вводное предложение увеличивает конверсию в подписку на 30–50%. Мы гарантируем, что ваш paywall покажет оффер только тем, кому он действительно доступен. В этой статье разберём, как настроить и проверить eligibility, интегрировать с paywall и избежать типовых ошибок.

Типы Introductory Offers и их настройка

Apple предлагает три типа: freeTrial (бесплатно), payAsYouGo (скидка на каждый период) и payUpFront (единоразовая плата за несколько периодов). Выбор зависит от бизнес-модели: для теста продукта — freeTrial, для привлечения долгосрочных клиентов — payAsYouGo или payUpFront.

Тип Описание Пример
freeTrial Бесплатный период 7 дней бесплатно
payAsYouGo Скидка на каждый период в течение N периодов Первые 3 месяца со скидкой
payUpFront Единоразовая оплата за N периодов 12 месяцев по сниженной цене

Introductory Offer создаётся на уровне подписки: App Store Connect → Subscriptions → [Subscription] → Introductory Offers. Укажите тип, длительность и цену. Важно: оффер применяется только к пользователям, которые никогда не были подписчиками этой subscription group. Apple проверяет это на сервере. Частая ошибка — неправильно указать период: например, для freeTrial нельзя ставить продолжительность 0 дней. Длительность freeTrial обычно составляет 3, 7 или 30 дней.

Как прочитать оффер через StoreKit 2?

Сначала загружаем продукт и проверяем наличие introductory offer:

import StoreKit

// Загружаем продукт
let product = try? await Product.products(for: ["premium_monthly"]).first

// Проверяем наличие introductory offer
if let intro = product?.subscription?.introductoryOffer {
    switch intro.paymentMode {
    case .freeTrial:
        let days = intro.period.value
        let unit = intro.period.unit
        showFreeTrialBanner(days: days)
    case .payAsYouGo:
        showDiscountedPriceBanner(price: intro.displayPrice, period: intro.period)
    case .payUpFront:
        showUpFrontBanner(price: intro.displayPrice, duration: intro.subscriptionPeriod)
    @unknown default: break
    }
}

Почему проверка eligibility критична?

Apple проверяет право на оффер на стороне сервера — Apple Developer Documentation. product.subscription?.introductoryOffer присутствует у каждого продукта, независимо от того, имеет ли пользователь право. Поэтому нужна дополнительная проверка. StoreKit 2 даёт доступ к истории транзакций:

// Проверяем статус подписки через Transaction
for await result in Transaction.currentEntitlements {
    if case .verified(let transaction) = result {
        if transaction.productID == "premium_monthly" {
            userHasBeenSubscriber = true
        }
    }
}

Альтернатива — серверная проверка через App Store Server API. Сервер возвращает isInBillingRetryPeriod и полную историю. Это надёжнее, но сложнее. Наше золотое правило: UI-решение на клиенте, валидация права — на сервере. Такой подход исключает злоупотребления и ошибки.

Как реализовать introductory offer: пошаговая инструкция

  1. Создайте оффер в App Store Connect. Укажите тип, срок и цену. Проверьте duration — для freeTrial он не может быть 0.
  2. Загрузите продукт и прочитайте offer в коде. Используйте Product.products(for:) и проверьте introductoryOffer.
  3. Проверьте eligibility. Через Transaction.currentEntitlements или серверный API. Для iOS 15+ используйте eligibleForIntroOffer.
  4. Создайте UI paywall. Отобразите баннер с условиями оффера, если пользователь eligible.
  5. Протестируйте. Используйте StoreKit Configuration File в Xcode для симуляции сценариев без ожидания 24 часов.
  6. Задокументируйте и передайте в поддержку. Укажите, какие офферы активны и как они отображаются.

Использование RevenueCat

RevenueCat берёт на себя проверку eligibility. Код становится проще:

Purchases.shared.getOfferings { offerings, error in
    if let intro = offerings?.current?.monthly?.product.introductoryDiscount {
        Purchases.shared.checkTrialOrIntroductoryPriceEligibility(
            productIdentifiers: ["premium_monthly"]
        ) { eligibilityDict in
            let eligible = eligibilityDict["premium_monthly"]?.status == .eligible
        }
    }
}

По нашим данным, переход на RevenueCat сокращает время разработки подписочной логики в 2–3 раза, а ошибки снижаются на 70%. Также RevenueCat автоматически обрабатывает восстановление покупок и уведомления.

Отображение в paywall UI

Типичный paywall условно показывает оффер:

struct PaywallView: View {
    let product: Product
    @State private var isEligibleForIntro = false

    var body: some View {
        VStack {
            if let intro = product.subscription?.introductoryOffer,
               isEligibleForIntro {
                IntroOfferBanner(offer: intro)
                    .transition(.opacity)
            }
            SubscriptionButton(product: product)
        }
        .task {
            await checkEligibility()
        }
    }

    func checkEligibility() async {
        isEligibleForIntro = await checkIntroEligibility()
    }
}

Сравнение методов проверки eligibility

Метод Сложность Надёжность Рекомендация
StoreKit 2 (Transaction.currentEntitlements) Средняя Высокая (только iOS) Для простых приложений
App Store Server API Высокая Максимальная Для комплексных проектов
RevenueCat Низкая Высокая Универсальное решение

Типичные ошибки при настройке Introductory Offers

  • Неверно указанная длительность freeTrial (например, 0 дней) — оффер не будет применён.
  • Игнорирование eligibility — оффер показывается всем, что приводит к ошибкам при покупке.
  • Отсутствие тестирования через StoreKit Configuration File — приходится ждать 24 часа для повторной проверки.
  • Не учтена версия iOS: Transaction.currentEntitlements доступен только с iOS 15. Для более старых версий используйте серверный API или библиотеку типа RevenueCat.
  • Забыли обновить paywall при изменении статуса подписки (например, после восстановления).

Что входит в работу

  • Чтение и отображение introductory offer из объекта Product (StoreKit 2)
  • Проверка eligibility через Transaction.currentEntitlements или серверную валидацию
  • UI-компонент paywall с условным отображением оффера
  • Тестирование через StoreKit Configuration File в Xcode (sandbox без ожидания 24 ч.)
  • Логирование в аналитику: показ оффера, конверсия, тип оффера
  • Документация и передача знаний вашей команде

Сроки и стоимость

От 3 до 5 дней в зависимости от сложности paywall UI и наличия серверной валидации. Стоимость рассчитывается индивидуально после анализа требований. Свяжитесь с нами для получения точной оценки. Получите консультацию по реализации подписок в вашем проекте.

Мы имеем более 5 лет опыта в разработке подписочных решений для iOS и Android. Наши сертифицированные разработчики гарантируют соблюдение App Store Review Guidelines.

Почему нельзя предлагать introductory offer повторно?Apple проверяет eligibility на стороне сервера: если пользователь уже был подписчиком в данной subscription group, оффер не будет применён. Это защищает от злоупотреблений и отвечает требованиям App Store.

Монетизация мобильных приложений: 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 автоматически отменяет покупку и возвращает деньги. Средняя стоимость такой ошибки — потеря $0.3–0.8 на пользователя в месяц (по данным наших проектов).

Рекламная медиация: повышение 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 может превышать $20. При 100 000 показов rewarded видео в день переход с waterfall на In-App Bidding может приносить дополнительно $50-100 ежедневно.

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

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

Сеть Тип рекламы CPM (США, rewarded) Особенность
AdMob banner, interstitial, rewarded $10–18 Широкая сеть, easy start
MAX (AppLovin) rewarded, interstitial $15–25 In-App Bidding, выше fill rate
ironSource rewarded video $12–20 Лучше для игр
Mintegral rewarded, native $8–14 Азия, программатик

Как мы внедряем монетизацию: пошаговый процесс

  1. Аудит текущей модели — анализ воронки, paywall, ценовых тиров и выявление узких мест.
  2. Проектирование модели — выбор типа (subscription, consumable, non-consumable) и оптимизация ценовых точек.
  3. Интеграция IAP — настройка StoreKit 2 / Google Billing 6, receip-валидация, 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 на старте — пользователь удаляет. Слишком щедрый бесплатный тир — нет стимула платить.

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

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

Чек-лист типичных ошибок при монетизации
  • Отсутствие обработки unfinished transactions — потери дохода 5-10%.
  • Нет идемпотентности на сервере при обработке consumable — двойные начисления.
  • Забыли вызвать acknowledgePurchase() на Android — отмена покупки через 3 дня.
  • Не обработаны события REFUND и DID_RENEW — некорректный статус подписки у пользователя.
  • Paywall без A/B тестов — оставляют 20-40% потенциала монетизации.
  • Реклама только через один источник (например, AdMob без медиации) — CPM ниже на 15-30%.

Объём работ по монетизации

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

Сроки ориентировочно

Этап Длительность
Базовая IAP (один store) 1–2 недели
Подписочная система + RevenueCat + paywall 3–5 недель
Рекламная медиация (MAX + 3 сети) 1–2 недели
Полный цикл (IAP + реклама + аналитика) 4–8 недель

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

Источники: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.