Каталог и категории
Иерархия должна помогать покупателю найти товар по задаче, типу и параметрам, а команде — управлять ассортиментом без дублирования карточек.
Разработка интернет-магазинов
Интернет-магазин как связка каталога, учёта и продаж
Проектируем ecommerce вокруг реальной товарной модели: категории, свойства, варианты, цены, остатки, поиск, корзина, оплата, доставка, 1С/ERP, CRM, SEO и аналитика. Витрина не должна жить отдельно от учётной системы.
- Каталог и товарная модель
- 1С/ERP, цены и остатки
- Заказ, оплата и доставка
Базовый контур
Что должно работать в интернет-магазине до запуска трафика
Ecommerce начинается с товарной и операционной логики. Красивый дизайн не компенсирует ошибки в единицах, вариантах, остатках или оформлении заказа.
Фильтры и поиск
Фильтруемые свойства определяются из реального выбора пользователя. Поиск учитывает названия, артикулы, синонимы и технические обозначения.
Карточка товара
Цена, единица продажи, варианты, наличие, характеристики, документы, комплектация, доставка и CTA должны быть однозначными.
Избранное и сравнение
Для сложного ассортимента помогаем сохранить выбор и сравнить параметры, которые действительно влияют на решение.
Корзина
Проверяем количество, единицы, цену, скидки, наличие и ограничения до перехода к оформлению.
Оформление заказа
Минимизируем обязательные поля, но собираем всё, что реально нужно для оплаты, доставки и связи с клиентом.
Оплата и доставка
Подключаем выбранные способы с учётом регионов, габаритов, ограничений товара и бизнес-правил.
Учётная система
Номенклатура, цены, остатки и заказы синхронизируются по заранее согласованной модели обмена и идентификаторам.
Готовность к росту
Что закладываем, чтобы магазин можно было масштабировать
После запуска ассортимент, SEO, реклама и повторные продажи увеличивают нагрузку на архитектуру. Эти сценарии лучше учитывать заранее.
0102 0305 06
SEO-категории и посадочные
Определяем, какие комбинации спроса становятся индексируемыми страницами, а какие остаются фильтрами и закрываются от поиска.
Промо, акции и скидки
Правила скидок не должны конфликтовать с ценами из 1С/ERP и ручным управлением. Источник истины фиксируется заранее.
CRM и статусы клиента
Заказ, обращение, повторная коммуникация и источник клиента связываются в едином контуре, если это нужно бизнесу.
04Сквозная аналитика
Передаём ecommerce-события, рекламные идентификаторы и данные о заказе в аналитический контур без персональных данных там, где они не нужны.
Фиды и внешние площадки
YML/XML/CSV или API-выгрузки проектируются из стабильной товарной модели, а не собираются вручную под каждую площадку.
Повторные продажи
Личный кабинет, история заказов, повтор заказа, уведомления и сегментация подключаются по мере зрелости бизнеса.
Архитектура
Интернет-магазин начинается с бизнес-логики заказа
До дизайна фиксируем товарную модель, цену, наличие, резерв, оплату, доставку и источник данных. Именно эти решения определяют интерфейс карточки и checkout.
Цена и товарные варианты
Определяем единицы измерения, модификации, комплектации, скидки и правила отображения цены. В сложном ассортименте эти решения влияют на карточку сильнее декоративных элементов.
Остатки и резерв
Фиксируем источник остатков, момент резервирования и поведение товара при отсутствии. Сайт не должен принимать заказ на позицию, которую учётная система уже считает недоступной.
Оплата и доставка
Проектируем комбинации способов оплаты, служб доставки, регионов и ограничений до подключения модулей. Ошибка в этих правилах напрямую влияет на завершение заказа.
Статусы и обмен с учётной системой
Заказ должен получить один идентификатор и предсказуемо пройти сайт, CRM/1С и службы исполнения. Логи и повторная синхронизация закладываются в интеграцию заранее.
Связанные решения
Что чаще всего связано с ecommerce-проектом
Магазин редко существует сам по себе: его качество зависит от учёта, поиска, SEO, CRM и операционного сопровождения.
01
1С-Битрикс
Корпоративная ecommerce-платформа, интеграции, каталог и стандартные бизнес-модули.
02SEO интернет-магазинов
Категории, фильтры, индексация, товарные страницы и управление дублированием.
03CRM и интеграции
Заказы, обращения, статусы и данные о клиентском пути.
04Техническая поддержка
Мониторинг обменов, обновления, ошибки оформления и развитие после запуска.
Товарная модель
Самая частая причина проблем — неправильная модель товара
До импорта каталога фиксируем, что является товаром, предложением, вариантом, свойством и единицей продажи.
Единицы измерения
Штука, метр, упаковка, комплект, кг или другая единица должна одинаково пониматься сайтом, 1С и менеджером. Если продаётся кратно упаковке — правило отражается в интерфейсе.
Варианты и модификации
Размер, цвет, длина, материал и комплектация не должны плодить дубли карточек, если покупатель воспринимает их как один продукт.
Артикулы и идентификаторы
Связь сайта и учётной системы строится по стабильным ключам. Название товара не используется как идентификатор обмена.
Характеристики
Свойства разделяем на фильтруемые, отображаемые, служебные и SEO-значимые, чтобы каталог не превращался в набор случайных полей.
1С / ERP
Интеграция с учётной системой проектируется как отдельный контур
Обмен должен быть устойчив к ошибкам и повторному запуску. Важно заранее определить источник истины для каждой группы данных.
Номенклатура
Определяем, какие поля создаются и обновляются автоматически, а какие редакторы сайта могут менять вручную.
Цены и типы цен
Розничные, оптовые, персональные и акционные цены имеют понятный приоритет и источник.
Остатки
Фиксируем склады, доступность, резерв и поведение при временной ошибке обмена, чтобы сайт не показывал ложное наличие.
Заказы
Заказ получает стабильный ID, передаётся в учётную систему и возвращает статусы без создания дублей.
Логи и диагностика
Ошибки синхронизации должны быть видны и воспроизводимы. Критичные обмены нельзя оставлять «чёрным ящиком».
Выбор товара
Каталог должен помогать выбрать, а не просто хранить позиции
Для сложного ассортимента UX строится вокруг реальных критериев сравнения и поиска.
Категории
Группировка соответствует логике покупателя и поисковому спросу, а не только структуре 1С или внутреннему учёту.
Фильтры
Показываем только свойства, которые помогают сузить выбор. Пустые и низкоценные фильтры не перегружают интерфейс.
Поиск
Поддерживаем артикулы, альтернативные названия, транслитерацию и синонимы там, где это влияет на поиск товара.
Сравнение
Сравниваем однородные характеристики и скрываем строки без различий, чтобы таблица оставалась полезной.
Checkout
Оформление заказа должно переживать реальные сценарии
Тестируем не только идеальный заказ, но и ошибки оплаты, изменение наличия, ограничения доставки и повторную отправку.
Проверка корзины
Перед оформлением повторно проверяются цена, количество, доступность и правила скидок.
Оплата
Успешный, отменённый и неуспешный платёж имеют понятные статусы и не создают дубликаты заказов.
Доставка
Стоимость и доступные способы рассчитываются по региону, весу, габаритам и бизнес-ограничениям.
Уведомления
Клиент и команда получают подтверждения только после корректной фиксации заказа в системе.
Платформа
Когда выбираем 1С-Битрикс и Аспро
Для магазинов с 1С, большим каталогом и стандартным ecommerce-контуром 1С-Битрикс часто снижает стоимость разработки по сравнению с созданием всех модулей с нуля.
0102 03
1С-Битрикс
Каталог, торговые предложения, корзина, заказы, скидки, пользователи, интеграции и развитая административная часть.
Аспро
Используем как ускоритель там, где типовой функционал и визуальная база соответствуют задаче. Основные файлы решения не редактируем — кастомизация выносится в local и пользовательские компоненты.
Кастомная разработка
Выбираем, если бизнес-логика сильно отличается от стандартного магазина и готовая платформа создаёт критичные ограничения.
Миграция
При переносе существующего магазина сначала сохраняем данные и SEO
До разработки нового сайта собираем текущие URL, товары, категории, свойства, изображения, пользователей и заказы в объёме, который действительно нужно перенести. Отдельно фиксируем соответствия ID между старой системой, новой CMS и 1С. Для поисковых страниц готовим карту 301-редиректов и проверяем, какие фильтры и категории должны сохранить индексацию. Нельзя сначала загрузить каталог, а потом пытаться восстановить связи и SEO по названиям.
Оценка проекта
Смета интернет-магазина определяется архитектурой, а не числом товаров
Десять тысяч однотипных товаров могут быть проще ста сложных карточек с вариантами, персональными ценами и нестандартной доставкой. На объём проекта влияют товарная модель, 1С/ERP, типы цен, склады, личный кабинет, способы оплаты и доставки, миграция, SEO, фиды и интеграции. До оценки фиксируем обязательный контур первой версии, отдельно — развитие после запуска.
FAQ
Вопросы о разработке интернет-магазина
Что важно определить до миграции каталога, подключения 1С и начала разработки.
С товарной модели и бизнес-логики заказа: что продаём, в каких единицах, какие варианты и цены существуют, откуда берутся остатки, как формируется доставка и куда должен попасть заказ. После этого проектируем каталог и интерфейс.
Да. До реализации фиксируем объекты обмена, стабильные идентификаторы, типы цен, склады, правила обновления и обработку ошибок. Не привязываем интеграцию к названиям товаров и не делаем прямые запросы к базе 1С-Битрикс.
Да. Для ecommerce-проектов используем 1С-Битрикс и решения Аспро, когда их архитектура соответствует задаче. Кастомизацию выносим в local/templates, пользовательские компоненты и точки расширения, чтобы не ломать обновления основного решения.
Да, но сначала анализируем структуру исходных данных. Важно сохранить связи товаров и вариантов, изображения, свойства, SEO-URL и идентификаторы для интеграций. Если старые данные противоречивы, часть нормализации нужно выполнить до миграции.
Собираем индексируемые URL, определяем новые соответствия, сохраняем сильные категории и карточки, готовим 301-редиректы, метаданные и canonical. После запуска проверяем sitemap, robots, коды ответа и технические дубли.
Да, если выбранный платёжный провайдер и юридическая схема клиента готовы к подключению. Обязательно тестируем успешную, отменённую и ошибочную оплату, чтобы статусы заказа не расходились с фактическим платежом.
Да. Конкретный набор служб и расчётов зависит от географии, веса, габаритов и процессов клиента. До интеграции фиксируем ограничения, чтобы не выводить покупателю невозможные способы.
Не всегда. Для первой версии часто достаточно истории заказа и уведомлений. Личный кабинет оправдан, если есть повторные покупки, персональные цены, документы, статусы, избранное или B2B-сценарии.
Стоимость определяется не количеством SKU, а сложностью товарной модели, 1С/ERP, интеграций, checkout, доставки, оплаты, миграции и личного кабинета. После аналитики фиксируем первую очередь и смету по этапам.
Контролируем обмены, оформление заказов, оплату, доставку, индексацию и ключевые ecommerce-события. Затем проект можно передать внутренней команде или оставить Vionex на техническом сопровождении и развитии.
Разберём каталог и бизнес-логику до оценки разработки
Покажите текущий магазин, выгрузку или структуру 1С — определим товарную модель, обязательные интеграции и состав первой версии.