KPI в маркетинге дописывают агентами: от целей направлений к причинам отклонений

В конце месяца на экране стоит зелёное «план выполнен». Это отвечает на вопрос о сумме, но не о работе направлений. Перевыполнение одного может закрыть недобор другого. Если у второго своя задача и своя аудитория, общий итог не объясняет, что случилось.

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

У контента план 30 лидов, факт 15: выполнение 50 %. По отделу план 100, факт 120: выполнение 120 %. Общая цель достигнута, а контент недобрал 15 лидов. Рядом с итогом руководителю нужна отдельная строка этого направления, а не ещё один зелёный кружок.

С чего начать разработку? С договора о смысле числа. KPI, ключевой показатель эффективности, связывает измеряемый результат с согласованной целью и сроком. Списки показателей есть у Битрикс24, eLama и Яндекс Рекламы. Для кода этого недостаточно: слово «лид» ещё не говорит, какую запись принять, а какую исключить.

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

В учебном примере выполнение равно факту, делённому на план, и умноженному на 100 %. Эта формула подходит для цели «получить не меньше заданного числа лидов». Для показателя «не превысить срок» оценка устроена иначе. При нулевом плане процент не определён; код должен показать это состояние, а не делить на ноль.

Лиды и опубликованные материалы нельзя складывать в «общий результат». Проценты выполнения разных целей тоже не превращаются сами собой в осмысленную среднюю оценку отдела. Если руководитель хочет сводный индекс, отдельно согласуют веса, ограничения и смысл его изменения.

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

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

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

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

На vibecoding.ru мы уже проходили такие ошибки, хотя считали другие вещи. Потерянное поле меняло запись, неполная страница источника превращалась в ноль, пропущенный запуск оставлял старый замер. Это доказательства устройства нашей машины и её проверок, без обещания эффекта для отдела маркетинга.

Статус загрузки нужен рядом с KPI. Сообщение «обновлено сегодня» ничего не гарантирует, если часть источников пропущена. В карточке показателя должно быть видно, какие входы проверены и какой период покрыт. Старое значение можно сохранить для справки с его датой, но не выдавать за свежую оценку.

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

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

Теперь у контента проверенные 15 лидов вместо 30. Причина уже известна? Пока известен только недобор. Агент может разложить его по продуктам, неделям или ответственным, если такие поля есть в данных. Этот разрез покажет, где возникла разница, но сам по себе не докажет, почему.

Допустим, журнал публикаций показывает пропущенный выпуск. Это подтверждённый факт процесса. Фраза «из-за него потеряли все 15 лидов» требует дополнительного основания: нельзя автоматически приписать весь недобор одному событию. Объяснение должно отделять наблюдение от причинного вывода.

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

Как превратить пожелание «пусть ИИ объясняет» в задание? Опишите задачу для ИИ-агента через результат приёмки: открыть период, увидеть план и факт по направлениям, перейти к исходным записям, проверить отклонение и его статус. Начните с одного показателя, по которому уже согласован паспорт.

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

Контрольный пример из начала статьи превращается в приёмку: общий итог 120, у контента 15 из 30 и 50 %, недобор 15. Если строка контента загрузилась не полностью, вместо оценки появляется предупреждение. Это два разных результата, и код должен воспроизводить оба.

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

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

У нашей машины есть собственная админка, её работа видна отдельной зоной публичной карты кода. Этот экран доказывает, что мы строим пульт для наблюдения за машиной. Он не показывает готовую систему KPI клиента; набор её экранов и источников ещё предстоит согласовать.

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

Подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц, условия проверены 8 октября 2026. Для этой задачи покупается код дашборда целей отдела по направлениям, формулам и ответственным. Инженер ведёт машину агентов, код остаётся в репозитории клиента; на поток идёт одна задача в работе, следующие ждут в очереди, пауза возможна в любой месяц.

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

Вернёмся к учебному месяцу. На обсуждение приходит не «отдел выполнил 120 %», а «контент выполнил 50 %, данные полные, недобор 15, причина пока не установлена; ответственный проверит пропущенный выпуск». После действия нужен следующий замер по тому же правилу. Иначе дашборд заканчивается комментарием, который никто не использует.

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

1. Смотрите цели направлений рядом с итогом отдела; складывайте только сопоставимые величины.

2. До разработки запишите формулу, период, источник, правила дублей и ответственного.

3. При неполных входах останавливайте оценку выполнения; ошибка загрузки не равна нулю.

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

5. Принимайте код на контрольном примере, назначайте действие и возвращайтесь к следующему замеру.