7 500 генераций карточек для маркетплейсов: что делают селлеры и как это устроено под капотом

от автора

Публичной статистики о том, как продавцы маркетплейсов реально пользуются нейросетями, почти нет: обзоры пересказывают друг друга, а цифры остаются внутри сервисов. Мы делаем banan.wtf — сервис, который из одного фото товара собирает карточку для Wildberries и Ozon, — и решили показать свои данные.

Под катом: почему «идеальный промпт» — миф и пользователи мыслят диффами, а не промптами; в какое время суток селлеры на самом деле делают контент; что случилось со спросом этим летом — и как устроен пайплайн, который всё это переживает: fan-out на подзадачи, каскад моделей с фолбэком и realtime-прогресс через Redis pub/sub.

Дисклеймер: мы — заинтересованная сторона, поэтому в статье нет сравнений с конкурентами и «рейтингов». Только наши агрегированные данные и инженерные детали.

Откуда данные и что мы считали

Всё, что ниже, — обезличенные агрегаты сервиса за декабрь 2025 — июль 2026: суммарно более 7 500 генераций изображений. «Задачей» мы называем цепочку «исходное фото + все его правки»; статистику итераций и времени суток считали по последним 90 дням — это около 1 300 задач.

Никакие пользовательские изображения и тексты запросов не анализировались и не публикуются; часть цифр намеренно округлена. И важная оговорка: это данные одного сервиса с его аудиторией — переносить их на «весь рынок» стоит с осторожностью.

Миф об идеальном промпте

Самая устойчивая находка в данных — то, как на самом деле выглядит работа с генератором.

Как закрываются задачи генерации: 71% — первой генерацией, 29% — правками

Как закрываются задачи генерации: 71% — первой генерацией, 29% — правками

71% задач закрываются первой же генерацией: пользователь загрузил фото, выбрал шаблон или описал задачу — и результат сразу ушёл в карточку. Но оставшиеся 29% — самое интересное. Это не «неудачные» генерации: это нормальный рабочий процесс, где человек доводит результат серией коротких правок. Внутри таких цепочек — в среднем 3,4 генерации на задачу.

Реальные правки выглядят не как переписанный промпт, а как императивы: «замени фон», «убери тень», «сделай текст крупнее», «другой формат». Пользователь мыслит диффами к результату, а не описаниями с нуля.

Из этого следуют два вывода. Продуктовый: правки должны быть first-class операцией — UX в стиле «не понравилось? напиши новый промпт» заставляет начинать заново и проигрывает по времени. Экономический: одна карточка — это не одна генерация; в среднем по всем задачам выходит ≈1,7 генерации на результат, и это стоит закладывать и в мощности, и в юнит-экономику.

Инженерное следствие менее очевидно: контекст задачи — исходник, промежуточные версии, история правок — должен жить на сервере как единая сущность. Мы храним цепочку целиком: каждая правка ссылается на общий корень, оригиналы никогда не перезаписываются, а «регенерация» одного слайда просто добавляет версию в массив. Это дёшево и снимает целый класс багов вида «пользователь откатился, а откатываться некуда».

Когда селлеры делают карточки

Распределение генераций по времени суток: пик 11:00–19:00, 13% после 22:00

Распределение генераций по времени суток: пик 11:00–19:00, 13% после 22:00

Распределение по часам двугорбое: первый пик — 15:00, второй — 19:00 по Москве. Рабочий интервал 11:00–19:00 даёт чуть больше половины объёма, но каждая восьмая генерация происходит после 22:00, а ~5% — глубокой ночью.

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

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

Лето, когда спрос проснулся

Абсолютные объёмы мы не раскрываем, но динамику показать можем: после спокойной весны объём генераций вырос в несколько раз за один месяц — июнь 2026 стал рекордным за историю сервиса, и июль идёт с опережением. Всплеск совпал с двумя вещами: волной интереса к image-моделям нового поколения (то самое семейство, которое в рунете прозвали «нано-банана») и подготовкой селлеров к осеннему сезону.

Видео — формат, который пока никто не забрал

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

Как это устроено под капотом

Теперь инженерная часть — три решения, которые держат описанную выше нагрузку.

Схема пайплайна: фото → анализ → параллельные генерации → комплект; прогресс через Redis pub/sub и WebSocket

Схема пайплайна: фото → анализ → параллельные генерации → комплект; прогресс через Redis pub/sub и WebSocket

Fan-out: комплект из одной загрузки

«Комплект карточки» — это 5–7 изображений (главное фото 3:4, инфографика, lifestyle-слайды) плюс видеообложка из одной пользовательской загрузки. Внутри это устроено как fan-out: серверный анализ товара порождает набор подзадач с готовыми промптами, подзадачи уходят в очередь и обрабатываются воркерами параллельно, отдельно от API-процесса. Состояние живёт в MongoDB, воркер и веб-часть — разные процессы с общими моделями данных.

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

Каскад моделей: фолбэк только на инфраструктурных ошибках

Провайдеры image-моделей регулярно отдают таймауты, 5xx и модерационные отказы — это данность, под которую надо проектировать. Ретраить ту же модель при инфраструктурной ошибке почти бессмысленно: если у провайдера деградация, вы просто встанете в очередь за ошибкой.

У нас порядок моделей задаётся конфигом, и при инфраструктурном или сейфти-отказе задача каскадом уходит на следующую модель списка. Два принципа, которые выстраданы практикой:

  • фолбэк — только на технических ошибках. Никогда — на «результат не понравился»: иначе стиль комплекта становится непредсказуемым, а расходы — неконтролируемыми;

  • каскад должен покрывать и подзадачи комплекта. Если из семи изображений упало одно, перегенерировать нужно ровно его — на резервной модели, не трогая остальные.

Realtime вместо поллинга

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

Прогресс устроен так: воркер публикует события в Redis pub/sub, web-api подписан на канал и пробрасывает события в браузер по WebSocket. Карточки комплекта появляются в интерфейсе по мере готовности, а не все разом в конце.

Две грабли, на которые мы наступили и которые стоит обойти вам:

  1. события должны нести готовый DTO, а не только id. Иначе клиент бежит за данными в REST и начинаются гонки «событие пришло раньше, чем запись стала видна»;

  2. realtime-снапшот списка обязан повторять видимость REST-выдачи — те же фильтры, та же агрегация. У нас однажды push-обновление «раскрывало» элементы, которые REST скрывает, и список визуально ломался.

Кириллица на инфографике

Исторически текст на изображениях — ахиллесова пята генераторов, а кириллица — вдвойне. Для карточек маркетплейсов это блокер: инфографика без читаемых надписей бесполезна.

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

Что из этого следует

Если вы делаете продукт с генерацией изображений — вот выжимка из наших данных:

  1. Итеративность — норма, а не сбой. Проектируйте правки как основную операцию и считайте экономику из ≈1,7 генерации на результат, а не из одной.

  2. Ваши пики — не ваши рабочие часы. У аудитории малого бизнеса нагрузка живёт вечером и ночью; калибруйте мониторинг под неё.

  3. Каскад моделей — обязателен, но фолбэк только на инфраструктурных ошибках, иначе потеряете предсказуемость.

  4. Видео из фото — открытая ниша 2026 года на маркетплейсах: спрос уже виден в данных, конкуренция на площадках пока низкая.

Статистику обновляем ежеквартально; расширенная версия с методологией — в нашем блоге. Вопросы по методологии и данным — в комментарии, отвечу.

ссылка на оригинал статьи https://habr.com/ru/articles/1057938/