Как проверить дубли offer id в YML-фиде

Если число товаров в YML выглядит правильным, это ещё не означает, что идентификаторы в порядке. Два offer могут делить один id, а один и тот же товар — получать новый id при каждой выгрузке. Проверять нужно оба случая: уникальность внутри файла и стабильность между версиями.

Что считать ошибкой

В YML идентификатор записывается в атрибуте offer: <offer id="CHAIR-101">. По требованиям Яндекс Директа каждый товар должен иметь уникальный идентификатор, а идентификаторы одного товара в разных фидах должны совпадать — в том числе у фидов разных типов.

Отсюда следуют две отдельные проверки:

1. Один id не должен встречаться у двух записей в одной выгрузке.
2. При следующей выгрузке тот же товар должен сохранить прежний id.

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

Внутри файла ищем повторы, между версиями — смену ID у той же карточки.

Проверка 1. Найдите повторы внутри одного YML

Возьмём учебный фрагмент:

<offers>
  <offer id="CHAIR-101">
    <name>Кресло чёрное</name>
    <url>https://example.com/chair-black</url>
  </offer>
  <offer id="CHAIR-101">
    <name>Кресло серое</name>
    <url>https://example.com/chair-gray</url>
  </offer>
</offers>

Записей две, URL разные, но id совпадает. Анализатор товарных фидов WiseLab на этом примере проверил три товара и показал одну блокирующую ошибку: «Повторяется ID товара». В замечании он указал второе появление CHAIR-101 и строку, где ID встретился впервые.

Для вариантов одного товара правило то же: если цвет или размер передан отдельным offer, у записи должен быть свой уникальный id. В учебном примере исправленная пара выглядит так:

<offer id="CHAIR-101-BLK">…чёрное кресло…</offer>
<offer id="CHAIR-101-GRY">…серое кресло…</offer>

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

Проверка 2. Сверьте ID между двумя версиями

Уникальный ID может пройти проверку одного файла и всё равно оказаться плохим. Допустим, белое кресло было CHAIR-102, а после обновления стало CHAIR-202, хотя URL карточки остался прежним. В каждой версии ID уникален, но его смена нарушает стабильность.

Для первичной сверки можно сопоставить версии по URL. Такой способ работает, если URL карточки сам не менялся. Если менялся и URL, нужен более надёжный внутренний ключ: SKU из ERP, артикул варианта или неизменяемый ID записи в базе.

Ниже — короткий скрипт без сторонних библиотек. Он печатает смены ID для одинаковых URL:

import sys
import xml.etree.ElementTree as ET

def by_url(path):
    root = ET.parse(path).getroot()
    return {
        (offer.findtext("url") or "").strip(): (offer.get("id") or "").strip()
        for offer in root.findall(".//offer")
        if (offer.findtext("url") or "").strip()
    }

old, new = by_url(sys.argv[1]), by_url(sys.argv[2])
for url in sorted(old.keys() & new.keys()):
    if old[url] != new[url]:
        print(f"{url}\t{old[url]}\t{new[url]}")

Запуск:

python3 compare_ids.py feed-before.yml feed-after.yml

Для учебных файлов результат будет таким:

https://example.com/chair-white    CHAIR-102    CHAIR-202

Это сигнал проверить источник ID. Сам по себе отчёт не доказывает, какой номер правильный: решение принимает владелец товарных данных по истории SKU и карточки.

Как оформить результат для разработчика

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

Для дубля CHAIR-101 полезно приложить обе записи. Для смены ID — две версии файла с датой генерации. Тогда разработчик сможет проверить, где создаётся значение: в ERP, CMS, модуле экспорта или промежуточном преобразовании.

Контроль после исправления

После новой выгрузки повторите три действия:

1. Запустите полную проверку, а не выборку первых строк.
2. Убедитесь, что повторов ID нет и количество уникальных ID равно количеству offer.
3. Сравните исправленную версию с предыдущей: разрешённые изменения должны быть объяснимы, а ID остальных товаров — сохраниться.

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

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.