Чтобы найти товары, потерянные при выгрузке в YML, сравните offer id файла с независимым списком предложений, которые должны в него попасть. Сначала согласуйте правила включения и единицу учёта, затем получите три списка: совпало, отсутствует, попало лишним.
Проверка особенно полезна после смены CMS, интеграции с учётной системой или настройки нового экспортного профиля. Файл может разбираться без ошибок и содержать корректные записи, хотя часть запланированного ассортимента вообще не была выгружена.
Откуда взять ожидаемый состав
Сохраните два независимых среза: каталог источника и результат экспорта. В каталоге нужны ключ предложения и поля, определяющие включение: статус, тип, канал, регион или другой согласованный признак. Время срезов и условия выборки запишите рядом с файлами.
Ожидаемый список нельзя строить из самого проверяемого фида. Если выгрузчик пропустил товары одной категории, повторный отбор из его результата не вернёт эти строки. Возьмите каталог из CMS или учётной системы до применения проверяемого экспортного фильтра. Убедитесь, что выгрузились все страницы исходного списка, а не первые сто результатов.
Не обязательно передавать весь магазин. Например, бизнес может выбрать конкретный ассортимент для канала. Проверка отвечает на вопрос о выполнении этого решения. Каждый исключённый сегмент должен иметь понятное основание; предполагаемую ошибку выгрузки нельзя задним числом объявлять новым правилом.
В требованиях Директа к YML указан уникальный идентификатор товара. Для сверки договоритесь о таком же уровне детализации в исходном каталоге: один вариант, комплект или другое предложение. Если CMS использует внутренний ID, а экспорт — составной ключ, нужна проверенная таблица соответствия. Автоматически удалять суффиксы и объединять варианты нельзя.
Учебный пример: восемь строк каталога
Все товары и статусы вымышлены. В нашем экспортном задании участвуют активные товарные предложения; архивные записи и услуги исключены. Наличие здесь не ограничивает выгрузку: для активного товара без остатка ожидается отдельный оффер с корректным состоянием наличия. Это правило примера, его нужно заменить правилами своего проекта.
| ID | Статус | Тип | Наличие | Ожидается в файле |
|---|---|---|---|---|
| A | active | goods | true | Да |
| B | active | goods | true | Да |
| C | active | goods | true | Да |
| D | active | goods | true | Да |
| E | archived | goods | false | Нет: архив |
| F | active | service | true | Нет: услуга |
| G | active | goods | false | Да: наличие не входит в отбор |
| H | active | goods | true | Да |
Ожидаемый состав — A, B, C, D, G, H: шесть предложений. В сохранённом YML найдены пять уникальных ID: A, B, C, E, X. Получаем:
| Результат | ID | Что проверить |
|---|---|---|
| Совпало с заданием | A, B, C | Записи есть; значения и страницы проверяются отдельно |
| Нет ожидаемого предложения | D, G, H | Причину исключения на этапе экспорта |
| Есть запись, исключённая правилом | E | Архивный статус и настройки профиля |
| ID отсутствует в исходном каталоге | X | Другой источник, устаревший срез или ошибку ключа |
Покрытие согласованного набора — 3 / 6 = 50%. Делить общее число офферов на ожидаемое число и называть это покрытием нельзя: 5 / 6 включает E и X, которые к нужному ассортименту не относятся. Это показатель полноты выгрузки, без оценки рекламных показов, выручки или допуска площадки.
Учебные данные. E известен каталогу и исключён правилом; X требует отдельного разбора как неизвестный ключ.
Как повторить сверку и сохранить доказательства
Начните с анализатора фидов WiseLab: проверьте структуру и доступные ему поля в пределах лимитов. Для полноты экспорта дополнительно нужен независимый каталог. Общий порядок подсчёта записей есть в инструкции о количестве товаров в YML.
До сравнения множеств проверьте пустые и повторяющиеся ID в обоих источниках. Преобразование списка в set скрывает повторы, поэтому такой шаг без предварительного контроля способен замаскировать дефект. Ключи храните строками с сохранением регистра и ведущих нулей. Пробелы по краям сначала вынесите на исправление источника.
Логику примера можно повторить в стандартном Python:
catalog = {
"A": ("active", "goods"), "B": ("active", "goods"),
"C": ("active", "goods"), "D": ("active", "goods"),
"E": ("archived", "goods"), "F": ("active", "service"),
"G": ("active", "goods"), "H": ("active", "goods"),
}
feed_ids = ["A", "B", "C", "E", "X"]
assert len(feed_ids) == len(set(feed_ids))
expected = {k for k, v in catalog.items()
if v == ("active", "goods")}
actual = set(feed_ids)
print(sorted(expected & actual)) # A, B, C
print(sorted(expected - actual)) # D, G, H
print(sorted((actual & set(catalog)) - expected)) # E
print(sorted(actual - set(catalog))) # X
print(len(expected & actual) / len(expected)) # 0.5Этот фрагмент использует заданные вручную уникальные ключи. При работе с файлами сначала проверьте уникальность строк каталога, затем создавайте словарь. Сохраните правило, время срезов, хеши исходных файлов и найденные ID: эти сведения позволят разработчику повторить результат. Неизвестные значения статуса или типа лучше остановить на разбор, чтобы молчаливое исключение не стало новой потерей ассортимента.
Где искать причину и как принять исправление
Для каждого пропавшего ID запросите трассу решения выгрузчика: запись в источнике, её признаки на момент среза, сработавшее условие и причину исключения. У D мог оказаться незаполненный обязательный атрибут; у G — незаявленный фильтр «только в наличии»; H мог не попасть в последнюю страницу выборки. Это гипотезы для проверки, а не установленные причины учебных пропусков.
Для E проверьте статус и кэш; для X — источник ключа и соответствие вариантов. Не исправляйте покрытие добавлением случайных офферов до нужного количества. При согласованном изменении правила сохраните новую версию ожидаемого состава и причину изменения.
После исправления повторите сверку на новых согласованных срезах. В точном экспортном задании все ожидаемые ID должны присутствовать, а каждое лишнее предложение — получить объяснение. При пустом ожидаемом списке процент покрытия не рассчитывается: сначала подтвердите, что пустая выборка действительно задумана.
Дальше отдельно проверьте обработку платформой и состав рекламной кампании. Валидация Директа описывает проверки элементов файла; она не заменяет вашу сверку с бизнес-каталогом. Оффер может присутствовать в YML, но не пройти обработку или рекламный фильтр — для этого есть самостоятельная проверка отбора товаров в Директе.
Итог передавайте по протоколу приёмки исправленного фида: согласованная версия задания, два исходных среза, список расхождений и результат повторной проверки. Локальная сверка доступна команде в Беларуси без подключения платных сервисов; доступность рекламного сценария и его запуск проверяются в своём кабинете отдельно.
Источники
Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.
Что думаете?
Загружаем комментарии…