Как запустить проект с сайтом и приложением
Денис Гордиенко, руководитель 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 веке - слушать такую чушь , и Читать у эх точно
Просто Денис ввёл всех заинтересованных читателей в заблуждение своим заголовком статьи "Как запустить проект с сайтом и приложением", а в результате просто пропиарил свой проект, хороший маркетинговый ход, а может случайность, сбился с мысли и рассказал о своих услугах.
А по факту (если изменить заголовок), то статья правильная.
Денис ввёл всех заинтересованных читателей в заблуждение не только своим заголовком статьи "Как запустить проект с сайтом и приложением", а всем материалом! Уверен, что статья - это его мысли «вслух», чтобы проверить свою гипотезу: «Зайдет или не зайдет» - предлагать своим потенциальным клиентам «снабжать» свои сайты-лендинги мобильным приложением.
Мобильное приложение предлагается использовать в качестве альтернативы e-mail уведомлениям (только через мобильные PUSH-уведомления) «о поступлении заявки на сайт».
Я уверен, что «не зайдет»! Просто, под такое «придуманное» решение нет целевой аудитории. Все те, кто обрабатывают по 300+ заявок в день, уже давно используют специализированные десктопные CRM системы в которые «сваливаются» все обращения клиентов с сайтов и распределяются между менеджерами/складами/партнерами (у них «ярко моргают лампочки» и даже «вибрируют стулья» при каждой новой заявке :))). А для 10-30 заявок в день, достаточно настроить проверку почты в смартфоне и получать «мобильные PUSH-уведомления» о поступлении новой почты бесплатно.
А для «эстетов», кому нужно «жить и работать в телефоне», есть облачные CRM-системы для сайта, в которых уже реализован функционал учета и обработки заявок с сайта с получением уведомлений в мобильное приложение и даже прием звонков с сайта в мобильное приложение.
Например, я использую облачную CRM-систему для сайта - Slon.biz
Ну тут я с вами не согласен, всё зависит от категории и задачи приложения и CRM-системы попросту не всё решают и к тому же лишнее звено. Есть проект - сервис поиска исполнителей, вот о нём он и раскрыл суть статьи, так как ранее был использован как вебвайм на битриксе, так что тут никакие вебваймы и CRM рядом не стояли. Второй пример - такси или каршеринг - тут что будете использовать?
Это как раз ко второму преимуществу приложений - работе с gps. Что для такси, что для каршеринга - это ключевые функции
я не вам вопрос адресовал, сам занимаюсь с ionic и прекрасно знаю все за и против
Комментарий недоступен
Выделив для каждой платформы принципиальные для неё функции
Да, согласен с вами. Открыл ваш сайт, прокрутил в конец и тут же закрыл
Зачем эти непонятные мутки сайт плюс приложение. Можно сделать нормальный сай который и на десктопе работает и на смартфоне .
У вас какой-то геноцид приложений получается
Комментарий недоступен
В итоге на чем платформа зиждется-то?
наша переписана на Ionic.Framework, но статья применима для любых проектов имеющих в себе сайт и приложение
90 за ионик?...
ну ладно.
В комплекте серверная часть , верно? А вот например типовая для моей сферы нагрузка - около 15млн товаров плюс ежемесячное пополнение на 200-300к.. Потянет или рухнет на первой сотне тысяч?
Вы, наверное, не увидели, что ядро для маркетплейса услуг.
А что касается товаров, то если есть планируемая нагрузка в 15 млн, то и сервер аналогично проектируется.
Та просто в WebView загружать мобильную версию та и всё.. зачем для магазинов что-то еще? Что может ionic из того, что нельзя реализовать в WebView?
Я тоже 2 года был сторонником вебвью. Пришлось перейти, т.к. чтоб сделать качественно на нем, программист должен быть очень прокачан и стоит дорого. Проще переучить на ангуляр
А ангуляр в WebView отличается от ангуляра в браузере что ли?
Выше речь про некомпилируемый webview, где отображается мобильная страница сайта и компилируемый ionic/cordova
Так если ваша мобильная версия летает в браузере то она так же будет летать в webview, программисты на php или на чем там у вас магазин дорогие нынче?
если обычные экранчики заверстать, то да. Обычно вебщики валятся на работе с push, gps, оптимизацией JS-вычислений и больших данных
насколько я знаю, в гугл.плей еще можно пробиться с таким "приложением открывающим сайт в вебвью", а вот в эйпл стор - не пройдет модерацию
Комментарий недоступен
Обычно о продаже идет речь в контексте готового решения, либо о покупке стартапа в целом. Во втором случае сделки проходят не публично