Товарный YML-фид — это структурированный XML-файл с информацией о товарах интернет-магазина: названиями, ценами, ссылками, изображениями, категориями, характеристиками и данными о наличии. Яндекс использует такие данные в нескольких сервисах: для товарного поиска, рекламных размещений, Яндекс Маркета, Яндекс Вебмастера, а в отдельных сценариях — для Яндекс Бизнеса и связанных с ним карточек компаний.
Фид нужен не просто для передачи прайс-листа. Он связывает каталог интернет-магазина с сервисами Яндекса и позволяет передавать данные в машиночитаемом виде. Поэтому ошибки в структуре XML, ценах, идентификаторах, ссылках или наличии могут привести к тому, что часть товаров не загрузится или будет использоваться некорректно.
В этой статье разберём, как устроен YML-фид, какие элементы в нём используются, чем отличаются варианты офферов, как создать файл для магазина, проверить его перед загрузкой и организовать регулярное обновление.
Что такое YML-фид и как он устроен
YML расшифровывается как Yandex Market Language. Это формат, основанный на XML и адаптированный для передачи информации о товарах и услугах в сервисы Яндекса. Внутри файла есть общая информация о магазине, дерево категорий и список товарных предложений, которые называются offer. YML — один из вариантов товарного фида. Подробнее о том, что такое фид, какие задачи он решает и где используется, — в статье глоссария «Фид: расшифровка, виды и форматы».
Схема файла: yml_catalog, shop, currencies, categories, offers
Упрощённо структуру YML можно представить как несколько вложенных уровней: корневой элемент yml_catalog, внутри него shop, а уже в магазине располагаются валюты, категории и предложения. Не все элементы одинаково обязательны для каждого сервиса, поэтому конкретный набор полей нужно проверять по требованиям площадки, для которой создаётся фид.
Базовая структура выглядит так:
<?xml version="1.0" encoding="UTF-8"?> <yml_catalog date="2026-09-13 12:00"> <shop> <name>Название магазина</name> <company>Название компании</company> <url>https://example.ru/</url> <currencies> <currency id="RUR" rate="1"/> </currencies> <categories> <category id="1">Категория</category> <category id="2" parentId="1">Подкатегория</category> </categories> <offers> <offer id="1001" available="true"> ... </offer> </offers> </shop> </yml_catalog>
У корневого yml_catalog есть атрибут date, который должен отражать время формирования файла. В требованиях конкретного сервиса формат даты может быть задан отдельно. Для Яндекс Директа в актуальных требованиях используется формат YYYY-MM-DD hh:mm.
Внутри categories формируется дерево категорий. Каждая категория получает собственный идентификатор id, а вложенная категория может ссылаться на родительскую через parentId. В offers находятся товары, и каждый товар связывается с категорией через categoryId.
Таким образом, Яндекс получает не просто список товаров, а связанные между собой сущности: магазин, валюты, категории и предложения. Подробнее можно прочитать в Яндекс Справке.
Типы офферов: упрощённый, произвольный, vendor.model
Способ описания товара в YML зависит от того, насколько подробно его можно представить через название, тип, производителя и модель. Для Яндекса используются упрощённый вариант и произвольный тип vendor.model. При этом дополнительные поля позволяют передать больше информации о товаре, если она действительно есть в каталоге.
Упрощённый вариант подходит, когда товар удобно описать одним полным названием. В этом случае используется тег name, внутри которого уже содержится название товара целиком.
<offer id="1001" available="true"> <name>Смартфон Brand Model X 256 ГБ черный</name> <price>59990</price> <currencyId>RUR</currencyId> <categoryId>15</categoryId> <picture>https://example.ru/images/model-x.jpg</picture> <url>https://example.ru/catalog/model-x/</url> </offer>
Здесь Яндекс получает готовое название из одного поля name. Такой способ удобен для товаров, где производитель и модель не являются главным способом идентификации или где каталог не содержит этих данных в отдельных полях.
Для товаров с чёткой структурой «тип + производитель + модель» используется произвольный тип vendor.model. Он задаётся атрибутом type у элемента offer. Внутри оффера используются отдельные поля typePrefix, vendor и model.
<offer id="1002" type="vendor.model" available="true"> <typePrefix>Смартфон</typePrefix> <vendor>Brand</vendor> <model>Model X</model> <price>59990</price> <currencyId>RUR</currencyId> <categoryId>15</categoryId> <picture>https://example.ru/images/model-x.jpg</picture> <url>https://example.ru/catalog/model-x/</url> </offer>
В этом случае название товара можно логически представить как сочетание трёх частей: typePrefix — тип товара, vendor — производитель, model — модель. Например: «Смартфон Brand Model X». Такая структура особенно полезна для техники, электроники и других товаров, где модель является важной частью поискового запроса.
Важно различать сам тип оффера и дополнительные данные. Наличие одновременно name и полей typePrefix, vendor, model не означает появление отдельного третьего типа YML. Это просто более подробное описание товара, если конкретный сервис и выбранная схема позволяют его использовать.
| Вариант | Основные поля | Когда использовать |
|---|---|---|
| Упрощённый | name |
Когда товар удобно описать одним полным названием |
Произвольный vendor.model |
typePrefix, vendor, model |
Когда у товара есть чёткий тип, производитель и модель |
| Расширенное описание | name + дополнительные поля |
Когда нужно передать сервису больше информации о товаре и это допускает конкретная схема |
Для Яндекс Директа выбор схемы имеет практическое значение: набор рекомендуемых полей зависит от типа YML. Для произвольного варианта Директ использует данные typePrefix, vendor и model, а для упрощённого важным полем является name. Поэтому при создании фида сначала стоит определить целевой сервис и его требования, а уже потом выбирать структуру оффера.
Если каталог содержит нормальные данные о производителе и модели, лучше передавать их отдельными полями, а не собирать всё в одну строку. Если таких данных нет или они не имеют смысла для конкретного товара, упрощённая схема будет понятнее и надёжнее.
Чем YML отличается от обычного XML и от CSV
YML технически основан на XML, но содержит согласованную для сервисов Яндекса структуру. Обычный XML может описывать практически любые данные и не обязан соответствовать схеме товарного фида.
CSV устроен проще: информация обычно располагается в строках и столбцах. Для человека таблица понятнее, но для сложной структуры каталога CSV менее удобен. В YML можно выразить дерево категорий, несколько изображений, характеристики, параметры доставки и другие связанные данные.
| Формат | Структура | Основное применение |
|---|---|---|
| YML | XML с товарной структурой | Сервисы и технологии Яндекса |
| XML | Произвольная | Обмен структурированными данными |
| CSV | Табличная | Импорт и экспорт каталогов |
Для интернет-магазина с категориями, вариантами товаров и большим количеством характеристик YML обычно удобнее именно за счёт вложенной структуры.
Где используется YML-фид в Яндексе
YML-фид может использоваться в нескольких сервисах Яндекса, но требования к нему не являются абсолютно одинаковыми. Поэтому правильнее воспринимать YML как основу для передачи товарных данных, а затем учитывать правила конкретного сервиса.
Яндекс Маркет: что передаётся, какие данные нужны товару
В Яндекс Маркете YML используется для передачи информации о товарах и предложениях магазина. В зависимости от схемы размещения и типа интеграции важны идентификаторы товара, название, цена, валюта, категория, ссылка, изображения, наличие и другие характеристики.
Особое значение имеет offer id. Это идентификатор конкретного предложения. Он должен быть уникальным и стабильным. Если идентификатор товара постоянно меняется при каждом обновлении фида, сервису сложнее корректно сопоставлять новую версию предложения с предыдущей.
Для большого каталога стабильные ID особенно важны: изменение идентификаторов без необходимости может повлиять на сопоставление товаров и историю работы с ними.
Яндекс Директ: товарные объявления, динамические форматы, Товарная галерея
В Яндекс Директе фид используется для автоматической передачи информации о товарах в рекламные инструменты. В актуальной структуре Директа это может быть связано с товарными объявлениями, товарными кампаниями, каталогами и Товарной галереей.
Для произвольного YML Директ рекомендует набор полей, среди которых url, price, picture, typePrefix, vendor и model. Для упрощённого варианта требования к минимальному набору отличаются.
Через param можно передавать характеристики товара: например, цвет, размер, материал или другие свойства. Они могут использоваться при формировании карточки товара и фильтрации предложений.
Отдельно нужно учитывать наличие. Если товар отсутствует, рекламная система не должна получать его как доступный для продажи. Иначе фид начнёт сообщать рекламной системе одно, а сайт покупателю другое. Технически это всего лишь рассинхронизация, но оплачивать её последствия приходится вполне настоящими деньгами.
Яндекс Вебмастер и товарный поиск
В Яндекс Вебмастере YML используется для передачи структурированной информации о товарах. Данные фида могут участвовать в формировании товарных ответов в поиске.
Яндекс может получать товарную информацию и самостоятельно с сайта, но передача актуального фида позволяет явно сообщить поисковой системе данные о каталоге в структурированном виде. Особенно полезно это для крупных интернет-магазинов, где ассортимент, цены и наличие регулярно меняются.
После подключения фид проверяется. Если в нём есть ошибки, статус источника может измениться, а часть данных не будет использована.
Яндекс Бизнес / Карты
YML может использоваться и в Яндекс Бизнесе для автоматического добавления товаров и услуг. Товары из прайс-листа могут отображаться в карточке компании в Поиске и Яндекс Картах.
При этом здесь действуют собственные ограничения. Например, для автоматической загрузки товаров через YML-фид Яндекс Бизнес сейчас указывает ограничение до 10 000 товаров или услуг и размер файла до 15 МБ. Это не общий лимит YML и не универсальное ограничение для всех сервисов Яндекса.
Поэтому фразу «YML-фид максимум такого-то размера» без указания сервиса лучше вообще не использовать. Лимиты могут различаться.
Чем отличаются требования площадок — один фид или разные
Один и тот же каталог можно использовать как источник для нескольких сервисов, но это не означает, что требования к фиду везде идентичны.
Если структура каталога и набор данных подходят всем целевым сервисам, один фид действительно удобнее. Если же для Маркета, Директа и других интеграций нужны разные поля, ограничения или способы группировки товаров, имеет смысл генерировать отдельные версии.
При этом идентификаторы товаров желательно сохранять стабильными. Разные фиды могут содержать один и тот же товар, но его ID не стоит менять без технической причины.
Технические требования к YML-фиду
Основные ошибки YML появляются не в сложной логике, а в базовых технических вещах: неправильной кодировке, битых XML-тегах, недоступных изображениях, неверных ценах, неправильных идентификаторах и устаревшем наличии. Поэтому техническая проверка должна начинаться до загрузки файла в сервис.
Формат, кодировка, размер файла, формат даты
YML является XML-файлом. При его формировании нужно соблюдать правила XML: корректно закрывать элементы, экранировать специальные символы и использовать заявленную кодировку.
На практике чаще всего используется UTF-8. Некоторые сервисы Яндекса могут поддерживать и другие варианты, но для нового фида UTF-8 обычно является наиболее предсказуемым выбором.
Размер файла определяется конкретным сервисом. Например, ограничения Яндекс Директа и Яндекс Бизнеса отличаются, поэтому перед загрузкой большого каталога нужно смотреть требования именно той площадки, куда передаётся фид.
Дата в yml_catalog должна соответствовать времени генерации файла. Для Директа используется формат:
<yml_catalog date="2026-09-13 12:00">
Если файл генерируется автоматически, дата должна обновляться вместе с его содержимым.
Автообновление: постоянная ссылка, расписание, свежесть данных
Для интернет-магазина статический YML, который однажды выгрузили и забыли, почти всегда является плохим решением. Цена, наличие и ассортимент меняются, а рекламные и товарные сервисы продолжают получать старую информацию.
Лучше использовать постоянный URL, по которому сервис может получать актуальную версию фида. При этом сама ссылка не должна меняться при каждом обновлении. Меняется содержимое файла, а не его адрес.
Автоматическую генерацию обычно запускают по расписанию. Частота зависит от скорости изменения каталога. Если цены и наличие меняются несколько раз в день, обновление раз в сутки может быть недостаточным для конкретной задачи. Если каталог практически не меняется, постоянный запуск каждую минуту тоже не делает систему лучше.
Структура и обязательные элементы
У каждого сервиса есть собственные требования к обязательным полям. В общем случае для товарного предложения важны идентификатор, цена, валюта, категория и информация, позволяющая определить товар и перейти к нему на сайте.
Минимальный рабочий набор зависит от типа оффера и целевого сервиса. Поэтому при разработке генератора сначала определяют, куда будет загружаться фид, и только после этого фиксируют обязательные поля.
Цены, валюты, oldprice
Цена в фиде должна соответствовать реальной цене товара на странице. Если пользователь открывает карточку и видит другую сумму, доверие к данным фида снижается, а некоторые сервисы могут отклонить предложение или показать его некорректно.
Для валюты используется currencyId. Допустимые значения зависят от сервиса и конкретной интеграции.
Если используется старая цена oldprice, она должна отражать реальную цену до скидки и соответствовать правилам конкретного сервиса. Нельзя просто добавить заведомо завышенную старую цену, чтобы скидка визуально выглядела крупнее.
<offer id="1001" available="true"> <name>Смартфон Brand Model X</name> <price>59990</price> <oldprice>69990</oldprice> <currencyId>RUR</currencyId> <categoryId>15</categoryId> </offer>
Если скидка не соответствует реальной цене или товар продаётся по другой стоимости, такой фид лучше исправить до загрузки, а не надеяться, что алгоритмы самостоятельно проявят человеческое милосердие.
Категории: дерево, id, parentId, связь с офферами
Категории образуют дерево. У каждой категории есть уникальный идентификатор, а дочерняя категория может указывать родителя через parentId.
<categories> <category id="1">Электроника</category> <category id="2" parentId="1">Смартфоны</category> <category id="3" parentId="1">Планшеты</category> </categories>
У товара значение categoryId должно соответствовать существующей категории:
<offer id="1001" available="true"> <name>Смартфон Brand Model X</name> <categoryId>2</categoryId> </offer>
Битая связь между товаром и категорией является одной из типичных структурных ошибок. Особенно часто она появляется после удаления категории в CMS или изменения логики генератора.
Изображения: требования, лимиты, частые проблемы
В поле picture указывается URL изображения. Ссылка должна вести непосредственно на файл изображения и быть доступной для робота.
Частые проблемы здесь вполне прозаичны:
- изображение доступно только авторизованным пользователям;
- URL возвращает HTML-страницу вместо картинки;
- используется битая или устаревшая ссылка;
- сервер блокирует роботов;
- картинка слишком большая или не соответствует требованиям конкретного сервиса;
- после изменения структуры сайта старые URL изображений перестают работать.
Перед загрузкой большого каталога полезно проверить не один товар, а выборку из разных категорий.
Ссылки на товары: прямые URL, редиректы, доступность
Поле url должно вести на страницу соответствующего товара. Желательно использовать конечный URL без лишней цепочки редиректов.
Если генератор формирует ссылки с временными параметрами, сессиями или техническими идентификаторами, это нужно исправлять на уровне генерации. Ссылка в фиде должна быть стабильной и однозначно вести к нужному товару.
Также необходимо проверить доступность страниц для роботов. Если товар присутствует в YML, но его страница отдаёт ошибку, требует авторизации или постоянно перенаправляет на другую страницу, интеграция становится нестабильной.
Характеристики (param) и дополнительные параметры
Для характеристик товара используется элемент param. Название характеристики задаётся атрибутом name, значение указывается внутри элемента.
<offer id="1001" available="true"> <name>Кроссовки Brand Run</name> <price>12990</price> <currencyId>RUR</currencyId> <categoryId>25</categoryId> <param name="Цвет">черный</param> <param name="Размер">42</param> <param name="Материал">текстиль</param> </offer>
В param стоит передавать действительно полезные характеристики, а не весь массив технических полей из базы данных. Мусорные параметры усложняют обработку и не помогают пользователю понять товар.
Доставка и самовывоз: delivery, delivery-options, pickup, store
Информация о доставке и самовывозе может передаваться отдельными элементами YML. Набор и детализация зависят от сервиса и типа интеграции.
Например, в структуре фида могут использоваться сведения о доступности доставки, вариантах доставки, самовывозе и наличии товара в конкретной точке:
<offer id="1001" available="true"> <name>Товар</name> <price>4990</price> <currencyId>RUR</currencyId> <categoryId>10</categoryId> <delivery>true</delivery> <pickup>true</pickup> </offer>
Не стоит добавлять элементы доставки только потому, что они встречались в чужом примере. Сначала нужно проверить, поддерживает ли их целевой сервис и какие именно значения он ожидает.
Как создать YML-фид для интернет-магазина
Способ создания YML зависит прежде всего от CMS, размера каталога и частоты изменений. Для большинства магазинов ручное редактирование XML быстро становится неудобным, поэтому основным вариантом остаётся автоматическая генерация из каталога.
Через модуль или плагин CMS (Битрикс, WordPress/WooCommerce, OpenCart и др.)
Для популярных CMS существуют плагины и модули, которые берут товары непосредственно из каталога и формируют YML автоматически.
Это наиболее удобный вариант, если:
- каталог регулярно меняется;
- товаров больше нескольких десятков;
- цены и наличие хранятся в CMS;
- нужно автоматически обновлять фид;
- магазин уже использует несколько товарных интеграций.
Главное преимущество здесь не в самом XML, а в синхронизации. При изменении товара данные должны автоматически попадать в новую версию фида.
После установки модуля всё равно нужно проверить результат. Автоматическая генерация не означает автоматическую корректность. Плагин может передавать неправильные категории, обрезать названия, использовать нестабильные ID или формировать URL, которые не работают.
Через отдельный генератор или онлайн-сервис
Отдельный генератор подходит, если данные магазина уже находятся в другом источнике: например, в CSV, XML, базе данных или внешней системе учёта.
Такой вариант может быть удобен для небольших проектов или нестандартных каталогов. Но при выборе сервиса нужно учитывать, где хранятся данные и как часто обновляется итоговый файл.
Для коммерческого магазина критично, чтобы генератор не создавал временную ссылку на файл. Яндексу нужен стабильный источник, а магазину — предсказуемый процесс обновления.
Вручную: когда оправдано и как не наделать ошибок
Вручную создать YML можно, если каталог маленький и практически не меняется. Для 10–20 товаров это может быть быстрее, чем разворачивать отдельную систему генерации.
При ручном создании нужно проверить:
- корректность XML;
- кодировку файла;
- уникальность
offer id; - существование всех
categoryId; - корректность цен и валют;
- работоспособность URL товаров;
- доступность изображений;
- актуальность наличия.
Для большого каталога ручной способ быстро превращается в источник ошибок. Человек прекрасно умеет забыть поменять одну цену в XML из трёх сотен строк, а потом искренне удивляться, почему реклама показывает товар по цене из прошлого квартала.
Пример YML-фида
Ниже приведён упрощённый пример YML, который показывает общую структуру файла. Это именно пример структуры, а не универсальный шаблон для загрузки во все сервисы Яндекса: перед публикацией нужно сверить обязательные поля с требованиями конкретной площадки.
Минимальная структура файла
В минимальном варианте нам нужны корневой элемент, магазин, валюта, категория и предложение товара.
<?xml version="1.0" encoding="UTF-8"?> <yml_catalog date="2026-09-13 12:00"> <shop> <name>Интернет-магазин</name> <company>ООО «Компания»</company> <url>https://example.ru/</url> <currencies> <currency id="RUR" rate="1"/> </currencies> <categories> <category id="1">Смартфоны</category> </categories> <offers> <offer id="1001" available="true"> <name>Смартфон Brand Model X</name> <price>59990</price> <currencyId>RUR</currencyId> <categoryId>1</categoryId> <picture>https://example.ru/images/model-x.jpg</picture> <url>https://example.ru/catalog/model-x/</url> </offer> </offers> </shop> </yml_catalog>
Здесь offer id="1001" идентифицирует товар, categoryId="1" связывает его с категорией, а url и picture указывают на страницу товара и изображение.
Произвольный тип и характеристики
Если товар удобно описывать через тип, производителя и модель, можно использовать произвольный тип vendor.model.
<offer id="2001" type="vendor.model" available="true"> <typePrefix>Ноутбук</typePrefix> <vendor>Brand</vendor> <model>ProBook 15</model> <price>89990</price> <currencyId>RUR</currencyId> <categoryId>5</categoryId> <picture>https://example.ru/images/probook-15.jpg</picture> <url>https://example.ru/catalog/probook-15/</url> <param name="Диагональ">15.6</param> <param name="Оперативная память">16 ГБ</param> <param name="Цвет">серый</param> </offer>
Такой формат позволяет передавать более подробную информацию о товаре. При этом конкретный набор обязательных и рекомендуемых элементов зависит от сервиса, куда отправляется фид.
Как проверить YML-фид перед загрузкой
Проверка YML должна состоять из нескольких этапов. Валидатор помогает найти синтаксические и структурные ошибки, но не способен определить все бизнес-проблемы. Например, XML может быть полностью корректным, а цена товара при этом окажется в десять раз выше реальной.
Валидатор Яндекса: что проверяет, а что пропускает
Валидатор Яндекса позволяет проверить фид на соответствие требованиям конкретной товарной системы. Он способен обнаружить проблемы со структурой, обязательными элементами и отдельными значениями.
Но валидатор не заменяет проверку самого магазина. Он не знает, действительно ли цена на сайте соответствует ожиданиям владельца бизнеса, правильно ли настроена скидка или должен ли конкретный товар продаваться в определённом регионе.
Поэтому после технической проверки нужно открыть несколько реальных карточек товаров и сравнить их с данными фида.
Внешние инструменты и ручная проверка выборки
Дополнительно можно использовать обычные XML-парсеры и средства проверки структуры XML. Для разработчика полезна также автоматическая проверка HTTP-ответов по URL товаров и изображений.
Ручную выборку стоит составлять не из первых пяти товаров, а из разных типов:
- товар с обычной ценой;
- товар со скидкой и
oldprice; - товар без изображения;
- товар с несколькими изображениями;
- товар в глубокой категории;
- товар с характеристиками;
- товар в наличии;
- товар без наличия.
Такая выборка быстрее показывает системные ошибки генератора, чем проверка одного идеального товара.
Чек-лист перед первой загрузкой
Перед подключением фида стоит пройти короткий технический чек-лист:
- XML открывается без синтаксических ошибок;
- кодировка соответствует заявленной;
- дата генерации обновляется;
- все
offer idуникальны; - ID товаров стабильны между обновлениями;
- все
categoryIdсуществуют; - цены соответствуют сайту;
- валюта указана корректно;
- URL товаров открываются;
- изображения доступны по прямым ссылкам;
- наличие соответствует реальному состоянию товара;
- характеристики передаются без лишнего технического мусора;
- размер файла соответствует ограничению целевого сервиса;
- ссылка на фид постоянная;
- после обновления содержимое файла действительно меняется.
Если все пункты проходят проверку, фид можно подключать к нужному сервису и контролировать его статус после первой загрузки.
Частые ошибки в YML-фиде
Ошибки YML удобно разделить на четыре группы: синтаксические, структурные, контентные и связанные с рекламным использованием данных. Такое разделение помогает быстрее понять, где искать причину проблемы.
Синтаксические: XML, кодировка, экранирование спецсимволов
XML чувствителен к синтаксису. Если внутри значения встречаются специальные символы, их нужно корректно экранировать.
Например, символы <, > и & нельзя бездумно вставлять в текст XML. Для специальных символов используются соответствующие XML-сущности.
Неправильно:
<name>Кабель 2 & 3 метра</name>
Корректный вариант:
<name>Кабель 2 & 3 метра</name>
Такие ошибки особенно часто возникают, когда YML формируется непосредственно из базы данных без корректного XML-экранирования.
Структурные: битые categoryId, дубли offer id, нестабильные идентификаторы
Если товар указывает на категорию, которой нет в блоке categories, структура фида нарушена.
Другой типичный случай — одинаковые ID у разных предложений:
<offer id="1001">...</offer> <offer id="1001">...</offer>
Каждый товарный оффер должен иметь уникальный идентификатор в рамках соответствующего фида и сценария использования.
Не менее опасна постоянная смена ID. Например, если CMS сегодня создаёт товар с ID 1001, а после очередного импорта тот же товар получает ID 78452, для системы это может выглядеть как новый товар.
Контентные: цены, наличие, картинки, мусор в param
Даже идеально валидный XML может содержать плохие данные. Самые частые проблемы связаны с содержимым предложения:
- цена отличается от цены на странице;
- товар отмечен как доступный, хотя его нет;
- изображение удалено или недоступно;
- URL ведёт на категорию вместо товара;
- характеристики передаются пустыми;
- в
paramпопадают внутренние поля базы данных; - название товара содержит технический мусор.
Для поисковых и рекламных систем качество данных фида не менее важно, чем правильность XML.
Таргетинговые: отсутствие typePrefix, несовпадение id с Метрикой, реклама absent-товаров
Некоторые проблемы проявляются уже на уровне рекламной интеграции. Например, для произвольного типа оффера могут быть важны typePrefix, vendor и model. Если обязательные для выбранной схемы поля отсутствуют, Директ может неправильно интерпретировать предложение.
Отдельно нужно проверять сценарии, где товарные идентификаторы используются совместно с данными Метрики или другими системами аналитики. В таких интеграциях ID должны быть согласованы. Это не универсальное требование ко всякому YML-фиду, но при использовании соответствующей связки несовпадение идентификаторов способно нарушить сопоставление данных.
Наконец, рекламная система не должна получать как доступный товар, которого фактически нет в продаже. Поэтому значение available должно формироваться из актуального состояния каталога.
Практические рекомендации для вашего магазина
Подход к YML лучше выбирать не по принципу «какой способ проще написать один раз», а по тому, как устроен каталог и насколько часто он меняется. Чем больше товаров и интеграций, тем важнее автоматизация и контроль качества.
Малый каталог (до 50–100 товаров)
Для небольшого каталога подойдёт готовый модуль CMS или простой генератор. Если товары редко меняются, допустима даже ручная подготовка, но только при наличии регулярной проверки.
Минимальная схема работы может быть такой:
- генератор формирует YML;
- файл размещается по постоянному URL;
- Яндекс получает актуальную версию;
- после изменения цен или ассортимента выполняется проверка;
- ошибки отслеживаются через кабинет соответствующего сервиса.
Для маленького магазина главное не усложнить систему раньше времени.
Средний и крупный каталог (1000+ товаров)
Для большого каталога ручная работа с YML становится неоправданной. Генерация должна выполняться автоматически из актуальных данных CMS, ERP или другой системы, где хранится каталог.
Полезно разделить процесс на несколько этапов: получение данных, нормализация, формирование XML, техническая проверка и публикация файла.
Для крупного магазина также стоит отдельно контролировать:
- количество товаров в фиде;
- количество товаров с ценой и без неё;
- количество товаров в наличии;
- количество недоступных изображений;
- количество битых URL;
- изменение общего размера файла;
- изменение числа категорий;
- появление дублей ID.
Резкое изменение одного из этих показателей часто помогает обнаружить проблему раньше, чем её заметят в рекламном кабинете.
Один фид или несколько: адаптация под Маркет и Директ
Один общий YML удобен, если структура данных подходит всем системам. Но иногда разные сервисы требуют разный состав данных или имеют собственные ограничения.
Отдельные фиды могут быть оправданы, если:
- для разных сервисов используются разные наборы товаров;
- цены или наличие отличаются по регионам;
- одной площадке нужны дополнительные характеристики;
- ограничения конкретного сервиса не позволяют использовать общий файл;
- нужно исключить из рекламы часть каталога.
При этом несколько фидов не должны превращаться в несколько независимых копий каталога. Лучше иметь единый источник данных и формировать из него необходимые версии YML.
Мониторинг: что проверять регулярно после запуска
После первой загрузки работа с фидом не заканчивается. Наоборот, именно после подключения начинают проявляться ошибки, которые невозможно заметить в статическом XML. Регулярно стоит проверять:
- статус фида в сервисах Яндекса;
- дату и время последнего обновления;
- количество загруженных товаров;
- ошибки отдельных предложений;
- соответствие цен на сайте и в фиде;
- наличие товаров;
- работоспособность изображений;
- корректность ссылок;
- стабильность идентификаторов;
- изменение размера и количества предложений в файле.
Особенно полезно настроить автоматический контроль критичных изменений. Например, если магазин обычно содержит 5000 товаров, а после ночного обновления в фиде осталось 700, проблема должна быть обнаружена до того, как рекламные и товарные сервисы начнут работать с неполным каталогом.
Хороший YML-фид — это не просто XML-файл, который успешно проходит валидатор. Это регулярно обновляемое представление каталога, где идентификаторы стабильны, цены и наличие соответствуют сайту, изображения и ссылки работают, а структура учитывает требования конкретных сервисов Яндекса.
