Мобильное приложение для интернет-магазина: когда нужно, если уже есть сайт, и что в нём должно быть

Короткий ответ: приложение нужно интернет-магазину, у которого покупатели возвращаются часто — продукты, косметика, корма, расходники, одежда с регулярными новинками, — и есть чем их возвращать: push, бонусы, повтор заказа. Если покупают раз в год и приходят из поиска, хватит хорошей мобильной версии сайта или PWA. Первую версию приложения делаем на том же бэкенде, что и сайт: каталог, цены, остатки и заказы общие. По прайсу мобильное приложение для iOS и Android стоит от 200 000 ₽ и делается от 2 недель.

Кому из магазинов приложение реально нужно?

Тем, у кого выручку делают постоянные покупатели, а не новые. Приложение не приводит людей из поиска — его ставят те, кто уже купил и собирается купить снова. Поэтому первый вопрос не «какое приложение», а «сколько у нас повторных заказов и что заставит клиента вернуться».

Признаки, что приложение оправдано:

• Повторные покупки — норма. Покупатель заказывает раз в неделю или раз в месяц: еда, вода, бытовая химия, корм для животных, детские товары, расходники для мастеров.
• Есть программа лояльности или вы её запускаете. Бонусный счёт, персональные цены, карта покупателя в телефоне вместо пластиковой.
• Есть поводы для уведомлений. Новые поступления, возврат товара в наличие, снижение цены на отложенное, статус доставки.
• Есть офлайн-точки. Приложение работает как карта клиента на кассе и как витрина «забрать сегодня в магазине».
• Покупатели сами просят. Если в отзывах и чатах спрашивают «а приложение будет?», это сигнал сильнее любого опроса.

И наоборот: магазин мебели, сантехники или крупной техники с покупкой раз в несколько лет приложение почти не использует. Его установят единицы, а удалят после первой покупки. Такому магазину важнее быстрый сайт, понятный каталог и заявка в один экран.

Что важно магазину	Мобильная версия сайта	PWA	Приложение в App Store и Google Play
Покупатель находит магазин из поиска	Да, это основной вход	Да, это тот же сайт	Нет, приложение ищут в сторе или ставят по ссылке
Иконка на экране телефона	Нет, только закладка	Да, если покупатель сам добавит её	Да, после установки из стора
Push-уведомления	Нет	Android — да; iPhone — с iOS 16.4 и только после добавления на экран «Домой»	Да, на обеих платформах с разрешения покупателя
Вход без пароля каждый раз, сохранённые адреса и карта	Зависит от браузера и cookie	Как у сайта	Да, сессия живёт в приложении
Проверка магазинами приложений	Не нужна	Не нужна	Нужна при каждой новой версии
Отдельный бюджет	Входит в тариф магазина	Считаем после брифа	От 200 000 ₽ и от 2 недель

Что приложение даёт по сравнению с мобильной версией сайта?

Три вещи: иконку на экране телефона, push-уведомления на обеих платформах и сохранённый вход с адресами и историей заказов. Всё остальное — каталог, поиск, корзина, оплата — хорошая мобильная версия сайта тоже умеет. Сайт при этом выигрывает в главном: его находят из поиска.

Отдельно о PWA — сайте, который можно добавить на экран телефона как приложение. На Android он умеет присылать push, а на iPhone веб-уведомления появились с iOS 16.4 и только для сайтов, добавленных на экран «Домой», — так написано в блоге WebKit. Добавлять сайт на экран покупатель должен сам, через меню браузера, и делают это немногие. Как устроены уведомления в приложении и почему их надо отдельно разрешать — в статье о push-уведомлениях.

Ещё одно ограничение, о котором стоит знать до старта: приложение-обёртку над сайтом магазины приложений принимают неохотно. В правилах проверки App Store (п. 4.2) прямо сказано, что приложение должно давать больше, чем переупакованный сайт. Поэтому в приложении магазина свои экраны, вход, push и работа с данными покупателя, а не сайт в рамке.

Экран	Что на нём	Нужен в первой версии?
Каталог и категории	Дерево разделов, фильтры, сортировка	Да
Поиск	Строка поиска с подсказками, те же правила, что на сайте	Да
Карточка товара	Фото, цена, наличие, варианты (размер, цвет), кнопка «В корзину»	Да
Корзина и оформление	Состав заказа, доставка, оплата, промокод	Да
Вход и профиль	Телефон или email, адреса, удаление аккаунта	Да
Мои заказы	Статусы, повтор заказа одной кнопкой	Да
Избранное	Отложенные товары и уведомление о снижении цены	Желательно
Бонусный счёт	Баланс, история начислений, карта покупателя	Если программа лояльности уже работает
Чат с поддержкой, отзывы, сторис	Общение и контент	Нет, во вторую очередь

Какие экраны и функции нужны в первой версии?

Только путь покупки и то, ради чего приложение ставят: каталог, поиск, карточка, корзина с оформлением, вход, мои заказы. Это шесть–семь экранов. Избранное и бонусный счёт — если без них приложение теряет смысл. Чат, отзывы, сторис и персональные подборки — во вторую версию.

Базовый тариф мобильного приложения рассчитан на 6–8 экранов, и приложение магазина обычно попадает ровно на эту границу. Каждый экран сверх неё, сложная логика и интеграции увеличивают смету — это видно на брифе, до договора.

Что легко упустить в первой версии:

• Удаление аккаунта. Если в приложении есть регистрация, Apple требует дать возможность удалить аккаунт прямо в приложении (п. 5.1.1(v) правил проверки). Без этого экрана сборку вернут.
• Повтор заказа. Кнопка «Заказать снова» в истории — то, ради чего постоянный покупатель открывает приложение, а не сайт.
• Глубокие ссылки. Ссылка на товар из рассылки или push должна открывать карточку в приложении, а если приложения нет — тот же товар на сайте.
• Пустые и ошибочные состояния. Нет интернета, товар закончился, пока лежал в корзине, оплата не прошла — у каждого случая свой понятный экран.
• Аналитика воронки. Сколько человек открыли карточку, положили в корзину и оплатили — без этого через месяц не понять, работает ли приложение.

Как приложение получает каталог, цены и остатки с сайта и из 1С?

Через API сайта, а не напрямую из 1С. Сайт уже получает товары, цены и остатки из учётной системы и отдаёт заказы обратно; приложение подключается к серверу сайта и видит то же самое. Один каталог, одни остатки, один список заказов — у менеджера ничего не раздваивается.

Как это выглядит по шагам:

1. 1С — сайт. Обмен остаётся каким был: товары, цены и остатки приходят на сайт, заказы уходят в 1С. Как он устроен на протоколе обмена с сайтом и CommerceML — в статье про магазин с обменом 1С.
2. Сайт — приложение. Сервер магазина отдаёт приложению каталог, карточки, корзину и заказы через программный интерфейс (REST API) и принимает от него новые заказы.
3. Заказ из приложения попадает в ту же админку и в ту же 1С, что и заказ с сайта, с пометкой источника, чтобы считать продажи по каналам.

Если сайт сделан на коробочной платформе, у неё обычно уже есть API, и вопрос в том, хватает ли его для приложения: корзина, личный кабинет, промокоды. Если сайт самописный и API нет, его делаем отдельно — по тарифу интеграций от 32 000 ₽ и от 2 дней или в составе сметы приложения. Подключать приложение к 1С напрямую не советуем: учётную базу не стоит выставлять в интернет ради каждого покупателя, а нагрузку от каталога она держит хуже веб-сервера.

Пример общего бэкенда из нашей практики — магазин AleksFurs: витрина, панель магазина и обмен с 1С по CommerceML 2.08 работают на одном сервере, а медиана ответа страницы каталога в замере — 12 мс. Если такому магазину понадобится приложение, оно подключится к тому же серверу, не трогая обмен с 1С.

Оплата, push и бонусы: что учесть?

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

Оплата. За физические товары App Store и Google Play не требуют встроенных покупок: Apple в п. 3.1.3(e) правил требует оплачивать такие товары другими способами, а правила платежей Google Play запрещают проводить оплату физических товаров через платёжную систему Google Play. Значит, работает ваш платёжный шлюз и онлайн-касса, как на сайте; чек по 54-ФЗ формируется так же — подробности в статье об оплате на сайте и онлайн-кассе.

Push. Разрешение на уведомления покупатель даёт один раз, а отзывает за секунду. Хорошее правило: спрашивать разрешение не при первом запуске, а в момент, когда польза очевидна, — после оформления заказа («сообщить, когда привезут?») или при добавлении в избранное («сообщить о снижении цены?»). Рассылка «скидки каждый день» приводит к отключению уведомлений, а иногда и к удалению приложения.

Бонусы. Начисления и списания живут на сервере — в 1С, CRM или в базе магазина, — а приложение только показывает баланс и даёт списать баллы при оформлении. Карта покупателя в виде штрихкода или QR на экране закрывает вопрос пластиковых карт в офлайн-точках.

Сколько стоит и сколько времени займёт?

По прайсу мобильное приложение для iOS и Android из одного кода стоит от 200 000 ₽ и делается от 2 недель. В базовый объём входят до 6–8 экранов, вход, push, оплаты, подключение к вашему API и публикация в App Store и Google Play под вашими аккаунтами. Точную смету называем после брифа и фиксируем в договоре до старта.

Из чего складывается итог для магазина:

• Приложение. От 200 000 ₽ за базовый объём; экраны сверх 6–8, чаты и сложная логика — по оценке. Подробно — в статье сколько стоит мобильное приложение для бизнеса.
• API сайта. Если готового нет — отдельная работа, от 32 000 ₽ по тарифу интеграций или в смете приложения.
• Если сайта ещё нет. Сначала магазин: тариф интернет-магазина — от 104 000 ₽ и от 5 дней, мобильные приложения в него не входят и считаются отдельно.
• Платежи сторам. Аккаунт разработчика Apple — 99 долларов в год, Google Play — 25 долларов один раз; оформляются на вас.
• После запуска. 14 дней бесплатно исправляем ошибки, гарантия по договору — 30 календарных дней с даты акта; дальше поддержка по абонентке от 7 900 ₽ в месяц или почасово.

По срокам закладывайте сверх разработки проверку в магазинах приложений: она идёт на стороне Apple и Google, и её срок от нас не зависит. Оплата по договору — 50 % предоплаты и 50 % после подписания акта; на приёмку у вас 5 рабочих дней. Правки — до 2 раундов на прототипе и до 2 раундов на готовой сборке.

Делать ли приложение из того же кода, что и сайт? Можно, и это законный путь: так сделано наше приложение знакомств Twin — единый код на React с нативными сборками для App Store и Google Play. Но для магазина важнее не технология, а то, чтобы у приложения были свои экраны и сценарии, иначе сборка упрётся в п. 4.2 правил Apple. Варианты по скорости и бюджету — PWA, кроссплатформа или натив — разобраны в отдельной статье рубрики.

Когда приложение не нужно

Когда у магазина мало повторных покупок, сайт ещё медленный или неудобный на телефоне, а бюджета на продвижение самого приложения нет. Приложение не исправляет плохой сайт и не приводит новых покупателей — оно удерживает тех, кто уже купил.

Типичные ошибки магазинов, решивших «тоже сделать приложение»:

• Приложение вместо сайта. Деньги ушли в приложение, а мобильная версия сайта осталась медленной. Новые покупатели по-прежнему приходят из поиска на сайт и уходят.
• Нет повода установить. В приложении то же, что на сайте, без бонусов, без повторного заказа, без уведомлений о заказе. Установок мало, и через полгода приложение не обновляют.
• Отдельная база. Приложению сделали свой каталог и свою выгрузку из 1С. Остатки в приложении и на сайте расходятся, менеджеры путаются в заказах.
• Сразу всё. Чат, отзывы, сторис, рекомендации и игры в первой версии. Срок растёт, а покупатели пользуются тремя экранами из десяти.
• Спам уведомлениями. Ежедневные рассылки с первого дня — и большинство пользователей отключает push, то есть главный инструмент приложения.
• Аккаунты сторов на подрядчике. Если приложение опубликовано не под аккаунтом магазина, перенос потом отнимает время. У нас приложения публикуются под вашими аккаунтами разработчика.

Честный порядок для большинства магазинов: сначала быстрый сайт с удобным оформлением заказа на телефоне, затем PWA или Telegram-бот для повторных заказов, и приложение — когда доля постоянных покупателей и программа лояльности его оправдывают. Если вы уже там, приложение на общем бэкенде с сайтом — понятный следующий шаг.

Чек-лист перед заказом приложения для магазина

Ответьте на эти вопросы до брифа — смета и срок станут точнее, а лишние экраны отпадут сами.

• Какая доля заказов за последний год — повторные? Как часто постоянный покупатель заказывает?
• Какой повод открыть приложение вы дадите: бонусы, повтор заказа, ранний доступ к новинкам, статус доставки?
• На чём сделан сайт и есть ли у него API для каталога, корзины и заказов?
• Откуда берутся цены и остатки — 1С, другая учётная система, таблица?
• Какой эквайринг и какая онлайн-касса подключены к сайту?
• Есть ли программа лояльности и где хранится бонусный баланс?
• Кто будет готовить push-уведомления и как часто?
• Оформлены ли аккаунты разработчика Apple и Google Play на вашу компанию?

Короткие ответы на частые вопросы

Нужно ли интернет-магазину мобильное приложение, если сайт хорошо работает на телефоне?

Только если у магазина много повторных покупок и есть повод возвращать покупателей: регулярные заказы, бонусы, новые поступления. Для разовых покупок из поиска хватает быстрой мобильной версии сайта, а иконку на экране и часть уведомлений даст PWA.

Сколько стоит мобильное приложение для интернет-магазина?

По нашему прайсу мобильное приложение для iOS и Android из одного кода стоит от 200 000 ₽ и делается от 2 недель, в базовый объём входят до 6–8 экранов. Приложение магазина с полным путём покупки обычно на границе этого объёма или чуть больше, поэтому точную смету называем после брифа и фиксируем в договоре до старта.

Можно ли сделать приложение, если магазин уже работает на своей платформе?

Да, если у сайта есть API или его можно добавить: приложение берёт каталог, цены, остатки и заказы оттуда же, откуда сайт. Если платформа не отдаёт данные наружу, сначала делаем программный интерфейс, и это считается отдельной работой.

Будут ли App Store и Google Play брать комиссию с покупок в приложении магазина?

За физические товары — нет: правила Apple и Google требуют для таких покупок использовать обычные способы оплаты, а не встроенные покупки магазина приложений. Оплата идёт через ваш эквайринг, комиссию берёт банк или платёжный сервис по своему тарифу.

Может ли приложение быть просто сайтом в обёртке?

Технически да, но Apple прямо пишет в правилах проверки, что приложение должно давать больше, чем переупакованный сайт, и такие сборки рискуют не пройти модерацию. Приложению нужны свои экраны, вход, push и работа с данными покупателя.

Услуги и кейсы по теме: мобильные приложения · интеграция с 1С и CRM от 32 000 ₽ · кейс AleksFurs · цены и сроки