Рост конверсии 25%: как мы обновили сайт по продаже дорожно-строительной техники

Заказчик — компания «Техстройконтракт», продает экскаваторы, бульдозеры, погрузчики, самосвалы и еще десятки наименований специализированной техники брендов со всего мира. Обширная сеть в 93 филиала по всей России, больше 100 тысяч наименований запчастей, услуги сервиса и аренды. В общем, настоящий гигант отрасли.

К нам обратились с конкретной проблемой: обновить и адаптировать один раздел на сайте. Проект интересный, заказчик отзывчивый и погруженный в тему — мы с удовольствием взялись за работу. Но быстро поняли, что все будет далеко не так просто…

Расскажем, с какими сложностями столкнулись, как переделывали весь сайт почти год, и что в итоге это дало бизнесу.

Любой проект начинается с того, что нужно внимательно изучить задачи бизнеса. Начать заказчик предложил с одного раздела на сайте — «запчасти». Того самого, где реально больше сотни тысяч позиций. Вот какие задачи стояли перед бизнесом.

Заказчик прекрасно понимал, что страница выглядела не очень современно. Нужно было подать «товар лицом» и в целом сделать дизайн не хуже, чем у конкурентов.

Заказчик изучил разные варианты и сам собрал техническое задание довольно общими штрихами: здесь должно быть так, тут примерно вот так. Но разумеется, был полностью открыт нашим предложениям.

Другая сторона — это бэкенд. Есть внешняя база данных на Oracle, суммарно примерно на 11 млн записей. На ней завязаны все бизнес-процессы компании, лезть туда с точки зрения безопасности нельзя. Но мы можем получать от нее данные двух форматах:

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

Старая версия раздела вообще не была как-то оптимизирована с точки зрения индексации в поисковиках. Важно было продумать расположение элементов, структуру и заголовки, чтобы было и удобно для клиентов, и роботы предлагали сайт в верхней части поисковой выдачи.

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

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

Другая проблема — предложение заказчика по общему виду раздела выглядело не особо современно. Мы мягко описали ему, в чем проблема, и почему важно переработать дизайн более глубоко, а не просто переставить несколько элементов и поменять цвета. Заказчик согласился, и подключились наши дизайнеры.

Проработали каждый нюанс: все отрисовали в Figma и создали UI Kit — набор готовых элементов, из которых потом можно собирать потом любые страницы «по кирпичикам».

Самый сложные этап, занявший больше месяца. База данных заказчика Oracle была закрыта. Нам отдали только исходный код сайта на Python и Django, и были готовы выгружать XML файлы с данными. Но стало ясно, что старый код морально устарел.

Начали с того, что внедрили базовый Docker, просто чтобы было удобно работать с данными на сервере заказчика, автоматически разворачивать контейнеры и прочее. Но дальше выяснилось, что выгружаются данные пачками по 1-1,5 Гб. Мало того, что механизм проверки данных не был реализован, так и на обработку такого массива уходило по несколько часов. Разумеется, бизнес такое не устраивало.

Как быть? Если не погружаться в технические детали, реализовали такой подход: данные выгружаются не большими массивами, а маленькими порциями. Какого размера, зависит от того, на какие позиции изменились цены или остатки. Для чего обновлять то, что не менялось, и тратить вычислительные ресурсы сервера?

Сами данные со стороны заказчика прилетают по времени автоматически. Номенклатура (например, добавление новых позиций в ассортимент) обновляется два раза в сутки в формате XML. А цены и остатки — в формате JSON динамически, в зависимости от изменений в базе заказчика. Например, клиент приобрел единственную запчасть, к нам прилетает остаток 0.

Разумеется, все данные проходят валидацию: как на стороне заказчика, так и у нас, чтобы исключить ошибки в формате, дублирование и так далее.

Первые тесты показали: вычислительной мощности сервера все равно не хватает. После того, как в арендуемом ЦОДе добавили примерно 50% производительности, процесс ускорился во много раз.

Самый ответственный момент — первая выгрузка данных. Нужно получить весь массив, а дальше только контролировать, что будет меняться в базе заказчика и выгружать по реализованному с нуля API. На выгрузку и первую валидацию ушло порядка четырех часов.

Результаты тестов показали, что теперь процесс занимал не часы, а буквально несколько минут. Причем обновление происходило в течение дня так, что на общую производительность это никак не влияло.

Отдельный момент — внедрить грамотную форму поиска. Какие должны быть фильтры? Как сделать его удобным для посетителя? Мы провели не один созвон с заказчиком, подробно разбираясь и оптимизируя алгоритм. В итоге реализовали два алгоритма:

Сам поиск товара после нажатия кнопки «Найти» занимает буквально доли секунды.

Заказчик обратился к внешней команде на аутсорсе, поскольку внутри компании этим никто не занимался. Пока команда разработчиков занималась импортом данных и поиском, SEO специалисты изучали дизайн раздела и предлагали свои замечания по оптимизации.

На весь процесс для «запчастей» потребовалось буквально две итерации согласования. Зато заказчик был уверен, что его сайт будет высоко ранжироваться в выдаче Google или Яндекс.

Текущая версия сайта была реализована на Python 3.7 и фреймворке Django 2.2. Этот стек был актуален в 2018 году, но сейчас работать с ним было неудобно:

Пообщавшись с заказчиком, мы решили «обновиться» до более актуальных Python 3.13 и Django 5.0. Чтобы не терять времени, распараллелили процессы: пока одни разработчики создавали новый программный модуль или компонент, другие адаптировали уже сделанный под новый стек. В результате получилось обновить код практически бесшовно.

Разработка раздела «Запчасти» заняла порядка двух месяцев, с учетом всех описанных выше этапов и сложностей. Получился рабочий раздел, в котором:

Заказчика все устроило, и он предложил: «А давайте обновим и другие разделы на сайте? Хочется реализовать еще много всякого функционала». Ну как тут можно отказаться? 🙂

На сайте заказчика были вот такие разделы:

У каждого раздела — своя логика, в которой нужно было разобраться. При этом хотелось внедрить дополнительный функционал личного кабинета, формы заказа, записи на сервис, возможность добавления в корзину арендуемой техники и много чего еще.

Какие же здесь были основные проблемы для бизнеса, которые собирались решать адаптацией сайта?

Забегая вперед — за следующие 8 месяцев мы успешно реализовали все, что требовалось для бизнеса, и даже больше. Вот некоторые примеры, как адаптировали функционал под бизнес-процессы.

Есть две основных категории клиентов: физические и юридические лица. У каждого при регистрации нужно спрашивать разное, при этом связанные с этим функции (например, форма заказа или уровни доступа) также меняется, в зависимости от указанных данных. Но какие именно связи возникают? Все это прописывалось и продумывалось в тесном общении со специалистами заказчиков.

Общий подход к реализации функционала — покомпонентный. Условно есть некие общие шаблоны под разную технику или услугу. Но как именно будут меняться конкретные поля, должно определяться автоматически, с точки зрения единообразия. А вдруг заказчик в будущем решит добавить что-то новое?

В итоге создали больше 90 автотестов. Конечно, это усложняет процесс разработки, но зато в будущем сэкономит намного больше времени, если нужно будет масштабироваться или находить неисправность.

Для примера: в карточках арендуемой техники автоматически подтягивается VIN номер и филиал, где она расположена. А для новой техники это не требуется.

Допустим, человек записывается на сервис. Он может сделать это по разной технике, в любом из 93 филиалов России. При этом должно отображаться доступное время и дата для записи, а еще лучше — приблизительная стоимость, в зависимости от мото-часов (примерно как пробег у обычных автомобилей).

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

Суммарно адаптация сайта «Техстройконтракт» заняла 10 месяцев. И после полной приемки и подготовки документации состоялся долгожданный для всех релиз.

Первые три месяца прошли немного в тестовом режиме: устраняли мелкие недочеты, оптимизировали микросервисы и следили за трафиком и конверсией в заявку. В итоге заметили, что с первого по третий месяц трафик вырос на 30%, а конверсия — на 25%. Ни заказчик, ни мы не ожидали такого быстрого результата.

Как это получилось? На это есть несколько причин:

Но кроме этого:

«Сейчас мы занимаемся переводом сайта на современный стек технологий на NextJS. В дальнейшем планируем улучшать интеграции с внешними сервисами и CRM заказчика», — говорит Дмитрий, руководитель команды разработки.