(function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)}; m[i].l=1*new Date(); for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }} k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)}) (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym"); ym(94899836, "init", { defer: true, clickmap:true, trackLinks:true, accurateTrackBounce:true }); ym(94899836, 'hit', window.location.href);

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

Про важность A/B-тестирования написаны сотни статей, книг, примерно столько же записано вебинаров. Кратный рост продуктов без проведения экспериментов сейчас уже практически невозможен. Но всё равно по разным причинам не все их проводят. Самый распространённый аргумент: A/B-тесты — это долго и дорого, особенно для небольших проектов. Разбираемся, есть ли смысл проводить тесты, если вы не Яндекс или Тинькофф.

Как работают классические сплит-тесты и что с ними не так?

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

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

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

Кейс, часть 1: A/B-тест

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

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

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

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

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

4 варианта пейволлов, участвовавших в тесте. Последний пейволл на картинке — изначальный вариант в приложении до теста.

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

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

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

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

Многорукий бандит

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

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

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

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

  • Тратится время продакта/аналитика/маркетолога, которому нужно регулярно следить за тестом и перераспределять его;
  • Распределение выполняется человеком. Поэтому его точность не абсолютна — Евгений спит по 8 часов в сутки и в это время не может изменять распределение трафика по вариантам;

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

Кейс, часть 2: Многорукий бандит в деле

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

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

  • Идеальный вариант: 1070 (100%). Столько покупок мы могли получить, если бы угадали самый эффективный пейволл и применили его без всяких тестов.
  • Исторически получили: 745 покупок (69%). Столько покупок мы получили благодаря распределению Евгения.
  • Алгоритм Томпсона: 935 (87%). Столько покупок принес бы нам бандит.

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

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

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

Графики распределения трафика по вариантам

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

Бандит на платформе

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

  • Тем, кто хочет начать запускать умные A/B-тесты для своего приложения;
  • Тем, кто проводит много экспериментов и хочет автоматизировать их проведение. Алгоритм выполняет сам все операции, которые во время теста выполнял маркетолог/аналитик/продакт;
  • Тем, кто хочет уменьшить затраты на проведение тестов.

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

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

0
9 комментариев
Написать комментарий...
Elena Bugakova

Отличная статья, спасибо! А вы выводите уже в админку результаты по каждому варианту онлайн? 

Ответить
Развернуть ветку
Appbooster
Автор

Да, при интеграции с AppsFlyer

Ответить
Развернуть ветку
Виктор Бабицкий

Утверждали ли варианты экранов c AppReview перед тестированием? Какой в итоге вариант победил?

Ответить
Развернуть ветку
Appbooster
Автор

Когда отправляли билд с тестом на проверку, в сопроводительном сообщении написали, что проводят а/б тест экранов оплаты, и приложили скриншоты самих экранов. Также писали, что чтобы посмотреть, как работают все, нужно с 4 девайсов открыть приложение.

Что модерация сделала с этим сообщением мы не знаем, но билд пропустили)

Выиграл вариант, который первый на картинке.

Ответить
Развернуть ветку
Виктор Бабицкий

Спасибо

Ответить
Развернуть ветку
Василиса Соколова

Интересный кейс, отличная идея для оптимизации. Я не очень поняла как Евгений считал доверительные интервалы каждый день, если речь идет о конверсиях, те у него было фактически 28 цифр за 7 дней (пока каждой картинке одна абсолюная конверсия в день), c чем он сравнивал эти цифры с историческими данными?
И какой пропорции перераспределялись пользователи?

Ответить
Развернуть ветку
Appbooster
Автор

По поводу 28 цифр за 7 дней, тут не совсем верно, у нас было 4 значения конверсии каждый день, и мы их каждый день обновляли.

Мы считаем конверсию из инсталла в покупку (можно считать из просмотра экрана оплаты в покупку, так будет быстрее, но в кейсе мы пишем про конверсию из инсталла в покупку, так как это более распространённая метрика).

Например, за первый день на одном варианте теста у нас было 1000 пользователей и 60 покупок, мы можем посчитать доверительный интервал. На втором варианте — 1000 пользователей и 50 покупок, тут тоже можем посчитать интервал, и так далее. На следующий день мы берём данные за оба дня и снова считаем интервалы.
И эти интервалы мы сравниваем между собой, чтобы понять какой вариант лучше.

Как это работает:

Когда значение верхней границы интервала для одного варианта станет меньше, чем нижняя граница интервала другого варианта, это значит, что другой вариант работает лучше (с разными уровнями достоверности).

Вы можете попробовать воспользоваться бесплатным калькулятором доверительных интервалов от mindbox https://mindbox.ru/ab-test-calculator/, нужно выбрать вкладку «Итоги тестирования» (https://take.ms/70Lcd)

По поводу пропорций — сколько трафика какому варианту мы отдавали при ручном распределении, сейчас эти данные уже сложно найти, но суть в том, что мы отдавали текущему лидеру больше трафика. А какие именно доли — это не так важно.

Ответить
Развернуть ветку
Katya Badeyeva

Интересный подход. Сходу появились вопросы.
Если говорить про оптимизацию расходов на вашем примере, то
1) в чем смысл оставлять 3 и 4 вариант в тесте, то есть тратить деньги на трафик, если очевидно, что их в расчет не стоит брать. Вместо этого на 3ий день трафик полностью можно было бы перераспределить на 2 лидирующих варианта, тем самым приблизившись к 100% инстала. 
2) к тому же на маленьком кол-ве пользователей искажается статистика. (условно, если из 10 человек установило 6, то это не значит, что конверсия 60%). И доверительный интервал также может не сработать на маленькой выборке.

Ответить
Развернуть ветку
Appbooster
Автор

1. Смысл в мат. статистике, мы вели тест до тех пор, пока доверительные интервалы не разойдутся. То, что на третий день 3 и 4 вариант показывали себя хуже, не значит что они на самом деле хуже с математической точки зрения. В нашем кейсе совпало что да, но это не правило, это скорее исключение.

2. Смысл доверительного интервала как раз в том, чтобы даже на маленькой выборке понять, значимы изменения или нет. Например, у нас есть два варианта, в первом купили 6 из 10, во втором 8 из 10. CR 60% и 80% соответственно. Но с точки зрения мат. статистики и доверительных интервалов, эти варианты не различаются, как раз потому что слишком мало пользователей в выборке.

Попробуйте поиграться с калькулятором а/б тестов, чтобы лучше понять как это работает, например вот тут — https://mindbox.ru/ab-test-calculator/

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда