Ростислав Михайлів, засновник TrueSocialMetrics.com ~ 4 хв.
Класичне A/B тестування – це розподіл між різними станами. Почнемо із загального зразка, яким користуються всі. У нас є сайт із кнопкою реєстрації, зараз вона синя, але ми хочемо протестувати новий червоний колір.
Потім ми розподіляємо туди якийсь трафік і трохи чекаємо. Для statistical significance є простий калькулятор.
Варіант А: 50 тисяч відвідувань - 500 реєстрацій Варіанти B: 50 тисяч відвідувачів – 570 реєстрацій – переможець
B є переможцем, це ясно. Більше реєстрацій, статистична значущість.
Зачекайте трошки! Що ми випускаємо щось нове. Наприклад, ми додаємо кнопку «демо» для огляду покрокового керівництва продуктом.
Якщо слідувати простій логіці A/B тестування – це не працює! Бо не можна порівнювати яблука з апельсинами. Ми не можемо нічого з чимось порівняти! Це абсолютно неправильно. Якщо кнопки демонстрації немає, користувачі можуть отримати гірший досвід, ніж ті, у кого є ця опція. Але цей параметр може допомогти лише користувачам, які вже зацікавилися продуктом або нещодавно повідомляли про нього. Навіть якщо у вас мільйони трафіку, ви не можете сказати, як це працює за кілька годин/днів, оскільки результати можуть бути відкладені в часі.
Для нової функціональності має бути випущений лінійний процес ентерального випуску. Лише потім через деякий час ми можемо поглянути на це та з’ясувати, чи вплинуло це на досвід клієнтів чи ні, але відстежуємо бізнес-метрики. А/Б-тести НЕ застосовуються для нової функції.
Поверніться до першого зразка з кнопкою реєстрації. Якщо наше припущення вірне, ми можемо додати більше варіантів A та більше варіантів B, і нічого не зміниться, тому що B все ще може виграти битву.
Тоді подивіться на результати:
A1: 50 тисяч відвідувань - 500 реєстрацій A2: 50 тисяч відвідувачів - 580 реєстрацій - переможець B1: 50 тисяч відвідувачів - 570 реєстрацій - переможець B2: 50 тисяч відвідувачів - 500 реєстрацій
ЩО! ЩО! ЩО! Можна сказати, що це неможливо, але ця ситуація показує різницю, якщо розподіл відвідувачів впливає на результати тестів. І ці результати демонструють стабільну статистичну значущість 95%, але низьку достовірність.
Якщо ми повернемося до початку статті, то помітимо величезний трафік 50 тисяч відвідувачів і 500 переходів, необхідних для отримання значущих результатів. Однак не всі сторінки мають таку можливість. Не всі стартапи достатньо хороші, щоб генерувати такий трафік, або це можуть бути сторінки з низьким трафіком, як-от налаштування/рахунки тощо. Для всіх цих випадків класичне a/b-тестування займе багато часу, щоб зібрати дані місяці/півроку або так. Наступний недолік загального підходу полягає в тому, що принаймні 50 тис. відвідувачів (зі 100 тис., призначених для тестування) отримали гірший досвід клієнтів. Тому ми довго чекаємо і втрачаємо клієнтів через віднесення до «збиткового» тесту. Чи є в цьому сенс? У медичних закладах лікарі перетинали справи, а в столі – життя людей. Якщо ми зробимо тест під час того, що 50% пацієнтів вмирає через «ще не перевірений догляд». І це біса божевілля. Ось хлопець Марвін Зелен, який придумав ідею адаптивного тестування, яка тепер називається Zelen’s design.
Уявімо, що у нас є 2 можливості: червона та синя кулі, тож статистично це становить 50% ймовірності.
Наприклад, ми випадково розподіляємо відвідувача на «синій», і «синій» є кращим враженням, оскільки ми отримали покупку. У цьому випадку «синій» перемагає, тому ми додаємо додатковий «синій» м’яч у пул.
У результаті вірогідність змінилася «червоний» - 33% і «синій» - 67%
Звучить добре! Але наступний відвідувач з «синіми» нічого не робить. Отже, «сині» програють, тому ми повинні видалити одну «синю» кулю з басейну, і ми отримали попередній стан.
Плюси: + працює при невеликій кількості трафіку + адаптивно забезпечує кращий догляд за користувачами Мінуси: - вимагає роботи розробників, щоб визначити виграшні/програшні тести в процесі тестування