Подготовка выборки
Сколько нужно пользователей, какие они должны быть?
Было бы здорово, если б существовала константа. Скажем, 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.
Но на деле вы вольны выбирать любые другие качественные метрики для своих тестов. Любая конверсия, например, отлично подойдет.
