На чём нельзя экономить при разработке интернет-магазина

Автор: команда Guard IT
Материал подготовлен на основе практики проектирования, разработки и доработки сайтов для бизнеса.

Проверил: Константин Щеголев, руководитель Guard IT. Участвует в развитии веб-проектов, подготовке структуры и контента, внедрении аналитики и ИИ-инструментов для бизнеса.

Экономия при разработке интернет-магазина оправдана, если она сокращает объём первого запуска, но не нарушает путь покупателя и работу сотрудников. Можно перенести часть автоматизации, отказаться от сложной анимации или начать с ограниченного набора функций.

Нельзя откладывать:

• проектирование каталога,
• подготовку товарных данных,
• мобильное оформление заказа,
• проверку оплаты, доставки и остатков.

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

Подробный состав проекта разобран в статье «Что входит в интернет-магазин под ключ». Здесь рассмотрим именно бюджет: какие работы можно перенести, а сокращение каких этапов обычно приводит к дополнительным расходам.

Коротко: на чём нельзя экономить

До запуска необходимо проверить:

• структуру категорий и фильтров;

• качество характеристик и изображений;

• карточки основных типов товаров;

• оформление заказа на телефоне;

• обмен с 1С или другой системой учёта;

• оплату, доставку и изменение статусов;

• соответствие цен и остатков;

• передачу заказов сотрудникам;

• основные события электронной торговли;

• резервные копии и порядок поддержки после запуска.

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

Проектирование структуры каталога

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

Структуру магазина нельзя без проверки копировать из 1С, прайс-листа или внутренней базы. Учётная система создаётся для сотрудников, а каталог сайта должен учитывать логику покупателя.

До начала дизайна нужно определить:

• категории и подкатегории;

• характеристики, влияющие на выбор;

• параметры фильтрации;

• товары, которые покупатели будут сравнивать;

• основные и сопутствующие позиции;

• страницы брендов, серий и областей применения;

• правила размещения товара в нескольких разделах.

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

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

Подготовка характеристик и исходных данных

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

Типичные проблемы:

• один цвет записан как «чёрный», «черный» и «Black»;

• размеры указаны в разных единицах;

• обязательные характеристики заполнены только у части товаров;

• фотографии имеют разные пропорции и не всегда соответствуют модификации;

• в названиях отсутствуют важные различия;

• в описаниях осталась служебная информация поставщика.

По таким данным нельзя стабильно настроить фильтры, сравнение и автоматическое обновление каталога. Сначала определяют обязательные поля, единицы измерения, допустимые значения и систему, которая будет главным источником информации.

Если ассортимент большой, обработку лучше начать с одной приоритетной категории. На ней можно проверить карточку товара, фильтры и импорт, а затем применить согласованные правила ко всему каталогу.

Красивый интерфейс не исправит каталог, в котором характеристики заполнены по-разному, изображения перепутаны, а остатки не соответствуют учётной системе.

Сократить бюджет можно за счёт количества товаров в первом релизе. Загружать весь ассортимент без проверки исходных данных не стоит. Массовая загрузка только увеличит объём последующих исправлений.

Карточка товара и помощь в выборе

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

Состав карточки зависит от товара, но в большинстве магазинов нужны:

• понятное название;

• актуальная цена;

• наличие или ожидаемый срок поставки;

• фотографии конкретной модификации;

• основные характеристики;

• варианты комплектации;

• условия оплаты и доставки;

• сведения о гарантии;

• совместимые или сопутствующие позиции.

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

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

Мобильное оформление заказа

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

Перед запуском нужно пройти полный сценарий:

1. Открыть категорию.

2. Применить фильтры.

3. Перейти в карточку.

4. Выбрать модификацию.

5. Добавить товар в корзину.

6. Изменить количество.

7. Выбрать доставку.

8. Ввести контактные данные.

9. Оплатить заказ.

10. Вернуться на сайт и получить подтверждение.

Проверку проводят не только в эмуляторе браузера, но и на реальных устройствах. Отдельно тестируют экранную клавиатуру, маску телефона, автозаполнение, подсказки адреса и повторный ввод данных после ошибки.

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

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

Сократить можно количество дополнительных сценариев первого релиза. Проверку основного оформления заказа на телефоне переносить нельзя.

Обмен с 1С или другой системой учёта

Если товары, цены и остатки ведутся в 1С, МойСклад или ERP-системе, до оценки интеграции необходимо определить источник каждого типа данных.

Обычно согласовывают:

• откуда сайт получает товары и характеристики;

• какая система передаёт цены;

• как учитываются несколько складов;

• как часто обновляются остатки;

• куда поступают новые заказы;

• где меняется статус заказа;

• как обрабатываются отмены и возвраты;

• что происходит при неполной или ошибочной выгрузке.

Для обмена между 1С и сайтом может применяться CommerceML. Описание протокола опубликовано на официальном сайте фирмы «1С». Наличие стандартного протокола не означает, что любую существующую базу можно подключить без анализа и подготовки.

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

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

Оплата, доставка, чеки и статусы заказа

Подключённая платёжная форма ещё не означает, что сценарий оплаты работает полностью. До запуска проверяют успешный платёж, отказ, отмену, повторную попытку и возвращение покупателя на сайт.

Также нужно определить:

• когда заказ считается оплаченным;

• как меняется его статус;

• когда резервируется товар;

• что происходит при отмене;

• как рассчитывается доставка;

• какие уведомления получает покупатель;

• куда поступает информация для менеджера;

• как формируется кассовый чек.

Требования к применению контрольно-кассовой техники зависят от деятельности компании и способа расчёта. Актуальные разъяснения необходимо проверять в разделе об онлайн-кассах на официальном сайте ФНС России и согласовывать с бухгалтером или профильным специалистом.

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

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

Скорость работы каталога

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

На производительность влияют:

• структура базы данных;

• количество и логика фильтров;

• программный код;

• кеширование;

• размер изображений;

• сторонние сервисы;

• параметры сервера;

• способ загрузки каталога.

Проверять нужно категории, карточки, поиск и корзину. Google объединяет показатели загрузки, реакции интерфейса и визуальной стабильности в группу Core Web Vitals. Эти данные полезны для диагностики, но автоматическая оценка не заменяет проверку реального сценария покупки.

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

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

Аналитика электронной торговли

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

Минимально полезно отслеживать:

• просмотр списка товаров;

• переход в карточку;

• использование фильтров;

• добавление и удаление товара;

• переход к оформлению;

• выбор доставки;

• начало оплаты;

• успешную покупку;

• стоимость заказа;

• источник перехода;

• устройство пользователя.

Настроенные события сами по себе не меняют показатели магазина. Но показывают, на каком этапе пользователи прерывают оформление и как меняется результат после доработок.

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

Даже при ограниченном бюджете до запуска нужно настроить основные цели и передачу данных о заказах. Иначе оценивать результат придётся по отдельным обращениям и субъективным впечатлениям сотрудников.

Тестирование перед запуском

Проверка магазина не должна ограничиваться открытием страниц и добавлением одного товара в корзину.

До запуска тестируют:

• категории и фильтры;

• карточки разных типов товаров;

• цены и остатки;

• промокоды и скидки;

• оформление на телефоне и компьютере;

• способы оплаты;

• расчёт доставки;

• письма и уведомления;

• передачу заказа в CRM или учётную систему;

• возврат после успешной и неуспешной оплаты;

• права доступа сотрудников;

• технические страницы и ошибки;

• индексацию и основные SEO-настройки.

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

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

Поддержка после запуска

После публикации появляются реальные заказы, устройства и способы заполнения форм, которые трудно полностью воспроизвести до запуска.

Поэтому заранее нужно определить:

• кто контролирует работу форм и оплаты;

• кто обновляет CMS и модули;

• как создаются и проверяются резервные копии;

• кто исправляет ошибки интеграции;

• в какой срок обрабатываются критические обращения;

• кто добавляет новые функции;

• кто отвечает за актуальность каталога.

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

Форматы, состав работ и стоимость сопровождения представлены на странице обслуживания и технической поддержки сайтов.

Что можно перенести на следующий этап

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

В зависимости от модели продаж на следующий этап можно перенести:

• рекомендации на основе поведения;

• бонусную систему;

• расширенный личный кабинет;

• сложные конфигураторы;

• автоматическую интеграцию с маркетплейсами;

• дополнительные способы оплаты;

• часть информационных разделов;

• нестандартную анимацию;

• A/B-тестирование;

• сквозную аналитику.

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

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

Что подготовить для предварительной оценки

Готовое техническое задание для первого обращения не требуется.

Чтобы разделить обязательные работы и последующие этапы, достаточно собрать:

• примерное количество товаров;

• список основных категорий;

• образец выгрузки или таблицы;

• информацию об учётной системе;

• способы оплаты и доставки;

• регионы продаж;

• правила формирования цен;

• необходимость интеграции с CRM;

• примеры подходящих магазинов;

• функции, без которых запуск невозможен.

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

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

Краткий вывод

При ограниченном бюджете интернет-магазин лучше запускать поэтапно. В первый релиз включают подготовленный каталог, основные карточки, мобильное оформление, оплату, доставку, учёт заказов и аналитику. Автоматизацию и дополнительные функции развивают после запуска на основе реальных данных.

Небольшой первый релиз допустим, если в нём стабильно работают поиск товара, оформление, оплата и передача заказа сотрудникам. Большое количество функций не компенсирует неверные остатки, ошибки в каталоге и незавершённые заказы.

Если вы планируете новый интернет-магазин или перерабатываете существующий, изучите условия услуги «Разработка интернет-магазина» и отправьте нам информацию о каталоге, учётной системе, оплате и доставке. Мы разделим обязательные работы и функции следующих этапов и подготовим реалистичный план запуска.

*Материал носит информационный характер. Состав технических, бухгалтерских и юридических требований необходимо определять с учётом бизнес-модели и особенностей конкретного проекта.