Каталог помещается в экран телефона. Настоящая сложность начинается после кнопки «Купить»: остаток уже изменился, платёж задержался, а заказ должен одинаково выглядеть у клиента, склада, доставки и поддержки. Приложение не исправит эти процессы — оно сделает их быстрее и заметнее. Если покупатель возвращается редко, установка может только удлинить путь. Ниже разберём, когда приложение действительно оправдано, что должно работать в первой версии и в какой системе искать правильную цену, остаток, клиента и заказ. Универсальной частоты или обещания роста не будет: решение нужно проверить на данных вашего магазина.
1. Короткий ответ: когда магазину действительно нужно приложение
Отдельное приложение стоит обсуждать, когда сходятся три условия. Во-первых, покупатель уже повторяет один и тот же путь: например, возвращается за расходниками, продуктами, косметикой или товарами для регулярного обслуживания. Во-вторых, приложение заметно сокращает этот путь — сохраняет личный контекст, привычный адрес, избранное, правила лояльности и статус. В-третьих, бизнес способен выполнить обещание: цена, доступный остаток, оплата, заказ, доставка и возврат не расходятся между системами.
Повтор виден в данных
Есть группа покупателей, впервые купивших в один период, обычный срок до следующей покупки для категории и подтверждённый следующий заказ.
Путь становится короче
Пользователь получает пользу сверх копии мобильного сайта, а не новую иконку с теми же шагами.
Операции готовы
У товара, цены, остатка, клиента и заказа есть владельцы, задержки и правила конфликта.
Есть канал установки
Магазин понимает, кто предложит приложение клиенту и в какой момент ценность установки уже очевидна.
Когда решение не нужно
Если товар покупают редко, большинство клиентов приходит из поиска, а мобильный сайт ещё не доводит заказ до конца без ошибок, приложение добавит новый релизный цикл, но не устранит основную потерю. То же относится к магазину, где цены и остатки сверяются вручную: приложение быстрее покажет клиенту внутренний разрыв, а поддержке — добавит обращения.
В таком случае сначала полезнее исправить мобильное оформление заказа, проверить PWA или вынести в более простой формат только повторный кабинет и лояльность. Общая логика выбора между цифровыми форматами разобрана в статье о лендинге, сайте, интернет-магазине и приложении; этот материал идёт глубже именно в интернет-торговлю.
2. Сайт, PWA или приложение: дерево решения по частоте и сценарию
Начните с мобильного сайта. Он даёт первую покупку без установки, работает по ссылке и остаётся публичной точкой входа. Затем посмотрите на повторные покупки: возвращаются ли люди, что они делают снова и где теряют время. Если путь можно сократить веб-возможностями, PWA становится нормальным пилотом, а не упрощённой заменой приложения.
Аргумент «нужны push-уведомления, значит нужно отдельное приложение» устарел. Веб-приложения, добавленные на домашний экран, поддерживают Web Push на iOS и iPadOS с версии 16.4. Но пользователь всё равно должен добавить сайт на домашний экран, а возможности и установка зависят от браузера и ОС. Поэтому PWA проверяют на целевых устройствах, а отдельное приложение выбирают тогда, когда подтверждена дополнительная польза и нужен собственный релиз в магазинах приложений.
| Канал | Когда сильнее | Что доказать | Главный риск |
|---|---|---|---|
| Мобильный сайт | Первая и редкая покупка, поиск, реклама, ссылка | Базовое оформление заказа работает без менеджера | Проблемы мобильного сайта ошибочно лечат новым каналом |
| PWA | Повторный веб-путь, домашний экран, кэш, Web Push | Нужные функции работают на целевых устройствах | Разная поддержка браузеров и установка |
| Приложение | Частый личный маршрут и самостоятельная польза | Польза перекрывает установку и отдельные релизы | Получится дорогая копия сайта |
Есть ещё одно требование App Store: приложение должно давать функции, контент и интерфейс сверх «переупакованного сайта». Поэтому встроенный веб-экран (WebView) с каталогом — не короткий путь к надёжному релизу. Магазину всё равно придётся показать самостоятельную полезность, работающую серверную часть и сценарии, доступные ревьюеру.
3. Первая версия: путь от товара до подтверждённого заказа
Первую версию лучше собирать не из желаний отделов, а вокруг одного завершённого заказа. Покупатель находит товар, видит актуальную цену и доступность, собирает корзину, выбирает получение, оплачивает и получает подтверждение от сервера. После этого он понимает, что происходит дальше. Если цепочка обрывается на красивом экране подтверждения, продукт ещё не закрывает покупку.
| Приоритет | Что входит | Почему |
|---|---|---|
| Сначала — без этого заказ сорвётся | Каталог, поиск, карточка, цена и остаток, корзина, оформление, оплата, заказ, статус, ошибки, минимальная админ-операция | Без этого нельзя принять и исполнить один заказ |
| Затем — для повторной покупки | Личный кабинет, история, избранное, адреса, лояльность, уведомления о статусе, быстрый повтор | Ускоряет путь, который уже работает |
| Позже — когда накопятся данные | Персональные витрины, рекомендации, отзывы, фото, сложные промо, эксперименты | Эффект нужно проверять на покупателях магазина |
Обязательный минимум — не значит «мало экранов». Экран может быть один, но за ним работают резерв, расчёт доставки, платёжный статус, журнал заказа и право оператора исправить исключение. И наоборот, подборки и анимации могут занимать несколько экранов, не приближая первый надёжный заказ. О том, как превратить такой путь в понятный список задач, читайте в материале о запуске первой версии продукта.
Пришлите один путь в формате «клиент находит → оформляет → получает подтверждение → проверяет статус → повторяет». На первом разборе 13FOX отделит обязательное от идей «на потом», покажет, кто отвечает за каждый этап, и назовёт системы, которые нужно проверить до оценки.
4. Личный кабинет, лояльность, уведомления и повторная покупка
Личный кабинет нужен не ради регистрации. Он полезен, когда хранит то, что действительно экономит время: адреса, состав прошлых заказов, возвраты, бонусный баланс и понятный статус. Если покупателю достаточно разовой покупки, обязательный аккаунт добавляет пароль, восстановление и работу поддержки. Apple отдельно рекомендует не требовать вход, если у приложения нет значимых функций аккаунта.
Представьте: пользователь только открыл приложение, а система сразу просит доступ к уведомлениям. Он ещё
не видел товар и не понимает пользу. Гораздо яснее спросить после заказа: «Разрешить сообщать об
изменении статуса?» На Android 13+ для обычных уведомлений нужно системное разрешение
POST_NOTIFICATIONS. Apple запрещает делать уведомления обязательными, а рекламные сообщения
разрешает только после явного согласия и при наличии отказа внутри приложения.
- Статусы заказа и акции разделяйте по настройкам и смыслу.
- Если уведомления выключены, заказ всё равно должен открываться и обновляться внутри приложения.
- Бонусный баланс получает подтверждение от своей системы, а не пересчитывается на экране.
- Отзывы, фотографии и вопросы покупателей требуют жалоб, модерации, блокировки и контакта поддержки.
Лояльность усиливает повтор, но не создаёт его из воздуха. Сначала измерьте, что человек покупает снова и через какое окно. Затем сравнивайте долю завершённых повторных заказов и число шагов, а не отчёт об отправленных уведомлениях.
5. Карта систем: CMS, CRM, 1С/ERP, склад, оплата, доставка, аналитика
Фраза «интегрируем с 1С и CRM» не описывает результат. До сметы нужно назвать сущности и поля: кто отдаёт описание товара, кто рассчитывает цену, кто подтверждает доступный остаток, где создаётся клиент, кто меняет заказ и как приложение узнаёт о доставке. Рядом фиксируются задержка, идентификатор записи, правила безопасного повторного запроса и ручной сценарий, если обмен остановился.
| Система | Возможная роль | Вопрос до разработки |
|---|---|---|
| CMS / PIM — товарный каталог | Описание, медиа, категории, атрибуты | Что меняется редактором и когда попадает в приложение? |
| 1С / ERP / склад | Цена, физический остаток, резерв, документы | Чем физический остаток отличается от доступного к продаже? |
| CRM / профиль | Клиент, согласия, сегмент, коммуникации | Как объединяются гость, телефон и существующий клиент? |
| OMS — сервер заказов | ID заказа, переходы статуса, журнал, правила | Кто разрешает отмену, замену и повтор? |
| Оплата и доставка | Фактический статус операции и отправления | Как сверяется задержанное или повторное событие? |
| Аналитика | Получатель событий и воронка | Какие серверные события подтверждают бизнес-результат? |
6. Источник истины для товара, цены, остатка, клиента и заказа
«Источник истины» — система, чьё значение считается окончательным для конкретной сущности или поля. Не обязательно выбирать одну систему на весь магазин. Android-архитектура прямо допускает разные источники для разных доменов: профиль может жить в одном месте, платёж — у провайдера, заказ — в серверной части магазина, а описание товара — в CMS.
У приложения другая работа: быстро показать локальную копию и отправить команду. Кэш помогает при слабой сети, но не превращается в владельца остатка. Если экран показывает «в наличии» по старой копии, он обязан предупредить об обновлении и перепроверить доступность перед подтверждением.
В одном из рабочих проектов доставки команда 13FOX делала обратную запись через 1С Fresh. Из этого опыта можно безопасно вынести один урок: обмен проектируют в обе стороны и заранее решают, что делать при повторе и конфликте. Название, конфигурация, объекты обмена, сроки и метрики проекта не публикуются. Публичных данных об этих деталях нет, поэтому выводов о них мы не делаем.
7. Работа без сети, ошибки оплаты и возвраты
Режим без сети — не переключатель «работает всё». Приложение может показать уже загруженный каталог, сохранённую корзину, историю и последний известный статус с временем обновления. Оно не должно обещать окончательный резерв, списание денег или доставку, пока сервер не подтвердил операцию.
Допустим, покупатель нажал «Оплатить», сеть оборвалась, а провайдер уже принял операцию. Пользователь нажимает снова. Если каждый запрос создаёт новый платёж и новый заказ, красивое оформление превращается в двойную покупку. От дубля защищают единый ключ запроса, журнал состояний, правило «повтор не создаёт второй платёж» и последующая сверка. Возврат пользователя в приложение сам по себе не доказывает оплату.
Слабая сеть
Покажите локальные данные, время обновления и безопасный повтор, а не бесконечный индикатор загрузки.
Платёж завис
Дайте статус «проверяем», запросите состояние у провайдера и не создавайте новый заказ молча.
Резерв не создан
Заказ не переходит в подтверждённый; оператор видит исключение и понятный следующий шаг.
Возврат задержан
Покажите этап возврата и причину ошибки; кнопка сотрудника не равна завершённой операции.
Для физических товаров Apple и Google не требуют использовать встроенную оплату магазинов приложений: можно использовать подходящий эквайринг, Apple Pay, Google Pay или ввод карты. Цифровые функции, подписки и смешанные наборы классифицируют отдельно. Это правило говорит о способе оплаты, но не отменяет эквайринг, договор, возвраты и применимое право.
8. Админка и операционная работа после публикации
После релиза сотрудникам понадобится менять товар, видеть новый заказ, исправлять адрес, отменять позицию, запускать возврат и объяснять клиенту задержку. Если каждое действие требует разработчика, приложение не автоматизирует магазин — оно создаёт ещё одну очередь задач.
- Заказы: поиск, состав, сумма, источник, история статусов, причина отмены.
- Исключения: платежи без заказа, заказы без резерва, задержанные события, дубли.
- Каталог и промо: кто редактирует данные и где окончательное значение.
- Права: оператор, менеджер, логист, поддержка и администратор не получают лишний доступ.
- Журнал: кто, когда и почему изменил состояние.
- Поддержка: владелец очереди, оповещения, резервные копии и порядок эскалации.
Подготовка к публикации тоже входит в MVP. Для App Store нужна доступная политика конфиденциальности и удаление аккаунта внутри приложения, если аккаунт создаётся. Google Play требует декларацию Data safety о работе с данными, учитывающую сторонние SDK, а также внутренний и внешний путь удаления аккаунта. Для проверки магазинам нужна работающая серверная часть и стабильный тестовый доступ ко всем функциям.
Удаление аккаунта не означает, что бизнес обязан стереть документы, которые должен хранить по закону. Но пользователь должен понимать, что удаляется, что сохраняется и почему. Юридические сроки зависят от страны и модели магазина; этот раздел не заменяет консультацию по праву.
9. Как считать смету через сценарии и интеграции
Два приложения с похожим числом экранов могут требовать совершенно разного объёма работ. В одном каталог приходит из готового API, оплата проста, доставка внешняя. В другом нужно объединить несколько складов, правила цен, частичные отмены, бонусы и 1С без стабильного тестового контура. Поэтому оценка начинается не с экранов, а со сценариев, ролей, данных и исключений.
| Фактор | Что подготовить до оценки | Что меняет объём |
|---|---|---|
| Путь покупки | Схема шагов и состояний | Ветки получения, оплаты, отмены и возврата |
| Роли | Таблица прав доступа | Покупатель, оператор, курьер, поддержка, админ |
| Данные | Список систем и нужных полей | Миграция, поиск, кэш, конфликты, объём каталога |
| Интеграции | API, тестовый доступ, лимиты | Очереди, повторы, мониторинг, ручное восстановление |
| Эксплуатация | Действия администратора и план поддержки | Логи, оповещения, резервные копии, релизы в магазинах приложений |
Готовое решение под брендом магазина (white-label) может быстрее проверить стандартный сценарий, но до договора проверьте владение аккаунтами в магазинах приложений, исходниками, данными, доменами и возможность миграции. Индивидуальная разработка оправдана, когда правила заказа и интеграции действительно отличают бизнес. Гибрид оставляет готовую основу, но требует честного списка ограничений. Подробная логика бюджета вынесена в материал о стоимости мобильного приложения.
10. Календарный MVP по методике Power
В публичном документе Power план на 6–26 апреля 2026 года разделён по ролям и этапам. Сначала фиксируются пути покупателя, курьера и администратора. Затем проектируются состояния «новый», «в пути», «доставлен», «отменён», ошибка геолокации и пустые экраны. Flutter-команда собирает каталог, корзину, оформление, статус, курьерский путь и проводит отдельный интеграционный день. После него запланирован блок тестирования и стабилизации.
Ценность примера не в календарных датах. Он показывает порядок мышления: роли → путь → состояния → интерфейсы → интеграция → стабилизация. Для вашего магазина состав и длительность будут другими, особенно если нет готового API, нужны сложные возвраты или несколько складов. Сам публичный план Power — рабочий артефакт методики, а не завершённый кейс с коммерческими результатами. Завершённые продукты и форматы задач вынесены отдельно в портфолио 13FOX, чтобы не смешивать метод и доказательства.
11. Метрики после релиза без вымышленных бенчмарков
Чужая «нормальная конверсия» мало говорит о вашем цикле покупки. Начните с единого словаря событий
сайта и приложения. GA4 рекомендует для интернет-торговли события view_item, add_to_cart,
begin_checkout, add_shipping_info, add_payment_info,
purchase и refund. Но бизнес-результат лучше подтверждать серверным заказом,
а не только клиентским событием.
Повторный спрос
Покупатели со следующим завершённым заказом / группа первой покупки за обычный срок повтора в категории.
Завершение пути
Серверно подтверждённые заказы / начавшие оформление, с разбивкой по версии и каналу.
Операционная точность
Конфликты цены, остатка и платежа; ручные коррекции; возраст незакрытых возвратов.
Надёжность
Сбои и зависания по одной версии и одному окну, время подтверждения заказа, ошибки API.
Для каждой метрики запишите: событие → числитель → знаменатель → окно → сегмент → исходная точка → решение. Тогда показатель отвечает на вопрос продукта. Без этого удержание, конверсия и доля сеансов без сбоев могут иметь разные знаменатели и вести к разным решениям.
12. Десять проверок: готов ли магазин к приложению
Это не тест с красивым процентом в конце. Для каждого пункта нужен документ, ответственный или честный ответ «пока не знаем». Если неизвестное может сорвать заказ, сначала его исследуют — зелёную галочку ставить рано.
- Повторный спрос: есть группа первой покупки и обычный срок до следующего заказа.
- Мобильный сайт: базовый заказ уже работает без обязательной установки.
- Польза приложения: один повторный путь становится конкретно короче или надёжнее.
- Владельцы данных: назначены товар, цена, остаток, клиент и заказ.
- Состояния заказа: описаны успех, отмена, ошибка и ручное восстановление.
- Оплата и возврат: есть безопасный повтор, серверное уведомление от платёжного сервиса и сверка.
- Интеграции: доступны API, тестовые данные, лимиты и ответственные.
- Операции: сотрудники видят журнал и исправляют разрешённые исключения без кода.
- Приватность: подготовлены согласия, удаление аккаунта и реестр SDK.
- После релиза: есть владелец событий, оповещений, поддержки и решений о развитии.
13. Источники и границы выводов
Правила платформ и архитектурные рекомендации проверены 29 июля 2026 года. Основные первичные и официальные источники:
- Apple App Review Guidelines, обновлены 8 июня 2026: оплата физических и цифровых товаров, минимальная полезность, уведомления, приватность и удаление аккаунта.
- Google Play Developer Program Policy, актуальная редакция с 15 июля 2026: Payments, User Data, Data safety, deletion и пользовательский контент.
- Android: notification runtime permission, обновлено 14 июля 2026.
- WebKit: Web Push for Web Apps, 16 февраля 2023: поддержка Home Screen web apps с iOS/iPadOS 16.4.
- Android Data layer, обновлено 29 апреля 2026: источники истины по доменам.
- Android Offline-first, обновлено 13 мая 2026: локальное чтение, очереди записи и конфликты.
- GA4 recommended events: стандартный словарь событий интернет-торговли без универсальных порогов.
- Power: календарный план MVP: публичный пример ролей и стабилизации, не клиентский результат.
Без данных конкретного магазина нельзя честно назвать универсальный рост, цену, срок, порог удержания или ROI. Закрытые детали 1С Fresh мы тоже не додумывали. Политики платформ, SDK и требования к данным меняются: их нужно перепроверять перед публикацией конкретного приложения.
FAQ
Когда интернет-магазину действительно нужно мобильное приложение?
Когда магазин уже видит повторный сценарий в своих данных, приложение заметно сокращает этот путь, а каталог, остатки, платежи, заказ, доставка и поддержка готовы работать как единый контур. Универсального порога частоты нет: его определяют по категории и собственным группам покупателей.
Что обязательно включить в первую версию приложения интернет-магазина?
В обязательный минимум входят один полный путь покупки, достоверные цена и остаток, каталог и поиск, карточка товара, корзина, оформление, подтверждённая оплата, заказ со статусами, понятные ошибки и базовые действия оператора. Лояльность и персонализацию можно добавить после первого стабильного заказа.
Может ли PWA заменить отдельное приложение магазина?
Иногда. PWA может устанавливаться, работать с кэшем и поддерживать Web Push, в том числе у Home Screen web apps на iOS и iPadOS с версии 16.4. Но возможности и установка зависят от браузера и ОС, поэтому решение проверяют на целевых устройствах и конкретном сценарии.
Как связать приложение интернет-магазина с 1С?
Сначала назначают владельца каждого поля: товара, цены, доступного остатка, клиента и заказа. Затем фиксируют направление обмена, задержку, ключи сущностей, поведение при дубле или конфликте, журнал и ручное восстановление. 1С может владеть частью данных, но не обязана быть источником истины для всего.
Как принимать оплату за физические товары в мобильном приложении?
Для физических товаров App Store и Google Play не требуют использовать встроенную оплату магазинов приложений: используются подходящий эквайринг, Apple Pay, Google Pay или ввод карты. Цифровые товары и функции классифицируются отдельно. Успех платежа подтверждает серверный статус провайдера, а не возврат пользователя на экран.
Сколько стоит и сколько времени занимает разработка?
Оценка зависит от пути покупки, ролей, источников данных, качества API, оплаты и возвратов, админки, слабой сети, аналитики, публикации в магазинах приложений и поддержки. Сопоставить сметы можно после разбора этих частей на задачи; точная цена по одному списку экранов скрывает допущения.
Узнайте, что должно войти в первую версию — до сметы
Пришлите частоту покупок, один повторный путь и список систем: CMS, CRM, 1С/ERP, склад, оплата и доставка. На первой встрече 13FOX проверит, нужно ли отдельное приложение, выделит обязательный минимум, соберёт вопросы к владельцам данных и разложит первую версию на задачи. Если приложение не оправдано, предложим мобильный сайт, PWA или другой более простой формат.