Кейс: как мы потеряли $7500 на A/B-тестах мобильного приложения, но научились их проводить

Недавно коллеги из AppQuantum опубликовали статью "Как проводить A/B-тесты в мобильных приложениях: часть I" по мотивам нашего совместного вебинара. В статье упоминался наш новый сервис умного A/B-тестирования мобильных приложений. В этом кейсе расскажем, как мы пришли к созданию сервиса, как обкатывался алгоритм, и чем наше решение поможет проводить A/B-тесты быстрее и дешевле.

Обычно, когда в продукт хотят внести какие-то изменения, прибегают к классическому A/B-тестированию. Всё стандартно: разделяют пользователей на группы, каждой показывается свой вариант изменения. Определяют метрику, по которой будут измерять результат, и на её основе выбирают победивший вариант.

По итогам эксперимента выиграет только один вариант. Но в процессе его проведения пользователи видят заведомо неудачные варианты дольше, чем могли бы. А проект на этом теряет деньги. Да, в дальнейшем вы переключитесь на выигрышные варианты и будете оптимизировать траты. Но конкретно в день проведения теста проект гарантированно понесёт издержки.

Можно ли усидеть на двух стульях: найти самый эффективный вариант и минимизировать издержки? В этом кейсе мы попробовали найти своё решение.

У одного из наших клиентов был проект — hookup-дейтинг сервис Sweet.

Проект привлекал платный трафик в плюс, конверсия в покупку около 4%. Экономика проекта была на грани сходимости, поэтому в такой ситуации трудно увеличивать рекламный бюджет и привлекать больше пользователей.

Трафик привлекали из США через Snapchat. Пробовали другие источники, но Snapchat показывал лучшую эффективность по сравнению с остальными.

Чтобы быстрее свести экономику и увеличивать бюджет на трафик, решили оптимизировать конверсию в первую покупку. Так, чтобы трафик окупался в первый месяц. Стало очевидно, что нужно проводить тесты, проверять разные подходы. На тот момент у нас была первая закрытая бета A/B-тестов на платформе Appbooster, и мы внедрили её в проект.

Запускали несколько мелких экспериментов внутри приложения, но значимых изменений они не приносили. Затем решили тестировать экран подписки. Отрисовали 3 новых варианта пейволлов. На начало эксперимента трафик по ним распределился поровну, ключевой метрикой выбрали конверсию.

Эксперимент длился неделю. В это время Евгений, наш специалист по продуктовому сопровождению, отслеживал конверсию в аналитике и считал доверительные интервалы в другом инструменте. Доверительные интервалы показывают возможные колебания оцениваемых значений с заданной вероятностью. В нашем примере они позволяют посчитать, в каком интервале в 95% случаев будет находиться конверсия пейволлов. Их используют в классическом A/B-тестировании, чтобы понять, какой вариант теста лучше с точки зрения статистики. В зависимости от этих показателей Евгений раз в день менял распределение пользователей по вариантам, отдавая больше трафика лидирующему по конверсии пейволлу.

Эта методика немного отличается от A/B-тестов в классическом понимании. Обычно по ходу эксперимента не вносятся изменения. Но в контексте мобайл-индустрии такой способ ускоряет выбор наилучшего результата и уменьшает издержки на проведение теста.

В результате выбрали самый эффективный пейволл, который дает наибольшую конверсию, и применили его на 100% аудитории. За время этого теста собрали 745 покупок. CR в покупку на лучшем варианте составил 6,33%. Таким образом, ARPU первого месяца — $1,06. CPI в закупке через Snapchat был около $1, и это позволило закупать в плюс в первый месяц. А с учётом высокой возобновляемости платежей, приложение получило большой запас роста CPI и надёжную, стабильную юнит-экономику.

В итоге клиент на этом объёме свёл экономику проекта, а мы стали развивать сервис A/B-тестирования — все остались в плюсе.

Методика, которую использовал Евгений, лежит в основе принципа многоруких бандитов. Название связано с игровыми автоматами в казино, “однорукими бандитами”. Представьте: вы заходите в казино и видите множество таких автоматов. Каждый раз, когда вы дёргаете за ручку, вы выигрываете какую-то сумму денег. У вас есть ограниченное количество попыток дёрнуть за ручку. По закону вероятности некоторые автоматы приносят больше денег, чем другие. А вы, конечно, хотите выиграть как можно больше. И если бы вы заранее знали, какие автоматы приносят больше денег, на каких стоит продолжать играть, а какие оставить, то сорвали бы куш.

Так и в мобайле: у нас есть несколько вариантов пейволлов для приложения. Но мы так же не знаем, какой из них показать пользователям, чтобы получить наибольшее число покупок в условиях ограниченного трафика. В этом примере пейволлы — это ручки автомата. Наша задача — дёрнуть самую денежную ручку, то есть найти самый эффективный пейволл.

Для решения этой задачи придумали алгоритм многорукого бандита. Это такой же бандит, только у него не одна ручка, а много — по количеству тестируемых вариантов. Вот мы тестировали 4 варианта пейволов, у бандита — 4 ручки. Когда пользователь подходит к этапу оформления подписки, алгоритм выбирает, какой пейволл ему показать. Если в ходе эксперимента алгоритм понимает, что какой-то вариант приносит бóльшую конверсию — он будет чаще показывать его пользователям, чем остальные. Бандит как бы подсказывает, какие “ручки” стоит дёргать, чтобы получить максимально возможную конверсию в условиях неопределённости и ограниченного трафика.

В нашем кейсе Евгений работал за алгоритм, вручную перераспределял трафик. В чём минусы подхода?

Как решить это? Автоматизировать!

Развивая сервис A/B-тестирования, мы дополнили его новым алгоритмом Томпсоновского Семплирования — он решает проблему многорукого бандита. Это Евгений на максималках — алгоритм меняет распределение чаще и учитывает больше факторов. Проверить его состоятельность решили на реальных исторических данных Sweet. Выгрузили их и “скормили” алгоритму. Как бы он стал распределять трафик по вариантам вместо Евгения?

Вот, что получилось:

Оказалось, что алгоритм справился бы с задачей лучше. По результатам теста победил бы тот же вариант, что и при ручном распределении. Но за те же деньги на его проведение клиент получил бы больше покупок, показатель CAC был бы меньше. Если оценивать в деньгах, за 5 дней проект недозаработал около $ 7500 по когорте юзеров.

Эффективность подобных алгоритмов оценивается с помощью метрики сожаление (regret). Она показывает отклонение от идеального сценария. В данном случае Алгоритм Томпсона сходится к минимальному регрету — он “проиграл” всего 135 покупок идеальному варианту. Ручное распределение “проиграло” 325 покупок.

А вот наглядное изображение — в чём преимущество алгоритма Томпсона перед стандартными A/B-тестами:

Итак, возвращаясь к вопросу о том, стоит ли проводить тесты, если у вас небольшой проект. Да, стоит — подобные решения в разы снижают издержки на их проведение и ускоряют процесс. Именно поэтому мы реализовали алгоритм Томпсона на платформе и сейчас выпускаем его бету.

Пока алгоритм работает с AppsFlyer на тарифе Enterprise или Business, а также с Amplitude. В дальнейшем подключим и другие трекеры. Если вы прямо сейчас используете эти сервисы, обращайтесь к нам (Telegram). Кому подойдёт решение:

Но даже если у вас другой тариф или трекер, мы придумаем, как осуществить интеграцию. В планах создание алгоритмов для других задач, оптимизации на разные метрики (ARPU, ARPPU, LTV и т.д.), уменьшения регрета.

Прямо сейчас мы проверяем работу алгоритма на исторических данных других партнёрских проектов. Можем проверить его и на ваших данных — напишите нам в Telegram, если вам это интересно.

#abтестирование #a_b_тестирование #кейс #appstore #app_store #abtesting #appbooster