Чем товарный фид отличается от прайса
Первое недоразумение, из-за которого выгрузка потом переделывается по три раза: товарный фид путают с прайсом для менеджера. Прайс отвечает на вопрос «сколько стоит». Фид отвечает на десяток вопросов сразу: что это за товар, как он называется на витрине площадки, куда ведёт ссылка, какая у него картинка, есть ли он на складе прямо сейчас, к какой категории его отнести, чем он отличается от соседнего размера или цвета.
Площадка не смотрит на ваш сайт, она смотрит только в файл. Если в файле указано, что товар в наличии, а на сайте он закончился неделю назад, покупатель придёт по объявлению на страницу «нет в наличии», и деньги за клик уже потрачены. Поэтому качество фида упирается в одну вещь: насколько честно он отражает состояние каталога в момент выгрузки.
У 1С-Битрикс здесь стартовая позиция лучше, чем у большинства CMS. Торговый каталог с торговыми предложениями, свойствами, ценами по типам и складским учётом уже есть в ядре. Данные для фида не нужно собирать из пяти таблиц, они лежат в структуре, которая ровно для этого и придумана. Вопрос только в том, как вытащить их в нужный формат.
Что умеет штатный экспорт 1С-Битрикс
Настройки лежат в разделе «Магазин» → «Настройки» → «Экспорт данных». Если модуль «Интернет-магазин» на проекте не установлен и работает только «Торговый каталог», путь другой: «Магазин» → «Торговый каталог» → «Экспорт данных».
В стандартной поставке доступно два типа экспорта: Froogle и Yandex. Второй существует в двух вариантах, обычном и упрощённом (Simple). В упрощённом нельзя выбрать отдельные разделы каталога, выгружается весь.
Профиль выгрузки Yandex настраивается по вкладкам. На вкладке «Настройка выгрузки» задаётся тип описания оффера (упрощённое, vendor.model, book, audiobook, artist.title), источник описания (анонс или детальный текст), дополнительные свойства и режим выгрузки торговых предложений: все предложения, только минимальная цена или отбор по свойству. Вкладка «Валюты и цены» отвечает за то, какой тип цены выгружать и в какой валюте, с указанием источника курса (курс сайта, ЦБ РФ, НБУ, НБК или региональный банк) и коррекции курса. На вкладке «НДС» указывается, выгружать ли ставки налога и какая ставка считается базовой.
Готовый файл система кладёт в каталог /bitrix/catalog_export/ под тем именем, которое вы задали в профиле. Файл с тем же именем перезаписывается, отдельной истории версий не ведётся. Чтобы файл обновлялся сам, к профилю добавляется агент, а площадка забирает результат по прямой ссылке.
Об одном ограничении лучше знать до начала работ. Штатная выгрузка отдаёт только общие для всех типов поля и не поддерживает специализированные атрибуты вроде ISBN для книг или длительности для фильмов. Как только каталог перестаёт быть «просто товарами», начинается доработка.
Google Merchant: семь обязательных полей и длинный хвост условных
Безусловно обязательных атрибутов у Google семь: id, title (либо structured_title), description (либо structured_description), link, image_link, availability и price. Без любого из них товар не пройдёт ни в объявления, ни в бесплатные листинги.
Дальше идёт блок условно обязательных атрибутов, и спотыкается на нём большинство магазинов:
brandнужен для новых товаров всех категорий, кроме фильмов, книг и музыки;gtinобязателен, если у товара есть известный производителю штрихкод;mpnтребуется, когда GTIN у производителя не предусмотрен;identifier_existsсо значениемnoставится товарам, у которых нет ни GTIN, ни MPN, ни бренда;conditionнужен для бывших в употреблении и восстановленных товаров;availability_dateобязателен приavailability: preorder;item_group_idтребуется товарам с вариантами;color,size,age_groupиgenderнужны для одежды и товаров с вариантами, конкретный набор зависит от страны.
Цена оформляется по стандарту ISO 4217 с точкой в роли десятичного разделителя: 1500.00 RUB. Для всех стран, кроме США и Канады, налог включается в стоимость.
Merchant Center принимает файлы в форматах TXT, TSV и XML, включая RSS 2.0 и Atom 1.0. Максимальный размер файла составляет 4 ГБ, кодировка UTF-8 или UTF-16. Забрать файл площадка может двумя способами: вы загружаете его с компьютера либо даёте ссылку, начинающуюся с http://, https:// или sftp://.
Тут важная деталь для проекта на 1С-Битрикс. Отдельного штатного профиля под Google Merchant в системе нет. Есть Froogle, исторический предшественник Google Shopping, и опираться на него как на готовое решение под актуальные требования Merchant Center рискованно: список обязательных атрибутов с тех пор заметно вырос. На практике экспорт товаров в Google Merchant с Битрикса собирают одним из трёх способов: решением из Маркетплейса, собственным скриптом выгрузки или доработкой штатного профиля под нужный набор полей.
Торговые предложения и атрибут item_group_id
Отдельного разговора заслуживают товары с вариантами, потому что архитектура Битрикса и логика Google тут расходятся.
В 1С-Битрикс торговое предложение представляет собой самостоятельный элемент инфоблока, привязанный к родительскому товару. Футболка одного артикула в пяти размерах даёт пять элементов. Google ждёт того же: каждый вариант приходит как отдельный оффер со своим id, своей ценой и своим наличием. Связывает их атрибут item_group_id, одинаковый у всех вариантов одной модели.
Ошибок тут обычно две. Первая: выгрузка отдаёт только родительский товар с минимальной ценой, и покупатель, кликнувший по объявлению за 4 900 тенге, попадает на карточку, где его размер стоит 7 400. Вторая: варианты выгружаются как независимые товары без общего item_group_id, и площадка считает их пятью разными позициями со всеми вытекающими для показов.
В штатном профиле Yandex режим выгрузки торговых предложений выбирается прямо в настройках: все предложения, только минимальная цена или отбор по свойству. Для рекламы почти всегда нужен первый вариант. Режим минимальной цены имеет смысл там, где предложения различаются несущественно для покупателя, например упаковкой одного и того же товара.
Яндекс: структура YML и два типа офферов
YML используется и Маркетом, и рекламными инструментами Директа: динамическими объявлениями, смарт-баннерами, товарными кампаниями. Для казахстанского бизнеса вторая часть обычно важнее первой. Один и тот же файл, собранный под выгрузку каталога, становится источником данных для рекламы, и это неплохой аргумент за то, чтобы сделать его аккуратно.
Структура файла выглядит так. Корневой элемент <yml_catalog> с атрибутом date в формате YYYY-MM-DD hh:mm, внутри него <shop>. Блоки <currencies> и <categories> обязаны идти до блока <offers>. Блок <collections> необязателен.
Дальше место, где ломается больше всего фидов. Требования к офферу зависят от того, указан ли у него атрибут type.
Упрощённый тип, без атрибута type, требует <id>, <name>, <categoryId>, <url> и <price>, последний нужен для показов в товарной галерее. Если у оффера нет <name>, Директ его проигнорирует, и объявление не сгенерируется.
Тип vendor.model требует другой набор: <id>, <vendor>, <model>, <categoryId>, <url>. Отсутствие <vendor> или <model> даёт ошибку, и оффер выпадает из фида.
Отсюда ошибка, которую мы видим регулярно. В профиле выгрузки выбран тип описания vendor.model, потому что «так подробнее», а свойство «Производитель» в инфоблоке заполнено у трети товаров. Формально фид валиден, площадка принимает его без замечаний. Фактически две трети каталога в рекламу не попадают, и по интерфейсу этого не увидеть: нужно открыть файл и посчитать офферы.
Один каталог, два фида: как не собирать данные дважды
Соблазн понятный: сделать один универсальный файл и скормить его обеим площадкам. Так не выйдет, схемы несовместимы на уровне формата. Собирать данные дважды тоже незачем.
Рабочая схема, которую мы используем на проектах, делит выгрузку на слой подготовки данных и слой рендеринга.
Слой подготовки решает содержательные вопросы. Какие разделы каталога вообще участвуют в выгрузке. Какие товары исключаются: снятые с производства, с нулевым остатком, без картинки, дороже определённой суммы. Откуда берётся название, из поля «Название» или из связки «бренд + модель + артикул». Что подставляется, когда свойство не заполнено. Как формируется ссылка, с UTM-метками или без них.
Слой рендеринга уже ничего не решает, он раскладывает готовый массив по нужной схеме: в YML-теги для Яндекса, в g:-атрибуты для Google.
Выгода видна на второй итерации. Когда маркетолог просит убрать из выгрузки товары с остатком меньше двух штук, правка делается в одном месте и применяется к обоим фидам. Если фиды собраны двумя независимыми скриптами, такая правка расходится: один поправили, про второй забыли, через месяц статистика по каналам перестала сходиться, и полдня уходит на поиск причины.
Где выгрузка ломается чаще всего
За несколько лет работы с каталогами на 1С-Битрикс набор проблем повторяется почти без вариаций.
Картинки. У товара в карточке изображение есть, а в фид уходит пустой image_link. Причина обычно в том, что картинка лежит в свойстве торгового предложения, а выгрузка берёт её у родительского товара, либо наоборот. Google товар без изображения не примет.
Остатки. Каталог использует складской учёт, но в фид уходит availability: in stock для всех подряд, потому что выгрузка ориентируется на флаг активности вместо количества. Со стороны бизнеса это видно как рост отказов на карточках товара и падение конверсии при формально хорошем CTR.
Цены. В магазине несколько типов цен: розница, опт, цена для авторизованных. В профиле выгрузки выбран не тот тип, площадка получает оптовую цену, сверяет её с ценой на посадочной странице, находит расхождение и отклоняет товар.
Категории. Дерево разделов строилось под удобство менеджеров и содержит разделы «Акции» и «Новинки», в которые товар попадает вторым и третьим вхождением. В фид уезжают дубли одной и той же позиции под разными categoryId.
Кодировка. Проект работает в CP1251, на 1С-Битрикс это до сих пор встречается. Файл фида при этом обязан быть в UTF-8. Если перекодировка не сделана на этапе генерации, площадка получит XML с битыми кириллическими символами и просто откажется его разбирать.
Время генерации. Каталог на 60 тысяч предложений собирается не мгновенно. Агент, запускающийся на живом сервере в час пик, заметно роняет скорость магазина. Лечится переносом генерации на ночь и, если каталог большой, выносом задачи в консольный скрипт по cron вместо агента на хитах.
Как это выглядит в работе: разбор одного каталога
Пример ниже условный, собран из типичных ситуаций, но порядок действий в нём настоящий.
Магазин инструмента, около 12 тысяч торговых предложений, сайт на 1С-Битрикс. Реклама запущена, расход идёт, заявок мало. Первое действие: скачиваем текущий фид по той самой ссылке, которую использует площадка, и считаем в нём офферы. В каталоге 12 тысяч предложений, в файле 4100 офферов.
Дальше разбираем разницу. Около 3000 позиций отпали из-за того, что в профиле выбран тип vendor.model, а производитель не заполнен. Ещё примерно 2500 отсеялись как товары без картинки в торговом предложении. Оставшиеся выпали по разделам, которые в выгрузку не включены.
Порядок работ после такой ревизии обычно один и тот же. Сначала правятся данные в каталоге: производитель заполняется массовой обработкой по артикулам, картинки подтягиваются от родительских товаров там, где у предложения своей нет. Потом меняется логика выгрузки. И только после этого имеет смысл трогать настройки рекламных кампаний. Обратный порядок бесполезен: оптимизировать ставки на фиде, в котором нет двух третей ассортимента, значит оптимизировать пустоту.
Стоит зафиксировать ещё одно. Полнота фида не бывает разовой работой. Через три месяца в каталоге появятся новые позиции, заведённые менеджером без бренда и без картинки, и история повторится. Поэтому вместе с выгрузкой имеет смысл сразу настраивать отчёт: сколько товаров в каталоге, сколько попало в фид, какой процент отсева и по каким причинам.
Расписание обновления и контроль
Частота обновления определяется тем, как быстро меняются данные. Магазин с фиксированными ценами и большими остатками спокойно живёт на суточном обновлении. Магазин, где цена привязана к курсу, а остаток измеряется штуками, требует нескольких обновлений в день.
Технически на 1С-Битрикс это решается двумя путями. Штатный путь, агент, привязанный к профилю выгрузки, прост в настройке, но выполняется на хитах посетителей, что для тяжёлой выгрузки нежелательно. Предсказуемее работает консольный скрипт, запускаемый по cron в заданное время, с записью результата в лог.
Контроль лучше строить на трёх проверках, а не на самом факте того, что файл сформировался. Файл доступен по ссылке и отдаёт код 200. Количество офферов в нём не отличается от вчерашнего больше чем на заданный процент. Дата в атрибуте date у корневого элемента свежая. Резкое падение числа офферов почти всегда означает поломку в данных, а не внезапное сокращение ассортимента.
Если своей команды под такие работы нет, эту часть логично передать подрядчику вместе с сопровождением сайта. У нас разработка и поддержка сайтов на 1С-Битрикс включает и настройку выгрузок, и мониторинг того, что они продолжают работать после очередного обновления каталога.
Что привести в порядок до того, как трогать экспорт
Большая часть проблем с фидами живёт в каталоге, а не в коде выгрузки. Перед настройкой профиля полезно пройти по короткому списку.
- Идентификаторы должны быть стабильными.
idтовара в фиде не должен меняться при пересохранении карточки: площадка сопоставляет по нему статистику, и плавающий идентификатор обнуляет накопленные данные. - Бренд должен быть заполнен, даже если вы не планируете тип vendor.model. Google требует
brandдля новых товаров всех категорий, кроме фильмов, книг и музыки. - Со штрихкодами порядок такой: GTIN обязателен, когда он известен производителю; если его нет, нужен MPN; если нет и MPN, товар помечается через
identifier_existsсо значениемno. Пустое место в этих полях площадка трактует не в вашу пользу. - Определитесь, где живёт изображение, у товара или у торгового предложения, и держите одно правило по всему каталогу.
- Маркетинговые подборки вроде «Хиты» и «Распродажа» лучше строить на свойствах и умных фильтрах, а не на дополнительных привязках товара к разделам. Тогда в фид уйдёт одно вхождение вместо трёх.
- Название в фиде видит покупатель в объявлении. «Дрель ударная Makita HP1630 710 Вт» работает, «HP1630» не работает.
Когда каталог в таком состоянии, экспорт товаров в Google Merchant и выгрузка в Яндекс.Маркет перестают быть проектом на две недели и превращаются в задачу на несколько часов. И сам фид перестаёт разваливаться от каждой новой партии товаров, заведённой в спешке.
Частые вопросы
Можно ли обойтись штатным экспортом 1С-Битрикс без доработок?
Для Яндекса часто да, если каталог простой и нужные поля заполнены: профиль Yandex в разделе «Магазин» → «Настройки» → «Экспорт данных» отдаёт валидный YML. С Google сложнее. Отдельного профиля Merchant Center в стандартной поставке нет, а список обязательных атрибутов у Google шире того, что покрывает старый Froogle, поэтому почти всегда нужна либо надстройка из Маркетплейса, либо собственная выгрузка.
Почему площадка приняла файл, но товаров в объявлениях меньше, чем в каталоге?
Файл может быть валидным и при этом неполным. Оффер без обязательного элемента просто игнорируется, а сам файл остаётся корректным. На стороне Яндекса чаще всего виноват выбранный тип vendor.model при незаполненном производителе. На стороне Google это обычно отсутствие image_link, бренда или идентификаторов. Проверяется просто: посчитайте офферы в файле и сравните с числом товаров в каталоге.
Обязательно ли делать два отдельных файла для Google и Яндекса?
Да, форматы описывают товар по-разному, и общим файлом обойтись не получится. Дублировать при этом нужно только финальный рендеринг: логику отбора товаров и подготовки полей разумно держать общей для обеих выгрузок.
Как часто обновлять фид?
Ориентируйтесь на скорость изменения цен и остатков. Сутки можно считать разумным минимумом для стабильного ассортимента. Если цена привязана к курсу или остатки штучные, обновляйте несколько раз в день, а генерацию выносите на cron, чтобы не нагружать сайт в рабочие часы.
Сайт работает в CP1251, это проблема?
Не проблема, но требует внимания. Файл фида должен быть в UTF-8, Merchant Center принимает UTF-8 или UTF-16. Перекодировка делается на этапе генерации файла. Если её пропустить, площадка получит XML с повреждённой кириллицей и разбирать его не станет.
Можно ли использовать один YML и для Маркета, и для рекламы в Директе?
Формат один, но требования к обязательным элементам оффера у рекламных инструментов свои. Прежде чем подключать существующий файл к динамическим объявлениям или смарт-баннерам, проверьте, что у офферов есть полный набор полей для выбранного типа. Иначе часть товаров просто не сгенерирует объявления.