Appbooster
Почему эти данные корректны:
1. Как мы написали, цель теста — окупаемость трафика в первый месяц. То есть мы заранее определились, на какую метрику смотрим, и именно по ней мы и выбирали лидера. Эта метрика — конверсия в первый платёж. Эти данные у нас были и их не надо ждать.
2. Если говорить про когорты и возобновляемость платежей — то, по нашему опыту, дизайн экрана оплаты в очень маленькой степени влияет на повторные оплаты, гораздо важнее то, что внутри приложения. То есть мы можем считать, что возобновляемость ± одинаковая.
Что касается алгоритма, если бы нам нужно было запустить тест, который подразумевает накопление платежей одного платящего — так мы тоже можем.
Ну и последнее) Нам кажется, что запускать тесты на несколько месяцев, чтобы сравнить LTV или другую накопительную денежную метрику, — это не очень удачный подход, как минимум потому что нужно ждать несколько месяцев. За это время всё может измениться и результаты теста уже будут неактуальными.
Вместо этого можно использовать, например, прокси-метрики. Если не знаете, что это, — мы обязательно напишем про это статью. Но, может, немного позже))
Не потратил)
Выиграл вариант, который первый на картинке.
Но мы не сравниваем пейволлы и казино, мы приводим пример казино, чтобы объяснить алгоритм.
А пейволлы — это прикладное применение алгоритма.
Нет, не нарушаем. Смысл байесовского многорукого бандита как раз в том, чтобы не делать одинаковые и заранее фиксированные выборки аудитории, а выбирать группу теста для нового юзера “на лету“.
Просто мы используем немного другую логику и математику под капотом, которая эффективнее
Здесь история абсолютно такая же, как в классических A/B-тестах.
Перед запуском эксперимента мы выбираем, на какую метрику хотим повлиять. По изменению этой метрики мы будем оценивать результаты эксперимента. Параллельно мы можем повлиять и на другие метрики. Например, запустив тест на “Подписку на пуши”, мы можем сломать Retention или вырастить LTV. То есть, в теории, изменение чего-либо может проявиться в неожиданных местах.
Это справедливо и для классических тестов, и для многорукого бандита. Можно сказать, что это не связано с а/б тестами в явном виде.
Отличие нашего алгоритма только в том, что мы стараемся как можно раньше выбрать вариант, который лучше работает с целевой метрикой. Ну и, как следствие, — если мы раньше отдадим варианту больше трафика, то мы раньше заметим, что этот вариант что-то меняет в пользовательском опыте.
А вывод скорее про здравый смысл и правильный выбор целевой метрики, что не надо а/б тестами ломать пользовательский опыт)