Настройка фида товарной рекламы для Яндекс.Маркета в 1С-Битрикс

Мы часто сталкиваемся с ситуацией: клиент запускает товарную рекламу в Яндекс.Маркете, а система сообщает, что 30% товаров не участвуют. Не хватает обязательных атрибутов. На одном проекте из 12 000 позиций в рекламу уходило только 7 000. Причина — отсутствие тегов <param> с характеристиками: цвет, память, размер. Без них Яндекс не может правильно сопоставить товар с запросом, и эффективность кампании падает в 2–3 раза. Качественно настроенный фид решает эту проблему и экономит до 30% рекламного бюджета за счёт лучшего таргетинга. Снижает стоимость клика на 15-20% за счёт точного попадания в запрос.

Какие проблемы решает грамотный YML-фид?

Правильно сформированный фид — это не просто выгрузка каталога. Это возможность управлять тем, как Яндекс видит ваши товары. Без тегов <param> товары не участвуют в уточняющих запросах («купить смартфон 128 ГБ чёрный»). С ними — конверсия растёт на 15–25%. Кроме того, отсутствие профиля под товарную рекламу приводит к тому, что Яндекс не может корректно отображать объявления по моделям, брендам и категориям.

Почему стандартный экспорт не подходит?

Встроенный профиль (Каталог → Экспорт → Добавить профиль → Яндекс.Маркет (YML)) генерирует базовый фид, но не выгружает свойства инфоблока как <param>. Для товарной рекламы это критично: без параметров Яндекс не может показывать объявления по уточняющим запросам. Также стандартный экспорт не позволяет гибко управлять структурой торговых предложений, а при больших каталогах (от 50 000 товаров) время генерации достигает 2 часов.

Сравним подходы:

Кастомный генератор обрабатывает каталог из 50 000 позиций в 8 раз быстрее — 15 минут вместо 2 часов. Это особенно важно при ежедневном обновлении фида.

Как ускорить генерацию фида?

Для больших каталогов используйте потоковую запись XMLWriter без буферизации всего DOM. Например:

// /local/cron/yandex_market_feed.php
$categories = getIblockSections($IBLOCK_ID);
$tmpFile = tempnam(sys_get_temp_dir(), 'yml_');
$xml = new XMLWriter();
$xml->openUri($tmpFile);
$xml->startDocument('1.0', 'UTF-8');
// ... генерация структуры yml_catalog

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

Как добавить недостающие параметры в фид?

Решение — перехватить событие OnGetYmlOfferXml и добавить элементы <param>:

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'catalog',
    'OnGetYmlOfferXml',
    function (\Bitrix\Main\Event $event) {
        $offer = $event->getParameter('OFFER');
        $xml   = $event->getParameter('XML');

        $paramProps = ['COLOR' => 'Цвет', 'MEMORY' => 'Память', 'SCREEN_SIZE' => 'Диагональ экрана'];
        foreach ($paramProps as $propCode => $paramName) {
            if (!empty($offer['PROPERTIES'][$propCode]['VALUE'])) {
                $xml .= sprintf(
                    '<param name="%s">%s</param>',
                    htmlspecialchars($paramName),
                    htmlspecialchars($offer['PROPERTIES'][$propCode]['VALUE'])
                );
            }
        }

        return new \Bitrix\Main\EventResult(
            \Bitrix\Main\EventResult::SUCCESS,
            ['XML' => $xml]
        );
    }
);

Шаги:

1. Определите свойства инфоблока, которые нужно выгрузить как параметры (цвет, память, размер).
2. Напишите обработчик на OnGetYmlOfferXml, который добавляет <param> для каждого свойства.
3. Проверьте фид в личном кабинете Яндекс.Маркета.

Типичные ошибки и их устранение

Частая проблема — неверный формат даты в yml_catalog. Дата должна быть в формате YYYY-MM-DD HH:MM, иначе фид отклоняется. Дублирующиеся id офферов возникают, когда товары и торговые предложения имеют одинаковые ID. Решение — генерировать уникальные ID, например, 'Товар123-ТП1'. Недопустимые символы в XML (например, амперсанд) нужно заменять на &. И наконец, все товары должны иметь цену (тег price) — если цены нет, товар не участвует в выгрузке.

Что входит в настройку фида

Наши инженеры (опыт работы с Битрикс — более 5 лет, более 50 настроенных фидов) выполняют полный цикл:

• Анализ структуры каталога и свойств инфоблоков. Выявляем, какие характеристики важны для Яндекс.Маркета, и проверяем их заполнение.
• Проектирование схемы фида: определяем маппинг стандартных полей и добавляем кастомные параметры через события или кастомный генератор.
• Реализация: пишем обработчики или отдельный скрипт генерации, используем XMLWriter для производительности.
• Тестирование: загружаем фид в личный кабинет Яндекс.Маркета, проверяем на ошибки и валидность.
• Оптимизация производительности: для каталогов от 10 000 товаров настраиваем кэширование и потоковую запись.
• Интеграция с планировщиком cron для ежедневного обновления фида.

Оценка сроков настройки

Стандартный YML-профиль с маппингом свойств и добавлением <param> через хуки — 4–8 часов. Кастомный генератор для сложного каталога с торговыми предложениями и параметрами — 1–2 рабочих дня. Для точной оценки необходима консультация по вашему проекту.

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

Разработка парсеров для 1С-Битрикс: с чего начать?

XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (CSV с CP1251, XML в CommerceML, Excel с объединёнными ячейками) превращаются в единый каталог с общей системой свойств инфоблока.
• Обогащение карточек — подтягиваем характеристики, инструкции, 3D-модели с сайтов производителей. Без этого карточка товара — пустышка для SEO.
• Обновление ассортимента — товары, пропавшие из фида поставщика, деактивируются через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Новые — создаются. Каталог синхронизирован.

Какие инструменты используем в разработке парсеров?

Статические сайты — PHP (Goutte, Symfony DomCrawler) или Python (Scrapy, lxml). Скорость: 50–100 страниц/сек. Хватает для каталогов без JS-рендеринга.

SPA и динамические сайты — Puppeteer или Playwright. Бесконечный скролл, AJAX-фильтры, lazy-load картинок — headless-браузер всё это обработает. Скорость падает до 1–10 страниц/сек, но альтернативы нет: данные существуют только после выполнения JavaScript.

Файлы поставщиков:

• Excel (XLS, XLSX) — PhpSpreadsheet. Осторожно с объединёнными ячейками и формулами — они ломают автоматический маппинг.
• CSV — fgetcsv() с правильной кодировкой. Поставщики любят CP1251, BOM в UTF-8 и точку с запятой вместо запятой. Всё это нужно детектить и обрабатывать.
• XML/YML — XMLReader для больших файлов, SimpleXML для фидов до 50 МБ.
• CommerceML — стандартный формат обмена с 1С. Разбираем import.xml и offers.xml, маппим на структуру инфоблоков.

API — REST-эндпоинты поставщиков, API маркетплейсов (Ozon Seller API, Wildberries API). Работаем в рамках rate limits, обрабатываем пагинацию.

Как устроен пайплайн автонаполнения?

Четыре этапа. Каждый может сломаться по-своему.

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

2. Нормализация. Здесь основная работа:

   • Очистка HTML-тегов, лишних пробелов, Unicode-мусора
   • Единицы измерения: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Маппинг категорий поставщика → разделы инфоблока Битрикс. У одного поставщика «Ноутбуки», у другого «Ноутбуки и планшеты», у третьего «Laptops» — всё в одну секцию
   • Дедупликация по артикулу, EAN/GTIN. Один товар от трёх поставщиков не должен появиться трижды

3. Загрузка в Битрикс. Через CIBlockElement::Add() для новых элементов, CIBlockElement::Update() для существующих. Изображения: скачиваем, ресайзим через CFile::ResizeImageGet(), конвертируем в WebP. Свойства — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генерируем из транслитерации названия.

4. Обновление. Ключевой момент — не затереть ручные правки контент-менеджера. Обновляем только цену, остатки, активность. Описание и фото, доработанные вручную, помечаем флагом UF_MANUAL_EDIT в свойствах элемента и пропускаем при импорте. Товары, пропавшие из фида — деактивируем, но не удаляем.

Почему мониторинг цен конкурентов необходим?

Отдельная подсистема со своей спецификой:

Результат — дашборд: ваш товар vs конкуренты, история цен, тренды. Менеджер видит, где можно поднять цену без потери позиции, а где нужно реагировать.

Модуль импорта CSV/XML: настройка под ваш формат

Для файлов от поставщиков — кастомный модуль с админкой:

• Настраиваемый маппинг: «колонка B в файле → свойство BRAND инфоблока»
• Автодетект кодировки (CP1251, UTF-8, UTF-16) через mb_detect_encoding() с проверкой
• Загрузка изображений по URL с очередью — чтобы не забить канал
• Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
• Cron-расписание, отчёт: создано 145, обновлено 892, ошибок 3 (с деталями)

Большие файлы: CSV обрабатываем батчами по 1000 строк через fgetcsv(), XML потоково через XMLReader, фоновое выполнение через очередь агентов Битрикс — никаких PHP-таймаутов.

Правовая сторона — что важно учесть

• robots.txt — уважаем. Crawl-delay — соблюдаем.
• Частота запросов — 1–2 в секунду, не больше. Не нужно DDoS-ить чужой сайт.
• Контент производителей — используем. Уникальные авторские тексты — не копируем.
• Персональные данные — не собираем.

Что входит в разработку парсера под ключ?

Как мы работаем и сроки

1. Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
2. Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
3. Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
4. Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
5. Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.