Как ИИ‑агент помог автоматизировать рекламу на площадке без API, быстро проверить гипотезу и вовремя свернуть проект

Привет! Я Катерина Лапаева, руководитель GIGASCHOOL. В этой статье хочу разобрать кейс Максима Тодорова. Максим собрал систему в качестве итогового проекта на практическом курсе по автоматизации бизнес‑процессов с помощью ИИ‑агентов, который мы разработали вместе с экспертом Андреем Кузьминых, @Dataist ^[1]. В течение курса участники выбирали реальный процесс, проектировали его целевую схему, определяли роль человека и агента, а затем собирали рабочий прототип и считали его экономику.

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

Давайте разберём архитектуру системы на n8n, роль языковой модели и результат, который оказался важнее расчётной экономии.

Что автоматизировали

Максим — учредитель компании, которая тестировала продвижение услуг через b17.ru. Это специализированная площадка для психологов и людей, которые ищут психологическую помощь.

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

Главное техническое ограничение заключалось в самой площадке.

У неё нет API для рекламной статистики. Площадка не рассчитана на автоматизированную выгрузку данных и активно препятствует работе ботов. Даже базовые операции с объявлениями приходилось выполнять вручную.

Максим так описывал исходные условия на защите проекта:

«Сам сайт, к сожалению, не имеет API, не предназначен для автоматизации, хорошо борется с роботами. Ну и отсюда идёт вся боль ^[2], связанная с автоматизацией работы на нём».

Но отказаться от канала было сложно. По результатам тестов лиды с сайта обходились дешевле и выигрывали по качеству, в сравнении с заявками из альтернативных рекламных источников.

Выгодный потенциал канала, но плохо масштабируемый из‑за ручной работы.

Как выглядел процесс до автоматизации

Исходный процесс состоял из пяти этапов:

1. Сбор статистики по объявлениям на b17.ru.

2. Атрибуция лидов (сопоставление каждой заявки с объявлением, которое её привело).

3. Расчёт показателей.

4. Анализ кампании.

5. Принятие решений по объявлениям и рекламной стратегии.

Первые четыре этапа выполнялись вручную.

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

На сбор, сведение и анализ данных маркетолог тратил около 11 часов в неделю. При этом полноценный пересмотр рекламной стратегии происходил примерно раз в месяц, когда часть данных уже успевала устареть.

Статистику можно было бы собирать и чаще, но полноценное сведение данных, анализ и пересмотр стратегии делались реже. Увеличение количества объявлений не решало задачу, так как вместе с рекламой рос объём ручной работы, а стоимость маркетолога увеличивала стоимость каждого лида.

Так как процесс линейный:

собрать > сопоставить > посчитать > проанализировать > применить,

то если объявлений становилось больше, каждый следующий этап становился длиннее.

Какой результат хотелось получить

Задача была не в полном исключении маркетолога.

Нужно было исключить операции, в которых человек выступал звеном между данными и интерфейсами:

• ручная выгрузка статистики;

• сведение данных в таблицу;

• сопоставление лидов с объявлениями;

• расчёт CTR, CPL и других показателей;

• первичный поиск аномалий и закономерностей;

• подготовка отчёта;

• формирование черновика рекомендаций.

За человеком должны остаться действия, в которых требуется ответственность и знание контекста:

• проверка корректности отчёта;

• изменение логики анализа;

• выбор маркетинговой стратегии;

• утверждение новых объявлений;

• отключение или запуск кампаний;

• решения по бюджету.

«Я не заменяю маркетолога, я переношу его выше по лестнице».

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

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

Из чего состоит система

Было бы неправильно называть агентом только языковую модель.

Агент в данном случае — это не только LLM, а целый пайплайн на базе n8n и браузерное расширение, которое помогает работать с b17 без API.

Составные части системы:

• браузерное расширения для получения данных с b17.ru;

• n8n для управления процессом;

• Google Таблицы для промежуточного хранения и обработки данных;

• языковая модель для анализа и подготовки рекомендаций;

• Telegram‑бот для запуска процесса и отправки результатов;

• DataLens для контроля технических и экономических показателей.

Языковая модель не может сама по себе открыть площадку, собрать данные из нескольких источников, проверить схему ответа, записать результат в хранилище и построить дашборд.

Как устроен сценарий

Из‑за отсутствия API сбор данных нельзя было организовать через обычный HTTP‑запрос.

Пользователь открывал b17.ru и запускал браузерное расширение. Оно извлекало доступную на странице статистику и отправляло её в n8n. После этого процесс продолжался автоматически.

Человек всё ещё должен зайти на сайт и инициировать сбор, но вместо нескольких часов копирования данных остаётся пара действий в интерфейсе.

Как агент обрабатывал данные

Сначала система собирала по каждому объявлению более 20 параметров. Это текст, просмотры, переходы, расходы и идентификаторы. Данные очищались, приводились к единому формату, проверялись на пропуски, дубли и ошибки ^[3] типов.

Эту часть Максим намеренно не отдавал языковой модели. Сбор данных, расчёты и проверки выполнялись обычным кодом, потому что при одинаковом входе он даёт предсказуемый результат, а ошибку можно воспроизвести.

Затем объявления связывались с заявками из форм. Атрибуция позволяла смотреть не только на клики, но и на стоимость лида и конверсию конкретного объявления. Это важно, так как высокий CTR ещё не означает, что реклама приводит подходящих клиентов.

После объединения данных код рассчитывал CTR, CPL, расходы, средние значения, ранги и отклонения. Языковая модель получала подготовленные метрики и занималась их интерпретацией, а не расчётами.

Ещё одно преимущество такого подхода, которое отметил Андрей Кузьминых во время защиты: визуальный сценарий помогает увидеть компанию как поток данных. Что откуда приходит, как проходит через системы и где возникают зависимости. После того как эта логика ^[4] становится понятна, тот же процесс уже проще перенести из n8n в отдельный сервис.

По сути, n8n в этом случае был не только средой автоматизации, но и способом разобраться в архитектуре процесса до перехода к коду.

Что делала языковая модель

Модель анализировала кампанию, искала закономерности и аномалии, предполагала причины слабых результатов и формировала рекомендации.

Например, она могла отличить объявление, по которому почти не кликают, от объявления с высоким CTR и низкой конверсией в заявку. Также Максим предусмотрел обратные аномалии, где небольшое количество кликов не всегда говорит о плохом результате, если объявление при этом показывает приемлемую стоимость или конверсию в заявку.

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

То есть LLM была только одной частью системы. Сбор, атрибуция, расчёты и валидация выполнялись детерминированно, а модель использовалась там, где требовались интерпретация и формирование гипотез.

Как выглядел результат

После запуска система присылала в Telegram краткую сводку и HTML‑отчёт с метриками и рекомендациями.

Отдельно Максим сделал таблицу с фильтрами, потому что на самой площадке объявления нельзя было нормально отсортировать.

DataLens использовался для наблюдения за работой системы. В нём отслеживались время выполнения, стоимость запуска, успешность и корректность ответа модели.

Среднее время одного прогона составляло около 124 секунд, а расчётная стоимость обработки одного объявления — 52 копейки.

Что происходило при ошибках

В n8n был отдельный контур обработки ошибок. Если падал узел или модель возвращала ответ неправильной структуры, сбой записывался и попадал в статистику.

На дашборде корректность схемы ответа составляла 88%. Остальные 12% — на специально проведённый тест с инъекцией. В штатных прогонах система отрабатывала стабильно.

Даже при сбое узла или невалидном ответе информация о запуске записывалась в статистику, чтобы ошибку можно было найти и решить.

Как был устроен workflow

Повторно используемые функции Максим вынес в отдельные ветки, которые запускались из основного сценария. Визуально весь процесс остался на одном рабочем поле n8n.

«Я разнёс все функции, которые можно использовать несколько раз, в отдельные ветки. Фактически структура субагентов реализована».

Для учебного проекта это помогало видеть весь поток данных целиком. В рабочей версии сбор, расчёты, анализ, отчётность и обработку ошибок уже можно было бы разделить на независимые сценарии.

Сколько заняла разработка

На проект ушло около 80 часов. Первые узлы Максим собирал вручную, затем использовал Perplexity для кода внутри нод, а на финальном этапе подключил Claude Code.

К этому моменту Claude Code уже мог просматривать исполнения, запускать workflow, вносить изменения и публиковать их. Но так как Максим сначала самостоятельно разобрал архитектуру и движение данных, он мог контролировать этот процесс.

Расчётная экономика

Агент больше месяца работал в реальном процессе, но снижение CPL и годовой ROI не удалось проверить, так как кампанию остановили раньше.

До автоматизации один цикл работы маркетолога стоил примерно 12 100 рублей. Благодаря агенту получилось сократить его время с 11 часов примерно до одного, а стоимость до 1 130 рублей. И бонус: система позволила проводить анализ не раз в месяц, а еженедельно.

По расчётам Максима, система могла экономить около 47 600 рублей в месяц.
Ещё 15 000 рублей он заложил как возможный эффект от снижения стоимости лида. Расчётный срок окупаемости составил три месяца, в пессимистичном сценарии — полгода.

Главный результат оказался не в экономии

Агент помог получить необходимое количество лидов и подтвердил, что выбранный канал привлечения работает. После этого выяснилось, что продукт оказался недостаточно адаптирован к аудитории, которую приводила реклама.

«У меня проблема‑то возникла в дальнейшем в обработке лидов, а не в их получении».

В результате он решил свернуть проект, для которого создавал автоматизацию. Автоматизация быстро сняла ограничение в верхней части воронки и показала, что проблема находится в продукте и дальнейшей работе с заявками.

Делаем выводы

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

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

Но главный вывод в том, что иногда задача автоматизации — как можно быстрее показать, что масштабировать пока нечего.

«Больше я в поле без автоматизации не хожу».