Анализ конкурентов SMM: архитектура Feberra

Feberra закрылась не потому что провалилась, а потому что выросла из своей формы - и это, пожалуй, самый честный итог, который может быть у продукта. Мы построили SaaS-платформу, которая автоматизировала анализ конкурентов SMM в Instagram и TikTok: следила за рилсами, прогоняла их через маркетинговый фильтр и выдавала готовые сигналы - что сейчас работает в нише, почему, и как адаптировать под себя. Платформа закрыта, но архитектура и идеи оказались настолько интересными, что я решил разобрать её по косточкам и переосмыслить в виде нового инструмента.

В этой статье я расскажу, что было внутри Feberra, какие технические решения мы принимали, с какими проблемами столкнулись, и куда движется следующая итерация — content-farm, внутренний инструмент для анализа трендов и генерации сценариев.

Что такое Feberra и зачем она вообще нужна

Задача звучит просто: SMM-щик или маркетолог хочет знать, что сейчас работает у конкурентов. Не просто «посмотреть их профиль», а получить структурированный сигнал — рилс, который набрал аномальный рост за последние 48 часов, с разбором хука, структуры, визуала и адаптацией под свою нишу.

Feberra решала эту задачу полного цикла: от скрапинга до генерации видео. Стек — Convex как бэкенд-платформа с реактивной базой данных, Trigger.dev для фоновых задач и очередей, Dokploy на VPS для деплоя, n8n для автоматизации части пайплайна. Фронтенд — Next.js.

Архив бэкапа при закрытии весил 752 МБ. Внутри — 1176 Convex-функций, 90+ таблиц, история из сотен тысяч запусков фоновых задач.

Scraper-пайплайн: как собирались данные

Самая сложная часть любого подобного продукта — это надёжный сбор данных. Instagram и TikTok активно борются со скрапингом, поэтому пайплайн был устроен с несколькими уровнями защиты и резервирования.

Основной поток выглядел так:

Cron (каждые 2 часа)
  → Trigger.dev: dispatch-reels-scrape
  → n8n webhook → внешний scraper API
  → Trigger.dev: process-results
  → Convex: upsert в socialAccountReels
  → trends.analyze-workspace
  → trendSignalEvents (обновление метрик)

Каждые два часа крон запускал задачу в Trigger.dev, которая через n8n обращалась к внешнему scraper API. Результаты возвращались обратно в Trigger.dev, обрабатывались и записывались в Convex. Параллельно запускался анализ трендов — функция смотрела на динамику метрик каждого рилса и решала, стоит ли он того, чтобы стать «сигналом».

Масштаб операций впечатляет: 323k dispatch-запусков, 244k process-results, и это только по основным задачам. Таблица trendSignalEvents разрослась до 969 МБ — и это не баг, а фича. Именно история изменения метрик во времени позволяла понять, рилс «выстрелил и затух» или «продолжает расти».

Маркетинговый фильтр: не каждый рилс становится сигналом

Ключевое архитектурное решение, которое отличало Feberra от простого парсера — жёсткий многоступенчатый фильтр. Рилс не становился сигналом сразу после скрапинга. Он проходил через систему стадий:

• SEED — свежий рилс, только попал в систему, метрики ещё не устоялись
• SSN — первые признаки роста выше среднего по нише
• SSN1 — устойчивый рост на протяжении нескольких дней
• SSN2 — «горячий» сигнал, аномальный рост, высокая релевантность

Система отслеживала каждый рилс на протяжении нескольких дней, обновляя метрики при каждом скрапинге. Только рилсы, которые демонстрировали устойчивый рост и прошли пороговые значения по просмотрам, лайкам и комментариям, поднимались до стадии SSN1 и SSN2 и попадали в интерфейс как «сигналы».

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

Trend Watching: интерфейс для работы с сигналами

Пользователь видел не сырые данные, а обработанные сигналы в виде плиток. Каждая плитка содержала:

• Вертикальный thumbnail рилса в пропорции 9:16
• Имя аккаунта конкурента и его ниша
• Ключевые метрики: просмотры, лайки, комментарии, ER
• Спарклайн динамики просмотров за последние 7-10 дней
• Бейдж стадии (SEED / SSN / SSN1 / SSN2) с цветовой кодировкой
• Краткий AI-инсайт: почему этот рилс работает

Фильтрация и сортировка позволяли быстро находить нужное: по нише, по стадии, по дате, по метрикам. Отдельный блок «AI рекомендует сегодня» показывал топ-3 сигнала, релевантных конкретному проекту пользователя.

Организация по проектам была принципиальной: у каждого проекта свой список конкурентов, своя ниша, свой TOV (tone of voice). Переключалка проектов в шапке позволяла работать с несколькими клиентами или направлениями одновременно.

Workspace: от сигнала к сценарию

Когда пользователь нажимал «Использовать» на сигнале, он попадал в рабочую зону — chat-driven workspace. Не классический wizard с шагами, а диалог с AI, который ведёт через процесс адаптации референса.

Архитектура воркспейса строилась на принципе multi-agent: не один большой LLM-вызов, а оркестратор и специализированные агенты:

Оркестратор (режиссёр)
  ├── AI-аналитик сигналов
  │     → транскрипция + визуальный анализ рилса
  │     → инсайт: хук, структура, почему зашло
  ├── AI-сценарист
  │     → адаптация под нишу и TOV проекта
  │     → генерация альтернативных хуков
  └── (в будущем) AI-монтажёр
        → b-roll подбор, таймлайн

Оркестратор общается с пользователем, понимает задачу и передаёт ТЗ специализированным агентам. Каждый агент заточен под свою задачу и имеет узкий контекст. Результаты агентов возвращаются оркестратору, который собирает финальный артефакт и представляет его пользователю.

Пользователь видит только чистый UI: индикатор «AI думает» и появляющиеся артефакты. Внутренний trace агентов пишется в базу для дебага, но не показывается в интерфейсе.

Карточка инсайта: центральный артефакт

Главный результат первого шага в воркспейсе — карточка разбора референса. Принцип: AI-рассуждение важнее сырых данных. Пользователь сам видит рилс, ему не нужна транскрипция — ему нужна интерпретация.

┌─ 🔍 Разбор реферанса ─────────────────────────┐
│                                                 │
│ 🎣 ХУК (первые 1.8 сек)                        │
│ «Жилая недвижимость — это пассив»              │
│ Тип: провокационное утверждение                │
│ Почему работает: разрушает убеждение большинства│
│                                                 │
│ 📐 СТРУКТУРА                                    │
│ Хук → Доказательство (цифры) → Альтернатива    │
│ → CTA «сохрани, чтобы не забыть»               │
│                                                 │
│ 👁 ВИЗУАЛ                                       │
│ Говорящая голова, быстрый монтаж, субтитры     │
│ Нейтральный фон, акцент на лице                │
│                                                 │
│ 💡 ПОЧЕМУ ЗАШЛО                                 │
│ Триггер «я так и думал, но боялся сказать»     │
│ + конкретные цифры = доверие                   │
└─────────────────────────────────────────────────┘

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

Память между сессиями

Одна из ключевых проблем chat-driven воркспейса — потеря контекста между сессиями. Мы разделили память на четыре типа:

Project Context — статичный, редактируется пользователем в настройках проекта. Ниша, TOV, описание продукта, целевая аудитория. Всегда подгружается в контекст агентов.

Session Memory — контекст текущей сессии работы с конкретным сигналом. Что уже обсудили, какие варианты отклонили, почему.

Cross-session Learnings — паттерны, которые AI извлекает из истории: какие хуки пользователь обычно принимает, какой стиль сценариев ему нравится. Накапливается со временем.

Signal History — какие сигналы уже были в работе, какие отклонены, чтобы не предлагать повторно.

Технические решения и их обоснование

Выбор Convex как основного бэкенда был неочевидным, но оправданным. Convex даёт реактивные запросы из коробки — UI автоматически обновляется при изменении данных в базе. Для Trend Watching, где метрики обновляются каждые два часа, это критично: пользователь видит свежие данные без ручного обновления страницы.

Trigger.dev для фоновых задач решал проблему надёжности: задачи персистентны, имеют retry-логику, можно смотреть историю запусков и дебажить конкретный run. 323k успешных dispatch-запусков — это не случайность, а результат правильно настроенной инфраструктуры очередей.

n8n как промежуточный слой для работы со scraper API добавлял гибкость: можно было менять провайдера скрапинга без изменения основного кода. Минус — n8n стал SPOF (single point of failure). В следующей итерации это решается мониторингом и инфра-избыточностью.

Для нового проекта (content-farm) стек смещается: Next.js + Supabase + Dokploy. Supabase даёт PostgreSQL с удобным API, Row Level Security и встроенную аутентификацию. Это проще и дешевле Convex для internal tool, где не нужна реактивность на уровне платформы.

Что не сработало и почему

Feberra закрылась не из-за технических проблем. Архитектура работала. Проблема была в позиционировании: полный цикл «анализ → генерация видео → публикация» требовал слишком много от пользователя на каждом шаге, и слишком много от нас в плане поддержки всего пайплайна.

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

Ещё одна проблема — мультитенантность. Биллинг, тарифные планы, onboarding-воронка, email-маркетинг — всё это отвлекало от core-продукта. В ретроспективе правильнее было начать с internal tool для себя и команды, отточить пайплайн, и только потом думать о SaaS.

Content-farm: следующая итерация

Новый проект — content-farm — это переосмысление Feberra как internal tool. Никакого биллинга, никакой мультитенантности, никакой видео-генерации на первом этапе.

Фокус на двух вещах:

1. Надёжный Trend Watching — автоматический сбор сигналов по конкурентам, маркетинговый фильтр, плитки с инсайтами
2. Chat-driven workspace — AI ведёт через анализ референса и адаптацию сценария, на выходе готовый текст для съёмки

Для chat-workspace рассматривали assistant-ui — MIT-лицензия, 10k+ звёзд, активная разработка. Как backend для агентов — Mastra или AI SDK напрямую. Persistence — Supabase с кастомными таблицами для threads, messages и artifacts.

Мulti-agent архитектура остаётся: оркестратор + специализированные агенты. Но без видео-монтажёра на первом этапе — только аналитик сигналов и сценарист. Это позволяет запустить быстро и получить реальную обратную связь от использования.

Выводы и уроки

Главный урок Feberra — не пытайся построить всё сразу. Полный цикл от скрапинга до публикации видео звучит как сильное УТП, но на практике это несколько разных продуктов, каждый из которых требует своего фокуса. Лучше сделать один шаг идеально, чем весь путь посредственно.

Второй урок — данные важнее интерфейса. 969 МБ в trendSignalEvents — это не технический долг, это продуктовый актив. История метрик позволяла строить сигналы, которые действительно работали. Без этой истории система была бы просто парсером. Инвестиции в правильную модель данных окупаются.

Третий урок — multi-agent архитектура правильная, но требует дисциплины. Один большой LLM-вызов проще в реализации, но хуже по качеству и контролируемости. Специализированные агенты с узким контекстом дают лучший результат — но нужно тщательно проектировать интерфейсы между ними и следить за консистентностью выходных данных.

Четвёртый урон — internal tool как первый шаг. Feberra пыталась сразу стать SaaS с биллингом и онбордингом. Content-farm начинается как инструмент для себя. Это позволяет сосредоточиться на core-функциональности, быстро итерировать и не тратить ресурсы на инфраструктуру, которая нужна только при масштабировании. Когда инструмент докажет ценность в реальном использовании — тогда и думать о продуктизации.

Feberra была правильной идеей с правильной архитектурой. Content-farm — это та же идея, но с правильным скоупом.