Товары попадают не в ту категорию рекламного фида: проверка родительских ID

Ниже разобран учебный экспорт каталога с несколькими уровнями. На сайте есть раздел «Оборудование», внутри него «Системы хранения», а внутри последнего «Компактные модели». Внешний получатель использует список категорий и ссылки товаров на их коды. Задача состоит в том, чтобы сохранить отношения разделов при выгрузке, включая переносы и повторные запуски.

Категория товара и родитель категории связаны по-разному

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

В примерах YML используется пара атрибутов id и parentId. Это иллюстрация конкретного семейства форматов, а не универсальный контракт любого рекламного сервиса. Перед реализацией разработчик должен открыть требования нужного получателя и определить, где описываются внутренние категории магазина, а где внешние классификаторы площадки. Похожее название поля ещё не означает одинаковое назначение.

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

Сначала проверьте исходное дерево CMS

Посмотрите, действительно ли раздел находится внутри ожидаемого родителя в административном интерфейсе. Иногда экспорт лишь воспроизводит уже неверную структуру. Тогда изменение сериализатора замаскирует проблему и создаст расхождение между сайтом и фидом. Ответ на вопрос «что является источником истины» нужен до правки кода.

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

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

Не смешивайте внутренние и внешние коды

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

Нужен понятный договор: в документе экспортируется стабильный код категории магазина или код внешней категории? Для каждого поля укажите владельца и правило получения. Если применяется преобразование кодов, родительские ссылки должны проходить через ту же карту, что и собственные коды разделов. Ошибка часто возникает, когда собственный id уже преобразован, а parentId остался внутренним.

Рекомендуемый учебный тест прост: экспортируйте три раздела с кодами, заведомо отличными от внутренних числовых ID. Если цепочка сохранилась, сериализатор использует карту последовательно. Если родитель ссылается на неизвестное число, вы нашли границу, где смешались пространства идентификаторов.

Проверка корней, пропусков и циклов

Корневая категория обрабатывается по требованиям выбранного формата. Для неё не нужно придумывать фиктивного родителя только ради одинакового количества атрибутов. Пустое значение, отсутствие атрибута и специальное значение могут интерпретироваться по-разному. Этот выбор должен быть подтверждён документацией получателя.

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

Есть и менее заметная ошибка: один код встречается дважды с разными родителями. В текстовом XML оба элемента могут выглядеть корректно, но получатель выберет один из них или отклонит документ. Уникальность кода проверяют до записи файла. Повтор названия допустим по структуре, повтор идентификатора должен иметь однозначное объяснение и обычно означает ошибку набора.

Как проверить связь товарного предложения

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

Учебный товар «Модель А» относится к компактным системам, а «Модель Б» к аксессуарам другой ветки. Добавьте третью позицию с несколькими привязками. Ожидание для неё запишите до запуска. Так проверяется правильность parentId и выбор исходной категории самого предложения.

Не стоит передавать наиболее верхний раздел во всех случаях ради отсутствия ошибки. Формально он может существовать, но полезная детализация исчезнет. Лучше зафиксировать конфликтующие товары в отчёте и договориться о правиле выбора. Техническое решение должно сохранять смысл классификации, а не лишь проходить XML-парсер.

Перемещение раздела проверяет устойчивость схемы

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

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

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

Что проверяет XML-валидатор, а что остаётся человеку

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

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

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

Как оформить регрессионный набор

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

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

Порядок выпуска исправления

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

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

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

Как диагностировать ошибку после копирования окружения

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

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

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

Почему исправление одного числа не закрывает задачу

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

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

Связанные разборы

Для смежных решений пригодятся материалы: Интеграция интернет-магазина с маркетплейсами. Общий материал о каталоге помогает выбрать структуру разделов. В выгрузке дополнительно проверяются родительские коды и сохранность товарных привязок.

Вопросы по теме

Достаточно ли исправить categoryId у товара?

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

Почему XML проходит проверку, но категория неверная?

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

Документация и источники

• Яндекс: структура YML: Пример дерева категорий использует id и parentId; конкретные требования зависят от получателя.