Как быстро запустить мобильное приложение для веб-сервиса: опыт Авиасейлс для бизнеса
Привет! Меня зовут Иван Бойцов, я руковожу сервисом для организации командировок Авиасейлс для бизнеса. Недавно мы запустили MVP-версию мобильного приложения, чтобы проверить, нужно ли оно нам, и если да, — в каком виде. Собрали его быстро и с минимальными затратами. Расскажу, как всё прошло. Этот опыт будет полезен тем, кто уже имеет работающий веб-сервис, но не уверен в необходимости мобильного приложения или не решается его делать.
Предыстория
Мы начали разрабатывать сервис для организации командировок в Авиасейлс за полгода до пандемии. Исследования показали, что большая часть российских компаний оформляет командировки с рабочих компьютеров. Запроса на мобильное приложение не было, поэтому мы разработали только веб-версию.
Первая версия продукта была готова в самый разгар пандемии, спрос на командировки тогда упал и вопрос о необходимости запуска мобильного приложения отложился на пару лет. Кстати, если вам интересно, каково это запускать тревел-сервис, когда все сидят дома, — в 2020 году я рассказывал об этом на Product Camp.
Хотя гибрид и удалёнка вошли в привычку за время пандемии, когда она закончилась, спрос на мобильность и командировки начал расти. К этому моменту вырос и наш продукт — появились новые услуги, сложная логика по управлению сотрудниками и разграничению доступов, тревел-политики и многое другое. Решиться на запуск разработки мобильного приложения с нуля тогда было непросто. Мы начали с выстраивания гипотез и их проверки.
Формулируем гипотезы
Прежде всего, мы хотели узнать, теряем ли мы часть аудитории из-за отсутствия приложения.
Вдобавок решили рассмотреть такие гипотезы:
Мобильное приложение не должно дублировать все функции веб-версии.
Мы предположили, что в мобильной версии нужно сосредоточиться на простых функциональностях, например, на сценариях согласования командировок и управления поездками. Эти действия можно делать на бегу.Приложение станет точкой входа для новых пользователей.
ASO может принести новых юзеров, а маркетинг — привлекать инсталлы вместо посадки трафика на лендинги.Бесшовный переход из B2C приложения в B2B поможет привлечь новых клиентов с минимальными затратами.
Похожая механика есть на веб-версии. Когда пользователь выбирает авиабилет, ему предлагается перейти в Авиасейлс для бизнеса и оформить покупку от имени юрлица.
Проверить гипотезы можно исследованиями или экспериментами. Мы провели ряд кастдевов и опросов по основной гипотезе и узнали, что в целом наличие мобильного приложения влияет на решение об использовании сервиса. Хотя однозначных выводов на ограниченной выборке респондентов мы не получили.
Мы решили запускать MVP-версию приложения, чтобы собрать фактическую информацию о поведении пользователей.
Выбираем, как сделать MVP-версию
Наши вводные:
Есть полноценная рабочая мобильная веб-версия;
Нет команды разработки;
Нужно собрать много данных для аналитики;
Делать плохо нельзя.
Писать полноценные нативные приложения для обеих платформ — долго и дорого. Быстро «пересобрать» фронтенд в мобильное приложение на React Native не получится с текущей кодовой базой.
Если начинаете делать веб-сервис, сразу закладывайте в архитектуру фронтенда, что в будущем может появиться приложение на React Native.
Решили, что приложение должно открывать наш текущий веб в WebView. Для оборачивания веба в мобильное приложение существуют готовые решения. Мы попробовали Median, но его функциональные возможности очень ограничены. Поэтому взялись писать приложение самостоятельно. Основную часть — в WebView, а всё, что можно сделать быстро, — нативно. Писали на Flutter — из всех кросс-платформенных решений это наиболее простой и удобный фреймворк. Большую часть разработки делегировали ChatGPT, потому что никто в команде до этого не работал с Flutter.
ChatGPT отлично справляется с задачей вёрстки на Flutter по скриншоту фигмы.
Что получилось
На запуск первой версии потребовалась пара недель. Она выглядела так:
Онбординг — мини-лендинг внутри приложения. Он помогает проверить гипотезу о том, что приложение может быть самостоятельной точкой входа в продукт.
Авторизация — нативная, с сохранением сессии и входом через биометрию.
Основные экраны с нижней навигацией:
Панель — WebView открывающий наш мобильный веб;
Поддержка — нативный модуль онлайн-чата;
Загрузки — сюда попадают скачанные файлы: билеты, ваучеры, страховки и т.д. Их можно открыть и посмотреть даже если у пользователя нет интернета (например, в самолёте).
Аналитика — собираем события самого приложения и обогащаем события, собираемые с веб-версии. Дополнительно подключили AppsFlyer.
В процессе разработки не было технических сложностей или особенностей. Самой непростой задачей оказалась правильная сборка, подпись и публикация приложения в сторах.
Внешний вид приложения Авиасейлс для бизнеса
Модерация в сторах
Перед публикацией приложения изучили правила сторов. Google Play формулирует их довольно однозначно:
At a minimum, apps should provide users with a basic degree of functionality and a respectful user experience.
При этом Apple в разделе Minimum Functionality делают акцент на том, что приложение не должно быть просто «переупакованной веб-версией»:
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or «app-like,» it doesn«t belong on the App Store.
Поэтому понадобился дополнительный рисёрч. Разобраться помогла статья сервиса Median Will Apple approve my webview app?. Основная идея — при соблюдении двух следующих критериев всё будет хорошо:
Во-первых, при использовании приложения у пользователей не должно быть ощущения, что они просто открыли мобильный сайт;
Во-вторых, приложение должно иметь дополнительные функциональности. Нативной авторизации, поддержки и раздела с загрузками нам оказалось достаточно.
В итоге, модерацию прошли успешно в обоих магазинах приложений, без проблем и замечаний.
Результаты
После запуска мы сделали рассылку по текущим клиентам и в первый день получили больше 500 инсталлов. Спустя месяц после запуска DAU держался в районе 200, без дополнительного продвижения. Этого было достаточно для сбора аналитики.
График DAU мобильного приложения, красное — iOS, синее — Android
Мы получили много данных, например, узнали:
кто из пользователей запускает приложение (в сервисе есть разные роли — сотрудник, руководитель, администратор, бухгалтер);
какая доля заказов делается в приложении, а какая — в веб-версии (по клиентам с приложением);
сценарии использования приложения по ролям;
распределение по платформам.
А ещё мы провели кастдевы с теми, кто регулярно пользуется приложением, и собрали информацию на их свежем опыте, а не из гипотетических сценариев. Это помогло получить ответы на наши гипотезы и собрать информацию для формирования стратегии полноценного запуска на мобильных устройствах.
Дальше мы провели серию экспериментов: разместили ссылку на приложение на посадочных страницах, занялись ASO, покупали рекламу и так далее.
Выводы
Гипотеза о том, что приложение — важный фактор при выборе сервиса для организации командировок, подтвердилась на цифрах.
Конверсия в первый заказ у тех, кто ставит себе приложение, значительно выше, а дальнейший отток — ниже.Гипотеза об ограниченных сценариях не подтвердилась.
Мы видели основной целевой аудиторией тех, кто оформляет билеты себе или согласует поездки подчинённых. Оказалось, эти действия не делаются на бегу, а выполняются в рабочее время и с компьютера. А наши настоящие пользователи — те, кто отвечает за командировки в компании. Приложение они открывают в нерабочее время, если приходит срочная задача: организовать поездку в последний момент, поменять/вернуть билеты, решить проблему с отелем или авиакомпанией и так далее. Эти задачи охватывают практически все части интерфейсов продукта.Гипотеза про мобильное приложение как точка входа подтвердилась.
Реклама приложения даёт примерно такую же стоимость и конверсию в клик, как обычные посадочные страницы. Мы получаем органический трафик из сторов. Конверсии в регистрацию хуже десктопных, но они всё равно высокие, учитывая простоту онбординга и открытие формы регистрации в браузере. Есть простор для экспериментов и улучшений.Гипотезу про переход из B2C приложения проверить не удалось.
Она оказалась сложной в технической реализации. Не все гипотезы можно проверить дешёвым способом и об этом нужно помнить, когда планируется эксперимент.
Что ещё узнали интересного:
доля iOS составляет 80–85%. Это знание даёт нам возможность в будущем сфокусироваться на одной платформе и сэкономить на ресурсах;
идентичность интерфейсов между мобильным приложением и мобильным вебом не вызывает особых замечаний, и мало кто в принципе обращает на это внимание;
многие наши пользователи узнавали о наличии приложения и устанавливали его поиском по названию сервиса в сторах, без каких-либо дополнительных касаний.
