Почему 5000 товаров на Prom.ua убьют ваш бизнес без нормального автообновления (и как мы на этом обожглись)

Ноябрь 2021 года. К нам заходит клиент с каталогом на 8 400 позиций. Автотовары, инструмент, садовая техника. Три разных поставщика, у каждого свой формат прайсов. Контент-менеджер уверяла, что успеет вручную пересчитывать цены и остатки через Excel каждый день. Я тогда пожалел деньги клиента на разработку нормального скрипта и вынес вердикт: «Ну давай попробуем через стандартный импорт Prom раз в сутки».

Черная пятница. Поставщик поднял курс доллара в 8:00 утра и урезал остатки по ходовым позициям. Стандартный YML-файл Prom завис в очереди на импорт — платформа тогда просто легла под нагрузкой. К 14:00 мы продали 42 автотурбины и насоса по старой цене, которых даже не было в наличии у дистрибьютора. Итог — около $1 800 чистого убытка из своего кармана на отпевание репутации и выплату компенсаций разгневанным покупателям. Плюс рейтинг магазина улетел на дно из-за отмен.

Тогда я раз и навсегда понял: полная автоматизация prom интернет-магазин — это не роскошь и не опциональная фича. Это единственный способ не вылететь с рынка, когда у вас больше тысячи SKU.

Почему стандартный YML-импорт Prom.ua не работает на больших объемах

Пром — отличная площадка для старта. Залил 200 товаров, сидишь, принимаешь заказы. Но как только ваш каталог переваливает за 3 000–5 000 позиций, стандартные механизмы превращаются в тыкву.

Первая проблема — частота. Стандартное обновление по ссылке в кабинете Prom происходит в лучшем случае раз в сутки или раз в пару часов. За это время ходовой товар у поставщика выгребают трижды. Вы получаете заказ, звоните клиенту, а товара нет. Клиент пишет разгромный отзыв. Алгоритмы маркетплейса режут вам выдачу.

Вторая проблема — формат данных. Поставщики никогда не отдают прайсы в идеальном состоянии. У одного поставщика цены в евро, у другого в долларах без НДС, у третьего остатки указаны словами «много/мало», а у четвертого вообще нет YML — только хрупкий REST API или кривой CSV на FTP-сервере. Встроенный импорт площадки не умеет на лету конвертировать валюты по плавающему курсу, накладывать сложные правила маржинальности в зависимости от категории или склеивать дубликаты из разных источников.

Третья проблема — лимиты и задержки. Когда вы загружаете тяжелый файл на 15 000 строк через стандартный интерфейс, парсер Prom тратит десятки минут просто на валидацию текста и картинок. В этот момент ваша синхронизация склада prom встает намертво.

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

Если вы хотите выживать с каталогом в 10 000+ товаров, вам нужна независимая прослойка между поставщиками и площадкой. Не просто модуль для CMS, а отдельный сервисный скрипт, который держит руку на пульсе.

Вот как мы проектируем такие системы сейчас:

1. Дельта-обновления вместо полной перезагрузки. Не нужно каждый раз перегонять все 10 000 карточек с описаниями, фото и характеристиками. Это глупо и долго. Система должна отслеживать только изменения: изменилась цена на 5 гривен — отправляем запрос на изменение одной конкретной цены. Когда у поставщика меняются остатки prom автообновление должно срабатывать точечно и моментально по хуку или короткому крону каждые 10-15 минут.

2. Умный слой бизнес-логики. Цены должны считаться автоматически. Курс валюты поднялся на 30 копеек? Сервис сам пересчитал розницу с учетом вашей минимальной маржи, округлил до красивой цифры и ушел обновлять Prom. Поставщик поставил остаток «1 шт»? Система ставит «нет в наличии», потому что этот единственный экземпляр на складе поставщика с вероятностью 90% окажется браком или забронирован другим ритейлером.

3. Прямая работа через Prom API. Мы полностью отказываемся от тяжелых XML-файлов для оперативных задач. Прямые API-запросы позволяют делать обновление цен на prom за миллисекунды. Загрузили новый прайс от дистрибьютора — через 2 минуты на маркетплейсе уже актуальные цифры.

Суровые реалии, о которых не пишут в документации

За годы разработки мы наступили на все возможные грабли.

Например, лимиты API (rate limits). Если вы попытаетесь выплюнуть 5 000 запросов в минуту без очереди и задержек, Prom просто заблокирует ваш токен. Приходится строить системы очередей с экспоненциальной задержкой.

Или отваливающиеся API поставщиков. Поставщик меняет структуру JSON в пятницу в 18:00 и уходит на выходные. Без адекватного мониторинга ваш скрипт либо упадет, либо, что хуже, затрет все остатки в ноль. В наших системах мы всегда ставим предохранители: если скрипт видит, что прайс поставщика резко похудел на 50% товаров, автообновление блокируется, а администратор получает аларм в Telegram.

Считаем экономику: ручной труд против кода

Контент-менеджер на зарплате в 15 000–20 000 грн физически не способен поддерживать актуальность 5 000 товаров. Он будет ошибаться, уставать, пропускать позиции и увольняться каждые полгода от выгорания.

Один раз построенная и отлаженная автоматическая система окупается за 2-3 месяца просто за счет спасенных маржинальных заказов и отсутствия штрафов от маркетплейса за отмененные сделки.

Мы в GuardLabs съели не один пуд соли на настройке интеграций любой сложности. Если у вас большой каталог, кривые прайсы поставщиков и вам надоело краснеть перед клиентами за неактуальные цены — приходите. Мы умеем связывать любые базы данных, API поставщиков и Prom в единый монолит, который работает без сбоев. Посмотрите наше решение: Автообновление остатков и цен на Prom для больших каталогов. Сделаем один раз, но надежно — чтобы вы занимались продажами, а не ручной перерисовкой табличек в Excel.