MQL упали на 30% за месяц. Команда решает, что дело в рекламном креативе, три недели переписывает объявления - а цифра не восстанавливается, потому что причина была не в рекламе. Это не редкий случай, это стандартный сценарий диагностики в маркетинге: гипотеза выбирается по интуиции и опыту, а не проверяется против остальных вариантов. MECE и Issue Tree, или дерево вопросов, - метод из управленческого консалтинга (связан с McKinsey, формализован Барбарой Минто в «Принципе пирамиды»), который решает именно эту проблему. Он не даёт начать работу над гипотезой, пока не исключены остальные ветки.
Почему интуитивная диагностика чаще всего ошибается
У любого падения метрики есть несколько кандидатов на причину. Проблема не в том, что команда не думает - проблема в том, что она думает об одном кандидате сразу, обычно самом заметном или самом обсуждаемом на последней встрече. Если на прошлой неделе меняли креатив, первое подозрение падает на креатив. Если недавно переделывали лендинг, подозревают лендинг.
Дальше происходит то, что можно назвать туннельным зрением: гипотеза проверяется в изоляции, без сравнения с альтернативами. Если она хотя бы частично подтверждается («да, CTR на новом креативе чуть ниже»), команда считает вопрос закрытым и тратит спринт на исправление. Метрика не восстанавливается - потому что реальная причина сидела в ветке, которую никто даже не сформулировал, не то что проверил.
Что такое MECE и Issue Tree
MECE расшифровывается как Mutually Exclusive, Collectively Exhaustive - взаимоисключающие и совместно исчерпывающие категории. Когда проблема разбивается на части по этому принципу, части не пересекаются между собой и в сумме покрывают весь возможный объём проблемы, без пробелов.
Issue Tree - практический инструмент поверх этого принципа. Вместо того чтобы формулировать одну причину, вы строите дерево: наверху - исходный вопрос («почему упали MQL»), на первом уровне - MECE-разбиение возможных направлений причины, на втором уровне каждая ветка разбивается дальше, и так до тех пор, пока ветка не сведётся к чему-то, что можно проверить напрямую по данным.
Смысл не в том, чтобы дерево было красивым. Смысл в том, что оно не даёт пропустить ветку. Пока не проверены все ветки одного уровня, ни одна не признаётся причиной - даже если она выглядит убедительно.
Как выглядит дерево вопросов на примере падения MQL
Возьмём тот же случай: MQL упали на 30% месяц к месяцу. MQL - это произведение количества посетителей на конверсию из посетителя в MQL. Значит первый уровень разбиения ровно два варианта, и вместе они покрывают все возможные причины падения без пересечения:
- Стало меньше посетителей
- Платный трафик упал
- Органический трафик упал
- Остальные каналы упали (реферальный, прямой, email, соцсети)
- Посетителей столько же, но конверсия в MQL упала
- Проблема на лендинге (меньше людей доходит до формы)
- Проблема с самой формой (техническая ошибка, лишние поля, сбой при отправке)
- Изменился порог оценки лидов или качество приходящего трафика (форму заполняют, но лид не квалифицируется как MQL)
Это ещё не готовые выводы - это список вопросов, каждый из которых можно закрыть одним запросом к данным. «Платный трафик упал» проверяется в GA4 или в рекламном кабинете за 30 секунд. «Изменился порог оценки лидов» проверяется в CRM: смотрите, менялись ли правила оценки лидов за этот период, и сравниваете объём квалифицированных лидов при старых и новых правилах на одном и том же входящем трафике.
Команда, которая сразу решила, что дело в креативе, скорее всего вообще не дошла до правой ветки дерева - потому что не сформулировала её как отдельный вопрос.
Как проверять ветки данными, а не мнением
Правило простое: ветка закрывается числом, а не мнением. «Кажется, лендинг стал хуже конвертировать» - это не проверка, это осталась та же интуитивная гипотеза, только оформленная как пункт списка. Проверка выглядит так: берёте конверсию из посетителя в заполненную форму за текущий период и за период до падения, сравниваете число к числу.
Дальше идёт тот же принцип на уровень глубже: если конверсия на лендинге действительно упала, спрашиваете, что именно изменилось за этот период - сам лендинг, источник трафика, который на него приходит, устройство, с которого заходят. Опять MECE-разбиение, опять проверка по данным, а не предположение.
Практическая сложность в том, что GA4 и CRM редко сходятся в одной картине: GA4 показывает поведение до формы, а CRM - что происходит с лидом после отправки. Команда либо тратит день на ручную сверку экспортов, либо пропускает часть веток дерева просто потому, что до них неудобно добраться. Инструменты вроде Prooflytics, которые соединяют трафик из GA4 с воронкой в CRM в одной панели, убирают именно это узкое место - проверка каждой ветки занимает минуты, а не отдельную задачу на день.
Что мешает применять этот метод на практике
Главное препятствие не техническое, а дисциплинарное. Issue Tree требует признать, что у команды пока нет ответа - а под давлением («метрика упала, нужно объяснение к понедельнику») куда проще предложить правдоподобную гипотезу и начать её чинить. Дерево выглядит как лишний шаг, который замедляет реакцию.
На деле он её ускоряет. Спринт, потраченный на исправление не той причины, - это не нейтральная задержка, это потерянное время плюс метрика, которая продолжает падать, пока команда занята не тем. Час на то, чтобы явно выписать MECE-ветки и проверить каждую по реальным цифрам, обходится дешевле, чем цикл «почини - подожди - не сработало - почини другое».
Дерево вопросов не заменяет экспертизу маркетолога - оно не подсказывает, какая ветка окажется верной. Оно просто не даёт закрыть расследование раньше, чем проверены все MECE-варианты, а не только тот, что пришёл в голову первым.