Проблема: аналитики тонут в цифрах, а решения запаздывают на недели
Представьте типичный понедельник в CLICKFORCE. Команда аналитиков получает свежие отчеты по сотням рекламных кампаний. Excel-таблицы на 50+ вкладках, десятки дашбордов в Tableau, километры SQL-запросов. Все это нужно проанализировать, найти аномалии, понять причины падения конверсии, предложить корректировки ставок.
На это уходило 3-5 дней. Иногда неделя. Пока аналитик докопается до сути, пока сформулирует рекомендации, пока они дойдут до менеджеров кампаний - рынок успевает измениться. Конкуренты уже скорректировали свои ставки. Возможности упущены.
Классическая проблема data-driven компаний: данных много, инсайтов мало, время реакции - черепашье. Особенно в рекламе, где каждый час простоя стоит денег.
Решение: не просто отчет, а AI-аналитик с мнением
Мы не хотели еще один дашборд. Дашбордов и так хватает. Мы хотели коллегу-аналитика. Того, кто смотрит на те же цифры, но сразу видит закономерности. Кто не просто показывает график CTR, а говорит: "CTR упал на 15% вчера после 18:00, вероятная причина - изменение аукциона в Facebook, рекомендую повысить ставку на 7% для аудитории 25-34"
Именно такую систему мы назвали Lumos. Не RAG поверх документов. Не чат-бот с API. А полноценный аналитический движок, который понимает контекст рекламных кампаний, знает исторические паттерны, умеет сравнивать с бенчмарками и генерировать конкретные, исполнимые рекомендации.
Архитектура: почему именно Amazon Bedrock, а не самописная модель
Сначала думали тренировать свою модель. Потом посчитали стоимость GPU-часов, данных для обучения, инженерных часов на дообучение. И поняли - это на год минимум. А решение нужно вчера.
Amazon Bedrock на февраль 2026 года предлагает Claude 3.7 Sonnet - модель, которая уже понимает таблицы, временные ряды, умеет рассуждать. И главное - поддерживает инструменты (tools). Мы можем дать ей доступ к нашим данным через API, а она будет этими инструментами пользоваться как аналитик: запрашивать исторические данные, сравнивать показатели, вычислять тренды.
Вот как выглядит стек:
| Компонент | Зачем нужен | Альтернативы, которые мы отвергли |
|---|---|---|
| Amazon Bedrock (Claude 3.7 Sonnet) | Ядро аналитики. Интерпретирует данные, генерирует инсайты | GPT-4.5 (дороже, хуже с таблицами), локальные модели (недостаточно контекста) |
| Amazon SageMaker | Предобработка данных, feature engineering, аномалии | Spark на EMR (сложнее в поддержке для аналитиков) |
| Amazon OpenSearch | Векторное хранение исторических инсайтов и рекомендаций | Pinecone (дороже, vendor lock-in), pgvector (меньше готовых функций) |
| AWS Glue | ETL: сбор данных из 15+ источников (Facebook, Google, TikTok и др.) | Airflow (нужен отдельный инженер), Fivetran (дорого для нашего объема) |
| Bedrock Guardrails | Защита от галлюцинаций и нерелевантных ответов | Самописные промпты (ненадежно), нейросетевые классификаторы (сложно) |
Важный момент про Guardrails - без них система бы галлюцинировала в 30% случаев. Особенно когда данных мало или они зашумлены. Мы настроили фильтры на основе практического руководства по Amazon Bedrock Guardrails, и это сократило ошибки до 2-3%.
Главная битва: как заставить LLM не обобщать, а анализировать конкретику
Первые версии Lumos страдали классической болезнью LLM: они слишком обобщали. Даешь данные по конкретной кампании - получаешь ответ в стиле "рекомендуем оптимизировать ставки и улучшить креативы". Спасибо, Кэп.
Проблема в том, что LLM тренированы на общих текстах. Они знают, что такое "рекламная кампания", но не знают специфики вашего бизнеса, ваших KPI, ваших исторических данных.
Мы решили это тремя слоями контекста:
1Слой бизнес-контекста
Каждый клиент, каждая вертикаль (e-commerce, SaaS, gaming) имеют свои метрики успеха. Для e-commerce - ROAS и стоимость заказа. Для SaaS - стоимость лида и LTV. Для gaming - CPI и retention.
Мы создали профили вертикалей в OpenSearch. Когда Lumos анализирует кампанию, она сначала определяет вертикаль и загружает соответствующий контекст: какие метрики важны, какие бенчмарки считать нормальными, какие типичные проблемы возникают.
2Слой исторических прецедентов
За год работы у нас накопились тысячи ситуаций: "CTR падает в пятницу вечером", "стоимость клика растет после запуска нового конкурента", "конверсия падает при изменении креатива с видео на картинку".
Мы векторизовали эти ситуации и храним в OpenSearch. Теперь, когда Lumos видит падение CTR, она ищет похожие исторические случаи и смотрит, что сработало тогда: повышение ставки, смена таргетинга, изменение времени показа.
Это похоже на подход из статьи про корпоративный ИИ-агент Яндекса, но адаптировано под рекламную аналитику.
3Слой инструментов-вычислителей
LLM плохо считает. Особенно проценты, тренды, статистические отклонения. Мы дали Lumos набор инструментов через Bedrock Tools:
- Калькулятор трендов (вычисляет slope за период)
- Детектор аномалий (использует алгоритм из SageMaker)
- Сравнитель с бенчмарками (берет данные из Data Warehouse)
- Симулятор изменений ("что будет, если повысить ставку на 10%?")
Теперь вместо "CTR, кажется, падает" мы получаем "CTR снизился на 0.4 п.п. за последние 3 дня (p-value < 0.05), что на 22% больше, чем типичная волатильность для этой кампании".
Пошаговый план: как мы собрали систему за 4 недели
Не час, конечно. На разработку ушло 4 недели. Но сам анализ теперь занимает час вместо недели. Вот как мы двигались:
1Неделя 1: данные и инструменты
Подключили все источники данных через Glue. Настроили пайплайны обновления. Создали витрину данных в Redshift с ключевыми метриками по кампаниям.
Реализовали первые инструменты для Bedrock: простые запросы к витрине, вычисление базовых статистик.
2Неделя 2: промпт-инжиниринг и тестирование
Создали промпт-шаблон, который превращает LLM в аналитика. Ключевые элементы:
- Роль: "Ты senior data analyst с 7-летним опытом в performance marketing"
- Цель: "Проанализируй данные кампании, найди 3 главные проблемы и предложи конкретные действия"
- Формат ответа: структурированный JSON с полями: проблема, данные_подтверждающие, уверенность_%, рекомендация, ожидаемый_эффект
- Ограничения: "Не предлагай общих рекомендаций. Если данных недостаточно - скажи, каких именно данных не хватает"
Протестировали на 50 исторических кампаниях, сравнивали с решениями живых аналитиков.
3Неделя 3: интеграция и автоматизация
Настроили триггеры: когда кампания показывает аномалию (детектирует SageMaker), автоматически запускается анализ через Bedrock.
Результаты пишутся в OpenSearch и отправляются в Slack канал менеджера кампании + в интерфейс нашего продукта.
Добавили обратную связь: менеджеры могут оценить рекомендацию (полезно/не полезно), эти оценки идут на дообучение промптов.
4Неделя 4: тонкая настройка и масштабирование
Добавили вертикальные специфики. Настроили лимиты на использование Bedrock (чтобы не разориться).
Создали дашборд для мониторинга качества рекомендаций: сколько было принято, какой ожидаемый vs фактический эффект.
Что получилось: цифры и эффекты
Через месяц после запуска:
- Время анализа кампании: с 3-5 дней до 45-60 минут
- Консистентность рекомендаций: 85% совпадений с решениями senior аналитиков
- Принятие рекомендаций менеджерами: 72% (выше, чем у рекомендаций junior аналитиков)
- Средний эффект от принятых рекомендаций: +9% к эффективности кампаний
- Стоимость анализа: $0.8-1.2 за кампанию (против $150-300 за работу аналитика)
Важный нюанс: Lumos не заменила аналитиков. Она освободила их от рутины. Теперь senior аналитики занимаются стратегическими вопросами, а не копанием в ежедневных отчетах. Junior аналитики учатся на примерах Lumos - смотрят, как система формулирует выводы, какие данные запрашивает, как строит аргументацию.
Ошибки, которые мы совершили (чтобы вы их не повторили)
1. Слишком сложные промпты. Первая версия промпта занимала 2000 токенов. LLM теряла суть. Упростили до 500 токенов, добавили контекст через инструменты.
2. Отсутствие человеческого контроля на старте. Первые недели рекомендации проверял аналитик перед отправкой менеджеру. Иначе могли бы отправить ерунду и потерять доверие.
3. Игнорирование latency. Первый прототип делал 10 последовательных вызовов к Bedrock. Анализ занимал 15 минут. Переписали на параллельные вызовы и кэширование - сократили до 2 минут.
4. Попытка охватить все сразу. Хотели анализировать и креативы, и таргетинг, и ставки, и аукционы. Получилась каша. Сфокусировались сначала на ставках и таргетинге - областях, где больше всего данных и понятнее метрики.
Что дальше? Куда развивается AI-аналитика в рекламе
Lumos - только начало. Сейчас мы работаем над тремя направлениями:
1. Predictive рекомендации. Не "что пошло не так", а "что может пойти не так завтра". Используем временные ряды и аналогии с историческими кампаниями. Похоже на то, что делает Catalog AI от Amazon для e-commerce, но для рекламных метрик.
2. Мультимодальность. Добавляем анализ креативов: изображений, видео, текстов объявлений. Claude 3.7 Sonnet уже умеет работать с изображениями. Можем определять, какие визуальные элементы коррелируют с высоким CTR.
3. Автоисполнение. Простые рекомендации (скорректировать ставку на 5%) система уже может выполнять сама через API рекламных платформ. Сложные (изменить стратегию таргетинга) - предлагает менеджеру одним кликом.
Самое интересное - как меняется роль маркетолога. Из оператора, который крутит ручки ставок, он превращается в стратега, который ставит задачи AI-аналитику: "Найди сегменты с максимальным LTV", "Оптимизируй кампанию под ROAS 300%". Система ищет, анализирует, предлагает. Человек принимает решение.
Это и есть будущее data-driven маркетинга: не больше данных, а умнее их использование. Не более сложные отчеты, а более простые и точные рекомендации. Не недели на анализ, а часы на действие.
И да, если думаете, что это слишком сложно для вашей компании - начните с малого. Возьмите одну метрику. Одну кампанию. Настройте простой детектор аномалий в SageMaker. Подключите Bedrock с базовым промптом. Посмотрите, что получится.
Потому что через год те, кто сегодня экспериментирует с AI-аналитикой, будут определять правила игры. А те, кто ждет "когда технология созреет", будут догонять. Как всегда.