Каждая торговая площадка имеет свои стандарты и методы обмена данными с продавцами. У Ozon — свои стандарты, у Яндекс.Маркета — свои, у Wildberries — свои.
Почему так происходит?
Есть ли универсальные решения?
К сожалению, абсолютно универсальных решений не существует. Помимо особенностей архитектуры каждой площадки (которые обусловлены методами реализации, программной средой, бизнес-структурой, ассортиментной политикой и внутренними регламентами работы с товарооборотом), каждый поставщик (продавец) также имеет свои уникальные особенности.
Например:
Каждый из них формирует свой каталог, опираясь на бизнес-особенности. К примеру, у одного поставщика раздел может называться «Хозтовары», у другого — «Товары для уборки», у третьего — «Для дома» и т.д.
При решении вопросов импорта важно учитывать как возможные источники данных, так и различия в номенклатуре.
Именно поэтому любая торговая площадка, как правило, предоставляет поставщикам не прямой метод, а определённый набор инструментов. Поставщик может выбрать наиболее подходящий из них для автоматического или полуавтоматического внесения данных в систему.
Давайте рассмотрим все доступные методы, их плюсы и минусы.
Данный метод поддерживается всеми маркетплейсами на DST-платформе.
Это максимально универсальный способ. Excel-таблицы содержат только самый необходимый набор информации о товаре, что значительно упрощает для продавца процесс формирования файла и его приведения в соответствие с требованиями площадки.
Файл содержит следующие поля:
· Код
· Элемент
· Наименование товара
· Описание товара
· Цена продажи
· Старая цена (до скидки)
· Бренд
· Страна-изготовитель
· Ссылки на изображения товара
· Количество (товарный остаток на складе)
· Минимальное количество (если товар отгружается кратно упаковке)
· ID категории товара (справочник ID доступен в личном кабинете поставщика, в разделе «Импорты»)
· Ширина товара
· Длина товара
· Вес товара
· Ссылка на файл с технической документацией (при наличии)
Это минимальный набор сведений, необходимый для формирования товарной карточки. В качестве источника данных можно использовать практически любую систему: «1С», любую CMS-систему сайта и т.д., так как практически все они позволяют выгружать каталог в формате Excel.
Задача поставщика сводится к тому, чтобы расположить данные в правильном порядке и проставить ID категорий для публикации. Все эти действия можно выполнить массово: применить формулу ко всему столбцу или использовать макросы. Как правило, процесс подготовки файла для импорта занимает от 10 до 30 минут.
Особенности и важные замечания:
Данный метод разрабатывается непосредственно под конкретную площадку с учётом её индивидуальных требований к атрибутам и характеристикам товаров. Файл может содержать большее количество полей и более подробные сведения о товарах.
Как правило, при таком подходе файлы формируются отдельно для каждого раздела каталога. Например, для раздела «Канцтовары» требуется один набор полей, а для раздела «Хозтовары» — другой.
Такой вариант позволяет продавцу внести в таблицу максимально полную информацию. Однако важно учитывать, что у продавца этих сведений может и не быть. Например, если в качестве источника данных он использует базовый прайс-лист из «1С», то в нём могут отсутствовать изображения или необходимые характеристики. Обычно в системах учёта хранятся только базовые данные, поэтому подготовка такого файла может занять у продавца продолжительное время.
Рассмотрим ситуацию, когда поставщик формирует файлы не вручную, а автоматически. Для этого он может привлечь разработчика, чтобы настроить автоматическую генерацию файла по стандарту маркетплейса и организовать его регулярное обновление по ссылке.
В таком случае можно настроить cron-задачу (автоматическое выполнение по расписанию). Наша система будет в установленные интервалы обращаться к этому файлу по ссылке и обновлять данные.
Как поставщику настроить автоматическую генерацию файла?
1.
Проверка источника данных: в своей
системе учёта (например, в «1С» или CRM) необходимо убедиться, что товарная
карточка содержит все необходимые поля. Скорее всего, потребуется добавить поле
ID категории, чтобы система
понимала, в какой раздел каталога публиковать товар.
2. Создание файла: если используется расширенный файл, нужно создать и заполнить все требуемые поля в соответствии с техническими требованиями для каждого раздела.
3. Настройка выгрузки: после этого необходимо разработать механизм автоматической выгрузки подготовленного файла по ссылке с определённой периодичностью (например, раз в сутки).
XML (eXtensible Markup Language) — это расширяемый язык разметки. Если говорить просто, это структурированный текстовый файл, который хранит данные в виде древовидной структуры с тегами.
Представьте себе обычную анкету. У нее есть поля: «Имя», «Фамилия», «Возраст». XML делает то же самое, но в цифровом виде. Он «оборачивает» каждый элемент данных в свой тег, чтобы компьютеры могли их легко понять и обработать.
Простой пример XML-файла для товара:
XML
<?xml version="1.0" encoding="UTF-8"?><product> <id>12345</id> <name>Смартфон SuperPhone X</name> <price>49999</price> <brand>SuperPhone</brand> <stock>15</stock> <images> <image>https://site.com/photo1.jpg</image> <image>https://site.com/photo2.jpg</image> </images> <parameters> <parameter name="Цвет">Черный</parameter> <parameter name="Диагональ экрана">6.7"</parameter> </parameters></product>
·
Теги (например, <price>...</price>)
— это как ярлыки, которые объясняют, что за данные в них заключ
·
Структура — теги могут быть
вложены друг в друга, создавая иерархию (например, все теги внутри <product>...</product>
описывают один товар).
Маркетплейсу (Ozon, Wildberries, Яндекс.Маркет и др.) и поставщику нужно постоянно обмениваться огромным количеством данных: ценами, остатками, описаниями товаров, заказами. XML — это хороший посредник для такого обмена, потому что он машинно-читаемый и стандартизированный.
Вот как это работает на практике:
А. Выгрузка товаров от поставщика на маркетплейс (загрузка товаров на площадку)
Поставщик формирует XML-файл по строгому шаблону (стандарту), который требует маркетплейс . Этот шаблон называется XSD-схема или DTD. Она гарантирует, что все файлы от разных поставщиков будут одинаково структурированы.
· Что передается:
o Полное описание товаров (названия, описания, характеристики, фото, видео).
o Цены.
o Остатки на складе.
· Процесс:
1. Поставщик готовит XML-файл со своим каталогом товаров. (Для этого ему нужен свой разработчик.)
2. Загружает этот файл в личный кабинет на маркетплейсе через специальную форму.
3. Или настраивает автоматическую выгрузку: система поставщика по расписанию генерирует актуальный XML-файл и размещает его на своем сервере по специальной ссылке.
4. Система маркетплейса в заданное время «забирает» (парсит) этот файл по ссылке, проверяет его на ошибки и загружает данные в свой каталог.
Б. Загрузка данных от маркетплейса к поставщику (получение заказов, обновление статусов)
Обратный процесс тоже часто идет через XML.
· Что передается:
o Информация о новых заказах.
o Статусы собранных и отправленных заказов.
o Данные о продажах и возвратах.
o Вопросы от клиентов и отзывы.
· Процесс:
1. Маркетплейс формирует XML-файл с новыми заказами.
2. Система поставщика в фоновом режиме «забирает» этот файл (или маркетплейс отправляет его по специальному адресу — webhook).
3. Система поставщика «читает» XML-файл и автоматически создает заказы в своей 1С или CRM, не требуя ручного ввода.
|
Плюсы (+) |
Минусы (-) |
|
✅ Стандартизация: Все участники процесса используют единый, понятный формат. |
❌ Громоздкость: Файлы могут быть очень большими из-за обилия тегов, что немного замедляет обработку. |
|
✅ Читаемость: Данные структурированы, их относительно легко прочитать и понять даже человеку (в отличие от бинарных форматов). |
❌ Сложность: Требует определенных технических знаний для настройки автоматической генерации и обработки. |
|
✅ Гибкость: Формат позволяет описать товар любой сложности с любым количеством характеристик благодаря вложенным тегам. |
❌ Строгая валидация: Файл должен идеально соответствовать схеме (XSD). Любая опечатка в теге или структуре приведет к ошибке загрузки. |
|
✅ Автоматизация: Подходит для полностью автоматического обмена данными между разными компьютерными системами без участия человека. |
XML — это универсальный «язык» для общения между компьютерными системами. В контексте маркетплейсов он выступает в роли цифрового курьера, который доставляет:
· От поставщика к маркетплейсу: полные данные о товарах, цены и остатки.
· От маркетплейса к поставщику: заказы, статусы и аналитику.
Это основа для автоматизации, которая позволяет работать быстро, эффективно и без ошибок, возникающих при ручном вводе данных.
API-интеграция — это современный, эффективный и наиболее предпочтительный способ обмена данными между поставщиком и маркетплейсом. Если XML-файлы — это как отправка документов курьером (пакетами по расписанию), то API — это прямое телефонное соединение между двумя компьютерами в реальном времени.
API (Application Programming Interface) — это набор правил, протоколов и инструментов, который позволяет двум разным программам/системам напрямую общаться друг с другом и обмениваться данными максимально быстро и автоматически, без участия человека.
Простая аналогия:
· Официант в ресторане — это API. Вы (клиент) делаете заказ официанту (API), он передает его на кухню (система маркетплейса), а затем приносит вам готовое блюдо (результат). Вам не нужно самим идти на кухню и объясняться с поваром.
API позволяет настроить двусторонний обмен данными наиболее оперативным из возможных способов . Важно понимать: речь идет не о буквальной «мгновенности», а о событийной модели обмена с минимальной задержкой, которая ограничена техническими лимитами.
Ключевые сценарии использования:
А. Синхронизация остатков (Stock API)
· Как было с файлами: Раз в час/день система выгружала огромный XML-файл со всеми остатками. Если товар продался через 5 минут после выгрузки, на маркетплейсе еще долго будет висеть неверный остаток.
· Как с API: Как только товар продается в вашей системе учета (1С, CRM), она почти сразу отправляет через API запрос на маркетплейс: «У товара с артикулом XXXX остаток стал 0».
· Важный нюанс: Маркетплейсы вводят ограничения (Rate Limiting) на количество запросов в секунду. Поэтому при обновлении 100 000 товаров одновременно система будет отправлять их пачками, и полное обновление займет время (15-30 мин). Но чаще нужно обновлять лишь несколько десятков позиций, и это происходит буквально за секунды.
Б. Обновление цен (Price API)
· Запустили акцию или изменили прайс? API отправляет новые цены только на те товары, которые изменились. Это происходит на порядок быстрее, чем ожидание очередной выгрузки полного файла.
В. Автоматическая обработка заказов (Order API)
· Как было с файлами: Вы должны были зайти в ЛК, скачать файл с новыми заказами и вручную перенести их в свою систему.
· Как с API: Как только на маркетплейсе появляется новый заказ, он автоматически через API отправляет его прямо в вашу систему учета. Заказ создается без вашего участия. Это идеальная «мгновенность» — заказы поступают в течение нескольких секунд после оформления покупателем.
Г. Отправка статусов заказов (Fulfillment API)
· Вы собрали заказ и отправили его? Ваша система через API сразу же отправляет статус «в пути» с трек-номером на маркетплейс. Клиент видит актуальную информацию без задержек.
|
Критерий |
XML/Excel-выгрузка |
API-интеграция |
|
Скорость |
Длительные интервалы (выгрузка раз в 1-12 часов). Большая задержка. |
Короткие интервалы. Данные отправляются непрерывным потоком с учетом лимитов. Задержка от секунд до нескольких минут. |
|
Принцип работы |
Пакетная обработка (Batch). Обновляется сразу весь файл, даже если изменения коснулись 1% товаров. |
Событийная модель (Event-based). Отправляются только изменения (дельты). Экономит ресурсы. |
|
Автоматизация |
Частичная. Требует контроля за расписанием выгрузок и обработкой файлов. |
Полная. Процесс работает без вмешательства человека после настройки. |
|
Риск ошибок |
Выше. Можно забыть выгрузить файл, сделать ошибку в формате. |
Ниже. Исключен человеческий фактор. |
|
Сложность настройки |
Проще. Можно настроить силами IT-специалиста или продвинутого менеджера. |
Сложнее. Требует квалифицированных разработчиков на обеих сторонах. |
|
Идеально для |
Небольших поставщиков с редким обновлением ассортимента и цен. Начального этапа работы. |
Крупных и средних поставщиков с большим ассортиментом, частыми изменениями и высокой оборачиваемостью. |
· XML/Excel — это хороший и простой способ начать работу с маркетплейсом, подходит для тех, у кого нет ресурсов на глубокую интеграцию. Это как ехать на поезде по расписанию.
· API — это мощный инструмент для полной автоматизации. Он не всегда «мгновенный» в буквальном смысле для тысяч товаров из-за лимитов, но он максимально оперативен и эффективен. Он экономит время, исключает ошибки и помогает предоставлять клиентам лучший сервис. Это как поездка на автомобиле: вы едете быстрее и по своему маршруту, но иногда можете попасть в пробку (ограничение запросов).
Переход на API — это логичный следующий шаг для роста и масштабирования вашего бизнеса на маркетплейсах, который окупается за счет снижения операционных затрат и увеличения продаж.
Как владелец нового маркетплейса, вы находитесь перед ключевым стратегическим выбором: заставлять каждого поставщика самостоятельно и дорого интегрироваться с вашим API или вложиться в создание и поддержку готовых модулей (коннекторов) для популярных систем учета. Это не просто техническая задача, а инвестиция в рост и конкурентное преимущество.
Вот аргументы «за» и «против», которые помогут вам принять решение.
А. Снятие барьеров для входа и ускорение on-boarding
· Проблема: Без готовых модулей поставщик, особенно малый и средний бизнес (МСБ), должен искать и оплачивать разработчика для индивидуальной интеграции. Это стоимость (от 50к руб.) и время (от 2 недель). Большинство потенциальных продавцов отсеется на этом этапе.
· Решение: Предложите им модуль «установил — настроил — работает». Вы кардинально снижаете порог входа. Поставщик подключается за 2-3 дня, а не недели, и практически бесплатно. Это мощнейший драйвер для быстрого роста числа продавцов.
Б. Конкурентная борьба с гигантами
· У Ozon, Wildberries и Yandex Market есть огромные команды и бюджеты на интеграции. Ваше преимущество — в скорости и простоте. Вы не можете тягаться с ними по охвату, но можете выиграть за счет лучшего user experience для поставщика. Легкость подключения — это ваш козырь.
В. Контроль качества и стабильности данных
· Проблема: Когда каждый поставщик интегрируется самостоятельно, вы получаете сотни разных реализаций вашего API. Многие — с ошибками, которые приводят к некорректным выгрузкам товаров, дублирующимся заказам и сбоям. Вы тратите колоссальные ресурсы техподдержки на разбор этих проблем.
· Решение: Ваш собственный (или партнерский) модуль — это предсказуемый и качественный канал данных. Вы точно знаете, как он работает, и можете гарантировать стабильность. Это снижает нагрузку на вашу поддержку и улучшает общее качество каталога.
Г. Создание экосистемы и лояльности
· Поставщик, который легко подключился и настроил автоматизацию через ваш модуль, сильнее привязан к вашей платформе. Ему будет сложнее уйти, так как его бизнес-процессы уже завязаны на вас. Вы становитесь не просто площадкой, а удобным инструментом.
Д. Централизованное обновление
· Когда вы обновляете или меняете свое API, вам не нужно ждать, пока сотни разработчиков со стороны поставщиков перепишут свой код. Вы просто обновляете свой модуль, и все ваши партнеры получают актуальную версию. Это стратегическая гибкость.
А. Прямые затраты на разработку и поддержку
· Это не разовое вложение. Вам нужна отдельная команда или сильный разработчик, который будет:
o Писать и тестировать модули.
o Адаптировать их под новые версии ПО (например, обновления 1С).
o Исправлять баги.
o Оперативно вносить правки при изменениях в вашем же API.
· Это постоянная статья расходов.
Б. Ограничение охвата
· Вы не сможете покрыть все системы на рынке. Вам придется выбирать топ-5-10 самых популярных систем (1С, RetailCRM, InSales и т.д.). Поставщики, использующие экзотическое ПО, все равно будут идти путем индивидуальной интеграции.
В. Ответственность и зависимость
· Любая ошибка в вашем модуле ударит сразу по всем подключенным через него поставщикам . Это создает риски массовых сбоев. Вы берете на себя ответственность за работу чужого функционала.
Стоит инвестировать в готовые модули, если:
· Ваша целевая аудитория — МСБ. Для них простота подключения — главный фактор.
· Вы находитесь на стадии активного роста
При ограниченных ресурсах разработку следует вести поэтапно, начиная с систем, которые дадут максимальный охват и отдачу. Вот рекомендуемый порядок и обоснование:
Первый этап (Критически важные, Maximum Impact)
1. 1С (все популярные конфигурации: УТ, ERP, Розница, Бухгалтерия)
o Почему это №1: 1С — это де-факто стандарт для среднего и крупного бизнеса в России. По разным оценкам, более 80% компаний, работающих с маркетплейсами, используют ту или иную версию 1С. Не имея модуля для 1С, вы автоматически отсекаете большую часть потенциально крупных и надежных поставщиков.
o Что охватывает: Полный цикл: выгрузка номенклатуры, остатков, цен, прием заказов, отправка статусов.
2. RetailCRM
o Почему это №2: RetailCRM — ведущая CRM-система specifically для e-commerce и ритейла в РФ. Ее часто используют как центральный хаб для управления всеми каналами продаж (свой сайт, маркетплейсы, соцсети). Интегрировавшись с RetailCRM, вы фактически интегрируетесь со всеми ее клиентами.
o Ключевое преимущество: Команда RetailCRM активно развивает готовые коннекторы, и они могут быть заинтересованы во включении вашей площадки в свой маркетплейс. Это может быть взаимовыгодное партнерство.
Второй этап (Важные для малого бизнеса и digital-native компаний)
3. InSales
o Почему: InSales — один из крупнейших облачных конструкторов интернет-магазинов в РФ. Его аудитория — это малый и средний бизнес, который уже работает онлайн и активно выходит на маркетплейсы. Интеграция с InSales позволяет легко привлечь этих "цифровых" продавцов.
Третий этап (Специализированные и нишевые системы)
Четвертый этап (Универсальные коннекторы и no-code платформы)
1. Соберите данные: Реализуйте в анкете поставщика вопрос "Какая система учета является для вас основной?".
2. Начните с ТОП-2: Сфокусируйте ресурсы на разработке и поддержке стабильных модулей для 1С и RetailCRM . Это закроет >70% потребностей рынка.
3. Ищите партнеров: Не обязательно разрабатывать всё силами своей команды. Вы можете предоставить исчерпывающую документацию и техническую поддержку вендорам этих систем (командам 1С, RetailCRM, InSales), чтобы они сами разработали и разместили модули для подключения к вашей площадке в своих маркетплейсах. Это модель win-win.
4. Анонсируйте и пиарьте: Как только модуль готов, сделайте это вашим ключевым маркетинговым преимуществом для привлечения продавцов: "Подключитесь к [Название Вашей Площадки] за 1 день прямо из вашей 1С!".
Метод |
Вложения/Затраты |
Необходимы разработчики? |
Скорость внедрения |
Комментарий для поставщика |
Ручной ввод |
Нулевые |
Нет |
Медленно |
Только для старта и маленького ассортимента |
Excel-выгрузка |
Низкие |
Нет/возможно |
Средняя |
Базовый вариант автоматизации, требует ручного контроля |
XML-выгрузка |
Низкие/Средние |
Обязательно |
Средняя |
Стандартизированный формат, лучше для автоматической обработки чем Excel. XML часто требует больше технических знаний, чем Excel, но предоставляет более строгую структуру и лучше подходит для автоматической обработки. Потребуется разработчик для настройки автоматической выгрузки. |
Готовый модуль |
Нулевые – если он будет бесплатный, могут быть и платные модули |
Нет |
Быстро (1-3 дня) |
Оптимальное соотношение цены и скорости |
Индивидуальная API |
Высокие |
Обязательно |
Долго (недели/месяцы) |
Решение для крупного бизнеса, максимальная гибкость |
Метод |
Преимущества |
Недостатки/Затраты |
Стратегическая цель |
Ручной ввод |
Нулевые затраты на интеграцию |
Ограничивает рост, низкое качество данных |
Тестирование площадки малыми поставщиками |
Excel-выгрузка |
Низкие затраты, широкая доступность |
Небольшие операционные затраты на поддержку |
Быстрое масштабирование числа продавцов |
XML-выгрузка |
Стандартизация, лучше машинное чтение чем Excel |
Нужна валидация схем (XSD), сложнее Excel, затраты на разработку и поддержку |
Профессиональная работа с данными, XML — это "золотая середина" между простым, но неструктурированным Excel и сложным, но мощным API. Идеален для поставщиков с корпоративными системами, готовыми настраивать автоматизированную выгрузку. |
Готовый модуль |
Массовый онбординг, качество данных, лояльность |
Высокие инвестиции в разработку и поддержку |
Ключевое конкурентное преимущество |
Индивидуальная API |
Привлечение крупных игроков, качество данных |
Высокие затраты на разработку и поддержку API |
Работа с premium-поставщиками и брендами |