Экспорт товаров в YML-фиды: Яндекс Маркет и реклама на 1С-Битрикс

Ваш каталог на 1С-Битрикс должен продавать не только на сайте. Чтобы товары попали в Яндекс Маркет, в товарные и динамические кампании Яндекс Директа, в рекламу VK и Google, магазину нужен товарный фид — машиночитаемый файл, который площадка регулярно забирает и по которому строит карточки и объявления. Самый распространённый формат такого фида — YML (Yandex Market Language). Если фид собран криво, площадка либо не примет товары, либо будет показывать устаревшие цены и продавать то, чего уже нет на складе. Эта статья — экспертный разбор того, как правильно организовать выгрузку YML на 1С-Битрикс.

Разберём по делу: что такое товарный фид и чем YML отличается от обычного прайса, где он используется и какие ещё бывают форматы, как устроена штатная выгрузка каталога в Битриксе, как настроить поля offer, сопоставить категории и свойства с требованиями площадки, как держать цены и остатки в фиде актуальными, обновлять его по расписанию, вести несколько фидов под разные каналы и не наступать на типовые грабли валидации. Материал опирается на нашу практику разработки интеграций магазинов на Битрикс с маркетплейсами и поисковой оптимизации ecommerce-проектов — без обещаний «настроим фид за пять минут».

Что такое товарный фид и зачем он нужен

Товарный фид — это выгрузка вашего каталога в структурированный файл, который внешняя система (маркетплейс, прайс-агрегатор, рекламная площадка) умеет читать автоматически. Вместо того чтобы заводить товары в чужом кабинете вручную, вы отдаёте один файл со всем ассортиментом, а площадка сама разбирает его и строит карточки, объявления или строки прайса. Фид — это мост между вашим каталогом и внешними каналами продаж.

Зачем это нужно магазину на 1С-Битрикс:

• Автоматизация. Тысячи товаров попадают на площадку без ручного ввода — фид генерируется из каталога и обновляется по расписанию.
• Актуальность. Цены и наличие в фиде подтягиваются из того же каталога, что и на сайте, поэтому площадка видит свежие данные, а не прошлогодний прайс.
• Масштаб каналов. Один и тот же каталог можно раздать в несколько фидов под разные площадки, не переписывая товары заново под каждую.
• Реклама. Товарные и динамические рекламные кампании строятся именно на фиде: без него нельзя запустить смарт-баннеры, товарную галерею или динамический ретаргетинг по товарам.

Важно понимать: фид — это не «ещё один прайс в Excel». Обычный прайс описывает строки «название — цена — количество», а товарный фид описывает полноценную товарную карточку: название, категорию, картинки, характеристики, бренд, артикул, доступность и ссылку. Из фида площадка собирает то, что покупатель видит на витрине или в объявлении. Поэтому качество фида напрямую влияет на то, как ваш товар выглядит и ранжируется во внешнем канале.

YML: формат Yandex Market Language

YML расшифровывается как Yandex Market Language — это формат, который Яндекс изначально разработал для передачи данных о товарах в Яндекс Маркет, но который со временем стал де-факто стандартом товарного фида в рунете. Многие площадки, агрегаторы и рекламные системы принимают именно YML или его вариации.

Технически YML — это не отдельный язык, а строгий диалект XML с заранее определённой структурой. Ключевые свойства формата:

• Это валидный XML. Любой YML открывается как XML: та же кодировка, те же правила экранирования спецсимволов, та же древовидная структура тегов.
• Фиксированная схема. Есть жёстко заданный корень yml_catalog, обязательный shop, а внутри — блоки валют, категорий и предложений. Нельзя придумывать теги как угодно: площадка ждёт конкретные имена.
• Товарная модель. Формат заточен под описание товарных предложений (offer) с ценой, категорией, картинками и характеристиками — то есть под то, что нужно для витрины и объявлений.

Из этого следует важный вывод: YML нельзя собирать «на глаз». Файл, который не соответствует схеме (нет обязательного тега, нарушена иерархия категорий, неверная кодировка, неэкранированный символ), площадка отвергнет целиком или проигнорирует часть предложений. Поэтому генерацию YML в Битриксе выстраивают так, чтобы на выходе всегда получался валидный по схеме документ, а результат проверяют валидатором до того, как его увидит площадка.

Где используется фид: площадки и форматы

Прежде чем настраивать выгрузку, полезно понять, куда вообще уходит фид и какой формат ждёт каждый канал. Одним YML дело не ограничивается: у рекламных систем и зарубежных площадок свои форматы, и это влияет на то, сколько фидов вам придётся вести.

Вывод из таблицы простой: YML покрывает большую часть каналов рунета (Маркет, Директ, многие агрегаторы), но не все. У Google Merchant Center свой формат с полями вроде g:id, g:price, g:availability, и туда YML напрямую не отдать — нужен отдельный фид под спецификацию Google. VK/MyTarget тоже нередко используют собственные требования к полям. Поэтому на практике магазин ведёт не «фид», а несколько фидов: базовый YML под Маркет и Директ и отдельные фиды под те каналы, где формат другой. Как связать эти данные в единую аналитику, мы разбираем в статье про сквозную аналитику ecommerce на Битриксе.

Структура YML: shop, categories, offers

Чтобы настраивать выгрузку осознанно, нужно понимать анатомию YML-файла. Он состоит из нескольких вложенных блоков, и у каждого своя роль. Разберём структуру сверху вниз на упрощённом примере.

<?xml version="1.0" encoding="UTF-8"?>
<yml_catalog date="2026-07-02 09: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="1024" available="true">
        <!-- поля предложения -->
      </offer>
    </offers>
  </shop>
</yml_catalog>

Что здесь важно по блокам:

• yml_catalog и атрибут date. Корень файла. Дата генерации помогает площадке понять свежесть фида.
• shop. Описание магазина: имя, компания, адрес сайта. Это «шапка», по которой площадка идентифицирует источник.
• currencies. Список валют с идентификаторами. Каждый offer ссылается на валюту по её id (например, RUR), поэтому валюта, указанная в offer, обязана присутствовать в этом блоке.
• categories. Дерево категорий: каждая категория имеет уникальный id, а вложенные — атрибут parentId, ссылающийся на родителя. Каждый offer привязывается к категории через categoryId.
• offers. Сердце фида — список товарных предложений. Именно здесь живут название, цена, картинки и характеристики.

Ключевая связность: валюта offer должна быть в currencies, а его categoryId — в categories. Нарушьте эти связи — и предложение станет невалидным. Поэтому генератор фида в Битриксе сначала собирает полный список используемых валют и категорий, а уже потом выгружает offer, ссылающиеся на них.

Поля offer: обязательные и рекомендованные

Основная работа при настройке фида — это правильно заполнить offer. Разберём его поля и разделим их на обязательный минимум и рекомендованный слой, который улучшает карточку.

Логика простая: без name, price, currencyId, categoryId и хотя бы одного picture предложение либо не пройдёт как валидный товар, либо будет выглядеть ущербно. Атрибут available сообщает, есть ли товар в наличии. Рекомендованный слой — oldprice (показывает скидку и повышает кликабельность), vendor и vendorCode (помогают площадке сматчить товар и построить фильтры), description и param (питают характеристики и качество карточки). Чем полнее заполнен offer, тем лучше карточка ранжируется и конвертит.

Два типа offer: упрощённый и произвольный

В YML исторически есть два способа описать предложение, и это стоит понимать, потому что от типа зависит набор и трактовка полей.

Упрощённый тип (simplified)

Предложение описывается тегом name — единой строкой названия. Это универсальный вариант, который подходит для большинства товаров и проще в генерации: вы просто отдаёте готовое название, цену, категорию и картинки. Именно его чаще всего используют магазины на Битриксе.

Произвольный тип (vendor.model)

Вместо единого name предложение описывается парой vendor (производитель) и model (модель), а также может содержать typePrefix (тип товара). Такой формат исторически использовался для техники и товаров, где важна связка «бренд + модель». Он даёт площадке более структурированное представление, но и требует, чтобы данные в каталоге были аккуратно разложены на эти составляющие.

<offer id="1024" type="vendor.model" available="true">
  <typePrefix>Смартфон</typePrefix>
  <vendor>Alpha</vendor>
  <model>X 128 ГБ</model>
  <price>29990</price>
  <currencyId>RUR</currencyId>
  <categoryId>2</categoryId>
</offer>

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

Штатная выгрузка на экспорт в 1С-Битрикс

Теперь к практике на Битриксе. В коробочной редакции с модулем «Торговый каталог» есть штатный механизм экспорта каталога в YML — его не нужно писать с нуля для типового случая. Он живёт в административной части в разделе экспорта данных торгового каталога.

Что делает штатная выгрузка «из коробки»:

• Формирует YML-файл из выбранного инфоблока каталога: собирает shop, валюты, дерево категорий из разделов и список offer из товаров.
• Подставляет цены и наличие из настроенных типов цен и данных о количестве, отражая атрибут available.
• Отдаёт файл по постоянному URL, который вы указываете площадке; та периодически забирает свежую версию.
• Обновляется по агенту — Битрикс перегенерирует файл по расписанию, чтобы данные не устаревали.

Путь настройки в общих чертах такой: в административной части открываете экспорт торгового каталога, создаёте профиль экспорта в формат Яндекс Маркет (YML), выбираете инфоблок-каталог, задаёте, какие разделы и товары выгружать, сопоставляете поля и свойства, включаете автоматическое обновление. На выходе получаете URL фида, который отдаёте площадке. Это фундамент; тонкая настройка полей и категорий — в следующих разделах.

Важная оговорка: штатная выгрузка хорошо закрывает базовый сценарий, но у неё есть потолок гибкости. Когда нужны нестандартный маппинг категорий, свои param под требования конкретной системы, UTM-метки, разные фиды под разные каналы или высокая производительность на большом каталоге — штатного механизма перестаёт хватать, и его либо расширяют своим кодом (через события и API Битрикса), либо заменяют кастомным генератором. Такие доработки мы делаем в рамках проектов по интеграции магазина с площадками.

Настройка профиля выгрузки

Профиль экспорта — это набор правил, по которым Битрикс превращает каталог в конкретный YML-файл. Один профиль = один фид. Разберём, из чего он состоит и на что обращать внимание.

Ключевые настройки профиля:

• Источник данных. Какой инфоблок-каталог выгружаем и по каким торговым предложениям (если каталог с SKU-предложениями, важно выгружать именно торговые предложения с их ценами и остатками).
• Тип цены. Какой тип цены идёт в price. Для рекламы и Маркета обычно это розничная цена, но можно завести отдельный тип цены под канал.
• Разделы и фильтры. Какие разделы каталога включать в фид и по каким условиям отбирать товары (например, только в наличии).
• Поля и свойства. Какие свойства товара выгружать как param, что писать в vendor, vendorCode, description.
• Валюта. Валюта фида и её идентификатор в блоке currencies.
• Обновление. Периодичность автоматической перегенерации файла.

Хорошая практика — не пытаться уместить всё в один «универсальный» профиль, а держать по профилю на канал. Тогда для Маркета вы отдаёте один набор полей и фильтров, для Директа — другой, для агрегатора — третий, и изменение требований одной площадки не ломает остальные фиды. Профили удобно называть по каналу (например, «YML — Маркет», «YML — Директ смарт-баннеры»), чтобы не путаться при поддержке.

Сопоставление категорий с деревом площадки

Один из самых частых источников проблем с фидом — категории. В YML вы отдаёте своё дерево категорий (из разделов каталога Битрикса), но площадка сопоставляет его со своей номенклатурой. Если товар попал в неподходящую с точки зрения площадки категорию, карточка не пройдёт модерацию или встанет не туда.

Что важно сделать правильно:

• Уникальные id категорий. Каждая category в фиде обязана иметь уникальный id. Дубли идентификаторов ломают дерево.
• Целостность иерархии. Каждый parentId должен указывать на категорию, которая реально присутствует в этом же фиде. Ссылка на несуществующий раздел — ошибка.
• Осознанный маппинг. Не всегда стоит выгружать своё дерево «как есть». Иногда разделы каталога сайта не совпадают с логикой категорий площадки, и их нужно сопоставить: ваш раздел «Гаджеты» → категория площадки «Смартфоны и аксессуары».
• Привязка offer. Каждый categoryId в offer обязан соответствовать существующей в фиде категории.

Если площадка «не принимает категории», в 90% случаев дело в одном из этих пунктов: нарушенная иерархия, неуникальные id или несоответствие вашего дерева ожиданиям площадки. Для крупных каталогов имеет смысл вести отдельную таблицу маппинга «раздел каталога → категория площадки» и применять её при генерации фида, а не полагаться на автоматический перенос дерева один в один.

Сопоставление свойств с param

Характеристики товара передаются в YML через теги param: у каждого есть атрибут name (название характеристики) и значение. Это то, из чего площадка строит фильтры и что показывает в карточке. Чем полнее и точнее заполнены param, тем выше качество карточки и тем по большему числу фильтров товар находится.

<offer id="1024" available="true">
  <name>Смартфон Alpha X 128 ГБ</name>
  <price>29990</price>
  <currencyId>RUR</currencyId>
  <categoryId>2</categoryId>
  <vendor>Alpha</vendor>
  <param name="Цвет">Чёрный</param>
  <param name="Объём памяти" unit="ГБ">128</param>
  <param name="Диагональ экрана" unit="дюйм">6.5</param>
</offer>

При настройке выгрузки на Битриксе вы сопоставляете свойства инфоблока с param фида: свойство «Цвет» → param name="Цвет", свойство «Память» → param name="Объём памяти" и так далее. Тонкости, которые важно учитывать:

• Имена param должны совпадать с ожиданиями площадки. Некоторые системы распознают конкретные названия характеристик; произвольные имена они могут проигнорировать при построении фильтров.
• Единицы измерения. Там, где площадка ждёт числовое значение с единицей, значение и единицу передают корректно (через атрибут unit или в тексте значения — по требованиям канала).
• Чистота данных. Мусорные значения в свойствах каталога попадут прямо в фид. Поэтому качество данных о товаре в Битриксе напрямую влияет на качество карточки на площадке.

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

Цены в фиде: price, oldprice, currencyId

Цена — одна из двух самых чувствительных сущностей в фиде (вторая — наличие). Ошибка в цене видна покупателю сразу и бьёт по деньгам. Разберём три связанных тега.

• price — текущая цена продажи. Это то, что площадка показывает как актуальную цену. Значение — число без пробелов и символа валюты.
• oldprice — цена до скидки. Если она указана и больше price, площадка показывает перечёркнутую старую цену и размер скидки, что повышает кликабельность. Указывать oldprice меньше или равной price нельзя — это ошибка валидации.
• currencyId — валюта, в которой указана цена. Обязана присутствовать в блоке currencies фида. Несоответствие валюты offer и списка валют — типовая ошибка.

Практические моменты. Во-первых, цена в фиде должна совпадать с ценой на карточке сайта: если площадка перейдёт по url и увидит другую цену, это провоцирует претензии и понижение доверия к магазину. Во-вторых, для рекламных и торговых каналов иногда заводят отдельный тип цены, чтобы управлять ценой канала независимо от розницы на сайте, — тогда в профиле фида выбирают именно этот тип цены. В-третьих, при акциях важно, чтобы price и oldprice обновлялись синхронно с сайтом, иначе площадка покажет скидку, которой уже нет.

Остатки и доступность: available

Наличие товара в YML передаётся атрибутом available у тега offer: true — товар доступен к заказу, false — нет. Это самая динамичная информация в фиде: остаток меняется при каждой продаже во всех каналах сразу.

Почему это критично именно для фида:

• Отмены и претензии. Если товар закончился, а в фиде всё ещё available="true", площадка предлагает его покупателю, тот оформляет заказ — и вы вынуждены отменять. Для маркетплейсов это ещё и штрафы и понижение рейтинга.
• Впустую потраченный рекламный бюджет. В товарной рекламе показ и клик по отсутствующему товару — это слитые деньги: покупатель приходит на карточку, а купить нельзя.
• Скорость важнее всего. Чем быстрее available в фиде отражает реальный склад, тем меньше «окно» рассинхрона.

Здесь важно, чтобы каталог Битрикса корректно вёл количество и признак наличия, а генератор фида отдавал available на основе актуального остатка. Если у вас единый источник остатков (в 1С), он раздаётся и на сайт, и в фид, поэтому наличие в фиде совпадает с реальным складом. Тему единого пула остатков и защиты от продаж несуществующего товара мы подробно разбираем в статье про интеграцию Битрикса с маркетплейсами — она напрямую связана с тем, насколько честен ваш фид по наличию.

Актуальность цен и остатков в фиде

Мы дважды упомянули, что цены и остатки должны быть свежими. Разберём отдельно, что это значит на практике и как этого добиваются. Проблема в том, что фид — это статический файл, снимок каталога на момент генерации. Между двумя генерациями данные в фиде «замороженные».

Есть два принципиальных подхода к обновлению:

• Полная перегенерация по расписанию. Раз в N минут/часов система заново собирает весь фид из каталога. Просто, но между генерациями есть «окно» устаревания, а на большом каталоге частая полная перегенерация тяжела для сервера.
• Разделение потоков. Карточки (название, описание, картинки, param) меняются редко — их перегенерируют реже. Цены и остатки меняются часто — их обновляют чаще, отдельным лёгким процессом, а не пересобирая весь файл целиком.

Разумная стратегия — не гнать полную выгрузку огромного каталога каждые несколько минут, а балансировать: держать цены и наличие свежими за счёт частого обновления именно этих данных, а тяжёлую перегенерацию карточек делать по расписанию реже. Отдельно стоит предусмотреть, что делать при сбое генерации: если процесс упал, площадке нельзя отдавать пустой или битый файл — лучше оставить предыдущую валидную версию и поднять оповещение, чем сломать фид целиком.

Обновление по расписанию: агент и cron

Автоматическое обновление фида в Битриксе реализуют двумя основными механизмами, и выбор между ними влияет на надёжность и точность расписания.

Агенты Битрикса

Агент — это внутренний механизм отложенных заданий Битрикса. Штатная выгрузка YML по умолчанию обновляется именно агентом. Плюс — не нужно ничего настраивать на уровне сервера, всё внутри CMS. Минус — агенты на «хитовом» запуске выполняются во время посещений сайта, поэтому их точность и регулярность зависят от трафика, а тяжёлая генерация может тормозить ответ пользователю.

Cron

Cron — планировщик на уровне сервера, который запускает задание строго по расписанию, независимо от посещений сайта. Для регулярной генерации больших фидов это надёжнее: тяжёлую выгрузку выносят в отдельный скрипт и запускают по cron, а агенты Битрикса переводят в режим запуска через cron, чтобы они не зависели от трафика.

1. Определите частоту. Отдельно для карточек (реже) и для цен/остатков (чаще), исходя из динамики каталога и нагрузки на сервер.
2. Вынесите тяжёлую генерацию в скрипт. Полную перегенерацию фида делайте отдельным процессом, а не «на хите» во время визита пользователя.
3. Запускайте по cron. Настройте запуск генератора по расписанию на уровне сервера, чтобы он не зависел от посещаемости.
4. Пишите в файл атомарно. Генерируйте во временный файл и подменяйте боевой только после успешного завершения — площадка никогда не должна увидеть наполовину записанный фид.
5. Логируйте и оповещайте. Фиксируйте время и результат генерации; при сбое присылайте оповещение, чтобы фид не «протух» незаметно.

Правильно настроенный cron превращает фид из «файла, который кто-то иногда обновляет руками» в надёжный автоматический процесс. Это тот случай, когда полчаса на настройку расписания экономят дни разбирательств с площадкой из-за устаревших данных.

Несколько фидов под разные площадки

Мы уже отмечали: один универсальный фид «на всех» — плохая идея. Разберём почему и как организовать несколько фидов из одного каталога.

Причины держать отдельные фиды:

• Разные форматы. Маркет и Директ едят YML, Google Merchant — свой формат с полями g:, VK/MyTarget — свои требования. Одним файлом это физически не покрыть.
• Разный набор полей. Одной площадке нужны определённые param, другой — gtin/brand, третьей достаточно минимума. Тащить всё в один файл — плодить лишнее и ловить ошибки валидации.
• Разная фильтрация. На Маркет вы можете выгружать один срез ассортимента, в рекламу — другой (например, только маржинальные позиции в наличии).
• Разные UTM. У каждого канала свой utm_source в ссылках, чтобы разделять трафик в аналитике.

Организационно это делается через несколько профилей выгрузки поверх единого каталога: источник данных один, а «упаковка» разная. Так вы ведёте товар один раз, а система отдаёт его в нужном виде под каждый канал. Добавление новой площадки становится добавлением ещё одного профиля, а не переделкой всего. Это и есть подход «единый каталог — много фидов», который масштабируется без хаоса.

Фильтрация товаров в фид

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

• Только в наличии. Самый частый фильтр: не выгружать в фид товары с нулевым остатком, чтобы не предлагать площадке то, чего нет. Особенно важно для рекламных фидов, где показ отсутствующего товара — слитый бюджет.
• Определённые разделы. В фид попадают только выбранные разделы каталога — например, товары тех категорий, где вы действительно готовы торговать на этом канале.
• Ценовой порог. Иногда исключают слишком дешёвые позиции, где комиссия и логистика съедают маржу, или, наоборот, слишком дорогие, неуместные для канала.
• Полнота карточки. Разумно не выгружать товары без картинки, без цены или без обязательных характеристик — они всё равно не пройдут модерацию и только испортят статистику фида.
• Признак товара. Через отдельное свойство в каталоге («выгружать в Маркет: да/нет») можно точечно управлять составом фида на уровне товара.

Хорошая практика — вести флаг участия в фиде как свойство товара, а не хардкодить условия. Тогда контент-менеджер управляет составом фида из привычной карточки товара, а не через программиста. А базовые фильтры (в наличии, с картинкой, с ценой) применяются автоматически на этапе генерации, отсекая заведомо невалидные предложения ещё до отправки площадке.

UTM-метки в ссылках фида

Ссылка на карточку товара живёт в теге url каждого offer. Для рекламных и товарных фидов к ней добавляют UTM-метки, чтобы в аналитике отделять переходы из фида от остального трафика и понимать, какой канал и какая кампания приносят продажи.

<url>https://example.ru/catalog/alpha-x/?utm_source=market&amp;utm_medium=cpc&amp;utm_campaign=feed</url>

На что обратить внимание при добавлении UTM в фид:

• Экранирование амперсанда. В XML символ & внутри URL записывается как сущность &. Неэкранированный амперсанд ломает валидность фида — это одна из самых частых ошибок.
• Разные метки под каналы. В фиде для Маркета один utm_source, в фиде для Директа другой, в VK третий. Это и есть аргумент за отдельные фиды под каналы.
• Идентификатор товара. Иногда в utm_content или отдельном параметре передают артикул/идентификатор товара, чтобы в аналитике видеть эффективность по конкретным позициям.
• Не плодить дубли для SEO. На стороне сайта UTM-хвост не должен создавать индексируемые дубли карточки: канонический адрес остаётся чистым, а параметры отбрасываются или канонизируются.

Аккуратно проставленные UTM превращают фид из «чёрного ящика» в измеримый канал: вы видите в сквозной аналитике, сколько трафика и выручки приносит каждый фид, и можете принимать решения на цифрах, а не на ощущениях. Как выстроить эту связку до уровня выручки, мы разбираем в материале про сквозную аналитику ecommerce на Битриксе.

Фиды для рекламы: Директ, VK, Google

Товарный фид — это топливо не только для маркетплейсов, но и для рекламы. Разберём, как фид используется в рекламных системах и чем их требования отличаются.

Яндекс Директ: товарные и динамические кампании

На основе YML-фида Директ строит смарт-баннеры, динамические объявления и товарные кампании: система сама берёт из фида название, цену, картинку и ссылку и собирает объявление по товару. Здесь особенно важны корректная цена, рабочая картинка, доступность и ссылка с UTM. Фид для рекламы обычно фильтруют жёстче: только товары в наличии, с картинкой и адекватной ценой.

VK Реклама / MyTarget

Динамический ретаргетинг и товарные карусели строятся на фиде с идентификаторами товаров, ценами, картинками и ссылками. Требования к полям и формату могут отличаться от классического YML, поэтому под этот канал нередко готовят отдельный фид.

Google Merchant Center

У Google собственный формат фида (XML или CSV) со своими полями в пространстве имён g:: g:id, g:title, g:description, g:price, g:availability, g:image_link, g:brand, g:gtin и другие. YML сюда напрямую не подходит — нужен отдельный генератор под спецификацию Google.

Общий вывод: рекламные фиды предъявляют к качеству данных даже более высокие требования, чем маркетплейсы, потому что здесь за каждый показ и клик платят деньгами. Битая картинка, устаревшая цена или отсутствующий товар в рекламном фиде — это прямые убытки, а не просто косметический дефект.

Валидация фида и типовые ошибки

Никогда не отдавайте фид площадке, не проверив его валидатором. Валидация ловит проблемы до того, как их увидит площадка и до того, как они превратятся в отклонённые товары или слитый бюджет. Разберём, что проверяют и какие ошибки встречаются чаще всего.

Порядок проверки обычно такой: сначала прогоняют фид через валидатор формата (проверка XML-схемы и обязательных полей), затем — через валидатор конкретной площадки (Маркета, Merchant Center), который дополнительно проверяет свои требования к категориям и атрибутам. Только после того как обе проверки чистые, фид выводят в бой. Для больших каталогов валидацию встраивают в сам процесс генерации: если после сборки файл не проходит базовые проверки, боевой фид не подменяется, а поднимается оповещение.

Большой каталог и производительность

Пока в каталоге пара тысяч товаров, о производительности выгрузки можно не думать. Но на десятках и сотнях тысяч предложений наивная генерация «выбрать всё и собрать документ в памяти» упирается в лимиты памяти и времени выполнения. Разберём приёмы, которые делают выгрузку большого каталога реальной.

• Потоковая запись. Не собирать весь XML в переменной, а писать его в файл по мере генерации offer. Это держит потребление памяти постоянным независимо от размера каталога.
• Порционная выборка. Читать товары пачками (пагинация), а не одним гигантским запросом, чтобы не тянуть весь каталог в память разом.
• Только нужные поля. Выбирать из базы только те свойства и данные, что реально идут в фид, а не всю карточку целиком.
• Кэш редко меняющегося. Категории и описания меняются редко — их можно кэшировать и не пересобирать каждый раз.
• Разделение потоков. Часто обновлять только цены и остатки, а полную перегенерацию карточек делать реже — это резко снижает нагрузку.
• Готовый статический файл. Отдавать площадке уже сгенерированный файл, а не собирать XML на каждый её запрос. Генерация — по расписанию в фоне.

Для очень больших каталогов производительность фида — это вопрос архитектуры выгрузки, а не одной галочки в настройках. Штатная выгрузка Битрикса на гигантских каталогах может не справляться по времени, и тогда пишут кастомный генератор с потоковой записью и порционной выборкой. Это ровно та инженерная работа, которую мы закладываем в проекты с большим ассортиментом — чтобы фид собирался за минуты, а не падал по таймауту.

Частые ошибки

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

• Один универсальный фид на всё. Пытаются обслужить Маркет, Директ, VK и Google одним файлом — везде получают компромисс и ошибки валидации. Нужны отдельные фиды под каналы.
• Редкое обновление. Фид обновляется раз в сутки, а цены и остатки меняются постоянно — площадка целый день показывает устаревшие данные.
• Битые и относительные ссылки на картинки. В picture отдают относительный путь или ссылку на удалённый файл — карточка остаётся без фото.
• Неэкранированные символы. Амперсанд в названии или URL ломает XML, и площадка не может распарсить фид целиком.
• Категории «как есть». Выгружают дерево разделов сайта без маппинга — площадка не принимает категории.
• Нарушенная иерархия category. parentId ссылается на несуществующий раздел или id категорий не уникальны — дерево ломается.
• Валюта offer вне списка. currencyId ссылается на валюту, которой нет в блоке currencies.
• oldprice меньше или равен price. Скидка невалидна — предложение отклоняется.
• Выгрузка товаров без остатка в рекламу. Реклама ведёт на отсутствующий товар — слитый бюджет и раздражённый покупатель.
• Нет мониторинга генерации. Фид «протух» или собрался битым, а узнают об этом из падения продаж, а не из оповещения.

Чек-лист фида

Короткий список, по которому удобно свериться перед тем, как отдать фид площадке:

1. Валидность XML. Файл в UTF-8, все спецсимволы экранированы, структура yml_catalog → shop → offers соблюдена.
2. Обязательные поля offer. У каждого предложения есть name, price, currencyId, categoryId, picture, url и корректный available.
3. Валюты и категории. Все currencyId есть в currencies, все categoryId — в дереве category, иерархия целостна.
4. Маппинг категорий. Разделы сопоставлены с категориями площадки, а не выгружены «как есть».
5. Цены. Цена совпадает с сайтом, oldprice больше price там, где указан.
6. Остатки. available отражает реальный склад, товары без остатка отфильтрованы (особенно в рекламе).
7. Картинки. Абсолютные рабочие ссылки, картинки доступны по URL.
8. UTM. В ссылках проставлены метки под канал, амперсанды экранированы, дубли для SEO не создаются.
9. Обновление. Настроен запуск по cron, файл пишется атомарно, есть логирование и оповещение о сбоях.
10. Валидация. Фид прошёл валидатор формата и валидатор площадки до вывода в бой.

Вывод

Экспорт товаров в YML-фиды на 1С-Битрикс — это не «выгрузка файла раз и навсегда», а живой процесс, от качества которого зависит, как ваш каталог выглядит и продаёт во внешних каналах. YML — строгий диалект XML со своей структурой: shop, валюты, дерево категорий и список offer с фиксированными полами. Штатная выгрузка Битрикса закрывает базовый случай, а под нестандартные требования — маппинг категорий, свои param, UTM, несколько фидов, большой каталог — её расширяют или заменяют кастомным генератором.

Главное помнить: критичнее всего актуальность цен и остатков, поэтому фид обновляют часто и по расписанию через cron, а не руками; под разные каналы держат разные фиды со своими форматами, полями и UTM; каждый фид обязательно проверяют валидатором до вывода в бой. Начните с чистого каталога и корректного маппинга категорий, настройте обновление и фильтрацию, добавьте UTM и мониторинг — и фид станет надёжным управляемым каналом продаж и рекламы, а не источником отклонённых товаров и слитого бюджета.