Почніть із критеріїв рішення після редизайну
Оцінка редизайну має сенс лише тоді, коли ви спочатку визначите, яке рішення потрібно ухвалити. Поставте одне просте запитання: нова версія зробила продукт зручнішим, менш зручним чи просто іншим? Саме так і починається відповідь на запитання як оцінити редизайн за метриками.
Це звучить очевидно, але економить години. Якщо головна сторінка отримала нову структуру, нову навігацію та новий флоу реєстрації, не варто вважати всі цифри на дашборді однаково важливими. Оберіть 2–3 результати, які найбільше мають значення для цього запуску, а потім вирішіть, які показники є сигналом, а які — шумом.
Для редизайну оформлення замовлення сигналом можуть бути рівень завершення, відсів на кроках і частота помилок. Для контентного сайту — глибина перегляду статей, внутрішні переходи та повторні візити. Косметична зміна потребує іншого погляду, ніж зміна робочого процесу, і дашборд має відображати цю різницю.
Корисна звичка — прописати критерії рішення ще до запуску. Наприклад: «Якщо на мобільних пристроях рівень завершення впаде більше ніж на заданий поріг, редизайн потребує ще одного проходу». Це дає вам поріг, а не просто відчуття, що особливо корисно, коли команда починає сперечатися про смак.
Часто запитують, які саме цифри на дашборді Astrina варто відстежувати після редизайну, і найкраща відповідь — не «все підряд». Це ті показники, які відповідають поведінці, яку редизайн мав змінити, тобто саме метрики після редизайну сайту, а не будь-яка випадкова статистика.
Оберіть правильне вікно порівняння та набір сторінок
Використовуйте ті самі шаблони сторінок або ті самі шляхи користувача до й після запуску. Якщо ви порівнюєте нову головну сторінку зі старою сторінкою продукту, результат буде беззмістовним. Набір сторінок має відповідати масштабу редизайну.
Також оберіть стабільне вікно. Перший день після запуску може бути «шумним» через ефекти кешу, повернення користувачів, поширення посилань і тестування співробітниками. 7-денне або 14-денне вікно часто кращі за один ранок, але правильний вибір залежить від вашого трафіку та графіка релізів.
По можливості вирівнюйте періоди «до» і «після» за днями тижня. Понеділок поводиться не так, як субота. Магазин може бачити сплеск у вихідні; B2B-продукт — ні. Якщо порівняти не ті дні, дашборд покаже хибну картину без жодного злого наміру.
Слідкуйте за дрейфом визначень метрик. Якщо під час редизайну подію перейменували, перетегували або перенесли, зафіксуйте це до порівняння зі старою версією. Діаграма може виглядати акуратно, але все одно вимірювати вже іншу річ.
Використовуйте ті самі одиниці виміру та той самий обсяг. Якщо Astrina показує дані на рівні сторінки, не змішуйте їх із даними на рівні сесії й не називайте це висновком про редизайн. Саме так команди починають святкувати перемогу, якої насправді не було.
Перевірте цифри на дашборді, що показують якість користувацького досвіду
Найкорисніші показники — ті, що описують, як люди відчули редизайн у дії. Почніть із рівня завершення основного завдання. Якщо редизайн мав пришвидшити реєстрацію, дашборд має показати, чи справді більше людей її завершили.
Перегляньте час виконання кроків, якщо Astrina його відстежує. Коротший шлях не завжди кращий, але різке уповільнення зазвичай означає тертя. Можливо, кнопка перемістилася нижче першого екрана. Можливо, поле форми стало менш помітним. Невеликі зміни можуть створювати великі затримки.
Частота помилок важлива, коли редизайн змінює форми, фільтри або етапи оплати. Потік у один клік, який генерує більше некоректних відправок, — це не успіх. Люди помічають плутанину ще до того, як скаржаться на неї.
Глибина прокрутки, внутрішні переходи та повторна поведінка «туди-сюди» можуть допомогти, але лише якщо вони пов’язані з відомою дією. Редизайн, який додає більше кліків, усе ще може працювати, якщо додатковий крок зрозумілий. А от редизайн, що збільшує кількість агресивних кліків, — це вже інша історія, і дашборд зазвичай це показує.
Не робіть поспішних висновків лише на основі одного показника відмов або виходів. Одна сторінка може виглядати гірше просто тому, що новий макет швидше дає відповідь користувачеві. Це нормальний результат, а не провал.
Є різниця між «меншою активністю» та «меншою плутаниною». Показник на дашборді, що впав на 12%, може бути хорошою новиною, якщо тепер користувачі отримують відповідь швидше.
Порівняйте поведінку за пристроями, макетом і ключовим сегментом аудиторії
Редизайн рідко впливає на всіх однаково. Користувачам на десктопі може подобатися щільніший макет, тоді як мобільні користувачі стикаються з проблемами через інтервали або приховані елементи керування. Такий розрив трапляється часто, і дашборд має показати його швидко.
Насамперед розбийте дані за типом пристрою. Мобільні пристрої заслуговують на особливу увагу, тому що зміни в макеті можуть впливати на доступність великим пальцем, перенесення рядків і розташування основних дій. Якщо мобільна версія втрачає завершення, а десктоп покращується, редизайн не зламався всюди — він зламався в одному місці.
Далі розділіть нових і повторних користувачів. Нові користувачі не мають пам’яті про старий інтерфейс, тому часто адаптуються інакше. Повернуті користувачі можуть негативно реагувати на змінену навігацію або перенесену кнопку, бо вже вивчили старий патерн.
Важливі й канали залучення. Відвідувачі з платного пошуку часто приходять із чітким наміром. Аудиторія email-розсилки може вже знати бренд. Редизайн може покращити один сегмент і погіршити інший, і обидва результати можуть бути правдивими одночасно.
Уважний огляд також має перевірити основні точки входу. Редизайн сторінки продукту може допомогти трафіку із соцмереж, але нашкодити прямому трафіку, якщо користувачі, які повернулися, не можуть знайти той самий скорочений шлях. Це не теоретичний ризик; таке трапляється досить часто, щоб варто було виділити цьому окремий рядок на дашборді.
Якщо один сегмент змінюється різко, а інші майже не рухаються, не «згладжуйте» результат середнім значенням. Середнє може приховати реальну проблему для частини користувачів.
Перевірте узгодженість кроків воронки в Astrina
Використовуйте Astrina, щоб порівняти порядок дій до і після редизайну. Сенс не лише в тому, чи завершили користувачі воронку, а й у тому, чи рухалися вони через неї в тому самому порядку.
Припустімо, стара воронка виглядала так: перегляд товару, додавання в кошик, доставка, оплата. Якщо редизайн змушує користувачів відкривати деталі доставки ще до того, як вони щось додали в кошик, це проблема потоку. Воронка може все одно завершуватися покупкою, але шлях стає менш зрозумілим.
Перевірте крок, на якому з’являється найбільший відсів. Якщо відсів змістився раніше, редизайн міг додати плутанину на самому початку потоку. Якщо ж він змістився пізніше, можливо, ранні кроки стали простішими, але з’явилась нова точка тертя ближче до фінішу.
Невеликі зміни на кроках можуть мати більше значення, ніж великі загальні підсумки. Зміна на 5% на першому кроці часто важливіша за зміну на 1% на останньому, бо раннє тертя накопичується. Саме тому узгодженість кроків заслуговує на окремий перегляд.
Слідкуйте за повторними циклами. Якщо користувачі переходять із кроку 3 назад на крок 1, це не завжди погано, але якщо після запуску такий цикл став частішим, редизайн, ймовірно, зробив шлях прийняття рішення менш зрозумілим. Люди не «відскакують» у чітких шаблонах.
Одна практична перевірка: якщо воронка виглядає коротшою, а завершення впало, редизайн міг прибрати корисну підказку. Коротше — не означає автоматично краще.
Читайте дашборд на предмет аномалій, пов’язаних із трекінгом або змінами UI
Не кожна зміна на дашборді є поведінковою. Деякі виникають через те, що сам редизайн зламав вимірювання. Перейменування перегляду сторінки, перенесення кнопки або затримка події можуть створити фальшиве падіння чи несправжнє зростання.
Почніть із відсутніх подій. Якщо на день запуску один із кроків зник із дашборда, запитайте себе, чи люди перестали виконувати дію, чи просто трекінг перестав спрацьовувати. Різниця має значення.
Далі шукайте дубльовані події. Редизайн може випадково надіслати один і той самий клік двічі, якщо компонент змонтований двічі або скрипт спрацьовує і на десктопному, і на мобільному брейкпоінті. Це може завищити активність і створити враження, що слабкий потік працює краще, ніж насправді.
Перейменовані перегляди сторінок — ще одна пастка. Якщо структура URL змінилася, дашборд, який групує за назвою сторінки, може розділити одну сторінку на дві. У результаті ви побачите дві посередні сторінки замість однієї стабільної. Погіршилися не дані, а підписи.
Зміни в UI також можуть впливати на значення подій. Якщо основна дія перемістилася з кнопки на натискання картки, стара подія може все ще спрацьовувати, але вже не відображати той самий намір.
Якщо вам потрібна допомога з розумінням інфраструктурного шуму під час запуску, дивіться що робити, коли є проблеми з uptime Astrina. Редизайн і збій можуть створювати однакову форму графіка. Це не дуже весела гра в здогадки.
Порівняння поруч: що змінилося, що лишилося стабільним, а що потребує доопрацювання
Таблиця поруч із поруч змушує до дисципліни. Вона не дає команді сперечатися загальними словами і допомагає побачити, які цифри заслуговують на ще один цикл роботи.
| Показник на дашборді | До редизайну | Після редизайну | Інтерпретація |
|---|---|---|---|
| Завершення основного завдання | Стабільний базовий рівень | Поточний базовий рівень | Покращення, погіршення або без змін |
| Відсів на ключовому етапі воронки | Стабільний базовий рівень | Поточний базовий рівень | Слідкуйте за раннішими втратами |
| Завершення на мобільних | Стабільний базовий рівень | Поточний базовий рівень | Часто перше місце, де редизайн показує напруження |
| Завершення на десктопі | Стабільний базовий рівень | Поточний базовий рівень | Може покращитися, навіть якщо мобільна версія просідає |
| Повторна поведінка з поверненням назад | Стабільний базовий рівень | Поточний базовий рівень | Сигналізує про плутанину, якщо зростає |
| Кількість подій для основного CTA | Стабільний базовий рівень | Поточний базовий рівень | Перевірте, чи немає дублювання трекінгу |
Ця таблиця не повинна прикидатися, що знає більше, ніж знає насправді. Якщо визначення змінилися, зазначте це в рядку. Якщо редизайн змінив саму воронку, зазначте, що порівняння до/після не є чистим вимірюванням. Тут важлива чітка мова.
Корисний підхід — позначати кожен рядок як зелений, жовтий або червоний лише після того, як сирі дані стабілізуються. Таблиця, заповнена занадто рано, може підштовхнути команду до швидкої історії замість правильної.
Чесний висновок: коли редизайн працює, коли результат змішаний, а коли потрібен відкат
Редизайн працює, коли дашборд показує покращення основного завдання, ключова воронка залишається цілісною, а проблемні сегменти не провалюються. Одного сильного сегмента недостатньо. Потрібно, щоб результат тримався там, де продукт використовується найчастіше.
Результат змішаний, коли десктоп покращується, а мобільна версія слабшає, або коли рівень завершення зростає, але людям потрібно більше часу, щоб завершити дію. Це не провал за замовчуванням. Це означає, що редизайн вирішив одну проблему й створив іншу.
Відкат варто серйозно обговорювати, коли дашборд показує явне погіршення в основній дії, особливо якщо та сама проблема повторюється в кількох сегментах, а трекінг виглядає чистим. Якщо падають і мобільні, і десктопні показники, а форма воронки змінюється в тому самому напрямку, не варто надто довго чекати з діями.
Іноді редизайн виглядає успішним в агрегації, але все одно потребує точкового виправлення. Таке трапляється, коли один сегмент генерує основний обсяг, а менший сегмент зазнає великого падіння. Загальне середнє може приховувати цей дисбаланс днями.
Отже, справжня відповідь — це не один бал. Це патерн: стабільне вимірювання, той самий період порівняння, чіткі кроки воронки та один або два показники, які доводять, що редизайн виконав свою обіцянку. Якщо ці цифри не сходяться, дашборд каже вам продовжувати роботу.
