Перевірено на людях, або Як і для чого починати A/B-тестування

Привіт, мене звуть Павло, я інжиніринг-менеджер у JustAnswer. Раніше — лід, перед тим — розробник. UMC, МТС, далі Conscensia й JustAnswer. Загалом уже майже 15 років в IT. Але маю дещо незвичний для розробника бекграунд: за освітою я соціолог. І це сильно допомагає під час роботи з продуктом — маркетинг, споживацька поведінка, розуміння бізнес-потреб. Останні чотири роки працюю в середовищі, де бізнес-рішення ухвалюються винятково після висування гіпотез та перевірки їх за допомогою A/B-тестування. Прилучився на стадії, коли складність гіпотез, які бізнес хотів перевірити, уперлася в стелю можливостей комерційної платформи A/B-тестування, що була в ужитку. І компанія постала перед вибором, куди рухатися далі.

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

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

Трошки конспірології

Чи бувало таке, що ви побачили дуже привабливу пропозицію на сайті перевізника, а коли наважилися бронювати квитки, пропозиція випарувалася? Або дуже вигідно взяли пробну підписку на музичний сервіс, а того ж дня ваші друзі не бачать такої опції. Чи, можливо, ви просто тепер бачите, що сайт Amazon на комп’ютері вашого колеги має інший вигляд, ніж на вашому? Можна припустити, що за вами стежить Старший Брат (як в Орвелла), що є велика змова проти простих користувачів Інтернету і ви стали її жертвою.

Але ймовірніше, ви просто стали учасником A/B-тестування. І так, за вами стежать!

A/B-тестування. Що це таке

Поняття «A/B-тестування» походить з традиційного маркетингу і є по суті методом дослідження, під час якого контрольні елементи (варіація A) об’єкта — пакування продукту, рекламного оголошення, вебсторінки тощо — порівнюються з подібними (варіація B), у яких один або кілька елементів змінено, для того щоб з’ясувати, які зі змін поліпшують цільовий показник (Wikipedia).

А можна простіше

Якщо зовсім просто, то для того, щоб дізнатися, чи насправді нову червону кнопку натискатимуть частіше, ніж стару синю, треба в той самий період часу одній половині відвідувачів показувати червону кнопку, а іншій — синю. І спостерігати. У такому разі контрольною групою будуть люди, які бачили стару синю кнопку (варіацію А). Мета тесту — порівняти їхню поведінку з поведінкою тих, хто бачив нову червону кнопку (варіацію B). Звідси й назва — A/B-тестування. Якщо одночасно хочуть перевірити більше варіантів змін, варіацій може бути більше. Тоді тест можуть позначати A/B/C/D/../N. Хоча найтиповішим усе ж є A/B. Кому показувати, які варіації та скільки спостерігати, теж не зі стелі беруть, але про це згодом.

Навіщо ті всі складності

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

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

На противагу традиційному підходу A/B-тестування дає змогу:

1. Змінімізувати ризики, тому що гіпотетичне поліпшення буде доступне мінімальній кількості відвідувачів, достатній для ухвалення рішення щодо корисності гіпотези. Тут стає в пригоді математична статистика, яка дає змогу підрахувати розмір вибірки. На ці теми не одну дисертацію захистили, але формули відлякують читачів, тому просто скажу, що в онлайні є чимало калькуляторів, за допомогою яких можна це підрахувати. Наприклад, можна почати з простого: A/B Test Sample Size Calculator.
2. Заощадити десятки людино-годин, бо є змога перевірити гіпотезу, опускаючи певні кейси або не імплементуючи фічу сповна. Наприклад, для тесту щось можна захардкодити на фронтенді, не імплементуючи колів на бекенд або не витягаючи якісь дані з бази, або не впроваджувати підтримку якихось екзотичних браузерів. Приклад: щоб перевірити гіпотезу, що продажі зростуть, якщо додати підтримку нової платіжної системи, перш ніж інвестувати саме в розробку такої можливості, можна додати саму кнопку «Заплатити через Х» і рахувати, скільки людей її натискають, щоб зрозуміти, чи це матиме попит. А тим, хто її натиснув, показувати повідомлення з вибаченням. Такий підхід ще називають Demand Test, або перевірка попиту.

А, B та їхні друзі

Перш ніж перейти до практики й уникнути плутанини, варто зупинитися на базовій термінології.

• Поняття A/B-тестування й експеримент взаємозамінні в контексті цієї статті.
• Вигляд сторінки до застосування змін називають контрольним (control) або нормальним (normal). Саме з ним порівнюватимуть тестовий, змінений вигляд (test).
  І control, і test — варіації (variation), що заведено позначати літерним індексом. Контрольна варіація А й тестова варіація B.
• Якщо гіпотезу підтверджено, і ми хочемо повністю замінити оригінальний вигляд сторінки виглядом варіації, що виграла, цей процес називають нормалізацією.
• Збір інформації про взаємодію користувача з елементами сторінки називають трекінгом (tracking). Наприклад, ми хочемо зафіксувати, якщо користувач натиснув кнопку. Нам треба зареєструвати унікальний ідентифікатор, пов’язаний із цією подією. Простими словами — додати трекінг.

Готуємо A/B-тест власноруч

Але досить голої теорії. Починаймо з’ясовувати.

На ринку є чимало достойних комерційних рішень зі своїми перевагами й недоліками для тих чи інших випадків і з різною ціновою політикою: Optimizely, VWO, Google Optimize, Adobe Target тощо. Проте, якщо A/B-тестування стають невіддільною частиною процесу розробки й ухвалення бізнес-рішень компанії, згодом її потреби, безумовно, переростуть будь-який наявний продукт і потребуватимуть власних підходів. Тому в цьому матеріалі ми спробуємо з’ясувати, як воно працює, тримається купи та як можна розробити прототип платформи A/B-тестування, щоб ухвалити поінформоване рішення про вибір платформи.

Інгредієнти

Проаналізуймо складові процесу тестування й підготовлення експерименту.

Трафік

Потрібні користувачі. Без користувачів увесь цей задум не має сенсу. Користувачів треба багато. Але вони нам потрібні не всі, а особливі. Тому трафік загрібати бажано не весь, а таргетований. Наприклад, гіпотеза про розширення бізнесу в США — нам не дуже цікаво, як відреагують на зміни відвідувачі з Європи. Або нам цікаво, як поводяться люди, що перейшли з конкретної реклами чи переглядали наші сторінки з мобільного. Тобто трафік треба відфільтрувати.

Випадковість

Важливо рівномірно й випадково поділити трафік між варіаціями. Кому дістанеться досвід А, а кому — B (або C, або D тощо, залежно від кількості варіацій)?

Трансформація

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

Відтворюваність

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

Відстеження активності

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

Гнучкість

Серед переваг A/B-тестування — гнучкість і динамічність. Запуск або зупинка тесту мали б відбуватися незалежно від релізу змін у продукті. Бажано навіть без участі інженерів. У процесі експерименту можуть виникнути обставини, коли тест тимчасово треба поставити на паузу або скоректувати параметри аудиторії.

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

Що під капотом

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

Ці підходи можна умовно поділити на Client Side (або Postload) і Server Side (або Preload).

Client Side

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

Архітектура

Є цільова сторінка. Сторінка завжди завантажує і намагається виконати JavaScript-файл, що хоститься окремо й може містити код A/B-тесту. Якщо ми тепер нічого не тестуємо, то файл просто буде порожнім.

Наша мета — виконати цей код якомога раніше в ході циклу завантаження сторінки й зробити трансформації до того, як завантажився оригінальний контент. Можна підписатися на DOMContentLoaded або load-івенти, наприклад, залежно від структури оригінальної сторінки й складності тесту.

Код A/B-тесту робить таке:

1. Фільтрує трафік (опційно) — ухвалює рішення, чи є поточний відвідувач нашою цільовою аудиторією. Пристрій, браузер, розмір вікна, країна користувача, залогінений, історія покупок, чи вже є щось в кошику, на якому тарифному плані, які сторінки бачив перед тим тощо. На практиці це просто ifCondition, який виконує ряд перевірок і вирішує, чи застосовувати трансформації. Можна навіть додатковий запит на бекенд від імені користувача надіслати, щоб отримати деталі, потрібні для ухвалення цього рішення. Це може суттєво затримати виконання трансформацій, але деколи це єдиний спосіб перевірити гіпотезу.
2. Визначає, чи користувач уже був на нашому тесті і йому слід показати відповідні зміни, чи це новий користувач, і треба призначити варіацію. Робимо це через cookie і рандомізацію.
3. Виконує потрібні трансформації. Тобто перефарбовує, змінює розміри й положення елементів, усуває їх чи замінює на інші.
4. Додає трекінг (опційно). Тут варто наголосити, що як до експерименту ми не цікавилися взаємодією користувачів із цільовими елементами, то доведеться додавати трекінг цих елементів і до оригінальної варіації також, щоб мати змогу ці варіації порівняти.

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

Для таких випадків є компромісне рішення. Воно не ідеальне, але може допомогти. Назвімо це технікою «білого покривала».

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

На JsFiddle можна побавитися із прикладом A/B-тесту, побудованого за цим підходом.

У цьому прикладі, якщо потрапити на варіацію B, то повторне натискання кнопки Run наочно продемонструє побічний ефект, як перемальовуються елементи за складних змін. Щоб змінити варіацію, треба почистити cookie.

Щоб стартувати, зупинити тест чи змінити розподіл трафіку, ми просто передеплоюємо наш JavaScript у те місце, де він хоститься доступними нам засобами.

Підсумки за Client Side

Pros:

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

Cons:

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

Server Side

Тут, на відміну від Client Side, треба підготувати всі (у разі А/B їх буде 2) кінцеві варіанти сторінки (варіації) з можливістю доступу за окремими посиланнями. Варіацію визначають ще в процесі оброблення http-запиту, і користувач відразу отримує потрібний варіант сторінки без накладання змін поверх. Тоді вся архітектура А/B-тесту зведеться до раутингу й установлення cookie. Опційно, але бажано для швидкодії, сторінку можна кешувати.

Звісно, це можна адаптувати під реалії кожної конкретної інфраструктури, але ось приклад з використанням Cloudflare CDN і їхнього Service Worker. Service Worker, по суті, — JavaScript, що виконується на сервері й дає змогу перехоплювати та вносити зміни до оригінального http-запиту або перенаправляти його на інші адреси. І, що важливо, цей код можна динамічно змінювати через адмінку або API.

Який вигляд у такому разі має архітектура A/B-тесту

1. Користувач робить запит на URL і потрапляє на CDN Edge server, де крутиться наш Service Worker.
2. Передусім ми перевіряємо наявність cookie в заголовках, щоб зрозуміти: він уже був на певній варіації і йому слід показати ту ж саму чи це новий користувач і варіацію треба вибрати випадково.
3. Визначивши варіацію, прокидаємо запит на відповідний route. Якщо сторінка є в кеші, CDN віддає її звідти, якщо ні — запит надсилається на origin (наш web-server), а дорогою назад response кешується. Нагадаю, для кожної варіації повинна бути попередньо підготовлена сторінка.
4. Перш ніж віддати response на клієнт, додаємо до нього Set-Cookie-заголовок з ідентифікатором варіації, щоб наступні запити потрапляли на ту саму варіацію.
   
5. Вертаємо response з розміткою і cookie-варіації.

Приклад коду й пісочниця Cloudflare:

У такий спосіб ми досягаємо кінцевої мети — користувачі «випадковим чином» можуть отримати різний контент за тим самим посиланням. Лишається тільки простежити їхню реакцію.

Щоб стартувати, зупинити або внести зміни в розподіл трафіку, ми просто передеплоюємо наш JavaScript у Service Worker доступними нам засобами — з адмінки або через API.

Як ми пам’ятаємо, трафік A/B-тесту потрібно таргетувати (фільтрувати). У разі Server Side ми можемо використати лише ту інформацію, що є в оригінальному запиті. Наприклад:

• User Agent допоможе визначити браузер або пристрій;
• Cookie;
• IP дає змогу фільтрування за геолокацією;
• Host. A/B-тест зазвичай розробляють для однієї/кількох сторінок сайту, для решти експериментального раутингу робити не треба.

Підсумки за Server Side

Pros:

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

Cons:

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

Відстеження активності

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

Якщо ще раз повернутися до наших синьо-червоних кнопок, то ключовою метрикою буде конверсія (натискання кнопки). Тобто нам треба фіксувати «натискання» і «ненатискання» як базовий мінімум. Цього досить, щоб порівняти вплив кольору кнопки загалом, але мало, щоб зрозуміти нашу аудиторію. Як додаткові датапоїнти (сегменти) ми можемо фіксувати контекст користувача. Браузер, пристрій, величина екрана, локація, валюта, платіжний метод, час доби — усе, що дасть змогу сегментувати аудиторію й аналізувати поведінку в межах цих сегментів чи на їхньому перетині. Персональної інформації не потрібно та це й протизаконно. Досить мати агреговані дані для виявлення поведінкових патернів або аномалій.

Маючи такі дані на руках, можна дійти висновку, наприклад, що червона кнопка працює ліпше для користувачів 4k-екранів з Техасу вночі.

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

Архітектура

Як це можна організувати технічно? Знову ж таки на ринку є великі гравці, як-от: Google Analytics чи Facebook Analytics — кожний зі своїм API, набором правил й аналітичних інструментів. І навряд чи хтось зможе конкурувати з ними на полі даних й аналітики. Проте організовано це всюди приблизно однаково.

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

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

На підставі якогось набору анонімних й унікальних даних, доступних на клієнті (IP, session, agent), генерують GUID, до якого ці всі події прив’язуватимуть, щоб дані можна було правильно агрегувати.

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

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

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

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

Замість висновків

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

Ми живемо в час нової лихоманки — інформаційної. Дані — це нове золото, і ті, хто має їх у достатній кількості й належної якості, мають велику перевагу над конкурентами.