HADI-циклы: что это, как формулировать гипотезы и пример на данных

Коротко

HADI-цикл — это способ проверять гипотезы по одному и тому же маршруту: Hypothesis (гипотеза) → Action (действие) → Data (данные) → Insight (вывод). Вывод одного цикла становится источником следующей гипотезы.

• Гипотеза записывается до запуска и содержит действие, метрику, размер ожидаемого изменения, срок и причину.
• Действие — минимальное изменение, которое проверяет одну причину, а не три сразу.
• Данные собирают по метрике, выбранной заранее. Срезы, которых не было в плане, дают новые гипотезы, а не доказательства.
• Вывод — это решение (оставить, откатить, перепроверить) и список того, что осталось предположением.
• HADI — рамка процесса, A/B-тест — один из способов получить данные на третьем шаге.
• При малом трафике и медленных метриках цикл растягивается на месяцы, и это нужно посчитать до старта.

Что такое HADI-цикл

HADI — аббревиатура от Hypothesis, Action, Data, Insight. Команда формулирует предположение о том, что изменит метрику, делает одно действие для проверки, собирает данные и записывает вывод. Затем цикл повторяется с новой гипотезой.

Метод вырос из практики стартапов и по смыслу близок циклу Build–Measure–Learn из «The Lean Startup» Эрика Риса. Кто именно придумал аббревиатуру HADI, достоверно не установлено: первоисточника с именем автора найти не удаётся. В русскоязычной среде метод разошёлся через стартап-акселераторы и продуктовые команды.

Ничего нового по сравнению с научным методом в HADI нет, и в этом его сила. Он заставляет записать ожидание до того, как появились данные. Без записи почти любой результат задним числом объясняется как успех.

Четыре шага HADI: что делает аналитик на каждом

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

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

Как сформулировать гипотезу для HADI: шаблон и примеры

Гипотеза начинается с наблюдения. В учебной базе продукта «Маяк» (сервис отчётов, регистрации с июня по август 2026 года) доля новых пользователей, создавших хотя бы один отчёт, сильно зависит от канала.

В paid_search отчёт создали 238 из 1 015 зарегистрированных — 23,4%. В referral — 486 из 1 037, то есть 46,9%. Разрыв вдвое. Это наблюдение, а не гипотеза: оно не говорит, что делать.

Плохая формулировка: «Улучшим онбординг для рекламного трафика, и активация вырастет». Непонятно, что именно меняется, на сколько должна вырасти метрика и когда признать, что не получилось. Такую гипотезу нельзя опровергнуть, поэтому она ничему не учит.

Хорошая формулировка: «Если пользователям из paid_search сразу после регистрации показать готовый шаблон отчёта, то доля создавших отчёт в первые семь дней вырастет с 23% минимум до 28% на когортах четырёх недель, потому что они приходят по запросу о конкретном отчёте и не находят, с чего начать». Здесь есть действие, аудитория, метрика, порог, срок и причина. Причина — самая важная часть: если метрика не сдвинется, вы узнаете, что дело не в «пустом экране», и следующая гипотеза будет о другом.

Оговорка: 28% и «потому что» в этом примере — предположения. База показывает только разрыв между каналами. Он может объясняться и тем, что реклама приводит менее мотивированных людей, и тогда шаблон ничего не изменит. Цикл как раз и нужен, чтобы это выяснить.

SELECT
  u.channel,
  count(*) AS signed_up,
  count(r.user_id) AS created_report,
  round(100.0 * count(r.user_id) / count(*), 1) AS activation_pct
FROM users AS u
LEFT JOIN (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_name = 'report_created'
) AS r ON r.user_id = u.user_id
GROUP BY u.channel
ORDER BY activation_pct;

Пример HADI-цикла: Hypothesis и Action

Гипотезу про paid_search проверить не на чем: такого изменения в базе не было. Зато в ней лежит готовый эксперимент onboarding_checklist, и на нём можно пройти цикл целиком. База хранит только итог теста, поэтому формулировка ниже — учебная реконструкция того, что стоило записать до запуска.

Hypothesis. «Если новым пользователям после регистрации показать чек-лист первых шагов, то доля дошедших до целевого действия вырастет с 20% минимум на 4 п.п. за время набора выборки, потому что сейчас после регистрации не видно, что делать дальше». Основная метрика — флаг converted из таблицы эксперимента. Рядом заранее названы две контрольные метрики: доля создавших отчёт и доля оплативших. Они не должны ухудшиться.

Откуда 4 п.п. Через тест прошло около 1 530 человек на группу. При базовой конверсии 20%, уровне значимости 5% и мощности 80% такая выборка надёжно различает прирост примерно от 4,2 п.п. Ставить порог ниже нет смысла: меньший эффект тест с большой вероятностью пропустит.

Action. Новых пользователей случайно делят на две группы: control видит прежний онбординг, checklist — чек-лист. Действие одно, поэтому результат можно приписать ему. Способ сравнения здесь — A/B-тест, набор шёл с 1 июня по 29 августа.

Пример HADI-цикла: Data

Сначала качество. В таблице одна строка на пользователя, в контроле 1 527 человек, в тестовой группе 1 541 — сплит ровный, перекоса выборки нет. Затем основной результат и обе контрольные метрики одним запросом.

Основная метрика выросла с 20,0% до 30,3%: 306 из 1 527 против 467 из 1 541. Разница — 10,27 п.п., 95%-й доверительный интервал от +7,22 до +13,31 п.п. Нижняя граница выше порога в 4 п.п., гипотеза по основной метрике проходит.

Контрольные метрики ведут себя иначе. Отчёт после попадания в тест создали 37,4% контроля и 39,2% тестовой группы: +1,8 п.п. при интервале от −1,6 до +5,2, от нуля не отличить. Доля оплативших в группе с чек-листом ниже: 18,7% против 21,3%, разница −2,7 п.п., интервал от −5,5 до +0,2. Ноль в интервал попадает, но едва.

SELECT
  x.variant,
  count(*) AS users,
  round(100.0 * count(*) FILTER (WHERE x.converted) / count(*), 1) AS converted_pct,
  round(100.0 * count(r.user_id) / count(*), 1) AS report_pct,
  round(100.0 * count(p.user_id) / count(*), 1) AS paying_pct
FROM experiment_exposures AS x
LEFT JOIN (
  -- создали отчёт после попадания в эксперимент
  SELECT DISTINCT e.user_id
  FROM events AS e
  JOIN experiment_exposures AS xe ON xe.user_id = e.user_id
  WHERE e.event_name = 'report_created'
    AND e.event_time >= xe.exposed_at
) AS r ON r.user_id = x.user_id
LEFT JOIN (
  SELECT DISTINCT user_id
  FROM payments
) AS p ON p.user_id = x.user_id
WHERE x.experiment_name = 'onboarding_checklist'
GROUP BY x.variant
ORDER BY x.variant;

Срез по устройствам: где именно сработал чек-лист

Средний эффект в 10 п.п. скрывает две разные картины. На десктопе конверсия выросла с 20,0% до 39,8% — почти вдвое, +19,75 п.п. при интервале от +15,4 до +24,1. На мобильных не изменилась: 20,1% в контроле и 19,9% с чек-листом, разница −0,16 п.п., интервал от −4,3 до +3,9.

Сравнивать группы внутри устройства корректно: устройство записано при регистрации и от варианта не зависит, доля десктопа в группах почти одинаковая — 51,7% и 52,4%.

В гипотезе этого среза не было, значит, формально он разведочный. Эффект на десктопе настолько велик, что случайностью его не объяснить. Но «на мобильных чек-лист не работает» — уже не доказанный факт, а осторожное наблюдение: интервал допускает и небольшой вред, и небольшую пользу.

SELECT
  u.device,
  x.variant,
  count(*) AS users,
  count(*) FILTER (WHERE x.converted) AS converted_users,
  round(100.0 * count(*) FILTER (WHERE x.converted) / count(*), 1) AS converted_pct
FROM experiment_exposures AS x
JOIN users AS u ON u.user_id = x.user_id
WHERE x.experiment_name = 'onboarding_checklist'
GROUP BY u.device, x.variant
ORDER BY u.device, x.variant;

Insight: что подтверждено данными, а что осталось предположением

Вывод цикла — не слово «подтвердилась». Это решение и честный список того, чего данные не показали. Удобно разложить всё по трём колонкам.

Самое неприятное место — сама основная метрика. В выгрузке не записано, какое действие отмечает флаг converted, и с событиями продукта он не связан: отчёт создали 37,4% сконвертированных и 38,6% остальных. Если «целевое действие» — это, например, прохождение самого чек-листа, тест показал, что чек-лист проходят, а не что продукт стал полезнее. В рабочей задаче этот вопрос задают владельцу эксперимента до расчётов.

Причину из гипотезы тест не проверял вовсе. Группы различались наличием чек-листа, и вырос флаг. Почему вырос и почему только на десктопе, по этим данным сказать нельзя. Версия «на телефоне чек-лист не попадает на первый экран» правдоподобна, но это следующая гипотеза, а не вывод.

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

Как вести журнал гипотез и сколько циклов запускать параллельно

Журнал — обычная таблица, одна строка на цикл. Главное правило: поля до черты «результат» заполняются перед запуском и потом не редактируются. Иначе журнал превращается в архив успехов.

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

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

Чем HADI отличается от A/B-теста и от PDCA

HADI и A/B-тест часто называют через запятую, хотя это вещи разного уровня. HADI описывает порядок работы с гипотезой. A/B-тест — способ получить данные на третьем шаге, самый надёжный, потому что случайное деление убирает влияние сезона, рекламы и состава трафика. Цикл можно пройти и без теста — сравнением «до и после» или когорт, — но тогда вывод слабее: изменение метрики нельзя уверенно приписать действию.

PDCA (Plan–Do–Check–Act) — цикл непрерывного улучшения процессов. Он восходит к работам Уолтера Шухарта и стал известен благодаря Эдвардсу Демингу; сам Деминг предпочитал вариант PDSA со словом Study вместо Check. PDCA начинается с плана и заканчивается закреплением нового стандарта. HADI начинается с предположения, которое может оказаться неверным, и заканчивается знанием. Первый удобен, когда понятно, что улучшать. Второй — когда неизвестно, что сработает.

Когда HADI-циклы не работают

Мало трафика. Допустим, в продукте 200 регистраций в неделю, базовая конверсия 20%, и вы хотите заметить прирост на 4 п.п. Нужно около 1 530 человек на группу, то есть 3 060 всего — это больше 15 недель. «Недельный цикл» здесь невозможен. Варианты: проверять гипотезы с крупным ожидаемым эффектом, взять более раннюю и частую метрику или заменить количественную проверку на интервью и тесты прототипов, честно понизив уверенность в выводе.

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

Подгонка вывода. Цикл превращается в ритуал, когда метрику выбирают после просмотра данных, останавливают тест в день, когда разница красивая, или перебирают срезы, пока один не «выстрелит». Признаки: в журнале нет опровергнутых гипотез, пороги не записаны, в выводах только слово «подтвердилась». В примере выше срез по устройствам тоже найден после просмотра данных — поэтому он помечен как разведочный и ведёт к новой гипотезе, а не к утверждению о мобильных.

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

Частые вопросы о HADI-циклах

Итог

HADI-цикл полезен не четырьмя буквами, а дисциплиной: ожидание записано до данных, действие одно, метрика выбрана заранее, вывод отделяет доказанное от догадок. На учебном примере цикл дал решение включить чек-лист на десктопе и три открытых вопроса — про мобильные, про определение целевого действия и про оплаты. Это нормальный итог: хороший цикл заканчивается следующей гипотезой.

Чтобы пройти такой цикл на своих данных, нужно уметь самостоятельно посчитать метрику из таблиц событий. Это отрабатывают в Симуляторе SQL-аналитика на той же базе продукта, что и запросы в этой статье.