Текст книги "Игра в цифры. Как аналитика позволяет видеоиграм жить лучше"

A/B-тесты в играх

Я уже говорил, что важной особенностью и даже задачей аналитика является необходимость сомневаться. На самом деле мы не так много знаем (кстати, да, я говорил, что аналитики – чаще всего агностики?). Наши предположения и гипотезы всегда субъективны, и нам нужен инструмент их проверки на объективность. Прекрасным инструментом являются A/B-тесты.

Что вообще такое A/B-тест? Это последовательность действий, при которой разным группам пользователей показываются разные, слегка измененные версии игры. После чего (через некоторое время) замеряется, какая из групп пользователей сработала лучше, и на основании этого принимается решение, какая из версий затем станет доступна всем пользователям игры. Звучит достаточно просто, однако в этом деле существует очень – даже слишком – много нюансов, и о некоторых из них я расскажу.

A/B-тест – это фиксированная последовательность шагов, и я бы выделил следующие основные этапы.

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

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

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

4. Выбор метрик.

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

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

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

Давайте отдельно пройдемся по каждому.

Менять, вообще говоря, можно любой функционал в игре. Это могут быть формы с предлагаемыми скидками («Купи сейчас!» или «Сейчас купи!»), это могут быть картинки и тексты уведомлений, это могут быть различные призывы к действию (call to action), описания предметов и товаров, внешний вид внутриигрового магазина, игровой туториал, сложность уровня – что угодно. Чуть реже A/B-тесты делают, меняя монетизационные показатели, допустим, цены и размеры скидок на товары. Всегда существует риск, что при смене монетизационных условий для разных пользователей те могут счесть это дискриминацией и, во-первых, существенно подпортить репутацию игре (например, понизить ее рейтинг в магазине), а во-вторых, чисто статистически сделать тест менее достоверным.

Вам знакома игра Angry Birds 2?

Ее сделала финская компания Rovio на волне успеха после первой Angry Birds. Готовя Angry Birds 2 к запуску, Rovio A/B-тестировали несколько гипотез.

1. Когда в Google Play или AppStore вы открываете страничку с Angry Birds 2, чтоб скачать игру, вы можете увидеть скриншоты. Что лучше располагать на этих скриншотах – полюбившихся с первой части персонажей, взятых крупным планом, или же непосредственно процесс геймплея (например, летящую птицу)?

2. А скриншоты должны быть горизонтальными или вертикальными? Обычно по умолчанию человек держит телефон в руке вертикально, и в магазине приложений он скорее всего находится в вертикальном режиме. С другой стороны, игра Angry Birds 2 ориентирована горизонтально. Так вот, как лучше (даже такие мелочи важны, потому что могут существенно повлиять на конверсию в скачивание приложения)?

Я не знаю точных результатов их экспериментов, но на момент написания книги могу констатировать: на картинках есть геймплей, а не персонажи, и картинки ориентированы горизонтально.

Еще один тест. Один (неигровой) сервис тестировал форму регистрации. На одном из вариантов просто были стандартные поля для заполнения, на другом была еще и призванная успокоить пользователя фраза „100 % privacy – we will never spam you“

(«100 % конфиденциальность – мы никогда не будем вас спамить»). Как вы думаете, какая из форм дала лучшую конверсию в регистрацию? Первая!

Видимо, пользователи, видя слово spam, в страхе покидали форму регистрации раньше, чем замечали слово never (никогда).

В итоге потребовался еще один A/B-тест, и победителем стала вариация формы регистрации, где был следующий текст: „We guarantee 100 % privacy. Your information will not be shared“ («Мы гарантируем 100 % конфиденциальность. Ваша информация никуда не утечет»).

И еще один пример. Представьте, что вы хотите протестировать гипотезу, важна ли игрокам скорость работы вашей игры. Станут ли они лучше платить, если игра будет быстрее? Чтобы проверить это напрямую, потребуется потратить немало времени на ускорение приложения; ускорение касается работы самого приложения, скорости связи с сервером, контакта к базе данных и т. д. Ускорить игру – процесс трудоемкий. Как же проверить нашу гипотезу?

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

Итого чаще всего меняются следующие элементы игры:

– ASO (как приложение размещено в магазине приложений);

– визуальное оформление;

– призывы к действию (call to action);

– FTUE (первая сессия);

– описания и тексты;

– реклама (где и в какой момент всплывает в игре рекламное сообщение);

– Push-уведомления и тайминг (когда присылать уведомления игроку и с каким текстом);

– цены и акции;

– экраны покупки и магазин.

Сколько может быть вариантов в A/B-тесте? По определению теста – вроде как два, группа A и группа B. На самом же деле вариантов может быть сколько угодно.

Допустим, вы хотите проверить две гипотезы сразу: сравнить красную и зеленую кнопки покупки, а также два вида продающего текста. Как нам запускать эти тесты, говоря языком физики: параллельно или последовательно?

Некоторые сначала выберут цвет кнопки, а лишь потом, зафиксировав цвет-победитель, пойдут искать лучший из двух вариантов продающего текста.

Я же предлагаю запустить сразу два теста, в одно и то же время. У нас есть два варианта кнопки и два варианта текста. Мы перемножаем одно на другое и получаем 4 группы для теста. Такой подход называется мультивариантным тестированием.

Плюс такого подхода – мы экономим время на тест. Минус – в каждую из групп попадет меньше людей, и нам будет несколько труднее достигать статистической значимости. Поэтому я рекомендую при небольшом числе вариантов не стесняться прибегать к мультивариантному тестированию. Ну а если у вас 10 вариантов на первый тест и 10 вариантов на второй, то, перемножив их, мы получим 100, и лучше такие тесты не делать, а запустить сначала один, а потом второй тест.

Сколько нужно пользователей, какие они должны быть?

Было бы здорово, если б существовала константа. Скажем, 1000 пользователей в каждую группу теста – и все. Но нет, там все гораздо сложнее.

Для начала нужно ответить на ряд вопросов.

1. А сколько будет групп теста? Две или больше?

2. А какое изменение мы хотим «отловить»? Если мы сделали изменение, которое обещает поднять Retention с 30 до 40 %, то пользователей много и не надо – мы сможем это доказать и на маленькой выборке. А если оно обещает изменить показатель с 30 до 30,1 %, то и больше потребуется пользователей, чтобы доказать, что наше изменение действительно сработало статистически значимым образом.

3. Какой у нас уровень значимости? О том, что это такое, мы поговорим чуть позже.

Все это вместе и определяет размер выборки. Памятуя о том, что каждая формула в книге уменьшает число ее читателей вдвое, я не буду вставлять сюда формул. Скажу лишь, что сейчас существует достаточно много калькуляторов (вбейте в строке поиска «калькулятор выборки»), и он сам вам все посчитает.

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

Пример

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

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

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

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

И еще очень важно, чтобы распределение по группам теста происходило случайно. Например, если вы пользователям, пришедшим в среду, показываете одно, а тем, кто пришел в четверг, другое, то это ошибка. Это разные пользователи, они пришли в разные дни, по-разному мотивированы и несут в себе, вообще говоря, разный потенциал. То же касается и пользователей из Франции и Германии, из источника трафика 1 и источника трафика 2.

А как правильно? Помните шляпу из Хогвартса?

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

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

А еще есть вариант с AAB-тестом. Мы (случайно!) раскидываем пользователей на три примерно одинаковые группы, и для двух из них не меняем ничего, а для третьей – меняем. И тест будем считать успешным лишь в том случае, если группы A1 и A2 не отличаются друг от друга (статистически значимо не отличаются), и обе из них в одну и ту же сторону статистически значимо отличаются от группы B.

Здесь достаточно просто. Нам подойдут те же самые метрики, которые подходят для когортного анализа, – метрики качества проекта:

– ARPU;

– ARPPU;

– доля платящих и конверсия в платеж;

– Retention;

– накопительный доход за N дней.

А метрики количества (DAU, MAU, New Users, Gross, Revenue) тут не подойдут. Максимум, для чего они нужны, – чтобы указать нам на размер когорты, можем ли мы ей доверять.

В конце концов, A/B-тесты нацелены именно на изменение качества проекта, а количественные показатели – лишь следствие.

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

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

Самое время скрестить пальцы. Совсем скоро мы узнаем, прошла ли наша гипотеза проверку на прочность.

Но здесь нас поджидает еще одна крупная потенциальная ошибка.

Допустим, запуская тест, вы заранее сделали ставку на какой-то из вариантов, вы болеете за него, как за лошадь на скачках. И пока тест идет, вы ненароком подглядываете, как там дела у метрик теста. В какой-то момент может возникнуть соблазн: кажется, наш фаворит действительно впереди, останавливаем тест, тут все понятно. Вот это и есть ошибка!

Такая проблема называется peeking problem, или проблема подглядывания. Многие ее допускают, и статистически доказано, что делать это неправильно. Вы же не останавливаете футбольный матч через 15 минут. И не останавливаете, если какая-то команда забила первый гол (к правилу золотого гола это не относится). Так давайте же дождемся окончания матча – простите, теста, – чтобы удостовериться в том, что тест действительно прошел правильно.

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

Допустим, в каждой из групп теста по 50 человек. И вы замеряете их среднее время сессии. У группы A получилось 3 минуты, а у группы B – 3 минуты и 3 секунды. Значит ли это, что группа B несет в себе такое изменение, которое действительно изменит длину сессии для всех в будущем? Вовсе нет.

Начиная с какого объема выборки или начиная с какой длины сессии мы сможем сказать: «Да, скорее всего, группа B действительно лучше»?

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

Как правило, значимость устанавливают на уровне 10 %, 5 %, 1 %, 0,1 %. Конечно, чем ниже мера ошибки, тем лучше и надежнее, но тем труднее в реальности ее достичь.

Существует два подхода к статистической значимости: частотный и байесовский.

В вузах, как правило, изучают частотный подход: нулевая гипотеза H0, альтернативная гипотеза H1, ошибки первого и второго родов, а на выходе – значение p-value. Чем оно меньше, тем лучше. Тем меньше вероятность ошибиться с результатами теста.

В последнее время все больше популярен байесовский подход. Он несколько иначе определяет и статистику, и вероятность (например, уже на второй-третьей странице в книжках про метод Байеса появляется понятие «вероятность вероятности»). Вероятность в нем определяется субъективно и считается до теста и после теста – так называемые априорная и апостериорная вероятности.

Байесовский метод труднее в расчетах и понимании, там очень сложные формулы, но зато он прост в трактовке результатов теста: мы просто получаем на выходе вероятность «победы» каждого варианта.

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

Выбирайте сами, что вам ближе.

Но я сразу скажу, что для обоих методов существуют онлайн-калькуляторы, и я вовсе не против, чтобы вы ими пользовались. Главное – держать в голове все вышеупомянутые нюансы.

Устали от статистики? Подождите уходить!

Мы еще не поговорили о биномиальных и небиномиальных метриках. Но тут все просто: биномиальные – это те метрики, которые, грубо говоря, «либо да, либо нет». Пользователь либо вернется на седьмой день, либо нет – метрика Retention биномиальная. Пользователь либо заплатит, либо нет – метрика конверсии в платеж также биномиальная.

Небиномиальные – это такие метрики, которые измеряются не в процентах, а в деньгах, минутах, какой-то непрерывной единице измерения. Например, это метрики ARPU, LTV и длины сессии.

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

Итого, статистика A/B-тестов сводится к двум классификациям: частотный и байесовский подходы, биномиальные и небиномиальные метрики.

Как видим, самый сложный случай – это байесовский подход с небиномиальными метриками, и на момент написания этой книги по нему почти нет материалов на русском языке. Зато есть пакет PyMC3 на Python.

Резюмируем статистическую часть: решаем про то, какой подход нам использовать, классифицируем метрики на биномиальные и небиномиальные, а дальше идем и ищем онлайн-калькулятор. Либо (если умеете) идем и подгружаем нужный нам пакет в Python – не руками же нам это считать?

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

Какие могут быть ошибки?

– Неправильные гипотезы и недостаточно заметные изменения. Вы уже поняли, что чем меньшее изменение мы хотим поймать, тем больше пользователей нам нужно. А чем меньше у нас пользователей в тесте, тем бо́льшие изменения мы должны закладывать в тест. Но далеко не всегда вы можете придумать что-то такое, что по щелчку поднимет вам Retention с 30 до 40 %. А значит, надо искать баланс, и вот тут можно ошибиться в ту или иную сторону.

– Выгодная трактовка результатов эксперимента. Тут чаще всего случается та самая ошибка подглядывания: «И так все понятно». Чтобы не ошибиться, дождитесь окончания теста. И да, здесь лучше забыть про интуицию!

– Ошибки с аудиторией. Слишком мало пользователей, либо пользователи не те (например, они уже видели этот функционал), либо аудитории доверять нельзя, а вы не проверили это AA-тестом.

Еще пара нюансов.

Можно ли запускать несколько тестов одновременно?

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

Красна ли кнопка, пока мы ее не видим? Точнее, не так. Если сегодня в тесте победила красная кнопка, значит ли это, что через месяц победит она же? Вообще говоря, не факт, и периодически (когда аудитория игры поменяется этак на 90 %) есть смысл перепроверять результаты теста. Если что-то сработало у кого-то одного, то нет гарантии, что это сработает и у вас. Более того, нет гарантии, что у вас сработает то же, что срабатывало у вас раньше, – слишком быстро меняются и игра, и аудитория.

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

Итак, лучше всего работают следующие механизмы.

– Дефицит (отображение количества доступных единиц товара): на сайте осталось лишь 10 холодильников!

– Социальное доказательство (обзоры и комментарии покупателей): ваш друг Вася уже играет в эту игру.

– Срочность (таймер, Countdown): акция закончится через 59 минут, ой, уже 58!

Интересно, что на некоторых сайтах, например на booking.com, все эти механизмы работают одновременно. Но если работают, то почему бы и нет.

Нужно понимать, что у A/B-тестов как инструмента есть несколько обратных сторон медали:

– бо́льшая часть A/B-тестов проваливается – выше я объяснял почему, – и надо быть к этому готовым;

– если их делать «по уму», то возникает очень много нюансов. И поверьте, далеко не обо всех я рассказал в попытке сделать книгу более «казуальной» для восприятия;

– а если делать «не по уму», то можно прийти к ошибочным решениям – и это правда;

– тесты требуют большой аудитории;

– прирост от одного теста, как правило, невелик. Трудно сделать такое изменение, которое единомоментно изменит игру и ее метрики до неузнаваемости;

– спустя время тестам требуется перепроверка;

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

Окей, вы поняли, что A/B-тесты – это не для вас. Куда вам идти? Вообще говоря, в начало главы про A/B-тесты и data driven-подход. Но если вы и после этого верны своему мнению, то вот вам несколько альтернатив.

– Опросы – иногда проще и быстрее попросить игроков заполнить опросную форму, но имейте в виду, что у опросов есть своя медицинская книга нюансов. В частности, смотрите мои рассуждения про Net Promoter Score.

– Customer development – это широкое понятие, но я использую его в смысле глубинных интервью с вашими пользователями. Могу порекомендовать книгу Фитцпатрика «Спроси маму» – в ней он рассуждает о том, как непредвзято общаться с пользователями и принимать решения по итогам этого общения.

– Детальная аналитика имеющейся аудитории. Иногда и тестов делать не надо, а можно просто углубиться в существующие данные и найти в них ответ. Сегментирование вам в помощь!