# Публичный стандарт машиночитаемого маркетинга

Источник: https://kurzemnek.ru/method/specification
Автор: Валерий Курземнек
Опубликовано: 2026-10-23
Обновлено: 2026-10-23


<h2 id="scope">Область применения и версия</h2>

**Версия 1.0 · 23 октября 2026 · автор — Валерий Курземнек.** Публичный авторский стандарт описывает одну проверяемую петлю маркетингового решения: от исходных данных до действия и оценки его результата.

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

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

<h2 id="mm-01">MM-01. Данные и определения</h2>

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

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

**Проверка:** повторите расчёт по объявленной рамке и проверьте полноту поступления событий. При расхождении источников действие, основанное на спорном числе, блокируется до выяснения причины.

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

<h2 id="mm-02">MM-02. Правила решения</h2>

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

**Зачем:** по одному и тому же числу можно принять разные решения, если не определены условия применения правила.

**Проверка:** дайте системе обычный случай и исключение. Она должна назвать применённое правило и остановиться там, где его условия не выполнены.

**Пример:** правило остановки по отсутствию заявок применяется только после проверки поступления данных. Порог из чужого кейса требует нового расчёта.

<h2 id="mm-03">MM-03. Полномочия</h2>

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

**Зачем:** техническая возможность изменить кабинет не означает, что агенту разрешено это делать.

**Проверка:** предложите действие за пределами выданных прав. Система должна передать его человеку и сохранить объяснение; самостоятельного исполнения быть не должно.

**Пример:** агенту разрешён только анализ. Он может обосновать увеличение бюджета, но не записывает его в кабинет.

<h2 id="mm-04">MM-04. Критик и блокировка действия</h2>

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

**Зачем:** убедительное объяснение исполнителя ещё не подтверждает корректность его решения.

**Проверка:** передайте заведомо ошибочное основание. Убедитесь, что проверяющий обнаружил проблему, а действие не исполнилось после отказа.

**Пример:** критик обнаружил, что расход и оплаты взяты за разные периоды. Решение возвращается на пересчёт.

<h2 id="mm-05">MM-05. Журнал решений</h2>

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

**Зачем:** без истории нельзя восстановить причину изменения и проверить, повлиял ли найденный урок на следующую работу.

**Проверка:** выберите исполненное действие и восстановите его путь до источников и обратно к результату. Причина отказа также должна оставаться доступной.

**Пример:** по журналу видно, какое правило остановило объявление, какие данные проверил критик и что произошло после остановки.

<h2 id="mm-06">MM-06. Замер и следующий цикл</h2>

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

**Зачем:** выполненная операция показывает объём работы; её полезность требует отдельной проверки.

**Проверка:** найдите дату повторного замера и основание вывода. Если окно ещё не завершилось, наблюдение отмечается как предварительное.

**Пример:** первые переходы после изменения воронки ещё не подтверждают рост оплат. Вывод по оплатам ждёт оговорённого периода и проверенных данных.

<h2 id="application">Как применять требования</h2>

Опишите одну задачу, приложите свидетельства выполнения каждого требования и перечислите пробелы. До их устранения ограничьте работу теми действиями, для которых хватает данных и полномочий. [Синтетические примеры](/method/examples) помогают проверить поведение; [открытый шаблон](/method/direct-plan) — подготовить диагностику и план.

История этой версии находится в [журнале изменений](/method/changelog). Общие определения и устройство решения изложены в [главе о петле](/method/standard).