Что такое машиночитаемый маркетинг
Машиночитаемый маркетинг — метод организации маркетинга, при котором данные, определения метрик, правила принятия решений и результаты действий доступны агентской системе в проверяемой форме. Человек задаёт цель, пределы полномочий и цену ошибки. Система получает данные, проверяет их, предлагает или выполняет действие и возвращается к измерению результата.
Я, Валерий Курземнек, развиваю этот метод на практике. Его первая публичная версия — манифест от 8 июля 2026 года. Эта страница раскрывает устройство метода и порядок внедрения. Фактура — в кейсах систем, которые мы построили.
Главное условие: нет петли — нет агента. Для управления рекламными деньгами нужно видеть связь расхода с оплатой. Для управления блогом — связь конкретной правки с выбранной метрикой и окном замера. Если система не может отличить результат действия от ошибки в данных, расширять её полномочия рано.
Единица метода — проверяемая петля решения
У петли есть конкретная задача, источники данных, правило, допустимое действие и способ проверить исход. Например: понять, нужно ли остановить объявление, по расходу и уникальным лидам; перед остановкой проверить, что источники не потеряли регистрации.
Данные → проверка → решение → действие → измерение → изменение правила.
Это повторяемый цикл. Ошибка становится материалом для следующей проверки: если однажды агент остановил работающую кампанию из-за разрыва разметки, в следующем проходе «ноль лидов» должен проходить отдельную приёмку.
Для каждой петли нужно записать:
- Цель: какой бизнес-результат мы меняем и за какой период.
- Единицу счёта: человек, регистрация, заказ или платёж; новые и повторные учитываются раздельно.
- Вход: источники, ключи склейки, свежесть и известные ограничения.
- Правило: условия остановки, продолжения и увеличения бюджета.
- Полномочия: что агент делает сам, что предлагает человеку и где останавливается.
- След: входные числа, применённое правило, действие и последующий исход.
Как устроены машиночитаемые данные
Основа аналитического контура — расход → визит → лид → квалификация → сделка → оплата. Источники могут называть этапы по-разному. Эти названия сопоставляются с общей схемой, а определения лежат рядом с данными.
Агрегат «кампания принесла миллион» недостаточен для нового вопроса. Нужны исходные события: когда пришёл человек, какие касания были, что он оплатил. Тогда разрез по месяцу, продукту или аудитории считается из одной базы, и не приходится заново заказывать отчёт.
Один и тот же бизнес может показать разные результаты при смене рамки. Оплаты новых людей, оплаты всех людей после рекламного касания и оплаты в месяце первой регистрации — разные ответы. Рамку объявляют до расчёта и сохраняют вместе с ним.
Числа считают скрипты, модель рассуждает поверх. У каждого числа должны быть источник и способ воспроизведения. Для значимых денежных решений нужна независимая сверка. Красный сигнал свежести или полноты блокирует вывод: система сообщает, чего ей не хватает.
Эту функцию в нашем контуре выполняет Соломон. Он превращает методологическое требование «рубль должен читаться» в рабочую аналитическую систему.
Чем это отличается от сквозной аналитики
Сквозная аналитика связывает расходы на привлечение с заявками, продажами и выручкой. Она помогает увидеть результат источников и кампаний в выбранной модели атрибуции. Для управления рекламными деньгами это основа машиночитаемого маркетинга.
Машиночитаемый маркетинг задаёт устройство всей петли решения: как агент получает данные, понимает определения, проверяет расчёт, выбирает допустимое действие и затем оценивает его результат. Связь клика с оплатой — первый слой этой работы.
| Вопрос | Что даёт сквозная аналитика | Что метод требует от контура дополнительно |
|---|---|---|
| Откуда пришли деньги? | Связь источников, заявок и продаж; расчёт по выбранной атрибуции | Явные определения людей и оплат, когорта и окно рядом с каждым выводом |
| Можно ли доверять числу? | Собранные данные и рассчитанные показатели | Проверки свежести, полноты и склейки; независимая сверка значимых денежных расчётов; запрет действия при расхождении |
| Как ответить на новый вопрос? | Отчёты и доступные разрезы системы | Доступ агента к исходным событиям, схеме и определениям; воспроизводимый расчёт нужного разреза |
| Что делать с результатом? | Основание для маркетингового решения | Записанные правила, пределы полномочий, критик, исполнение и журнал с последующим замером |
Разница становится видна на простой ситуации. В отчёте у кампании расход есть, а лидов нет. Перед остановкой машиночитаемый контур проверяет, поступают ли данные и совпадают ли кабинет, аналитика и CRM. Если разметка сломалась, он блокирует решение об остановке и сообщает о разрыве. Если источники исправны и стоп-правило выполнено, агент может остановить кампанию в пределах своих полномочий. Причина и входные числа останутся в журнале.
Для этого данные должны быть доступны на уровне событий. Рядом лежат определения: что считается новым человеком, какой реестр содержит деньги, когда обновилась таблица. Тогда вопрос «какие новые люди из этой кампании оплатили в следующем месяце?» можно пересчитать и проверить по тем же исходным данным.
У современных аналитических платформ тоже бывают автоматизация и управление ставками. Поэтому наличие автоматического действия само по себе не отличает наш метод. Существенна организация контура: доступность данных и правил агенту, обязательная приёмка оснований, ограничение полномочий и проверка исхода. Если существующая система уже обеспечивает эти свойства, её можно использовать внутри метода.
Начинать заново со смены сервиса не требуется. Начать стоит с проверки текущей петли: может ли агент воспроизвести число, обнаружить сломанный источник, объяснить решение и остановиться там, где данных или полномочий недостаточно. Сквозная аналитика даёт связь с деньгами; метод определяет, как этой связью пользоваться при делегировании решений машине.
Шкала машиночитаемости 0–3
Уровень 0. Рубль не читается. Путь до оплаты обрывается, определения расходятся или источники не сверяются. Работа этапа — восстановить данные. Автономные решения о деньгах запрещены.
Уровень 1. Петля есть, решения руками. Данные проверяются, человек принимает решения. Работа этапа — записать правила, исключения и пределы полномочий.
Уровень 2. Агент предлагает, человек утверждает. Система приносит действие с обоснованием. Человек проверяет её поведение на реальных ситуациях и на ошибочных входных данных.
Уровень 3. Агент действует внутри правил. Система выполняет разрешённые действия, журналирует их и останавливается на исключениях. Человек меняет архитектуру и рамку.
Уровень задаётся для отдельной петли. У компании может быть автономная закупка трафика и одновременно непроверенный новый канал. Право действовать не переносится на него автоматически.
Порядок внедрения
1. Выбрать одну задачу. Например, ежедневный разбор рекламных кампаний. Зафиксировать цель, окно оценки и допустимый расход на проверку гипотезы. Результат шага — описание одной петли.
2. Собрать и определить данные. Сопоставить расход, касания, людей и оплаты. Разделить новые и повторные регистрации, выбрать реестр денег. Результат — схема и словарь метрик, доступные человеку и агенту.
3. Проверить прибор. Сверить ключи, полноту и свежесть. Посчитать выручку вторым маршрутом. Проверить поведение на сломанном источнике: система должна обнаружить проблему. Результат — условия, при которых числу можно доверять.
4. Оцифровать решения. Записать стоп-правила, потолок бюджета, ступени масштабирования, полномочия и исключения. Результат — регламент, который исполняется одинаково при каждом проходе.
5. Запустить предложения. Агент показывает, что сделал бы и почему. Критик проверяет основания. Расхождения с человеком становятся правками правил или данных. Результат — журнал решений на реальных ситуациях.
6. Открыть ограниченное действие. Дать запись через API только внутри проверенной рамки. Сохранить потолок ущерба и порядок остановки. Результат — рабочая петля с наблюдаемым исходом.
7. Повторить цикл. После окна замера проверить гипотезу. Перенести найденную ошибку в автоматическую проверку. Следующую петлю открывать по той же последовательности.
Как выглядят правила решений
В Голиафе используются стоп-правила: семь дней без лидов; расход 3×ARPL без лида; стоимость ключевого этапа выше модельной в 1,7 раза. Это правила конкретного контура, их нельзя переносить в другой бизнес без расчёта. ARPL — выручка на одного лида в объявленной когорте и окне; задержка оплат меняет его смысл.
Перед остановкой нужно убедиться, что «нет лидов» означает отсутствие результата. Если кабинет, аналитика и CRM расходятся, сначала разбирается стык данных. Увеличение бюджета тоже идёт ступенями: редкий большой чек не должен автоматически давать гипотезе неограниченное доверие.
Критик сверяет решение с источниками и правилами. Гейт запрещает действие при нарушении условия. Для арифметики и технических ограничений подходит программная проверка; для смысла текста и контекста — модель. Роль критика имеет смысл только тогда, когда его отказ действительно останавливает работу.
Границы применения
Метод вырос из перформанс-маркетинга. Автономные денежные решения требуют связи с оплатами, достаточного объёма наблюдений и учёта задержки продаж. При длинном цикле сделки или малой выборке система может готовить анализ, но право масштабировать бюджет требует отдельного основания.
Блог измеряется по своей петле: статья или правка, поисковые показы и переходы, последующие действия. Количество публикаций показывает объём работы. Оно само по себе не доказывает рост спроса или выручки.
Доступ к API определяет границу исполнения. Без него контур заканчивается предложением человеку. Данные с персональными сведениями требуют отдельной подготовки перед использованием внешней модели — для этого мы сделали Трансграничного монстра.
У подхода есть общие части со сквозной аналитикой, BI и управлением по данным. Машиночитаемый маркетинг собирает их в исполняемый контур: определения, проверки, правила, право действовать и журнал исходов доступны системе вместе.
Четыре реализации метода
- Соломон — аналитическая основа: данные, определения, расчёты и границы достоверности.
- Голиаф — управление Яндекс Директом внутри правил и бюджетных ограничений.
- Прометей — работа с блогом: исследование, создание, критик, публикация и проверка гипотез.
- Трансграничный монстр — подготовка CRM-выгрузок с сохранением аналитической связи между событиями.
Все четыре связаны одним требованием: система должна видеть, на каких данных и по какому правилу она действует.
Первичный источник метода и полных кейсов — kurzemnek.ru. На страницах указаны автор, дата, рамка измерения и ограничения. Новая фактура будет дополнять эту базу, а обсуждение — идти в Telegram.