Почему не все товары из YML-фида попадают на площадку: пошаговая диагностика

В каталоге магазина числится 1 000 активных товаров, YML-фид успешно загружается, но на площадке покупатели видят только 900. Сообщение «фид обработан» не объясняет расхождение: часть позиций могла не попасть в файл, часть — получить отказ при импорте, а остальные — быть принятыми, но скрытыми из показа.

Чтобы найти причину, сравнивайте не два общих счётчика, а путь одного конкретного товара через все этапы. Сначала подтвердите, должен ли он выгружаться. Затем найдите его в актуальном YML по стабильному идентификатору. Если предложение есть в файле, переходите к отчёту импорта и итоговому статусу в кабинете площадки.

Почему статуса «фид загружен» недостаточно

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

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

Перед расследованием убедитесь, что площадка скачала именно текущую версию. Если есть подозрение на старый файл, используйте отдельную инструкцию о том, как проверить обновление YML-фида, URL и кеш. Здесь будем считать, что актуальный файл уже получен.

Пять контрольных чисел на пути товара

Зафиксируйте счётчик после каждого перехода. Например, условная цепочка может выглядеть так:

Это условные числа, а не статистика конкретной площадки. Их ценность — в границах: падение с 1 000 до 970 относится к магазину и генератору; с 950 до 925 — к результатам импорта; с 925 до 900 — к модерации, коммерческим настройкам и правилам показа.

Ситуация № 1: товара нет в YML-файле

Если предложение отсутствует в самом файле, кабинет площадки пока не нужен: получатель не может обработать то, чего ему не отправили. Сначала определите ожидаемый состав конкретной выгрузки. Число активных карточек в CMS редко равно числу offer, потому что экспорт может включать только опубликованные товары нужного канала, региона, статуса или категории.

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

Выберите один пропавший товар и возьмите стабильный внутренний ID или артикул. Название подходит хуже: оно меняется и может отличаться в CMS и фиде. Поиск должен подтвердить наличие всего предложения, например:

<offer id="sku-1042" available="true">
  <name>Кофемолка ручная M2</name>
  ...
</offer>

Если sku-1042 не найден, проверьте журнал генерации и решение фильтров именно для этой записи: была ли карточка опубликована, входила ли в канал, какой остаток видел генератор, нашлась ли категория, не сработало ли исключение. Так вы доказываете, что товар потерян на стороне магазина, а не отклонён площадкой.

Если нужно уточнить, где находится offer и как он связан с категориями, достаточно кратко свериться со статьёй о структуре и элементах YML-фида. Повторно разбирать весь XML для поиска одного ID не требуется.

Ситуация № 2: товар есть в файле, но отклонён площадкой

Найденный offer меняет направление проверки. Теперь зафиксируйте его ID и откройте отчёт последнего импорта. Нужна связка доказательств: предложение присутствует в скачанном файле, площадка прочитала его и присвоила конкретный статус или причину отказа.

Проверяйте не только текст ошибки, но и предложение, к которому она относится. Дублирующийся либо некорректный offer id может связать сообщение не с той карточкой. Если ID одного товара меняется при каждой генерации, площадка способна создавать новую сущность вместо обновления старой. Стабильность идентификатора поэтому важна и до, и после исправления.

Причина отказа может относиться к данным, обязательным именно для выбранного получателя: неподдерживаемой категории или типу предложения, цене, валюте, наличию, недоступной карточке или изображению, ограничениям содержимого, модерации либо конфликтующим значениям. Частное правило одной площадки нельзя переносить на все остальные — сверяйте формулировку отчёта с её актуальной документацией.

Ситуация № 3: товар принят, но не показывается пользователям

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

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

Проверяйте отображение в тех же условиях, что у пользователя: нужный регион, способ доставки, кампания и отсутствие фильтров. Если предложение доступно в одном регионе и скрыто в другом, проблема не в YML и не в принятии, а в настройках показа.

Пошаговое расследование одного пропавшего товара

1. Зафиксируйте число активных товаров в магазине на конкретный момент.
2. Определите ожидаемый состав выгрузки: канал, категории, регионы, статусы и правила остатка.
3. Посчитайте элементы offer в актуальном YML XML-парсером или инструментом проверки, а не числом строк.
4. Выберите одну отсутствующую позицию и сохраните её внутренний ID, артикул и название.
5. Найдите ID в файле. Название используйте как запасной признак.
6. Если товара нет, проверьте для него настройки, входные данные и журнал генератора.
7. Если товар есть, найдите тот же ID в отчёте последнего импорта площадки.
8. Зафиксируйте статус: принят, отклонён, предупреждение, модерация или скрыт.
9. Исправьте подтверждённую причину в источнике данных или настройках, не в готовом XML вручную.
10. Сформируйте фид повторно и убедитесь, что ID предложения не изменился.
11. Снова сравните пять чисел на тех же контрольных точках.
12. Проверьте конкретный товар, даже если общий счётчик уже выглядит правильным.

Такой алгоритм отделяет факт от догадки. Запись «исключён из-за нулевого остатка» в журнале генератора полезнее общего предположения о фильтрах, а статус «принят, доставка недоступна в регионе» полезнее повторной отправки того же файла.

Таблица диагностики по симптомам

Практический пример: у пропавших товаров разные причины

Рассмотрим условный магазин. В CMS есть 1 000 активных карточек. По настройкам канала в выгрузку должны попасть 970: остальные не опубликованы для этой площадки. После генерации XML-парсер находит только 954 элемента offer. Уже здесь доказано, что 16 ожидаемых позиций потеряны до отправки.

Специалист выбирает товар sku-1042. В файле его нет, а журнал показывает фильтр «не выгружать без остатка». Настройка объясняет эту карточку, но не все 16. Другой товар отсутствует из-за несопоставленной категории, а несколько позиций попали в незавершённую часть пакетной генерации. Причины исправляют отдельно и получают ожидаемые 970 предложений.

Площадка обнаруживает 950 из них и принимает 925. Для одного отклонённого ID отчёт указывает недоступное изображение, для другого — значение, недопустимое в его категории. Это уже не фильтры магазина: предложения находятся в XML и получили конкретные ответы получателя.

Из 925 принятых товаров пользователям показываются 900. Проверка карточки в нужном регионе выявляет неподключённую доставку; часть предложений ещё находится на модерации, несколько отключены в кампании. Последовательная сверка не пытается объяснить все сто пропавших товаров одной ошибкой и сразу направляет каждый случай к правильной системе.

Итоговый чек-лист

• Сохранены пять чисел: каталог, YML, обработано, принято, показывается.
• Ожидаемый состав выгрузки отделён от всех активных товаров магазина.
• Количество предложений посчитано по элементам offer.
• Выбран конкретный пропавший товар со стабильным ID.
• Подтверждено его наличие или отсутствие в актуальном файле.
• Для отсутствующего товара проверены фильтры и журнал генератора.
• Для найденного товара открыт отчёт последнего импорта.
• Статусы «отклонён» и «принят, но скрыт» не смешиваются.
• После исправления offer id остался прежним.
• Повторно проверены и общий счётчик, и конкретное предложение.

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

Почему количество товаров в магазине и YML отличается?

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

Как быстро понять, выгрузился ли конкретный товар?

Возьмите стабильный ID или артикул из CMS и найдите его внутри offer id актуального файла. Поиск только по названию менее надёжен: текст может сокращаться, нормализоваться или меняться.

Товар есть в фиде, но площадка его не видит. Что делать?

Убедитесь, что площадка обработала именно эту версию файла, затем найдите ID в отчёте импорта. Отсутствие в отчёте и явный отказ — разные состояния и требуют разных проверок.

Может ли валидный YML содержать отклонённые товары?

Да. Валидность XML подтверждает, что документ можно разобрать. Площадка после этого применяет собственные правила к категориям, данным и содержанию каждого предложения.

Почему принятый товар не показывается?

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

Достаточно ли сравнить только общее количество?

Нет. Итоговые числа могут совпасть, если одни товары исчезли, а другие добавились. Для точной проверки сравнивайте списки стабильных ID и отдельно проходите путь проблемной позиции.

Сначала найдите этап, потом исправляйте причину

Расхождение количества товаров — не одна ошибка, а результат нескольких переходов. Товар может не войти в YML, быть отклонён при импорте или остаться скрытым после принятия. Пять контрольных чисел показывают проблемный переход, а один стабильный offer id даёт доказательство для конкретной карточки.

ФидСторож может загрузить публичный YML по URL, посчитать предложения и показать найденные ошибки и предупреждения. Он не заменяет отчёт импорта и кабинет площадки, но помогает подтвердить состав и состояние самого файла. Проверьте актуальный YML-фид в ФидСтороже, затем продолжите расследование по ID товара на стороне получателя.