В текущих реалиях индюшатины каждый человек на вес золота и выделять для аналитики отдельного человека - расточительство. Вместе с тем сфера аналитики как дремучей лес, мало информации, множество непонятных терминов и сложных вычислений. Однако это совершенно не мешает чтобы грубо, как обезьяна, потыкать палкой в эту странную сферу и получить дополнительный вектор для развития проекта.
Статья рассчитана в первую очередь на проекты с уже настроенной аналитикой, когда результаты собраны, но что делать с ними дальше вы не знаете. Вполне ожидаемо следующим шагом развития станут попытки повлиять на метрики каким-либо образом, естественно так или иначе вам придётся столкнуться с А/Б тестированием. Я попытался выделить общие подходы которые могут быть применимы к инди проектам когда разработка происходит в отсутствие квалифицированных специалистов и ограниченном бюджете. Ради этого придётся существенно пожертвовать точностью самих А/Б тестов, однако лучше хоть что-то чем совсем ничего, верно? В любом случае не нужно это рассматривать как основной подход для принятия решений об изменениях в проекте, а скорее как дополнительное направление для разработки когда других идей не осталось.
Перед тем как начать
Немного определимся с терминами. А/Б тест - обычно подразумевают ситуацию когда имеются две версии игры: оригинальная и модифицированная, между этими версиями распределяют игроков, а затем сравнивают результаты аналитики. Но вне контекста формулировка 'А/Б тест' может нести в себе разное значение.
Поэтому чтобы не допустить путаницы я буду использовать термин 'Группа изменений' или просто 'Группа' - это изменение или набор изменений относительно нашей основной версии, иными словами модифицированная версия. А под 'А/Б тестом' я буду иметь ввиду сам подход применяемый к нашим группам.
'Контрольная версия' - она же 'контрольная группа', не модифицированная версия, оригинальная.
'Выборка' - набор пользователей для одной группы изменений.
Задача А/Б тестирования
На самом деле в качестве результатов законченного теста нужны не численные значения полученных метрик, а динамика этих метрик относительно контрольной версии. Хотя и это не совсем верно. В отсутствии опыта работы с аналитикой я как разработчик хочу узнать только направление в котором мне нужно развивать проект чтобы 'сделать игру лучше', А/Б тест для меня лишь инструмент которому не повезло попасться в мои неопытные руки. Ввиду этого поиск направления выглядит примерно так: случайные изменения проекта -> запуск А/Б теста -> если динамика положительная, вносим эти изменения в контрольную версию и оставляем -> если динамика отрицательная или в районе погрешности, начать сначала. Всё что от нас здесь требуется - снизить статистическую погрешность и постараться учитывать влияние внешней среды.
Требования к проекту для тестирования
Конечно в первую очередь это работающая аналитика и инструмент для A/Б тестирования. Так же нужно смириться с тем, что для проекта в целом может не подойти сам метод А/Б тестирования, например: когда динамика метрик от изменений так мала что не превосходит погрешность, это оффлайн игра, одиночная, с P2P монетизацией, и т.д.
Но помимо этого важно обеспечить поток трафика на время итерации теста так чтобы аудитория для всех групп была одинаковая. Результаты теста будут некорректными если для одной группы у вас будут по большей части пользователи из вашей целевой аудитории, а для другой группы абсолютно противоположные пользователи. Результаты этих тестов нельзя сравнить друг с другом. Однако если разделить трафик поровну между обоими группами так чтобы в среднем у вас получились две идентичные выборки пользователей, то проблем не будет. Но если у вас идёт рекламная компания и весь трафик идёт в первую группу, а затем через время для второй группы вы запустили новую компанию вы можете получить не тот трафик что был в первой группе, только этот фактор может повлиять на метрики и сделать сравнение некорректным. Главное помнить что результаты тестов нельзя сравнивать если аудитория участвовавшая в этих тестов разная.
Выборка и нюансы
Нужно заметить что выборкой считаются только те пользователи которые закончили то действие которое мы отслеживаем, или повлияли на отслеживаемую метрику. Например мы отслеживаем процент пользователей которые прошли уровень 1 и перешли на уровень 2, здесь выборкой будет считать не то количество пользователей которых мы залили в игру или не то которое начали первый уровень, а те пользователи которые перешли на уровень 2 и оставили вклад в отслеживаемую метрику.
При проведении тестов главная задача снизить погрешность и ошибку этих тестов, с этим напрямую коррелирует размер выборку. Однако больше не всегда значит лучше. Линейное уменьшение статистической погрешности требует экспоненциального увеличения выборки. Так при уровне доверия 95% и 99% и выборке в 500 человек статистическая погрешность +- 4,38% и 5,77%, для выборки в 1000 человек 3,1% и 4,08%.
Уровень доверия - описывает процент с которым значение попадёт в интервал погрешности, по сути это точность наших предсказаний. Так при уровне доверия 95% и погрешности 10% каждый 20 результат такого измерения будет лежать за интервалом погрешности в 10%.
Погрешность - собственно погрешность нашего предсказания. Описывает интервал возле истинного значения в который попадёт наш результат. Например если истинное значение 100 для уровня доверия 95% и погрешности 10% 19 из 20 результатов измерений будут находится в интервале ≈ от 90 до 110 и только 1 из 20 будет находится за этой границей.
Истинное значение - значение которое должны были бы получить в идеальных условиях без какой либо погрешности. Обычно используется значение соответствующей метрики из контрольной версии.
Проблемы большой выборки
Несмотря на то что большая выборка позволяет снизить погрешность, она так же имеет минусы. И самое банальное - это слишком долго и дорого. В реалиях инди довольно мало ситуаций когда нужна минимальная погрешность, обычно речь идёт о динамике конкретной метрики в районе 10-15% в одной группе изменений. Вместе с тем приходится планировать окончание теста так чтобы дата окончания не легла на выходные или пятницу, иначе новый тест запустить попросту не успеют, а любой простой это потеря пользователей которых можно было использовать для сбора данных.
Большая выборка не позволяет тестировать маленькие по объёму изменения. Когда встаёт выбор какие изменения отправить на тестирование: механику разработка которой заняла месяц или перекрашенную кнопочку в главном меню; обычно выбирают более объёмные изменения. Большая выборка не позволяет часто запускать тесты, их количество и направление сильно ограниченно. В общем большая выборка это не про гибкость.
Многомерное сравнение
На смену большой выборки можно взять подход с использованием маленькой выборки и множеством уникальных групп изменением. Обширные изменения будут находится не в 1 группе, а в нескольких чтобы повысить точность для таких изменений. Например тест может состоять из таких групп: 'a b c', 'a h k', 'a c d', 'b h d'; где a b c d h k - обозначение изменений. Это менее точный подход и уже становится невозможно сказать какое конкретно изменение повлияло на метрики, однако нам это и не нужно, достаточно лишь положительной динамики метрик. Так как большие изменения попадают в несколько групп мы сможем увидеть корреляцию, например: 'a h k' показывает положительную динамику по метрикам вдвое больше чем 'a c d' и втрое больше чем 'b h d'; из этого можно предположить что изменение 'a' положительно влияет на метрики, в то время как изменения 'b' 'd', а так же возможно 'k' влияют отрицательно. Конечно не стоит забывать о взаимодействии изменений внутри группы, когда их влияние на метрики может многократно усиливаться, приводить влияние от обоих метрик к нулю или даже заставлять оба изменения которые по отдельности оказывают положительное влияние, в группе показать отрицательную динамику; но это сложная тема в которую я не готов запускать свою палку.
Низкая точность окупается огромной эффективностью. Для одной группы нужна выборка всего в 50-200 человек. При уровне доверия в 85% выборка в 50 человек обеспечивает погрешность ≈ 10% чего достаточно для смелых изменений которые могу оказать сильное влияние на метрики, а таких в инди проекте не мало. Для менее влиятельных изменений требуется выборка от 200 человек обеспечивающая погрешность ≈ 5%.
Иногда при использовании многомерного сравнения можно пренебречь контрольной группой. Если в тесте много групп, в том числе групп с изменениями которые оказывают мизерное влияние на метрики, а выбирается для сохранений изменений или дополнительных тестов всегда группа с наивысшей положительной динамикой по метрикам тогда шанс что такая группа окажется хуже чем контрольная группа довольно мал. Однако любое изменение сложной структуры с бОльшей вероятностью приводит либо к отсутствию результата либо к ухудшению. Поэтому чем больше проект - тем выше шанс что все группы из теста окажутся хуже контрольной версии.
Уровень доверия к выборке
Уровень доверия напрямую коррелирует с количеством необходимой выборки. Поэтому чем меньше уровень доверия - тем меньше потребуется выборка при одинаковой погрешности. При расчёте выборки следует учитывать это и закладывать в среднем больше чем требуется на 1 тест. (ссылки на ресурсы, в том числе калькулятор для подсчёта, в конце статьи)
Корреляция выборки от погрешности
Погрешность добавляется к истинному значению с обоих сторон, поэтому при погрешности 3% диапазон в который результат попадёт - 6%, при истинном значении 100 это интервал ≈ 97-103. Погрешность которую релевантно использовать в большинстве случаев: 5%-25%.
Заключение
Я не затрагивал лишние сложности по типу MDE и прочие аналитические штучки. Если коротко MDE - усовершенствованный способ расчёта на смену расчёта статистической погрешности, но тем не менее если взять экскаватор за гусеницу и попытаться использовать его как лопату это не значит что он будет эффективнее, скорее наоборот. Эта статья должна стать отправной точкой для инди кроликов, а не пугающим набором непонятных аббревиатур или курсом 'с нуля до принятия оффера на позицию аналитика в гугл'.
Ссылки:
