Сеть сайтов знакомств. Часть 11. Мобильные приложения

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

1. Все как у взрослых. Например, Facebook. Заводим десктопную версию сайта, мобильную, а так же нативные приложения для iOS и Android. Но минус такой архитектуры в очень сложном администрировании: помимо того, что необходимо администрировать десктопную и мобильную версию, необходимо еще и постоянно дорабатывать мобильные приложения.

2. Отказ от десктопной и мобильной версий, оставив только мобильные приложения. Такой подход тоже видится логическим в моем случае, так как в моих планах — 97% трафика с мобильных устройств и в этом случае нет смысла делать упор на десктопную версию. Более того, существует огромное количество проектов, у которых есть исключительно мобильные приложения. Но и такая идея мне показалась не самой лучшей: ведь в случае, если до релиза дойдет мобильное приложение, в котором пропустили серьезный баг, то пройдет несколько дней, пока будет выпущен апдейт (в случае с iOS, от релиза до обновления приложений в смартфонах пользователей, уходит в среднем 3-5 дней).

В итоге был выбран третий вариант.
В основе третьего варианта мы имеем десктопную версию сайта, мобильную, а в свою очередь приложения являются гибридными.
В основе гибридного мобильного приложения — привязка всей логики к мобильной версии сайта. По сути, приложение будет браузером для мобильной версии сайта, имея небольшое количество собственного функционала:
— получение идентификатора мобильного устройства;
— привязка конкретного мобильного устройства к конкретному аккаунту;
— определение геопозиции пользователя;
— push уведомления;
— метрика;
— баннеры;

Такая архитектура имеет ряд неоспоримых преимуществ перед нативными приложениями:
1. В случае, если будет пропущен баг, то мы всего лишь лишаемся не сильно критичного функционала (например, не сможем получать геопозицию), но при этом, пользователи смогут продолжать переписываться.
2. Нет необходимости постоянно выпускать апдейты. Нам нужно будет лишь раз в 2 недели выпускать новый билд (ибо App Store и Google Play любят постоянные апдейты и это дает плюс в ранжировании мобильного приложения). Для добавления новой функции, нам достаточно ее добавить в мобильной версии сайта и ее получат сразу все пользователи App Store и Google Play, без необходимости обновлять мобильное приложение.
3. Проще с администрированием проекта: в 99.9% случаев достаточно лишь услуг веб программиста, который вносит необходимые правки в мобильную версию сайта.
4. И конечно же, ниже сложность разработки (в случае с такси, одно только описание протокола API взаимодействия приложений с сервером, заняло свыше 20 страниц), меньшие сроки разработки (на разработку нативного мобильного приложения легко может уйти пол года, а гибридное, при наличии ТЗ, меньше месяца), а так же значительно, во много раз меньшая стоимость разработки, доработки и технической поддержки (качественные нативные приложения App Store + Google Play могут обойтись в ₽1М, плюс ежемесячно десятки тысяч на поддержку/доработки)


Еще один нюанс, который необходимо внедрить в мобильные приложения — систему мотивации пользователей сайта, чтобы они оставляли отзывы приложениям в Google Play и App Store. Необходимо будет проработать сценарии, при которых выводить пользователю окно запроса для оценки мобильного приложения именно в тот момент, когда он максимально лоялен.
Делать это буду как и все другие приложения: всплывает окно, с предложением оценить приложение. Здесь очень важно удачно подобрать момент, когда должно всплыть такое окно, то есть это должен быть момент, когда пользователь максимально лоялен к проекту и согласен оставить отзыв, а не закрыть окно.

Если пользователь поставил 1-3 звезды, то всплывает новое окно, с просьбой рассказать что не нравится. Вся эта информация будет автоматизированно собираться.
Если пользователь поставил 4-5 звезд, то новое окно, в котором информация о том, что пользователю подарен Premium статус на 2 недели и просьба нажать на кнопку, которая переведет его на страницу мобильного приложения, для размещения отзыва о нашем приложении. Ну и рядом кнопка крестика, которая закрывает окно.
— если пользователь получив Premium, закрыл окно, то такого помечаем как «редиску» и в будущем он не получит за бесплатно никаких плюшек.
— если пользователь перешел на страницу приложения, такого помечаем «звездочкой» и такому пользователю в будущем можем дать еще каких-нибудь плюшек.
Конечно, ряд пользователей перейдут на страницу приложения и не оставят отзыв. Этого мы не сможем узнать.
Некоторая часть пользователей оставят отзыв, но он через некоторое время исчезнет (Google Play любит удалять отзывы). Но к сожалению, здесь мы не можем ничего сделать, ибо нет механизмов, позволяющих точно отслеживать, оставил ли вообще, пользователь отзыв, либо перешел на страницу приложения и вернулся обратно в приложение.

Можно попробовать предложить, дать пользователю Premium в случае, если он перейдет по ссылке на страницу приложения, но это плохой вариант: политика App Store и Goole Play запрещает мотивацию пользователей за отзывы и если поймает, отправит в бан. А в описанном выше случае, мы ловим лояльного клиента, дарим ему заранее плюшки, что значительно повышает шанс того, что он перейдет на страницу приложения и оставит хороший отзыв.

Естественно, будет таргетирование и A-B тестирование (в котором будут задейстсованы сразу несколько сотен пользователей по каждому тестированию), какая категория пользователей более лояльна к проекту и охотнее оставляет отзывы и только эту аудиторию и будем просить оставлять отзывы. На основе полученных данных, какой-то категории пользователей будем дарить Premium на 7 дней, какой-то на 3 недели.
Какой-то категории Premium Silver, какой-то Premium Gold. Ведь наша задача дать минимум и получить максимум.


Полностью концепция мобильных приложений будет доработана ближе к концу месяца.

Отправить ответ

avatar
  Subscribe  
Уведомление