AB Тестування 101

Що я бажав знати про AB тестування, коли розпочав свою кар’єру

Я почав свою кар’єру як інженер-програміст (Software engineer) у компанії Applied Predictive Technologies (APT), яка продавала складні програмні засоби для AB тестування Fortune 500 клієнтам за мільйонні контракти і була придбана компанією Mastercard в 2015 році за 600 мільйонів доларів. Таким чином, я був вовласним у AB тестування з самого початку своєї кар’єри.

Через кілька років я став віце-президентом з інженерії в компанії Storyblocks, де я допоміг побудувати онлайн-платформу для проведення AB тестів та збільшив наш прибуток з 10 мільйонів до 30 мільйонів доларів і більше. Потім, наступним кроком, я був віце-президентом з інженерії в компанії Foundry.ai, де я допоміг створити “багаторукавого бандита” для медіа-сайтів. Через кілька років я взяв участь у запуску AB тестування як архітектор в компанії ID.me, компанії з оцінкою понад 1,5 мільярда доларів і річним оборотом понад 100 мільйонів доларів.

Тож, може здавалося, що я повинен був знати багато про AB тестування, чи не так? Але я помітив, наскільки мало я знав, коли приєднався до компанії Eppo, спеціалізованої на платформі для проведення AB тестувань. Нижче наведено узагальнення того, що я бажав знати про AB тестування, коли розпочав свою кар’єру.

Що таке AB тест?

Спочатку давайте визначимо, що таке AB тестування (також відоме як тестування розділу (split testing)). Щоб процитувати Harvard Business Review, “AB-тестування – це спосіб порівняти дві версії чогось, щоб визначити, яка працює краще.”

Ось візуальне представлення AB тестування веб-сторінки.

Фіктивна компанія “YourDelivery” проводить тестування, щоб визначити, який варіант призведе до більше замовлень доставки їжі. Той варіант, який переможе, буде розгорнуто для всієї популяції користувачів.

Далі в цій статті я буду вважати, що ми працюємо над AB тестуванням веб- або мобільного продукту.

Отже, давайте визначимо, що входить у процес запуску AB тесту:

1. Включення функціоналу та рандомізація: як визначається, хто бачить який варіант (наприклад, який досвід або функції).
2. Метрики: що ми вимірюємо, щоб визначити, який варіант перемагає, і щоб ми не навмисно не пошкодили нічого в процесі.
3. Статистика: важливий математичний метод визначення, чи один варіант кращий за інший за допомогою метрик.
4. Висновки: як ми приймаємо рішення на основі метрик і статистики.

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

Функціональне включення і рандомізація

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

Рандомізація полягає в “киданні кубиків” і визначенні, який варіант бачить користувач. Здається, що це просто, але насправді це складно робити належним чином. Давайте розпочнемо з “наївної” версії рандомізації, щоб продемонструвати складність цього процесу.

Наївна версія рандомізації

Користувач переходить на домашню сторінку, і ми проводимо тест на основному тексті з варіантами “контрольна” і “тестова”. Сервер повинен визначити, який варіант показати користувачеві. Ось як працює рандомізація для користувача, який відвідує домашню сторінку:

1. Пошук варіанта користувача в базі даних. Якщо він існує, використовувати записаний варіант. Якщо його немає, тоді…
2. Кидання кубиків. Викликається функція Math.random() (або будь-яка функція рандомізації для вашої мови програмування).
3. Призначення варіанта. Порівнюється число, що повернула функція Math.random(). Якщо воно менше 0,5, то призначається варіант “контроль”. В іншому випадку призначається варіант “тест”.
4. Збереження варіанта в базу даних (щоб його можна було знайти в кроці 1, коли користувач наступного разу відвідає домашню сторінку).
5. Використання варіанта для визначення того, який текст показувати на домашній сторінці.
6. Відображення домашньої сторінки.

Здається, це досить просто. Насправді це те, що ми реалізували в Storyblocks в 2014 році, коли ми розпочали AB тестування. Це працює, але має помітні недоліки:

1. Велика залежність від читання і запису в транзакційну базу даних. Якщо у вас є тест, який запущено на домашній сторінці, тоді можливо великий обсяг записів йде до вашої таблиці для тестування. І якщо у вас є два, три, чотири або більше тестів, які запущені на цій сторінці, то помножте цей навантаження. Додаток також намагається читати з цієї таблиці при кожному завантаженні сторінки, тож виникає велика конкуренція читання/запису. У нас кілька разів “падав”(crashed) додаток через блокування бази даних, пов’язані з високим обсягом запису, особливо коли до високонавантажених сторінок додається новий тест.
2. Переважно працює з традиційною архітектурою, де сервер відображає сторінку HTML. Це не дуже підходить для односторінкових або мобільних додатків, оскільки для коректного відображення кожен тест потребує блокуючого мережевого виклику перед відображенням вмісту.
3. Умовна гонка. Якщо користувач відкриває домашню сторінку кілька разів одночасно (наприклад, зі сеансу відновлення в Chrome), то невизначено, який варіант побачить користувач і який варіант буде записаний. Це через те, що запити з кроку 1 можуть повертати нічого, тож кожне завантаження сторінки “кидає кубики” і призначає різний варіант. Випадково виграє той, який першим буде збережений в базу даних, і користувач потенційно бачить різні варіанти.

Покращена рандомізація за допомогою хешування

Як же ми можемо вдосконалити рандомізацію? Проста відповідь: за допомогою хешування. Замість простого “кидання кубиків” за допомогою Math.random(), ми хешуємо комбінацію ідентифікатора експерименту і ідентифікатора користувача, використовуючи, наприклад, MD5, що фактично створює стійке випадкове число для поєднання експерименту і користувача. Потім беремо перші кілька байтів і відзначаємо залишок відносно великого числа (скажімо, 10 000). Потім розподіліть свої варіанти серед цих 10 000 “фрагментів”, щоб визначити, який варіант слід відобразити. (Якщо ви цікавитеся практичним кодом для цього, ви можете перевірити SDK від Eppo, який пропонує таку можливість). Ось як це виглядає на діаграмі з 10 фрагментами.

Після того, як ви визначили варіант, ви реєструєте результат, але замість запису в транзакційну базу даних, що блокує ресурси, результат записується в потік даних (наприклад, AWS Kinesis) без блокування. З часом дані потрапляють в таблицю в вашому сховищі даних (data lake/warehouse) для подальшого аналізу (зазвичай її називають “таблицею призначень”).

Добре, але чому мені потрібен інструмент для функціонального включення? Чи не можу я просто реалізувати цю логіку хешування самостійно? Так, ви можете (і ми це робили в Storyblocks у свій час), але є деякі недоліки:

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

Відповідь на проблему рандомізації: функціональне включення

Отже, що ми робимо? Ми використовуємо функціональне включення! Я не буду розглядати це в повних деталях тут, але функціональне включення вирішує ці питання для нас, поєднуючи найкращі можливості обох підходів: здатність включити конкретні групи користувачів в тест і здатність випадково включити всіх інших. Якщо вам цікаво дізнатися більше, то є чудовий пост в блозі Eppo, який описує, що потрібно для створення глобальної служби функціонального включення, якщо ви хочете дізнатися більше.

Метрики

Метрики, ймовірно, є найлегшою частиною AB тестування для розуміння. Зазвичай для кожного бізнесу чи продукту визначають власний набір метрик, які визначають залучення користувачів, фінансовий результат і все інше, що можна виміряти та що допомагає управляти стратегією та приймати бізнес-рішення. Для Storyblocks, веб-сайту з медіа-контентом, цими метриками були доход за 30 днів для нових користувачів (фінансові метрики), завантаження (показники залучення), швидкість пошуку (показники продуктивності), рейтинг Net Promoter (задоволення клієнтів) та багато інших.

Наївний підхід тут – це просто об’єднувати таблицю призначень з іншими таблицями в базі даних для обчислення значень метрик для кожного користувача в експерименті. Ось декілька ілюстративних запитів:

SELECT a.user_id, a.variant, SUM(p.revenue) AS revenue
FROM assignments a
JOIN purchases p
 ON a.user_id = p.user_id
WHERE a.experiment_id = 'some-experiment'
 AND p.purchased_at >= a.assigned_at

SELECT a.user_id, a.variant, COUNT(*) AS num_page_views
FROM assignments a
JOIN page_views p
 ON a.user_id = p.user_id
WHERE a.experiment_id = 'some-experiment'
 AND p.viewed_at >= a.assigned_at

-- etc.

Це стає проблематичним з декількох причин:

1. Із зростанням кількості користувачів вашої бази даних, спроби з’єднати таблицю призначень стають рутинними і витратними.
2. Із збільшенням кількості метрик складно керувати SQL-запитами для їх обчислення (припустіть, що у вас є 50 або навіть 1000 таких метрик).
3. Якщо основні дані змінюються з часом, стає важко відтворити результати.

Отже, для масштабування вашого AB тестування вам потрібна система із наступними характеристиками:

1. Здатність обчислювати призначення для конкретного експерименту один раз протягом кожного обчислювального циклу.
2. Сховище для керування SQL-запитами, що визначають ваші метрики.
3. Незмінний шар подій або “фактів”, щоб визначити основні параметри для обчислення метрик.

Дозвольте мені докладніше пояснити шар подій/фактів. Важливим аспектом спрощення вимірюваних і відтворюваних метрик є те, що вони базуються на подіях або “фактах”, які відбуваються в продукті чи бізнесі. Вони повинні бути незмінними та мати мітку часу. У випадку Storyblocks до цих фактів входили оплати підписки, завантаження, перегляди сторінок, пошуки та подібне. Метрика доходу за 30 днів для нових користувачів – це просто операція (сума) на факті (оплата підписки). Кількість пошуків – це просто підрахунок кількості подій пошуку. І так далі. Компанія, як Eppo, робить ці факти та інші визначення важливою частиною вашої інфраструктури для AB тестування і також надає можливості для обчислення призначень один раз і створення сховища фактів/метрик.

Важливим аспектом налаштування експерименту є визначення основних і контрольних метрик. Основна метрика для експерименту – це метрика, яка найближче пов’язана з тим, що ви намагаєтеся перевірити. Таким чином, для оновлення домашньої сторінки YourDelivery, де ви тестуєте колір фону (синій проти червоного), вашою основною метрикою, ймовірно, є доход. Контрольні метрики – це ті показники, які ви, як правило, не намагаєтеся змінити, але ви вимірюєте їх, щоб переконатися, що не негативно впливаєте на досвід користувачів. Це, наприклад, час на сайті, кількість переглядів сторінок і т. д.

Статистика

Статистика. Це найважча частина для того, хто новий в AB-тестуванні, щоб зрозуміти. Ви, можливо, чули, що нам потрібно, щоб p-значення було менше 0,05, щоб різниця в показнику була статистично значущою, але можливо, ви не знаєте багато іншого. Тож я розпочну з наївного підходу, який можна знайти в підручнику зі статистики 101. Потім я покажу, що неправильно в наївному підході. Нарешті, я поясню підхід, який вам потрібно вживати. В кінці також буде бонусний розділ.

Наївний підхід: студентський t-тест

Припустимо, що ми виконуємо тест домашньої сторінки для YourDelivery, показаний вище, з двома варіантами – control (синій) та test (червоний) з рівним розподілом 50/50 між ними. Також припустимо, що ми дивимося лише на одну метрику – дохід. Кожен користувач, який відвідує домашню сторінку, призначається одному з варіантів, і потім ми можемо обчислити метрику доходу для кожного користувача. Як ми визначаємо, чи є статистично значуща різниця між тестом і контролем? Наївний підхід просто використовує студентський t-тест, щоб перевірити, чи є статистична різниця. Ви обчислюєте середнє значення та стандартне відхилення для тесту та контролю, підставляєте їх у формулу для t-статистики, порівнюєте це значення з критичним значенням, яке ви шукаєте, і вуаля, ви знаєте, чи є ваша метрика, у цьому випадку дохід, статистично різною між групами.

Давайте розглянемо деталі. Формула для класичної t-статистики виглядає наступним чином:

X₁,X₂ – Середне (avg/mean) в групі
S₁,S₂ – Стандртне відхилення в групі
n₁,n₂ – Кількість випадків в групі

Для пошуку критичного значення для заданого рівня значущості (зазвичай 5%), вам потрібно знати ступені свободи. Але для великих розмірів вибірки, які зазвичай маємо при AB-тестуванні, розподіл t-розподілу збігається з нормальним розподілом, тому ми можемо використовувати нормальний розподіл для пошуку критичного значення. Параметри цього нормального розподілу за нульової гіпотези (тобто немає різниці між групами) виглядають наступним чином:

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

Що неправильно з наївним підходом

На перший погляд, наївний підхід може здатися досить обґрунтованим, правда? Все ж, він дотримується стандартів статистики. Однак є декілька суттєвих недоліків:

1. “Проблема підглядання“. Класичний t-тест гарантує свою статистичну значущість лише у випадку, якщо ви дивитесь на результати один раз (наприклад, фіксований розмір вибірки). Докладніше нижче.
2. P-значення відомі своєю схильністю до невірного тлумачення, мають довільні пороги (наприклад, 5%) і не вказують на величину ефекту.
3. Абсолютні проти відносних різниць. Класичний t-тест розглядає абсолютні різниці, а не відносні різниці.

Проблема підглядання

За допомогою наївного підходу з t-тесту, ми вважали, що маємо рівень статистичної значущості на рівні 5%. Однак класичний t-тест надає заявлені гарантії статистичної значущості лише у випадку, якщо ви дивитесь на результати один раз (іншими словами, ви заздалегідь визначаєте фіксований розмір вибірки). Еван Міллер пише чудовий блог-пост про цю проблему, який я вам рекомендую прочитати, щоб краще зрозуміти. Нижче наведено таблицю з блог-посту Евана, яка ілюструє, наскільки серйозною є проблема підглядання.

Тож, якщо ви проводите тест протягом 2 тижнів і щодня перевіряєте результати, то для досягнення справжньої значущості на рівні 5%, вам потрібно підвищити значущість, щоб вона була ≤ 1%. Це досить значуща зміна і представляє принаймні повний стандартний рівень відмінності від наївного підходу.

Підхід, який ви маєте вживати

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

1. Відносні підвищення. Дивіться на відносні підвищення, а не на абсолютні різниці.
2. Послідовні довірчі інтервали. Ці довірчі інтервали надають вам гарантії значущості, які діють протягом усього часу, так що ви можете перевіряти результати скільки завгодно разів, і вони легше інтерпретуються, ніж p-значення.
3. Контрольний експеримент за даними перед експериментом (CUPED –Controlled-Experiment Using Pre-Experiment Data). Ми можемо використовувати високорівневі методи, які використовують дані перед експериментом для зменшення дисперсії, отже, скорочення довірчих інтервалів та прискорення тестів.

(1) Відносні підвищення

Логіка відносних підвищень проста: ми, зазвичай, цікавимося відносними змінами, а не абсолютними, і їх легше обговорювати. Легше зрозуміти “збільшення доходу на 5%” порівняно з “збільшенням доходу на користувача на $5”.

Як змінюється математика для відносних підвищень? Я цитую документацію від Eppo на цю тему. Спершу давайте визначимо відносне підвищення:

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

Добре, це трохи складно. Але це необхідно для обчислення послідовних довірчих інтервалів.

Послідовні довірчі інтервали

Спершу давайте розглянемо довірчий інтервал з візуальним представленням з панелі експериментів Eppo:

Отже, ви бачите, що “оцінка точки” становить 5,9% підвищення, з довірчим інтервалом приблизно на 2,5% з обох боків, який представляє те місце, де справжнє відносне підвищення має бути 95% часу (один мінус типова значущість на рівні 5%). Ці інтервали набагато легше інтерпретувати для тих, хто не є статистиками, ніж p-значення – візуальна ілюстрація дійсно допомагає пояснити дані і статистику разом.

Тож що таке послідовні довірчі інтервали? Просто кажучи, це довірчі інтервали, які зберігаються на певному рівні довіри протягом всього часу. Вони вирішують “проблему підглядання”, так що ви можете дивитися на свої результати стільки разів, скільки завгодно, знаючи, що ваш рівень значущості залишається сталим. Математика тут дуже складна, тому я просто посилатимусь на документацію Eppo з цього питання, якщо ви бажаєте дізнатися більше.

Контрольний експеримент з використанням даних перед експериментом (CUPED)

Послідовні довірчі інтервали ширші, ніж їх фіксовані аналоги для фіксованої вибірки, тому важче досягти статистичної значущості при використанні послідовних довірчих інтервалів. Ось де з’являється “Контрольний експеримент з використанням даних перед експериментом” (зазвичай називається CUPED), метод для зменшення дисперсії за допомогою даних перед експериментом. Коротко кажучи, ми можемо використовувати те, що ми знаємо про поведінку користувачів перед експериментом, щоб точніше передбачити відносне підвищення. Візуально це виглядає приблизно так:

Математика складна, тому я не буду нудьгувати вас деталями. Просто знайте, що потужні платформи для AB-тестування, такі як Eppo, надають реалізації CUPED на стандартних умовах.

Бонусний матеріал — спрощення обчислень

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

Спочатку середні значення досить прості для обчислення:

Стандартне відхилення трохи важче обчислити, але визначається так:

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

Добре, це виглядає досить складно. Оригінальна формула, схоже, простіша. Проте ви помітите, що ми можемо обчислити ці суми в одному проході. У мові SQL це щось на зразок:

SELECT count(*) as n
  , sum(revenue) as revenue
  , sum(revenue * revenue) as revenue_2
FROM user_metric_dataframe

Отже, це дуже добре з точки зору обчислень.

Бонусний матеріал — Байєсівська статистика

Можливо, ви раніше чули про Теорему Байєса, але, скоріше за все, ви не чули про Байєсівську статистику. Я особисто ніколи не чув про це, поки не прийшов до Eppo. Я не буду докладатися в деталі, але спробую надати короткий огляд.

Давайте розпочнемо з Теореми Байєса:

У Байєсівській статистиці ви маєте власні переконання щодо вашої популяції та спостережувані дані. Давайте спростимо це до “переконань” та “даних” і подамо Теорему Байєса трохи інакше.

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

Чому ця методологія потенційно бажана при невеликому розмірі вибірки? Тому що ви можете встановити свої вихідні дані, як щось відносно обґрунтоване і отримати вузькі довірчі інтервали, ніж ви могли б отримати з класичної частотної статистики. Звідси ви можете сказати, що ви очікуєте, що відносна різниця між тестом (червоний) та контролем (синій) має нормальний розподіл зі стандартним відхиленням 5% (або щось подібне, це трохи залежить від вас, встановлювати вихідні дані).

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

Підводячи підсумок

Завершення експерименту – це мистецтво AB-тестування. Іноді рішення є простими: діагностика – це весь спектр, показники експерименту рухаються в очікуваному напрямку, і не спостерігається негативних впливів на контрольні показники. Однак дослідження показують, що лише близько 1/3 експериментів призводять до позитивних результатів. Багато експериментів можуть виглядати схоже на звіт нижче для експерименту “Орієнтація нового користувача”:

Основний показник “Загальна кількість переходів на платний тариф” зріс на приблизно 6%, тоді як є деякі негативні впливи, такі як “Створення сайтів” скоротилися на близько 10%. То що робити? Нарешті, тут немає однозначної відповіді. Все залежить від вас та вашої команди, щоб приймати важкі рішення в таких ситуаціях.

Крім звітів про експерименти, важливо дивитися на діагностику експерименту, щоб переконатися, що вихідні дані мають гарний стан. Дуже поширену проблему з AB-тестуванням називають “невідповідністю співвідношення вибірки” або SRM, це просто виразне вираження того, що кількість користувачів в тесті та контролі не відповідає очікуваному. Наприклад, ви можете проводити тест 50/50, але ваші дані показують 55/45. Ось як виглядає SRM в Eppo:

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

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

Інструменти та платформи Хоча на початку ви можливо думали, що створення платформи AB-тестування є досить прямолінійним завданням, я сподіваюся, що я продемонстрував, що робити це добре – це надзвичайно складно. Від побудови інструменту для флагів функцій до створення сховища метрик, від правильного підходу до статистики до фактичного обчислення результатів щоранку, в цьому процесі дуже багато складних завдань. Щасливо, вам не потрібно будувати це все з нуля. Існує безліч інструментів та платформ, які допомагають спростити AB-тестування. Нижче наведений список деяких із них:

• Eppo
• LaunchDarkly
• Split
• Statsig
• Growthbook
• Optimizely

Аналіз кожної з цих платформ виходить за межі цього матеріалу. Однак, з усіма вимогами до платформи AB-тестування, наведеними вище, я можу з впевненістю сказати, що Eppo (навіть якщо я можливо трохи упереджений через те, що працюю там) – це найкраща все-в-одному платформа для компаній, які мають централізовані дані у сучасному сховищі даних (Snowflake, BigQuery, Redshift або Databricks) і прагнуть проводити тести продуктів на веб-сайтах чи мобільних пристроях, включаючи тести систем штучного інтелекту/машинного навчання. Eppo надає потужну глобальну систему функцій, шар управління фактами/метриками, вищу статистику, нічне обчислення результатів експерименту, детальну діагностику експерименту та дружній для користувача інтерфейс, який легко використовувати навіть не-статистикам. Якщо ви просто шукаєте можливість провести прості тести маркетингового тексту, то, ймовірно, для вас краще підійде інструмент, подібний до Optimizely, хоча він, мабуть, буде досить дорогим.

Рекомендована література Є багато матеріалів для читання щодо AB-тестування. Ось декілька моїх рекомендацій:

• Trustworthy Online Controlled Experiments
• Evan Miller’s blog
• Bayesian Statistics the Fun Way
• Eppo’s blog
• Optimizely’s blog
• Udacity’s AB testing course (технічно це не читання, але все одно корисно)

І ось і все. Дякую, що залишилися, друзі!

ОРИГІНАЛ СТАТІ: AB Testing 101
АВТОРИ СТАТІ: Written by Jonathan Fulton

Долучайтесь до нашої спільноти Telegram

ANALYST UA
ANALYST GROUP UA
DATA ENGINEERING UA
Долучайтесь до нашої спільноти FaceBook
Data-Life-UA