Разработка товарного фида

Начинаем всегда с «разбора полётов» — без понимания, что у вас в каталоге, любая генерация фида это стрельба вслепую. Проверяем структуру данных — какие поля есть, какие пустуют, где дубли, как закодированы спецсимволы. Часто оказывается, что «цена» хранится в одном месте, «наличие» в другом, а «картинки» вообще в облаке с доступом по сессии. Если честно, в 9 из 10 случаев мы находим критичные пробелы, которые не дают фиду пройти валидацию с первого раза.

Что именно смотрим:

• Обязательные атрибуты для целевых площадок: id, name, price, availability, image_link, gtin.
• Форматы данных: числа без пробелов, даты в ISO, URL с HTTPS.
• Кодировку и экранирование: чтобы кавычки, амперсанды и кириллица не ломали XML.
• Источники данных: CMS, «1С», CRM, парсинг — откуда тянуть актуальные значения.

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

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

Переходим от «что есть» к «что нужно площадке». Разбираем требования «Яндекс Товаров», Avito или других каналов — какие поля обязательны, какие рекомендованы, какие форматы допустимы. Нужно предусмотреть все детали, чтобы модерация приняла с первого раза.

Процесс выглядит так:

1. Составляем таблицу соответствия: ваше поле product_name → требование площадки title.
2. Прописываем правила трансформации: обрезка длинных текстов, форматирование цен, подстановка дефолтных значений.
3. Согласовываем исключения: как обрабатывать товары без фото, без GTIN, с нулевым остатком.

Мы не берём маппинг «с потолка». Если площадка требует condition со значениями new/refurbished/used, а у вас в базе только «новый» или «б/у», мы прописываем правило конвертации. На этом этапе иногда всплывают скрытые нюансы — например, необходимость мультиязычных значений или региональных цен.

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

Пишем скрипт под вашу инфраструктуру, который выгружает данные из источника, применяет правила маппинга и собирает валидный XML/CSV/YML. Важно сделать так, чтобы процесс можно было повторять автоматически.

Типичные задачи, которые решаем:

1. Экранирование спецсимволов: & → &, < → <, кавычки → ".
2. Форматирование цен: без пробелов, с точкой как разделителем, в нужной валюте.
3. Подстановка дефолтов: если нет brand — берём из категории, если нет gtin — помечаем как custom.
4. Сортировка и группировка: чтобы фид был читаемым и удобным для отладки.

Если просто выгрузить данные без проверки кодировки, фид может «поехать» на кириллице или спецсимволах. Фид — это не файл, а конвейер, поэтому если одно звено кривое, вся линия встаёт. Поэтому мы закладываем валидацию на каждом шаге: проверка обязательных полей, контроль дублей, логирование ошибок.

В финале получаем отлаженный механизм генерации. Все данные проверены, структура соответствует спецификации, кодировка UTF-8 без BOM. Если у вас 50 000 товаров — скрипт будет работать порциями, без перегрузки памяти.

Наша задача — чтобы фид прошёл модерацию с первого раза, а не висел в статусе «на проверке» неделями. Поэтому проводим многоуровневую валидацию, проверяем его на соответствие спецификациям площадок, делаем тестовую загрузку в sandbox, анализируем предупреждения и ошибки.

Что именно проверяем:

• Синтаксис XML/CSV: корректность тегов, кавычек, разделителей, кодировки.
• Обязательные атрибуты: все ли поля заполнены, в нужном ли формате.
• Бизнес-правила: цена > 0, ссылка доступна, изображение загружается, GTIN уникален.
• Площадочные валидаторы: «Яндекс Вебмастер», Avito API.

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

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

Как это работает на практике:

• Cron-задача на сервере — скрипт запускается каждый час/день и перегенерирует фид.
• Webhook от CMS — при изменении товара система сама инициирует обновление.
• API-интеграция — фид формируется «на лету» при запросе от площадки.

Если настроить автообновление без контроля нагрузки, скрипт может «повесить» базу в пиковый час. Поэтому мы кэшируем тяжёлые запросы, разбиваем выгрузку на порции, логируем ошибки.

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

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

Что входит в передачу:

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

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