Начните с критериев принятия решения после редизайна
Разбор редизайна работает только тогда, когда вы сначала определяете, какое именно решение нужно принять. Задайте один простой вопрос: новая версия сделала продукт удобнее, сложнее или просто другим?
Это звучит банально, но экономит часы. Если у главной страницы новый макет, новая навигация и новый сценарий регистрации, не стоит считать все показатели дашборда одинаково важными. Выберите 2–3 результата, которые важнее всего для этого запуска, а затем решите, какие метрики — это сигнал, а какие — шум.
Для редизайна оформления checkout сигналом могут быть конверсия до завершения, отвал на шагах и количество ошибок. Для контентного сайта сигналом могут быть глубина чтения статьи, внутренние клики и возвраты пользователей. Визуальное изменение требует одного взгляда, а изменение сценария работы — другого, и дашборд должен это отражать.
Полезная привычка — записать критерии принятия решения до запуска. Например: «Если мобильная конверсия упадёт больше чем на заданный порог, редизайну нужен ещё один проход». Так у вас появляется порог, а не просто ощущение, что особенно полезно, когда команда начинает спорить о вкусе.
Часто спрашивают, какие показатели смотреть после редизайна, и лучший ответ — не «все». Смотрите на те метрики, которые соответствуют поведению, которое редизайн должен был изменить, потому что именно так понятнее, как оценить редизайн сайта без лишнего шума.
Выберите правильное окно сравнения и набор страниц
Используйте одни и те же шаблоны страниц или пользовательские сценарии до и после запуска. Если сравнивать новую главную страницу со старой страницей продукта, вывод будет бесполезным. Набор страниц должен соответствовать масштабу редизайна.
Также выберите стабильное окно. Первый день после запуска может быть шумным из-за кеша, возвратных пользователей, репостов ссылок и тестов сотрудников. Окно в 7 или 14 дней часто лучше, чем один утренний срез, но правильный период зависит от вашей динамики трафика и графика релизов.
По возможности выравнивайте периоды до и после по дням недели. Поведение в понедельник не такое, как в субботу. У магазина может быть всплеск в выходные; у B2B-продукта — нет. Если сравнить неправильные дни, дашборд соврёт без всякого умысла.
Следите за смещением в определениях метрик. Если какое-то событие переименовали, перетегировали или перенесли во время редизайна, отметьте это до сравнения со старой версией. Гладкий график всё равно может измерять уже не то же самое.
Используйте одни и те же единицы измерения и один и тот же охват. Если Astrina показывает метрики на уровне страниц, не смешивайте их с метриками на уровне сессий и не называйте это итогом редизайна. Именно так команды празднуют победу, которой на самом деле не было.
Проверьте показатели, которые показывают качество пользовательского опыта
Самые полезные показатели — те, которые описывают, как люди почувствовали редизайн на практике. Начните с конверсии по основной задаче. Если редизайн должен был ускорить регистрацию, дашборд должен показать, стало ли больше людей действительно завершать её.
Смотрите на время прохождения шага, если Astrina его отслеживает. Более короткий путь не всегда лучше, но заметное замедление обычно означает трение. Возможно, кнопка ушла ниже первого экрана. Возможно, поле формы стало труднее заметить. Небольшие изменения могут создавать большие задержки.
Показатель ошибок важен, когда редизайн затрагивает формы, фильтры или шаги оплаты. Поток в один клик, который даёт больше некорректных отправок, — это не успех. Люди замечают путаницу раньше, чем начинают жаловаться.
Глубина прокрутки, внутренние клики и повторяющееся метание туда-сюда могут помочь, но только если они связаны с известным действием. Редизайн, который добавляет больше кликов, всё ещё может работать, если дополнительный шаг понятен. А вот редизайн, который увеличивает rage clicks, — это уже другая история, и дашборд обычно это показывает.
Не переоценивайте один показатель отказов или выходов. Одна страница может выглядеть хуже просто потому, что новый макет быстрее даёт пользователю ответ. Это нормальный результат, а не провал.
Есть разница между «меньше активности» и «меньше путаницы». Показатель на дашборде, который падает на 12%, может быть хорошим, если теперь пользователи быстрее находят ответ.
Сравнивайте поведение по устройствам, макетам и ключевым сегментам аудитории
Редизайн редко влияет на всех одинаково. Пользователям на десктопе может понравиться более плотный макет, а на мобильных — мешать отступы или скрытые элементы управления. Это обычная ситуация, и дашборд должен быстро её показать.
Сначала разбейте данные по устройствам. Мобильный трафик заслуживает особого внимания, потому что изменения в макете могут повлиять на доступность кнопок для большого пальца, перенос текста и расположение основных действий. Если мобильная версия теряет конверсию, а десктопная улучшается, редизайн не сломан везде — он сломан в одном месте.
Затем разделите новых и возвращающихся пользователей. Новые пользователи не знают старый интерфейс, поэтому часто адаптируются иначе. Возвращающиеся пользователи могут негативно реагировать на новую навигацию или перенесённую кнопку, потому что уже выучили прежний сценарий.
Имеют значение и каналы привлечения. Посетители из платного поиска часто приходят с конкретным намерением. Аудитория из email может уже знать бренд. Редизайн может улучшить одну аудиторию и ухудшить другую, и оба результата могут быть верны одновременно.
Внимательный разбор должен проверить и основные точки входа. Редизайн страницы продукта может помочь трафику из соцсетей, но навредить прямому трафику, если возвращающиеся пользователи не могут найти прежний короткий путь. Это не теоретический риск — такое случается достаточно часто, чтобы заслужить отдельную строку в дашборде.
Если один сегмент резко меняется, а остальные почти не двигаются, не усредняйте результат до неузнаваемости. Среднее значение может скрыть реальную проблему для части пользователей.
Проверьте согласованность шагов воронки в Astrina
Используйте Astrina, чтобы сравнить порядок действий до и после редизайна. Важно не только то, завершили ли пользователи воронку, но и сохраняется ли прежняя последовательность шагов.
Предположим, раньше воронка выглядела так: просмотр товара, добавление в корзину, доставка, оплата. Если после редизайна пользователи начинают открывать детали доставки до того, как что-то добавили в корзину, это проблема сценария. Воронка всё ещё может заканчиваться покупкой, но путь становится менее понятным.
Проверьте шаг, на котором появляется самый большой отток. Если отток сместился раньше, редизайн мог внести путаницу прямо в начале сценария. Если он сместился позже, возможно, ранние шаги стали проще, но появился новый барьер ближе к завершению.
Небольшие изменения на шаге могут быть важнее крупных изменений в сумме. Изменение на 5% на первом шаге часто важнее, чем 1% на последнем, потому что раннее трение накапливается. Поэтому согласованность шагов заслуживает отдельного анализа.
Следите за повторяющимися циклами. Если пользователи возвращаются с шага 3 на шаг 1, это не всегда плохо, но если таких циклов стало больше после запуска, значит, редизайн, вероятно, сделал путь к решению менее ясным. Люди не движутся по воронке идеально ровно.
Практическая проверка: если воронка стала короче, а конверсия упала, редизайн мог убрать полезную подсказку. Короче — не значит автоматически лучше.
Ищите на дашборде аномалии, связанные с трекингом или изменениями интерфейса
Не каждое изменение на дашборде — поведенческое. Иногда редизайн просто ломает измерение. Переименование страницы, перенос кнопки или задержка события могут создать ложное падение или мнимый рост.
Начните с пропавших событий. Если на день запуска шаг исчез с дашборда, спросите себя, перестало ли действие происходить или перестал срабатывать трекинг. Разница принципиальна.
Дальше ищите дублированные события. Редизайн может случайно отправлять один и тот же клик дважды, если компонент смонтирован дважды или скрипт срабатывает и на десктопном, и на мобильном брейкпоинте. Это может раздувать активность и делать слабый сценарий лучше, чем он есть на самом деле.
Ещё одна ловушка — переименованные просмотры страниц. Если изменилась структура URL, дашборд, который группирует по названию страницы, может разделить одну страницу на две. Тогда вы увидите две посредственные страницы вместо одной стабильной. Данные не стали хуже — просто изменились подписи.
Изменения в интерфейсе также могут менять смысл событий. Если основное действие перенесли с кнопки на тап по карточке, старое событие может по-прежнему срабатывать, но уже не отражать то же намерение.
Если нужна помощь с шумом инфраструктуры во время запуска, посмотрите что делать, когда падает uptime Astrina. Редизайн и сбой могут выглядеть на графике одинаково. Это не очень приятная игра в угадайку.
Сравнение рядом: что изменилось, что осталось стабильным, что требует доработки
Таблица рядом заставляет соблюдать дисциплину. Она не даёт команде спорить общими словами и помогает быстрее увидеть, какие метрики заслуживают ещё одного цикла работы.
| Показатель дашборда | До редизайна | После редизайна | Интерпретация |
|---|---|---|---|
| Завершение основной задачи | Стабильный базовый уровень | Текущий базовый уровень | Улучшилось, ухудшилось или осталось без изменений |
| Отток на ключевом шаге воронки | Стабильный базовый уровень | Текущий базовый уровень | Следите за более ранними потерями |
| Мобильная конверсия | Стабильный базовый уровень | Текущий базовый уровень | Часто первое место, где редизайн начинает давать сбой |
| Десктопная конверсия | Стабильный базовый уровень | Текущий базовый уровень | Может улучшиться, даже если мобильная версия просела |
| Повторяющееся возвратное поведение | Стабильный базовый уровень | Текущий базовый уровень | Сигнализирует о путанице, если растёт |
| Количество событий по основному CTA | Стабильный базовый уровень | Текущий базовый уровень | Проверьте, нет ли дублирования трекинга |
Эта таблица не должна делать вид, что знает больше, чем знает на самом деле. Если определения изменились, укажите это в строке. Если редизайн изменил саму воронку, отметьте, что сравнение до/после не является чистым измерением. Чёткие формулировки здесь особенно важны.
Полезный подход — отмечать каждую строку как зелёную, жёлтую или красную только после того, как сырые данные стабилизировались. Таблица, заполненная слишком рано, может подтолкнуть команду к удобной, но неверной истории вместо правильной.
Честный вердикт: когда редизайн работает, даёт смешанные результаты или требует отката
Редизайн работает, когда дашборд показывает улучшение основной задачи, ключевая воронка сохраняется, а проблемные сегменты не проваливаются резко вниз. Одного сильного сегмента недостаточно. Важно, чтобы результат держался там, где продукт используется чаще всего.
Редизайн даёт смешанные результаты, когда на десктопе есть рост, а на мобильных устройствах — просадка, или когда конверсия растёт, но пользователям требуется больше времени на завершение. Это не означает провал по умолчанию. Это значит, что редизайн решил одну проблему и создал другую.
Откат стоит всерьёз обсуждать, когда дашборд показывает явное ухудшение в основной функции, особенно если одна и та же проблема видна в нескольких сегментах и трекинг выглядит чистым. Если и мобильная, и десктопная версии просели, а форма воронки изменилась в одном и том же направлении, не тяните с решением.
Иногда редизайн выглядит успешным в сумме, но всё равно требует точечной доработки. Так бывает, когда один сегмент даёт основную долю трафика, а небольшой сегмент сильно проседает. Широкое среднее может скрывать такой перекос на несколько дней.
Поэтому настоящий ответ — не одна цифра. Это набор признаков: стабильные измерения, одно и то же окно сравнения, понятные шаги воронки и одна-две метрики, которые доказывают, что редизайн сделал то, что обещал. Если эти показатели не совпадают, дашборд говорит вам продолжать работу.
