Хакатон SberCloud
для разработчиков
До конца регистрации:
04
:
11
:
42
:
35
Подробнее
45 дней сериалов
и фильмов по промокоду:
VC45 Активировать 18+
Личный опыт
Денис Гордиенко
1666

Как запустить проект с сайтом и приложением

Денис Гордиенко, руководитель 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 месяца - вы уже получаете эти заявки.

Очевидно, что сайт тоже придётся со временем модернизировать, если будет масштабирование по регионам или даже странам. Но для старта, текущего корп.сайта будет вполне достаточно.

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 25, "likes": 3, "favorites": 74, "is_advertisement": false, "subsite_label": "life", "id": 93711, "is_wide": false, "is_ugc": true, "date": "Sat, 23 Nov 2019 18:09:30 +0300", "is_special": false }
45 дней сериалов и фильмов по промокоду VC45
Активировать
Условия подписки Яндекс.Плюс: clck.ru/FMQND. 45 дней подписки Яндекс.Плюс — бесплатно, далее автопродление — 199 руб./мес. с указанием данных банковской карты. Предложение до 31.12.2020г. Только для новых пользователей, ранее не оформлявших подписку Яндекс.Плюс. Условия просмотра на КиноПоиск: ya.cc/4y4UX
18+
Объявление на vc.ru Отключить рекламу
Маркетинг
Как мы продали обувь ручной работы на 12 млн рублей за четыре месяца: кейс Biker Boots Russia
Как разработать стратегию продвижения, правильно выстроить рекламную воронку и установить рекорд по объему продаж…
0
25 комментариев Накачай стартап
Популярные
По порядку
Написать комментарий...
5

Открыл статью , где в названии написано как запустить сайт+ мобильные приложения!
Итог: статья о каком то типе, который описал как он тратил деньги на свой проект - не нужно не кому в 21 веке - слушать такую чушь , и Читать у эх точно

Ответить
1

Просто Денис ввёл всех заинтересованных читателей в заблуждение своим заголовком статьи "Как запустить проект с сайтом и приложением", а в результате просто пропиарил свой проект, хороший маркетинговый ход, а может случайность, сбился с мысли и рассказал о своих услугах.
А по факту (если изменить заголовок), то статья правильная.

Ответить
1

Денис ввёл всех заинтересованных читателей в заблуждение не только своим заголовком статьи "Как запустить проект с сайтом и приложением", а всем материалом! Уверен, что статья - это его мысли «вслух», чтобы проверить свою гипотезу: «Зайдет или не зайдет» - предлагать своим потенциальным клиентам «снабжать» свои сайты-лендинги мобильным приложением.
Мобильное приложение предлагается использовать в качестве альтернативы e-mail уведомлениям (только через мобильные PUSH-уведомления) «о поступлении заявки на сайт». 

Я уверен, что «не зайдет»! Просто, под такое «придуманное» решение нет целевой аудитории. Все те, кто обрабатывают по 300+ заявок в день, уже давно используют специализированные десктопные CRM системы в которые «сваливаются» все обращения клиентов с сайтов и распределяются между менеджерами/складами/партнерами (у них «ярко моргают лампочки» и даже «вибрируют стулья» при каждой новой заявке :))). А для 10-30 заявок в день, достаточно настроить проверку почты в смартфоне и получать «мобильные PUSH-уведомления» о поступлении новой почты бесплатно. 

А для «эстетов», кому нужно «жить и работать в телефоне», есть облачные CRM-системы для сайта, в которых уже реализован функционал учета и обработки заявок с сайта с получением уведомлений в мобильное приложение и даже прием звонков с сайта в мобильное приложение.
Например, я использую облачную CRM-систему для сайта - Slon.biz 

Ответить
0

Ну тут я с вами не согласен, всё зависит от категории и задачи приложения и CRM-системы попросту не всё решают и к тому же лишнее звено. Есть проект - сервис поиска исполнителей, вот о нём он и раскрыл суть статьи, так как ранее был использован как вебвайм на битриксе, так что тут никакие вебваймы и CRM  рядом не стояли. Второй пример - такси или каршеринг - тут что будете использовать?

Ответить
0

Это как раз ко второму преимуществу приложений - работе с gps. Что для такси, что для каршеринга - это ключевые функции

Ответить
0

я не вам вопрос адресовал, сам занимаюсь с ionic и прекрасно знаю все за и против

Ответить

Острый Артем

5

Как запустить проект с сайтом и приложением

Так как же?

Ответить
0

Выделив для каждой платформы принципиальные для неё функции

Ответить
2

Пользователям важно, чтоб сайт был красивым [...] вёрстка в стиле "голый бутстрап" редко адекватно воспринимается

Да, согласен с вами. Открыл ваш сайт, прокрутил в конец и тут же закрыл

Ответить
1

Зачем эти непонятные мутки сайт плюс приложение. Можно сделать нормальный сай который и на десктопе работает и на смартфоне .

Ответить
0

У вас какой-то геноцид приложений получается

Ответить
0

clickchat.me может объеденить приложение и сайт. (Не реклама) Просто пример

Ответить
0

В итоге на чем платформа зиждется-то?

Ответить
0

наша переписана на Ionic.Framework, но статья применима для любых проектов имеющих в себе сайт и приложение

Ответить
0

90 за ионик?...
ну ладно.

В комплекте серверная часть , верно? А вот например типовая для моей сферы нагрузка - около 15млн товаров плюс ежемесячное пополнение на 200-300к.. Потянет или рухнет на первой сотне тысяч?

Ответить
1

Вы, наверное, не увидели, что ядро для маркетплейса услуг. 

А что касается товаров, то если есть планируемая нагрузка в 15 млн, то и сервер аналогично проектируется. 

Ответить
0

Та просто в WebView загружать мобильную версию та и всё.. зачем для магазинов что-то еще? Что может ionic из того, что нельзя реализовать в WebView?

Ответить
0

Я тоже 2 года был сторонником вебвью. Пришлось перейти, т.к. чтоб сделать качественно на нем, программист должен быть очень прокачан и стоит дорого. Проще переучить на ангуляр

Ответить
0

А ангуляр в WebView отличается от ангуляра в браузере что ли?

Ответить
0

Выше речь про некомпилируемый webview, где отображается мобильная страница сайта и компилируемый ionic/cordova

Ответить
0

Так если ваша мобильная версия летает в браузере то она так же будет летать в webview, программисты на php или на чем там у вас магазин дорогие нынче?

Ответить
0

если обычные экранчики заверстать, то да. Обычно вебщики валятся на работе с push, gps, оптимизацией JS-вычислений и больших данных

Ответить
0

насколько я знаю, в гугл.плей еще можно пробиться с таким "приложением открывающим сайт в вебвью", а вот в эйпл стор - не пройдет модерацию

Ответить
0

Посоветуйте, где можно купить маркетплейс уже готовый? типа playntrade.ru (не реклама) просто пример!

Ответить
0

Обычно о продаже идет речь в контексте готового решения, либо о покупке стартапа в целом. Во втором случае сделки проходят не публично

Ответить

Комментарии

null