Область применения и версия#
Версия 1.0 · 23 октября 2026 · автор — Валерий Курземнек. Публичный авторский стандарт описывает одну проверяемую петлю маркетингового решения: от исходных данных до действия и оценки его результата.
Для выбранной задачи должны выполняться все шесть требований ниже. Проверять их нужно на конкретных источниках и действиях: наличие документа с правилами ещё не доказывает, что система их соблюдает. Выполненные проверки подтверждают устройство петли в проверенных условиях; финансовый результат измеряется отдельно. Короткие примеры в требованиях — условные ситуации.
Готовность данных и право агента действовать оцениваются раздельно. Если данные доступны, а полномочия ограничены предложениями, система готовит предложение человеку. Это ограничение сохраняется при каждом запуске.
MM-01. Данные и определения#
У решения должны быть указаны источники, единица счёта, состав аудитории, период, определения метрик и время обновления данных. Расчёт воспроизводится инструментом; значимое денежное число проходит независимую сверку.
Зачем: одинаковое название показателя может скрывать разные события. Регистрация, человек, сделка и оплата требуют своих определений.
Проверка: повторите расчёт по объявленной рамке и проверьте полноту поступления событий. При расхождении источников действие, основанное на спорном числе, блокируется до выяснения причины.
Пример: регистрации есть в CRM, но отсутствуют в рекламном отчёте. Сначала восстанавливается связь событий; вывод «реклама не даёт заявок» пока не подтверждён.
MM-02. Правила решения#
Для петли записаны условия продолжения, остановки и изменения действия, а также исключения. Денежные пороги и окна оценки имеют основание в экономике и цикле сделки конкретного бизнеса.
Зачем: по одному и тому же числу можно принять разные решения, если не определены условия применения правила.
Проверка: дайте системе обычный случай и исключение. Она должна назвать применённое правило и остановиться там, где его условия не выполнены.
Пример: правило остановки по отсутствию заявок применяется только после проверки поступления данных. Порог из чужого кейса требует нового расчёта.
MM-03. Полномочия#
Для каждой петли определены разрешённые операции, предел доступного расхода и случаи обязательного решения человека. Доступ на чтение и право на запись задаются отдельно.
Зачем: техническая возможность изменить кабинет не означает, что агенту разрешено это делать.
Проверка: предложите действие за пределами выданных прав. Система должна передать его человеку и сохранить объяснение; самостоятельного исполнения быть не должно.
Пример: агенту разрешён только анализ. Он может обосновать увеличение бюджета, но не записывает его в кабинет.
MM-04. Критик и блокировка действия#
До исполнения решение проходит отдельную проверку оснований и правил. Для арифметики и технических ограничений используются программные проверки; смысл и контекст может проверять отдельная модель. Отказ действительно блокирует действие и возвращает задачу на доработку.
Зачем: убедительное объяснение исполнителя ещё не подтверждает корректность его решения.
Проверка: передайте заведомо ошибочное основание. Убедитесь, что проверяющий обнаружил проблему, а действие не исполнилось после отказа.
Пример: критик обнаружил, что расход и оплаты взяты за разные периоды. Решение возвращается на пересчёт.
MM-05. Журнал решений#
Для каждого прохода сохраняются исходные числа и их рамка, применённое правило, предложенное действие, результат проверки и факт исполнения. После замера запись дополняется исходом.
Зачем: без истории нельзя восстановить причину изменения и проверить, повлиял ли найденный урок на следующую работу.
Проверка: выберите исполненное действие и восстановите его путь до источников и обратно к результату. Причина отказа также должна оставаться доступной.
Пример: по журналу видно, какое правило остановило объявление, какие данные проверил критик и что произошло после остановки.
MM-06. Замер и следующий цикл#
До действия определены ожидаемый результат, период оценки и способ сравнения. После окна замера прогноз сопоставляется с фактом. Подтверждённый урок переносится в правило или инструмент и проверяется на следующем запуске.
Зачем: выполненная операция показывает объём работы; её полезность требует отдельной проверки.
Проверка: найдите дату повторного замера и основание вывода. Если окно ещё не завершилось, наблюдение отмечается как предварительное.
Пример: первые переходы после изменения воронки ещё не подтверждают рост оплат. Вывод по оплатам ждёт оговорённого периода и проверенных данных.
Как применять требования#
Опишите одну задачу, приложите свидетельства выполнения каждого требования и перечислите пробелы. До их устранения ограничьте работу теми действиями, для которых хватает данных и полномочий. Синтетические примеры помогают проверить поведение; открытый шаблон — подготовить диагностику и план.
История этой версии находится в журнале изменений. Общие определения и устройство решения изложены в главе о петле.