В текущих реалиях индюшатины каждый человек на вес золота и выделять для аналитики отдельного человека - расточительство. Вместе с тем сфера аналитики как дремучей лес, мало информации, множество непонятных терминов и сложных вычислений. Однако это совершенно не мешает чтобы грубо, как обезьяна, потыкать палкой в эту странную сферу и получить дополнительный вектор для развития проекта.
Статья рассчитана в первую очеред�� на проекты с уже настроенной аналитикой, когда результаты собраны, но что делать с ними дальше вы не знаете. Вполне ожидаемо следующим шагом развития станут попытки повлиять на метрики каким-либо образом, естественно так или иначе вам придётся столкнуться с А/Б тестированием. Я попытался выделить общие подходы которые могут быть применимы к инди проектам когда разработка происходит в отсутствие квалифицированных специалистов и ограниченном бюджете. Ради этого придётся существенно пожертвовать точностью самих А/Б тестов, однако лучше хоть что-то чем совсем ничего, верно? В любом случае не нужно это рассматривать как основной подход для принятия решений об изменениях в проекте, а скорее как дополнительное направление для разработки когда других идей не осталось.
Перед тем как начать
Немного определимся с терминами. А/Б тест - обычно подразумевают ситуацию когда имеются две версии игры: оригинальная и модифицированная, между этими версиями распределяют игроков, а затем сравнивают результаты аналитики. Но вне контекста формулировка 'А/Б тест' может нести в себе разное значение.
Поэтому чтобы не допустить путаницы я буду использовать термин 'Группа изменений' или просто 'Группа' - это изменение или набор изменений относительно нашей основной версии, иными словами модифицированная версия. А под 'А/Б тестом' я буду иметь ввиду сам подход применяемый к нашим группам.
'Контрольная версия' - она же 'контрольная группа', не модифицированная версия, оригинальная.
'Выборка' - набор пользователей для одной группы изменений.
Задача А/Б тестирования
На самом деле в качестве результатов законченного теста нужны не численные значения полученных метрик, а динамика этих метрик относительно контрольной версии. Хотя и это не совсем верно. В отсутствии опыта работы с аналитикой я как разработчик хочу узнать только направление в котором мне нужно развивать проект чтобы 'сделать игру лучше', А/Б тест для меня лишь инструмент которому не повезло попасться в мои неопытные руки. Ввиду этого поиск направления выглядит примерно так: случайные изменения проекта -> запуск А/Б теста -> если динамика положительная, вносим эти изменения в контрольную версию и оставляем -> если динамика отрицательная или в районе погрешности, начать сначала. Всё что от нас здесь требуется - снизить статистическую погрешность и постараться учитывать влияние внешней среды.
Требования к проекту для тестирования
Конечно в первую очередь это работающая аналитика и инструмент для 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 - усовершенствованный способ расчёта на смену расчёта статистической погрешности, но тем не менее если взять экскаватор за гусеницу и попытаться использовать его как лопату это не значит что он будет эффективнее, скорее наоборот. Эта статья должна стать отправной точкой для инди кроликов, а не пугающим набором непонятных аббревиатур или курсом 'с нуля до принятия оффера на позицию аналитика в гугл'.
Ссылки:
