Парсинг Яндекс.Маркет для каталогу на 1С-Битрикс: що ламається
Майданчик оновив ціни вночі, а вітрина на 1С-Битрикс залишилася на попередніх значеннях: покупець оформлює замовлення за ціною, якої вже немає, а менеджер бачить залишок, що не збігається з реальним складом.
Це не разовий збій, а штатна поведінка каталогу без регулярного обміну — парсинг Яндекс.Маркет перетворюється на набір ручних операцій, тоді як він має бути частиною потоку даних.
Причина зазвичай одна: зіставлення позицій відбувається за назвою. Назву постачальник править під час кожної рекламної кампанії, і зв'язок рветься — з'являються дублі, а частина товарів оновлюється не тим пропозиціям. Надійний ключ — артикул і штрихкод, а назва та опис залишаються редагованими полями.
Оновлення цін і залишків, запущене пакетом без журналу, під час обриву зв'язку залишає половину каталогу зі старими значеннями: наступне вивантаження стартує спочатку й не наздоганяє відсталі позиції.
Звідси ж і ручні правки карток — менеджер править заголовок або властивість, а черговий імпорт його перезаписує, бо редакторський контент не відокремлений від даних постачальника.
Замикає ланцюжок розбіжність каталогу й майданчика за наявністю: товари без наявності залишаються активними й ідуть у відмову, а кеш і пошуковий індекс тримають старе значення ще добу. Далі розбираємо, як це закривається на боці Битрикса.
Що дає регулярний обмін товарними даними з маркетплейсом
Разовий збір каталогу вирішує завдання на день, після чого ціни й залишки знову розходяться з реальністю. Регулярний обмін із Яндекс.Маркет будується як регламентне завдання: система сама забирає зміни за товарами й віддає оновлені ціни та наявність, залишаючи людям лише винятки.
Перший вимірний ефект — частка позицій з актуальною ціною. Під час ручної правки прайсу раз на тиждень вона просідає до кінця інтервалу й завжди нерівномірно: частина карток відривається, а відновити картину без звірки неможливо.
Обмін за розкладом і лише за зміненими артикулами тримає частку актуальних цін біля верхньої межі, а розбіжність за конкретним товаром живе хвилини, а не дні.
Другий ефект — час на підготовку вивантаження. Звірка прайсів, чищення дублів, ручна правка описів і характеристик згортаються в разове зіставлення полів: регламент оновлення виконує ту саму роботу за журналом обміну, а не за пам'яттю менеджера. Звільнені години йдуть на картки та ціни, які справді потребують рішення людини.
Третій — клас відмов через неправильну наявність. Продаж позиції, якої немає на складі, обертається скасуванням замовлення й просіданням рейтингу продавця.
Обмін залишків за розкладом, буферний запас за ходовими артикулами й окремий статус «немає в наявності» замість нульової ціни прибирають цю категорію помилок майже повністю.
Обмін не підміняє облікову систему — він тримає маркетплейс у згоді з нею. Нижче розбираємо, як влаштований парсинг даних і на яких місцях він ламається найчастіше.
Формати парсингу: разовий імпорт, розклад, потік оновлень
Формат збору визначає не зручність роботи, а допустиму розбіжність між каталогом на сайті та карткою на майданчику.
Дані Яндекс.Маркет можна забирати разово, за розкладом, потоком або через офіційний інтерфейс майданчика — у кожного варіанта свій клас відмов і свої обмеження збору. Нижче — порівняння, за яким зазвичай і обирають схему.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разова вивантаження | Первинне наповнення каталогу, перенесення асортименту, звірка після зміни постачальника | До наступного обміну ціни й залишки розходяться з майданчиком; годиться як стартова база, не як постійне джерело |
| Збір за розкладом | Регулярне оновлення цін, залишків, характеристик і описів | Жорсткі ліміти на кількість звернень за інтервал: у разі перевищення зростають затримки, а мережева адреса потрапляє під тимчасове блокування |
| Потокове оновлення | Позиції з частою зміною ціни й залишку, де важлива реакція протягом дня | Тримає постійний канал і чергу; потрібна дедуплікація подій, інакше повторні записи перевантажують обмін з 1С |
| Офіційний інтерфейс майданчика | Коли потрібна стабільність і підтверджене джерело даних | Потребує партнерського доступу, віддає не всі поля картки, терміни надання доступу не залежать від нас |
Обирають не «найшвидший» варіант, а комбінацію: разове вивантаження задає базу, розклад підтримує актуальність, потік закриває критичні позиції.
Далі вирішує зіставлення — товари зв'язуємо за артикулом і штрихкодом, щоб оновлення не плодило дублі в інфоблоках, а розбіжності потрапляли у звіт. Опишіть завдання — повернемося з оцінкою та планом під ваш випадок.
Порядок впровадження: від аудиту каталогу до передачі регламентів
Обмін із маркетплейсом — не разове вивантаження, а регламентна операція: ціни, залишки й картки змінюються щодня, а замовлення потрібно забирати до спливу строку підтвердження.
Тому роботу будуємо так, щоб кожен етап давав перевірюваний результат, а не «налаштували й сподіваємося».
- Аудит каталогу. Звіряємо номенклатуру, торгові пропозиції та властивості, шукаємо дублі, позиції без зовнішніх ідентифікаторів і товари, які в каталозі є, а в постачальника вже зняті з продажу. На виході — карта відповідності та список місць, які обмін зламає.
- Схема обміну. Визначаємо напрямки потоків, періодичність запуску, поведінку в разі розбіжності та ліміти на обсяг змін за один прогін. Схема фіксується письмово до першого рядка коду.
- Правила зіставлення. Основний ключ — зовнішній ідентифікатор, резервний — артикул і нормалізована назва. Окремо описуємо створення нових позицій, архівацію зниклих і пріоритет ціни: з картки чи з прайсу.
- Налаштування обміну. Реалізуємо обмін у 1С-Битрикс, ставимо завдання за розкладом, підключаємо журнал: кожен прогін пише звіт із кількістю створених, оновлених і відхилених позицій.
- Перевірка на копії. Прогоняємо на копії бойового каталогу та копії бази: повторний запуск, обрив зв'язку, порожня відповідь, частково некоректні дані. Відкат має бути штатною операцією ще до релізу.
- Передача регламентів. Інструкції для контент-менеджера: як читати звіт, що робити при масових відхиленнях, як додати категорію. Плюс журнал запусків і оповіщення, щоб збій виявлявся раніше за скаргу покупця.
Що залишається у вас: схеми обміну, правила зіставлення, регламенти
Після запуску парсингу Яндекс.Маркет у вас залишаються не разові вивантаження, а робочий контур обміну: схеми, правила й документи, за якими команда продовжує роботу без автора рішення.
Це головний критерій приймання — систему можна передати іншому інженеру або віддати на супровід, не відновлюючи логіку з листування.
- Схема обміну даними — карта маршруту «джерело → проміжна таблиця → картка в каталозі» з переліком полів на кожному кроці: що оновлюється завжди, що лише додається, що ніколи не перезаписується.
- Правила зіставлення товарів — пріоритет ключів (артикул виробника, потім штрихкод, потім зв'язка «бренд + модель»), окремі гілки для наборів, комплектів і позицій з варіантами.
- Журнал помилок — фіксує тип збою, час, вихідний запис і ознаку «повторювати автоматично або в ручний розбір»; розбіжності не проковтуються мовчки, а потрапляють у чергу зі зрозумілим статусом.
- Регламент оновлення — періодичність запусків для цін і залишків, порядок дій у разі недоступності джерела, правила відкату до попереднього знімка каталогу.
- Інструкція для редактора — які властивості правляться руками, а які буде перезаписано під час наступної синхронізації, щоб ручні правки не зникали безслідно.
- Налаштовані перевірки — контроль дублів, порожніх цін і аномальних стрибків: зміни проходять валідацію й не потрапляють у бойовий каталог до підтвердження.
- Доступи й точка передачі — де розміщені конфігурації, хто відповідає за розклад, як передати контур новому підряднику.
Кожен пункт узгоджений із вашою командою на етапі запуску та перевірений на реальному вивантаженні — вам не потрібно здогадуватися, як поводитиметься обмін за наступної зміни видачі.
Кейс: прибрали ручне оновлення цін і залишків у каталозі
Каталог на 12 000 позицій тримався на ручній роботі: редактори раз на тиждень зводили вивантаження з трьох джерел, звіряли порядково за артикулом і заливали оновлення на сайт.
Розбіжності за ціною й наявністю сягали 20% — покупець бачив актуальні дані лише в момент оформлення замовлення, а відмови «немає в наявності» били по конверсії та репутації магазину.
На підготовку прайсу йшло 12–14 годин на тиждень, тобто кілька повних робочих днів редактора на місяць на механічну звірку замість роботи з описами та категоріями.
Помилка в одному рядку спливала не відразу: її помічали вже за зверненням клієнта, коли позиція тижнями висіла з неправильним залишком.
Ми зібрали потік даних від Яндекс Маркет до каталогу: зіставлення за артикулом і штрихкодом, правила пріоритету, чергу обміну з журналом за кожною позицією та відкат до останнього коректного стану в разі збою джерела.
Спірні рядки не перетирають ціни мовчки, а складаються в окремий список із причиною — редактор розбирає лише їх.
Оновлення відбувається раз на 30 хвилин за ціною й залишком і раз на добу за категоріями та характеристиками.
Частка розбіжностей упала нижче 1%, ручного втручання потребують близько 3% позицій, а навантаження на редактора скоротилося до 40 хвилин на день: він перевіряє винятки, а не зводить таблиці. Відмови за наявністю скоротилися в рази, і картки перестали розходитися з реальним складом.
Що робити, якщо каталог уже синхронізується стороннім модулем?
Сторонній модуль обміну — зазвичай чорна скринька зі своєю таблицею зіставлень і своїм розкладом. Зносити його відразу не можна: разом із ним зникне накопичена прив'язка товарів до розділів, а частина полів заповнена лише ним.
Перший крок — не заміна, а зняття телеметрії: скільки записів зачіпає цикл, які властивості картки він перезаписує, за яким ключем зіставляє товар.
Далі — перевірка коректності даних. Беремо зріз каталогу й звіряємо артикули, ціни, залишки, торгові пропозиції та прив'язку до розділів із джерелом.
Окремо дивимося дублі й позиції, яких у джерелі вже немає: модуль позначає їх знятими з продажу, а не видаляє, і цю поведінку потрібно зберегти — інакше отримаємо биті посилання в розділах.
Конфлікт оновлень знімається розмежуванням володіння полями: ціна й залишок залишаються за обміном, опис, фото та вкладки — за редактором. Без цього дві схеми затирають правки одна одної, і помітно це лише за історією змін конкретної картки, тобто вже після втрати контенту.
Міграція без простою відбувається паралельно: новий канал піднімається поряд зі старим і пише в ті самі сутності через окремі службові властивості. Кілька повних циклів порівнюємо за кількістю змінених позицій і розбіжностями, і перемикаємося лише після збігу.
Відкат змін при цьому залишається оборотним: поки триває звірка, тримаємо дамп каталогу й таблиць зіставлення, тому повернення до попередньої схеми — одна операція, а не відновлення зі старої резервної копії.
Технічні сумніви: зіставлення, дублі, ліміти звернень
Розбір технічних сумнівів починається з того, що стійкість обміну закладається у схему на етапі проєктування, а не правиться вручну після кожного вивантаження.
Ключ зіставлення, правила нормалізації назв і розклад запитів описуються до першого запуску — тому повторний обмін оновлює каталог, а не створює його заново.
Нижче — питання, які найчастіше спливають на старті: як зв'язуються позиції, що відбувається з дублями карток і як обмін поводиться при обмеженнях за частотою звернень.
Як зіставляються артикули, якщо в постачальника немає нашого коду?
Позиція зв'язується за набором ознак: виробник і артикул, штрихкод, нормалізована назва та ключові характеристики. Прямий збіг за артикулом має пріоритет, інші ознаки працюють як підтвердження.
Спірні збіги не потрапляють у каталог автоматично — вони складаються в окремий список для ручного підтвердження, щоб помилкова зв'язка не розійшлася за цінами й залишками.
Що буде з дублями карток при регулярному обміні?
Дедуплікація відбувається за тим самим ключем: повторне вивантаження оновлює наявну картку, а не створює другу. Якщо товар надходить із кількох джерел, торгові пропозиції зливаються в одну картку зі збереженням історії змін.
Позиції, що втратили актуальність у постачальника, позначаються як зняті з продажу, а не видаляються — це зберігає прив'язку до замовлень.
Чи не впремось ми в ліміти звернень до джерела?
Обмін відбувається за розкладом із паузами між запитами й кешуванням незмінених розділів. У разі відповіді про обмеження обмін призупиняється й продовжується з тієї ж позиції, а повторні спроби йдуть із наростаючою затримкою.
Журнал фіксує кожну операцію, тому збій на середині вивантаження не призводить до частково оновленого каталогу.
Обговоримо завдання: що підготувати до розмови і що ви отримаєте
Щоб розмова про парсинг Яндекс.Маркету була предметною, а не «загалом», до неї достатньо підготувати кілька вступних даних про каталог. Чим точніше вони описані, тим менше припущень в оцінці термінів і тим конкретнішим виходить план робіт. Нижче — те, що реально впливає на склад робіт.
- Джерело та приймач. Розділ або перелік категорій Маркету, звідки беремо картки, і куди вони лягають у 1С-Битрикс: торгові пропозиції, властивості, розділи каталогу.
- Правила зіставлення. За яким полем зв'язуємо товар із уже наявною позицією — артикул, штрихкод, назва з моделлю; що робимо, коли два джерела дають різні значення.
- Склад картки. Які поля потрібні: ціна, характеристики, галерея, опис, залишки; що оновлюється часто, а що достатньо завантажити один раз.
- Регламент оновлення. Запуск вручну, за розкладом або за фактом зміни; що відбувається з товаром, який зник із видачі.
- Доступи й обмеження. Чи є офіційний програмний доступ до даних або працюємо через вивантаження, які ліміти за частотою звернень, хто з боку замовника підтверджує правила.
- Відповідальний за спірні картки. Хто розбирає межові випадки й за яким каналом узгоджуємо правки в правилах.
Опишіть завдання у вільній формі та додайте те, що вже є, — повернемося з оцінкою та планом робіт: етапами, перевіркою на тестовому наборі карток і варіантом відкату, якщо правила зіставлення доведеться переглядати.
