A/B-тестування, яке шкодить бізнесу: типові помилки команд

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Усім привіт! Мене звати Дмитро Цапій. Я Product Marketing Lead одного з бізнесів групи продуктових IT-компаній Universe Group — Wisey. Ми розробляємо екосистему сервісів для підвищення персональної продуктивності користувачів.

Всі маркетологи та product-менеджери знають, що треба тестувати. Однак, мало хто усвідомлює, що неправильне тестування може бути гіршим за його повну відсутність.

У кожній команді є люди, які десь щось побачили і пропонують це протестувати. Зазвичай всі погоджуються, бо тестування — це добре, data-driven підхід, те, що роблять Netflix, Duolingo та інші великі гравці.

Але є нюанс. Погано проведений тест не просто дає «незрозумілий результат». Він дає результат, якому не можна довіряти, але який виглядає переконливо. Це ще гірше, бо ви впевнені, що прийняли правильне рішення, а насправді — ні.

Тест показує +12% до конверсії при 50% довірі — і команда масштабує зміни на 100%.
Через місяць конверсія падає. Найпростіше пояснення — «сезонність». Але проблема була не в ній.
Це не сезонність. Це помилка типу 1. І вона коштує грошей.
Саме тому в цій статті я зібрав типові помилки, які команди регулярно допускають у A/B-тестуванні, і поясню, як їх уникнути.

7 типових помилок, які команди роблять постійно

#1 Зупинка тесту занадто рано (peek problem)

Ситуація: Ви запустили A/B тест. На третій день варіант B показує приріст, наприклад, +15%. Ви дивитеся на дашборд і вирішуєте, що результат уже очевидний і тест можна завершувати. Але це одна з найпоширеніших і найдорожчих помилок.

Чому це погано: результати тесту хитаються: на початку один варіант може виглядати сильнішим, потім інший, і лише з часом картина стабілізується. Якщо зупинитися в момент, коли варіант B випадково вийшов уперед, ви приймаєте рішення на основі шуму (можливого викиду), а не реального сигналу того, що зміна спрацювала.

За досвідом, значна частина таких «переможців» не відрізняється від контрольної групи — просто їм пощастило на конкретному відрізку часу.

Як виправити?

Розраховуйте sample size (необхідний розмір вибірки) до запуску тесту. І зупиняйте його лише після того, як він набрав потрібну кількість юзерів, незалежно від того, що показує дашборд.

Ще один важливий момент — дні тижня. Навіть якщо тест швидко набрав необхідний sample size, варто переконатися, що він охоплює і будні, і вихідні. Поведінка користувачів у понеділок і, наприклад, у суботу може суттєво відрізнятися, а разом із нею і результати тесту.

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

#2 Тест без гіпотези: «запустимо — там уже буде видно»

Найгірший спосіб тестувати — це запускати зміни за принципом «подивимось, що буде». Без чіткої гіпотези ви не розумієте, що саме перевіряєте, не можете коректно інтерпретувати результат і не зможете зробити висновки навіть із «успішних» тестів.

Як виправити?

Кожен тест має починатися з гіпотези:

Якщо ми зробимо [зміна А] у [місце В], то це вплине на [аудиторія С] та призведе до зміни [метрика D] на Х%, тому що [аргумент E]

Одна гіпотеза — одна ключова метрика успіху. Усі інші метрики варто використовувати як допоміжні для інтерпретації результатів.

#3 Тестування занадто багатьох варіантів одночасно

Ситуація: ви запускаєте A/B/C/D тест із чотирма варіантами. На перший погляд все виглядає ефективно, адже за один запуск ви перевіряєте більше ідей. Але проблема в тому, що з кожним додатковим варіантом зростає ймовірність випадкового «переможця». Не тому, що він справді кращий, а через збіг обставин.

У результаті частина таких «виграшів» — хибні. Чим більше варіантів у тесті, тим вища ця ймовірність: 3 варіанти — і вже кожен сьомий «переможець» фейковий. 8 варіантів — кожен третій.

Як виправити?

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

#4 75% довіри — достатньо

У більшості продуктових команд стандартом вважається 95% статистичної значущості (p-value 0.05). Важливо розуміти, що 90% — це мінімум, а не «достатньо хороший» результат. Тому 75% — це взагалі лотерея. При такому рівні якщо ви проведете 10 тестів, приблизно у трьох із них «переможець» буде випадковим.

Як виправити?
Закладайте мінімум 90% статистичної значущості. Для критичних рішень, таких як зміни в ціноутворенні чи пейволі — орієнтуйтеся на 95%. Також завжди перевіряйте, чи тест досяг необхідного sample size (розміру вибірки).

#5 Feature metric замість business metric

Ситуація: ви тестуєте новий квіз і вимірюєте completion rate. Варіант B виграє, маючи +18% completion. Але конверсія в підписку залишається без змін. У результаті ви витратили 1–2 тижні на покращення метрики, яка не впливає на бізнес.

CTR кнопки виріс на 40%. Конверсія в підписку — без змін.

Формально метрика покращилась. Але бізнес-результат — ні.

Оптимізація заради оптимізації — не growth

Як виправити?
Ключова метрика тесту має бути напряму пов’язана з бізнес-результатом. Це може бути конверсія, retention або LTV.

Feature-метрики (completion rate, click rate) варто використовувати лише як допоміжні, щоб зрозуміти чому ви отримали саме такий результат, а не як критерій успіху.

#6 Ігнорування різних сегментів

Ситуація: команда дивиться на загальний результат тесту. Варіант B виграє із результатом +7%. Здається, рішення очевидне та потрібно його впроваджувати. Але якщо розбити цей результат за пристроями, то картина виходить інша. На десктопі — +25%, і це 50% вашого трафіку. На мобільному — —5%, це інші 50%.

У підсумку ви отримуєте ~+7% у середньому, але одночасно погіршуєте досвід для половини свого трафіку.

Як виправити?
Сегментуйте результати по різним можливим сегментам: девайси, платформи, джерела трафіку, гендер, вік.

#7 Тест провалився — і ніхто нічого не записав

Ситуація: тест не показав очікуваного результату. Команда рухається далі: без зайвих обговорень запускає наступний тест.

Здається, що це про швидкість, але насправді — про втрату знань. Якщо результат тесту не зафіксований і не проаналізований, ви втрачаєте не дані, адже вони залишаються в дашбордах. Ви втрачаєте розуміння: чому гіпотеза не спрацювала, що це говорить про поведінку користувача і які висновки з цього варто зробити.

У результаті через кілька місяців команда може повернутися до тієї ж ідеї і знову витратити 1–2 тижні, щоб отримати вже відомий результат.

Як виправити?
Ведіть архів тестів: гіпотеза, метрика, результат, інсайт. Навіть «провальні» тести — це знання. Часто вони дають більше розуміння, ніж успішні, тому що змушують переосмислити початкову гіпотезу.

Якщо тест не підтвердив очікування, важливо відповісти на питання: що саме пішло не так і чому. Саме ці відповіді формують основу для наступних рішень.

Ознаки здорової культури тестування

Помилки, про які йшлося вище, зазвичай не виглядають критичними в моменті. Але саме з них поступово формується культура, в якій тестування не допомагає приймати рішення, а лише створює ілюзію data-driven підходу.

Щоб цього уникнути, важливо дивитися не лише на окремі тести, а на підхід команди в цілому. Нижче ділюся, на що варто звернути увагу, якщо ви хочете зрозуміти, наскільки добре працює ваше тестування:

Перед кожним тестом є гіпотеза з чіткою business-метрикою
Sample size розраховується до запуску, не після
Тести не зупиняються достроково через «і так зрозуміло»
Результати сегментуються по сегментам
Є архів тестів (у Notion чи Confluence)
Програшні тести обговорюються так само ретельно, як успішні

«Найгірший спосіб тестувати — це запустити зміну і просто подивитися, що буде. Без гіпотези ви не знаєте, що вимірюєте.»

— PM 101: Pitfalls of A/B Testing

Отже, знаючи ці помилки хороша новина в тому, що більшість з них не потребують додаткових інструментів чи бюджету. Вони вирішуються на рівні підходу. Достатньо трьох речей: чіткої гіпотези перед запуском тесту, домовленості не зупиняти його раніше потрібного sample size і системної фіксації результатів та інсайтів.