Интеграция с Яндекс Маркетом: витрина, заказы, YML

Интеграция с Яндекс Маркетом обычно сводится к трём техническим задачам: выгрузить товары на витрину через YML, научиться принимать и обрабатывать заказы через API, и удержать синхронизацию остатков, когда склад меняется быстрее, чем обновляется фид. За последний год делал такие подключения для магазинов на Tilda и WooCommerce, и почти везде всплывают одни и те же грабли: фид падает на валидации, заказы приходят с задержкой, а остатки на сайте и в кабинете продавца расходятся уже на второй день после запуска.

Что входит в интеграцию с Яндекс Маркетом

Маркет предлагает четыре модели размещения, и от выбранной модели зависит объём кода, который придётся писать. В FBY товар физически лежит на складе Маркета, и от продавца нужен только фид и периодическое обновление остатков на этом складе. В FBS склад остаётся у продавца, поэтому добавляется приём заказов, печать этикеток и передача трек-номера при отгрузке на склад Маркета. DBS и Экспресс идут дальше: доставку тоже организует продавец, значит в схему добавляется курьерская служба, чаще всего СДЭК или собственная логистика, и обмен статусами по каждому заказу в реальном времени.

Что нужно для регистрации кампании

До любой техники магазину нужно юрлицо или ИП, договор оферты в личном кабинете партнёра и подключённая касса по 54-ФЗ, иначе кампанию просто не создадут. Дальше добавляется реквизиты для выплат и подтверждение категорий товаров, которые продавцу разрешено размещать. Это разовая административная часть, но её часто недооценивают и начинают собирать YML-фид раньше, чем кабинет вообще готов принимать заказы.

Выгрузка YML-фида для витрины

Фид собирается из стандартного набора тегов: offer с id и атрибутом available, price, currencyId, categoryId по классификатору Маркета, picture, vendor, barcode и набор param под характеристики товара. У каждой категории в классификаторе свои обязательные параметры: для одежды это размер и цвет, для электроники - гарантия и страна производства. Без них карточка либо не проходит модерацию, либо теряет фильтры в поисковой выдаче Маркета.

<offer id="12345" available="true">
  <name>Кроссовки беговые, размер 42</name>
  <price>7990</price>
  <currencyId>RUR</currencyId>
  <categoryId>101</categoryId>
  <picture>https://example.ru/img/12345.jpg</picture>
  <vendor>Nike</vendor>
  <param name="Размер">42</param>
  <param name="Цвет">чёрный</param>
</offer>

Тильда сама не формирует YML, поэтому фид для витрины Маркета собираю отдельным скриптом на Python, который тянет товары из CRM или 1С и раскладывает их по категориям Маркета. На WooCommerce фид можно получить плагином вроде WP All Export, но в большинстве проектов его всё равно приходится дорабатывать: плагин берёт категории сайта, а Маркету нужен свой categoryId по собственному классификатору, и это отдельная таблица соответствий, которую руками не удержать больше пары недель.

Простые и составные офферы

Для товаров с вариантами - размер, цвет, комплектация - Маркет ждёт связку через vendor и model или через group_id, чтобы карточки схлопывались в одну витрину с выбором варианта. Если сделать каждый вариант отдельным независимым офером без группировки, покупатель увидит десяток почти одинаковых карточек вместо одной с выпадающим списком, а конверсия на такой выдаче обычно заметно ниже.

Если магазин на Tilda и готового генератора фида нет, такую задачу закрываю как разработку кастомной интеграции: скрипт забирает товары из источника данных и собирает XML по правилам Маркета, включая проверку на битые ссылки и обязательные поля перед публикацией. Полный фид пересобираю и заливаю раз в сутки, а для быстро меняющихся price и available использую отдельный частичный апдейт через API - Маркет принимает точечное обновление остатков и цен без перезаливки всего XML, и такой вызов можно дёргать хоть каждые 15 минут.

Приём и обработка заказов через API Маркета

Доступ к заказам получаю по OAuth-токену на конкретную кампанию campaignId, а businessId нужен, когда у продавца несколько магазинов и часть операций делается на уровне бизнеса, а не отдельной точки. Список новых заказов забираю через GET-запрос к списку заказов кампании, дальше работаю со статусами: PROCESSING, DELIVERY, PICKUP, DELIVERED, CANCELLED, UNPAID.

curl -X GET 
  "https://api.partner.market.yandex.ru/v2/campaigns/12345/orders?status=PROCESSING" 
  -H "Authorization: Bearer $YANDEX_TOKEN"

Заказ в статусе PROCESSING нужно подтвердить в ограниченное время, обычно в течение суток, иначе Маркет отменяет его автоматически, и это бьёт по рейтингу продавца. Маркет умеет присылать уведомление о новом заказе на URL, зарегистрированный в личном кабинете, но на практике часть пушей не долетает, поэтому рядом всегда ставлю поллинг раз в 5-10 минут как подстраховку: без него заказы иногда провисают необработанными по несколько часов. Для DBS и Экспресс статус меняется в обратную сторону через PUT-запрос к тому же заказу, включая передачу трек-номера собственной доставки.

Возвраты и отмены заказов

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

Синхронизация остатков и цен между сайтом и Маркетом

Главный риск для FBS и DBS - продажа одного и того же товара одновременно на сайте и на Маркете, когда остаток обновляется с задержкой. Источником правды по остаткам должна быть одна система, обычно CRM или 1С, а не движок сайта сам по себе: сайт и фид Маркета читают остаток из неё, а не пишут его каждый в свою сторону. Частичный апдейт остатков и цен через API отправляю каждые 15-30 минут, для FBY это не так критично, потому что товар физически лежит на складе Маркета и сверка идёт по факту приёмки.

На практике встречал ситуацию так: заказ оплачен на сайте, а через минуту тот же последний экземпляр товара купили на Маркете, потому что остаток там пересчитывался раз в сутки. Продавцу пришлось вручную отменять второй заказ, объясняться с покупателем и получить минус в рейтинг за отмену не по вине Маркета. После перехода на частичный апдейт остатков каждые 20 минут подобные накладки почти исчезли.

Цену в карточке Маркета сверяют с ценой на сайте продавца, особенно в схемах, где сайт выступает витриной для сравнения цен. Заметное расхождение - частая причина замечаний от модерации, поэтому обновление price в фиде и на сайте лучше делать из одного источника и в одной транзакции, а не двумя независимыми процессами с разным расписанием.

Автоматизация заказов через n8n и уведомления в Telegram

Типовая цепочка, которую собираю под такие интеграции: cron-триггер в n8n опрашивает заказы Маркета, новый заказ уходит в CRM через HTTP-запрос, при схеме DBS тут же создаётся накладная через API СДЭК, а менеджеру в Telegram-чат приходит сообщение с составом заказа и адресом доставки. Подтверждение сборки менеджер жмёт прямо в боте, бот вызывает вебхук в n8n, а тот меняет статус заказа обратно в Маркете.

Проверка на тестовой кампании

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

Такую цепочку собираю в n8n, автоматизация в n8n начинается от 25 000 ₽. Если бота под уведомления в компании ещё нет, добавляю простого aiogram-бота отдельно, разработка телеграм-бота от 30 000 ₽. Комплексную связку фид плюс заказы плюс CRM обычно оцениваю от 40 000 ₽, дальше цена растёт от числа кампаний и внешних систем, с которыми нужно сверяться.

Почему Маркет отклоняет фид или блокирует магазин

Большинство блокировок и отказов в модерации сводятся к нескольким повторяющимся причинам:

• Битые ссылки на изображения в фиде - Маркет не смог скачать картинку при обходе
• Отсутствуют обязательные параметры категории, например размер или цвет для одежды
• Просроченный SSL-сертификат на URL фида - по HTTPS XML скачать не получается
• Регулярная просрочка подтверждения заказов в статусе PROCESSING
• Расхождение цены в карточке и на сайте продавца сверх допустимого порога
• Превышение частоты запросов к API, обычно не чаще одного запроса в секунду на кампанию

Частые вопросы

Сколько времени занимает интеграция с Яндекс Маркетом?

Для готового сайта с понятной товарной базой фид и приём заказов по FBS делаю за 3-5 дней. Если нужна связка с CRM, складом и автоматической передачей статусов по DBS, срок растягивается до 2-3 недель, в основном из-за согласования маппинга категорий и тестовой прогонки заказов.

Какую модель размещения выбрать - FBY, FBS или DBS?

FBY снимает с продавца логистику, но требует физически отгрузить товар на склад Маркета и держать там запас. FBS оставляет склад у продавца и добавляет обработку заказов на своей стороне, зато не требует своей курьерской службы. DBS и Экспресс дают больше контроля над доставкой и обычно выгоднее по комиссии, но требуют интеграции с курьерской службой вроде СДЭК и обмена статусами почти в реальном времени.

Можно ли подключить Яндекс Маркет к сайту на Tilda?

Да, но Тильда не формирует YML сама, поэтому фид и обработку заказов делаю отдельным скриптом, который забирает товары из CRM или таблицы поставщика и собирает XML по требованиям Маркета. Приём заказов и смена статусов тоже реализуются вне конструктора, обычно тем же скриптом или связкой с n8n.

Что делать, если остатки на сайте и в Маркете расходятся?

Свести обновление остатков к одному источнику данных и одному расписанию: CRM или 1С отдают остаток и в фид, и на сайт, а частичный апдейт через API идёт каждые 15-30 минут вместо раза в сутки. Разные скрипты, которые независимо друг от друга пишут в остаток, почти всегда рано или поздно расходятся.