Задача#
Воронка связывает привлечение с последующими действиями человека и результатом бизнеса. Работа с ней начинается с вопроса: на каком переходе требуется решение и по каким событиям можно проверить изменение.
FF относится к этому направлению метода. Глава описывает подход к воронкам; состав и возможности конкретной реализации FF требуют отдельной документации. Здесь открыты принципы и учебные приёмы работы.
Выберите один путь и одну задачу. Например, разобраться, что происходит между отправкой формы и созданием заказа. Рост числа отправок ещё не объясняет, стали ли люди чаще оплачивать.
Условия#
Для каждого перехода определите событие, источник и правило связи с человеком. Запишите, когда событие считается состоявшимся: нажатие кнопки, принятие обращения и успешная оплата означают разные вещи.
До изменения сценария зафиксируйте исходную версию, аудиторию, метрику и период оценки. Уточните, что агент может предложить, что разрешено публиковать и кто принимает решение по исключению. Чтение событий не даёт права менять форму или отправлять сообщения.
Назначьте ответственного за полноту данных и отдельного владельца решения. Если этих условий не хватает, результат первого этапа — план подготовки. Исходное определение показателя сохраняется в паспорте метрики.
Устройство#
Опишите путь через наблюдаемые события: источник → обращение → следующий этап → заказ → оплата. Названия зависят от задачи. Переход может не состояться; система должна отличать это от потери события в источнике.
Для одной правки запишите:
- Гипотезу: какое сообщение, поле или правило перехода меняем и почему это стоит проверить.
- Область: какой сценарий и какая группа затронуты; что исполнитель вправе изменить.
- Измерение: какое событие ожидаем увидеть, когда вернёмся к результату и с чем сравним.
- Остановку: какие ошибки данных, проверки или полномочий блокируют публикацию и зависимые выводы.
Агент может подготовить вариант и проверить его по заданию. Публикация проходит после проверки в пределах разрешённой операции; версия и дата правки остаются в журнале.
Проверка#
Сначала пройдите сценарий в изолированной учебной среде. Убедитесь, что событие пришло полностью, сохранило связь с человеком и не продублировалось. Отказ критика должен блокировать соответствующее изменение.
После публикации отдельно проверяются техническая работа сценария и результат гипотезы. Источники должны покрывать назначенное окно, а сравнение — сохранять единицу счёта и аудиторию. Если изменился состав трафика, это ограничение вывода.
Конверсия между соседними этапами не заменяет проверку всего пути. Даже рост оплат после правки не доказывает, что причина именно в ней: для такого вывода нужен подходящий план сравнения. Публичный стандарт сохраняет эти требования для каждой петли.
Учебный приём: проверить отправку формы#
Полностью вымышленный учебный пример. Магазин «Бумажная орбита», интерфейс и события придуманы; клиентские наблюдения не используются.
Вход: посетитель нажал «Отправить», но подтверждения принятия обращения нет. Отчёт считает нажатие созданной заявкой.
Учебное правило: заявка возникает только после подтверждённого принятия с уникальным идентификатором. Нажатие остаётся самостоятельным событием.
Проверка: проследить оба события и связь между ними. Пока подтверждение не найдено, нельзя увеличивать число заявок по кликам кнопки. Если источник подтверждений неполон, вывод о потере обращений также преждевременен.
Допустимый вывод: состояние перехода требует проверки; результат бизнеса по нему не установлен. Это упражнение на определения, без измеренного клиентского эффекта.
Связи#
Голиаф отвечает за рекламную петлю, Соломон — за проверяемый расчёт. Сквозной разбор соединяет их с воронкой. Критик, каталог ошибок и словарь помогают проверить решение и согласовать его смысл.