Разработка
ТЗ на каталог товаров: варианты, фильтры, поиск и импорт
Требования к каталогу: модель товара, атрибуты, варианты, поиск, карточки, обновление и SEO. Контрольный набор и бриф для скачивания.

Каталог начинается с модели товара
Каталог товаров помогает найти подходящую позицию и понять её свойства, наличие и следующий шаг. Это может быть покупка, запрос цены или обращение к менеджеру. До проектирования экранов нужно определить модель ассортимента: чем товар отличается от варианта, предложения поставщика и комплекта. Иначе визуально аккуратная витрина скрывает путаницу в данных.
ТЗ на каталог описывает структуру категорий, атрибуты, поиск, карточки, импорт и жизненный цикл позиций. Оно отличается от ТЗ на интернет-магазин: корзина и оплата могут вообще не входить в задачу. Сначала зафиксируйте конечное действие и границы системы, затем добавляйте функции, которые действительно нужны для выбора.
Товар, вариант и предложение
Представьте одну модель лампы в нескольких цветах. Общее описание относится к модели, а конкретный цвет может иметь собственный артикул, фотографию, цену и остаток. Если всё хранится в одной строке без связей, фильтр покажет доступным вариант, которого нет. Для каждого уровня задайте устойчивый идентификатор и правила наследования свойств.
Уточните наборы и совместимость. Комплект может иметь собственную цену и одновременно зависеть от наличия компонентов. Запасная часть может подходить только к определённым моделям и версиям. Такие связи нельзя надёжно заменить текстом в описании, если по ним строится поиск. Опишите, кто создаёт связи и как проверяется их полнота.
Для каждого атрибута укажите тип, единицу, допустимые значения и обязательность по категории. Размер в миллиметрах и сантиметрах требует нормализации, а материал — согласованного справочника. Свободное текстовое поле удобно для ввода, но часто разрушает фильтрацию. При этом не все свойства нужно превращать в фильтр: выбирайте признаки, которыми человек действительно пользуется для сравнения.
Категории и фильтры
Структура должна отражать способ выбора, а не внутреннюю организацию склада. Проверьте её на нескольких типовых заданиях: найти конкретный артикул, выбрать по характеристике и подобрать совместимую позицию. Если товар может встречаться в нескольких разделах, укажите правила навигации и основного адреса. Дублирование карточек не должно создавать независимые расходящиеся записи.
Для фильтра задайте тип выбора, сочетание нескольких условий, порядок, поведение пустого результата и сохранение состояния в URL. Покупатель должен понимать, какие ограничения включены и как их сбросить. Укажите, показываются ли недоступные значения и почему. При изменении одного фильтра остальные должны пересчитываться согласованно с фактическим набором товаров.
Сортировка требует определения. «Популярное» может означать просмотры, покупки или редакционный выбор — это разные правила. Для отсутствующих данных предусмотрите порядок по умолчанию. Не делайте вид, что каталог знает объективную популярность, если статистика не собирается. Название сортировки должно соответствовать тому, что система действительно вычисляет.
Поиск по реальным запросам
Соберите обезличенные примеры запросов: название, артикул, сокращение, ошибка ввода и синоним. Для каждого выберите ожидаемый набор или допустимый первый результат. Особенно важно определить нормализацию артикулов: пробелы, дефисы и похожие символы могут иметь значение. Не объединяйте разные позиции только потому, что их обозначения визуально близки.
Опишите поиск без результатов, подсказки и предложение альтернатив. Альтернатива должна объяснять отличие, если это важно для совместимости. Для точного артикула уместнее показать отсутствие, чем уверенно подставить неподходящий товар. Согласуйте, какие сведения можно искать публично и какие доступны только клиентам с договором.
Приёмка поиска строится на контрольном наборе, а не на демонстрации одного удачного запроса. Разделите точное нахождение, подбор и исследовательский поиск. Для каждого типа проверьте релевантность и возможность продолжить действие. Скорость измеряйте на реалистичном объёме данных и согласованной нагрузке, иначе результат пустого тестового каталога ничего не говорит о рабочем.
Состав карточки и честные состояния
Зафиксируйте обязательные сведения: название, изображения, характеристики, варианты, условия наличия и целевое действие. Для отсутствующей цены нужен понятный сценарий запроса, если он предусмотрен бизнесом. Не отображайте нулевую цену вместо неизвестной. Дата актуальности может быть важна, если сведения приходят по расписанию и не подтверждаются в реальном времени.
Изображения должны относиться к выбранному варианту или явно показывать общий вид модели. Требуются правила порядка, размера, кадрирования и альтернативного текста. При отсутствии фотографии предусмотрите осмысленное состояние, а не случайную картинку из другой категории. Проверьте длинные названия и характеристики, чтобы карточка сохраняла понятную иерархию.
Опишите снятый с продажи товар, временное отсутствие и позицию под заказ. Это разные состояния с разными обещаниями. Срок поставки нельзя выводить из пустого поля как подтверждённый. Если карточка уже имеет внешние ссылки, решение о её удалении принимается вместе с правилом адреса и подходящей заменой, а не только из желания убрать товар из выдачи.
Импорт и ответственность за данные
Назначьте владельца каждого поля: учётная система, PIM, поставщик или редактор. Опишите, какие ручные изменения переживают следующий импорт, а какие перезаписываются. При нескольких источниках нужен приоритет и журнал конфликтов. Иначе редактор будет исправлять одно и то же описание после каждого обновления, не понимая причины.
Пример импортного файла должен включать корректную запись, отсутствующее обязательное поле, неверную единицу, повтор артикула и вариант без родителя. Система должна выдавать понятный отчёт и не публиковать повреждённые данные незаметно. Решите, отклоняется весь пакет или отдельные строки; частичный результат должен быть явно обозначен и воспроизводим.
Обновление цены и остатка требует правил свежести и отказа. Если источник недоступен, каталог может сохранить последнее подтверждённое значение с допустимой пометкой либо ограничить действие — это решает бизнес. Нельзя выдавать устаревшие данные за только что проверенные. Для критических обновлений предусмотрите сверку количества и выборочную проверку значений после загрузки.
SEO для вариантов и навигации
Определите, какие категории и карточки имеют самостоятельное содержание и должны индексироваться. Отдельно опишите параметры сортировки, фильтры, пагинацию и варианты. Canonical, внутренние ссылки и sitemap должны поддерживать выбранную модель. Не объявляйте все комбинации фильтров посадочными страницами без полезного содержания и управляемого жизненного цикла.
Если используете структурированные данные товара и вариантов, они должны соответствовать видимым сведениям. Документация Google описывает отдельные возможности для групп товаров; применять их следует по реальной модели каталога. Разметка не заменяет корректную цену, доступность и понятную карточку. Нельзя добавлять выдуманные отзывы или наличие ради привлекательного вида в поиске.
Проверьте постоянные URL и изменения названий. Новый заголовок не должен бесконтрольно создавать новый адрес и терять старые ссылки. Для переименования, объединения и удаления задайте процедуру с ответственным. Каталог — живые данные, поэтому требования должны работать после десятого импорта, а не только в день запуска.
Набор приёмки и шаблон ТЗ
Подготовьте небольшой, но разнообразный набор: простой товар, модель с вариантами, комплект, отсутствующая позиция и длинное описание. Пройдите импорт, поиск, фильтр, выбор варианта и целевое действие. Затем измените цену одного варианта и удалите другой из источника. Убедитесь, что результат соответствует правилам обновления и не повреждает соседние товары.
Сравните поиск по артикулу и подбор по характеристикам на телефоне и компьютере. Проверьте клавиатуру, читаемость выбранных фильтров и возврат к списку. Зафиксируйте ожидаемые значения, фактический результат и версию данных. Ошибка связи варианта с ценой важнее косметической неточности отступа и должна блокировать соответствующий сценарий запуска.
В приложении доступен текстовый бриф с моделью товара, словарём полей и приёмочными заданиями. Для оценки передайте его вместе с примером реального обезличенного экспорта. Количество карточек важно, но сложность часто определяют связи, качество атрибутов и число источников. Полезный каталог начинается с согласованной модели, которую можно проверить на конкретных товарах.
Источники
- Product variants structured data
Google Search Central / доступ 2026-10-07
Структурированные данные для реальных групп товаров и вариантов.
- Consolidate duplicate URLs
Google Search Central / доступ 2026-10-07
Первичная документация о канонических сигналах и дублирующихся URL.
- Скачать шаблон брифа / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-07
Заполняемый авторский шаблон к этой статье. Сохраните текстовый файл и внесите исходные данные проекта.
FAQ
Нужна ли каталогу корзина?
Только если покупка входит в задачу. Каталог может завершать путь запросом цены или обращением к менеджеру; это фиксируется до оценки.
Как хранить варианты одного товара?
Нужно определить общий уровень модели и отдельные варианты с устойчивыми идентификаторами, ценами и остатками, если эти свойства различаются.
Можно ли публиковать весь импорт сразу?
После предусмотренной проверки обязательных полей и связей. Ошибочные строки должны блокироваться или попадать в явно обозначенный карантин.

