Витиснути максимум з A/B тестів: як зекономити 40% часу та отримати в півтора раза більше цінності

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

Привіт! Я Катя, Product Analyst в компанії-платформі Kiss My Apps. У цій статті я поділюся підходами, які дозволяють суттєво скоротити час на проведення A/B-тестів і які ми вже активно використовуємо в роботі.

Всі ми знаємо, що A/B тестування — це фундаментальний інструмент для перевірки гіпотез. Однак проведення експерименту «за підручником» не завжди можливе, адже для бізнесів із середньою або малою базою користувачів може вимагати місяців очікування.

Наше портфоліо включає понад 30 застосунків із сумарною аудиторією 100M+ користувачів. Ми одночасно запускаємо нові застосунки й тестуємо окремі флоу та канали трафіку всередині великих продуктів, де реальна вибірка на старті може бути значно меншою. У таких умовах критичною стає не лише коректність, а й швидкість експериментів. Саме тому ми змушені переглядати класичні підходи та шукати способи «хакнути» систему.

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

Дисклеймер: одразу зауважу, що мова йтиме саме про конверсійні тести. Подібні методи можна застосовувати й до тестів, наприклад, на середні значення, але там з’являються додаткові нюанси, тож щоб не перевантажувати матеріал, зупинимось лише на одному класі метрик.

Ліричний відступ про розмір вибірки

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

• Сonfidence: ймовірність помітити ефект, коли насправді його нема (помилка I роду).
• Power: ймовірність задетектити ефект, коли він дійсно є (1 — помилка II роду).
• MDE: мінімальна різниця між варіантами, яку тест має шанс виявити як значущу. Як правило він є довільним і необґрунтованим. Тож більш уважний підхід до його вибору може суттєво скоротити час тестування.

Навіть невеликі зміни в цих показниках суттєво зменшують необхідний час на тест, але і призводять до більшої ймовірності помилок, особливо накопичених. В умовах стабільної обмеженості трафіку/часу саме баланс між цими налаштуваннями дозволяє контролювати ризики і приймати рішення швидше. Rule of thumb такий: конфіденс знижуємо з класичних 0.95 до 0.9, якщо тест перевіряє безпечну й дешеву у впровадженні зміну (наприклад, мінорні зміни в UI, CTA на екранах тощо), а рівень потужності з 0.8 до 0.75 — коли нас цікавлять лише значні ефекти і нам необхідно швидко тестувати наступні гіпотези.

То коли ж зупинятись завчасно

Перш за все, важливо заздалегідь визначити конкретні точки, у яких ми будемо «підглядати» за результатами та потенційно приймати рішення на основі неповної вибірки. Саме фіксовані чекпоінти дозволяють контролювати додаткову помилку I роду, яка виникає щоразу, коли ми дивимося на дані раніше, ніж припускає методологія класичного A/B тестування.

Рання зупинка прийнятна в кількох сценаріях:

• Негативний результат або його відсутність: Якщо тестовий варіант стабільно гірший або не демонструє жодної різниці з контрольним, на кожному чекпоінті ми оцінюємо, чи має результат шанс стати статистично значущим до завершення тесту. Для цього моделюємо решту вибірки та аналізуємо верхній перцентиль симуляцій — саме так це працює у нас. Якщо навіть у найбільш оптимістичному сценарії ймовірність отримати значущий результат близька до нуля, тест можна закривати завчасно.
• Надпозитивний результат: найбільш бажаний для нас кейс, але водночас найбільш чутливий до поспішних рішень, тож він вимагає строгішого обґрунтування. Тут підхід з симуляцією вибірки вже не зовсім підходить, але в загальних рисах ідея схожа: ми маємо вимагати значно жорсткіших умов, ніж стандартні p-value < 0.05.

Ще один важливий дисклеймер: тести бажано закривати достроково лише тоді, коли з моменту їх запуску минув принаймні один повний бізнес-цикл (зазвичай тиждень) з метою мінімізації впливу сезонності або ефекту новизни на результати.

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

Оскільки способів коригувати рівень значущості при кількох підгляданнях існує багато, а формули їхнього розрахунку виглядають доволі громіздко, я вирішила зупинитися на готовому рішенні зі статті. У ньому для кожної точки задаються фіксовані пороги, при перетині яких тест можна достроково закривати в той чи інший бік. Єдиний нюанс: такий дизайн вимагає збільшити початковий MSS приблизно на 10%, але фінальну вигоду все одно оцінюємо відносно тестів з фіксованою тривалістю. Далі я провалідую цей підхід на симуляціях у середовищі, максимально схожому на реальний трафік, щоб переконатися, що метод працює так, як нам потрібно.

Так виглядають межі для одностороннього тесту з 95% конфіденсом і 80% потужністю.
ВАЖЛИВО: для тестів з іншими попередніми налаштуваннями трешхолди набуватимуть інших значень

Валідація підходу послідовного тестування на синтетичних даних

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

• яка реальна економічна та часова вигода;

• чи дійсно зростає помилка I роду при кількох підгляданнях;
• як змінюється потужність тесту відносно класичного дизайну.

Перейдемо до методології.

Ми провели 10 000 симуляцій. Кожен тест базувався на наступних налаштуваннях:

• Базова конверсія P = 0.1 та MDE 0.01, що відповідає 10% відносному зростанню. Такий порядок конверсій є типовим для наших продуктів, і саме на такий відносний приріст ми найчастіше орієнтуємося, коли закладаємо очікуваний ефект у тестах.

• Всі запущені тести були односторонніми з рівнем значущості α = 0.05 та статистичною потужністю 0.8. Заздалегідь можемо зафіксувати MSS = 11.1 тис. на групу, який порахували в одному з калькуляторів, але також пам’ятаємо, що маємо збільшити його на 10% для відповідності до поправок.
• Щоб симуляція виглядала максимально наближено до реальності, справжній розмір ефекту у кожній симуляції генерувався випадковим чином. Для цього ми застосували розподіл Лапласа з масштабом, пропорційним MDE. Попередній рісерч показав, що така форма розподілу добре наближає розкид ефектів, яку ми спостерігаємо на продуктах: більшість змін дають малий або нульовий ефект, а помірно-позитивні та помірно-негативні «хвости» зустрічаються частіше, ніж, наприклад, у нормальному розподілі. Звісно, це не ідеальна модель, оскільки не враховує асиметрію розподілу та деякі інші нюанси, але з метою спрощення цим можна знехтувати.

Як виглядає симульований розподіл величини ефектів, я брала коефіцієнт 0.75

Перейдемо до огляду результатів.

У сукупності результати моделювання показують, що за заданої конфігурації послідовний дизайн дозволяє суттєво скоротити обсяг використаної вибірки. Спостерігається чітка залежність між напрямком ефекту та тривалістю тесту: гіпотези з негативним ефектом найчастіше зупиняються вже на 25-50% вибірки, а нейтральні — ближче до 60-70%. Тести з позитивним ефектом продовжують ранитись найдовше, але все одно досить рідко доходять до повного обсягу. У середньому симульований тест потребує лише 60% вибірки відносно класичного дизайну.

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

У моделюванні було оцінено два джерела отримання вигоди:

• уникнення втрат у разі невдалих варіантів;
• пришвидшений дохід у разі вдалих варіантів.

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

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

1. Перевірка на наявність хибнопозитивних результатів. Для цього було запущено 10000 симуляцій зі справжнім ефектом, близьким до нуля. У цьому сценарії статистично значущої різниці між контрольною та тестовою групами бути не повинно. Класичний односторонній тест показав частку хибнопозитивних результатів на рівні близько 5% (що відповідає заданому α = 0.05), тоді як для послідовного цей показник склав лише ≈1.5%. Тобто обрані пороги й поправки поводяться радше консервативно: проміжні «підглядання» не лише не збільшують ймовірність помилки I роду, а й додатково її зменшують.

2. Аналіз чутливості. Тут я змоделювала сценарій, у якому справжній ефект дорівнює MDE. У цьому випадку нас цікавить ймовірність коректно зафіксувати виграш тестового варіанта. Для класичного фіксованого тесту вона склала ≈0.784, для послідовного — ≈0.777. Різниця менша за 1 в.п. (не виключаю, що на зменшення різниці вплинула додаткова умова на збільшений MSS). Так чи інакше, перехід на послідовне тестування практично не знижує потужність тесту на рівні MDE, попри суттєве скорочення використаної вибірки.

Також додам, що й у цього підходу є свої обмеження:

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

Коли варто відмовитись від класичного A/B тестування (і що робити натомість)

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

Кейс: ми додали блок з особистісними тестами всередині застосунку, він не впливав на UI та відповідно не блокував доступ до інших фіч. Усього за кілька днів побачили, що лише 8% користувачів активно взаємодіють з новим функціоналом. При цьому фіча виявилась цінною з аналітичної точки зору, адже дозволила нам краще зрозуміти соціально-демографічний розподіл та додаткову інформацію про більш залучену аудиторію, що можна використовувати для оптимізації закупки. В цьому випадку ми призупинили тест і одразу розкатили тестовий варіант.

Щоб прийняти рішення без повноцінного запуску тесту, також існує багацько підходів:

• Використання проксі-метрик: вимірювання конверсій в проміжні дії замість цільової з метою збільшення значення бейзлайн-метрики. Наприклад, якщо інтернет-магазин має мало транзакцій на день, він може перевірити новий дизайн картки товару за приростом додавань в кошик. Також цей метод підходить для випадків, коли початкова таргет-метрика обчислюється з затримкою.
• Якісні методи: до них входять інтерв’ю та опитування юзерів, сешн-реплеї, аналіз конкурентів (або апок в одній категорії в нашому випадку).
• Квазіексперименти: до них входять такі методи, як Interrupted Time Series (показники контрольної групи прогнозуються, тестова група викатується одразу, потім порівнюється прогноз та фактичні значення), аналіз до-після тощо.

Висновок

Процес тестування можна суттєво прискорити, якщо свідомо підходити до нього ще на етапі дизайну: обирати реалістичний MDE, гнучко налаштовувати статистичні параметри та використовувати послідовне тестування. Водночас важливо підкреслити, що послідовне тестування не є заміною класичного A/B-тестування. Воно має власні обмеження та ризики, описані вище, і повинно застосовуватись як додатковий інструмент у сценаріях обмеженого трафіку або часу, а не як універсальний стандарт для всіх експериментів. Для конверсійних метрик цей підхід часто економить до ~40% вибірки, бо дає змогу зупиняти очевидно програшні або нейтральні тести раніше з мінімальними втратами у строгості.

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.