Сегодня около 80% мобильных приложений работают по системе подписки.
Благодаря этому у нас есть сотни различных подходов к тому, как и когда показать пользователю экран с предложением подписки, как мотивировать пользователя к покупке, чем лучше заманить пользователя.
При встраивании подписок иногда упускаются важные моменты:
- как и где хранить идентификаторы предлагаемых продуктов?
- Как часто планируется внедрять новые продукты?
- На каком этапе подачи заявки следует запросить товар? При запуске или перед демонстрацией экрана
- У вас есть время на встраивание сложной системы работы с продуктами или вам нужен быстрый запуск?
- Переносим всю работу на сервер
- Вся логика работы с продуктами остается на клиенте
- Хранение идентификаторов продуктов: клиент или сервер?
- На каком этапе приложения следует запрашивать продукты?
- Кэшировать или не кэшировать товары?
- Аналитика покупок: снова клиент или сервер?
Сохранение идентификатора продукта
Как только вы задумываетесь о встраивании в приложение подписки или любой другой встроенной покупки, на сцену выходит идентификатор продукта — небольшая сущность, обычно в виде строки, которой вы будете оперировать на протяжении всего процесса работы.с подписками.
И возникает головная боль, как и где хранить этот самый id: жестко закодировать его на устройстве или получить с сервера.
При хранении на клиенте вам не нужно думать о контрактах на работу с бэкендом или поиске SaaS-решения, если ваш проект не требует сервера.
Вы просто сохраняете массив идентификаторов нужных вам продуктов внутри приложения, запрашиваете их и отображаете.
В общем, вы даже можете довольно быстро переключаться между разными подписками, просто обновляя приложение в магазине.
Но что, если мы хотим чего-то большего? А что если мы захотим AB-тесты, что если мы захотим взять пару кнопок и заменить старый продукт на новый во всем приложении? И, конечно, у нас достаточно свободного времени.
Здесь на сцену выходит сервер.
В случае серверного хранения идентификаторов продуктов на большом расстоянии ограничения различных подходов заключаются лишь в возможностях нашего воображения и, конечно, в навыках разработчиков в команде.
Однако с большими возможностями приходит и большая ответственность.
Потому что в этом случае клиент и сервер должны заранее подумать о контракте, в котором они будут взаимодействовать.
Как минимум, необходимо учитывать такие вещи, как:
- Как клиент поймет, к какому типу товара относится этот идентификатор?
- Как отличить на экране покупки какие товары где показаны
Потому что в противном случае есть шанс упустить пользователей, которые, возможно, и рады заплатить за ваш продукт, но просто не имеют такой возможности из-за технических проблем.
| Возможность быстрой интеграции | Гибкость системы к изменениям | Скорость интеграции | |
|---|---|---|---|
| Клиент | * | ** | *** |
| Сервер | ** | *** | * |
Запрос продукта и кеширование
Когда мне следует запрашивать продукцию? Это второй вопрос, над которым всегда стоит задуматься, прежде чем мы начнем встраивать подписки в наше приложение.Потому что чем раньше мы загрузим продукты, тем быстрее сможем предложить пользователю купить нашу подписку.
А в случае с клиентским хранилищем обычно всё понятно: запросил, сохранил, показал.
Тогда в случае, когда мы работаем с сервером, появляется ветка.
Потому что мы можем захотеть показать пользователю только самое актуальное предложение: менеджер может обновлять новые подписки в тот момент, когда пользователь заходит в приложение и видит старое предложение.
При таком подходе стоит отложить запрос до тех пор, пока пользователь не войдет на экран или не запрашивать продукты в фоновом режиме один раз каждый n-раз, но если пользователь уже зашел на экран, то стоит показать то, что уже закешировано, чтобы избежать ждем пользователя.
Давайте немного сосредоточимся на процессе запроса идентификаторов продуктов с сервера и самих продуктов у Apple. 
На этой схеме показан процесс получения идентификаторов товаров с учетом возможности выхода из строя сервера, в этом случае у нас всегда есть список запасных идентификаторов товаров для скачивания.
Если сервер возвращает ошибку, то чтобы не запрашивать id бесконечно, мы можем установить лимит на попытки и при достижении лимита запрашивать товары из локального магазина.
Но можно пойти «хитрым путем» и, запросив запасные товары, продолжать стучать на сервер раз в n раз, и если id все равно будут получены, то в этом случае по ним можно запросить текущие товары и заменить их.
их в кэше во время работы с приложением.
Однако стоит учитывать, что при таком подходе появляется промежуточный результат, при котором любой A/B-тест может сломаться.
Представим ситуацию: пользователь заходит на экран покупки и видит товары, загруженные из запасного списка.
Затем пользователь выходит из экрана и продолжает использовать приложение.
За это время актуальные товары снова загружаются и показываются пользователю, и на этот раз пользователь совершает покупку.
В такой ситуации перед бизнесом встает вопрос, на который есть множество ответов, среди которых придется долго искать истину: Что побудило пользователя совершить покупку на этот раз? Эту проблему можно решить следующим образом 
Такой подход позволяет поместить информацию об ошибках внутрь приложения и на основе, например, дополнительного флага от сервера принять решение о необходимости повторного запроса текущих продуктов или нет. В такой ситуации у бизнеса появляется больше возможностей для маневра и, например, можно выделить группу пользователей и посмотреть, как они отреагируют на изменения в продуктах, проанализировав их поведение.
Нижняя граница
Встраивание покупок само по себе — простое действие, но стоит подумать о том, как ваш проект и продукт будут развиваться в дальнейшем.Задайте себе вопросы:
- Планирую ли я создать большой продукт или небольшой любимый проект?
- Как я планирую развивать подписки в будущем?
- Есть ли у меня время на разработку комплексного решения?
Также, если у вас небольшой проект, но вам нужна серверная логика, то всегда лучше присмотреться к готовым решениям и BaaS, которые уже прошли через основную боль и сэкономят вам массу времени.
.
О Адаптации
Если вы разрабатываете мобильное приложение, то понимаете, что реализация встроенных покупок требует огромного ресурса разработки.Адаптивность значительно упрощает работу по добавлению покупок:
- Встроенная аналитика позволяет быстро понять основные метрики приложения.
- Когортный анализ отвечает на вопрос: как быстро сходится экономика.
- A/B-тесты увеличивают доход приложения.
- Интеграция с внешними системами позволяет отправлять транзакции в службы атрибуции и продуктовой аналитики.
- Рекламные кампании уменьшить отток аудитории.
- SDK с открытым исходным кодом позволяет интегрировать подписки в приложение за несколько часов.
- Серверная проверка и API для работы с другими платформами.
Теги: #iOS #разработка iOS #разработка ios #Swift #подписки покупка в приложении #adapty
-
Планшет Android – Растущая Популярность
19 Oct, 24 -
«Мы Облажаемся, И В Этом Виноваты Клиенты»
19 Oct, 24 -
Идеальный Бэклог Продукта
19 Oct, 24 -
Века. Инструкции По Использованию
19 Oct, 24 -
Жизнь Скрывается В Темной Материи?
19 Oct, 24 -
Концепция Группировки Типов В C++
19 Oct, 24 -
Playstation 3 Придется Подешеветь На $50-100
19 Oct, 24 -
Хабр Хочет Пригласить Вас В Блог =)
19 Oct, 24
