A/B тестування на сайті
Спершу рахуємо, чи вистачає вам відвідувачів для достовірного висновку, і лише потім перевіряємо. Розрахунок безкоштовний.
Оптимізація конверсії сайту починається з питання, чи правильно ви її рахуєте: якщо одна заявка потрапляє у звіт двічі, а дзвінки не потрапляють зовсім, покращувати нема що. Далі робота йде по даних. Знаходимо крок, на якому відвідувачі масово йдуть: категорія, картка, кошик, форма, оформлення. Шукаємо причину й ранжуємо правки за тим, скільки людей проходить через це місце і скільки коштує виправлення. Явні вади, як-от поле, що відхиляє правильний телефон, чи доставка, яку видно лише на останньому кроці, виправляємо одразу. Спірні гіпотези перевіряємо A/B-тестом, якщо трафіку вистачає для висновку, а якщо ні, порівнюємо до і після й чесно кажемо, що це слабший доказ.
Реклама й пошук приводять людей, у звіті тисячі візитів, а замовлень одиниці. Перш ніж купувати більше трафіку, варто зрозуміти, на якому кроці губляться ті, хто вже прийшов, бо їхня вартість уже сплачена.
Розберемо вашу ситуацію на безкоштовному аудитіДо кошика доходять, а до оплати ні. Причина зазвичай конкретна: несподівана вартість доставки, обов'язкова реєстрація, форма на дванадцять полів або спосіб оплати, якого покупець не знайшов.
Один хоче нову головну, інший — інший колір кнопки, третій — новий сайт. Потрібен порядок дій, у якому кожна правка має причину в даних, а спірні варіанти перевіряються, а не вирішуються голосуванням.
Сайт став гарнішим, а звернень поменшало, і незрозуміло чому. Порівнюємо шлях до і після за даними аналітики й знаходимо, що саме зламалось: форма, крок оформлення чи подія, яка просто перестала рахуватись.
Звіряємо події аналітики з реальними заявками й замовленнями. Якщо цифри розходяться, спершу виправляємо облік, бо без нього всі наступні висновки будуть хибними.
Будуємо воронку за вашими даними й проходимо ключовий шлях на телефоні й комп'ютері. На виході — місця відтоку з поясненням можливої причини.
Ранжуємо правки за охопленням і вартістю. Узгоджуємо з вами, що виправляємо одразу, а що спершу перевіряємо.
Вносимо явні правки й запускаємо перевірки спірних. Строк залежить від обсягу правок і трафіку: тест не зупиняємо раніше, ніж даних вистачить.
Показуємо результат за кожною зміною у ваших даних і кажемо, чи є сенс продовжувати, чи наступне обмеження вже не на сайті.
Універсальної цифри немає, і будь-яке «нормальне» число з чужої статті вам мало що скаже. Конверсія залежить від ніші, ціни, джерела трафіку й того, що саме рахується: магазин дешевих аксесуарів і сайт промислового обладнання мають різні порядки цифр. Корисніше порівнювати сайт із самим собою за кроками воронки й між каналами: так видно, де саме ви втрачаєте людей.
Як частку відвідувачів, які зробили цільову дію: замовлення, заявку, дзвінок. Складність не у формулі, а в чисельнику. Якщо подія спрацьовує і на відправку форми, і на сторінку подяки, заявок у звіті вдвічі більше, ніж насправді. Якщо дзвінки й месенджери не відстежуються, частина звернень зникає. Тому перший крок будь-якої оптимізації конверсії — звірка звіту з реальними заявками.
З обліку, потім з воронки. Спершу переконуємося, що цифри правдиві, потім дивимось, на якому кроці відтік найбільший, і йдемо туди. Найчастіше перші знахідки прозаїчні: форма не приймає номер у потрібному форматі, доставку видно лише в кінці, кнопка оформлення на телефоні ховається під банером. Такі речі виправляються одразу й без тестів, бо сумнівів у них немає.
UX-аудит — одноразовий звіт: проходимо шлях покупця й кажемо, де він обривається. Оптимізація конверсії йде далі. Вона спирається на ваші дані, включає виправлення й перевіряє, чи дала кожна зміна ефект. Якщо аналітики на сайті немає або вона зламана, чесніше почати з аудиту чи налаштування вимірювання, а оптимізацію робити тоді, коли буде на що спиратись.
Ні. A/B-тест потрібен для спірних змін, коли незрозуміло, котрий варіант кращий. Для явних вад він зайвий: зламану форму не тестують, її лагодять. До того ж тест має сенс лише за достатньої кількості відвідувачів і замовлень. На малому трафіку різниця між варіантами тоне у випадковості, і тоді чесніше порівняти до і після, пам'ятаючи про межі такого висновку.
Має, але інша. На кількох сотнях візитів на місяць статистично довести різницю між варіантами майже неможливо, тому тести там не запускаємо. Зате явні вади видно й без великої вибірки: прохід шляху вручну, записи сесій, якщо підключено Hotjar чи Clarity, і звірка із заявками показують, де люди застрягають. Виправити це можна одразу, а ефект оцінити, коли накопичиться більше даних.
Наперед цього не знає ніхто, і той, хто називає відсоток до початку робіт, вигадує. Можемо сказати, що саме заважає людям оформити замовлення зараз, і в якому порядку ми це приберемо. Результат кожної зміни покаже ваша аналітика, і ми показуємо його таким, яким він є, включно з випадками, коли різниці не виявилось.
Етапи вказані вище в діапазонах, а повний цикл від перевірки обліку до висновків залежить від трафіку. Діагностика коротка, а найдовше триває перевірка змін: тест не можна зупинити, щойно цифра виглядає гарно, треба дочекатися достатньої кількості даних. Далі можна працювати циклами, поки наступне обмеження не опиниться поза сайтом, наприклад у ціні чи швидкості відповіді менеджера.
Опишіть задачу своїми словами — підкажемо, з чого починати, і чи потрібне вам те, за чим ви прийшли. Якщо не потрібне, так і скажемо.