Як робити А/В тести на нових продуктах швидше: 7 порад продуктовим командам

Привіт, мене звати Єва Колдовська і я продакт-менеджерка в компанії Headway, що розробляє EdTech-продукти. Я відповідаю за запуск та розвиток наших R&D-напрямків на вебі.

Запускаючи новий продукт, я не раз стикалася з тим, що А/В-тести займали дуже багато часу, не досягали статистично значущих результатів, а тому й оцінити їх було важко. Саме з цієї причини часто продакт-менеджери узагалі не запускають А/В-тести, доки продукт не досягне великих об’ємів трафіку. Але це — велика помилка, адже завдяки тестам можна отримувати корисні інсайти від самого старту роботи з продуктом.

За 2 роки створення нових продуктів у Headway ми з командою дослідили цю проблему, провели десятки тестів, назбирали досвід та best practices, якими хочу поділитися у цій статті. Вона покликана дати практичні поради, як пришвидшити запуск та закриття А/В-тестів на ранніх етапах, коли користувачів ще мало, а калькулятор для визначення розміру вибірки каже, що вам знадобиться декілька місяців на один тест.

Поради зі статті допоможуть продуктовим командам проводити А/В-тести на нових продуктах та отримувати інсайти вже з перших тижнів після запуску.

Порада № 1: Shu, або Знай теорію

У японських бойових мистецтвах існує концепція навчання під назвою Shuhari:

  1. Shu = Learn the rules. Повторюй за вчителем. Вчи теорію, техніки й правила.
  2. Ha = Bend the rules. Обмірковуй свої дії, знаючи теорію, внось свої корективи та інновації.
  3. Ri = Break the rules. Виходь за рамки правил та створюй нові.

Ідея в тому, що для переходу на наступний рівень потрібно освоїти попередній.

Етап Shu — вивчення та розуміння теорії — дуже важливий і в А/В-тестуванні. Без нього будь-яке відхилення від правил буде або неусвідомленим, або неефективним. Щоб почати порушувати правила, потрібно їх розуміти.

Для використання частотного підходу (frequentist approach), що лежить в основі більшості А/В-тестів сьогодні й на якому я буду фокусуватися в цій статті, потрібно обов’язково заздалегідь рахувати й встановлювати необхідний розмір вибірки (sample size). Це закладено в саму суть цього статистичного методу.

Якщо цього не зробити, можна легко потрапити в пастку «проблеми підглядання» (peeking problem), коли необхідний розмір вибірки ще не набрався, а ми вже бачимо статистично значущий результат і закриваємо тест. А насправді ж отримуємо хибно позитивний результат.

Коли ви рахуєте розмір вибірки та кількість днів для проведення тесту, слід чітко усвідомлювати, як кожен з параметрів впливає на результат.

Розглянемо параметри в типовому калькуляторі для визначення розміру вибірки:

  1. Базова конверсія. Що вища ця метрика, то менше потрібно користувачів для досягнення статистичної значущості її зміни.
  2. Мінімальний очікуваний ефект. Що більшого ефекту ми очікуємо побачити від тесту, то легше його помітити.
  3. Рівень значущості (p-value). Що вища ймовірність помилки, то швидше отримаємо результат.
  4. Статистична потужність (power). Що нижчий відсоток часу, коли ефект буде помічено, то менше потрібно для цього користувачів.
  5. Кількість користувачів на продукті. Що більше користувачів, то швидше набереться необхідна вибірка.

Знаючи ці залежності, можна оперувати тими параметрами, які ми в змозі контролювати, щоб обирати найкращі тести та скоротити їх тривалість.

❗️Раджу чудову книгу для заглиблення в тему А/В-тестів та їх теоретичні основи — Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing by Ron Kohavi, Diane Tang, Ya Xu. Вона надає і теорію, і практичні поради щодо проведення тестів, а також багато прикладів та кейсів відомих компаній (Google, LinkedIn і Microsoft).

Порада № 2: Обирай правильну метрику

Важливо усвідомлено обирати зону продукту, на якій буде відбуватися А/В-тест, та метрику для його оцінки.

Ми вже знаємо: що вища базова конверсія, тим меншою має бути вибірка. Тому для зменшення необхідного розміру вибірки слід:

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

Ми хочемо провести на ній тест на онбордингу. Очікуваний ефект — приріст конверсії в реєстрацію на 15%.

Якщо оцінювати тест за розподілом користувачів з початку воронки (з лендингу), маємо:

  • Користувачів щоденно: 1000.
  • Базова конверсія (з лендингу в реєстрацію): 8%.
  • Очікуваний приріст: 15%.
  • Розмір вибірки: ~8,000.
  • Днів на тест: 8,000 / 1,000 = 8.

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

  • Користувачів щоденно: 200.
  • Базова конверсія (в реєстрацію з початку онбордингу): 40%.
  • Очікуваний приріст: 15%.
  • Розмір вибірки: ~1,000.
  • Днів на тест: 1,000 / 200 = 5.

Не змінивши нічого в самому А/В-тесті, ми зекономили майже 40% часу на його проведення!

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

2. Використовувати проксі-метрики для оцінки. Якщо метрика з більшою кількістю користувачів (вища на воронці) сильно корелює з цільовою метрикою, вона може вважатись проксі-метрикою. Відповідно, тест можна оцінювати за нею.

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

  • Користувачів щоденно: 200.
  • Базова конверсія (в наступний крок з онбордингу): 50%.
  • Очікуваний приріст: 15%.
  • Розмір вибірки: ~700.
  • Днів на тест: 4.

Ми зекономимо ще 1 день тесту! Справа знову у вищій базовій конверсії цього кроку.

3. Приводити метрики до вигляду конверсій. Оцінювати тести за складеними метриками (наприклад, середній дохід з користувача або кількість спожитого ним контенту) зазвичай важче і довше, ніж за конверсіями.

Тому для спрощення складені метрики можна розкласти на конверсії.

Наприклад, середній дохід з користувача для продукту з підписками — LTV — складається з ряду конверсій у:

  • взяття тріала;
  • купівлю конкретного тарифного плану серед усіх;
  • оплату повної вартості після тріала;
  • скасування підписки;
  • рефанд;
  • наступні оплати.

Корисно визначити, які з них найсильніше впливають на цільову метрику, і оцінювати тест за ними.

Порада № 3: Прагни більшого

Що вищий мінімальний очікуваний ефект, то меншою має бути вибірка. Тож важливо:

1. Пріоритезувати зону продукту з найбільшими проблемами та потенціалом для покращення.

Повернімося до нашого прикладу:

Залежно від продукту та індустрії, оптимальні показники конверсій можуть різнитися. Тому корисно порівнювати наші з бенчмарками. Наприклад, ми бачимо, що середній показник конверсії на лендингах конкурентів — 40%. На нашому лендингу він в цілих два рази менший — 20%. Натомість на кроці реєстрації в продуктах з нашої ніші в середньому конвертять 75% користувачів. Показник нашого продукту навіть вище — 80%.

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

Отож, оскільки ми маємо більший потенціал для покращення на лендингу, мінімальний очікуваний ефект від тестів на ньому можемо ставити вищим.

2. Тестувати масштабні гіпотези замість ітеративних покращень. Що оберете: провести три тести з очікуваним приростом по 5-10% кожен чи один тест, орієнтований на 30+%?

Для пришвидшення А/В-тестів краще обрати другий варіант. Чому? Уявімо, що у нас є гіпотеза, ніби персоналізація воронки підвищить конверсію в реєстрацію. Ми можемо персоналізувати окремо лендинг, онбординг та екран реєстрації. Реалізацію цієї гіпотези можна розбити на три кроки й тестувати кожен окремо. Так ми чіткіше побачимо ефект від кожної окремої зміни, проте в цього підходу є свої мінуси:

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

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

3. Обирати тести з найбільшим очікуваним ефектом. На старті розвитку продукту ми маємо багато невідомих, тому є сенс тестувати масштабні зміни.

Ризики втрати користувачів невеликі та водночас нам дуже важливо отримувати фундаментальні знання про них та продукт. Тестувати 41 відтінок блакитного кольору, як робив Google для своєї пошукової видачі, ще трохи зарано.

Тому раджу першими запускати тести, які сильно змінюють формат взаємодії з продуктом та можуть принести найбільшу вигоду. Наприклад:

  • сетап воронки (її розташування та наявність кроків, довжина воронки, формат взаємодії з нею);
  • модель монетизації (Freemium / Premium, наявність тріалу, реклами всередині продукту);
  • головну ціннісну пропозицію;
  • нові функції в продукті;
  • інші ризиковані гіпотези.

Очікуваний ефект від них зазвичай набагато вищий, ніж від «мінорних» тестів.

4. Депріоритезувати тести, орієнтовані на вузькі сегменти аудиторії. «А давайте зробимо знижку для користувачів, які знаходяться на екрані з покупкою довше двох хвилин? Можливо, вони довго думають і потребують додаткової мотивації купити.» Подібні гіпотези важливі з оптимізаційної точки зору, проте якщо вони стосуються лише 5% вашої аудиторії, то будь-який позитивний ефект від змін для них потрібно буде множити на 5%.

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

Порада № 4: Використовуй паралельні тести

Щоб розкрити повний потенціал льорнінгу на продукті, можна запускати декілька тестів паралельно. Це дозволить отримувати більше інсайтів з одного користувача.

Проте робити це потрібно обережно. Важливо, щоб не було прямого або логічного перетину змін у тестах.

Наприклад, ми хочемо зробити два А/В-тести на одному і тому ж кроці воронки. Не варто запускати їх одночасно, адже один тест може сильно впливати на результати іншого. В таких випадках необхідно оцінювати ефект на метрики в кожній розбивці, що не буде економити час, витрачений на тест.

Але якщо тестуються різні зони продукту, тести можна запускати паралельно.

Наприклад, запускаємо два А/В-тести — зміни в дизайні онбордингу та новий заголовок на екрані реєстрації.

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

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

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

Наприклад, для двох А/В тестів можна розподілити користувачів так:

— 33% — спільна контрольна група;
— 33% — група зі змінами першого тесту;
— 33% — група зі змінами другого тесту.

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

Порада № 5: Усвідомлено закривай тести раніше строку

Іноді закривати тести раніше, ніж набереться запланована вибірка, нормально. Ми зазвичай це робимо у таких випадках, коли:

1. Тестова група стабільно дає мінус в цільовій метриці. Якщо протягом повного бізнес-циклу (для нас це один тиждень) ми бачимо негативний тренд у головній метриці і статистична значущість цього результату підвищується з кожним днем, ми не чекаємо та закриваємо тест.

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

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

2. Ефект позитивніший, ніж очікувалося. Наприклад, ми проводимо тест з такими вхідними даними:

  • Користувачів щоденно: 1000.
  • Базова конверсія: 5%.
  • Очікуваний приріст: 10%.
  • Розмір вибірки: ~30,000.
  • Днів на тест: 30.

Але проходить два тижні й ми бачимо стабільний приріст у 20%. Якби ми одразу очікували на такий приріст, то планували б проводити тест 8 днів:

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

3. Ми запускали тест, щоб пересвідчитися, чи не буде проблем. Іноді А/В-тести запускають для перевірки того, чи не викличе нова крута функція несподіваної негативної реакції в користувачів.

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

❗️ Rule of thumb: більше слідкувати за трендом, ніж за результатом в моменті. Якщо статистична значущість росте з кожним днем тесту і це відбувається протягом тривалого часу, ризики зменшуються і можна задуматись над закриттям тесту.

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

Порада № 6: Знай, коли А/В тест не потрібен

Одне з правил, як пришвидшити тести, — не запускати непотрібні.

Для цього корисно відповісти собі на такі питання:

  • Чи потрібна для перевірки вашої гіпотези однорідна аудиторія? Іноді наші гіпотези направлені на розширення аудиторії, а не на оптимізацію роботи з нинішньою.

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

    Так ви перевірите не лише перформанс воронки, а й можливість залучити новий тип аудиторії на продукт.

  • Чи вірите ви в те, що ця зміна взагалі може дати мінус? А/В-тести не повинні керувати вашими рішеннями. Так, важливо перевіряти свої гіпотези за допомогою даних, але деякі рішення точно можуть бути прийняті й без тесту.

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

    1. Запустити тест з нижчим рівнем бажаної статистичної значущості (наприклад, 80% замість звичних 95%).
    2. Закривати тест раніше строку за наявності сильного позитивного тренду, що продовжується довгий час.
    3. Провести зміну в продукті без тесту, а потім оцінити її ефект за схожими когортами користувачів.
  • Чи можна провести якісне дослідження, щоб провалідувати реалізацію гіпотези на ранньому етапі? Багато ідей можна відсіяти ще до етапу розробки.

    Допомогти з цим можуть якісні дослідження: інтерв’ю з користувачами, UX-тести, прототипування. Якщо провести їх до кількісного дослідження, можна завчасно зрозуміти недоліки вашої реалізації гіпотези та допрацювати її.

    Це потребує часу, але все ж менше, ніж проведення цілого А/В-тесту даремно.

  • Чи корелює цей тест з цілями команди? Найважливіші тести — ті, що допоможуть вам досягти своїх цілей.

    Іноді існує спокуса проводити «nice to have» тести, що не відповідають реальним цілям команди. Наприклад, ваш пріоритет на період — знайти оптимальну модель монетизації для продукту. У такому випадку тести на текст кнопки, ілюстрації на воронці або ретеншн можна відкласти.

Порада № 7: Зберігай правильний майндсет

Процес А/В-тестування — це чудова можливість експериментувати, ризикувати й реалізовувати ідеї, що приводять продукт до успіху.

Проте важливо розуміти обмеження цього інструменту, а також ставитися до нього як до постійного джерела можливостей для розвитку:

1. Генерувати нові гіпотези за будь-яких результатів тесту. Навіть ті А/В-тести, що дають негативний ефект, корисні. Часто такі результати можуть наштовхнути вас на навіть крутіші гіпотези та сильно змінити уявлення про поведінку користувачів.

2. Розуміти, що тестується конкретна реалізація гіпотези, яка може бути невдалою. Рідко за результатом одного тесту можна однозначно встановити, правильна гіпотеза чи ні, адже сама реалізація може бути невдалою. Водночас сама гіпотеза все ще має право на існування.

3. Ставитися до А/В тесту як до підказки, а не замінника прийняття рішень. Тестування дозволяє знизити рівень невизначеності, але не отримати однозначну відповідь.

Результат А/В-тесту показує нам ймовірний ефект від змін, проте не відповідає на питання, чому такий ефект відбувається. Найкращий льорнінг отримується з комбінації різних методів досліджень (кількісного і якісного), аналізу і критичного мислення.

4. Вести базу гіпотез і тестів. Щоразу, коли ми в компанії проводимо тест, ми фіксуємо всю інформацію про нього в базі знань Notion:

  • Яка команда проводила та коли.
  • На якому продукті та місці воронки.
  • Гіпотези, опис тестових груп та змін.
  • Базова конверсія, очікуваний приріст, розмір вибірки, прогнозована довжина.
  • Посилання на дизайн, аналітичні дашборди, підрахунки.
  • Результати, льорнінг та кінцеве рішення.

Це допомагає створити архів з інсайтами, до якого можна згодом повертатися за ідеями для нових тестів, а також підтримує дослідницький дух та прозорість інформації в команді.

5. Be Bold! Це один з важливих принципів, яким я користуюсь. Він про те, щоб бути сміливим, не боятися ризикувати й помилятися. Вважаю, що це дуже актуально і для А/В-тестування.

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

Так, завжди будуть помилки, проте слід ставитися до них, як до ще одного інструменту для навчання й розвитку. Як казав майстер Йода: «The greatest teacher, failure is». Тож закликаю вас ризикувати, помилятися, ще раз ризикувати — та вчитися у процесі. Адже сміливі завжди мають щастя.

Висновки

Отже, щоб пришвидшити запуск і закриття А/В-тестів на ранніх етапах розвитку продукту, слід:

  • Розуміти, як довжина тесту залежить від параметрів розрахунку.
  • Обирати для оцінки метрики з вищими базовими конверсіями.
  • Запускати тести з високим мінімальним очікуваним ефектом.
  • Використовувати паралельні тести.
  • Усвідомлено закривати тести раніше строку.
  • Запускати тільки необхідні А/В тести.
  • Розуміти обмеження цього інструменту і не боятися помилок.

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

цікава стаття, корисні поради!

Дякую, що ділитесь досвідом!

Класна та пізнавальних стаття

Крута і пізнавальна стаття! Дякую.

Підписатись на коментарі