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

1. Визначіться з тим, що вам потрібно тестувати

(І тестуйте тільки те, що справді необхідно)
В ідеальному всесвіті ми могли б тестувати всі наші зміни в UI/UX і нові продуктові фічі. Але кожне тестування потребує ресурсів:

• Розробка, аналітика, планування — час ваших колег, котрий варто б витрачати на проекти та задачі з високим ROI.
• Швидкість доставки оновлень продукту. Доки ви тестуєте дизайн-елементи або продуктові фічі, інші важливі розробки чекають в беклозі.

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

1. Можуть негативно вплинути на роботу продукту, customer satisfaction чи revenue. Наприклад, зміна ключових функцій продукту або білінг моделі.
2. Можуть суттєво позитивно вплинути на конверсії чи інші цільові показники, і вам важливо дізнатися, в якій мірі. Наприклад, ви тестуєте надання безкоштовних консультацій на онбординга всім новим користувачам, і хочете дізнатися чи вартує результат часу customer success.
3. Зміни, тестування котрих не блокує інші важливі тести та потребує незначну кількість ресурсів, але такі, що з часом кумулятивно матимуть значний позитивний вплив на цільові показники.

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

З іншого боку, постійне тестування з метою поступового покращення показників має сенс, якщо ви вже подолали шлях від нуля до одиниці і маєте ресурси для середньо- і довгострокових ініціатив. Десять оновлень продукту, кожне з яких збільшує engagement на 10%, сумарно забезпечать буст активності у 2.5 рази. Так само, якщо ви досягли доволі високих конверсій і retention rate, варто тестувати оновлення інтерфейсу аби уникнути зниження показників.

2. Пересвідчіться, що у вас вийде провести тест

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

Ця порада виглядає банальною. Але, по-перше, якщо у вас поки що не знімаються деякі цільові показники, не факт, що наразі є інженерна можливість їх рахувати. По-друге, треба бути впевненими, що виміри ви можете провести для кожної з груп окремо. Наприклад, ви хочете запустити тест на веб-сторінці вашого продукту з метою зниження churn rate. Чи зможуть ваші інженери зв’язати дані відвідуваності сторінок з даними revenue? Далеко не завжди відповідь — “Так!”.

До запуску тесту подивіться на актуальні значення цільових метрик. За допомогою будь-якого “ab test planning calculator” що ви знайдете в Гуглі, порахуйте орієнтовну кількість часу або кількість користувачів, потрібну для того щоб зробити висновки. Якщо вам потрібно буде проводити тест кілька місяців, ймовірно, воно того не варте. Загальне правило: чим нижчий показник цільової конверсії, тим довше вам доведеться проводити тест. Будь-який буст на конверсії 20% ви побачите значно швидше, ніж на конверсії 2%.

3. Якщо не впевнені, діліть користувачів 50:50

Розділяйте користувачів порівну між контрольною та тестовою групами. Це дозволить вам швидше отримати статистично значущий результат. Змінювати пропорції має сенс у двох випадках:

1. Є значні ризики, що оновлення яке ви тестуєте негативно вплине на цільові показники або викличе невдоволення користувачів. В такому випадку зробіть тестову групу меншою, виділіть на неї 10-40%.
2. Ви майже впевнені, що оновлення покращить метрики, але хочете впевнитися, що вони нічого не зламають і що від них не буде неочікуваних негативних наслідків. Тоді виділіть на тестову групу 60-90%.

Чим більші ризики, тим меншою варто робити тестову групу. Чим вище ймовірність позитивного впливу — тим більшою.

4. Не нехтуйте правилами розділення користувачів на групи

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

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

5. Тестуйте на старих та нових користувачах окремо

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

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