Фінал A
Провести A/B-тест
УмоваЄ рішення, дані та ціна помилки, яка виправдовує експеримент.
A/B-тест не знаходить правильне рішення. Він показує, чи спрацювало конкретне.
Спочатку визначаємо точку втрати, причину та рішення. Тест використовуємо лише там, де ціна помилки висока, результат вплине на наступну дію, а даних достатньо для чесної відповіді.
- 01Проблема
- 02Доказ
- 03Причина
- 04Рішення
- 05Спосіб перевірки
05 · Спосіб перевіркиA/B-тест – лише один із варіантів цього кроку, а не початок роботи.
Послідовність
«Давайте протестуємо» – не відповідь на питання, що потрібно змінити
Аналітика показує, де користувачі випадають. Дослідження та експертиза допомагають зрозуміти, чому це відбувається. Лише після цього формується конкретне рішення, ефект якого можна перевірити.
- 01ДаніДе саме випадають користувачі
- 02Поведінкова проблемаЯку дію людина не виконує
- 03ПричинаЧому рішення не ухвалюється
- 04РішенняКонкретна зміна в продукті
- 05Спосіб перевіркиТест або інший доказ
- 06РішенняВпроваджуємо, відхиляємо або перевіряємо інакше
Погана гіпотеза
«Зробимо кнопку червоною – раптом кліків стане більше».
Робоча гіпотеза – приклад структури
«Користувачі не продовжують оформлення, бо до наступного кроку не бачать повної вартості. Якщо показати її раніше, більше людей завершить замовлення».
Якщо ми не можемо пояснити, чому зміна має вплинути на рішення користувача, тестуємо не гіпотезу, а випадковість.
Дерево рішення
Тест потрібен не кожній зміні
-
Питання 01
Чи існує конкретне рішення для перевірки?
Ні → спочатку аналітика, UX-дослідження або аудит.
Так → далі
-
Питання 02
Чи змінить результат тесту наше рішення?
Ні → тест не потрібен.
Так → далі
-
Питання 03
Чи висока ціна помилки або масштабування?
Ні → розглянути контрольоване впровадження.
Так → далі
-
Питання 04
Чи достатньо трафіку та цільових подій?
Ні → обрати інший спосіб перевірки.
Так → далі
-
Питання 05
Чи можемо ми коректно виміряти результат?
Ні → спочатку виправити аналітику.
Так → планувати експеримент
Фінал B
Впровадити контрольовано
УмоваРизик помірний або трафіку замало для чесного тесту – фіксуємо обмеження висновку.
Фінал C
Спочатку дослідження або дані
УмоваНемає причинної моделі чи довіри до аналітики.
До запуску
Спочатку визначаємо, чи здатен тест відповісти. Потім проєктуємо варіанти
- 01Основна метрика
- 02Захисні метрики
- 03Базовий рівень
- 04Мінімальний ефект, заради якого варто змінювати продукт
- 05Потрібний обсяг вибірки
- 06Мінімальна тривалість
- 07Повні бізнес-цикли
- 08Сегменти
- 09Технічна коректність розподілу
- 10Правило зупинки
- 11Наступна дія для кожного можливого результату
Якщо тест не може набрати достатньо даних у прийнятний для бізнесу строк, він не стає чеснішим від того, що працює довше.
Результат
У тесту більше двох результатів: не лише «переміг» або «програв»
01 – Фінал
Рішення підтвердилося
Ефект достатньо переконливий, захисні метрики не погіршилися, а масштаб зміни має бізнес-сенс.
Наступна діяВпроваджуємо
02 – Фінал
Рішення не підтвердилося
Не впроваджуємо його як доведене. Переглядаємо причинну модель або формуємо іншу гіпотезу.
Наступна діяПовертаємось до причини
03 – Фінал
Даних недостатньо
Не називаємо випадкове коливання перемогою. Фіксуємо обмеження та вирішуємо, чи продовжувати, змінити метод перевірки або зупинитися.
Наступна діяЦе теж результат
Основна метрика має бути максимально близькою до бізнес-результату. Проміжну метрику використовуємо лише тоді, коли зрозуміло, як вона пов’язана з наступною цінною дією.
Більше кліків – не перемога, якщо вони не змінюють результат, заради якого існує сторінка або продукт.
Межа
Іноді найцінніше рішення щодо A/B-тесту – не проводити його
Порівняння «до/після» не є рівноцінною заміною експерименту. Якщо використовуємо контрольоване впровадження, прямо позначаємо обмеження причинного висновку.
Ми не створюємо експеримент, щоб заповнити щомісячний звіт.
- Не запускаємо тест, якщо
- 01Немає конкретної гіпотези
- 02Результат не вплине на рішення
- 03Трафіку або подій недостатньо
- 04Аналітика не дозволяє довіряти даним
- 05Одночасно змінюється забагато зовнішніх умов
- 06Тест коштуватиме дорожче, ніж контрольоване впровадження
- 07Проблема є очевидним дефектом, помилкою або порушенням базового сценарію
- 08Команда не готова впроваджувати жоден із можливих результатів
У межах CRO
Що отримує клієнт навколо кожного експерименту
(01) Рішення
Обґрунтоване рішення.
Опис проблеми, причинна модель, дані та конкретна зміна для перевірки.
- Проблема
- Причинна модель
- Дані
- Зміна
(02) Розрахунок
Розрахунок до запуску.
Оцінка необхідної вибірки, тривалості та здатності тесту побачити ефект, який має значення для бізнесу.
- Вибірка
- Тривалість
- Мінімальний ефект
- Правило зупинки
(03) Реалізація
Реалізація експерименту.
Дизайн варіантів, технічна постановка, перевірка даних і контроль коректності запуску.
- Дизайн варіантів
- Постановка
- Перевірка даних
- Контроль розподілу
(04) Висновок
Рішення після результату.
Інтерпретація без вибіркових метрик, рекомендація щодо впровадження та фіксація нового знання про поведінку користувача.
- Інтерпретація
- Захисні метрики
- Рекомендація
- Нове знання
Формат роботи
A/B-тестування не продається окремо від задачі, яку воно має вирішити
A/B-тести входять у CRO для eCommerce або CRO для цифрових продуктів. До експерименту проводиться діагностика, після нього ухвалюється та впроваджується рішення.
Точка стартуРазово
від $2 500
Повний аудит сайту: точки втрати, причини та пріоритети.
- Аналіз ланцюга рішення
- Точки втрати з доказами
- Пріоритетний план змін
- Рекомендований спосіб перевірки кожної зміни
Формат роботиЗалежить від задачі
У складі CRO
Вартість експерименту залежить від складності гіпотези, кількості варіантів, потреби в дизайні, складності реалізації, системи експериментів, аналітики, тривалості контролю та кількості платформ і сегментів.
Перевірити, чи потрібен тестМісце в CRO
Тест – один крок циклу, а не окремий процес
- 01ДіагностикаДе і скільки втрачається
- 02РішенняЩо саме змінюємо і чому
- 03Вибір методу перевіркиA/B-тест · UX-дослідження · прототип · контрольований запуск · аналіз до/після з обмеженнями · спостереження за метриками
- 04ВпровадженняЗміна доходить до продукту
- 05ВимірюванняЩо змінилось у поведінці та грошах
- 06Наступне рішенняЦикл повторюється з новим знанням
Наша мета – не провести більше тестів. Наша мета – швидше отримати достатньо доказів для правильного рішення.
Питання
Що зазвичай запитують про експерименти
Універсальної цифри немає. Потрібний обсяг залежить від базової конверсії, мінімального ефекту, який важливо виявити, кількості варіантів і допустимої похибки. Це розраховується до запуску.
Кожен тест використовує трафік, час команди та відкладає впровадження. Якщо результат не змінить рішення або тест не здатен побачити важливий ефект, він не створює цінності.
Іноді це корисний орієнтир, але таке порівняння не ізолює вплив зміни від сезонності, реклами, складу аудиторії та інших факторів. Тому рівень доказовості буде нижчим, ніж у коректному контрольованому експерименті.
Вона має бути максимально близькою до бізнес-результату. У деяких продуктах дохід виникає занадто пізно, тому використовується підтверджена проміжна метрика разом із захисними показниками.
Це не гарантія бізнес-користі й не доказ абсолютної істини. Він означає, що за умов обраної моделі спостережувану різницю складніше пояснити випадковістю. Окремо потрібно оцінити розмір ефекту, якість даних і практичну цінність.
Використати інший спосіб отримання доказів: UX-дослідження, прототипне тестування, контрольований запуск, аналіз поведінки або спостереження після впровадження з чітким розумінням обмежень.
Ні. Ми проти тестування без питання, математики та наступного рішення. Коли експеримент є найкращим способом знизити ризик, ми його використовуємо.
Початок
Спочатку визначимо не що тестувати, а яке рішення вам потрібно ухвалити
30-хвилинна онлайн-зустріч із фаундером. Обговоримо задачу, доступні дані, трафік і ціну помилки. Після розмови запропонуємо наступний крок: A/B-тест, аудит, CRO або інший спосіб перевірки.