В такой ситуации полезно проверить, какие данные получает поиск. Хорошее описание помогает человеку разобраться в товаре. Для фильтрации нужны ещё и согласованные свойства, по которым система сможет сравнивать модели.
Начинать стоит со схемы характеристик – перечня полей для категории и правил их заполнения. Она определяет, какие сведения собирать, как хранить значения, какие единицы использовать и что делать с пропусками. Разберём эту задачу на небольшом каталоге и покажем порядок внедрения перед массовым наполнением карточек.
Почему заполненные карточки могут плохо работать в поиске
На странице товара могут одновременно присутствовать название, длинный текст и таблица параметров. Но поисковая система магазина не обязательно использует всё, что видит посетитель. Она получает определённый набор полей из CMS, выгрузки или отдельной базы. Для работы фильтров эти поля должны быть подключены к соответствующим условиям отбора.
Поэтому проверка начинается с конкретного запроса. Найдите товар, который должен ему соответствовать, и проследите путь нужной характеристики – исходник поставщика, запись каталога, поисковый индекс, фильтр и результат на экране.
Если в карточке указаны два литра, а в поисковой записи объём отсутствует, ошибка находится между карточкой и индексом. Если в индексе хранится строка «2 л», а фильтр ожидает число, нужно проверить тип данных и преобразование. Если данные корректны, переходите к настройкам фильтра, категории, доступности товара и обновления индекса.
Точно так же отдельно проверяют текстовый поиск. Он может учитывать название и описание, а фильтр – только структурированные свойства. Исправление одного набора настроек не подтверждает исправление другого.
Что исследование BEATS добавляет к работе с каталогом
В исследовании BEATS, представленном на SIGIR 2026, команда Rakuten и Национального университета Тайваня описала создание схем характеристик с помощью языковых моделей и экспертной проверки. После согласования схемы значения присваивали отдельным товарам.
Внедрение в Rakuten Taiwan охватило девять крупных категорий и более 5,4 млн товаров. В эксперименте с поисковой моделью Recall@10 вырос с 66,6 до 70,4% – на 3,8 процентного пункта. Показатель отражает полноту нахождения релевантных товаров среди первых десяти результатов. Он не измеряет рост продаж или позиций Google.
Для практической работы полезно само разделение задач. Сначала определяют подходящие свойства категории, затем заполняют их у товаров. Проверка специалистом помогает отсечь неверные и неоднозначные предложения автоматизации.
+3,8 процентного пунктаПолнота поиска в эксперименте BEATS. Показатель не описывает продажи или позиции Google.
Разберите одну категорию перед массовым заполнением
Выберите категорию, где есть заметный ассортимент, повторяющиеся параметры и понятные критерии выбора. Для первого разбора подойдут, например, бытовые пылесосы одного назначения. Не стоит сразу смешивать с ними роботы-пылесосы, промышленные установки и расходные материалы.
Соберите представительную выборку. Включите товары разных поставщиков, записи с полными и неполными характеристиками, спорные единицы и варианты комплектации. Начальные 50–100 товаров могут помочь обнаружить типовые ошибки, но такой объём сам по себе не подтверждает качество всего каталога.
Одновременно подготовьте покупательские сценарии. «С контейнером от двух литров», «для сухой уборки», «на аккумуляторе», «с определённым классом фильтра» – это разные условия. Каждое нужно связать с полем или набором полей, которые действительно подтверждают соответствие.
Полезный результат этого этапа – список задач покупателя, необходимых свойств и доступных источников данных. На его основе уже можно обсуждать схему с разработчиком и человеком, который отвечает за ассортимент.
Пример каталога из шести товаров
Ниже условные модели и записи. Пример показывает логику проверки; это не статистика работающего магазина.
Какие товары потерял фильтр?
В этой мини-витрине шесть условных товаров из таблицы. Переключите обработку данных и посмотрите, какие модели проходят одинаковые условия.
Учебный обработчик читает только точные поля «Тип пылесборника», «Объём пылесборника» и числовую мощность в ваттах.
Подтверждённо подходят 1 из 6 – A-101. У 3 недостаточно данных; 2 не соответствуют условиям.
Контейнер, 2 л.
Исходный обработчик не сопоставил названия полей.
Мешок вместо контейнера.
Объём 1,5 л меньше выбранного порога.
Исходный обработчик не сопоставил названия полей.
Объём не указан в исходных данных.
Учебный пример не подключён к магазину и не оценивает потери продаж. Подходящие модели определяются только подтверждёнными значениями. Исходные записи и пояснения приведены ниже.
| Модель | Как записан тип | Как записан объём | Потребляемая мощность |
|---|---|---|---|
| A-101 | Тип пылесборника – контейнер | Объём пылесборника – 2 л | 700 Вт |
| B-102 | Пылесборник – контейнер | Объём контейнера – 2500 мл | 0,8 кВт |
| C-103 | Тип пылесборника – мешок | Объём пылесборника – 3 л | 750 Вт |
| D-104 | Тип пылесборника – контейнер | Объём пылесборника – 1,5 л | 600 Вт |
| E-105 | Пылесборник – контейнер | Ёмкость контейнера – 2 л | Не указана; отдельно есть разрежение 24 кПа |
| F-106 | Тип пылесборника – контейнер | Объём не указан | 650 Вт |
Предположим, исходный фильтр читает только поля «Тип пылесборника» и «Объём пылесборника» и ожидает объём в литрах. Для условия «контейнер от двух литров» он находит A-101. Подходящие B-102 и E-105 пропускаются, потому что нужные значения находятся под другими названиями.
После подтверждённого сопоставления полей и приведения единиц условию соответствуют A-101, B-102 и E-105. C-103 имеет другой тип пылесборника, D-104 – меньший объём. Для F-106 соответствие по объёму установить нельзя, пока данных недостаточно.
Добавим требование «потребляемая мощность не выше 800 Вт». Тогда подтверждённо подходят A-101 и B-102. E-105 нельзя считать прошедшим проверку мощности – разрежение 24 кПа не определяет потребляемую электрическую мощность.
Результат меняется по конкретной причине – система получает сопоставимые сведения. В этом примере не требуются предположения о росте продаж или замена всех описаний товаров.
Как составить схему характеристик категории
Для каждого свойства зафиксируйте устойчивый технический код, понятное название, смысл, тип значения, единицу и правила применимости. Отдельно укажите источник, способ проверки и назначение поля в интерфейсе.
Название для покупателя можно менять или переводить. Технический код должен сохранять связь с одним и тем же свойством. Иначе переименование «объём контейнера» в «ёмкость пылесборника» рискует превратиться для интеграции в создание нового поля.
| Код поля | Назначение | Тип значения | Пример правила |
|---|---|---|---|
| dust_collection_type | Тип пылесборника | Значение из справочника | container, bag и другие согласованные варианты |
| dust_capacity_l | Полезный объём пылесборника | Число в литрах | Значение относится именно к пылесборнику выбранной комплектации |
| input_power_w | Потребляемая электрическая мощность | Число в ваттах | Не смешивать с разрежением и мощностью всасывания |
| power_source | Источник питания | Значение из справочника | Сеть, аккумулятор или подтверждённый комбинированный вариант |
| runtime_min | Время работы от аккумулятора | Число в минутах | Хранить вместе с указанным режимом измерения |
| filter_grade | Подтверждённый класс фильтра | Значение из справочника | Обозначение HEPA само по себе не подтверждает H13 |
Таблица задаёт основу обсуждения, а не универсальный набор для любого магазина. Состав свойств зависит от категории, ассортимента и покупательских задач.
Справочник значений тоже требует управления. Одному коду можно сопоставить русское и украинское название, принятые сокращения и подтверждённые варианты записи поставщиков. При этом внешне похожие слова нельзя автоматически считать одинаковыми характеристиками.
Родительская категория может задавать общие поля – бренд, модель, источник питания. Подкатегория добавляет свои характеристики и правила применимости. Наследование схемы не означает, что у всех товаров автоматически появляются одинаковые значения.
Особенно внимательно проверяйте модификации и комплекты. Если время работы зависит от аккумулятора, значение должно относиться к конкретному продаваемому варианту и режиму. Перенос максимального значения из описания всей серии в каждую карточку создаёт ложную точность.
Как привести единицы и названия к общим правилам
Для каждого числового свойства выберите единицу хранения. В нашем примере 2500 мл превращаются в 2,5 л, а 0,8 кВт – в 800 Вт. Исходную запись сохраните отдельно, чтобы преобразование можно было проверить.
| Исходная запись | Действие | Результат |
|---|---|---|
| Объём контейнера – 2500 мл | Проверить смысл поля и перевести миллилитры в литры | dust_capacity_l = 2,5 |
| Потребляемая мощность – 0,8 кВт | Перевести киловатты в ватты | input_power_w = 800 |
| Мощность – 24 кПа | Уточнить назначение исходного показателя | Не заполнять input_power_w этим значением |
| Система – циклонная | Проверить отдельное свойство технологии отделения пыли | Не подменять без подтверждения тип пылесборника |
| HEPA-фильтр | Сохранить подтверждённое обозначение | Не добавлять класс H13 по предположению |
Объединять поля можно после проверки смысла. «Объём бака» у моющего пылесоса может обозначать резервуар чистой воды, грязной воды или пылесборник. Совпадающая единица измерения ещё не делает эти параметры одним свойством.
Отдельно задайте правила обработки десятичных разделителей, пробелов и сокращений. Строка «0,8 кВт» из русскоязычного документа и числовое значение 0.8 в JSON используют разное представление. Преобразование должно учитывать формат источника и проверять полученное число.
Для фильтра «от двух литров» нужно сравнение чисел. Поле с красивой подписью «2 л» не гарантирует такого поведения. Проверьте, что поисковая запись содержит числовое значение, единица согласована, а настройка диапазона использует именно это поле.
Как отличать неизвестное значение от отсутствия свойства
Пустое поле нельзя автоматически заменять нулём или ответом «нет». Иначе товар с неизвестной мощностью может ошибочно пройти условие «не выше 800 Вт», а отсутствие сведений о функции превратится в утверждение, что функции нет.
Удобно разделять значение и состояние его проверки.
| Состояние | Что известно | Как обрабатывать |
|---|---|---|
| Подтверждено | Есть проверенное значение для нужной модели | Использовать по согласованным правилам поиска и фильтрации |
| Неизвестно | Свойство применимо, но сведений недостаточно | Не присваивать 0, false или случайный вариант |
| Не применимо | Свойство не относится к этому типу товара | Исключать из расчёта применимых характеристик |
| Конфликт | Источники или записи противоречат друг другу | Направлять на проверку до использования спорного значения |
В JSON значение null, отсутствие поля, число 0 и логическое false различаются. Но одного null недостаточно, чтобы объяснить причину пропуска. Поэтому состояние «неизвестно», «не применимо» или «конфликт» полезно хранить отдельно в основной системе данных.
Товар с неизвестным объёмом не подтверждает соответствие выбранному диапазону. В строгой выдаче по этому условию его исключают. Если интерфейс показывает отдельную группу «объём уточняется», она должна явно отличаться от товаров, которые прошли фильтр.
Как использовать ИИ для подготовки характеристик
Начинайте с определения полей для категории. Специалист по ассортименту проверяет, какие параметры помогают выбирать товар, какие дублируют друг друга и какие относятся к соседнему типу оборудования. После этого утверждаются коды, определения и примеры ошибок.
На следующем этапе ИИ может извлекать значения из разрешённых источников и сопоставлять их с утверждёнными полями. Для каждой записи полезно возвращать исходный фрагмент, ссылку на документ или страницу, предлагаемое значение и причину сомнения.
Далее работают проверки по правилам. Они контролируют тип, единицу, допустимые значения, применимость, наличие источника и конфликты. Уверенная формулировка модели не заменяет подтверждение характеристики.
Неподтверждённые свойства остаются в очереди проверки. Если по фотографии или названию нельзя установить объём, класс фильтра либо комплектацию, поле не заполняют догадкой. Для изменяющихся сведений дополнительно сохраняют дату проверки источника.
Когда схема утверждена, можно подключать автоматизированную подготовку карточек товаров из файлов поставщиков. В таком процессе понятны и цель обработки, и условия, при которых запись разрешено передать дальше.
Какие поля подключать к поиску и фильтрам
Не каждую характеристику нужно показывать отдельным фильтром. Для части полей полезен числовой диапазон, для других – короткий справочник вариантов. Некоторые сведения достаточно оставить в таблице характеристик или использовать только в текстовом поиске.
Оцените заполненность, сопоставимость, количество разных значений и понятность признака покупателю. Поле «дополнительные особенности» с сотнями свободных формулировок обычно требует разбора перед превращением в список вариантов выбора.
Для поиска по запросу «пылесос с контейнером от двух литров» мало создать поля. Система должна распознать смысл запроса, нужное свойство и числовое условие. Для фильтра, который посетитель включает вручную, отдельно проверяют сопоставление элемента интерфейса с полем индекса.
После изменения основной базы может потребоваться обновление поискового индекса и сброс соответствующего кэша. Проверяйте версию данных и время обновления – иначе исправленные характеристики останутся в CMS, а покупатель продолжит видеть прежний результат.
Также согласуйте единицу подсчёта результатов. Если выдача объединяет несколько вариантов в одну модель, количество карточек и количество SKU могут различаться. Покупатель должен видеть непротиворечивые числа при выборе параметров и переходе к конкретному доступному варианту.
Улучшение свойств каталога и правила индексации фильтров – разные уровни работы. Полезный покупателю фильтр не обязан создавать новую индексируемую страницу для каждой комбинации.
Решения по URL, canonical, обходу и посадочным страницам нужно принимать отдельно. Этот вопрос разобран в материале как фильтры создают тысячи лишних адресов интернет-магазина.
Что включить в задание разработчику
Передайте определение каждого поля и правила его использования. Разработчику нужны не только названия, но и проверяемые условия, по которым можно принять результат.
Для числовых значений задайте достаточную точность хранения и проверьте преобразование при передаче в поисковую систему. При замене справочника заранее определите, как будут сопоставлены старые значения и сохранённые настройки фильтров.
Как проверить изменения на контрольной выборке
Сохраните исходную выгрузку и результаты контрольных запросов. Затем подготовьте исправленную версию одной категории, проверьте её на тестовом индексе или площадке и сравните с исходным состоянием.
Ожидаемые результаты нужно определить заранее по документам и свойствам товара. Иначе команда рискует принять любой новый список выдачи за улучшение.
| Проверка | Что должно произойти |
|---|---|
| Контейнер от двух литров в учебном каталоге | Подходят A-101, B-102 и E-105 |
| То же условие плюс мощность не выше 800 Вт | Подтверждённо подходят A-101 и B-102 |
| У товара F-106 нет объёма | Значение остаётся неизвестным; товар не объявляется прошедшим диапазон |
| У E-105 указано разрежение 24 кПа | Это значение не попадает в поле потребляемой мощности |
| Повторно обработана та же исходная запись | Не создаются новые товары и дубли свойств |
| Обновлены характеристики в CMS | Проверяемая версия значений появляется и в поисковом индексе |
В реальной выборке дополнительно проверяйте отсутствие подходящих товаров, комбинации с нулевым результатом, варианты комплектации и смену источника. Исправление не должно незаметно расширять условия фильтра или включать неподтверждённые значения.
Какие показатели отслеживать после внедрения
Начните с качества данных. Для выбранных применимых полей считайте долю подтверждённых значений, конфликтов, пропусков и ошибок преобразования. Для полноты укажите знаменатель – например, все пары «товар – применимое обязательное свойство» в выбранной категории.
Если применимость ещё не определена, такие случаи учитывают отдельно. Их нельзя незаметно записывать в «не применимо», чтобы повысить процент заполненности. Точно так же проверка типа данных не доказывает достоверность самого значения.
Затем оцените работу поиска. На контрольных запросах проверяйте, какие ожидаемые товары найдены и какие лишние включены. Для оценки полноты нужен заранее проверенный набор релевантных товаров. Одной общей цифры «найдено 30 результатов» недостаточно.
Долю запросов без результатов можно считать как количество обработанных поисковых запросов с нулевой выдачей, делённое на число всех обработанных запросов за тот же период. Отделите обычный поиск от подсказок при вводе, технических ошибок и автоматических обращений.
Для поведения покупателей отслеживайте применение фильтров, переходы в карточки, добавления в корзину и покупки в сопоставимых сеансах. Изменение конверсии оценивают с учётом ассортимента, наличия, цен, источников трафика и сезонности. При достаточном объёме данных полезен контролируемый эксперимент.
Если покупки передаются из CRM в Google Ads, дополнительно проверьте, как учитываются отмены и возвраты. Иначе оценка результата может опираться на заказы, которые уже отменены. Порядок сверки описан в руководстве по проверке CRM-конверсий и корректировке стоимости заказов.
Первые проверки на небольшой категории позволяют проверить механику и обнаружить ошибки. Подтверждение влияния на продажи требует отдельного наблюдения с достаточными данными.
Частые вопросы о характеристиках товаров
Сначала определите свойства, которые применимы к категории и нужны покупателям или работе системы. Избыточные поля усложняют заполнение и проверку. Приоритетные характеристики должны иметь понятное назначение и надёжный источник.
Можно подготовить предложения по сопоставлению, но правило нужно проверить на примерах. «Объём бака» и «объём пылесборника» могут обозначать разные ёмкости. После утверждения соответствие сохраняют и используют повторно.
Описание помогает человеку выбирать. Поиск и фильтры используют настроенные поля и правила обработки. Нужно проверить, какие сведения из описания действительно попадают в поисковый индекс и какие числовые условия система способна применить.
Сохранить известные значения, отметить недостающие и направить их на уточнение. Для каждого покупательского условия заранее определить, считается ли соответствие подтверждённым. Неизвестное значение не подменяют отрицательным ответом или нулём.
Решение зависит от возможностей текущей системы и объёма задачи. Сначала проверьте существующие поля, выгрузку, индекс и настройки фильтрации. Ограниченный пилот покажет, какие изменения нужны в данных, а какие – в программной части.
Исследование BEATS проверяло качество внутреннего поиска. Для Google дополнительно важны индексируемые страницы, их содержание, техническая доступность и другие факторы. Результат работы с каталогом нужно измерять по соответствующим задачам, сохраняя отдельный контроль органического трафика.
Начните с одной категории и проверяемого результата
Выберите несколько покупательских сценариев, проверьте исходные данные и согласуйте схему свойств. После этого подготовьте контрольные товары, исправьте одну категорию и убедитесь, что ожидаемые модели находятся по заданным условиям.
Такой порядок даёт основу для дальнейшего наполнения и автоматизации. Команда получает единые определения, правила проверки и понятное задание на подключение характеристик к поиску и фильтрам.