Каждая площадка требует свой формат карточки товара — свои категории, свои обязательные характеристики, свой формат передачи данных. Вести карточки вручную по каждой площадке отдельно означает дублировать одну и ту же работу несколько раз с риском разойтись в деталях. Ниже — как устроен единый каталог, из которого карточки на все площадки собираются автоматически.
Проблема: разные требования к карточкам на разных площадках
Один и тот же товар на сайте, Wildberries, Ozon и Яндекс.Маркете не может использовать одну и ту же карточку без изменений — у каждой площадки свой набор обязательных характеристик, своя категорийная сетка и свой формат передачи данных. Wildberries требует заполнить строго определённый набор характеристик для категории — состав, размерную сетку, цвет из справочника значений — и не примет карточку, если обязательное поле пустое. Ozon использует собственное дерево категорий и собственную схему атрибутов, частично пересекающуюся с Wildberries, но не идентичную. Яндекс.Маркет принимает данные через YML-фид с своим набором тегов, а МегаМаркет — по ещё одной схожей, но не совпадающей схеме.
При ручном ведении карточек это выливается в дублирование одной и той же работы четыре раза с четырьмя разными результатами: описание на одной площадке отредактировали, а на трёх остальных — забыли; цена изменилась на сайте, но осталась старой в фиде Яндекс.Маркета; категория, привязанная вручную, устарела после того, как площадка обновила свою категорийную сетку, и карточка ушла в архив без уведомления. Каждое из этих расхождений по отдельности выглядит мелочью, но в масштабе каталога из нескольких сотен SKU превращается в постоянный источник ошибок, которые чаще всего замечают по факту — когда карточка уже пропала из выдачи или отображает неверную цену.
Проблема усугубляется тем, что требования площадок не статичны: категорийные деревья Wildberries и Ozon регулярно обновляются, состав обязательных характеристик для отдельных категорий меняется, а формат YML-фида Яндекс.Маркета дополняется новыми тегами. При ручном ведении карточек за этими изменениями приходится следить по каждой площадке отдельно, и любое пропущенное обновление приводит к тому, что часть каталога перестаёт публиковаться без явного уведомления — карточка просто не проходит валидацию при следующей загрузке.
Ситуация усложняется ещё и тем, что схемы площадок не просто разные — они по-разному детализированы. Там, где Wildberries требует единственное поле «цвет», Ozon может запрашивать отдельно основной цвет и цвет в описании, а для той же категории на Яндекс.Маркете вообще нет обязательного поля цвета, зато есть требование к минимальному числу фотографий на карточке. Пытаться свести это к одному общему шаблону карточки, одинаковому для всех площадок, на практике не получается — приходится либо занижать данные до общего знаменателя и терять часть возможностей каждой площадки, либо вести карточки отдельно и терять согласованность.
Как устроен единый источник данных о товаре (мастер-каталог)
Рабочая альтернатива ручному дублированию — вести один мастер-каталог: каноническую карточку товара, независимую от требований конкретной площадки. В ней хранятся базовые данные — артикул, название, описание, изображения, базовая цена, вес и габариты, бренд, ключевые характеристики. Эта запись не привязана к схеме Wildberries или Ozon напрямую, она существует как единственный источник правды о товаре.
Карточки на каждой площадке при этом не редактируются отдельно вручную, а генерируются из мастер-записи через правила преобразования под конкретную схему площадки. Если нужно поменять описание или цену — правка вносится один раз в мастер-каталоге, и дальше автоматически расходится по всем производным карточкам. Это не устраняет разницу в требованиях площадок, но переносит точку правки из четырёх мест в одно, убирая саму возможность того, что данные разойдутся просто потому, что кто-то забыл обновить одну из копий.
Важное следствие такой архитектуры — версионность и предсказуемость изменений. Когда карточка на каждой площадке генерируется по правилам из одной и той же мастер-записи, всегда можно проверить, почему конкретное поле на конкретной площадке выглядит именно так: либо это значение из мастер-каталога, либо результат применения правила преобразования. При ручном ведении четырёх независимых карточек такой прослеживаемости обычно нет — расхождение можно объяснить только тем, что кто-то когда-то отредактировал одну из копий и не отразил это в остальных.
Мастер-каталог также снимает вопрос, какая версия карточки «правильная» в спорной ситуации. Если менеджер по продажам на маркетплейсе и менеджер сайта одновременно правят описание независимо друг от друга, рано или поздно возникает конфликт версий. При едином источнике данных такого конфликта в принципе не возникает — редактируется одна запись, а не несколько параллельных копий одного и того же товара.
Маппинг категорий и атрибутов под каждую площадку
Мастер-каталог сам по себе не публикует карточки на площадках — для этого нужен маппинг: таблица соответствий, которая связывает внутреннюю категорию и атрибуты товара с категорийным деревом и справочниками конкретного маркетплейса. На практике это работает на двух уровнях.
- Категорийный маппинг: внутренняя категория «Женская обувь / Кроссовки» привязывается к конкретному ID категории в дереве Wildberries, отдельному ID в дереве Ozon и соответствующему тегу в фиде Яндекс.Маркета. При обновлении категорийной сетки площадки достаточно поправить одну связь в таблице маппинга, а не искать и перепривязывать вручную все карточки этой категории.
- Атрибутный маппинг: внутреннее значение характеристики переводится в формат, который требует конкретная площадка — например, значение цвета «красный» сопоставляется с нужным пунктом справочника цветов Wildberries, а единица измерения приводится к формату, который ожидает Ozon. Здесь же обрабатываются обязательные поля, которых нет во внутренней схеме: если площадка требует характеристику, которую магазин не ведёт, для неё задаётся значение по умолчанию или карточка помечается на ручное дозаполнение.
Маппинг — не разовая настройка, а слой, который нужно поддерживать: площадки периодически меняют категорийные деревья и добавляют новые обязательные характеристики, и без актуального маппинга часть карточек начинает пропадать из публикации без явной причины.
Отдельная тонкость маппинга — обработка значений, для которых у площадки нет точного соответствия внутреннему справочнику. Например, внутренний каталог хранит цвет как свободный текст «изумрудный», а справочник Wildberries требует выбрать значение из ограниченного списка, где ближайший вариант — «зелёный». Такие случаи нельзя закрыть автоматическим правилом раз и навсегда: нужен либо расширенный словарь синонимов с ручной проверкой новых значений, либо явный список исключений, которые всегда уходят на ручную проверку перед публикацией.
Хорошая практика — вести маппинг не как разрозненные правки в разных местах, а как единую таблицу соответствий с историей изменений: когда именно площадка обновила категорию, какое значение атрибута использовалось раньше и какое актуально сейчас. Это превращает поддержку маппинга из реагирования на уже сломанные карточки в плановую задачу, которую можно выполнять по мере появления уведомлений от площадок, а не по факту падения показов.
Что автоматизируется, а что всё равно нужно адаптировать вручную
Автоматизации хорошо поддаётся всё, что сводится к применению правил: подстановка категорий и атрибутов по таблице маппинга, синхронизация цены и остатка, массовая перепубликация карточек после изменения категорийной сетки площадки, базовая сборка заголовка и описания по шаблону из полей мастер-записи.
Ручной адаптации по-прежнему требует то, что зависит от специфики конкретной площадки, а не только от структуры данных:
- заголовки и описания, оптимизированные под внутренний поиск конкретного маркетплейса — шаблонный текст из мастер-записи редко конкурирует с карточками, которые целенаправленно написаны под особенности ранжирования Wildberries или Ozon;
- новые обязательные характеристики, которые площадка ввела внезапно и которых ещё нет во внутренней схеме — их приходится добавлять в мастер-каталог и в маппинг вручную, прежде чем автоматика сможет их подставлять;
- пограничные случаи категоризации, когда товар формально подходит под две категории площадки с разными наборами обязательных полей — тут нужно ручное решение, какую категорию выбрать;
- требования к изображениям, которые различаются по площадкам — соотношение сторон, наличие или отсутствие фона, минимальное разрешение — иногда для этого нужен отдельный кроп фотографии под конкретную площадку, а не одно изображение на всех.
Задача автоматизации — снять с менеджера каталога рутинное дублирование и держать данные согласованными между собой, а не полностью убрать необходимость понимать особенности каждой площадки. В «Витрине» карточки на сайте, Wildberries, Ozon, Яндекс.Маркете и МегаМаркете публикуются из одного каталога с настроенным маппингом категорий и атрибутов, так что изменение в одной записи не нужно вручную повторять на каждой площадке отдельно.
На практике роль менеджера каталога при таком подходе смещается: вместо повторяющегося ввода одних и тех же данных четыре раза он тратит время на настройку и поддержку маппинга, проработку заголовков и описаний под конкретные площадки и разбор пограничных случаев — то есть на задачи, которые действительно требуют понимания специфики каждого маркетплейса, а не на механическое копирование значений из одной формы в другую.