Фреймворки ICE и PIE: как мы приоритизируем гипотезы роста конверсии
Проблема, которую решают эти фреймворки
«Формулирование и приоритизация гипотез по фреймворку ICE/PIE» — отдельный пункт в том, что входит в CRO у нас. Причина, по которой приоритизация вообще нужна как отдельный шаг: на любом реальном сайте или в приложении почти всегда можно найти десятки потенциальных гипотез для теста — изменить текст кнопки, переставить блоки, сократить форму, поменять цвет CTA, изменить структуру страницы. Ресурсы команды и трафик сайта ограничены, а тестировать всё подряд одновременно и без приоритета — способ потратить месяцы, так и не добравшись до гипотез, которые реально повлияли бы на бизнес.
Как устроен ICE
ICE оценивает каждую гипотезу по трём параметрам: Impact (насколько сильно изменение потенциально повлияет на целевую метрику), Confidence (насколько мы уверены в этом эффекте — на основе данных, а не догадки) и Ease (насколько просто и быстро реализовать и протестировать изменение). Каждый параметр оценивается по простой шкале, а итоговый балл — их произведение или сумма (в зависимости от версии методики) — даёт относительное ранжирование гипотез. Гипотеза с высоким потенциальным эффектом, но крайне низкой уверенностью и высокой сложностью реализации, закономерно уходит вниз списка, даже если звучит соблазнительно на словах.
Как устроен PIE и когда мы используем его вместо ICE
PIE оценивает страницу или элемент по Potential (насколько велик потенциал улучшения именно здесь), Importance (насколько эта страница важна с точки зрения трафика и вклада в конверсию) и Ease (та же логика простоты реализации). PIE удобнее, когда решение — не «какую гипотезу тестировать», а «на какой странице вообще стоит фокусироваться в первую очередь», то есть на уровне выше отдельной гипотезы. Мы используем оба фреймворка на разных этапах: PIE — чтобы выбрать приоритетные страницы или экраны, ICE — чтобы внутри выбранной страницы ранжировать конкретные гипотезы.
Как это выглядело на практике
В CRO-спринте «Домашнего доктора» после релиза редизайна мы тестировали сразу несколько направлений: 5 вариантов формы записи, расположение блока «онлайн-консультация», отдельную доработку мобильной версии. Такое количество параллельных направлений требует именно приоритизации — иначе команда физически не может грамотно распределить время между гипотезами с разной ожидаемой отдачей. Форма записи получила наивысший приоритет по ICE именно потому, что аудит уже показал: 40% заявок терялись именно на этом шаге, — то есть Impact и Confidence здесь были объективно выше, чем у менее очевидных гипотез.
Что это даёт клиенту
Приоритизация по фреймворку — не бюрократия ради отчётности, а прозрачный способ объяснить клиенту, почему мы тестируем именно эту гипотезу в этот момент, а не любую другую из длинного списка идей. Это также защищает от ситуации, когда решение о том, что тестировать, принимается по громкости мнения внутри команды или клиента, а не по объективной оценке потенциального эффекта.
Вернуться в блог.