Как менять offer id и переносить товары между YML-фидами
Содержание 10 разделов
offer id часто воспринимают как технический номер строки, который можно пересоздать при смене CMS или генератора. Для Яндекс Товаров это идентификатор предложения. Официальная документация требует сохранять его для одного и того же предложения во всех версиях фида и делать уникальным среди источников магазина. Массовая перенумерация выглядит для системы как исчезновение старых предложений и появление новых.
Особенно осторожно нужно переносить товар из одного YML-фида в другой. Яндекс предупреждает: если удалить предложение из одного источника и добавить в другой, оно может на несколько дней пропасть из результатов поиска. Поэтому миграцию планируют как изменение канала поставки данных, а не как простое копирование XML.
Когда id нужно сохранить, а когда допустим новый
Если покупатель видит тот же товар в том же магазине и предложение сохраняет смысл, идентификатор обычно оставляют. Смена CMS, доменного пути, программы выгрузки или номера записи во внутренней базе сама по себе не делает предложение новым. Для связи используют карту между старым offer id и новым внутренним ключом.
Новый id оправдан, когда предложение действительно стало другим: изменился объект продажи или старая запись была ошибочно объединена с другой. Решение принимают по бизнес-смыслу, а не по удобству генератора. Если один товар имеет варианты, следует заранее определить, что считается самостоятельным предложением, и применять правило одинаково во всех версиях.
| Изменение | Обычное решение для offer id | Что проверить |
|---|---|---|
| Смена CMS или PIM | Сохранить | Карта старого id к новой записи |
| Новый URL той же карточки | Сохранить | Редирект, доступность и совпадение товара |
| Перенос между фидами магазина | Сохранить уникальность и по возможности сам id | Нет ли одновременного дубля в двух источниках |
| Два предложения ошибочно имели один id | Разделить по согласованному правилу | Какое предложение продолжает прежнюю историю |
| Полностью новый объект продажи | Назначить новый | Устойчивость генерации в следующих версиях |
Почему нельзя использовать номер строки
Позиция товара в выгрузке меняется после сортировки, удаления и добавления. Если offer id строится из номера строки, сотни товаров получают новые идентификаторы при каждом обновлении каталога. Аналогичная проблема возникает со случайным значением, текущей датой и внутренним ключом временной таблицы.
Идентификатор должен воспроизводиться из постоянного ключа источника либо храниться в отдельном реестре. Этот реестр переживает миграцию. Перед переключением его выгружают, проверяют уникальность и загружают в новый генератор. Если постоянного ключа раньше не было, создают карту по нескольким признакам и вручную разбирают неоднозначные совпадения.
Инвентаризация перед переносом
Сохраните последнюю успешную версию каждого фида и составьте таблицу: offer id, внутренний товар, источник, URL карточки, категория, цена, наличие и планируемый целевой фид. Отдельно отметьте предложения, которые присутствуют сразу в нескольких файлах. Официальные рекомендации Яндекса требуют уникальности id среди всех фидов одного магазина, поэтому одинаковый идентификатор не должен одновременно описывать разные предложения.
Затем сравните фактические правила генерации. Один фид может использовать артикул, другой — числовой ключ CMS, третий — сочетание товара и склада. Без унификации перенос создаст коллизии. Карта соответствий должна явно показывать старый источник и id, новый источник и id, а также причину исключения или изменения.
Как переносить предложение поэтапно
- Подготовьте новый источник отдельно. Проверьте XML, обязательные элементы, ссылки, цены и изображения до рабочего переключения.
- Импортируйте реестр id. Для прежних предложений новый генератор должен выдавать те же устойчивые значения.
- Проверьте пересечения. Один id не должен в этот момент означать разные товары в двух источниках.
- Перенесите малую группу. Выберите товары разных категорий, с наличием и без него, со скидками и вариантами.
- Зафиксируйте момент переключения. Сохраните обе версии фидов и журнал публикации.
- Проверьте обработку Яндексом. Смотрите ошибки источника и наличие предложений, учитывая предупреждение о возможном временном исчезновении при переносе.
- Расширяйте пакет после контроля. Массовый перенос выполняют только после понятного результата пилота.
Нельзя обещать бесшовное сохранение показов: окончательное представление управляется Яндексом. Задача технической миграции — сохранить смысл и стабильность идентификаторов, не создать дубли и сократить период неопределённости за счёт поэтапного контроля.
Региональные фиды и дубли
Яндекс рекомендует разделять источники по регионам, если ассортимент или цены действительно различаются. При этом id предложения должен оставаться уникальным в рамках источников магазина согласно правилам. Нужно заранее решить, описывают ли региональные строки одно предложение с разными условиями или разные предложения. Случайное смешение правил приводит к тому, что один id то исчезает, то появляется в другом файле.
Разбиение имеет смысл только при реальном различии. Если все регионы получают одинаковый каталог, дополнительные фиды увеличивают число точек отказа. Для каждого источника придётся контролировать свежесть, объём, ошибки и пересечения. Архитектуру выбирают по данным бизнеса, а не ради формального деления.
Что делать при смене URL карточек
Изменение адреса не требует автоматически менять offer id. Старая страница должна корректно перенаправлять на новую, а новый URL — открываться без входа и показывать то же предложение. В фиде обновляют ссылку после готовности страницы. Одновременная массовая смена id, URL, названий и структуры категорий усложняет диагностику, поэтому изменения лучше разделить.
Если домен или CMS переключается целиком, проверяют выборку редиректов, канонические адреса, цены и наличие. Карта миграции связывает старый URL, новый URL и сохранённый offer id. Она полезна и после запуска: по ней можно объяснить, какое предложение исчезло и где его искать.
Как проверить новый генератор
- одинаковые входные данные дают одинаковый offer id при повторной генерации;
- внутри каждого файла и между файлами нет недопустимых коллизий;
- товары из карты сохраняют прежние идентификаторы;
- новые предложения получают id по устойчивому правилу;
- удалённые товары не возвращаются из старого кэша;
- число предложений и распределение по источникам совпадают с планом;
- рабочий URL отдаёт только полностью собранную версию.
Полезно автоматически сравнивать две выгрузки. Отчёт показывает добавленные, удалённые и изменённые id, а также товары, у которых поменялся id без изменения основных данных. Такой список просматривают до публикации. Резкий массовый churn идентификаторов считается блокирующей ошибкой.
План возврата при проблеме
До переключения храните предыдущий рабочий фид и карту состояния. Возврат означает публикацию последней проверенной версии по тому же URL либо восстановление старого источника по согласованной процедуре. Нельзя в панике генерировать третью схему id: это добавит ещё один слой новых предложений.
После возврата выясняют, что именно произошло: коллизия идентификаторов, недоступность источника, исчезновение категории, неверная цена или ожидаемая задержка обработки перенесённых товаров. Исправление проверяют на пилотной группе, а не повторяют полный перенос вслепую.
Что наблюдать после миграции
Минимальный мониторинг включает доступность и возраст фидов, количество offer в каждом источнике, уникальность id, число добавлений и удалений, ошибки Яндекса и доступность карточек. Отдельный отчёт по карте переноса показывает, какие прежние предложения присутствуют в целевом фиде и какие пропали.
Стабильный offer id — не косметическая деталь XML, а основа непрерывной истории предложения. Если сохранить идентификаторы, менять данные поэтапно и держать проверяемую карту, переход на новый генератор или структуру фидов становится управляемой операцией.