Книга: Игра в цифры. Как аналитика позволяет видеоиграм жить лучше
Назад: A/B-тесты в играх
Дальше: Итак, мы запустили тест

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

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

Было бы здорово, если б существовала константа. Скажем, 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.

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

Назад: A/B-тесты в играх
Дальше: Итак, мы запустили тест