На сегодняшний день около 80% мобильных приложений работают по подписочной системе. Благодаря этому мы имеем сотни разных подходов к тому как и когда показать пользователю экран с предложением подписки, как мотивировать пользователя на покупку, чем лучше завлечь пользователя.
При встраивании подписок, иногда упускаются важные вопросы:
- как и где хранить id для предлагаемых продуктов?
- как часто планируется итерация по новым продуктам?
- на каком этапе работы приложения стоит запрашивать продукт? На запуске или перед показом экрана
- есть ли время на встраивание сложной системы для работы с продуктами или необходим быстрый запуск?
В отличие от огромного количества UX-подходов для работы с подписками, техническое решение имеет всего два пути развития:
- Мы переносим всю работу на сервер
- Вся логика работы с продуктами остается на клиенте
У каждого подхода есть плюсы и минусы, далее мы рассмотрим следующие вопросы:
- Хранение id продуктов: клиент или сервер?
- В какой момент работы приложения стоит запросить продукты?
- Кэшировать или не кешировать продукты?
- Аналитика покупок: и снова клиент или сервер?
Итак, погнали!
Хранение id продукта
Как только вы задумаетесь о встраивании подписки или иной любой внутренней покупки в приложение, на сцену выходит id продукта — небольшая сущность, обычно в виде строки, которой вы будете оперировать на протяжении всего процесса работы с подписками.
И появляется головная боль, как и где хранить этот самый id: захардкодить на устройстве или получать с сервера.
При хранении на клиенте вам не нужно задумываться о контрактах работы с бекендом или поиском SaaS решения, если в вашем проекте отсутствует надобность в сервере. Вы просто сохраняете массив нужных вам id продуктов внутри приложения, запрашиваете их и показываете. В целом вы даже можете довольно быстро итерироваться по разным подпискам, просто обновляя приложение в store.
Но что если нам хочется чего-то большего? Что если нам хочется AB-тестов, что если мы хотим взять и при помощи парочки кнопок заменить во всем приложении старый продукт на новый? А, ну и, конечно, у нас при этом достаточно свободного времени. Тут на сцену и выходит сервер.
В случае серверного хранения id продуктов на длинной дистанции ограничения различных подходов заключаются только в возможностях нашей фантазии, ну и, конечно, умениями разработчиков в команде. Однако c большими возможностями приходит и большая ответственность. Поскольку в таком случае клиенту и серверу стоит заранее продумать контракт по-которому они будут взаимодействовать. В минимальном виде необходимо учитывать такие вещи как:
- Как клиент будет понимать к какому виду продуктов относится данный id
- Как различать на экране покупки какие продукты где показывать
Также стоит всегда иметь массив id продуктов на случай если сервер, вдруг, неожиданно "отвалится". Поскольку в ином случае есть шанс упустить пользователей, которые могут с удовольствием заплатить за ваш продукт, но просто не иметь такой возможности из-за технических неполадок.
| Возможность быстрой интеграции | Гибкость системы к изменениям | Скорость интеграции | |
|---|---|---|---|
| Клиент | * | ** | *** |
| Сервер | ** | *** | * |
Запрос продуктов и кэширование
Когда запрашивать продукты? Это второй вопрос, о котором всегда стоит задуматься перед началом встраивания подписок в наше приложение. Поскольку чем раньше мы загрузим продукты, тем раньше мы сможем предложить пользователю купить нашу подписку. И в случае с клиентским хранением все обычно однозначно: запросили, сохранили, показали.
То в случае, когда мы работаем с сервером появляется разветвление. Потому что мы можем иметь желание показать пользователю только самое актуальное предложение: менеджер мог обновить новые подписки в тот момент, когда пользователь зашел в приложение и в итоге увидит старое предложение. При таком подходе стоит отложить запрос до момента захода пользователя на экран или запрашивать продукты в фоне раз в n-времени, но если пользователь уже зашел на экран, то стоит показать то, что уже было закешировано, чтобы избежать ожидания пользователя.
Сконцентрируемся немного на процессе запроса id продуктов с сервера и самих продуктов уже от Apple.
На данной диаграмме изображен процесс получения id продуктов с учетом возможности, что сервер может отвалиться, в таком случае мы всегда имеем список запасных id продуктов для загрузки. Если сервер возвращает ошибку, то чтобы не запрашивать бесконечно id, мы можем выставить лимит на попытки и, при достижении лимита, запросить продукты из локального стора. Но можно пойти "хитрым путем" и, запросив запасные продукты, продолжить стучаться на сервер раз в n-времени, и если id все же будут получены, то в таком случае можно по ним запросить актуальные продукты и подменить их кэше во время работы с приложением.
Однако стоит учитывать, что при таком подходе появляется промежуточный результат, при котором любой A/B тест способен сломаться. Представим ситуацию: пользователь заходит на экран покупки и видит продукты, загруженные из запасного списка. Затем пользователь выходит с экрана и продолжает пользоваться приложением. За это время загружаются актуальные продукты и снова показываются пользователю, и в этот раз пользователь совершает покупку. В такой ситуации перед бизнесом появляется вопрос, на который есть множество ответов, среди которых придется долго искать истину: Что мотивировало купить пользователя совершить покупку в этот раз?
Данный вопрос можно разрешить следующим образом
Данный подход позволяет положить внутри приложения информацию об ошибке и, отталкиваясь от, например, дополнительного флага от сервера, решать, нужно ли перезапрашивать актуальные продукты или нет. В данной ситуации бизнес имеет большее поле для маневров и, например, может отделить группу пользователей и посмотреть, как они будут реагировать на изменение продуктов, анализируя их поведение.
Итог
Встраивание покупок само по себе несложное действие, но стоит задуматься о том, как в дальнейшем будет развиваться ваш проект и продукт. Задайте себе вопросы:
- Я планирую делать большой продукт или маленький пет-проект?
- Как в дальнейшем я планирую развивать подписки?
- У меня есть время на разработку сложного решения?
Эти три вопроса помогут вам понять какие шаги для проектирования стоит сделать и куда смотреть дальше. Также если вы небольшой проект, но вам необходимо иметь серверную логику, то всегда лучше взглянуть на готовые решения и BaaS, которые уже прошли основную боль и сэкономят вам кучу времени.
Про Адапти
Если вы занимаетесь развитием мобильного приложения, то понимаете, что внедрение внутренних покупок требует огромного ресурса разработки.
Adapty сильно упрощает работу по добавлению покупок:
- Встроенная аналитика позволяет быстро понять основные метрики приложения.
- Когортный анализ отвечает на вопрос, как быстро сходится экономика.
- А/Б тесты увеличивают выручку приложения.
- Интеграции с внешними системами позволяют отправлять транзакции в сервисы атрибуции и продуктовой аналитики.
- Промо-кампании уменьшают отток аудитории.
- Open source SDK позволяет интегрировать подписки в приложение за несколько часов.
- Серверная валидация и API для работы с другими платформами.
Познакомьтесь подробнее с этими возможностями, чтобы быстрее внедрить подписки в своё приложение и улучшить конверсии.
