A/B тесты в LiveOps
A/B-тестирование LiveOps в играх: идеи, генерация вариантов, выбор метрик, подготовка выборки, само тестирование и интерпретация результатов теста
A/B тесты в LiveOps
Published
28.05.2020
|
devtodev

LiveOps - одна из самых требовательных к данным отраслей геймдева, и сегодня мы покажем, как A/B тесты могут там работать.

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

Перед тем, как реализовать A/B тест мы должны составить план, который, в целом, будет выглядеть следующим образом:

  1. идея эксперимента;

  2. генерация вариантов (что именно мы меняем для разных групп);

  3. выбор метрик;

  4. подготовка выборки; 

  5. предварительное тестирование;

  6. непосредственно эксперимент;

  7. интерпретация результатов.

Если вам интересесна эта тема, проходите наш бесплатный онлайн-курс по LiveOps в играх

Идея эксперимента

Применительно к LiveOps, очень часто меняют две вещи:

  • тексты оффера - условно говоря, “купи меч скорее” или “купи скорее меч”.

  • визуальное оформление оффера.

В целом, A/B тестами можно проверять гипотезы по:

  • ASO. Например, Angry Birds 2 тестировали три вещи применительно к скриншотам: нужно ли размещать персонажей (показать непосредственно процесс геймплея); делать вертикальные или горизонтальные скриншоты (мы смотрим на телефон вертикально, но в эту игру играем горизонтально); нужны ли рамочки на скриншотах (некоторые игроки любят эти рамочки).

  • Визуальное оформление (одна кнопочка или две, если две - то какой текст будет на каждой из них)

  • Призывы к действию

  • FTUE

  • Описание и тексты

  • Реклама

  • Push-уведомления и тайминг

  • Цены и акции (цены тестируют реже, чем акции из-за проблем, которые могут возникать вследствие коммуникации между тестируемыми группами)

  • Экраны покупки и магазин

  • И т.д.

100 идей для A/B-теста на Хабре

Ухудшающие тесты

Для тестирования Live Ops-событий можно проводить так называемые “ухудшающие тесты”.Например, мы хотим добавить дополнительные уровни и проверяем гипотезу - нужны они игрокам, или нет. Мы не можем тратить на них время, не зная, какую пользу они нам принесут, ведь, например, создание 50 дополнительных уровней - это ещё месяц работы. Как проверить без лишних затрат? Скажем, у нас в игре уже есть 150 уровней. Тогда для одной группы новичков можно сократить это число до 100, а для второй оставить 150 уровней. Это и есть ухудшающий A/B тест, в котором одна группа получает заведомо более плохой вариант. Если мы видим, что те люди, которые проходили 150 уровней, показали лучший результат, у них были более хорошие метрики, то мы можем сказать, что, да, дополнительные уровни нам потребуются.

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

Смотрите вебинар A/B-тесты в играх: основные ошибки и важные нюансы

Генерация вариантов

Кажется, что вариантов A/B теста может быть только два, - A и B, но на самом деле, их может быть гораздо больше, поскольку существует ещё и мультивариантное тестирование. Например, мы хотим сделать два теста - тест над ценой и тест над текстом. Цена 2 доллара или 3 доллара и текст “купи скорее” или “скорее купи”. Эти тесты мы можем провести либо параллельно (два теста одновременно), либо последовательно (сначала проводим один, потом другой). Первый вариант - это и есть мультивариантное тестирование. То есть, у нас есть два варианта цены и два варианта текста, мы их перемножаем и получаем 4 варианта, и одновременно их проверяем. Это удобный способ при наличии небольшого количества вариантов. Но если у нас гипотез больше, чем две, например, 10 вариантов цвета фона и 10 вариантов цвета кнопочки, то мы получаем 100 вариантов, и тогда в каждой группе будет недостаточно людей, чтобы достичь статистической значимости (читайте про неё ниже).

Читатйте также статью про карту метрик игровой аналитики devtodev

ВЫБОР МЕТРИК

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

  • Конверсии различного типа (например, какая доля пользователей конвертировалась в платёж по итогам недели, или какая доля пользователей конвертировалась в пятый и выше платежи по итогам месяца).

  • Retention - показатели удержания 1, 7, 20 дня.

  • Метрики монетизации, например, ARPU, размер первого платежа и т.д.

  • Любые другие кастомные метрики, на которые вы хотите своим тестом повлиять.

Возьмём, к примеру, метрику накопительного дохода:

Метрика накопительного дохода график
Скриншот из аналитической системы devtodev

Если мы посмотрим на Cumulative ARPU 7 дня на этом графике, то сможем понять, сколько денег пользователь приносит нам за свои первые 7 дней в игре. Это очень хорошая метрика, потому что в ней косвенно учитывается Retention и, при этом, напрямую учитывается монетизация, то есть, она очень ясно говорит о качественном изменении продукта. Если вводимое нами изменение хоть сколь нибудь касается монетизации, то эту метрику вполне можно использовать для A/B тестов.

devtodev - аналитический сервис, разработанный специально для игр . С помощью devtodev можно проанализировать поведение платящей аудитории, выявить узкие места в экономике игры, оценить эффективность игровых уровней и спрогнозировать LTV

Подготовка выборки

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

Планируя A/B тест, мы должны понимать,

  • Сколько у нас будут групп.

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

  • Какого изменения мы добиваемся.

Существует грубая формула, которую не рекомендуется использовать:

Формула статистической вероятности

Но в ней есть интересный показатель, на который стоит обратить внимание. В числителе есть стандартное отклонение в квадрате (чем менее стабильно ведёт себя метрика, тем больше пользователей нам нужно, чтобы провести тест), а в знаменателе есть изменение, которого мы хотим добиться. Таким образом, чем более мелкого изменения мы хотим добиться, тем в квадрате больше пользователей нам для этого потребуется. Например, если у нас Retention 30%, но путём добавления Live Ops ивента, мы хотим сделать его 40% (это маловероятно, но это будет резко заметно), то это можно проверить на маленьком количестве пользователей. Если Retention у нас был 30%, а мы хотим проверить, стал ли он 30,1%, причём это должно быть статистически значимо, то тогда нам нужно будет очень много пользователей.

Самое важное, что разбиение должно быть случайным. В корне неправильно определять пользователей, пришедших, например, в среду в одну группу, а пользователей, пришедших в четверг, в другую. Это разные пользователи, они по-разному мотивированы, они пришли в разные дни. Правильно и тех и других объединить в один сегмент и распределить случайным образом по двум группам.

Читайте также: Как оптимизировать магазин free-to-play игры

Предварительное тестирование

Прежде, чем начинать A/B тест, нужно проверить, достаточно ли хороша наша аудитория, чтобы доверять полученным результатам. Для этого можно провести АА-тест и ААВ-тест.

В А/А тесте мы ничего ни для кого не меняем, а просто случайным образом распределяем аудиторию по двум группам и проверяем по ней метрики. Если они совпадают - всё хорошо. Если нет, то это значит, что наша аудитория слишком разношёрстная, чтобы ей доверять. И, вполне возможно, что стоит увеличить её объём, чтобы по закону больших чисел метрики более-менее усреднились, и тогда мы сможем начать работать.

Чтобы А/А тест не выносить в отдельный этап, можно применить А/А/В тест, когда для двух групп мы не меняем ничего, а для третьей что-то меняем. Тогда получается, что тест будет успешным, если мы статистически значимо докажем, что разницы между А1 и А2 нет, и что и А1 и А2 отличаются от В в одну и ту же сторону.

Кейс Google

Ходят слухи, что Google применял A/B-тестирование, когда выбирал оттенок голубого для ссылок в письмах. Было создано несколько десятков вариантов, которые распределили по всем пользователям и замерили их CTR. И тот цвет, который победил, и который сейчас и используется, выиграл с отрывом всего на какую-то долю процента. Но его CTR был статистически значимо выше, поскольку у Google было достаточно пользователей, чтобы провести этот эксперимент и получить достоверный результат. Если вы не Google, то старайтесь не делать A/B тесты на 40 вариантах.

Читайте также: Главные метрики. Churn Rate

Интерпретация результатов

До того, как подойдёт время интерпретации результатов, мы рискуем столкнуться с соблазном подглядеть в результаты. То есть, когда мы уже запустили тест, у нас часто есть внутренний фаворит или версия, которая очень нравится продюсеру. И бывает такое, что тест ещё не закончился, все пользователи ещё не прошли через тест, однако мы подглядываем в результаты и нам кажется, что фаворит уже выигрывает, и мы принимаем решение о том, что можно тест остановить. Останавливаем. Но часто это является ошибкой. И если бы мы всю выделенную для этого аудиторию прогнали через тест, то результаты могли бы быть иными. Это то же самое, как если бы матч между ФК Барселона и другой малоизвестной командой останавливали бы за 15 минут до окончания, если бы Барселона успевала забить гол. Но все мы знаем, что за 90 минут матча случается много неожиданностей. Поэтому подглядывать в результаты можно, но всегда нужно дожидаться того, чтобы вся выборка проходила через тест.

Читайте также: Главные метрики. Downloads

Статистическая значимость

Значимость - это некая мера уверенности. Мы можем сказать, что тест значим, если мы уверены в том, что результаты, которые мы получили на маленькой выборке, будут точно такими же и на более крупной аудитории. Значимость зависит от многих факторов и мы сами выбираем себе некий уровень, в котором мы можем ошибиться, например, с вероятностью не более, чем 1%. То есть, мы уверены в результате на 99%.

Существует два подхода к измерению значимости:

1. Частотный подход. Именно его, в основном, изучают в вузах.

  • В нём вероятность - это частота совершения события.

  • Им проверяют статистические гипотезы.

  • На выходе получаем p-value.

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

2. Байесовский подход.

  • Вероятность в нём - это степень уверенности (субъективная вероятность).

  • На выходе мы получаем вероятность успеха по каждому из вариантов.

Он менее требователен к исходным данным: мы не обязательно должны проверять распределение, нам для этого достаточно меньшего объёма данных, но платой за это является некоторая сложность байесовских расчётов. 

Применение частотного и Байесовского подходов к разным метрикам

Путём лайвопса мы влияем на разные метрики. Существуют:

1. Биномиальные метрики. Они обычно измеряются в процентах:

  • 0 или 1 (да или нет)

  • Конверсия (заплатил/не заплатил, перешёл/не перешёл)

  • Retention (вернулся/не вернулся)

2. Небиномиальные метрики. Они измеряются не в процентах, а, например, в деньгах или минутах:

  • ARPU

  • ARPPU

  • LTV

  • Продолжительность сессии

Рассмотрим несколько случаев:

Частотный подход и биноминальные метрики (например, Retention или конверсии)

Тут можно использовать классический t-тест (t-критерий Стьюдента) или z-тест (z-критерий Фишера).

Частотный подход

Байесовский подход и биноминальные метрики

Здесь вероятность несколько субъективна. Она оценивается до теста (априорная вероятность) и после теста (апосториорная вероятность). Главное, что стоит понимать - что этот подход работает несколько по-другому, нежели частотный подход.

Плюс этого метода в том, что в результате вы получаете не p-value, а, условно говоря, вероятность успеха каждой из групп теста. И его довольно удобно трактовать. Хотя и трудно считать.

Байесовский подход

Для небиномиальных метрик используются другие методы статистического анализа. Это важно учитывать, потому что в LiveOps большинство изменений касается денег.

Биноминальные и небиноминальные метрики

Читайте также: Главные метрики. ROI

Итого. Основные ошибки в A/B тестах

  1. Неправильные гипотезы и недостаточно заметные изменения (мы не всегда чётко понимаем, сколько пользователей у нас есть, и на какие изменения мы рассчитываем).

  2. Выгодная (для себя) трактовка результатов эксперимента (проблема подглядывания; отсутствие результата по заданной заранее метрике и смена её после получения результатов теста на другую).

  3. Интуиция (её вообще нельзя использовать при проведении тестов).

  4. Аудитория

  • новая/не новая

  • источники трафика (по одному источнику трафика даётся одна версия теста, по другому - другая)

  • платящие/не платящие

  1. Слишком мало пользователей (на маленькой аудитории можно проверить лишь очень заметные гипотезы).

  2. Несколько тестов одновременно (мультивариантное тестирование проводить можно, но нужно проверять гипотезы, как можно меньше влияющие друг на друга).

  3. Качество тестов может меняться от проекта к проекту, во времени и т.п. (то, что сработало для одного проекта, не факт, что сработает для другого проекта; более того, то, что сработало для этого проекта, может не сработать для него же через год).

  4. Статистическая значимость.

  5. Отсутствие предварительного тестирования.

  6. Неверно выбранные метрики.

  7. Неверно определённый размер выборки (слишком маленькая или слишком большая).

В A/B- тестах не всё так просто. И, как ни странно, не всегда 51 будет больше 50.

Негативные стороны A/B-тестов

  • Большая часть A/B тестов проваливается.

  • Если проводить их по уму, то возникает очень много нюансов, на которые мы не можем закрывать глаза.

  • Если проводить их не по уму, то можно прийти к ошибочным решениям.

  • Требуют большой аудитории.

  • Прирост от одного теста, как правило, невелик.

  • Требуется перепроверка спустя время.

  • Это затягивает.

Проходите наши бесплатные онлайн-курсы, раскрывающие разные стороны геймдева и аналитики

Кейс для тех, кто дочитал

A/B-тесты часто публикуют в Интернете, и нашлись люди, которые проанализировали 6700 A/B тестов в сфере e-commerce, и определили, какие изменения в хорошо работают в этой сфере (какие дают значимые результаты A/B тестов):

  • Дефицит (отображение доступного количества товара)

  • Социальное доказательство (обзоры и комментарии покупателей)

  • Срочность (таймер, countdown)

Read more