Як можна було розробити правило зупинки в аналізі потужності двох незалежних пропорцій?

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

Типовий тестовий сценарій включає порівняння двох URL-адрес на веб-сайті. Відвідувач відвідує, LANDING_URLа потім випадковим чином пересилається на URL_CONTROLабо URL_EXPERIMENTAL. Відвідувач являє собою зразок, і умова перемоги досягається, коли відвідувач виконує якісь бажані дії на цьому сайті. Це становить конверсію, а швидкість конверсії - швидкість конверсії (зазвичай виражається у відсотках). Типовий коефіцієнт конверсії для даної URL-адреси - це сфера від 0,01% до 0,08%. Ми проводимо тести, щоб визначити, як нові URL-адреси порівнюються зі старими URL-адресами. Якщо URL_EXPERIMENTALпоказано, що він перевершує URL_CONTROL, замінимо URL_CONTROLна URL_EXPERIMENTAL.

Ми розробили систему з використанням простих методів тестування гіпотез. Я використовував відповіді на інше питання CrossValidated тут, щоб розробити цю систему.

Тест встановлюється наступним чином:

• Оцінка коефіцієнта конверсії обчислюється CRE_CONTROLз URL_CONTROLвикористанням історичних даних.
• Необхідний коефіцієнт конверсії цільової CRE_EXPERIMENTALз URL_EXPERIMENTALцієї множини.
• Зазвичай використовується рівень значущості 0,95.
• Зазвичай використовується потужність 0,8.

Усі ці значення разом використовуються для обчислення потрібного розміру вибірки. Я використовую функцію R, power.prop.testщоб отримати цей розмір вибірки.

Тест триватиме, поки не будуть зібрані всі зразки. На цьому етапі довірчі інтервали для CR_CONTROLта CR_EXPERIMENTALобчислюються. Якщо вони не перетинаються, то переможця можна оголосити рівнем значущості 0,95 та потужністю 0,8.

У користувачів наших тестів є дві основні проблеми:

1. Якщо в якийсь момент під час тестування зібрано достатньо зразків, щоб показати чіткого переможця, тест не можна зупинити?

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

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

Ось два підходи ми хочемо розглянути:

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

Приклад: Тест встановлено, щоб перевірити, чи існує така поведінка в нашій системі:

• CRE_CONTROL: 0,1
• CRE_EXPERIMENTAL: 0,1 * 1,3
• При цих параметрах розмір вибірки Nстановить 1774.

Однак у міру проходження тесту і досягнення 325 проб CRM_CONTROL(виміряна швидкість конверсії для контролю) становить 0,08 і CRM_EXPERIMENTALстановить 0,15. power.prop.testпроводиться на цих коефіцієнтах конверсії і Nвиявляється 325. Рівно кількість зразків, необхідних для оголошення CRM_EXPERIMENTALпереможця! На даний момент ми сподіваємось, що випробування можна було б закінчити. Аналогічно, якщо тест досягає 1774 проби, але переможця не знайдено, але тоді він досягає 2122 зразків, що достатньо, щоб показати, що CRM_CONTROL0,1 та CRM_EXPERIMENTAL0,128 - це результат, коли переможця можна оголосити.

У відповідному запитанні користувачі повідомили, що такий тест є менш достовірним через заохочення ранніх зупинок, що мають меншу кількість зразків, а також є вразливим до зміщення оцінок та збільшення кількості помилок типу I та типу II. Чи є якийсь спосіб змусити це правило зупинення роботи? Це наш переважний підхід, оскільки він означає менший час програмування для нас. Можливо, це правило зупинки може спрацювати, запропонувавши якусь числову оцінку чи бали, що вимірюють достовірність тесту, чи слід його припинити достроково?

2. Використання послідовного аналізу або SPRT .

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

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

Це цікава проблема, і пов'язані з ними методи мають багато застосувань. Їх часто називають стратегіями "проміжного моніторингу" або "послідовним експериментальним дизайном" (стаття у Вікіпедії, з якою ви пов'язувались, на жаль, є трохи рідкісною), але для цього є кілька способів. Я думаю, що @ user27564 помиляється, сказавши, що ці аналізи обов'язково повинні бути байєсовими - безумовно, є і часті підходи до проміжного моніторингу.

$As$$Bs$$A$$B$$P(A)=P(B)=0.5$$58$$x \textrm{ such that } 1-F(x;100;0.5) \lt \alpha$$F$

Подібна логіка дозволяє знайти "точки неминучості" для інших тестів, де:

1. Загальний розмір вибірки * є фіксованим, і
2. Кожне спостереження вносить у вибірку обмежену кількість.

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

$A$$B$$A$

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

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

[*] Лише добра дружня порада: будьте уважні, дивлячись на значення значущості, обчислені з дуже великої кількості точок даних. Як ви збираєте все більше і більше даних, ви будете в кінцевому підсумку знайти значимий результат, але ефект може бути дуже малий. Наприклад, якщо ви запитали всю планету, чи вони віддають перевагу A або B, дуже малоймовірно, що ви побачите точний розкол 50:50, але, мабуть, не варто переоблаштовувати ваш продукт, якщо розкол 50,001: 49,999. Продовжуйте перевіряти розмір ефекту (тобто різницю в коефіцієнтах конверсії) теж!

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

Я не можу говорити з другим запропонованим вами підходом.

Однак перший підхід не на твердій основі. Звичайні наближення біноміальних розподілів не вірні для низьких пропорцій (що застосовується методом power.prop.test, також методом, використовуваним Коеном у його класичній книзі про потужність). Більше того, наскільки мені відомо, не існує рішення для аналізу потужності в закритій формі для двопробних випробувань пропорцій (пор. Як можна виконати двогруповий біноміальний аналіз потужності без використання нормальних наближень? ). Однак існують кращі методи наближення довірчих інтервалів пропорцій (див. Пакетний біном). Ви можете використовувати довірчі інтервали, що не перекриваються, як часткове рішення ... але це не те саме, що оцінювати p-значення і, таким чином, не забезпечує напрям живлення безпосередньо. Я сподіваюся, що у когось є приємне рішення закритої форми, яким вони поділяться з іншими нами. Якщо я натрапляю на одне, я оновлю вищезазначене запитання. Удачі.

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

У вас є типові запитання, що виникають у статистичних тестах. Є два "аромати" статистики там, часто-часто та байєсів. Частістська відповідь на обидва ваші запитання проста:

• НІ
• Ні, ви не можете зупинитися рано
• Ні, ви не можете виміряти просто довше

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

Але є байєсівська точка зору, яка зовсім інша. Байєсівський підхід потребує на відміну від ветеринарів додатковий вхід, априорі розподіл ймовірностей. Ми можемо назвати це також попередніми знаннями або забобонами. Маючи це, ми можемо використовувати дані / вимірювання для оновлення своїх знань до ймовірності a-posteriori. Справа в тому, що ми можемо використовувати дані і навіть більше, ми можемо використовувати дані в кожній проміжній точці вимірювання. У кожному оновленні остання задня частина - це наш новий попередній показник, і ми можемо оновити його новим вимірюванням нашим сучасним знанням. Жодних проблем із ранньою зупинкою!

Я знайшов розмову, де обговорювались подібні проблеми, як у вас, і я описав вище: http://biostat.mc.vanderbilt.edu/wiki/pub/Main/JoAnnAlvarez/BayesianAdaptivePres.pdf

Але крім цього, ви справді впевнені, що вам це взагалі потрібно? Здається, у вас працює якась система, яка вирішує, куди слід зв’язати запит. Для цього вам не потрібно доводити, що ваші рішення в статистичному сенсі є правильними з допомогою тесту на гіпотезу. Ви коли-небудь купували кокс, бо ви могли виключити, що пепсі зараз "зараз" з вірогідністю 95%? Достатньо взяти той, який просто кращий, не виключаючи гіпотези. Це був би тривіальний алгоритм: обчисліть невизначеність швидкості A, обчисліть нестандартність B. Візьміть різницю обох ставок і поділіть її b на невизначеність різниці. Результат - щось на кшталт значущості різниці сигми. Тоді просто візьміть усі ланки там, де є більше двох-трьох сигма різниці. Відношення,

можливо, там можуть бути використані деякі методи

• Pocock
• О'Браєн і Флеммінг
• Пето

це дозволить скорегувати скорочення P на основі результатів і допоможе припинити збір даних та економити ресурси та час.

можливо, сюди можуть бути додані інші твори.