Фид может открываться без XML-ошибок и сохранять привычное число <offer>, но часть товаров всё равно не попадёт в объявления: в оффере выбран один способ описания названия, а переданы поля другого. Проверьте каждый товар по паре «атрибут type — поля названия», затем исправьте экспорт у источника, а не отдельные строки готового файла.
Ниже — учебный YML и скрипт, который делит офферы на ошибки, предупреждения и принятые строки. Он проверяет только способ описания товара; цену, валюту, категории, ссылки и доступность нужно принимать отдельно.
Два способа описать товар
В YML для Директа используются два типа офферов.
| Открывающий тег | Основные поля названия | Что проверяем |
|---|---|---|
<offer id="..."> | <name> | поле существует и содержит текст |
<offer id="..." type="vendor.model"> | <typePrefix>, <vendor>, <model> | vendor и model заполнены; typePrefix проверяем как часть полного названия |
По требованиям Яндекса к YML-фиду, атрибут type применяется только со значением vendor.model. Если он указан, робот проверяет наличие vendor и model; без них оффер будет проигнорирован и объявления по нему не сформируются. Для упрощённого описания атрибут type не нужен, зато требуется name.
В одном файле разрешено смешивать способы и даже передавать составное и упрощённое название в одном оффере. Это полезно при переходе между схемами, но не отменяет проверку обязательных полей выбранного типа.
Какие расхождения искать
Аудит должен отвечать на один вопрос: сможет ли получатель однозначно собрать название товара по выбранной схеме.
- Нет
type, ноnameпуст — ошибкаMISSING_NAME. - Указан
type="vendor.model", но нетvendorилиmodel— ошибкаMISSING_VENDORилиMISSING_MODEL. - Для
vendor.modelзаполненыvendorиmodel, но нетtypePrefix— предупреждениеMISSING_TYPE_PREFIX: оффер не объявляем технически отклонённым, однако название получается слабее и требует ручной проверки. - Указано другое значение
type— ошибкаUNSUPPORTED_TYPE. - Поля содержат только пробелы — считаем их пустыми.
Не переключайте тип автоматически только ради зелёного отчёта. Если экспорт отдаёт vendor и model, но не даёт осмысленного name, сначала исправьте сопоставление полей в CMS, ERP или генераторе фида. Ручная подстановка может скрыть системную ошибку и исчезнет при следующей выгрузке.
Учебный фид с пятью случаями
В sample-offers.yml есть пять вымышленных товаров. У всех сохранены базовые поля цены, валюты, категории и URL, чтобы пример был похож на рабочую выгрузку.
| ID | Схема | Ожидаемый результат |
|---|---|---|
SIMPLE-OK | без type, есть name | PASS |
VM-OK | vendor.model, все составные поля | PASS |
SIMPLE-BROKEN | без type, есть только vendor и model | MISSING_NAME |
VM-BROKEN | vendor.model, нет model | MISSING_MODEL |
VM-WARN | vendor.model, нет typePrefix | MISSING_TYPE_PREFIX |
В примере SIMPLE-BROKEN нельзя принять только потому, что человек способен сложить бренд и модель глазами: выбранная схема требует name. А VM-WARN остаётся предупреждением, потому что Яндекс прямо связывает игнорирование оффера с отсутствием vendor или model; влияние отсутствующего typePrefix следует подтвердить в кабинете на вашей категории.
Сначала читаем type, затем проверяем поля именно выбранной схемы; остальные проверки фида идут отдельным этапом.
Запустите воспроизводимую проверку
Скрипт audit_offer_names.py использует стандартный модуль Python xml.etree.ElementTree. Он не обращается к сети и формирует CSV с идентификатором оффера, типом, статусом, отсутствующими полями и собранным названием.
python audit_offer_names.py sample-offers.yml --output offer-name-audit.csvДля учебного файла результат такой:
offers: 5; pass: 2; warnings: 1; errors: 2В CSV появятся строки:
| offer_id | offer_type | status | missing_fields |
|---|---|---|---|
SIMPLE-OK | simple | PASS | — |
VM-OK | vendor.model | PASS | — |
SIMPLE-BROKEN | simple | ERROR | name |
VM-BROKEN | vendor.model | ERROR | model |
VM-WARN | vendor.model | WARNING | typePrefix |
Скрипт намеренно прекращает работу при повреждённом XML и помечает повторяющиеся offer id. Это помогает не обсуждать названия поверх файла, который нельзя однозначно разобрать. Для очень больших или недоверенных XML используйте потоковый и защищённый парсер: документация Python отдельно предупреждает, что стандартные XML-модули не предназначены для обработки вредоносных данных.
Исправляйте источник, затем принимайте весь файл
Сгруппируйте ошибки по товарной категории или шаблону экспорта. Если у сотен строк нет model, вероятнее всего, проблема в одном сопоставлении поля, а не в товарах по отдельности. Исправьте правило генерации, выгрузите новую версию и повторите тот же аудит.
После проверки названий:
- откройте обновлённый файл и убедитесь, что число офферов не уменьшилось неожиданно;
- проверьте уникальность
offer id, категории, цену и валюту; - откройте выборку URL и изображений;
- прогоните файл через анализатор YML-фида;
- загрузите ту же версию на площадку и разберите сообщения уже её валидатора.
Ошибки структуры и бизнес-правил собраны в материале «Ошибки и предупреждения YML-фида». Финальную приёмку после исправлений удобно вести по отдельному протоколу для исправленного товарного фида: зафиксировать версию, сравнить состав, повторить проверки и только затем менять файл в рекламной системе.
Этот аудит не доказывает, что оффер будет опубликован: он не проверяет всю спецификацию, модерацию, доступность категории, географию показа или содержимое посадочной страницы. Его результат уже и конкретнее: для каждой строки видно, соответствует ли способ описания товара полям, из которых должен собраться заголовок.
Источники
Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.
Что думаете?
Загружаем комментарии…