Как запустить проект с сайтом и приложением
Денис Гордиенко, руководитель Bright Mobile, о проблемах, которые ждут руководителя бизнеса, когда идёт комплексная разработка ИТ-продукта, состоящего из сайта, приложения и интеграций со сторонними API.
Ozon, YouDo, Avito. Мы уже привыкли к тому, что у крупных сервисов есть и сайт, и приложение. Причём, сделанное практически полнофункционально: что есть на сайте, то дублируется и в приложение. Во второй половине 2019 года, вижу и в заказной разработке подобный тренд. Основатели все чаще приходят не только за приложением, а за целой системой: чтобы был сайт, приложение, и всем этим можно было управлять из единой панели (в одном из сервисов предполагалось аж 4 роли админа). Сегодня и пойдёт речь о нюансах в разработке таких проектов.
Но как показывает практика, для первой версии делать единый функционал и в вебе и в приложениях - это слишком затратно. Внутреннее API и сайт будут стоить примерно в два раза дороже приложения. Сомнительная выгода при двукратном увеличении чека.
Ранее мы запускали проекты на webview-движке Сервис ПИ (модуль к 1С-Битрикс). Там говорить о полном функционале было легко - по факту менялся только адаптивный шаблон. В начале этого года перевели разработку на Ionic.Framework, а ядро переписали с нуля, получив RTPlatform. Хоть движок стал работать быстрее/круче/веселее, но фишка с функционалом сразу и на сайте, и в приложении пропала - нужно как минимум делать отдельный шаблон, а как максимум переделывать экран с нуля, оставляя только API.
Появилась глобальная задача оставить на сайте самое важное для пользователя и проекта, когда человек находится стационарно, а в приложение вынести функции, необходимые в момент времени, к которым нужно иметь доступ оперативно.
Опросив 10 основателей, за месяц понял, что некоторые вещи, конечно, зависят от специфики бизнеса, но 80% - это общие правила для всех.
Что важно на сайте
Внешний вид
Пользователям важно, чтоб сайт был красивым. В отличие от приложений, где размер экрана не оставляет места для искушённых иллюстраций, а для пользователя на первом месте удобство и скорость, у сайтов вёрстка в стиле "голый бутстрап" редко адекватно воспринимается. При этом, в приложениях, "голый ionic" не нравится 20%, нормально воспринимается 70%, ещё 10% от него в восторге. Как говорится, невероятно, но факт. В итоге, основателю приходится заказывать индивидуальный дизайн для сайта, а в бюджетных вариантах купить шаблон и потратиться на его адаптацию.
SEO
SEO - это главное преимущество сайтов перед приложениями, поэтому, принебрегать его использованием не стоит. SEO продвижение на порядок дешевле, чем контекстная и прочая cpp реклама, где нужно платить за клики, показы, переходы. Для этого применяются разделы Новостей, Блога или Статей.
Круто будет применить UGC для снятия барьера между пользователем и сервисом. В случае маркетплейса услуг, например, это контент от самих специалистов, которые оказывают услуги.
Личный кабинет
Этот раздел у меня под вопросом, потому что сильно зависит от специфики проекта. Если пользователь что-то покупает или заказывает на сайте и ему нужно отслеживать заказ, иметь возможность написать исполнителю и т.п., то раздел нужен. Если это не принципиально, то нет. Наглядный пример - такси. Вы заказываете мотор с приложения или с сайта? У Яндекса, например, есть и то, и другое, а запуская новый агрегатор делать заказ с сайта было бы излишней тратой денег.
В некоторых случаях можно ограничится лендингом с формой захвата, чтобы пользователь мог просто оставить заявку, а она по API улетела в приложение мастеру или в админку оператору на проверку.
Что важно в приложении
В приложении важна оперативность передачи или получения данных. Для сравнения, у вебщиков загрузка страницы в 5 сек считается нормой, а для крупных проектов даже хорошим результатом, а для мобильщиков, если экран грузится больше 2-х сек, то уже зашквар. С учётом того, что единый функционал в приложении стоит дороже сайта, то приложение используется в проектах, где нужно оперативно выцеплять пользователя (push) или точно работать с его локацией (gps).
Push
Если говорить про маркетплейсы услуг, то чаще приложениями пользуются исполнители, а не заказчики. Исполнителям нужно видеть новые заявки как можно быстрее, с момента появления - от этого зависит заработают они или нет.
Как технически реализовывать “отклик” - это другой вопрос. Это может быть мессенджер, возможность оставить свое предложение под заявкой на бирже заданий, можно реализовать по принципу “ кто первый отклинулся - того и заявка” или сделать автоматическое назначение заявки исполнителю, как это делают в такси.
GPS
Актуально, примерно в 70% случаях. Если основная идея продукта в том, чтобы найти или трекать ближайшего кого-то или что-то, то это всё выносится в приложение. На вскидку, в этом году запускали вот такие идеи, где GPS был, как кровь из носу:
- Кешбек-сервис с поиском ближайшего заведения
- Биржа предложений от поваров, с отметками, где они находится
- Сервис поиска пропавших родственников
- Сервис аренды недвижимости
- Сервис поиска парковочного места
Маркетплейс, как автоматизация процессов и масштабирование бизнеса
Возможно, в начале статьи стоило оговориться, что я специализируюсь на разработке маркетплейсов, но хотелось, чтобы статья была полезна максимальному количеству людей. Тем не менее, пример приведу всё-таки из своей основной области. Не во всех маркетплейсах заявки от заказчиков напрямую попадают исполнителям, от покупателей - продавцам. Во многих случаях есть еще менеджерское звено. Вот тут рассказывал подноготную одного раскрученного стартапа с такой идеей:
Заказчики оставляют заявки, администратор перезванивает, уточняет детали. Исполнители уже получают подготовленную заявку, где отражена вся необходимая для них информация.
Часто ко мне обращаются с идеей создания маркетплейса не с нуля. У человека уже есть оффлайн бизнес, есть сайт на котором оставляют заявки, менеджеры, обрабатывающие входящий трафик, и сами исполнители (мастера в той или иной отрасли, которые фактически выполняют задание). При этом, исполнители могут быть как штатные, так и на сдельщине.
Владельцу бизнеса хочется автоматизировать процесс назначения заявки, чтобы можно было масштабироваться на другие города и работать с удаленными сотрудниками.
Запускать и сайт, и приложение, для пользователей и исполнителей - дорого. А, если есть работающий сайт, то бессмысленно, с точки зрения продвижения. Зачем тратиться на новый сайт, когда уже есть трафик на старом?
В таких случаях я рекомендую делать следующее.
Доработка сайта. На сайте добавляется виджет для сбора заявок, вместо обычной формы обратной связи. Она отправляет заявку не в админку или почту, а в CRM или админку управления заказами.
Панель администратора. Админка здесь разделяется на два ключевых звена. Первое - это админка сайта, которая остаётся для управления контентом и SEO. Вторая - это админка управления заявками, которая реализуется через CRM (если много взаимосвязанных сущностей), либо в простеньком веб-интерфейсе, напрямую подключённому к API приложения. Второй вариант, само собой, существенно дешевле.
Приложение. Приложение в минимальной версии нужно только мастерам. Там они настраивают профиль, получают заявки по своей специализации и отчитываются за выполнение. Получается такой мини-планадо, только в своей отрасли.
В итоге, выходит такая схема. Клиент находит сайт в поисковике, оставляет заявку. Диспетчер перезванивает, узнает необходимые данные и уточняет заявку. После уточнения, она попадает в приложение для исполнителей, а исполнители бронируют за собой и выполняют.
Вроде бы выходит логика работы стандартного маркетплейса с промежуточным звеном, но за счёт готового сайта получается существенная экономия:
- Сама разработка сайта, в среднем 200-300 тыс
- SEO продвижение за 3-4 месяца. Тут всё сильно от сферы зависит, оценю по минимуму в 100 тыс
- Экономия времени 3-4 месяца - вы уже получаете эти заявки.
Очевидно, что сайт тоже придётся со временем модернизировать, если будет масштабирование по регионам или даже странам. Но для старта, текущего корп.сайта будет вполне достаточно.
Открыл статью , где в названии написано как запустить сайт+ мобильные приложения!
Итог: статья о каком то типе, который описал как он тратил деньги на свой проект - не нужно не кому в 21 веке - слушать такую чушь , и Читать у эх точно
Просто Денис ввёл всех заинтересованных читателей в заблуждение своим заголовком статьи "Как запустить проект с сайтом и приложением", а в результате просто пропиарил свой проект, хороший маркетинговый ход, а может случайность, сбился с мысли и рассказал о своих услугах.
А по факту (если изменить заголовок), то статья правильная.
Комментарий недоступен
Выделив для каждой платформы принципиальные для неё функции
Пользователям важно, чтоб сайт был красивым [...] вёрстка в стиле "голый бутстрап" редко адекватно воспринимается
Да, согласен с вами. Открыл ваш сайт, прокрутил в конец и тут же закрыл
Зачем эти непонятные мутки сайт плюс приложение. Можно сделать нормальный сай который и на десктопе работает и на смартфоне .
У вас какой-то геноцид приложений получается