Пока товаров меньше пятидесяти, магазин — это задача дизайна. Всё помещается на два экрана, по каталогу удобно ходить, и хорошая вёрстка вытягивает весь опыт покупателя.
Дальше происходит перемена, которую большинство владельцев так и не называют вслух: покупатель перестаёт сталкиваться с вашим дизайном и начинает сталкиваться с вашими данными.
Он вводит запрос в строку поиска и не получает ничего. Фильтрует по размеру — и половина ассортимента исчезает, потому что у двенадцати товаров этот атрибут так и не заполнили. Находит одну и ту же книгу три раза, потому что она есть в твёрдой обложке, в мягкой и в аудиоверсии. Попадает на страницу с надписью «в наличии», хотя на складе этого товара нет уже месяц.
Ни одна из этих проблем не про дизайн. Каждая стоит вам продажи, и ни одна не отображается в аналитике иначе как уход с сайта.
Налог на пустую выдачу
Вот цифра, которую ни один магазин из тех, что мы проверяли, не смог назвать по запросу: какой процент поисковых запросов на сайте ничего не находит?
Измерить это элементарно — всё уже есть в логах поиска, — и это одна из самых информативных цифр в бизнесе. Поиск без результатов — это клиент, который своими словами сказал вам, что именно хочет купить, и ушёл.
Рядом и точно так же не измеряется другое: как часто клиент ищет, получает результаты и не нажимает ни на один? Это провал релевантности, а не охвата, и обычно он хуже, потому что приучает клиента к мысли, что ваш поиск не работает.
Вместе они образуют налог, который целиком платят люди с намерением купить. А отсюда неприятное следствие второго порядка:
Плохой поиск не просто теряет продажи. Он меняет то, что люди покупают. Когда поиск не срабатывает, покупатели откатываются к просмотру категорий и сортировке по цене — потому что цена единственный атрибут, который всегда заполнен и всегда сравним. Вы не просто потеряли конверсию. Вы незаметно перенастроили магазин на свои самые дешёвые товары.
Это проблема маржи, которая притворяется технической.
Пять показателей здоровья каталога
Ни один из них не требует платформы. Все они требуют, чтобы кому-то было не всё равно.
1. Доля пустых выдач. Процент поисковых запросов на сайте, которые ничего не нашли. Всё, что выше 5%, — открытая рана. Читайте сами запросы: это бесплатный список товаров, которые вам стоит завезти, и синонимов, которые стоит добавить.
2. Заполненность атрибутов с учётом выручки. Не «какой процент полей заполнен», а «какой процент полей заполнен у ста товаров, приносящих больше всего выручки». Магазин может быть заполнен на 80% в целом и на 40% — во всём, что имеет значение.
3. Схлопывание дублей и вариантов. Одна вещь из реального мира — это одна запись, под которой собраны её форматы и издания? Если один и тот же товар встречается трижды, вы делите его отзывы, оценки, релевантность в поиске и остатки между тремя более слабыми записями.
4. Задержка актуальности. Сколько времени проходит между тем, как меняется реальность — цена, остаток, снятие с производства, — и тем, как это отражается на витрине. Измеряйте в часах, и измеряйте худший случай, а не средний.
5. Покрытие синонимов. Возьмите двадцать фраз, которые реально используют покупатели, включая опечатки и второй язык, на котором они могут писать, и поищите каждую в своём магазине. Посчитайте провалы.
Как выглядит правильная модель данных
Пример — потому что здесь абстракции перестают помогать.
Knigopoisk — русскоязычный книжный магазин, в каталоге которого заявлено более 11 000 книг. Исходная модель считала каждую продаваемую позицию товаром. Это работает, пока одно произведение не выходит электронной книгой, в мягкой обложке и аудиокнигой — и тогда одно и то же название превращается в три не связанные друг с другом записи с тремя наборами отзывов, тремя рейтингами и тремя шансами оказаться той самой, которую покупатель так и не найдёт.
В 2026 году мы перестроили его в модель Книга → Издание → Товар через поэтапные миграции: новый слой данных с дозаполнением, переключение владения данными, публичный API, переведённый на товары, и, наконец, новая консоль каталога в админ-панели. Теперь у одного произведения может быть несколько изданий и форматов без дублирования записей.
Из этого стоит вынести две вещи.
Это делалось поэтапно, а не одним большим переключением. Перестройка каталога в работающем магазине — самое рискованное изменение из всех возможных. Каждый этап выходил отдельно, и его можно было остановить.
Консоль в админ-панели была последним шагом, а не первым. Инстинктивно хочется начать с перерисовки экранов. Но экраны — следствие модели; если поменять их первыми, в неправильную модель просто станет удобнее вбивать данные.
Три модели данных и как понять, какая нужна вам
Почти любая проблема каталога восходит к тому, что в самом начале выбрали не ту из них — когда выбор был бесплатным и никто не обращал на него внимания.
Модель A — плоский список. Одна строка на каждую продаваемую вещь. Подходит, когда каждая позиция действительно уникальна: искусство, антиквариат, услуги без настроек, штучный товар. Ломается в тот момент, когда одна и та же вещь появляется в двух размерах.
Модель B — товар с вариантами. Один товар, много вариантов для покупки по заданным осям (размер, цвет, объём). Подходит для большей части розницы. Дисциплина, которой она требует, — оси должны быть объявлены: «размер» — это измерение с известными значениями, а не произвольный текст, который вписывают в каждый товар. Ломается в тот момент, когда одно и то же произведение выходит в форматах, которые не варианты друг друга, а совершенно разные вещи: книга в твёрдой обложке и аудиокнига — это не два размера одного предмета.
Модель C — произведение, издание, товар. Абстрактное произведение; его издания; товары для покупки внутри каждого издания. Подходит для книг, музыки, кино, курсов, лицензий на софт — для всего, где есть переводы, форматы или региональные версии. Стоит дороже на старте, и внедрить её задним числом почти невозможно, когда отзывы, оценки и заказы уже привязались не к тому уровню.
Тест, который решает выбор одним вопросом: если покупатель оставляет отзыв, о чём этот отзыв? Если о самой истории, а не о книге в мягкой обложке, вам нужна модель C, потому что отзыв принадлежит произведению и должен быть виден в каждом его издании. Ошибитесь здесь — и вы сами размажете свои социальные доказательства по трём карточкам. Именно эту проблему и решала перестройка Knigopoisk.
И ещё одно правило, усвоенное дорогой ценой и применимое ко всем трём моделям: никогда не пускайте в модель вопросы отображения. «Рекомендуемое», «баннер на главной», «плашка распродажи» — это состояния показа, а не атрибуты товара. В тот день, когда они поселятся в карточке товара, ваш каталог начнёт хранить в себе прошлогоднюю маркетинговую кампанию, и никто никогда не решится это удалить.
Когда данные приходят извне
Если каталог наполняется от поставщиков, из фидов или через API, проблема умножается: теперь вы не просто поддерживаете данные, а разбираете разногласия между источниками.
Finkonkurs — крайний случай: платформа рыночных данных, где слой скраперов запускает более 120 классов скраперов для более чем 40 поставщиков — от API рыночных данных до страниц с объявлениями бирж. Архитектурное решение, которое делает это управляемым, простое и подходит всем:
Всё сначала попадает в одну таблицу сырых данных — с дедупликацией по SHA-256 и отпечатком схемы, — и только потом что-то может стать фактом на странице. Преобразование в доменные модели происходит после, через более чем 50 отдельных классов-трансформеров, которые читают из представления только для чтения.
Правило, которое за этим стоит: никогда не позволяйте внешнему источнику писать напрямую в то, что читает ваша витрина. Сырые данные на вход, преобразование, потом публикация. Когда поставщик в три часа ночи поменяет формат, отпечаток схемы это поймает, и пайплайн громко упадёт, вместо того чтобы молча испортить ваши цены.
Та же логика стоит за правилом в нашем ИИ-пайплайне контента для той же платформы: запуск, который упёрся в лимит запросов, в нехватку средств на счету или вернул пустоту, падает с указанием причины, а не публикует заглушку поверх существующего описания. А изменчивые значения вроде места монеты в рейтинге или комиссии биржи вообще не попадают в сгенерированный текст: они хранятся как токены [[ placeholder ]], которые бэкенд подставляет из живых данных в момент просмотра страницы. Сгенерированный текст устаревает. Подставляемые данные — нет.
Поиск — это инфраструктура, а не функция
Ещё одно архитектурное замечание, потому что оно определяет, что будет возможно потом.
В Bronjoy — 23 727 заведений на сентябрь 2026 года — поиск работает на Meilisearch, а не на запросах к базе данных, и он находит совпадения и на латинице, и на кириллице, потому что клиент в Узбекистане может написать название одного и того же заведения и так и так. Словарь каталога — услуги, удобства, способы оплаты — переведён один раз в общий словарь и подставляется при каждом запросе, а не хранится отдельно у каждого заведения. А у заведений есть история слагов, так что старый URL переименованного заведения по-прежнему ведёт на его актуальную страницу.
Каждое из этих решений почти невозможно внедрить задним числом и почти бесплатно заложить сразу. Это общий принцип работы с каталогом: дорогие решения — ранние, и все они про модель, а не про интерфейс.
Что это значит для вашего следующего проекта
Если вы планируете редизайн, а каталог у вас действительно большой, честная последовательность такая:
- Исправьте модель — одна вещь, одна запись, варианты под ней
- Заполните атрибуты у товаров, которые приносят деньги
- Исправьте поиск — охват, синонимы и долю пустых выдач
- Исправьте актуальность — насколько быстро реальность доходит до страницы
- И только потом делайте редизайн
Если сделать всё в обратном порядке, получится красивый магазин, который по-прежнему не может найти собственные товары, — самый частый дорогой исход в электронной коммерции.
Кроме того, теперь это обязательное условие для следующего канала: ИИ-агент для покупок читает ваши атрибуты, наличие и итоговые суммы — и больше ничего. Об этом мы пишем в статье «Когда покупатель — программа».
Наши интернет-магазины начинаются с коммерческой модели — товары, варианты, цены, правила доставки и налогов прорабатываются до того, как что-либо рисуется, — от $499, срок — 1–5 недель. Каталогам, которые полностью переросли готовые платформы для магазинов, обычно нужны скорее веб-приложения под ключ, и мы так и скажем.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Насколько большим должен быть каталог, чтобы это стало важно?
Примерно тогда, когда покупатель уже не может увидеть всё, что вы продаёте, за две минуты прокрутки. На практике это где-то от пятидесяти до нескольких сотен позиций — и раньше, если у товаров есть варианты.
Можно ли исправить поиск, не трогая данные?
Частично. Хороший поисковый движок справляется с опечатками, словоформами и синонимами, и это возвращает заметную долю пустых выдач. Но он не может выдумать атрибут, который никто не заполнил, и не может слить три дублирующие записи в одну. Инструменты поднимают потолок, а данные его определяют.
Нужна ли для этого headless-архитектура?
Не обязательно, но она помогает по конкретной причине: отделяет каталог от его отображения, поэтому одни и те же данные могут питать витрину, приложение, виджет партнёра и интерфейс для агентов без перестройки каждый раз. Настоящий аргумент в пользу headless — именно эта гибкость, а не скорость.
Кто внутри компании должен отвечать за каталог?
Один конкретный человек с правом отклонять плохие данные поставщиков. Каталоги деградируют, когда ответственность разделена между мерчандайзингом, операционным отделом и IT, потому что каждый из них считает, что заполненность проверяет кто-то другой.
Какое улучшение самое дешёвое для начала?
Включите логирование поиска, если оно выключено, и прочитайте за неделю запросы, которые ничего не нашли. Это полдня времени, никакой разработки — и список конкретных исправлений, который стоит больше большинства редизайнов.
