Фид загрузился. Через час площадка отклонила 700 товаров. Команда открывает кабинет и начинает вручную читать причины по одной карточке.

Мне не нравится, когда маркетплейс или Merchant Center становится первым валидатором нашего каталога. Большую часть ошибок можно поймать до отправки. То есть задача конкретная: как автоматически проверить товарный фид до выгрузки и не разбирать потом сотни отклонений в кабинете площадки?

Диагностика товарного фида должна работать партией: schema, product facts, identity, channel rules. Чистые SKU идут дальше, исключения получают reason code и остаются в рабочей очереди.

Schema checks запускаются до любой публикации

Обязательное поле пустое, цена без валюты, некорректный URL, неизвестный тип значения — это не проблема площадки. Это наша ошибка данных.

Я бы валидировала типы, обязательность, длины и допустимые форматы на canonical/channel representation до API или feed export.

Google Merchant Center публикует product data specification с требованиями к атрибутам. Такие правила можно превратить в автоматический preflight.

Проверяемые источники: Google Merchant Center — Product data specification

Механическая сцена проверки товарных данных перед публикацией
Schema preflight: товар проходит контроль формата и обязательных полей до отправки в канал.

Product identity проверяется отдельным слоем

Товар может формально пройти schema и всё равно иметь неправильный brand, GTIN или variant relation. Такие ошибки дороже простого пустого поля.

Я бы проверяла consistency идентификаторов, parent/variant links и конфликты между channel data и master catalog. Неизвестный GTIN не нужно придумывать ради заполнения.

Product data quality policies Merchant Center отдельно рассматривают достоверность и соответствие передаваемых данных.

Проверяемые источники: Google Merchant Center — Product data specification · Google Merchant Center — Fixing Merchant Center disapprovals for product data quality violations

Сцена проверки идентичности товара с увеличительным механизмом
Product identity проверяется как отдельная сверка товара, идентификатора и master data.

Channel rules должны жить как версия mapping

Площадка меняет обязательные поля или допустимые значения. Если rule зашит в ручную инструкцию редактора, следующая партия снова сломается.

Я бы хранила versioned channel mapping и validation rules. Обновили спецификацию — прогнали тестовую партию, посмотрели новые exceptions, затем включили версию для всех SKU.

Google обновляет product data specification и публикует изменения. Это хороший повод относиться к channel rules как к версии, а не вечной настройке.

Проверяемые источники: Google Merchant Center — Product data specification · Google Merchant Center — Merchant Center product data specification update 2026

Центральный распределительный узел для правил разных каналов
Versioned channel mapping распределяет один канонический товарный поток по разным каналам без ручного дублирования правил.

Одна ошибка не должна останавливать весь batch

Из 10 000 SKU двадцать не прошли validation. Я бы не блокировала остальные 9 980.

Чистая часть партии публикуется, проблемные карточки получают reason code и остаются в error queue. После исправления переотправляем только их.

Так редактор работает с исключениями. Публикационный поток не ждёт идеального каталога целиком.

Проверяемые источники: Google Merchant Center — Fixing Merchant Center disapprovals for product data quality violations

Отдельная ветка для ошибочных SKU рядом с основным товарным потоком
Проблемный SKU изолируется в exception lane, а чистая часть batch продолжает публикацию.

Ошибки площадки возвращаются в тот же workflow

Некоторые проверки возможны только после отправки: модерация, внешняя policy или состояние аккаунта. Эти ответы всё равно не должны жить отдельно в кабинете.

Я бы сохраняла channel item ID, status и reason code рядом с master SKU. Повторяющаяся причина становится backlog для mapping/validation rule.

Merchant Center даёт инструменты для исправления disapprovals и attribute rules. Операционно важно вернуть этот feedback в свой каталог.

Проверяемые источники: Google Merchant Center — Fixing Merchant Center disapprovals for product data quality violations · Google Merchant Center — Attribute rules

Замкнутый маршрут возврата ошибок площадки в товарный workflow
Ответы площадки возвращаются в тот же контур: status и reason code снова попадают в validation workflow.

Feed health измеряется очередью ошибок

Количество отправленных SKU звучит бодро. Мне полезнее доля принятых с первого прохода, размер error queue, повторяющиеся reason codes и время до исправления.

Если новая партия снова падает на тех же полях, команда лечит симптомы. Если reason codes постепенно исчезают после изменений правил, процесс учится.

Хороший фид не тот, который однажды загрузился. Он выдерживает ежедневные изменения каталога без ручного пожаротушения.

Проверяемые источники: Google Merchant Center — Product data specification · Google Merchant Center — Attribute rules

Перед большим изменением rules нужен canary batch

Поменяли category mapping или обязательный атрибут — не обязательно сразу пересобирать 100 000 SKU. Я бы выбрала небольшую репрезентативную партию из нескольких категорий.

Canary проходит полный preflight и отправляется в канал. Смотрим новые reason codes, неожиданное изменение coverage и channel statuses. После этого расширяем rollout.

Так ошибка в одном transform rule не размножается на весь каталог за несколько минут. Для массового потока это намного дешевле героического отката.

Canary стоит собирать не только из идеальных карточек. Я бы включала variants, товары без GTIN, сложные категории и SKU с недавними ошибками. Иначе тестовая партия проходит красиво, а реальный поток ломается на первом же редком формате.

Проверяемые источники: Google Merchant Center — Product data specification · Google Merchant Center — Merchant Center product data specification update 2026

Небольшой тестовый контур для проверки новой версии правил перед массовым запуском
Canary batch проходит полный тестовый маршрут до того, как новая версия правил подключается ко всему каталогу.

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

Как проверить товарный фид до загрузки?

Прогнать schema validation, product identity, обязательные атрибуты и channel-specific rules локально. Проблемные SKU отправить в отдельную очередь, а чистую часть партии публиковать.

Нужно ли останавливать весь фид из-за нескольких ошибок?

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

Что делать с ошибками после загрузки на площадку?

Возвращать status и reason code в master workflow, анализировать повторяющиеся причины и обновлять mapping/validation rules, а не исправлять каждую карточку изолированно.

Площадка не должна учить нас качеству данных на каждой выгрузке заново. Сначала проверяем партию сами, публикуем чистое, возвращаем внешние ошибки в очередь и улучшаем правила. Тогда feed становится потоком, а не еженедельной операцией спасения каталога.

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