Мене звати Артем Дрей, я займаюсь Frontend-розробкою в venture builder SKELAR. Ми будуємо продуктові IT-бізнеси на західні ринки. В процесі у нас як правило з’являється багато ідей щодо покращення наших продуктів: додати нові фічі в інтерфейс, оновити механіку реєстрації або перемалювати форму оплати.

‍

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

‍

В цьому матеріалі я вирішив поділитися одним з наших кейсів про тестування двох варіантів форм оплати на фронтенді. Описую, як ми це проводили та як збирали результати.

‍

Проведення А/В тестування — теорія

А/B тест (спліт-тест) — це інструмент для прийняття рішень на основі даних. У процесі проведення тестування порівнюються дві версії одного й того самого продукту, різниця між якими лише в одному елементі. Так можна тестувати, наприклад: форму реєстрації, email-розсилку, ціни і т.д.

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

«0» — контрольна група юзерів, яка бачить продукт без змін;
«1» — група юзерів, які бачать змінений продукт (нові UI/UX, фічі, логіка).

‍

План А/B тестування на нашому кейсі — практика

У даному кейсі ми розберемо, як покращити форму оплати в продукті. Для цього юзеру відображаються pop-up для вибору пакета, після чого його переводить на крок оплати.

Для тестування була створена наступна гіпотеза: «Якщо зробити вибір пакета простішим та без зайвого інформаційного шуму, тоді конверсія в оплату збільшиться».

‍

‍

Платіжна форма ліворуч — відображається у групі «0», праворуч — у групі «1».

Механіка проведення тесту:

Реєстрація юзера на продукті.
Після реєстрації, за допомогою splitter-сервісу на backend відбувається розподіл юзера в одну з груп: «0» або «1».
З кожним запитом «me» отримуються дані по спліт-тесту.
Спираючись на цю інформацію, frontend відображає різні версії продукту.
Після збору й отримання статистично значущих даних, спліт-тест закривається на користь однієї з груп.

‍

Як ми організували проведення А/В тесту на фронтенді

Ділюся своїми напрацюваннями та фрагментами коду, які я використовував для розв’язання задачі.

‍

1. Звідки фронтенд дізнається про тест

При ініціалізації React застосунку спочатку відбувається запит me, після якого повертається інформація про спліт-тест: splits: []

idSplit — унікальний ідентифікатор cпліт-тесту.
splitGroup — група: «0» чи «1» (в даному кейсі розподіл трафіку 50/50).

‍

me: { id: 'ID_ME', // ..., splits: [ { idSplit: 'ID_SPLIT_TEST', splitGroup: '0', createdAt: '2022-12-17T10:11:54Z', }, ], },

‍

2. Створюємо додаткові компоненти, що будуть реалізовувати зміни в інтерфейсі/ логіці

У випадку якщо зміни мінорні, зробити це можна в рамках одного компоненту.

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

‍

‍

2.1. <PaymentPackage /> — компонент, який відображає деталі пакета (ціна, кількість валюти), після вибору якого переходимо на етап оплати (група «0»).

2.2. <SplitPaymentPackage /> — новий компонент з такою самою логікою, але іншим UI (група «1»).

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

‍

3. Імплементація A/B тесту

Далі в компоненті, який рендерить список пакетів, за допомогою getSplitTestById перевіряємо, чи знаходиться юзер в гуппі «1». Якщо так, то показуємо йому новий інтерфейс. У всіх інших випадках показуємо попередній.

getSplitTestById — утиліта, яка повертає дані спліт-теста по id. У випадку, якщо нічого не знайдено, повертається порожній стейт.

‍

‍

Рендеринг пакетів, спираючись на спліт-групу.

‍

Усі інші компоненти та фічі розгалужуються за такою ж самою схемою.

Результати тесту

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

В нашому кейсі переможцем стала контрольна група «0». Отже, наразі ми залишаємо продукт без змін допоки не виникне потреби в проведенні наступних тестів. Коли рішення прийняте, необхідно залишити один з варіантів реалізації та видалити весь зайвий код (в нашому кейсі для варіанту «1»).

‍

*Цей матеріал написаний спеціально для DOU.