# От рекламы до следующего решения

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


<h2 id="scenario">Рамка учебного разбора</h2>

**Полностью вымышленный учебный пример.** Магазин бумажных моделей «Бумажная орбита», события, роли, суммы и правила придуманы специально для объяснения. Здесь нет клиентской фактуры, включая обезличенные наблюдения.

Разбираем заявки одного учебного объявления за 1–7 сентября 2026. Для каждой заявки учитываем связанные оплаты с момента создания включительно до того же времени через семь дней исключительно. Это учебное окно, а не рекомендация для другого бизнеса. Источники полны по 14 сентября включительно; расчёт выполняется 15 сентября. Часовой пояс — Europe/Moscow, валюта — RUB.

<figure class="m-journey-map" aria-labelledby="journey-caption">
<figcaption id="journey-caption">Одна проверяемая цепочка</figcaption>
<ol class="m-journey-track">
<li>Объявление</li><li>Заявка</li><li>Заказ</li><li>Оплата</li><li>Расчёт</li><li>Критик</li><li>Разрешённое решение</li><li>Следующий замер</li>
</ol>
</figure>

<h2 id="advertising">Объявление и расход</h2>

**Вход:** идентификатор объявления, время привлечения и учебный расход за период. **Ответственный:** исполнитель рекламной петли; её устройство описано в [главе Голиафа](/method/goliath).

**Выход:** источник каждого привлечённого обращения и проверенный расход. **Остановка:** нет связи с объявлением, период не совпадает или источник расхода неполон. Нельзя распределять неизвестный расход по заявкам догадкой.

<h2 id="lead">Подтверждённая заявка</h2>

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

**Выход:** четыре подтверждённые заявки L-A, L-B, L-C, L-D. **Остановка:** есть лишь нажатие кнопки или невозможно проверить повтор. События и определения сначала уточняются в [воронке](/method/funnels).

<h2 id="order">Связь с заказом</h2>

**Вход:** идентификатор заявки и события заказа. **Ответственный:** владелец учёта заказов. **Выход:** L-A связана с O-A, L-B — с O-B; для двух других заявок в полном учебном источнике заказов нет.

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

<h2 id="payment">Событие оплаты</h2>

**Вход:** платёжный источник с суммой, временем и связью с заказом. **Ответственный:** владелец денежного реестра. **Выход:** P-A на 200 ₽ связана с O-A, P-B на 400 ₽ — с O-B; обе оплаты попадают в окно своих заявок.

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

<h2 id="calculation">Воспроизводимый расчёт</h2>

**Вход:** проверенные связи и [паспорт метрики](/method/data-contract). **Ответственный:** аналитическая петля [Соломона](/method/solomon); числа считает скрипт.

**Синтетические строки того же полностью вымышленного примера:**

| Заявка | Заказ и учтённая оплата |
| --- | --- |
| L-A | O-A → P-A: 200 ₽ |
| L-B | O-B → P-B: 400 ₽ |
| L-C | Заказа и оплаты нет |
| L-D | Заказа и оплаты нет |

**Выход:** при вымышленном расходе 400 ₽ стоимость заявки равна 400 / 4 = **100 ₽**. Учтённые оплаты: 200 + 400 = **600 ₽**. Это разные показатели; четыре заявки не превращаются в четырёх покупателей.

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

<h2 id="review">Проверка готового разбора</h2>

**Учебная проверка полностью вымышленного разбора.**

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

**Выход:** в этом вымышленном сценарии независимая сверка подтвердила расчёт. Фома выдал PASS только для передачи человеку предложения об одной правке формы. PASS не разрешает запись или изменение бюджета и не доказывает бизнес-эффект. **Остановка:** существенное основание не подтверждено; зависимое действие блокируется. Подробнее — [протокол критика](/method/critic).

<h2 id="decision">Ограниченное решение</h2>

**Вход:** проверенный разбор и гипотеза владельца учебного сценария — уточнить подпись одного поля формы. Причина отсутствия заказов у части заявок пока неизвестна. **Ответственный:** человек отдельно утвердил эту конкретную правку; исполнитель получил право только на неё.

**Выход:** записаны версия формы, дата изменения и план замера. **Остановка:** требуется другая правка или изменение бюджета, на которые разрешение не выдано. Рекламные полномочия Голиафа остаются прежними. Проверенный расчёт обосновывает наблюдение; выбранная правка всё ещё проверяет гипотезу.

<h2 id="measurement">Следующий замер и новый вопрос</h2>

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

**Вход:** после учебной правки 15 сентября собирается следующая группа заявок за 16–22 сентября; для неё действует то же семидневное окно оплат. **Ответственный:** аналитик повторяет расчёт после полноты источников по 29 сентября.

**Вымышленное наблюдение того же учебного магазина:** при расходе 400 ₽ получено пять заявок, два оплаченных заказа и 600 ₽ оплат. Стоимость заявки равна 400 / 5 = **80 ₽**. Оплаты в примере не выросли, хотя стоимость заявки стала ниже.

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

[MM-06](/method/specification#mm-06) требует сохранить ограничения и проверить следующий урок. [Каталог ошибок](/method/failures) помогает разобрать неверные выводы; [словарь](/method/glossary) — согласовать термины. Здесь открыт учебный ход работы, без готового агента, конфигураций и внутренних инструкций.