# Анализ конкурирующих гипотез (ACH): как найти причину падения метрики

> Анализ конкурирующих гипотез (ACH) Хойера для продукта: матрица гипотез и фактов, диагностичность, 8 шагов и что спросить у команды, когда упала метрика.

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/ach-analiz-konkuriruyushchih-gipotez/

Анализ конкурирующих гипотез (ACH) — это способ искать причину события, заставляя все объяснения соревноваться друг с другом, а не подтверждать одно любимое. Вы строите матрицу «гипотезы × факты», вычёркиваете факты, которые подходят ко всем объяснениям сразу, и выбираете гипотезу, против которой меньше всего фактов — а не ту, за которую больше всего.

Руководителю это нужно в момент, когда метрика упала и через час в чате уже есть ответ: «Удержание (retention) просело — это новый онбординг». Ответ звучит убедительно, данные под него находятся, команду отправляют откатывать. А через две недели выясняется, что причина была в другом.

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

## Что такое анализ конкурирующих гипотез и откуда он взялся

Метод описал Ричардс Хойер-младший (Richards J. Heuer Jr.) в книге «Psychology of Intelligence Analysis», ACH посвящена глава 8. Сам Хойер пишет в сноске, что разработал процедуру для аналитиков, работавших над особенно трудными задачами.

Книгу выпустил Центр изучения разведки ЦРУ (CIA Center for the Study of Intelligence) в 1999 году. Она лежит в открытом доступе на cia.gov, ссылка — в «Источниках».

Хойер начинает с диагноза. Обычный аналитик интуитивно выбирает самый вероятный ответ и смотрит на информацию с одной точки зрения: подтверждает она его или нет. Если подтверждает — «я же говорил», и поиск закончен.

В главе 4 Хойер называет это выбором первого подходящего (satisficing): берём первое решение, которое выглядит удовлетворительным, вместо того чтобы перебрать варианты.

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

Метод закрывает этап «решить и запустить» в цикле решений при неопределённости. Общую карту восьми методов и место каждого в цикле смотрите в [хабе кластера](/blog/produktovye-resheniya-pri-neopredelennosti/).

## Почему руководителю важен ACH: цена одного объяснения

Ошибка, которую предотвращает метод, — предвзятость подтверждения (confirmation bias) на разборе инцидентов и падений метрик. Мы подробно разбирали, как команда месяцами «валидирует» то, во что уже верит, в материале про [предвзятость подтверждения в данных](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/). ACH — инструмент именно для этого момента: когда объяснение нужно быстро, а неверное стоит дорого.

Во что обходится неверная причина:

- **Чинят не то.** Откатывают релиз, который ни при чём, и теряют неделю работы команды и фичу, которую ждали клиенты.
- **Настоящая причина продолжает работать.** Если сломан трекинг, решения ближайших недель принимаются по ложным цифрам. Если сменился состав трафика, маркетинг продолжает лить деньги в канал, который не конвертирует.
- **Падает доверие к аналитике.** После двух-трёх «уверенных» объяснений, которые не подтвердились, любой отчёт встречают словами «а вы точно уверены?».

У ACH есть ещё одно свойство, которое Хойер называет следом решения (audit trail). Матрица — это запись того, какие объяснения рассматривали и почему отбросили. Через месяц на ретро не нужно восстанавливать по памяти, кто что говорил.

## Как провести ACH: 8 шагов для продуктовой аналитики

Ниже — восемь шагов Хойера в том порядке, в котором он их даёт. Под каждым — что это значит, когда упала конверсия, удержание или выручка.

1. **Выпишите все разумные гипотезы.** Хойер советует собирать их группой с разными точками зрения: если верной гипотезы нет в списке, правильного ответа не будет. В продукте зовите аналитика, разработчика релиза, маркетинг и того, кто отвечает за биллинг, и сначала соберите все варианты без оценки, а отбор — потом.
2. **Составьте список фактов и аргументов.** Сюда входят не только данные из дашбордов, но и допущения: «маркетинг ничего не менял», «сезонности у нас нет» — Хойер настаивает, что их надо записать явно. Для каждой гипотезы задайте вопрос: если она верна, что мы должны видеть — и чего не видеть?
3. **Постройте матрицу: гипотезы по столбцам, факты по строкам.** Идите по строкам: берёте один факт и отмечаете, согласуется ли он с каждой гипотезой, противоречит ей или не относится к ней. Здесь же оценивается диагностичность — какие факты помогают различать гипотезы.
4. **Доработайте матрицу.** Если две гипотезы нечем различить, объедините их; если важного фактора нет в матрице, добавьте. Факты без диагностической ценности уберите в отдельный список, чтобы осталась запись, что их рассматривали.
5. **Сделайте предварительные выводы — опровергая, а не доказывая.** Теперь идите по столбцам: смотрите на каждую гипотезу целиком и ищите факты, которые позволяют её отвергнуть. Одного надёжного противоречия может хватить, чтобы отказаться от гипотезы, а сколько угодно подтверждений не доказывают её.
6. **Проверьте чувствительность к ключевым фактам.** Вывод обычно держится на двух-трёх фактах: что будет, если один из них неверен, устарел или читается иначе? Эти факты перепроверьте по первоисточнику — сырым логам, выгрузке биллинга, а не чужому графику.
7. **Отчитайтесь по всем гипотезам.** В отчёте нужна относительная вероятность каждой гипотезы, а не только победителя. Тому, кто принимает решение, нужен запасной план на случай, если верной окажется менее вероятная гипотеза.
8. **Назовите вехи для наблюдения.** Заранее запишите, какие сигналы скажут, что события идут не по вашей версии. Хойер отмечает, что так потом сложнее «объяснить» неудобный факт и не менять вывод.

Хойер разделяет генерацию гипотез (шаг 1) и их оценку (шаги 3–5). Если смешать эти этапы, слабые на первый взгляд варианты отсекаются до того, как по ним успели собрать факты.

## Диагностичность: какие факты на самом деле что-то говорят

Диагностичность — это то, насколько факт помогает отличить одну гипотезу от другой: факт, который подходит ко всем версиям, ничего не говорит. У Хойера: «the extent to which any item of evidence helps the analyst determine the relative likelihood of alternative hypotheses».

Хойер объясняет это через медицину. Высокая температура хорошо говорит врачу, что пациент болен, но почти ничего не говорит о том, чем именно: она согласуется со слишком многими диагнозами.

В продукте «температура» — это сам факт падения. «Конверсия упала на неделе релиза» одинаково подходит к багу, сезонности, смене трафика и поломке трекинга. Такой факт ничего не различает, сколько бы раз его ни показывали на слайде.

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

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

Диагностичные факты, наоборот, должны определять вывод. Именно их Хойер просит перепроверять в первую очередь.

Если пометок «+» и «−» не хватает, Хойер предлагает для каждой клетки другой вопрос: если эта гипотеза верна, насколько вероятно, что я увижу этот факт? Это уже шаг к вероятностной оценке, но для разбора инцидента обычно достаточно трёх пометок.

## Пример матрицы ACH: конверсия упала после релиза

Ситуация условная: B2B SaaS, конверсия из регистрации в оплату в продуктовой аналитике резко просела. Что происходило вокруг:

- **Вторник.** Вышел релиз web-версии с новым онбордингом.
- **За две недели до релиза.** Поменяли цены на новом тарифе.
- **Четверг.** Маркетинг запустил новую рекламную кампанию.
- **Сезон.** Начало лета, июнь.

Команда почти единогласна: «новый онбординг сломал оплату».

Гипотезы:

- **H1.** Баг релиза мешает пользователям оплатить.
- **H2.** Сезонность.
- **H3.** Сменился состав трафика: новая кампания привела холодную аудиторию.
- **H4.** Пользователей отпугнула новая цена.
- **H5.** Сломался трекинг: оплаты есть, но событие оплаты в аналитику не доходит.

Обозначения: ✓ — факт согласуется с гипотезой, ✗ — противоречит, — — не относится.

| Факт | H1 баг | H2 сезон | H3 трафик | H4 цена | H5 трекинг |
| --- | --- | --- | --- | --- | --- |
| E1. Конверсия в аналитике упала на неделе релиза | ✓ | ✓ | ✓ | ✓ | ✓ |
| E2. Падение началось ступенькой в день релиза | ✓ | ✗ | ✗ | ✗ | ✓ |
| E3. Число оплат в биллинге почти не изменилось, разрыв с аналитикой вырос | ✗ | ✗ | ✗ | ✗ | ✓ |
| E4. Падение есть и в органике, и в прямых заходах | ✓ | ✓ | ✗ | ✓ | ✓ |
| E5. Падение только на web, приложение без изменений | ✓ | ✗ | ✓ | ✗ | ✓ |
| E6. Ошибок платёжного шлюза не прибавилось, в записях сессий оплата проходит | ✗ | — | — | — | ✓ |
| E7. В прошлые годы в июне конверсия проседала | — | ✓ | — | — | — |
| E8. Падение одинаково на старом и новом тарифе | ✓ | ✓ | ✓ | ✗ | — |
| **Итого ✗** | **2** | **3** | **3** | **4** | **0** |

**Шаг 3–4, диагностичность.** E1 согласуется со всеми гипотезами — это «температура», её убираем из матрицы в отдельный список. E4 работает только против H3, E8 — только против H4. Самый сильный факт — E3: его объясняет только поломка трекинга.

**Шаг 5, выводы.** Посмотрите на плюсы: даже без E1 у любимой гипотезы команды, H1, их четыре, у H5 — пять. Если считать подтверждения, гипотезы почти равны, и выбирают ту, в которую уже верят. По минусам картина другая: у H5 ни одного противоречия, у H1 — два, у остальных — три и больше.

Хойер прямо пишет: гипотеза с наименьшим числом минусов, вероятно, самая правдоподобная. Но сразу оговаривается, что это лишь грубое ранжирование: факты весят по-разному, а степень противоречия одной пометкой не передать.

Матрица не принимает решение за вас — она показывает, на чём держится ваше суждение.

**Шаг 6, чувствительность.** Вывод держится на E3 и E6. Что, если выгрузка биллинга приходит с задержкой и последние дни ещё не догружены? Тогда E3 рушится, и H1 возвращается в лидеры.

Значит, до любых действий аналитик сверяет сырые данные биллинга за две недели, а разработчик проверяет, уходит ли событие оплаты на стенде после релиза.

**Шаг 7, отчёт.** Текст для руководителя:

> «Наиболее вероятно — сломана отправка события оплаты (H5). Не исключён частичный реальный эффект релиза (H1): проверим после починки трекинга. H2, H3 и H4 не объясняют ступеньку в день релиза и маловероятны. Откат релиза сейчас не нужен».

**Шаг 8, вехи.** Если после починки события конверсия в аналитике за пару дней сравняется с биллингом — версия подтверждена. Если разрыв закроется, а конверсия останется ниже прошлого уровня, возвращаемся к H1 и смотрим воронку нового онбординга. Если в следующие недели просадка расползётся на приложение и органику — пересматриваем H2.

## Шаблон матрицы ACH

Матрицу можно вести в любой таблице. Минимальный набор колонок:

| Колонка | Что писать |
| --- | --- |
| Факт или допущение | Одна наблюдаемая вещь, с источником: дашборд, лог, выгрузка, интервью |
| Источник и надёжность | Откуда факт и можно ли ему доверять: сырые данные или чужой график |
| H1…H5 | ✓ согласуется, ✗ противоречит, — не относится |
| Диагностичность | Различает ли факт гипотезы: высокая, низкая, нет |
| Что проверить | Для ключевых фактов — как перепроверить по первоисточнику |

Заготовка, которую можно скопировать в документ разбора и заполнить:

```text
Вопрос: почему <метрика> упала с <дата>?
Допущения: <что считаем неизменным: «маркетинг ничего не менял», «сезонности нет»>

| Факт (источник; сырые данные или чужой график) | H1 <…> | H2 <…> | H3 <…> | H4 поломка трекинга | Диагностичность |
| E1 <…> (<лог/выгрузка>)                         | ✓/✗/—  | ✓/✗/—  | ✓/✗/—  | ✓/✗/—               | высокая/низкая/нет |
| E2 <…> (<лог/выгрузка>)                         | ✓/✗/—  | ✓/✗/—  | ✓/✗/—  | ✓/✗/—               | высокая/низкая/нет |
| Итого ✗                                         | <…>    | <…>    | <…>    | <…>                 |                    |

Недиагностичные факты (подходят ко всем гипотезам): <…>
Вывод по всем гипотезам: H<n> наиболее вероятна, потому что <…>; H<m> не исключена: <…>
Вывод держится на: E<…>, E<…> — перепроверить по <первоисточник>
Пересматриваем, если: <сигнал> до <дата>
```

Последние три строки — обязательная часть: вывод по всем гипотезам, ключевые факты, от которых он зависит, и вехи, при которых вывод пересматривают.

## Как руководителю попросить матрицу вместо одного объяснения

Метод не требует обучения команды. Достаточно поменять вопрос на разборе. Вместо «что случилось?» — «какие объяснения у нас есть и что против каждого?».

Сообщение в рабочий чат может выглядеть так: «Прежде чем откатывать, соберите, пожалуйста, матрицу: минимум четыре гипотезы, включая поломку трекинга, и факты по строкам. Мне важнее всего, что противоречит каждой версии». Последняя фраза — ключевая: она переводит команду с поиска подтверждений на поиск опровержений.

Вопросы, которые стоит задать, когда матрица готова:

- Какие гипотезы рассматривали и отбросили до матрицы — и почему?
- Если верна ваша главная версия, чего мы должны не видеть? Мы это проверили?
- Какой факт в матрице самый диагностичный? Откуда он и проверен ли по сырым данным?
- От каких двух фактов зависит вывод? Что будет, если один из них неверен?
- Что заставит нас передумать в ближайшие дни?

Красные флаги:

- **В матрице почти одни ✓.** Значит, искали подтверждения, а не опровержения.
- **Одна гипотеза плюс «прочее».** Генерация гипотез не состоялась.
- **«Доказательств нет» = «опровергнуто».** Хойер отдельно разделяет недоказанную и опровергнутую гипотезы: отсутствие следов поломки трекинга, если трекинг никто не проверял, ничего не опровергает. Пример из книги: перед ядерными испытаниями Индии в 1998 году разведсообщество сообщало, что признаков скорого испытания нет, и отсутствие признаков приняли за опровержение.
- **Ключевой факт — скриншот из чужого дашборда.** Его надо проверить первым.

## Где взять гипотезы: Исикава, команда и LLM

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

Для генерации хорошо подходит [диаграмма Исикавы](/blog/isikawa-diagram/): она раскладывает проблему по категориям и не даёт остановиться на первой причине. ACH начинается там, где Исикава заканчивается, — когда кандидатов несколько и надо выбрать.

Помогает и [дерево метрик](/blog/products-metrics-tree/). Если разложить упавшую метрику на составляющие, сразу видно, какие ветки могли её утянуть, и гипотезы получаются конкретнее.

LLM годится как ещё один участник брейншторма на шагах 1–2, если просить у неё не ответ, а альтернативы и проверяемые признаки. Готовый промт (он же лежит отдельным материалом — [«Альтернативные гипотезы для ACH»](/prompts/ach-alternativnye-gipotezy/)):

```text
Ты — аналитик, который помогает команде разобрать падение продуктовой метрики
методом анализа конкурирующих гипотез (ACH, Ричардс Хойер).

Ситуация: <описание ситуации: какая метрика, на сколько и с какой даты упала;
что менялось в продукте, маркетинге, ценах, трекинге>
Версия команды: <версия команды>
Данные, которые у нас есть: <дашборды, логи, выгрузки>

1. Предложи 4–6 альтернативных объяснений, кроме версии команды.
   Обязательно включи поломку трекинга или сбора данных.
2. Для каждой гипотезы, включая версию команды, напиши:
   — что мы должны увидеть в данных, если она верна;
   — чего мы не должны увидеть, если она верна;
   — где это проверить: конкретный отчёт, лог или выгрузка.
3. Назови 3–5 фактов, которые лучше всего различают гипотезы
   (одна гипотеза их предсказывает, другие нет), и отдельно —
   факты, которые подходят ко всем и ничего не различают.
4. Собери черновик матрицы: гипотезы по столбцам, факты по строкам,
   в клетках ✓ согласуется, ✗ противоречит, — не относится, ? нужны данные.

Правила:
— Не выдумывай данные и числа: всё, чего нет в описании, помечай «нужно проверить».
— Не выбирай победителя: твоя задача — расширить список и показать, что проверять.
— Если две гипотезы нечем различить, предложи их объединить.
```

Ответ — сырьё для обсуждения, а не факты: каждую гипотезу и каждый «ожидаемый признак» команда проверяет сама.

## Когда анализ конкурирующих гипотез не нужен

ACH требует времени, и Хойер сам рекомендует его для важных и спорных вопросов. Не стоит запускать метод, если:

- **Решение дешёвое и обратимое.** Если откат занимает десять минут и ничего не ломает, откат сам по себе быстрая проверка гипотезы.
- **Причина видна в одной строке лога.** Матрица ради формы — потеря времени.
- **Можно быстро поставить эксперимент.** Если A/B-тест или выключение фичи по флагу ответит за день, разбирать нечего.
- **Гипотез больше семи.** Хойер считает, что больше семи гипотез может быть неуправляемо, и предлагает сначала объединить их в группы.

Есть и ограничение самого метода: ACH исходит из того, что гипотезы — альтернативы. В продукте причины часто складываются: релиз немного ухудшил воронку, а кампания привела холодный трафик.

Поэтому формулируйте гипотезы как «основной вклад в падение» и не удивляйтесь, если в отчёте на шаге 7 окажутся две живые версии.

Что делать с выбранной версией дальше: если для проверки ключевого факта нужно отдельное исследование, сначала прикиньте [ценность информации](/blog/value-of-information-hubbard/) — окупится ли оно. А когда причина найдена и команда готовит исправление, перед запуском полезен [премортем](/blog/premortem-analiz-proval-do-zapuska/): представить, что фикс провалился, и выписать почему.

## Как внедрить ACH за неделю: чек-лист

- **День 1.** Возьмите последний инцидент или падение метрики, которое уже разобрали. Попросите аналитика собрать по нему матрицу задним числом и сравнить с принятым тогда решением.
- **День 2.** Скопируйте заготовку из раздела «Шаблон матрицы ACH» и положите её рядом с шаблоном постмортема.
- **День 3.** Договоритесь о правиле: при падении ключевой метрики решение об откате или фиксе принимают после матрицы минимум с четырьмя гипотезами. Поломка трекинга — обязательная гипотеза.
- **День 4.** Проверьте, что в шаблоне отчёта заполняются два поля: ключевые факты, от которых зависит вывод, и вехи для пересмотра.
- **День 5.** На ближайшем разборе задайте вопросы из чек-листа выше и посмотрите, на каких из них команда «плавает». Там и будет первая зона для работы.

## Частые вопросы

### Чем ACH отличается от «5 почему» и диаграммы Исикавы?

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

### Почему считают минусы, а не плюсы?

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

### Сколько гипотез брать в матрицу?

Правильного числа у Хойера нет: чем выше неопределённость и цена вывода, тем больше альтернатив стоит рассмотреть. Больше семи гипотез он считает трудноуправляемыми и советует объединять похожие. На практике (это совет статьи, а не Хойера) для разбора продуктовой метрики хватает четырёх-шести.

### Можно ли делать ACH в одиночку?

Можно, но первый шаг Хойер рекомендует проводить группой с разными точками зрения — в одиночку человек пропускает варианты. Разумный компромисс: аналитик собирает черновик матрицы, а гипотезы и спорные клетки обсуждают с разработкой, маркетингом и биллингом.

### Где прочитать первоисточник?

Глава 8 книги Ричардса Хойера «Psychology of Intelligence Analysis» (CIA, 1999). Книга бесплатно доступна в PDF на сайте ЦРУ, глава занимает около пятнадцати страниц и содержит пример матрицы.

## Источники

- Richards J. Heuer Jr. [*Psychology of Intelligence Analysis*](https://www.cia.gov/resources/csi/static/Pyschology-of-Intelligence-Analysis.pdf). CIA Center for the Study of Intelligence, 1999. Глава 8 «Analysis of Competing Hypotheses», с. 95–110; о диагностичности — также глава 4.