Як провести своє перше А/В-тестування

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

Всім привіт! Я Ліза, Product Analyst в Kiss My Apps. У цій статті я поділюсь своїм досвідом та переліком кроків для проведення успішного A/B-тестування.

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

Не зважаючи на критичність таких рішень, частина з них все ще базується на HIPPO — Highest Paid Person’s Opinion. Це коли ключові рішення у бізнесі ухвалює людина з найбільшим впливом та найбільшою зарплатою, а на дані та аргументи аналітиків (якщо такі є в команді) при цьому не зважають. Чи варто уточнювати, що такий підхід Data-driven не назвеш ну зовсім?

Окей, ми не хочемо спиратись на бегемотів й маємо на меті приймати лише зважені data-driven decisions. То як це робити?

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

Якщо коротко, мета A/B-тестування — зменшити невпевненість під час прийняття рішення і відповісти на питання: «Чи варто нам впроваджувати зміни, які за нашими очікуваннями позитивно вплинуть на продукт?».

Яким чином ми це робитимемо? Випадково розділимо користувачів на дві групи, де перша бачитиме поточний (бейзлайн) варіант продукту, а друга (тестова), бачитиме варіант зі змінами, які плануємо вносити. Якщо зміни у поведінці юзерів тестової групи статистично значущі та відповідають заявленим у гіпотезі припущенням — впроваджуємо їх. As simple as that! Чи ні?

Просто провести A/B-тест мало, його потрібно провести коректно. Для того, щоб тест можна було вважати якісним, варто пам’ятати декілька правил і слідувати за алгоритмом.

1. Визначтесь з метою і засобом тестування

Експерименти, які ми проводимо в Kiss My Apps, у своїй більшості поділяються на монетизаційні та retention-тести. Мета перших — підвищити прибуток компанії, других — покращити користувацький досвід та змотивувати юзера залишитися в нашому застосунку довше. Від мети залежить вибір подальших метрик та пріоритет тесту.

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

2. Оберіть метрику

Вибір метрики для A/B-тесту має базуватись на цілях, характері змін, які ви тестуєте, та на якому етапі шляху користувача ці зміни буде впроваджено. Ось кілька прикладів сценаріїв, в яких вони можуть бути застосовані:

• Ви тестуєте різні дизайни пейволів з однаковими підписками. Ми очікуємо, що на новому пейволі краще донесли цінність продукту й більше користувачів оформлять пробний період застосунку. Тож основна метрика — конверсія в пробний період, додаткова — конверсія в покупку.

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

• Ви тестуєте новий тип підписки (зміна вартості, тривалості) — найскладніший варіант. Очевидні відповіді — конверсія в покупку, середній дохід на платного користувача. Неочевидні, але більш відповідні — метрики які враховують і зростання конверсії, і зміни в ARPPU = ARPU. Рішення за таким тестом не вийде ухвалити одразу, доведеться дочекатись поновлень підписки серед когорти та порівняти retention :)

Пам’ятайте, що варто звертати увагу не тільки на основну метрику при формуванні висновків, але таргет-метрика — основа вашої гіпотези, про це далі.

3. Сформулюйте гіпотезу

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

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

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

{генеральний параметр} — {його значення, що тестується} = 0. Нуль у цьому твердженні й дав назву гіпотезі :-).

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

Все це звучить дуже круто, але на практиці гіпотези генерує продакт-менеджер, якому зовсім не цікаві твої генеральні параметри, він згенерує лише продуктову гіпотезу. Тому слід скористатись підказкою:

• Статистична гіпотеза: Мета — визначити, чи є статистична відмінність між групами, що може або не може мати практичне значення.
• Продуктова гіпотеза: Мета — припустити, які зміни в продукті чи послузі можуть призвести до покращень в певних метриках чи функціях.

Ідеальна продуктова гіпотеза — чітка, зрозуміла та вже містить в собі основну метрику, наприклад:

H0 = При зміні дизайну кнопки з варіанту А на варіант Б конверсія з показу екрана у натискання кнопки не зміниться.

H1 = При зміні дизайну кнопки з варіанту А на варіант Б конверсія з показу екрана у натискання кнопки збільшиться на 10%, з 15% до 16,5%.

4. Залиште собі право на помилку

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

Перевіряючи статистичну гіпотезу, слід памʼятати про два види помилок:

• Помилкою першого роду називають таку, яка полягає у відхиленні правильної нульової гіпотези, false alarm. Імовірність такої похибки називають рівнем значущості та позначають α.
• Помилка другого роду — ситуація, коли альтернативний варіант кращий за дефолтний, проте в тесті ми цього не виявили відхиляємо його. Імовірність такої похибки позначають β, а величину 1 — β називають потужністю критерію.

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

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

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

5. Розрахуйте розмір вибірки

Впевнена, ви вже не раз це чули, але навіщо це робити? Відповідь ви вже теж чули — щоб запобігти проблемі підглядання... Річ у тім, що на різних етапах «життя тесту» (20% семпл сайзу, 50% і 100%) ймовірність перемоги тої чи іншої групи може кардинально відрізнятись. Поспішні висновки можуть спровокувати непередбачувані наслідки.

Щоб цьому запобігти, необхідно завчасно визначитись з кількістю користувачів, які нам потрібні для прийняття неупередженого рішення. Для цього необхідно використати задані раніше параметри: рівень значущості α, статистичну потужність 1 — β, відоме значення цільової метрики та бажаний мінімальний апліфт = Minimum Detectable Effect. MDE — відсоток зміни метрики, при досяжності якого ми вважаємо зміни значущими. Для монетизаційних метрик все так само, лише додатково варто розрахувати розмах варіації метрики (дисперсію).

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

P.S: відоме значення цільової метрики ≠ рівню метрики у контрольній групі. Це середнє значення метрики в вашій цільовій аудиторії перед впровадженням змін. Baseline conversion rate ≠ conversion rate(A).

6. Зберіть дані та зупиніть тест

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

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

7. Проаналізуйте результати

Уявімо, що все супер і ви вирішили проводити тест до кінця (до того, як набереться семпл сайз). Саме час обрати метод аналізу. Від типу обраної основної метрики залежить тип тестування та статистичний критерій для аналізу.

Головне, що нас цікавить, це p-value. Його значення дорівнює ймовірності отримати спостережуваний результат, якщо нульова гіпотеза є правильною. Що менший p-value, то сильніше докази проти нульової гіпотези. Якщо p-value менший заданого рівня значущості α, то ми відкидаємо нульову гіпотезу і приймаємо альтернативну.

Дізнатись ймовірність того, наскільки випадковий результат нашого експерименту можна, використавши різні статистичні критерії. Як вибрати відповідний до типу метрики — дивіться в наступних випусках (не все ж смачне одразу).

8. Оберіть переможця та зробіть висновки

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

Головне — комплексно оцінити експеримент. Якщо ви змінили монетизаційну стратегію (додали нову підписку), обов’язково зверніть увагу на retention і зробіть висновки щодо ролауту за деякий час. Можливо, всі метрики підросли, а відгуки в сторі погіршились? Це теж наслідок тесту. Рішення не може бути прийняте виключно на основі p-value, потрібно брати до уваги контекст, додаткові метрики та здоровий глузд.

Важливі правила

☐ Яку метрику ви обрали основною — за нею і розраховуйте семпл сайз — за нею і закривайте тест, але беручи до уваги зміни у другорядних метриках.

☐ Не змінюйте основну метрику посеред тесту (тільки якщо ну прям дуже треба).

☐ Враховуйте сезонність застосунку, свята та інше при проведенні експерименту.

☐ Повертайтесь до закритих тестів, в яких ви не повністю впевнені, щоб переконатись у правильності рішення.

☐ Сегментуйте юзерів.

☐ Не тестуйте ризиковані гіпотези на великому обʼємі трафіку, якщо він варіативний залежно від джерела.

☐ Розробники та дизайнери теж беруть участь у запуску експериментів. Порадьтесь з ними, можливо у них є інсайти та поради стосовно технічної реалізації

☐ Не довіряйте репутації Баєса.