Баєсівське A/B-тестування

Баєсівське A/B-тестування – це підхід до аналізу експериментів, який показує ймовірність того, що один варіант кращий за інший, враховуючи спостережувані дані та будь-яку надану попередню інформацію. Він відрізняється від частотного підходу, який показує, наскільки дивовижними були б дані, якби варіант не мав жодного ефекту. Практична різниця полягає в результатах: баєсівські методи дають такі твердження, як «існує 93-відсоткова ймовірність того, що варіант B перевершить контрольний варіант, з очікуваною втратою 0.2 відсотка, якщо ми зробимо неправильний вибір», які безпосередньо відображаються на бізнес-рішеннях.

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

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

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

Жоден фреймворк не рятує погано розроблений експеримент. Баєсівський аналіз тесту з порушеною рандомізацією, помилкою відстеження, невідповідністю коефіцієнта вибірки або метрикою, яка не відображає бізнес-цінності, дасть впевнену та точну відповідь на неправильне запитання. Вибір між фреймворками – це вибір теорії звітності та прийняття рішень; якість дизайну експерименту, що лежить в його основі, визначає, чи відповідь чогось варта.

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

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