Разработка интернет-магазина: каталог, оплата, аналитика и SEO

Сначала опишите модель заказа

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

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

Базовая цепочка выглядит так:

1. Покупатель находит категорию или товар.
2. Выбирает вариант, количество и способ получения.
3. Добавляет товар в корзину.
4. Передает контактные и необходимые для заказа данные.
5. Получает итоговую сумму с учетом доставки и скидок.
6. Выбирает способ оплаты.
7. Магазин получает подтвержденный статус платежа.
8. Заказ передается на сборку, доставку или самовывоз.
9. Покупатель получает уведомления об изменении статуса.
10. Продажа и возврат, если он возник, отражаются в учете и аналитике.

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

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

Определите источник товарных данных

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

Минимальная карта данных включает:

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

Для каждого поля стоит ответить на четыре вопроса:

1. Где оно создается?
2. Кто его меняет?
3. Как быстро обновление попадает на сайт?
4. Что делает магазин, если значение отсутствует или конфликтует с другим источником?

Главный вопрос интеграции - не «можем ли мы передать поле», а «какая система имеет право считать свое значение правильным». Без этого цена, наличие и статус заказа начинают жить в нескольких версиях.

Спроектируйте каталог как инструмент выбора

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

Категории

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

Фильтры

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

Поиск по магазину

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

Карточка товара

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

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

Соберите корзину и оформление вокруг решения покупателя

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

Я бы разделил путь на три слоя.

Состав заказа

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

Получение

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

Контакт и подтверждение

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

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

Оплата должна работать по статусам, а не по странице успеха

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

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

Конкретный набор статусов зависит от провайдера и способа оплаты, но бизнес-сценарии нужно определить заранее:

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

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

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

Интеграции проектируются от ответственности

Интернет-магазин редко работает один. Он обменивается данными с учетной системой, CRM, складом, службой доставки, платежным провайдером, телефонией, рассылками и рекламными площадками.

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

Для каждой связи фиксируются:

1. Какие данные уходят и возвращаются.
2. Какая система запускает обмен.
3. Какой идентификатор связывает объекты.
4. Как часто обновляются данные.
5. Что считается успешной передачей.
6. Кто видит ошибку и что делает дальше.
7. Можно ли безопасно повторить операцию.

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

Аналитика закладывается в сценарий заказа

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

Событийная карта обычно включает:

• просмотр списка товаров;
• выбор товара из списка;
• просмотр карточки;
• выбор варианта;
• добавление и удаление из корзины;
• начало оформления;
• выбор доставки и оплаты;
• завершенную покупку;
• возврат, если он передается в аналитику.

У каждого события должны совпадать идентификатор товара, название, категория, цена, количество и идентификатор заказа там, где он появляется. Тогда отчеты можно связать с реальным ассортиментом и продажами.

Яндекс Метрика принимает данные электронной коммерции через события о взаимодействии с товаром и покупкой; для покупки используется идентификатор, а доход может передаваться в событии. Настройку следует проверить по фактическим действиям до запуска: передача e-commerce данных и проверка электронной коммерции.

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

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

SEO нужно заложить до появления тысяч URL

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

На старте нужно определить:

• какие категории и подкатегории имеют самостоятельный смысл;
• как строятся постоянные URL;
• какие состояния фильтров могут стать посадочными;
• как обрабатываются варианты товара;
• что происходит с временно и окончательно отсутствующими товарами;
• как устроены пагинация и постепенная загрузка;
• какие поля формируют Title, Description, H1 и товарные данные;
• как категории связываются с карточками обычными ссылками;
• как создается Sitemap и обновляются товарные фиды.

Google рекомендует строить доступную ссылочную цепочку от меню к категориям, подкатегориям и карточкам. Если товары доступны только через внутренний поиск, робот может их не обнаружить. Sitemap и Merchant Center дополняют, но не заменяют ссылки из каталога: структура e-commerce сайта в Google Search Central.

Для товарных страниц Google поддерживает structured data Product, включая цену, наличие и варианты, но эти данные должны соответствовать видимой странице. Разметка проектируется из тех же товарных полей, а не создается отдельной копией: документация Google по Product.

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

Админка должна поддерживать ежедневную работу

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

До выбора CMS или собственной разработки составьте список регулярных действий:

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

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

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

Разделите разработку на проверяемые этапы

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

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

Как принять магазин перед запуском

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

Я бы включил в приемку минимум следующие проверки:

1. Товар находится через категорию, фильтр и внутренний поиск.
2. Цена, вариант и остаток одинаковы в карточке, корзине и заказе.
3. Пересчет количества, скидки и доставки дает ожидаемую сумму.
4. Заказ создается только один раз при повторном нажатии или запросе.
5. Успешная, ожидающая и отмененная оплата меняют заказ по согласованным правилам.
6. Заказ передается в учетную систему или очередь менеджера.
7. Покупатель получает корректное уведомление.
8. E-commerce события содержат товары, сумму и идентификатор заказа.
9. Приоритетные категории и карточки доступны по обычным ссылкам.
10. Сотрудник может обработать заказ, ошибку и возврат через предусмотренный процесс.
11. Мобильная версия позволяет пройти покупку без скрытых действий.
12. Команда знает, кто реагирует на сбой оплаты, обмена, остатков или доставки.

Google описывает несколько моделей запуска e-commerce сайта, включая полный и мягкий запуск. Для бизнеса практичен мягкий режим: полностью готовая цепочка открывается на ограниченном потоке, а маркетинговое усиление начинается после проверки реальных операций. Официальные варианты собраны в руководстве Google по запуску e-commerce сайта.

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

От чего зависит стоимость разработки

Количество страниц слабо объясняет бюджет интернет-магазина. Основную сложность создают товарная модель и операции.

На оценку влияют:

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

Корректная смета появляется после описания этих решений. Фраза «интернет-магазин под ключ» сама по себе не определяет объем: для одного бизнеса это небольшой каталог с ручной обработкой, для другого - несколько складов, тысячи вариантов и автоматический обмен.

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