Всем привет, меня зовут Виталий, я основатель Adapty. Подписки один из способов монетизировать приложение. С их помощью вы можете дать пользователю возможность получить постоянный доступ к обновляемому контенту в приложении или же к предоставляемому сервису. В отличие от обычных покупок, где Apple берет себе 30% комиссию, на подписках эта комиссия сокращена до 15% в случае, если пользователь подписан в течение 1 года и более.Важныймомент: если пользователь отменит подписку, то данный счетчик сбросится через 60 дней.

В этой части мы научимся:

• Создавать покупки в App Store Connect
• Конфигурировать подписки указывать длительность, стоимость, пробные периоды
• Получать список покупок в приложении

Создание покупок

Перед тем, как начать внедрять покупки внутри приложения необходимо:

• Оплатить Apple Developer аккаунт как физическое лицо или организация.
• Приняты все соглашения в App Store Connect. Обновленные соглашения будут появляться сверху в личном кабинете App Store Connect, их легко заметить.

Предположим, что в нашем приложении будет два вида подписок: месячная и годовая. У каждой из них мы сделаем пробный период длиной в 7 дней.

На странице нашего приложения в App Store Connect открываем вкладку In-App Purchases Manage. На этой вкладке отображается список созданных нами покупок. Для того, чтобы создать новую покупку, необходимо нажать на кнопку(+),которая находится около заголовка In-App Purchases.

Интерфейс создания покупок

Далее мы попадаем в диалог создания покупки. Наш выбор Auto-Renewable Subscription.

Выбираем 3 пункт

Следующим шагом нам будет предложено создать группу подписок(SubscriptionGroup). Группа подписок это множество подписок с главным свойством, что пользователь не может активировать две подписки одновременно из одной группы. Дополнительно, все introductory offers такие как триал применяются ко всей группе сразу. Группы нужны для того, чтобы отделять бизнес логику внутри приложения.

Назовем нашу группу Premium Access. При добавление следующей подписки интерфейс предложит добавить ее в уже существующую группу. Позже вы можете управлять группами в меню In-App Purchases Subscription Groups

Создание Группы подписок

Далее конфигурируем название подписки

• Reference Name то, как будет отображаться подписка в App Store Connect, а также в разделе Sales и в отчетах
• Product ID уникальныйидентификатор продукта, который используется в коде приложения

Рекомендую выбирать читаемое название для Product ID, из которого можно почерпнуть максимальное количество информации. Хорошей практикой является указание длины подписки, так меньше запутаетесь потом в аналитике.

Добавим второй продукт точно так же, в итоге наш интерфейс вкладки In-App Purchases Manage будет выглядеть следующим образом:

Две подписки в приложении

Конфигурация подписок

Покупки добавили, но пока они не готовы к использованию: Status выше имеет значение Missing Metadata. Это означает, что мы пока не добавили информацию по цене и периоду подписки. Сейчас мы это исправим.

Длительность и цены

Кликаем на продукт и конфигурируем его.

Здесь нам необходимо выбрать период(SubscriptionDuration). В нашем случае, выбираем 1 Month или 1 Year. После чего переходим в меню конфигурации цен. Можно гибко настраивать цены в зависимости от стран, но мы ограничимся автоматическими ценами, выбрав только цену в USD. App Store Connect автоматически переведет цены в другую валюту, не всегда ясно, как это происходит. Скорее всего для ваших целевых рынков вы захотите поменять цену руками.

Бесплатный пробный период (free trial)

Одним из популярных способов повышения конверсии в подписку является бесплатный пробный период: пользователь активирует его, пользуется бесплатно приложением. Если не отменяет подписку, то после окончания периода с него списываются деньги. Разработчики любят бесплатный период, потому что он хорошо работает. Посмотрим, как его включить.

Чтобы зайти в нужное нам меню, нажмите на кнопку(+)рядом с заголовком и выберите пунктCreate Introductory Offerиз выпадающего списка:

Выбираем список стран

Выбираем длительность оффера. Можно поставить No End Date, если не хотите себя ограничивать.

Последний этап выбор типа оффера. Как видно на следующем скриншоте, существует три типа:

• Pay as you go использование со скидкой: пользователь платит сниженную цену в течение нескольких начальных периодов, а после становится обычным подписчиком со стандартными ценами.
• Pay up front предоплата за использование приложения: пользователь сразу платит некоторую стоимость и получает возможность использовать приложение в течение определенного времени, а затем, также становится обычным подписчиком.
• Free бесплатный пробный период, по истечение которого пользователь может стать подписчиком.

Нас интересует третий вариант, а продолжительность(Duration)устанавливаем на 1 неделю.

Сохраняем настройки.

Получение списка SKProduct

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

Хорошим правилом является создание класса-синглтона для работы со StoreKit. Такой класс имеет только один инстанс во всем приложении. МножествоproductIdentifiersбудет хранить в себе идентификаторы наших покупок:

import StoreKitclass Purchases: NSObject {    static let `default` = Purchases()    private let productIdentifiers = Set<String>(        arrayLiteral: "barcode_month_subscription", "barcode_year_subscription"    )    private var productRequest: SKProductsRequest?    func initialize() {        requestProducts()    }    private func requestProducts() {        // Will implement later    }}

Только идентификаторов недостаточно, чтобы полноценно пользоваться покупками необходимо получить: стоимость, валюту, локализацию, скидки. Возвращает всю эту и дальше большую информацию класс SKProduct. Чтобы получить эту информацию, нам необходимо сделать запрос к Apple. Создадим объектSKProductsRequest, назначим емуdelegate вметодыdelegateбудет приходить результат запроса. Вызываем методstart(), который инициализирует асинхронную процедуру:

private func requestProducts() {        productRequest?.cancel()        let productRequest = SKProductsRequest(productIdentifiers: productIdentifiers)        productRequest.delegate = self        productRequest.start()        self.productRequest = productRequest}

Если операция пройдет успешно, будет вызван методproductsRequest(didReceive response:), в котором и будет содержаться вся необходимая нам информация:

extension Purchases: SKProductsRequestDelegate {    func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) {        guard !response.products.isEmpty else {            print("Found 0 products")            return        }        for product in response.products {            print("Found product: \(product.productIdentifier)")        }    }    func request(_ request: SKRequest, didFailWithError error: Error) {        print("Failed to load products with error:\n \(error)")    }}

Если все прошло успешно, то в результате в лог будет выведены две строчки:

Found product: barcode_month_subscriptionFound product: barcode_year_subscription

При этом, если будет ошибка, то SKProduct с таким ID не вернется. Такое может быть, если продукт по какой то причине стал не валидный.

Ну вот и все, очередной забор за нашей спиной.

Спасибо Алексею Гончарову x401om за подготовку статьи. В следующей статье мы разберемся, как проводить покупки внутри приложения: открывать/закрывать транзакции, обрабатывать ошибки, валидировать receipt и другое.

На сегодняшний день около 80% мобильных приложений работают по подписочной системе. Благодаря этому мы имеем сотни разных подходов к тому как и когда показать пользователю экран с предложением подписки, как мотивировать пользователя на покупку, чем лучше завлечь пользователя.

При встраивании подписок, иногда упускаются важные вопросы:

• как и где хранить id для предлагаемых продуктов?
• как часто планируется итерация по новым продуктам?
• на каком этапе работы приложения стоит запрашивать продукт? На запуске или перед показом экрана
• есть ли время на встраивание сложной системы для работы с продуктами или необходим быстрый запуск?

В отличие от огромного количества UX-подходов для работы с подписками, техническое решение имеет всего два пути развития:

1. Мы переносим всю работу на сервер
2. Вся логика работы с продуктами остается на клиенте

У каждого подхода есть плюсы и минусы, далее мы рассмотрим следующие вопросы:

1. Хранение id продуктов: клиент или сервер?
2. В какой момент работы приложения стоит запросить продукты?
3. Кэшировать или не кешировать продукты?
4. Аналитика покупок: и снова клиент или сервер?

Итак, погнали!

Хранение id продукта

Как только вы задумаетесь о встраивании подписки или иной любой внутренней покупки в приложение, на сцену выходит id продукта небольшая сущность, обычно в виде строки, которой вы будете оперировать на протяжении всего процесса работы с подписками.

И появляется головная боль, как и где хранить этот самый id: захардкодить на устройстве или получать с сервера.

При хранении на клиенте вам не нужно задумываться о контрактах работы с бекендом или поиском SaaS решения, если в вашем проекте отсутствует надобность в сервере. Вы просто сохраняете массив нужных вам id продуктов внутри приложения, запрашиваете их и показываете. В целом вы даже можете довольно быстро итерироваться по разным подпискам, просто обновляя приложение в store.

Но что если нам хочется чего-то большего? Что если нам хочется AB-тестов, что если мы хотим взять и при помощи парочки кнопок заменить во всем приложении старый продукт на новый? А, ну и, конечно, у нас при этом достаточно свободного времени. Тут на сцену и выходит сервер.

В случае серверного хранения id продуктов на длинной дистанции ограничения различных подходов заключаются только в возможностях нашей фантазии, ну и, конечно, умениями разработчиков в команде. Однако c большими возможностями приходит и большая ответственность. Поскольку в таком случае клиенту и серверу стоит заранее продумать контракт по-которому они будут взаимодействовать. В минимальном виде необходимо учитывать такие вещи как:

1. Как клиент будет понимать к какому виду продуктов относится данный id
2. Как различать на экране покупки какие продукты где показывать

Также стоит всегда иметь массив id продуктов на случай если сервер, вдруг, неожиданно "отвалится". Поскольку в ином случае есть шанс упустить пользователей, которые могут с удовольствием заплатить за ваш продукт, но просто не иметь такой возможности из-за технических неполадок.

Запрос продуктов и кэширование

Когда запрашивать продукты? Это второй вопрос, о котором всегда стоит задуматься перед началом встраивания подписок в наше приложение. Поскольку чем раньше мы загрузим продукты, тем раньше мы сможем предложить пользователю купить нашу подписку. И в случае с клиентским хранением все обычно однозначно: запросили, сохранили, показали.

То в случае, когда мы работаем с сервером появляется разветвление. Потому что мы можем иметь желание показать пользователю только самое актуальное предложение: менеджер мог обновить новые подписки в тот момент, когда пользователь зашел в приложение и в итоге увидит старое предложение. При таком подходе стоит отложить запрос до момента захода пользователя на экран или запрашивать продукты в фоне раз в n-времени, но если пользователь уже зашел на экран, то стоит показать то, что уже было закешировано, чтобы избежать ожидания пользователя.

Сконцентрируемся немного на процессе запроса id продуктов с сервера и самих продуктов уже от Apple.

На данной диаграмме изображен процесс получения id продуктов с учетом возможности, что сервер может отвалиться, в таком случае мы всегда имеем список запасных id продуктов для загрузки. Если сервер возвращает ошибку, то чтобы не запрашивать бесконечно id, мы можем выставить лимит на попытки и, при достижении лимита, запросить продукты из локального стора. Но можно пойти "хитрым путем" и, запросив запасные продукты, продолжить стучаться на сервер раз в n-времени, и если id все же будут получены, то в таком случае можно по ним запросить актуальные продукты и подменить их кэше во время работы с приложением.

Однако стоит учитывать, что при таком подходе появляется промежуточный результат, при котором любой A/B тест способен сломаться. Представим ситуацию: пользователь заходит на экран покупки и видит продукты, загруженные из запасного списка. Затем пользователь выходит с экрана и продолжает пользоваться приложением. За это время загружаются актуальные продукты и снова показываются пользователю, и в этот раз пользователь совершает покупку. В такой ситуации перед бизнесом появляется вопрос, на который есть множество ответов, среди которых придется долго искать истину:Что мотивировало купить пользователя совершить покупку в этот раз?

Данный вопрос можно разрешить следующим образом

Данный подход позволяет положить внутри приложения информацию об ошибке и, отталкиваясь от, например, дополнительного флага от сервера, решать, нужно ли перезапрашивать актуальные продукты или нет. В данной ситуации бизнес имеет большее поле для маневров и, например, может отделить группу пользователей и посмотреть, как они будут реагировать на изменение продуктов, анализируя их поведение.

Итог

Встраивание покупок само по себе несложное действие, но стоит задуматься о том, как в дальнейшем будет развиваться ваш проект и продукт. Задайте себе вопросы:

• Я планирую делать большой продукт или маленький пет-проект?
• Как в дальнейшем я планирую развивать подписки?
• У меня есть время на разработку сложного решения?

Эти три вопроса помогут вам понять какие шаги для проектирования стоит сделать и куда смотреть дальше. Также если вы небольшой проект, но вам необходимо иметь серверную логику, то всегда лучше взглянуть на готовые решения и BaaS, которые уже прошли основную боль и сэкономят вам кучу времени.