Подготовил финальное, расширенное ТЗ для WB Bidder с дорожной картой и архитектурой:
WB Bidder - SaaS-сервис для автоматизации рекламы продавцов Wildberries: управление ставками, контроль KPI, аналитика кампаний, парсинг позиций и AI-рекомендации. Сервис должен работать строго через официальные API Wildberries, безопасно хранить токены продавцов и регулярно обновлять рекламные данные через очереди и cron-задачи. Главная ценность продукта - не просто показывать метрики, а превращать их в конкретные действия: какие ставки изменить, какие фразы минусовать, какие кампании масштабировать, а какие остановить. Архитектура строится на единой TypeScript-экосистеме: NestJS для backend, Nuxt 3 для frontend, PostgreSQL для основных данных, Redis + BullMQ для фоновых задач.
WB Bidder должен занять позицию "операционного автопилота рекламы Wildberries" для продавцов и команд маркетинга.
Ключевое УТП:
- Actionable AI вместо абстрактной аналитики: советник формирует конкретные рекомендации с ожидаемым эффектом, риском и кнопкой применения.
- Гибкий биддер: стратегии удержания позиции, контроля CPO/ДРР и интеллектуального распределения бюджета между фразами.
- Быстрый старт: подключение магазина через OAuth или валидный токен категории "Продвижение", автоматическая первичная синхронизация кампаний, баланса и статистики.
- Белая интеграция: работа через официальные API Wildberries, шифрование токенов, аудит действий и прозрачные ограничения.
- Понятный интерфейс: главный экран сразу показывает товар, кампанию, зоны показа, ставки, KPI и рекомендации.
- Готовность к нагрузке: отдельные очереди для синхронизации, биддера, парсинга позиций, AI-отчетов и обслуживания данных.
Сильные стороны:
- Автоматизация ставок и удержание рекламных позиций.
- Поддержка сценариев оптимизации бюджета.
- Фокус на практических инструментах для продавцов маркетплейсов.
Слабые стороны и возможности для WB Bidder:
- Интерфейс может быть сложным для первичной настройки.
- AI-часть часто воспринимается как вспомогательная аналитика, а не как система принятия решений.
- WB Bidder должен дать более короткий путь от проблемы к действию: "обнаружено - объяснено - применено".
Сильные стороны:
- Автобиддер и аналитика рекламных кампаний.
- Работа с фразами, ставками и бюджетами.
- Полезные функции для массового управления.
Слабые стороны и возможности для WB Bidder:
- Высокий порог понимания для новых пользователей.
- Недостаточно прозрачная логика рекомендаций.
- WB Bidder должен показывать причину каждого изменения ставки: метрики, период, расчет, ожидаемый эффект.
Сильные стороны:
- Сильная аналитика рынка и конкурентов.
- Большой набор отчетов, графиков и сравнений.
- Полезен для стратегического анализа ниш, товаров и спроса.
Слабые стороны и возможности для WB Bidder:
- Не всегда закрывает ежедневную операционную задачу автоматического управления ставками.
- Много данных, но пользователю часто нужно самому превращать их в действия.
- WB Bidder должен соединить аналитику и исполнение: рекомендация должна быть применима к конкретной кампании, фразе и ставке.
Сильные стороны:
- Сильная продуктовая и конкурентная аналитика.
- Удобные отчеты для e-commerce-команд.
- Поддержка принятия решений по ассортименту и продвижению.
Слабые стороны и возможности для WB Bidder:
- Фокус шире рекламы, поэтому рекламный биддинг может быть не главным пользовательским сценарием.
- В ежедневной оптимизации рекламных расходов нужен более специализированный интерфейс.
- WB Bidder должен стать узким, быстрым и точным инструментом именно для рекламы WB.
Цель: объяснить ценность сервиса, собрать регистрацию и обеспечить SEO-видимость.
Обязательные блоки:
- Первый экран: название WB Bidder, краткое позиционирование, CTA "Подключить магазин" и "Посмотреть демо".
- УТП: AI-рекомендации, автобиддер, контроль CPO/ДРР, официальный API, быстрый запуск.
- "Как это работает": подключение магазина, синхронизация кампаний, выбор стратегии, применение рекомендаций.
- Блок сценариев: удержание позиции, снижение ДРР, масштабирование прибыльных фраз, ежедневный отчет.
- Тарифы: ограничения по магазинам, кампаниям, частоте обновления, AI-лимитам.
- FAQ: безопасность токенов, поддерживаемые типы кампаний, частота обновления, работа с OAuth.
- Футер: документы, контакты, политика конфиденциальности, пользовательское соглашение.
SEO и технические требования:
- SSR/SSG через Nuxt 3.
- OpenGraph и Twitter Cards.
- Schema.org: Organization, FAQPage, BreadcrumbList, SoftwareApplication.
- sitemap.xml и robots.txt.
- ЧПУ для публичных страниц.
- Core Web Vitals: LCP до 2.5 сек, CLS до 0.1, INP до 200 мс.
Функции:
- Регистрация и вход по email/password.
- Подтверждение email.
- Сброс пароля.
- Сессии с refresh-токенами и ротацией.
- Роли: owner, manager, analyst, admin.
- OAuth-подключение Wildberries при доступности потока OAuth.
- Ручное добавление API-токена, если OAuth недоступен для части сценариев.
Проверка токена:
- Проверить валидность токена через API Wildberries.
- Проверить, что токен относится к категории "Продвижение".
- При неверном типе токена показать явную ошибку: "Токен не подходит. Нужен токен категории Продвижение".
- Не сохранять невалидный токен.
- Валидный токен сохранять только в зашифрованном виде.
После подключения:
- Создать сущность магазина.
- Запустить первичную синхронизацию профиля продавца, рекламного баланса, списка кампаний и доступной статистики.
- Показать статус синхронизации в личном кабинете.
Безопасность:
- Argon2 или bcrypt для паролей.
- Шифрование токенов AES-256-GCM через KMS или envelope encryption.
- HTTPS only, Secure/HttpOnly/SameSite cookies.
- Аудит действий пользователя.
- Rate limiting на auth endpoints.
Основные разделы:
- Дашборд.
- Кампании.
- Биддер.
- Фразы и кластеры.
- Аналитика.
- AI-советник.
- Отчеты.
- Настройки магазина.
- Команда и роли.
Дашборд:
- Общий расход за период.
- Заказы, выручка, CPO, ДРР, CTR, CPC/CPM.
- Баланс рекламного кабинета.
- Кампании с лучшей и худшей динамикой.
- Последние рекомендации AI.
- Ошибки синхронизации и предупреждения по токенам.
Главный экран должен быть рабочим инструментом, а не обзорной витриной.
Состав экрана:
- Верхняя панель: выбор магазина, период, статус синхронизации, баланс, кнопка ручного обновления.
- Левая зона или верхний фильтр: список кампаний, статус, тип кампании, стратегия биддера.
- Карточка товара: фото, название, бренд, артикул WB, vendor code, текущий бюджет, расход, заказы.
- Управление зоной показа:
- "Поиск".
- "Рекомендации".
- Для автоматических кампаний - единая ставка и явная подсказка об ограничении API/типа кампании.
- Inline-редактирование ставок:
- ставка поиска;
- ставка рекомендаций;
- минимальная ставка;
- максимальная ставка;
- шаг изменения;
- дневной лимит.
- Таблица фраз/кластеров:
- фраза или кластер;
- статус;
- средняя позиция;
- частота;
- показы;
- клики;
- CTR;
- расход;
- CPC/CPM;
- заказы;
- CPO;
- ДРР;
- текущая ставка;
- рекомендуемая ставка;
- действие: запустить, остановить, минусовать, применить рекомендацию.
- Массовые действия:
- изменить ставки на процент;
- установить лимиты;
- остановить убыточные фразы;
- применить рекомендации AI;
- экспортировать CSV/XLSX.
Состояния интерфейса:
- Загрузка данных.
- Частичная ошибка API.
- Нет кампаний.
- Токен истек.
- Кампания не поддерживает раздельные ставки.
- Биддер выключен.
- Очередь обновления запущена.
Мастер создания:
- Выбор магазина.
- Выбор товаров.
- Выбор типа кампании: ручные ставки, АРК, рекомендательные полки, иные типы по доступности API.
- Настройка модели оплаты: CPM или CPC, если поддерживается типом кампании.
- Выбор фраз/кластеров.
- Бюджет и дневной лимит.
- Стратегия биддера.
- Предпросмотр.
- Создание и первичная синхронизация.
Валидации:
- Бюджет не ниже минимального допустимого значения API.
- Ставки в допустимом диапазоне.
- Товар доступен для продвижения.
- Кампания не дублирует уже активный сценарий без подтверждения.
Биддер работает как набор фоновых задач BullMQ. Каждая задача получает актуальные настройки стратегии, последние метрики, позицию, бюджетные ограничения и принимает решение о ставке.
Общие правила:
- Не менять ставку чаще заданного интервала.
- Соблюдать minBid, maxBid, bidStep, dailyBudget.
- Учитывать задержку статистики WB.
- Все изменения писать в журнал bid_decisions.
- Перед применением проверять, не изменилась ли настройка кампании пользователем.
- При ошибке API повторять через backoff и фиксировать ошибку.
Параметры:
- targetPositionFrom.
- targetPositionTo.
- city или регион проверки.
- maxBid.
- minBid.
- bidStep.
- resetOnCeiling: true/false.
- notifyOnCeiling: true/false.
Алгоритм:
- Получить последнюю позицию по фразе и городу.
- Если позиция хуже целевого диапазона, повысить ставку на bidStep, но не выше maxBid.
- Если позиция лучше верхней границы диапазона, снизить ставку на bidStep или на адаптивный процент.
- Если достигнут maxBid и позиция все еще хуже цели, выполнить reset до minBid или отправить уведомление.
- Записать решение и причину.
Цель: удерживать видимость, но не переплачивать за позиции выше заданного диапазона.
Параметры:
- targetCpo.
- targetDrr.
- attributionWindow.
- minOrdersForDecision.
- maxBid.
- minBid.
- aggressiveness.
Алгоритм:
- Собрать статистику за окно анализа.
- Если заказов меньше minOrdersForDecision, использовать мягкий режим и не делать резких изменений.
- Если CPO или ДРР выше цели, снижать ставку или останавливать фразу при критическом отклонении.
- Если CPO или ДРР ниже цели и есть потенциал показов, повышать ставку.
- Учитывать CTR: высокий CTR при низкой конверсии - кандидат на проверку карточки товара или минусацию.
Цель: не удерживать позицию любой ценой, а максимизировать заказы в рамках KPI.
Параметры:
- dailyBudget.
- targetCpo или targetDrr.
- reservePercent.
- minBudgetPerPhrase.
- maxBudgetSharePerPhrase.
- learningModeDays.
Алгоритм:
- Разделить фразы на группы: прибыльные, перспективные, нейтральные, убыточные.
- Выделить базовый бюджет на обучение.
- Основной бюджет распределить в пользу фраз с лучшим CPO/ДРР и достаточным объемом.
- Ограничить долю одной фразы, чтобы избежать концентрационного риска.
- Убыточные фразы снижать, останавливать или отправлять в AI-рекомендации на минусацию.
Цель: тратить дневной бюджет там, где он дает больше заказов.
Функция строит зависимость между позицией, ставкой, расходом, заказами и CPO. Система постепенно тестирует несколько диапазонов позиций и выбирает тот, где CPO соответствует цели, а количество заказов максимально.
Ограничения:
- Не запускать тесты на низком объеме данных без предупреждения.
- Не менять одновременно слишком много фраз.
- Сохранять контрольную группу для сравнения.
AI-советник - ключевой модуль продукта. Он не заменяет биддер, а объясняет, где есть возможность сэкономить, масштабировать или исправить кампанию.
Типы рекомендаций:
- Повысить ставку по фразе, потому что CPO ниже цели и есть недобор показов.
- Снизить ставку, потому что ДРР превышает порог.
- Остановить фразу, потому что расход есть, заказов нет, статистически значимый объем достигнут.
- Минусовать кластер как нерелевантный.
- Увеличить дневной бюджет кампании, если она стабильно прибыльна и упирается в лимит.
- Проверить карточку товара, если CTR высокий, но конверсия низкая.
- Проверить цену или наличие, если показы и клики упали без изменения ставки.
- Масштабировать кампанию, если CPO стабильно ниже целевого.
Виджет реального времени:
- Плашка над таблицей: "Советник: 3 фразы можно улучшить".
- Клик открывает список рекомендаций.
- Каждая рекомендация содержит: действие, причину, метрики, ожидаемый эффект, риск, кнопку применения.
- Пользователь может применить одну рекомендацию, применить все безопасные или отклонить.
Ежедневный отчет:
- Отправка в личный кабинет и на email.
- Сводка KPI за день.
- Успешные кампании для масштабирования.
- Убыточные кампании для оптимизации.
- Аномалии CPO/ДРР.
- Изменения позиций.
- Рекомендации на следующий день.
LLM-интеграция:
- В админке задается провайдер: OpenAI, Anthropic, YandexGPT или совместимый endpoint.
- Настраиваются модель, API-ключ, лимиты и temperature.
- Система prompt templates хранится версионированно.
- На вход LLM передаются агрегированные данные без секретов и токенов.
- Ответ LLM валидируется по JSON Schema.
- Перед автоприменением рекомендация должна пройти правила безопасности.
Пример структуры ответа AI:
{
"campaignId": "123",
"recommendations": [
{
"type": "decrease_bid",
"target": "keyword:summer dress",
"currentBid": 125,
"recommendedBid": 95,
"reason": "ДРР 31% выше целевого 20% при достаточном объеме кликов",
"expectedEffect": "Снижение расхода без существенной потери заказов",
"risk": "medium"
}
]
}Метрики:
- Показы.
- Клики.
- CTR.
- Расход.
- CPC.
- CPM.
- Заказы.
- Выручка.
- CPO.
- ДРР.
- Средняя позиция.
- Конверсия в заказ.
- Остаток бюджета.
Отчеты:
- По кампаниям.
- По товарам.
- По фразам и кластерам.
- По зонам показа.
- По стратегиям биддера.
- По действиям AI.
Фильтры:
- Период.
- Магазин.
- Кампания.
- Товар.
- Тип кампании.
- Статус.
- Стратегия.
Экспорт:
- CSV.
- XLSX.
- Асинхронная генерация больших отчетов через очередь.
Парсинг позиций выносится в отдельный сервис, чтобы изолировать браузерные процессы и не нагружать основной API.
Функции:
- Очередь задач на проверку позиции.
- Поддержка HTTP, HTTPS, SOCKS5 прокси.
- Ротация прокси при ошибках, банах и таймаутах.
- Ограничение частоты запросов.
- Проверка позиции по фразе, товару, городу и зоне показа.
- Сохранение результата в positions_history.
Техническая реализация:
- Node.js + Playwright.
- Отдельный Docker image.
- Управление задачами через BullMQ.
- Health endpoint.
- Метрики времени выполнения, ошибок, успешности прокси.
Разделы:
- Пользователи: просмотр, блокировка, смена роли.
- Магазины: статус подключения, ошибки токенов, дата последней синхронизации.
- AI-провайдеры: ключи, модели, лимиты, тест запроса.
- Прокси: добавление, удаление, проверка, статистика ошибок.
- Очереди: статус BullMQ, количество задач, failed jobs, retry.
- Cron-задачи: расписание, последний запуск, следующий запуск, статус.
- Логи: фильтр по уровню, сервису, магазину, кампании.
- Аудит: кто применил рекомендацию, кто изменил ставку, когда и почему.
Рекомендуемая реализация: BullMQ + Redis repeatable jobs. Для небольшой MVP-инсталляции допустим NestJS Schedule как thin scheduler, который ставит задачи в BullMQ. Бизнес-работа должна выполняться воркерами, а не внутри cron handler.
Причина выбора:
- BullMQ устойчивее для повторов, backoff, параллельной обработки и горизонтального масштабирования.
- Redis позволяет разделить API-сервис, воркеры и парсер.
- Failed jobs можно повторять и анализировать.
- Задачи можно шардировать по магазинам и кампаниям.
Обязательные задачи:
| Задача | Частота | Очередь | Назначение |
|---|---|---|---|
| syncCampaignStats | 5-15 минут | stats-sync | Получение статистики кампаний через API WB |
| syncBalance | 5 минут | balance-sync | Обновление рекламного баланса и бюджетов |
| runBidder | 5 минут | bidder | Расчет и применение ставок |
| parsePositions | 5 минут | position-parser | Проверка позиций по фразам и городам |
| generateAiReports | ежедневно 00:05 | ai-reports | Дневная агрегация и рекомендации |
| cleanupOldData | ежедневно | maintenance | Очистка устаревших логов и временных данных |
| checkTokens | ежедневно | maintenance | Проверка состояния токенов и уведомления |
Правила надежности:
- Идемпотентность задач.
- Distributed lock на магазин/кампанию.
- Retry с exponential backoff.
- Dead letter queue для задач после N ошибок.
- Метрики длительности, ошибок и количества задач.
- Алерты при росте failed jobs.
Цель: запустить безопасный кабинет с подключением магазина и чтением рекламных данных.
Задачи:
- Создать монорепозиторий: apps/api, apps/web, apps/position-parser, packages/shared.
- Настроить NestJS API.
- Настроить Nuxt 3 frontend.
- Подключить PostgreSQL и Redis.
- Настроить Prisma или TypeORM.
- Реализовать auth: регистрация, вход, refresh-сессии, роли.
- Реализовать подключение WB: OAuth или API-токен.
- Реализовать шифрование токенов.
- Реализовать первичную синхронизацию профиля, баланса и кампаний.
- Сделать дашборд с профилем магазина, балансом и списком кампаний.
- Добавить базовый CI: lint, typecheck, test, build.
Критерии готовности:
- Пользователь регистрируется.
- Подключает магазин.
- Видит баланс и кампании.
- Ошибки токена понятны пользователю.
Цель: реализовать основной продуктовый сценарий управления рекламой.
Задачи:
- Реализовать таблицы настроек стратегий.
- Реализовать BullMQ очереди и воркеры.
- Реализовать журнал bid_decisions.
- Реализовать стратегию фиксации позиции.
- Реализовать стратегию CPO/ДРР.
- Реализовать стратегию распределения бюджета.
- Реализовать микросервис парсинга позиций.
- Реализовать пул прокси.
- Сделать главный экран биддера на Nuxt.
- Добавить inline-редактирование ставок.
- Добавить массовые действия.
- Добавить ручной запуск пересчета.
Критерии готовности:
- Биддер меняет ставки по правилам стратегии.
- Все решения логируются.
- Пользователь может включить, выключить и настроить стратегию.
- Позиции регулярно обновляются.
Цель: превратить сервис в систему рекомендаций и управленческой аналитики.
Задачи:
- Реализовать детальные отчеты по кампаниям, товарам, фразам.
- Добавить графики и сравнение периодов.
- Реализовать экспорт CSV/XLSX.
- Реализовать AI pipeline: сбор данных, prompt, LLM call, JSON validation, сохранение рекомендаций.
- Реализовать виджет AI-советника.
- Реализовать ежедневные email-отчеты.
- Реализовать админку управления AI-провайдерами.
- Реализовать админку прокси, пользователей, очередей и cron-задач.
Критерии готовности:
- Советник выдает конкретные рекомендации.
- Рекомендации можно применить или отклонить.
- Дневной отчет приходит автоматически.
- Администратор видит состояние системы.
Цель: подготовить систему к коммерческой эксплуатации.
Задачи:
- Покрыть критическую бизнес-логику unit-тестами.
- Добавить integration tests для API WB adapter, очередей и auth.
- Добавить e2e-тесты ключевых сценариев.
- Настроить Docker и Docker Compose.
- Настроить staging и production окружения.
- Настроить GitHub Actions: lint, test, build, Docker image.
- Добавить Sentry.
- Добавить Prometheus и Grafana.
- Провести нагрузочное тестирование очередей и API.
- Добавить rate limits и circuit breakers для внешних API.
- Подготовить SLA, backup policy и runbooks.
Критерии готовности:
- Сервис выдерживает расчетную нагрузку.
- Есть мониторинг, алерты и резервные копии.
- Релиз повторяем через CI/CD.
- Команда поддержки понимает, как реагировать на сбои.
Технологии:
- Node.js.
- NestJS.
- TypeScript.
- Prisma или TypeORM.
- PostgreSQL.
- Redis.
- BullMQ.
Обоснование:
- Единый TypeScript-стек с frontend ускоряет разработку.
- NestJS дает модульную архитектуру, DI, guards, interceptors, pipes и удобную интеграцию с очередями.
- Node.js хорошо подходит для I/O-интенсивных задач: внешние API, очереди, WebSocket, отчеты.
- PostgreSQL надежен для транзакционных данных и аналитических запросов среднего объема.
- Redis нужен для очередей, кэша, distributed locks и rate limiting.
Основные backend-модули:
- AuthModule.
- UsersModule.
- StoresModule.
- WbIntegrationModule.
- CampaignsModule.
- BidsModule.
- BidderStrategiesModule.
- StatisticsModule.
- PositionsModule.
- AiAdvisorModule.
- ReportsModule.
- NotificationsModule.
- AdminModule.
- AuditModule.
- BillingModule.
Технологии:
- Nuxt 3.
- Vue 3.
- TypeScript.
- Pinia.
- SSR/SSG.
Обоснование:
- Nuxt 3 подходит одновременно для SEO-лендинга и личного кабинета.
- SSR улучшает индексацию публичных страниц.
- SSG можно использовать для статичных marketing-страниц.
- Vue 3 и Composition API удобны для сложных таблиц, фильтров и форм.
Frontend-разделы:
- Публичный лендинг.
- Auth pages.
- Onboarding магазина.
- Dashboard.
- Campaigns.
- Bidder workspace.
- Analytics.
- AI Advisor.
- Reports.
- Admin.
Технологии:
- Node.js.
- Playwright.
- BullMQ consumer.
- Proxy manager.
Обоснование:
- Парсинг позиций требует отдельной изоляции от API-сервиса.
- Playwright устойчив для браузерных сценариев и headless-проверок.
- Горизонтальное масштабирование воркеров позволяет увеличивать частоту проверок.
Development:
- Docker Compose: api, web, postgres, redis, parser, mailhog.
Production:
- Docker images.
- Kubernetes или managed container platform.
- Managed PostgreSQL.
- Managed Redis.
- Object storage для экспортов и логов.
- CDN для frontend assets.
Monitoring:
- Prometheus для метрик.
- Grafana для дашбордов.
- Sentry для ошибок.
- Structured JSON logs.
CI/CD:
- GitHub Actions.
- Проверки: lint, typecheck, tests, build.
- Сборка Docker images.
- Deploy на staging.
- Manual approval для production.
Пользователь открывает Nuxt 3 frontend. Frontend обращается к NestJS API через HTTPS. API работает как основной backend и содержит доменные модули: пользователи, магазины, кампании, статистика, биддер, AI-советник и админка. PostgreSQL хранит основные сущности, настройки и историю решений. Redis используется для кэша, distributed locks и очередей BullMQ.
NestJS API не выполняет тяжелые задачи синхронно. Он ставит задания в BullMQ: синхронизация статистики, обновление баланса, запуск биддера, генерация AI-отчетов, экспорт файлов. Отдельные NestJS worker-процессы забирают эти задания, обращаются к API Wildberries, применяют ставки и сохраняют результаты. Микросервис position-parser слушает свою очередь, проверяет позиции через Playwright и прокси, затем пишет результаты в API или напрямую в PostgreSQL через безопасный internal endpoint.
AI Advisor получает агрегированные данные из PostgreSQL, формирует prompt, вызывает выбранного LLM-провайдера, валидирует JSON-ответ и сохраняет рекомендации. Пользователь видит рекомендации в кабинете и применяет их через API. Каждое применение фиксируется в audit log.
Ключевые сущности:
- users: учетные записи.
- organizations: команды и владельцы.
- organization_members: роли пользователей.
- stores: подключенные магазины WB.
- wb_tokens: зашифрованные токены и metadata.
- campaigns: рекламные кампании.
- products: товары.
- campaign_products: связь кампаний и товаров.
- keywords: фразы и кластеры.
- keyword_stats_daily: дневная статистика.
- campaign_stats_daily: дневная статистика кампаний.
- positions_history: история позиций.
- bidder_settings: настройки биддера.
- bidder_strategies: типы и параметры стратегий.
- bid_decisions: журнал решений биддера.
- ai_recommendations: рекомендации советника.
- reports: экспортированные отчеты.
- proxy_pool: прокси.
- job_runs: история фоновых задач.
- audit_logs: аудит действий.
Примерные группы endpoint:
- POST /auth/register.
- POST /auth/login.
- POST /auth/refresh.
- POST /auth/logout.
- GET /stores.
- POST /stores/connect.
- POST /stores/:id/sync.
- GET /stores/:id/balance.
- GET /campaigns.
- GET /campaigns/:id.
- PATCH /campaigns/:id/bids.
- GET /campaigns/:id/keywords.
- PATCH /keywords/:id/bid.
- POST /keywords/bulk-actions.
- GET /analytics/campaigns.
- GET /analytics/keywords.
- POST /reports/export.
- GET /ai/recommendations.
- POST /ai/recommendations/:id/apply.
- POST /ai/recommendations/:id/dismiss.
- GET /admin/jobs.
- GET /admin/proxies.
- POST /admin/proxies.
Минимальный набор тестов:
- Unit-тесты стратегий биддера.
- Unit-тесты расчета CPO, ДРР, CTR.
- Unit-тесты валидации токенов.
- Integration tests для BullMQ jobs.
- Integration tests для WB API adapter с mock server.
- E2E-тест подключения магазина и просмотра кампаний.
- E2E-тест настройки стратегии биддера.
- Contract tests для JSON-ответов AI.
Надежность:
- Idempotency keys для фоновых задач.
- Optimistic locking при изменении ставок.
- Circuit breaker для API Wildberries.
- Backoff и retry.
- Dead letter queue.
- Audit log для всех действий.
- Feature flags для новых стратегий.
- API - программный интерфейс для обмена данными между системами.
- WB API - официальные API Wildberries, включая API продвижения.
- OAuth - протокол авторизации через перенаправление без передачи пароля сервису.
- API-токен - секретный ключ для доступа к API продавца.
- Биддер - система автоматического управления рекламными ставками.
- Ставка - цена, которую рекламодатель готов платить за показ, клик или размещение.
- CPO - Cost Per Order, стоимость одного заказа.
- CPC - Cost Per Click, стоимость клика.
- CPM - Cost Per Mille, стоимость тысячи показов.
- CTR - Click Through Rate, отношение кликов к показам.
- ДРР - доля рекламных расходов, отношение рекламных расходов к выручке.
- Кластер - группа близких поисковых фраз или тематических запросов.
- Фраза - поисковый запрос или рекламная фраза, по которой показывается товар.
- АРК - автоматическая рекламная кампания.
- Cron - регулярная задача, выполняемая по расписанию.
- BullMQ - очередь задач для Node.js на базе Redis.
- Redis - in-memory хранилище для очередей, кэша и блокировок.
- PostgreSQL - реляционная база данных.
- SSR - server-side rendering, рендеринг страницы на сервере.
- SSG - static site generation, генерация статичных страниц.
- LLM - большая языковая модель.
- AI-советник - модуль, который анализирует данные и формирует рекомендации.
- Proxy pool - набор прокси-серверов для распределения запросов.
- Worker - процесс, который выполняет фоновые задачи из очереди.
- Dead letter queue - очередь задач, которые не удалось выполнить после повторов.
- Audit log - журнал действий пользователей и системы.