Если ваша команда не может договориться, какой A/B-тест запустить следующим — скорее всего, у вас нет системы приоритизации. ICE, PIE и PXL — три проверенных фреймворка, которые превращают споры в данные и помогают выбирать правильные тесты в правильное время.
Почему важна приоритизация тестов
Один A/B-тест занимает от 2 до 4 недель. Если в квартале вы успеваете запустить 12 тестов — это весь ваш ресурс. Выбрать не те тесты значит потерять три месяца впустую.
Без системной приоритизации команды сталкиваются с типичными проблемами:
- HiPPO-синдром — побеждает мнение самого высокооплачиваемого сотрудника, а не данные.
- Предвзятость новизны — запускается то, что предложили последним.
- «Кто громче» — тест получает тот стейкхолдер, который настойчивее требует.
- Приоритет простоты — берут то, что проще реализовать, а не то, что важнее.
Хороший фреймворк убирает политику из процесса и даёт обоснованный ответ на вопрос: «Почему именно этот тест?»
Фреймворк ICE: простота и скорость
ICE расшифровывается как Impact, Confidence, Ease (Влияние, Уверенность, Простота). Фреймворк популяризировал Шон Эллис — один из основоположников концепции growth hacking.
Формула: ICE Score = Impact × Confidence × Ease
Каждый параметр оценивается по шкале от 1 до 10, затем три значения перемножаются. Итоговый диапазон — от 1 до 1000.
- Impact — насколько сильно тест повлияет на целевую метрику при победе?
- Confidence — насколько вы уверены, что тест даст результат?
- Ease — насколько просто реализовать и запустить тест?
Пример: тест «Добавить значки доверия под кнопкой «Купить»»: Impact 6 × Confidence 8 × Ease 9 = 432 балла.
Когда использовать ICE: молодые CRO-программы (менее 6 месяцев), небольшие команды, ситуации, когда нужно быстро расставить приоритеты без сложной аналитики, а также когда к обсуждению подключаются нетехнические стейкхолдеры.
Слабое место ICE: высокая субъективность. «8» у аналитика и «8» у дизайнера могут означать совершенно разные вещи.
Фреймворк PIE: фокус на страницах и воронке
PIE расшифровывается как Potential, Importance, Ease (Потенциал, Важность, Простота). Фреймворк разработал Крис Говард из агентства Conversion специально для CRO-команд.
Формула: PIE Score = (Potential + Importance + Ease) ÷ 3
Каждый параметр оценивается от 1 до 10, итог — среднее значение в диапазоне от 1 до 10.
- Potential — насколько большой потенциал для улучшения есть на этой странице?
- Importance — насколько ценен трафик на этой странице (объём, доход)?
- Ease — насколько просто провести этот тест?
Пример: тест «Редизайн страницы оформления заказа с индикатором прогресса»: Potential 8 + Importance 10 + Ease 5 = 23 ÷ 3 = 7,67 балла.
Когда использовать PIE: оптимизация воронки конверсии, наличие чёткой аналитики по проблемным страницам, 1–2 года опыта в CRO, агентства, ведущие несколько клиентов.
Слабое место PIE: фактор «Potential» сложно оценить без опыта — джуниоры часто ошибаются с этим параметром.
Фреймворк PXL: объективность для зрелых команд
PXL (произносится «пиксел») создан командой CXL Institute. Это наиболее строгий из трёх фреймворков: вместо субъективных оценок он использует бинарные вопросы и взвешенные факторы.
Формула: PXL Score = сумма всех бинарных и взвешенных факторов
Бинарные вопросы (по 2 балла за «да»):
- Изменение находится выше линии сгиба?
- Изменение заметно в течение 5 секунд?
- Тест добавляет или убирает элементы?
- Тест запускается на страницах с высоким трафиком?
Взвешенные факторы (1–5 баллов каждый):
- Простота реализации
- Наличие пользовательских данных или исследований
Пример: тест «Замена главного изображения на видео о продукте на главной странице»: все 4 бинарных вопроса — «да» (+8), Ease 3/5, Data support 4/5 = 15 баллов.
Когда использовать PXL: зрелые CRO-программы (10+ тестов в квартал), наличие пользовательских исследований, требования к задокументированным критериям принятия решений, команды, стремящиеся минимизировать субъективность.
Слабое место PXL: высокий порог входа. Новым членам команды нужно обучение, а малым командам фреймворк может оказаться избыточным.
ICE vs PIE vs PXL: сравнительная таблица
| Параметр | ICE | PIE | PXL |
|---|---|---|---|
| Метод подсчёта | Произведение (1–10) | Среднее (1–10) | Сумма (бинарные + взвешенные) |
| Субъективность | Высокая | Средняя | Низкая |
| Сложность освоения | Низкая | Средняя | Высокая |
| Время на оценку | 2–3 минуты | 3–5 минут | 5–10 минут |
| Лучше всего подходит | Стартапы, growth-команды | CRO-команды, агентства | Enterprise CRO |
| Требования к данным | Минимальные | Базовая аналитика | Аналитика + пользовательские исследования |
Как выбрать подходящий фреймворк
Лучший фреймворк — тот, который ваша команда будет реально использовать на постоянной основе.
Выбирайте ICE, если:
- CRO-программа существует менее 6 месяцев
- В бэклоге менее 20 идей для тестов
- В приоритизации участвуют нетехнические стейкхолдеры
- Нужны быстрые решения без глубоких данных
Выбирайте PIE, если:
- Фокус — на оптимизации воронки конверсии
- Есть чёткая аналитика по проблемным страницам
- Команда имеет 1–2 года опыта в CRO
- Вы управляете несколькими сайтами или клиентами
Выбирайте PXL, если:
- Программа запускает 10+ тестов в квартал
- Есть выделенные ресурсы на пользовательские исследования
- Стейкхолдеры требуют задокументированных критериев
- Нужно снизить субъективность в оценках
Гибридный подход: многие зрелые команды комбинируют фреймворки. Например, используют ICE для первичного отбора всего бэклога, а затем применяют критерии PXL к топ-10 кандидатам — так удаётся сбалансировать скорость и строгость.
Типичные ошибки при приоритизации (и как их избежать)
Несогласованность оценок. Разные члены команды трактуют баллы по-разному. Решение: создайте рубрики с чёткими определениями — что означает оценка 1, 5 и 10 для каждого параметра.
Оценка в одиночку. Индивидуальные оценки скрывают разногласия, которые важно обсудить. Решение: оценивайте тесты совместно. Если мнения расходятся на 3+ балла — это сигнал к дискуссии.
Игнорирование исторических данных. «Уверенность» оценивается интуитивно, а не на основе реального процента побед. Решение: отслеживайте win rate по типам тестов и корректируйте оценки Confidence.
Устаревшие оценки. Тест, оценённый полгода назад, может быть уже неактуален. Решение: пересматривайте топ-20 тестов ежеквартально.
Слепое следование рейтингу. Оценки — это инструмент, а не приговор. Решение: используйте баллы как вводные, но учитывайте стратегический контекст: блокирующие зависимости, запуски продуктов, стратегические гипотезы.
Как выстроить процесс приоритизации
Фреймворк сам по себе не решит проблему. Нужен процесс вокруг него.
- Создайте баллы оценок. Для каждого параметра пропишите, что означает 1, 5 и 10 — с конкретными примерами.
- Проводите регулярные сессии оценки. Выделяйте 1–2 часа еженедельно или раз в две недели для работы с бэклогом.
- Сравнивайте прогнозы с результатами. После каждого теста фиксируйте, насколько реальный результат совпал с прогнозом. Команды, которые делают это системно, повышают точность прогнозов на 40% за 6 месяцев.
- Визуализируйте приоритизированный бэклог. Таблица с колонкой «Score» сложна для восприятия. Используйте визуальные роадмапы, отсортированные по приоритету.
Прокачка приоретизации через GIST + MoSCoW
Все эти очкования (указание очков) для задач — хорошо. Однако сами по себе эти оценки работают не всегда.
Мой опыт показал что они хорошо работают в связке с методиками GIST + MoSCoW:
- GIST — позволяет в целом завязать бэклог идей и задач с целями и проектами
- MoSCoW — позволяет лучше сгруппировать длинные списки в более четкие ограниченные шорт листы: Must, Should, Could …
Пример как это работает для Agile разработки продукта в долгую:
- собираем цели, проекты, задачи и идеи в единую связку — например в Notion, GitHub, Джира или Конфа
- затем идеи и задачи — группируем по приоритетам MoSCow — Must это топ 3 самые важные задачи, Should — 10 других хороших задач на подготовке и проработке, Could хорошие идеи — которые должны лежать на глазах, но пока не тратимся (пусть будет шорт лист 20 штук)
Внутри этой таблицы или бэклога можно добавлять поля про очки — ICE vs PIE vs PXL. Можно выбрать одну методику, а можно хоть все 3 вместе взятые.
Далее оцениваем и видим какие идеи поднимаются вверх по списку, а какие оседают внизу.
Основной фокус в топ 3 идеи/задачи/проекта — остальное на подхвате/проработке.
Лимиты и шорт листы настраиваются по вкусу и исходя из имеющихся ресурсов. Можно настроить хоть под 1го человека, хоть под 10 команд из 100 человек.
