Меняем материал товара. Редактор правит сайт. Потом маркетплейс A. Потом маркетплейс B. Через неделю выясняется, что в одном канале осталось старое значение.

На маленьком каталоге это раздражает. На большом — становится постоянной причиной ошибок. Интеграция с маркетплейсами должна убрать именно это повторение: один master-факт меняется один раз и дальше расходится по каналам через правила.

Я бы убрала саму идею ручной синхронизации. У каждого факта должен быть master source, а каналы получают свои представления через mapping и validation. Тогда изменение делают один раз.

Сначала назначьте master source для каждого типа данных

Не обязательно все поля живут в одной системе. Product attributes могут приходить из PIM, цена — из ERP, остаток — из складской системы, маркетинговый текст — из CMS.

Важно другое: для каждого поля должен быть один владелец истины. Если сайт и marketplace могут независимо менять `материал`, конфликт неизбежен.

Я бы описала field ownership до интеграции. Тогда синхронизация знает направление движения, а не пытается угадывать, какая версия свежее.

Проверяемые источники: Google Search Central — Share your product data with Google · GS1 — GS1 GDSN standards

Channel mapping переводит master schema, а не копирует карточку

У площадок разные названия категорий, допустимые значения, обязательные атрибуты и ограничения формата. Поэтому прямой copy-paste master JSON редко работает.

Для каждого канала я бы держала mapping: canonical category → channel category, canonical field → channel field, transform rules и validation rules. Изменился формат площадки — меняем mapping, а не master catalog.

Google Merchant Center тоже задаёт собственную product data specification. Это хороший пример того, что канал является представлением общего товара, а не новым источником истины.

Проверяемые источники: Google Search Central — Share your product data with Google · Google Merchant Center — Product data specification

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже
Интеграция с маркетплейсами: как синхронизировать карточки без ручного копирования · временная заглушка

Variants синхронизируются как связанные SKU, а не как набор отдельных карточек

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

Я бы держала parent product и variants. Общие facts наследуются на уровне product, variant-specific values — на SKU. На выходе channel adapter собирает формат, который требует площадка.

Google Product Variant structured data формализует похожую модель групп вариантов. Для внутреннего каталога это ещё полезнее: мы перестаём дублировать общие данные в каждой строке.

Проверяемые источники: Google Search Central — Product Variant structured data

Остаток и цена не должны ждать контентную публикацию

Если цена изменилась, не нужно пересобирать всё описание и ждать editorial queue. Я бы разделяла быстрые offer updates и более медленные content updates.

Так проще выдерживать актуальность. Stock pipeline отправляет availability и quantity. Price pipeline — цену и скидку. Product content идёт своей партией после QA.

Канал на выходе получает согласованное состояние, но внутренние потоки не блокируют друг друга без необходимости.

Проверяемые источники: Google Search Central — Share your product data with Google · Google Merchant Center — Product data specification

Validation идёт до publish, а ошибка — в отдельную очередь

Каждый adapter должен знать обязательные поля, типы, допустимые значения и channel limits. Не прошла проверка — SKU не отправляется и получает понятный reason code.

Я бы не останавливала всю партию из-за одной карточки. 9 980 валидных SKU уходят дальше, двадцать — в error queue. После исправления переотправляем только их.

GS1 GDSN тоже строится вокруг стандартизированного обмена product data между trading partners. Внутри компании полезен тот же operational principle: структурировать данные и синхронизировать изменения, а не рассылать файлы вручную.

Проверяемые источники: GS1 — GS1 GDSN standards

Контроль потока показывает, где ещё осталось ручное копирование

Я бы вывела несколько простых метрик: время от изменения master до канала, failed updates, количество SKU в error queue, причины ошибок и ручные corrections после публикации.

Особенно интересны повторяющиеся ручные правки. Если редакторы каждый день исправляют один и тот же mapping после автоматической выгрузки, проблема находится в transform rule, а не в конкретных карточках.

Цель не в том, чтобы убрать человека вообще. Человек остаётся на новых категориях, спорных атрибутах и исключениях. Всё повторяемое должно проходить потоком.

Проверяемые источники: Google Search Central — Share your product data with Google · Google Merchant Center — Product data specification

Обратный канал ошибок нужен так же, как прямой publish

Площадка может принять API-запрос и позже отклонить карточку из-за категории, атрибута или модерации. Если этот status не возвращается в master workflow, команда узнаёт об ошибке из личного кабинета и снова работает руками.

Я бы сохраняла channel item ID, последний publish status, reason code и время проверки. Ошибка попадает в ту же очередь исключений, где видно, какое master value её вызвало.

После исправления отправляем только затронутый SKU и проверяем новый статус. Так sync становится двусторонним процессом состояния, а не однократной выгрузкой файла.

Проверяемые источники: Google Search Central — Share your product data with Google · Google Merchant Center — Product data specification

Что проверить перед следующей партией

Как синхронизировать карточки между сайтом и маркетплейсами?

Назначить master sources, привести данные к canonical schema и сделать отдельные channel mappings. Каждый канал получает преобразованное представление вместо ручной копии карточки.

Где хранить основной каталог товаров?

Это может быть PIM, ERP или другая система — зависит от архитектуры. Важно, чтобы для каждого типа поля был однозначный source of truth и понятное направление обновления.

Нужно ли останавливать всю выгрузку из-за одной ошибки?

Обычно нет. Лучше валидировать на уровне SKU, публиковать чистую часть партии и отправлять проблемные карточки в отдельную очередь с reason codes.

Нормальная синхронизация видна по простой вещи: изменение делают один раз. Дальше mapping, validation и publish проходят сами, а редактор видит только исключения. Если три площадки по-прежнему требуют три ручные правки, поток ещё не собран.

Следующие задачи в каталожном потоке для «интеграция с маркетплейсами»: Контент-конвейер для тысяч SKU: как выстроить процесс без хаоса · QA карточек товаров: как проверять качество до публикации.