Як ми налаштували систему A/B тестування та перейшли на GrowthBook

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

Усім привіт! Мене звати Євгеній Гончаренко, я маю 9 років досвіду у фронтенд-розробці — до речі, за свою карʼєру працював тільки в продуктових компаніях. Зараз займаю позицію Front-end Lead у Howly — одному з бізнесів венчур-білдера SKELAR. Всередині Howly ми розвиваємо декілька продуктів у сфері онлайн-консультацій, а також повʼязаних з роботою з документами.

Я щиро вірю, що кількість перетворюється на якість. Зрозуміти це мені допомогли 250 A/B тестів, які ми в Howly запустили минулого року. Деякі з них не виправдали наших очікувань, але ми отримали класні інсайти — наприклад, що не все з тестувань варто впроваджувати.

Для чого необхідне A/B тестування

Основна ідея A/B тесту — розділити користувачів на декілька груп (контрольна та одна або більше тестових варіацій) і спостерігати, наскільки та чи інша варіації покращують ваші метрики. При цьому трафік між групами зазвичай розподіляється рівномірно, але це може змінюватись. Є підходи в тестуванні, в межах яких відсоток користувачів у групі динамічно коливається. Це залежить від того, яка група перформить краще. І в такій групі частка юзерів може автоматично зростати.

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

В чому можуть допомогти A/B тести:

• Оптимізувати конверсію та UX. Навіть незначні оновлення, як-от зміна кольору кнопки або переміщення форми реєстрації, може вплинути на досвід користувачів як позитивно, так і негативно. Щоб потестувати це, необхідні A/B тести.
• Впроваджувати нові функції без ризиків. Так, ви можете самостійно додати дуже корисний на вашу думку функціонал, але після релізу зʼясується, що для користувачів це не так. Тому краще будь-які оновлення запускати A/B тестами — викатувати поступово на обмежену групу людей і після збору метрик переконатись, чи варто розкатувати його далі.
• Перевіряти гіпотези перед масштабуванням. Якщо ви користуєтеся застосунком Sentry для моніторингу багів, то могли помітити, що вони додали кнопку «спробувати новий UI». Так от, мені дуже складно знайти людину, кому б це оновлення сподобалось. Тож якби Sentry викатили новий UI одразу для всіх користувачів, думаю, що чимало юзерів шукали б новий сервіс. Великі зміни краще релізити поступово: зібрати фідбек від частини користувачів, покращити нову версію, а не поспішати відкрити для всіх те, що ви з командою створили.

Що важливо врахувати перед запуском A/B тестів:

1. У вас має бути достатній трафік. Щоб отримати якомога точніші результати, потрібно зібрати більше статистики, даних від користувачів. Якщо я підкину монетку всього 3 рази й 2 з них випаде орел, це не дає змоги стверджувати, що зі ймовірністю 66% випадає орел.
2. Вам слід чітко сформулювати гіпотезу. «Ми хочемо спробувати новий дизайн» — не звучить як класна гіпотеза, тому що вона не дає розуміння, чого ви хочете досягти. Можна сформулювати гіпотезу так: «У новому дизайні ми зробили більший фокус на форму реєстрації. Це потенційно має вплинути на кількість конверсій, тому ми очікуємо підвищення Conversion Rate на 10%». Така гіпотеза — ефективна, тому що з неї випливають ключові метрики, на які ви будете дивитися й, відповідно, аналізувати результати A/B тестів.
3. Важливо вибрати правильні метрики. Наприклад, якщо ви покращуєте UI та користувач почав довше перебувати на вашій сторінці — це може негативно вплинути на кінцеву конверсію. Тому, крім очевидних речей, які ви хочете перевірити, важливо не забувати про ключові KPI бізнесу.

Як ми вибирали інструмент для A/B тестування

Раніше в Howly ми користувалися сервісом Google Optimize, запускали тести лише на фронтенді, а всі зміни відбувалися на клієнті. Який вигляд це мало: в користувача завантажується сторінка, ініціалізується Optimize, юзер потрапляє в одну з груп і UI може дещо змінитися. Тоді процес A/B тестування в нас не був ретельно розбудований, тести проходили як звичайні завдання. Так було до осені 2023 року, коли Google Optimize припинив роботу.

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

16-17 травня, Київ. Квитки тут!👇

• Ми знали, що хочемо запускати тести також на бекенді. Наприклад, щоб перевірити різні флоу імейлів або поведінки юзерів після реєстрації.
• У пріоритеті було зробити так, щоб і на бекенді, і на фронтенді ми змогли використовувати один сервіс.
• Потрібно було покращити UX користувача, щоб уникнути кейсів, коли юзер бачить одну версію сторінки, а потім вона в реальному часі змінюється. Щоб користувач бачив необхідну варіацію одразу, ми мали стартувати запуск тестів на SSR.
• Оскільки ми активно масштабувалися, нам була необхідна гнучка система таргетування, щоб мати інформацію, з якої країни користувач, з телефону чи з десктопу він зайшов на сторінку тощо.

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

Чому ми зрештою обрали GrowthBook

1. Відкритий код. Це значить, що GrowthBook можна використовувати як SaaS-рішення, так і на власному вебсервері.
2. Легка інтеграція. Він має готові SDK для робити з React та з Next.js, дозволяє запускати тести як на SSR, так і на клієнті.
3. Проста інтеграція з Go. Бекенд у нас на цій мові, тож команда сказала, що без проблем зможе інтегрувати GrowthBook у кодову базу.
4. Безплатна базова версія. У ній є обмеження на кількість запитів та користувачів, однак ми понад рік користувались безплатною версією — її вистачало навіть на наших масштабах.
5. Підтримка Feature Flags. GrowthBook можна використовувати не тільки для A/B тестування, а і як систему Feature Flags, щоб закривати певний функціонал, добре протестувати й лише після цього показувати користувачам.

Таргетування та налаштування в коді

Оскільки бізнес зростав, нам було необхідно розділяти користувачів і запускати тести лише на певні групи. В адмінці GrowthBook можна засетапити ті атрибути, які точно будуть лежати в інстанці. Тому в UI наші продакти та маркетологи можуть без розробників налаштувати звичайний drug & drop, drop down і таке інше. Там можна вибирати країни, девайси, звідки прийшов користувач, на якій він сторінці тощо.

А якщо цього мало або продакти не хочуть цим займатися, GrowthBook також підтримує MongoDB query syntax, що дозволяє все дуже гнучко налаштувати.

На диво для світу JavaScript, у коді все працює так, як написано в документації. Ми на SSR збираємо необхідні атрибути користувача, ініціалізуємо наш GrowthBook, запускаємо необхідні тести та повертаємо ці дані на клієнта.

Далі вони перекидаються в контекст, відбувається гідрація і той html, який згенерувався на SSR, гідрується в такий самий на клієнті.

Для цього не потрібно ніякої rocket science — все працює на GrowthBook Provider.

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

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

Запити бізнесу на A/B тести, які стали викликами

Поділюся з вами улюбленим — історіями, як ми справлялися з челенджами, щоб налаштувати процес A/B тестувань, запускати сепаровані тести на бекенді та фронтенді та збирати більше даних про користувачів.

Кейс № 1. Після деяких простих A/B тестів продакти приходять до нас з ідеєю: «Хочемо запустити тест на бекенді, але щоб на фронтенді також щось змінилось».

Що ми зробили? У нас на бекенді вже був сервіс аналітики, в який ми відправляли дані про те, в який експеримент потрапив користувач. Тоді ми подумали, чому б не спробувати не тільки відправляти дані в цей сервіс, а також їх отримувати. Так на фронтенді ми почали спиратися на лише на GrowthBook, а й на бекенд. Тобто, перш ніж запустити A/B тест, ми запитували в бекенда, чи конкретний користувач не потрапив в іще якийсь експеримент. Якщо знаходили виключні A/B тести, ми його навіть не стартували.

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

• Спиратися лише на GrowthBook.
• Тільки на бекенд.
• Комбінувати GrowthBook та бекенд.

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

Кейс № 2. Бізнес каже: «Нам потрібно запустити експеримент Х, але тільки за умови, що користувач не потрапив в експеримент Y. Звісно, в мене виникло запитання, чому б не запустити ці експерименти паралельно. Відповідь на нього я періодично повторюю собі вголос: необхідно збирати більше даних. Уявіть, що ви хочете запустити на сторінці один A/B тест, який змінює колір кнопки, і другий A/B тест, який змінює текстовку цієї кнопки. Якщо запустити їх одночасно, у вас вийде 3 групи користувачів:

1. Які побачили лише змінений колір.
2. Які побачили лише змінений текст.
3. Які побачили одночасно і ту, й іншу зміни.

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

Що ми зробили? Використали дуже класну фічу GrowthBook — namespaces. Це така собі віртуальна сутність, яку ви можете створити й додавати в неї необхідні експерименти. І вже сам GrowthBook гарантує, що користувач потрапить лише в один namespace.

Також ми написали власну логіку. На перший погляд, namespaces було достатньо, але це обмежувало кількість користувачів, які потрапляють у необхідні експерименти. Наприклад, якщо в namespace є 2 групи користувачів у 2 експериментах, то виходить, що зі 100 користувачів, які заходять на сайт, лише 50 потраплять в експеримент Х. А з них тільки 25 потраплять у тестову групу. І якщо цей namespace не зайнятий повністю, то в нас залишається частина користувачів, які взагалі нікуди не потраплять. Цей варіант не оптимальний, адже нам потрібно проводити якомога більше експериментів.

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

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

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

Що ми зробили:

• Відокремили частину фронтендів в окрему команду, яка фокусувалась на запуску A/B тестів на нашій воронці.
• Покрили аналітикою всю воронку, починаючи від того, куди юзер проскролив і на що клікнув до того, на чому зупинився та на що звернув увагу. Завдяки цьому ми маємо якісну інфо по всіх метриках та ухвалюємо більш зважені рішення.
• Налаштували дашборди. Коли A/B тест запускають без інженерів та аналітиків, вони одразу зʼявляються в нас на дашбордах і можна з першого дня дивитися висновки. За це команді аналітиків величезна вдячність!
• Реалізували віджетну систему на воронці — зробили такий собі wix на мінімалках ;) У нас є адмінка, в якій можна динамічно створювати необхідні сторінки, конфігурувати, які саме елементи на ній будуть, і задавати контент. Раніше це працювало так, що потрібно було вказати: «Якщо юзер у цьому експерименті, то зроби кнопку синьою». А ми зробили так, що кожен експеримент — заміна цього файлу конфігурації. Також на бекенді та на фронтенді ми додали логіку в ці конфіги: перед тим, як фронтенд отримує конфіг з бекенд-сервісу, він уже перевіряється в GrowthBook, чи не потрібно цей конфіг змінити.
• Завдяки пункту вище додали можливість запускати експерименти без залучення розробників — у нас цим може займатися команда маркетингу або PM.

Інсайти з відпрацьованих A/B тестів

В одному з тестів ми додали Google/Apple login — здавалося, що ці дві кнопки є на більшості сайтів, тому це має бути дуже зручно для користувачів. Важко уявити людину, в якої немає Google- чи Apple-акаунта, але серед кількох сайтів і їхніх десктопних та мобільних версій цей тест переміг лише в одній. А на всіх інших після додавання цього функціоналу метрики погіршились. Це переконало мене в тому, що будь-яку зміну, якою «хорошою» та обовʼязковою вона вам не здавалась б, краще запускати через тестування.

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

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

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

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

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

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