Привет! Меня зовут Иван Бойцов, я руковожу сервисом для организации командировок Авиасейлс для бизнеса. Недавно мы запустили MVP-версию мобильного приложения, чтобы проверить, нужно ли оно нам, и если да, — в каком виде. Собрали его быстро и с минимальными затратами. Расскажу, как всё прошло. Этот опыт будет полезен тем, кто уже имеет работающий веб-сервис, но не уверен в необходимости мобильного приложения или не решается его делать.

Предыстория

Мы начали разрабатывать сервис для организации командировок в Авиасейлс за полгода до пандемии. Исследования показали, что большая часть российских компаний оформляет командировки с рабочих компьютеров. Запроса на мобильное приложение не было, поэтому мы разработали только веб-версию.

Первая версия продукта была готова в самый разгар пандемии, спрос на командировки тогда упал и вопрос о необходимости запуска мобильного приложения отложился на пару лет. Кстати, если вам интересно, каково это запускать тревел-сервис, когда все сидят дома, — в 2020 году я рассказывал об этом на Product Camp.

Хотя гибрид и удалёнка вошли в привычку за время пандемии, когда она закончилась, спрос на мобильность и командировки начал расти. К этому моменту вырос и наш продукт — появились новые услуги, сложная логика по управлению сотрудниками и разграничению доступов, тревел-политики и многое другое. Решиться на запуск разработки мобильного приложения с нуля тогда было непросто. Мы начали с выстраивания гипотез и их проверки.

Формулируем гипотезы

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

Вдобавок решили рассмотреть такие гипотезы:

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

• Приложение станет точкой входа для новых пользователей. 
  ASO может принести новых юзеров, а маркетинг — привлекать инсталлы вместо посадки трафика на лендинги.

• Бесшовный переход из B2C приложения в B2B поможет привлечь новых клиентов с минимальными затратами. 
  Похожая механика есть на веб-версии. Когда пользователь выбирает авиабилет, ему предлагается перейти в Авиасейлс для бизнеса и оформить покупку от имени юрлица.

Проверить гипотезы можно исследованиями или экспериментами. Мы провели ряд кастдевов и опросов по основной гипотезе и узнали, что в целом наличие мобильного приложения влияет на решение об использовании сервиса. Хотя однозначных выводов на ограниченной выборке респондентов мы не получили.

Мы решили запускать MVP-версию приложения, чтобы собрать фактическую информацию о поведении пользователей.

Выбираем, как сделать MVP-версию

Наши вводные:

1. Есть полноценная рабочая мобильная веб-версия;

2. Нет команды разработки;

3. Нужно собрать много данных для аналитики;

4. Делать плохо нельзя.

Писать полноценные нативные приложения для обеих платформ — долго и дорого. Быстро «пересобрать» фронтенд в мобильное приложение на React Native не получится с текущей кодовой базой. 

Если начинаете делать веб-сервис, сразу закладывайте в архитектуру фронтенда, что в будущем может появиться приложение на React Native. 

Решили, что приложение должно открывать наш текущий веб в WebView. Для оборачивания веба в мобильное приложение существуют готовые решения. Мы попробовали Median, но его функциональные возможности очень ограничены. Поэтому взялись писать приложение самостоятельно. Основную часть — в WebView, а всё, что можно сделать быстро, — нативно. Писали на Flutter — из всех кросс-платформенных решений это наиболее простой и удобный фреймворк. Большую часть разработки делегировали ChatGPT, потому что никто в команде до этого не работал с Flutter.

Что получилось

На запуск первой версии потребовалась пара недель. Она выглядела так:

1. Онбординг — мини-лендинг внутри приложения. Он помогает проверить гипотезу о том, что приложение может быть самостоятельной точкой входа в продукт.

2. Авторизация — нативная, с сохранением сессии и входом через биометрию.

3. Основные экраны с нижней навигацией:

   1. Панель — WebView открывающий наш мобильный веб;

   2. Поддержка — нативный модуль онлайн-чата;

   3. Загрузки — сюда попадают скачанные файлы: билеты, ваучеры, страховки и т.д. Их можно открыть и посмотреть даже если у пользователя нет интернета (например, в самолёте).

4. Аналитика — собираем события самого приложения и обогащаем события, собираемые с веб-версии. Дополнительно подключили 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, без дополнительного продвижения. Этого было достаточно для сбора аналитики.

Мы получили много данных, например, узнали:

• кто из пользователей запускает приложение (в сервисе есть разные роли — сотрудник, руководитель, администратор, бухгалтер);

• какая доля заказов делается в приложении, а какая — в веб-версии (по клиентам с приложением);

• сценарии использования приложения по ролям;

• распределение по платформам.

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

Дальше мы провели серию экспериментов: разместили ссылку на приложение на посадочных страницах, занялись ASO, покупали рекламу и так далее.

Выводы

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

• Гипотеза об ограниченных сценариях не подтвердилась. 
  Мы видели основной целевой аудиторией тех, кто оформляет билеты себе или согласует поездки подчинённых. Оказалось, эти действия не делаются на бегу, а выполняются в рабочее время и с компьютера. А наши настоящие пользователи — те, кто отвечает за командировки в компании. Приложение они открывают в нерабочее время, если приходит срочная задача: организовать поездку в последний момент, поменять/вернуть билеты, решить проблему с отелем или авиакомпанией и так далее. Эти задачи охватывают практически все части интерфейсов продукта.

• Гипотеза про мобильное приложение как точка входа подтвердилась. 
  Реклама приложения даёт примерно такую же стоимость и конверсию в клик, как обычные посадочные страницы. Мы получаем органический трафик из сторов. Конверсии в регистрацию хуже десктопных, но они всё равно высокие, учитывая простоту онбординга и открытие формы регистрации в браузере. Есть простор для экспериментов и улучшений.

• Гипотезу про переход из B2C приложения проверить не удалось.
  Она оказалась сложной в технической реализации. Не все гипотезы можно проверить дешёвым способом и об этом нужно помнить, когда планируется эксперимент.

Что ещё узнали интересного:

• доля iOS составляет 80-85%. Это знание даёт нам возможность в будущем сфокусироваться на одной платформе и сэкономить на ресурсах;

• идентичность интерфейсов между мобильным приложением и мобильным вебом не вызывает особых замечаний, и мало кто в принципе обращает на это внимание;

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