Как подготовить товарные данные для выбора и покупки через AI-помощников

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

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

В январе 2026 года Яндекс сообщил, что Алиса AI в среднем получает 500–600 тысяч вопросов о подборе товаров в день. В апреле компания уточнила: около 10% запросов к Алисе AI связаны с поиском, выбором и покупкой, а оформление через чат доступно более чем в 3900 интернет-магазинах. Эти данные описывают одну платформу на конкретные даты, но уже показывают масштаб сценария.

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

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

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

CMS — Content Management System, система управления содержимым сайта.

CRM — Customer Relationship Management, система работы с клиентами, заказами и продажами.

EAN — European Article Number; в товарных данных так часто называют GTIN-13, который кодируется штрихкодом EAN-13.

ERP — Enterprise Resource Planning, система управления ресурсами компании: складом, закупками, финансами и другими процессами.

GTIN — Global Trade Item Number, глобальный номер товарной позиции.

MPN — Manufacturer Part Number, артикул, присвоенный товару производителем.

PIM — Product Information Management, система управления информацией о товарах.

SKU — Stock Keeping Unit, учетная единица конкретного варианта товара.

SLA — Service Level Agreement, согласованный уровень сервиса; в этой статье — максимально допустимая задержка обновления данных.

YCP — Yandex Commerce Protocol, стандарт агентной коммерции Яндекса для интеграции интернет-магазинов с AI-сценариями покупки.

YML — Yandex Market Language, основанный на XML формат товарного фида Яндекса.

AI сопоставляет запрос с параметрами товара

Возьмем разговорный запрос:

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

В нем есть пять критериев: уровень шума, работа с шерстью, автономность, площадь уборки и доступность расходников. Для подбора системе нужны конкретные сведения и понятные связи между ними.

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

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

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

Карточка также должна отвечать на вопросы, которые возникают до покупки:

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

• с какими моделями, расходниками и системами он совместим;

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

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

• сколько стоят расходники, как действуют гарантия и возврат.

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

Модель, вариант, предложение и заказ требуют разных данных

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

Модель

К модели относятся бренд, линейка, назначение и свойства, общие для всех вариантов. Эти сведения меняются после обновления спецификации или исправления данных.

Вариант

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

Предложение продавца

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

Заказ

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

Schema.org позволяет опубликовать эти связи на странице: семейство вариантов описывается через ProductGroup, конкретный вариант — через Product, условия продажи — через Offer. Свойства hasVariant и isVariantOf связывают группу и варианты. Google поддерживает такую разметку для товарных вариантов в поиске. Поддержка отдельных свойств зависит от платформы, поэтому в коде стоит использовать свойства из официальной схемы и проверять требования нужного канала.

Яндекс поясняет, что семантическая разметка помогает поисковым системам понимать страницу, хотя прямо на ранжирование не влияет. Подробнее о роли разметки и постоянных ID мы писали в статье «Разметка Schema.org для AI-поиска: что внедрить на сайт».

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

Устойчивые идентификаторы сохраняют связи между системами

Товарные данные проходят через ERP, PIM, CMS, фид, аналитику и CRM. Названия могут различаться, поэтому связь между записями держится на идентификаторах. Внутренние имена model_id, variant_id и offer_id зависят от архитектуры магазина и не являются универсальным стандартом.

GS1 объясняет, что GTIN служит глобальным идентификатором товара, а GTIN-13 также называют EAN. Внешний номер помогает сопоставлению между компаниями и площадками, внутренние ID сохраняют связи внутри систем магазина.

Изменение цены или остатка не должно создавать новый ID предложения. Яндекс сопоставляет предложение по паре feed id + offer id. Перенос прежнего offer id в другой фид создает новую пару, которая считается новым предложением.

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

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

Фид, разметка, карточка и корзина описывают одно предложение

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

Для Яндекс Товаров одним из источников служит YML-фид с данными о магазине, категориях и предложениях. Структуру и способы генерации мы разбирали в статье «YML-файл для Яндекс.Маркета: что это, зачем и как его сделать». Фид нужно сравнивать с JSON-LD, видимой карточкой и корзиной.

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

Минимальный чек-лист:

• цена в фиде и JSON-LD совпадает с карточкой и корзиной;

• товар можно заказать в заявленном регионе;

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

• URL открывает нужный товар и сохраняет выбранный вариант;

• изображение соответствует варианту;

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

• закончившиеся предложения своевременно исключаются;

• время обновления фиксируется и контролируется по каждому динамическому полю.

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

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

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

Динамические условия перепроверяются при оформлении заказа

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

Яндекс называет YCP стандартом агентной коммерции для интеграции с Поиском и Алисой AI. Во время оформления YCP обращается к API магазина для проверки корзины, расчета доставки и финальной проверки с резервированием товара. Кнопка «Купить в 1 клик» пока тестируется и может показываться не всем пользователям и товарам. Подключение доступно через YCP, Яндекс KIT, Яндекс Маркет или 1С-Битрикс.

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

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

Частота обновления зависит от изменчивости поля и стоимости ошибки. Дефицитные и быстро меняющиеся предложения могут обновляться через API или короткими интервалами; обычный ассортимент — по расписанию; характеристики — после изменения в PIM. Яндекс требует версию YML-каталога не старше десяти дней. Для цены и наличия магазину обычно нужен более строгий внутренний SLA.

Что проверить магазину. E-commerce-команда фиксирует условия продажи, разработка проверяет API и сохранение варианта, логистика — расчет по регионам, поддержка — гарантию и возврат. Тестовый заказ должен пройти до подтверждения с исходным вариантом, корректной ценой и доступной доставкой.

Метрики связывают качество данных с коммерческим результатом

Веб-аналитика показывает переходы и действия на сайте. Часть выбора проходит внутри внешнего AI-интерфейса, поэтому переход может прийти без реферера и UTM-параметров, а сведения о внутреннем сравнении останутся у площадки. Для оценки нужны три группы показателей.

Качество данных

• доля предложений без обязательных полей;

• доля расхождений цены и наличия;

• доля неработающих URL и неверных изображений;

• задержка обновления относительно SLA;

• доля заказов, отмененных или исправленных из-за ошибки в данных.

Представление в AI-ответах

• доля ответов, в которых появляется подходящая модель;

• доля ответов с предложением магазина;

• доля ответов с правильным вариантом;

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

• доля верно названных характеристик и ограничений;

• частота и контекст появления конкурентов.

Коммерческий результат

• переходы на товарные страницы, когда источник определяется;

• добавления в корзину и начатые оформления;

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

• отмены из-за остатка или изменения цены;

• конверсия по категориям и вариантам;

• возвраты из-за ошибочно выбранного варианта.

Для мониторинга нужен фиксированный набор запросов. В каждом запуске фиксируют дату, регион, устройство, аккаунт и режим поиска; повторные срезы проводят при одинаковых управляемых условиях. Важные сценарии стоит повторять, поскольку AI-ответы меняются между запусками. Принципы отбора запросов мы разобрали в статье «Как собрать промпт-сет для мониторинга бренда и категории продукта».

В одном отчете можно связать ошибки из Яндекс Товаров, поведение на сайте, логи корзины, заказы и причины отмен в CRM. Возможности и ограничения атрибуции мы подробно описали в статье «Как отслеживать лиды из ChatGPT, Perplexity и других AI-систем».

Что проверить магазину. Выберите одну категорию и соберите 15–20 запросов по характеристикам, пользовательской задаче, цене, совместимости и доставке. В ответах фиксируйте модель, вариант, продавца, цену, наличие и срок доставки, затем сверяйте их с фидом, карточкой и корзиной. После исправлений повторите проверку в тех же условиях. Основной показатель выбирайте по исходной проблеме: для неверной цены это доля ответов с корректной ценой. Видимость товара оценивайте отдельно. Подход к сравнению до и после правки мы описали в статье «Как проверять гипотезы в GEO: эксперимент, сравнение и оценка эффекта».

***

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

Читайте также:

Как проверять гипотезы в GEO: эксперимент, сравнение и оценка эффекта

AI-агенты входят в клиентский путь: как подготовить данные, сайт и процессы

Комплексный маркетинг в 2026 году: каналы, аналитика, AI-поиск и продажи