Якісно підготовлені A/B-тести вигравали частіше: аналіз 173 тисяч експериментів
Команда запустила двадцять A/B-тестів і знайшла десять переможців. Це хороший місяць? Поки невідомо: виграш міг бути надто малим, а впровадження — дорожчим за його користь. У звіті Optimizely якісно підготовлені експерименти перемагали частіше: 58% проти 35%. Для власної роботи корисно розібрати не лише цю різницю, а й питання, яке має передувати запуску: яке рішення ви зможете ухвалити за результатом тесту?
Опубліковано:
Що Optimizely вважав перемогою
Optimizely проаналізував 173 тисячі експериментів у понад 1200 компаніях за 2018–2026 роки. Формальний фільтр включав контроль і щонайменше одну тестову варіацію, від тисячі відвідувачів у кожній та відсутність ознак A/A-тесту.
Перемогою вважали поліпшення основної метрики зі статистичною значущістю від 90%. Порівняння якісного й неякісного налаштування дало 58% проти 35%, тобто різницю у 23 відсоткові пункти. Детальний спосіб поділу цих груп у публічному тексті не розкрито. Самі автори застерігають: порівняння спостережні, не причинні.
Найвища частка перемог була в гіпотез пошуку потрібного — Findability, 60%, та терміновості — Urgency, 56%. Для найпоширенішого пояснення цінності, Clarify Value, вона становила 41%. Водночас 43% експериментів проводили в нижній частині воронки. Це опис вибірки, а не рекомендація штучно додати терміновість до вашої пропозиції.
Почніть із рішення, а не з кольору кнопки
Припустімо, люди не помічають умови доставки. Команда хоче винести їх ближче до кнопки замовлення. Гіпотеза має пояснити, яку перешкоду це прибере та яку дію змінить. «Новий блок виглядає зрозуміліше» ще не визначає результату.
До розробки запишіть три речі:
- Основний результат. Наприклад, виконані замовлення на відвідувача. Клік на блок можна залишити пояснювальним показником.
- Найменший корисний ефект. Яке поліпшення виправдає розробку й підтримку? Воно допоможе спланувати потрібний обсяг даних разом зі статистичними параметрами.
- Умову відмови від зміни. Наприклад, зростання замовлень не має супроводжуватися неприйнятним падінням їхньої цінності.
Поріг у тисячу людей зі звіту не є готовим планом вибірки. Для рідкісної покупки й невеликого очікуваного ефекту цього може не вистачити. До запуску варто з’ясувати, чи ваш трафік узагалі дозволить перевірити потрібну різницю в прийнятний строк.
Як перемога може не окупитися
Візьмемо умовний результат: зміна додає десять виконаних замовлень на місяць, з кожного після змінних витрат залишається 100 грн. Додатковий внесок становить 1000 грн на місяць. Якщо розробка коштує 30 тисяч, простий строк її покриття — тридцять місяців. Тут припускаємо незмінний ефект і не враховуємо подальшу підтримку.
Це не причина відкидати всі невеликі поліпшення. Може бути дешевше впровадження, більший майбутній обсяг або важлива користь для доступності. Але ці аргументи потрібно назвати окремо, а не ховати за позначкою «статистично значуще».
Після тесту перевірте основний результат, небажані наслідки та вартість реалізації. Якщо зміна корисна лише за масштабу, якого бізнес поки не має, це теж частина рішення. Звіт про CRO-програму стане змістовнішим, коли поруч із кількістю перемог з’явиться те, що команда справді впровадила й отримала від цих змін.
