A/B тестування інтерфейсів
Вступ
A/B тестування - це контрольований експеримент, де дві (або більше) версії інтерфейсу порівнюються на реальних користувачах, щоб зрозуміти, яка версія призводить до кращих продуктових метриків. Мета - знижувати невизначеність при прийнятті рішень і покращувати UX через зміни, що перевіряються, а не думки.
Коли доречно A/B-тестування
Є вимірювана мета (конверсія, час до дії, утримання, NPS, швидкість задачі).
Очікуваний ефект неочевидний або може відрізнятися за сегментами.
Ризик зміни досить високий, щоб виправдати експеримент.
Трафік дозволяє швидко зібрати статистично значущу вибірку.
Коли краще не тестувати: мікрокопії на маловикористовуваних екранах, фічі з сильною мережевою/соціальною залежністю (перелив ефектів), правки, що вимагають тривалого навчання користувачів.
Формулювання гіпотези
Шаблон:- Якщо ми змінимо [X в інтерфейсі] для [Y-сегмента/всіх], то [метрика Z] зміниться на [напрямок/величина] тому що [поведінкова причина].
Приклад: Якщо перенести основний CTA вище лінії згину і скоротити форму з 6 до 3 полів, то CR первинної дії виросте на + 3-5% за рахунок зниження тертя.
Метрики: цільові та захисні
Primary (основна): одна ключова - наприклад, завершення цільового сценарію/конверсія.
Secondary: глибина скролла, CTR, час до дії, помилки, швидкість сторінки.
Guardrails (захисні): стабільність продуктивності (TTFB, LCP), повернення/відмови, скарги/відкати, дотримання лімітів повідомлень, доступність.
Рекомендується заздалегідь зафіксувати MDE (мінімально детектований ефект), вікно спостереження і критерії успішності.
Дизайн експерименту
Рандомізація та одиниця аналізу
Одиниця рандомізації: користувач (user_id), іноді - сесія або організація (кластер).
Стратифікація/блокування: по пристроях/каналах, якщо є сильні відмінності.
Перелив (interference): уникайте, коли поведінка однієї групи впливає на іншу (наприклад, загальні списки/стрічки). У таких випадках - кластерні тести.
Розмір вибірки і MDE (спрощено)
Наближено: чим нижча базова конверсія і чим менший ефект, тим більша вибірка.
Для CR ~ 10% і MDE ~ + 5% відносного ефекту нерідко потрібно десятки тисяч спостережень на варіант.
Тривалість
Орієнтуйтеся на повний тижневий цикл поведінки + запас (зазвичай 2-4 тижні) або до досягнення запланованої потужності. Не зупиняйте тест передчасно.
Рамп-ап (поступове виведення)
1-5% трафіку (canary) → 10-25% → 50% → 100%, з моніторингом guardrails.
Якість даних і валідність
SRM (Sample Ratio Mismatch)
Перевірте, що фактичний розподіл трафіку (A/B) відповідає плановому (наприклад, 50/50). Значущі відхилення = проблема інклюзії/прапорів/ботів.
Ідентичність і крос-девайс
Використовуйте стабільний user_id; враховуйте крос-пристрої, cookie-decay, авторизацію пізніше у воронці.
Боти та аномалії
Фільтруйте неприродні патерни (надшвидкісні кліки, відсутні user-агенти, невалідні реферери).
Сезонність і події
Не запускайте тести на сильні «аномальні» періоди (свята/розпродажі), якщо це не мета тесту.
Статистичний аналіз
Частотний підхід (класичний)
Фіксуйте альфа (зазвичай 0,05) і потужність (зазвичай 80%).
Не «підглядайте» кожні години без коригувань - ризик хибнопозитивних.
Для множинних метрик/варіантів застосовуйте коригування (Bonferroni/Holm/Hochberg) або ієрархію метрик.
Байєсовський підхід
Оцінює розподіл ймовірності ефекту і ймовірність переваги варіанту.
Зручний для моніторингу в реальному часі і прийняття рішень «досить добре».
CUPED/коваріати
Зниження дисперсії за рахунок передтестових коваріат (наприклад, активність за минулий тиждень) → швидше досягається потужність.