Налаштування YML-фіду для Яндекс.Маркет у Бітрікс

Ми часто стикаємося з ситуацією: клієнт запускає товарну рекламу в Яндекс.Маркеті, а система повідомляє, що 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 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (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 з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• 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-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.