Мобильное A / B-тестирование: 7 серьезных ошибок и заблуждений, которых следует избегать

Ни для кого не секрет, что маркетинг в целом во многом опирается на данные. То же самое относится к мобильному маркетингу и привлечению пользователей. В этой области выбор правильных элементов страницы продукта для App Store и Google Play может иметь решающее значение для успеха приложения или мобильной игры. Мобильное A / B-тестирование - это инструмент, который помогает сделать выбор на основе данных.

Однако сколько раз мы слышали аргумент, что A / B-тестирование не приносит желаемых результатов или что кто-то не уверен, что проводит мобильные эксперименты правильно? Это часто происходит из-за некоторых распространенных ошибок и неправильного толкования данных. В этом посте я расскажу о самых больших ошибках и неверных выводах при A / B-тестировании мобильных приложений, знание которых поможет вам добиться успеха.

1. Завершение эксперимента до того, как вы получите нужный объем трафика.

Это одна из самых распространенных ошибок в мобильном A / B-тестировании. Если вы приверженец классического A / B-тестирования, завершение эксперимента до того, как вы получите необходимый объем трафика - размер выборки - представляет собой риск получения статистически недостоверных результатов .

Чтобы получить надежные доказательства, вам нужно подождать, пока не будет достигнут необходимый объем трафика для вариантов A и B.

Если вы ищете альтернативу классическому варианту, прибегните к последовательному A / B-тестированию. Вам нужно будет начать с указанием скорости базового преобразования (коэффициент конверсии вашего изменения тока), статистическую мощность (80% по умолчанию), уровень значимости и минимальный регистрируемый эффект (MDE) - это поможет вам определить размер выборки.

По умолчанию уровень значимости составляет 5%, что означает, что погрешность не превышает 5%. Вы можете настроить это значение вместе с MDE - минимальным ожидаемым увеличением коэффициента конверсии, которое вы хотели бы видеть . Примечание: не меняйте уровень значимости, MDE или статистическую мощность после того, как вы начали эксперимент.

При последовательном A / B-тестировании алгоритм будет постоянно проверять ваши варианты уровня значимости и объема трафика, оставшегося до завершения эксперимента. Вот как это работает на нашей платформе A / B-тестирования SplitMetrics.

Извлеченный урок: если вы запускаете классические A / B-тесты, не завершайте эксперимент, пока не будет достигнут нужный объем трафика. Или попробуйте последовательное A / B-тестирование, и вы сможете проверить результаты в любое время.

2. Завершение эксперимента до истечения 7 дней.

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

Чтобы получить надежные результаты в экспериментах по A / B-тестированию мобильных устройств, вы должны фиксировать пиковые дни вашего приложения во время эксперимента. В противном случае вы рискуете сделать поспешные выводы.

Например, вы запускаете тесты для приложения для управления задачами. Вы начинаете эксперимент в среду и заканчиваете его в субботу. Но большая часть вашей целевой аудитории использует ваше приложение по понедельникам, поэтому вы просто упустите суть, поскольку всплеск активности еще не пришелся на период эксперимента. Или наоборот, вы проводите A / B-тесты для своей гоночной игры с пятницы по воскресенье: в пиковые дни игры. В этом случае результаты также будут неадекватными.

Итак, даже если вы избежали ошибки номер один и уже получили необходимый объем трафика в первый же день, не останавливайте эксперимент, пока не пройдет семь дней.

Извлеченный урок: из-за слабых пиков активности, которые различаются для каждой мобильной игры или приложения, не завершайте эксперимент до завершения полного (семидневного) цикла.

3. Тестирование слишком мелких изменений в дизайне.

Еще одна распространенная ошибка в мобильном A / B-тестировании - это сравнение вариантов, которые выглядят почти одинаково из-за незначительных различий в дизайне.

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

В этом случае оба варианта покажут одинаковый результат, и это совершенно нормально. Итак, если вы когда-либо пытались запустить A / B-тесты в магазине приложений, но потом отказались от них, поскольку варианты выполнялись одинаково, пришло время подумать о том, что пошло не так. Возможно, ваши варианты выглядели примерно так же.

Чтобы убедиться, что вы проводите A / B-тестирование значительного изменения, покажите обе версии своей семье или друзьям. Пусть ваш коллега рассмотрит каждый вариант 3-5 секунд. Если они не знают разницы, вам лучше переделать свои визуальные ресурсы.

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

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

Если вы используете сторонний инструмент мобильного A / B-тестирования, например, SplitMetrics, вы покупаете трафик и размещаете баннеры в рекламных сетях. Дело в том, что такой баннер не должен выглядеть как один из визуальных ресурсов, которые вы тестируете , будь то снимок экрана или те же элементы на значке.

Например, вы проводите эксперименты для своего образовательного приложения. Вы создаете баннер, который имеет тот же элемент, что и значок из варианта A, а вариант B - это совершенно другой значок. Вариант A покажет более высокий коэффициент конверсии, поскольку он имеет тот же дизайн, что и пользователи баннера, которые изначально видели и на которые нажимали.

Исследования показывают, что если люди что-то видят неоднократно, их мозг быстрее обрабатывает информацию, что вызывает у них чувство симпатии. Вы можете прочитать больше об этом здесь. Таким образом, пользователи склонны неосознанно нажимать на уже знакомые изображения.

Извлеченный урок: работая над баннерной рекламой, делайте дизайн максимально нейтральным. Дизайн баннера не должен совпадать с дизайном иконки вашего приложения или вариантами скриншотов.

5. Проверка сразу нескольких гипотез.

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

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

Извлеченный урок: если вы протестируете сразу несколько гипотез, вы не сможете понять, какая из них верна.

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

При запуске A / A-тестов вы можете быть сбиты с толку, когда инструмент A / B-тестирования показывает выигрышный вариант среди двух идентичных активов. В частности, это характерно для встроенного в Google Play Store инструмента для проведения экспериментов.

На платформе SplitMetrics на уровне значимости 5% в таком случае вы увидите, что результат незначительный.

Небольшие различия между двумя совершенно одинаковыми вариациями - чистое совпадение. Разные пользователи отреагировали немного по-разному. Это похоже на подбрасывание монеты: вероятность выпадения орла или решки составляет 50-50, а вероятность того, что один из вариантов покажет лучший результат, составляет 50-50.

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

Извлеченные уроки: если вы получаете выигрышный вариант при тестировании идентичных активов, с вашим инструментом A / B-тестирования все в порядке, это просто совпадение. Однако при последовательном A / B-тестировании вы увидите, что результат незначительный.

7. Расстраиваться, когда новая вариация проигрывает текущей.

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

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

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