Автоматизация PPC-отдела: как мы убрали рутину и повторяющиеся ошибки

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

Как руководитель отдела я смотрю на это так. Время специалиста должно уходить на то, что действительно влияет на результат клиента: оптимизацию кампаний, проработку стратегий, анализ. Всё, что повторяется из месяца в месяц и делается по одной схеме, — кандидат на автоматизацию. И дело не только во времени. Освободившиеся часы позволяют специалисту вести больше проектов, а это для отдела уже вопрос эффективности. Есть и третья причина, о которой говорят реже: в повторяющихся задачах повторяются и ошибки. Человек устаёт, глаз замыливается, и опечатка спокойно проходит все этапы проверки.

За несколько месяцев мы собрали для отдела набор внутренних инструментов. Рассказываю, какие задачи они закрывают, как мы ими пользуемся и как к ним пришли. Без раскрытия того, как они устроены внутри: здесь важнее логика, чем код.

Откуда брались задачи

Сразу скажу важное: ни один инструмент не появился потому, что нам захотелось «внедрить ИИ». Каждый вырос из конкретной боли, о которой говорили клиенты, коллеги из других отделов или сами специалисты. Если проблема всплывала на планёрке не первый раз, я ставила задачу.

Вот как, например, выглядела постановка задачи на проверку орфографии:

«Денис, тут обсуждали, что частая проблема, с которой сталкиваемся, — это опечатки и ошибки сначала в файле согласования, потом в РК. То есть файл согласования должен проверяться ещё до отправки клиенту на согласование».

Если вчитаться, в этой задаче нет ни слова о технологии. Только что болит, где это происходит и каким должен быть результат. И одно ограничение, которое я считаю принципиальным: «либо чтобы ИИ спрашивала, нужно исправлять или нет (чтобы она там не напортачила)». В итоге мы осознанно отказались от автоматического исправления. Инструмент находит ошибки и предлагает варианты, а решение остаётся за человеком.

Задача на выводы для отчётов родилась так же, из обсуждения на планёрке. Здесь я сразу заложила логику, которую потом увидела в готовом инструменте: три сценария (рост, стагнация, падение), типовые формулировки под каждый и примеры причин.

Мне кажется, это главный урок всего проекта. Хорошая задача на автоматизацию описывает не «что сделать», а «что должно получиться и почему». Как именно это реализовать, решает исполнитель.

Отчёты: с полутора–двух часов до получаса

Ежемесячный отчёт клиенту — классическая рутина специалиста. Выгрузить цифры из Директа и Метрики, свести их в таблицы, построить графики, написать выводы, сверстать документ. Время зависит от того, насколько отчёт кастомный, но для ориентира приведу один наш проект: вручную отчёт собирался за 1,5–2 часа, сейчас за 30 минут. И это с учётом проверки всех данных, а не просто нажатия кнопки.

За этим стоят два связанных инструмента.

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

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

Отдельно скажу про выводы, потому что их тут два вида. Первый — ИИ-разбор по каждой кампании: оценка эффективности с динамикой и 2–3 рекомендации. Рекомендации учитывают тип кампании и стратегию, например, на автостратегиях он не предлагает крутить ставки вручную. Это подсказка для специалиста, а не готовое решение. Второй — конструктор текста для клиента, тот самый из задачи выше. Специалист выбирает сценарий, отмечает нужные пункты, и система собирает готовый текст с цифрами и сравнением с прошлым месяцем. Это не ИИ, а наши собственные готовые формулировки, поэтому текст для клиента всегда звучит так, как мы привыкли писать.

Конструктор отчётов. Из карточки клиента одним кликом открывается готовый отчёт по нашему образцу. Цифры подтягиваются сами, а тексты правятся прямо на странице. Разделы можно переставлять, скрывать и добавлять свои, а если у клиента несколько кабинетов, они собираются в один отчёт со сводкой. На выходе PDF для отправки или DOCX, если нужно что-то доправить в Word.

Отчёт за новый месяц стартует с текстов прошлого, но цифровые блоки пересчитываются заново. Так старые цифры не уедут к клиенту. А в инструкции к конструктору мы прописали правило, которое до этого жило только в головах опытных специалистов: НДС, учёт медийных кампаний и источник конверсий нельзя менять от месяца к месяцу, иначе динамика в отчёте окажется ложной. По сути, автоматизация стала ещё и способом зафиксировать стандарты отдела.

Проверка орфографии: ошибка, которую не заметили трое

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

Инструмент проверяет текст, файл (.docx, .pdf, .xlsx и другие), страницу сайта или Google-таблицу. Ошибки подсвечиваются, при наведении показываются варианты замены. В таблице согласования ячейки с ошибками заливаются красным, а в примечании пишутся варианты. Для тех, кто работает в Google Sheets, есть кнопка прямо в таблице.

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

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

Проверка посадочных: когда «200 OK» ничего не значит

В файле согласования может быть пять посадочных, а может быть сто, всё зависит от структуры кампаний. Проверять их вручную — это рутина, время и тот же риск что-то пропустить. На большом проекте ручная проверка могла занимать 2–3 часа, сейчас она идёт полностью автоматически. А цена пропущенной битой ссылки выше, чем у опечатки: клики списываются, а заявок с них нет.

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

Проверять можно три вещи. Файл согласования: инструмент сам найдёт все ссылки в таблице и пометит битые ячейки. Сайт клиента целиком. И товарный фид: здесь он находит ещё битые картинки, картинки меньше 450 px, которые Яндекс отклоняет, и товары, которые есть в фиде, но уже пропали с сайта.

Разовая проверка полезна перед запуском, но сайты ломаются и после него. Поэтому проекты можно поставить на проверку по расписанию, дважды в день. А дальше самое ценное, на мой взгляд: инструмент не спамит. Уведомление в Telegram приходит только тогда, когда что-то сломалось или починилось, и о сбое — только после второй неудачной проверки подряд. Если всё работает, тишина. Каждому, кто настраивал автоматические уведомления, знакома ситуация, когда их становится столько, что их перестают читать. Здесь каждое сообщение означает действие.

РНП: все проекты отдела в одной таблице

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

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

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

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

На практике РНП изменил сразу несколько вещей. Планёрки отдела стали продуктивнее: открываем таблицу и проходимся по показателям проектов, а не вспоминаем цифры по памяти. Аккаунт-менеджеры сами быстро находят свои проекты и могут ответить клиенту на вопрос «как дела?», не дёргая специалиста. А мне как руководителю не нужно ждать конца месяца, чтобы узнать, что какой-то проект просел.

Как это делалось

Теперь о том, кто всё это сделал. Все инструменты создал не разработчик, а специалист PPC-отдела Денис с помощью Claude. Опыт программирования у него был минимальный: общее понимание того, как работают базы данных и клиент-серверная архитектура. И желание развиваться в этом направлении. Я попросила его рассказать, как всё начиналось:

«Вообще всё началось с желания оптимизировать сводную таблицу и получать данные по API автоматически. Тут моих знаний не хватало, и Claude очень помог. Ну а дальше понеслось: другие приложения. На сам дашборд ушло дней три–пять, это без доработок. Разбираться с инструментом особо не нужно: ты с ним общаешься как с человеком и выдаёшь ему поток мыслей. Что-то приходится делать руками, потому что сам он этого сделать не может, но он всегда подскажет как. Плюс у него появилось сохранение истории: он запоминает, где были ошибки и недочёты. Сложного ничего нет, главное — желание и фантазия».

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

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

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

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

При этом важно честно сказать и об ограничениях. Инструменты не делаются один раз и навсегда: их нужно поддерживать и дорабатывать. Путь от постановки задачи до готового инструмента занимал у нас от трёх недель до трёх месяцев, вместе со всеми итерациями. Данные из Директа иногда не подтягиваются, поэтому в РНП есть ручной ввод. Защита некоторых сайтов принимает проверку посадочных за бота, и такие страницы всё равно нужно открыть самому. И самое главное: автоматизация не отменяет ответственность специалиста. Те самые 30 минут на отчёт — это время с проверкой данных, и пропускать её мы не собираемся.

Что в итоге

Если собрать всё вместе, автоматизация дала отделу три вещи. Время: отчёт, который раньше занимал полтора–два часа, теперь готов за полчаса, проверка посадочных на большом проекте, которая занимала 2–3 часа, теперь идёт сама, а файл согласования больше не нужно вычитывать строка за строкой. Надёжность: там, где ошибки повторялись, теперь стоит системная проверка, а не надежда на внимательность. И прозрачность: картина по всем проектам отдела видна в одной таблице, и отстающий проект не теряется среди остальных.

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

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