Интернет-магазин в MAX — это Mini App с каталогом, карточками товаров, корзиной и оформлением заказа, который открывается внутри мессенджера. Бот помогает пользователю войти в магазин, сообщает статус и возвращает его к повторной покупке.
Формат подходит не каждому e-commerce-проекту. Наиболее сильные сценарии — повторные заказы, компактный ассортимент, локальная доставка, подборки и продажи аудитории, которая уже взаимодействует с брендом в MAX.
Магазин реализуется как веб-приложение по HTTPS, подключённое к чат-боту MAX. Требования к запуску и взаимодействию Mini App с клиентом мессенджера собраны в официальной документации.
Какие форматы магазина можно запустить
Витрина с заявкой
Пользователь выбирает товар и отправляет запрос менеджеру. Цена, наличие и детали подтверждаются вручную. Это самый простой вариант для пилота, B2B-продаж и товаров со сложной конфигурацией.
Каталог и корзина
Клиент добавляет позиции, указывает количество и оформляет заказ. Система рассчитывает сумму и передаёт данные в CRM или учётную систему. Оплата может происходить позднее по ссылке, счёту или после подтверждения.
Полный сценарий заказа
Mini App показывает актуальные остатки, применяет промокоды, рассчитывает доставку, принимает оплату через выбранного провайдера и создаёт заказ в 1С или другой системе.
| Формат | Для кого подходит | Основное ограничение |
|---|---|---|
| Витрина с заявкой | B2B, сложные товары, тест спроса | Ручное подтверждение |
| Каталог и корзина | Розница и локальные бренды | Нужна обработка заказов |
| Полный магазин | Регулярные продажи и повторные покупки | Интеграции и поддержка данных |
Как выглядит путь покупателя
- Пользователь открывает бот или переходит по диплинку на конкретную подборку.
- Mini App показывает категории, поиск и карточки.
- Клиент выбирает варианты и добавляет товары в корзину.
- Система проверяет цену и наличие.
- Пользователь указывает способ получения и контакт.
- При необходимости проходит оплата.
- Заказ создаётся в рабочей системе компании.
- Бот отправляет подтверждение и изменения статуса.
Путь должен оставаться коротким. Если магазин требует сложной регистрации до просмотра ассортимента, часть аудитории не дойдёт до выбора.
Что должно быть в каталоге
Для каждой позиции необходимо определить обязательные данные:
- название и категория;
- изображения;
- краткое описание;
- цена и единица измерения;
- варианты или модификации;
- наличие;
- условия получения;
- ограничения по количеству;
- связанные товары.
Источником каталога может быть CMS, 1С, ERP, товароучётная система или собственная база. Если ассортимент небольшой и меняется редко, допустимо управлять им через простую административную панель.
Корзина и проверка заказа
Корзина должна храниться на стороне сервера или синхронизироваться с backend, если пользователь может вернуться позже. Перед оформлением необходимо повторно проверить цены, остатки и ограничения.
Нельзя полагаться только на значения, пришедшие из интерфейса. Пользовательский код не является доверенным источником суммы заказа. Финальный расчёт выполняется на сервере.
Если часть товара закончилась или цена изменилась, интерфейс должен объяснить это до оплаты и предложить обновить корзину.
Оплата и касса
Платёжный сценарий проектируется с учётом выбранного провайдера, онлайн-кассы, способа доставки, возвратов и юридической модели продавца. Mini App может инициировать оплату и получать результат через backend, но токены и секретные ключи нельзя размещать во фронтенде.
До разработки нужно определить:
- когда заказ резервируется;
- сколько действует резерв;
- когда формируется чек;
- как подтверждается успешная оплата;
- что делать при закрытии платёжной страницы;
- как оформляются частичный и полный возвраты;
- кто решает спорные ситуации.
Если заказ требует проверки менеджером, безопаснее сначала создать заявку, а оплату запрашивать после подтверждения наличия и условий.
Доставка и получение
Для локального магазина часто достаточно трёх вариантов: самовывоз, доставка по зоне и согласование с менеджером. В более сложной версии подключают расчёт по адресу, интервалы, пункты выдачи и внешние службы.
Пользователю нужно заранее показать:
- доступные способы;
- стоимость;
- ориентировочный срок;
- минимальную сумму;
- ограничения по территории;
- контакт для изменений.
Интеграция с CRM и 1С
Интеграция убирает ручное копирование и позволяет поддерживать единый статус заказа. Обычно передаются:
- клиент и контакт;
- состав корзины;
- цены и скидки;
- адрес и способ получения;
- источник и рекламные параметры;
- статус оплаты;
- номер заказа;
- изменения и отмены.
Из 1С или ERP Mini App может получать каталог, цены, остатки и статусы. Архитектура зависит от конфигурации, доступного API и требований к нагрузке. Для стабильности часто используют промежуточный backend, который кеширует данные и изолирует учётную систему от прямых пользовательских запросов.
Конструктор или индивидуальная разработка
Конструктор подходит, если магазин типовой: небольшой каталог, стандартная корзина, простая форма и готовая интеграция. Это дешевле и быстрее для проверки канала.
Индивидуальная разработка нужна, если есть:
- нестандартный каталог или конфигуратор;
- разные цены для сегментов;
- сложная логика остатков;
- несколько складов и филиалов;
- программа лояльности;
- B2B-роли и документы;
- интеграция с существующим backend;
- особые требования к дизайну и аналитике.
Выбор должен зависеть от процесса, а не от желания сразу построить максимально сложный продукт.
Как продвигать магазин внутри MAX
Точки входа можно размещать в канале, чат-боте, на сайте, в рассылках, QR-кодах на упаковке и офлайн-точках. Диплинк позволяет открывать конкретную категорию или предложение и передавать метку источника.
Для повторных продаж бот может напоминать о регулярном заказе, сообщать об изменении статуса и предлагать релевантное продолжение. Коммуникации должны учитывать согласие пользователя и правила платформы.
Метрики магазина
- переход в Mini App;
- просмотр категории и карточки;
- добавление в корзину;
- начало оформления;
- успешно созданный заказ;
- успешная оплата;
- средний чек;
- повторный заказ;
- отмена и возврат;
- ошибки синхронизации цен и остатков.
По этим данным видно, где пользователи теряются и какие товары действительно интересны аудитории MAX.
Частые ошибки
- Переносить весь большой интернет-магазин без адаптации под мобильный сценарий.
- Хранить цену и итоговую сумму только во фронтенде.
- Не синхронизировать остатки.
- Считать заказ созданным до записи в учётную систему.
- Не обрабатывать повторный callback от платёжного провайдера.
- Не показывать пользователю понятный статус.
- Отправлять менеджеру заказ без состава и источника.
Частые вопросы
Можно ли создать магазин в MAX без программирования?
Да, если задача укладывается в возможности готового конструктора. Для нестандартной логики, дизайна и интеграций потребуется разработка.
Обязательно ли принимать оплату внутри сценария?
Нет. Можно начать с каталога и заявки, а оплату проводить после подтверждения менеджером. Это особенно уместно для сложных или B2B-заказов.
Можно ли синхронизировать товары с 1С?
Да. Способ зависит от конфигурации 1С и доступного механизма обмена. Обычно интеграцию выполняют через отдельный backend.
Подходит ли MAX для большого ассортимента?
Технически каталог может быть большим, но интерфейс должен поддерживать поиск, фильтры и быструю загрузку. Для первой версии разумно проверить отдельную категорию или повторный сценарий покупки.
Нужен ли отдельный сайт?
Обычно да. Сайт продолжает работать с поисковым и широким рекламным трафиком, а магазин в MAX сокращает путь для аудитории мессенджера и повторных клиентов.