Ввести в оману A/B-тестування – це просто

Ростислав Михайлів, засновник TrueSocialMetrics.com ~ 4 хв.

класичний

Класичне A/B тестування – це розподіл між різними станами. Почнемо із загального зразка, яким користуються всі. У нас є сайт із кнопкою реєстрації, зараз вона синя, але ми хочемо протестувати новий червоний колір.

A/B testing

Потім ми розподіляємо туди якийсь трафік і трохи чекаємо. Для statistical significance є простий калькулятор.

Варіант А: 50 тисяч відвідувань - 500 реєстрацій Варіанти B: 50 тисяч відвідувачів – 570 реєстрацій – переможець

B є переможцем, це ясно. Більше реєстрацій, статистична значущість.

Нове класичне яблуко до апельсинів

Зачекайте трошки! Що ми випускаємо щось нове. Наприклад, ми додаємо кнопку «демо» для огляду покрокового керівництва продуктом. A/B testing a new feature

Якщо слідувати простій логіці A/B тестування – це не працює! Бо не можна порівнювати яблука з апельсинами. Ми не можемо нічого з чимось порівняти! Це абсолютно неправильно. Якщо кнопки демонстрації немає, користувачі можуть отримати гірший досвід, ніж ті, у кого є ця опція. Але цей параметр може допомогти лише користувачам, які вже зацікавилися продуктом або нещодавно повідомляли про нього. Навіть якщо у вас мільйони трафіку, ви не можете сказати, як це працює за кілька годин/днів, оскільки результати можуть бути відкладені в часі.

Для нової функціональності має бути випущений лінійний процес ентерального випуску. Лише потім через деякий час ми можемо поглянути на це та з’ясувати, чи вплинуло це на досвід клієнтів чи ні, але відстежуємо бізнес-метрики. А/Б-тести НЕ застосовуються для нової функції.

AA/BB перевіряє впевненість

Поверніться до першого зразка з кнопкою реєстрації. Якщо наше припущення вірне, ми можемо додати більше варіантів A та більше варіантів B, і нічого не зміниться, тому що B все ще може виграти битву.

AA/BB testing

Тоді подивіться на результати:

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% ймовірності.

Adaptive test initial state

Наприклад, ми випадково розподіляємо відвідувача на «синій», і «синій» є кращим враженням, оскільки ми отримали покупку. У цьому випадку «синій» перемагає, тому ми додаємо додатковий «синій» м’яч у пул.

Adaptive test added blue ball

У результаті вірогідність змінилася «червоний» - 33% і «синій» - 67%

Звучить добре! Але наступний відвідувач з «синіми» нічого не робить. Отже, «сині» програють, тому ми повинні видалити одну «синю» кулю з басейну, і ми отримали попередній стан.

Adaptive test final state

Плюси: + працює при невеликій кількості трафіку + адаптивно забезпечує кращий догляд за користувачами Мінуси: - вимагає роботи розробників, щоб визначити виграшні/програшні тести в процесі тестування

струс мозку

  • Класичне A/B-тестування не працює для нових функцій, оскільки ви не можете нічого перевірити з чимось
  • Зазвичай A/B-тести НЕ є репрезентативними, навіть якщо ваша аналітика каже, що вони репрезентативні
  • Підхід AA/BB допомагає перевірити результати тесту A/B
  • Адаптивне тестування надзвичайно корисне для невеликого трафіку, але вимагає ручної роботи для визначення цілей


Коли ви будете готові розгорнути свою аналітику в соціальних мережах

спробуйте TrueSocialMetrics!


Почніть пробну версію
Кредитна картка не потрібна.






Продовжити читання →




Збреши мені: погані показники для соціальних мереж
Найкращий спосіб зіпсувати аналітику соціальних медіа — вибрати погані показники або використовувати їх неправильно. Ось найкращі способи зробити це.


Як Oreo Rocks у Twitter: використання сегментації вмісту для аналізу твітів
Oreo має одну з найактивніших і найефективніших стратегій у соціальних мережах, яка принесла їм кілька нагород у минулому. Тож давайте подивимося на їхній обліковий запис у Twitter, щоб вивчити вміст і порівняти кілька чудових ідей із цього супер-печива.


Як часто твітнуть провідні бренди
Ідеальна щільність публікацій у Твіттері не є ідеальним рішенням. Доведеться знайти власний смак, як це роблять основні світові бренди. Деякі з них точно знають, як розгойдувати в соціальних мережах, тож вам слід якнайкраще наслідувати їх.


Static Files as a Database
For a long time, we have been living in a world where we use default approaches without fully thinking about their purpose. Take WordPress as an example: it's a powerful application, but it requires MySQL as its database, and to make it fast, you often need Memcache to cache MySQL queries and reduce database load. Alongside, there's the WYSIWYG editor, which, in theory, allows users to edit HTML easily, but in practice often generates unreadable, bloated code.