Сайт NOVEX — это не витрина, а операционный инструмент продаж.
Ключевая особенность — сайт работает на общей бэк-части с мобильным приложением (смотри кейс ↗) и использует единые данные по товарам, остаткам, заказам и пользователям.
Проект интегрирован с большим количеством внутренних и внешних систем. Любые изменения в интерфейсе напрямую затрагивают бизнес-логику: доступность товара, способы получения, условия акций и корректность расчётов в заказе.
Часть сценариев прорабатывалась параллельно для сайта и мобильного приложения, чтобы поведение системы оставалось согласованным во всех каналах.
в каталоге novex.ru
с внешними и внутренними системами
с начала проекта
Особенности проекта
— Архитектурные ограничения, заложенные на ранних этапах развития продукта.
— Большой объём данных и товаров
— Высокая связность компонентов
— Многоуровневая бизнес-логика
— Зависимость фронтенда от нескольких API
— Необходимость поддержки разных технологических стеков (Nuxt 2 и Nuxt 3)
— Требования к высокой стабильности и отказоустойчивости
— Невозможность быстрых и радикальных изменений без риска для продаж
Каждая доработка проходит с учётом влияния на всю систему.
Стек технологий
— Backend: PHP (Symfony)
— Frontend: Nuxt 2, Vue 2
— Backend: PHP
— Frontend: Nuxt 3, Vue 3
— Flutter
Такое разделение требует поддержки разных версий фронтенда, совместимости API и согласованной архитектуры между продуктами.
Команда
8 человек из команды NAN обеспечивают полный цикл: от аналитики и проектирования до реализации, тестирования и поддержки
Backend developer • Frontend developer • Mobile Developer • DevOps • System Analyst • QA Engineer • UX/UI Designer • Project manager
Со стороны клиента — внутренняя IT-команда и стейкхолдеры.
«Новэкс» пришли к нам в августе 2023 года на техническую поддержку. На момент старта:
«Наш запрос был довольно стандартный: необходимо закрыть те компетенции, которых нет внутри компании. То есть разработчики тех специализаций, которых у нас нет. Чтобы сделать какую-то большую задачу, нам нужен полный цикл, в который войдёт и аналитик, и дизайнер, и потом фронт, бэк, мобильщик, тестировщик. И, соответственно, надо либо держать всё это внутри, либо отдавать кому-то, у кого есть всё. Держать всё это внутри для нас невыгодно, потому что это просто материально нецелесообразно. Значит, нужна студия, которая имеет полный цикл и может закрыть этот вопрос. Мы выбрали NAN».
Работа велась в формате технической поддержки и развития по запросу клиента.
Инициаторами задач выступали бизнес, внутренняя IT-команда, команда NAN — в части выявления рисков и технических проблем.
сделать сценарий покупки предсказуемым при высокой нагрузке;
обеспечить корректную работу сложной логики: акции, наличие, доставка, самовывоз;
внедрить функционал, повышающий конверсию сайта на ключевых этапах воронки;
снизить количество отказов при выборе товара и оформлении заказа.
Подход: не «переписывать всё», а точечно улучшать и стабилизировать систему.
Интеграция с сервисом доставки «Купер», ПВЗ СДЭК, ПВЗ Яндекс
Интеграция умного поиска на сайт и в мобильное приложение
Интеграция с Wildberries (готово ТЗ)
Усиление защиты сайта
Переработка фильтров в каталоге (ТЗ в разработке)
Доработка сервиса promo.ru
Объединение нескольких видов одного товара в одну карточку с возможностью выбора вариации внутри карточки (ТЗ в разработке)
Переработка карточек товара: изменение дизайна и добавление отображения наличия по филиалам (в наличии / под заказ)
Вынос и переработка ресайза изображений на отдельный сервер: изображения ранее обрабатывались на сервере Новэкса; для снижения нагрузки они были перенесены в хранилище Яндекса
Основные направления работ
→ Реализована интеграция с платформой Купер (СберМаркет); с пунктами выдачи заказов СДЭК; с сервисом умного поиска SearchBooster
→ Доработана интеграция с сервисом акций Mindbox
→ Подготовлены технические задания на интеграцию с Wildberries, пунктами выдачи заказов Яндекс и курьерской доставкой;
→ установка защиты от DDoS-атак через Cloudflare.
Проект развивается как живой продукт, где техподдержка является не просто устранением ошибок, а частью стратегического развития цифрового канала продаж.
Стабильная работа интернет-магазина
Регулярное развитие функционала
Поддержка и улучшение интеграций
Повышение удобства пользовательских сценариев
Готовность платформы к дальнейшему масштабированию
В этом кейсе мы сосредоточились на том, чтобы сценарий покупки был понятным, предсказуемым и устойчивым — как для пользователя, так и для бизнеса.
Повысили конверсию на ключевых шагах воронки и снизили долю отказов, связанных с неожиданными ограничениями по наличию и доставке, устранив неочевидные барьеры при выборе товара и оформлении заказа.
Сократили операционные риски, связанные с архитектурными и производственными ограничениями: минимум ошибок → минимум ручных разборов и обращений в поддержку.
Сделали процесс покупки управляемым и предсказуемым, даже при высокой нагрузке.
Цифровая инфраструктура для розницы — детали реализации
Проект развивался на протяжении длительного времени и к моменту начала работы с NAN уже имел сложившуюся архитектуру и набор технических особенностей, которые необходимо учитывать при развитии.
Архитектура и технический долг
Сайт является самописным решением, не основанным на CMS, и развивался несколькими подрядчиками. В процессе накопился технический долг, требующий регулярной поддержки и точечного рефакторинга. Часть архитектурных решений, заложенных на ранних этапах, со временем перестала соответствовать текущему масштабу проекта.
Серверная часть
С ростом функциональности и количества сценариев серверная часть системы значительно усложнилась. Изначальная структура не была рассчитана на текущую нагрузку и объём логики, поэтому развитие проекта требует более аккуратного подхода к изменениям и приоритизации задач.
Логика и используемые инструменты
В системе присутствует неочевидная бизнес-логика и взаимосвязи между сущностями, сформированные в ходе эволюции продукта. Используются инструменты и библиотеки предыдущих поколений, обновление которых требует осторожного подхода. Часть этих особенностей проявляется не сразу и может быть выявлена только в процессе глубокой работы с системой.
Документация
От предыдущих этапов разработки не сохранилась актуальная техническая документация, поэтому часть решений приходилось восстанавливать по коду и фактическому поведению системы.
Основной фокус был не на визуальном обновлении, а на поведении пользователя в сценарии покупки.
Мы последовательно разобрали воронку: каталог → карточка товара → корзина → оформление заказа — и выявили точки, где пользователь чаще всего «спотыкался».
Ключевая проблема: ограничения (наличие товара, способы доставки, участие в акциях) для пользователя становились очевидны слишком поздно — уже после того, как он принял решение о покупке. Это приводило к большому числу отказов.
Было:
Покупатель видел не все доступные для заказа товары: в каталоге отображались только позиции, находящиеся в наличии в выбранном филиале. Товары, доступные для заказа при изменении способа доставки или филиала, скрывались, что приводило к потере потенциальных покупок.
Стало:
Новая логика отображения наличия, которая позволяет покупателю:
Таким образом, покупатель раньше понимает все возможные варианты получения товара и не сталкивается с ограничениями на финальных шагах покупки.
Отдельное внимание уделили чекауту — самому чувствительному уровню воронки с точки зрения выручки.
Мы упростили сценарий оформления заказа, убрали лишние переходы и состояния неопределённости, синхронизировали расчёты доставки и итоговой стоимости.
Цель была простой: пользователь должен понимать, что именно он покупает, как и за какую цену, без сюрпризов.
Для расширения каналов продаж была реализована интеграция сайта Novex с платформой Купер (СберМаркет). Она позволяет покупателям оформлять заказы через витрины Купер, а магазину Novex — принимать, обрабатывать и отслеживать эти заказы в своей системе.
Ассортимент Novex был размещён на витринах Купер (сайт и мобильное приложение). Пользователь выбирает магазин, формирует корзину и оформляет заказ. Информация о заказе передаётся в Novex, где он собирается сотрудниками магазина, после чего в Купер отправляется статус готовности к доставке.
Обмен данными о заказах реализован через Orders API. Основной целью разработки было выстроить двусторонний обмен информацией о заказах:
Для передачи данных о товарах используется Content API. Через него в Купер передаются ассортимент, категории, цены и скидки, остатки и фотографии товаров. Для интеграции выбран формат JSON.
В результате был реализован стабильный двусторонний обмен заказами, система отслеживания статусов, механизм отмены заказов и обеспечена актуальность товарных данных. Интеграция протестирована в тестовой среде Купер и с использованием их сервиса самостоятельного тестирования.
На сайт был внедрен сервис SearchBooster, предназначенный для работы с большим ассортиментом и повышения качества навигации по каталогу.
Цель интеграции — улучшить качество поиска для пользователей сайта и мобильного приложения, а также начать сбор данных для анализа и дальнейшего развития поисковых сценариев.
SearchBooster включает два ключевых компонента:
В рамках задачи реализовано:
Сегодня умный поиск является обязательным элементом эффективного e-commerce-проекта и напрямую влияет на конверсию и лояльность пользователей.
promo.novex.ru — внутренний сервис NOVEX, личный кабинет для менеджеров, маркетологов и поставщиков. В системе создаются, редактируются, согласовываются, объединяются и продлеваются промо-акции, которые затем используются в интернет-магазине и других каналах продаж.
Команда NAN выполнила крупный блок доработок сервиса объемом около 300 часов, сосредоточившись на развитии функциональности и адаптации системы под реальные операционные процессы бизнеса.
Была доработана система управления акциями:
Отдельное внимание было уделено удобству пользователей: переработан интерфейс административной части сервиса для работы с большим объёмом акций.
Также была настроена интеграция с внутренней системой учёта SAP, из которой сервис получает данные по товарам. Это позволило синхронизировать акционные механики с актуальной товарной информацией и снизить количество ручных операций.
Стабильность и производительность
В процессе работы над проектом команда столкнулась с критической проблемой: крупный релиз невозможно было выкатить из-за утечки памяти на фронтенде. Проблема напрямую влияла на стабильность системы и серверную нагрузку, поэтому была вынесена в отдельную задачу.
В результате была выявлена и исправлена причина деградации производительности — некорректное использование паттерна EventBus и IntersectionObserver в Nuxt.js-приложении.
Для решения проблемы:
Решение не увеличило нагрузку на клиентскую часть, при этом позволило:
Для снижения нагрузки на серверы Novex и повышения производительности сайта обработка изображений была вынесена во внешнее облачное хранилище — Yandex Object Storage с использованием Yandex Cloud Functions.
В рамках работ:
Вынесение ресурсоёмких операций позволило освободить ресурсы серверов, ускорить загрузку страниц, повысить стабильность работы сайта и оптимизировать расходы на инфраструктуру.
Так как сайт работает в условиях высокой нагрузки и большого ассортимента, любые изменения проверялись с учётом производительности и устойчивости.
Решения принимались не изолированно, а с оглядкой на общую архитектуру и параллельную работу мобильного приложения, чтобы изменения не создавали расхождений между каналами.
Для оптимизации работы сайта:
Отдельно выполнена диагностика и устранение утечек памяти на фронтенде, выявленных в процессе эксплуатации.
Работа велась по отдельному техническому заданию.
Заключение
Этот проект — не про быстрые улучшения и не про редизайн.
Он про контроль сложной e-commerce-системы, где каждое изменение должно быть осмысленным, безопасным и согласованным с архитектурой продукта.
Задача команды NAN заключалась в том, чтобы поддерживать и развивать сайт без потери управляемости воронки и без риска для бизнеса.