# Воронки и FF в методологии

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


<h2 id="section-1">Задача</h2>

Воронка связывает привлечение с последующими действиями человека и результатом бизнеса. Работа с ней начинается с вопроса: на каком переходе требуется решение и по каким событиям можно проверить изменение.

FF относится к этому направлению метода. Глава описывает подход к воронкам; состав и возможности конкретной реализации FF требуют отдельной документации. Здесь открыты принципы и учебные приёмы работы.

Выберите один путь и одну задачу. Например, разобраться, что происходит между отправкой формы и созданием заказа. Рост числа отправок ещё не объясняет, стали ли люди чаще оплачивать.

<h2 id="section-2">Условия</h2>

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

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

Назначьте ответственного за полноту данных и отдельного владельца решения. Если этих условий не хватает, результат первого этапа — план подготовки. Исходное определение показателя сохраняется в [паспорте метрики](/method/data-contract).

<h2 id="section-3">Устройство</h2>

Опишите путь через наблюдаемые события: источник → обращение → следующий этап → заказ → оплата. Названия зависят от задачи. Переход может не состояться; система должна отличать это от потери события в источнике.

Для одной правки запишите:

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

Агент может подготовить вариант и проверить его по заданию. Публикация проходит после проверки в пределах разрешённой операции; версия и дата правки остаются в журнале.

<h2 id="section-4">Проверка</h2>

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

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

Конверсия между соседними этапами не заменяет проверку всего пути. Даже рост оплат после правки не доказывает, что причина именно в ней: для такого вывода нужен подходящий план сравнения. [Публичный стандарт](/method/specification) сохраняет эти требования для каждой петли.

<h2 id="synthetic-funnel">Учебный приём: проверить отправку формы</h2>

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

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

**Учебное правило:** заявка возникает только после подтверждённого принятия с уникальным идентификатором. Нажатие остаётся самостоятельным событием.

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

**Допустимый вывод:** состояние перехода требует проверки; результат бизнеса по нему не установлен. Это упражнение на определения, без измеренного клиентского эффекта.

<h2 id="section-5">Связи</h2>

[Голиаф](/method/goliath) отвечает за рекламную петлю, [Соломон](/method/solomon) — за проверяемый расчёт. [Сквозной разбор](/method/walkthrough) соединяет их с воронкой. [Критик](/method/critic), [каталог ошибок](/method/failures) и [словарь](/method/glossary) помогают проверить решение и согласовать его смысл.