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

Про важность 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