4 июля 2026 г.·Команда WEB24#LLM#MCP#аналитика#Яндекс Директ

Может ли LLM заменить аналитика по рекламе? Кейс о LLM, MCP и аналитике рекламы в Яндекс Директе

Блогер обещал, что LLM с доступом к API Яндекс Директа заменит аналитика. Мы подключили нейросеть к рекламным данным через MCP-сервер и ClickHouse и проверили это на практике.

Пару недель назад в ленте попалось видео от очередного эксперта «по ИИ». Сюжет классический: подключаем нейросеть напрямую к API Яндекс Директа и Яндекс Метрики через какой-то сервис-посредник, просим её «проанализировать рекламу» — и вуаля, можно увольнять аналитика, ведь теперь у вас есть ChatGPT.

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

Но мы сделали немного иначе

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

Поэтому мы пошли другим путём:

Данные мы забирали не из Яндекса напрямую, а из своей базы. У нас уже был настроен ClickHouse с представлениями (views), где расходы по рекламе, лиды из CRM и статусы сделок склеены в готовые аккуратные таблицы — «витрины». То есть вся грязная работа по объединению данных из разных источников была сделана заранее, руками аналитика. Модели остаётся дёрнуть примерно такой запрос — уже с посчитанными метриками, без единого JOIN:
```
SELECT
    date, direct_product,
    sum(cost)  AS cost,
    sum(leads) AS leads,
    round(sum(cost) / nullif(sum(leads), 0), 2) AS cpl
FROM analytics.ad_performance
WHERE date BETWEEN %(date_from)s AND %(date_to)s
GROUP BY date, direct_product
ORDER BY date
```
Поверх этого мы написали MCP-сервер — по сути небольшой слой-переводчик, который умеет отвечать на вопросы вроде «покажи расходы по продуктам за июнь» или «сравни Поиск и РСЯ по цене лида», выполняя нужные запросы к базе и возвращая LLM аккуратные цифры, а не сырой JSON из рекламного кабинета. На уровне кода один такой инструмент — это просто функция с описанием на человеческом языке:
```
@mcp.tool()
def get_ad_performance(date_from: str, date_to: str, group_by: str = "date") -> dict:
    """Расходы, лиды и CPL по рекламным кампаниям за период."""
    rows = run_query(date_from, date_to, group_by)
    return {"period": [date_from, date_to], "data": rows}
```
LLM сама решает, когда и с какими аргументами вызвать эту функцию, а всю логику подключения к базе, фильтры и защиту от «выгрузи вообще всё» мы прячем внутри.
Подключили этот сервер к обычному чат-ассистенту (в нашем случае — Claude), дали ему доступ только на чтение и договорились о простых правилах: какие метрики считать, как называются продукты и сети, какой период данных доступен по умолчанию.

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

Что получилось

Если честно — получилось хорошо, и даже немного рады за блогера, потому что часть его тезиса подтвердилась. Модель:

за секунды строила срезы, на которые у аналитика раньше уходило минут 20–30 (собрать данные, свести в таблицу, посчитать проценты);
сама подмечала неочевидные вещи — например, что в определённые часы CPL резко проседает, или что одна из площадок РСЯ явно «сливает» бюджет;
умела объяснить любую цифру человеческим языком, без «а что такое CTR» и танцев с пивотными таблицами;
в перспективе легко настраивается на регулярную отправку отчётов и рекомендаций — грубо говоря, «пришли мне такую сводку каждое утро в Telegram».

То есть как инструмент для первого прохода по данным и для быстрых ответов на вопросы «а как у нас дела» — это работает и работает хорошо.

Почему аналитика мы всё-таки не уволили

А теперь резюме, ради которого всё затевалось. Эксперимент удался, но нанимать LLM вместо человека мы бы точно не стали, и вот почему.

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

Мы отдаём модели уже готовые, обогащённые данные, а не сырьё. Все те представления в ClickHouse, из которых модель берёт цифры, — это не «просто выгрузка из Яндекса». Это результат работы аналитика: связать расходы из Директа с лидами из CRM, отфильтровать техническими правилами дубли и спам-заявки, разметить статусы сделок, учесть, что один и тот же клиент писал с двух разных источников. Без этой подготовительной работы LLM просто не с чем было бы работать — она отвечает на вопросы по данным, но не умеет сама превратить хаос в витрину.

Специфику рекламных кампаний модель не знает и знать не может. Что кампания «Продукт X — гео тест, отключить после 20 числа» на самом деле тестовая и её нельзя сравнивать с остальными. Что источник трафика с высоким CPL специально держат ради охвата, а не ради лидов. Что в прошлом месяце был сбой в передаче данных из одного из аккаунтов и часть цифр занижена. Это знание живёт в голове у человека, который ведёт эти кампании, а не в базе данных — и без него LLM с одинаковой уверенностью сделает вывод и по хорошим данным, и по кривым.

Итог

Увольнять аналитика точно не надо. Но и игнорировать LLM в аналитике — тоже ошибка. Правильная роль модели — не «заменить человека», а забрать у него рутину: быстро строить дашборды и срезы по запросу, отвечать на вопросы обычным языком вместо интерфейса BI-системы, регулярно присылать отчёты и подсвечивать аномалии, которые стоит проверить. Финальное решение и здравый смысл — всё равно остаются за человеком. Кстати, ровно на этой идее — агент поверх подключённых данных бизнеса — Anthropic построила целый продукт: разбор в статье «Claude for Small Business: автоматизация малого бизнеса в России».

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

Коротко

Может ли LLM заменить аналитика по рекламе?

Нет. Модель быстро строит срезы и объясняет цифры человеческим языком, но не проверяет качество данных и не знает контекст конкретных кампаний — финальные решения и здравый смысл остаются за аналитиком.

Что такое MCP-сервер и зачем он нужен для аналитики рекламы?

MCP (Model Context Protocol) — способ дать LLM доступ к внешним данным через функции-инструменты. MCP-сервер отвечает не сырым API Яндекс Директа, а уже готовыми посчитанными цифрами — расходами, лидами, CPL.

Какие данные нужны LLM для анализа рекламных кампаний?

Не сырые выгрузки из API Яндекс Директа и Яндекс Метрики, а очищенные витрины: расходы по рекламе, лиды из CRM и статусы сделок в одной таблице, без дублей, с размеченными продуктами и сетями.

Сколько времени экономит LLM при анализе рекламы?

В нашем кейсе срезы, на которые у аналитика уходило 20–30 минут, модель строила за секунды. Но подготовка данных в витринах ClickHouse — отдельная работа аналитика, без которой LLM не с чем работать.

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