Введение

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

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

Один из наиболее точных способов оценить ценность какой-либо фичи или элемента дизайна - проведение a/b тестирования.

В предыдущей статье мы рассмотрели особенности формирования групп для a/b тестирования, а также пользу от фокусировки на конкретных запросах. В этой статье мы подробно расскажем, как именно проводится тестирование, до какого момента и как после этого обрабатываются данные.
Проведение

Чтобы получить корректные данные, a/b тест должен проходить изолированно. Например, во время него не должно проходить другого a/b теста. Смешивание a/b тестов в большинстве случаев будет давать размытые результаты для каждого теста по отдельности.

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

С другой стороны a/b тест не должен находиться в противоречии. Член одной группы во время теста никогда не должен сталкиваться с вариантом для другой группы. Знание об альтернативном варианте может очень сильно повлиять на поведение пользователя. Самый грубый вариант - показывать в случайном порядке варианты A и B, не привязываясь к группам. Например, показывать два вида рекламы пользователям в случайном порядке и сравнивая конверсию.

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

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

Каждое тестирование должно иметь конечную цель и заканчиваться по достижению результатов. Тестирование ради тестирования - это всего-лишь трата ресурсов. Бесконечное повторение одного и того же теста с каждым разом будет давать вам менее ценные результаты. Так что важно вовремя остановиться и перейти к другим тестам - или на время отказаться от тестирования вовсе.

Обработка

Один из способов получить достоверные результаты - провести несколько итераций теста. С шагом, например, в день. Полученные данные не будут одинаковыми - день ото дня они будут отличаться. Цель - понять, насколько данные отличаются друг от друга. Если разброс небольшой (на уровне 10%), то можно приводить значения к усредненным. Если же разброс более 10%, тестирование - и его результаты нужно подвергнуть критике. Чем выше разброс, тем ниже уверенность в достоверности результатов.

Число пользователей в каждой группе не всегда одинаковое. Так что при обработке результатов используйте относительные значения. Не 5.64 пользователей, а 12%.

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

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

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

Самый простой - продлить тестирование, чтобы протестировать его на большей аудитории.

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

Вариант 10-10-80. Используется, когда нужно принять быстрое решение малыми ресурсами. Вы разделяете процесс тестирования на два этапа. В первом этапе вы проводите базовое a/b тестирование, но уделяете для каждой группы лишь 10% расчетной аудитории. После того, как определится фаворит, все тестирование переходит на него, чтобы потвердить результаты. Если результаты подтверждаются, тестирование можно считать успешным. Таким образом вы можете пропустить более выгодный вариант из-за статистической погрешности, но при этом вы минимизируете риски выбрать убыточный вариант.

Заключение

В конечном итоге, цель a/b тестирования - привнести понимание явного превосходства одного варианта над другим.

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

Тестирование обеспечивает вас сухими аналитическими данными. Но вот конечное решение принимать уже вам.