Развитие продукта — это постоянный поиск ответов на вопросы: что можно улучшить, что поможет повысить прибыль и в какую сторону стоит двигаться. Единственный правильный способ не навредить продукту изменениями — проводить А/Б-тесты и принимать решения на основе полученных данных.

Продуктовая ИТ-компания Wowmaking уже около трёх лет создает мобильные приложения, которые скачивают миллионы пользователей по всему миру. Мы постоянно проводим А/Б-тесты наших продуктов и рекламных кампаний, поэтому готовы поделиться рекомендациями и примерами.

В чём суть А/Б-тестирования

Проведение А/Б-тестов помогает сравнивать разные решения, которые вы планируете реализовать в продукте и выбирать наиболее эффективное. Этот метод защищает вас от принятия решений, которые будут иметь негативные последствия.

Как мы в Wowmaking проводим А/Б-тесты продуктов? Это выглядит следующим образом. Готовим два варианта, например, иконки приложения, которое отличаются цветом: одна в тёмных тонах, другая в светлых. Показываем части аудитории, например 20 тысячам юзеров, вариант А, другой — Б. Замеряем показатели: сколько пользователей кликнули по светлой иконке, сколько — по тёмной. Анализируем результаты и принимаем решение, какой вариант иконки лучше использовать.

Где ищем идеи для тестов

Генерация идей и их тестирование у нас проходят на постоянной основе. Мы создали отдельную команду, цель которой — глубокий анализ продукта, рынка, пользователей и разработка идей для тестирования. Кроме этого продуктовые команды сами генерируют идеи по развитию продукта и проверяют их с помощью А/Б-тестов.

Чтобы сформировать гипотезы для проведения тестов, мы главным образом анализируем маркетинговую воронку AAARRR (Awareness/ Acquisition/ Аctivation/ Retention/ Revenue/ Referral). Это позволяет сфокусироваться на узких местах, а не на тех, которые нам больше нравятся или где у нас есть больше идей. Пару слов о каждом этапе.

• Awareness (информирование). Здесь мы ищем идеи для новых рекламных роликов и баннеров.

• Acquisition (покупка трафика). Выдвигаем гипотезы, какие ещё каналы можно задействовать и как можно улучшить таргетирование.

• Аctivation (активации). Для этого этапа мы подыскиваем идеи, которые помогут как можно большему проценту пользователей понять, как наш продукт решает их проблему.

• Retention (удержание). В этой части воронки мы смотрим на уже активированных пользователей. На их возвраты влияет сам продукт и то, какими способами мы их возвращаем.

• Revenue (доход). Самое время для тестов модели монетизации (подписка/внутренние покупки/реклама или гибридная модель). И более глубокие тесты, когда определена модель (цены, места продажи, дизайн страниц подписки).

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

Примеры наших тестов

Большая часть наших тестов направлена на проверку гипотез по улучшению user flow или путей пользователя. Их цель — довести как можно большую часть пользователей до того момента, где они смогут понять ценность продукта. Если юзер не понимает ценность продукта, то скорее всего уйдет, не окупив расходы на его привлечение.

Среди продуктов Wowmaking есть приложение-пазл SRCH. Команда провела много тестов по поиску идеальной последовательности, согласно которой нужно показывать уровни разной сложности новым пользователям. Стремились найти баланс между увлекательными простыми уровнями и более сложными. Данные показали, что лучше всего дать пользователю возможность самому выбирать, какой рисунок раскрашивать, и при этом оставить только 3 незакрашенных элемента.

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

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

Мы продолжаем тестировать новые форматы подбора первой истории для пользователя.

Много гипотез выдвигается о способах монетизации. В Mustread используется гибридная модель монетизации: мы получаем доход от продажи подписок и показа рекламы. Одно из мест показа рекламы — между эпизодами внутри одной истории. Изучая отзывы пользователей и в рамках интервью, мы периодически получали негативный фидбэк о рекламе конкретно в этом месте. Чтобы проверить, как это влияет на продукт и как к этому относится большая часть пользователей, мы запустили эксперимент.

Показ рекламы в приложении не портит продукт

В эксперименте участвовали только новые пользователи. Для 50% пользователей мы отключили рекламу между эпизодами. В результате увидели, что отключение рекламы не приводит к росту Retention, количества прочитанных эпизодов или историй. При этом мы теряем порядка 30% рекламного дохода за всё время использования продукта юзером. Сейчас мы точно уверены, что показ рекламы между эпизодами не влияет негативно на продукт и спокойно относимся к единичным негативным отзывам по этому поводу.

Также мы тестируем дизайн страниц подписки. Во многих продуктах используются страницы, на которых продаётся сразу несколько продуктов: недельная/годовая/месячная подписки. Какое-то время назад с помощью A/B теста мы выяснили, что продажа нескольких продуктов на странице подписки позитивно влияет на LTV.

Но одна из особенностей таких страниц в том, что на них остаётся мало места для раскрытия преимуществ, которые дает пользователю подписка. Одно из решений — до показа страницы подписки показать дополнительный экран, на котором будут подробно раскрыты все преимущества. Мы проверили эту гипотезу и увидели на iOS рост конверсии в подписку порядка 25%. Также мы наблюдали рост конверсии в списания по подпискам и как следствие рост LTV.

Как проводить А/Б-тестирование

Проведение эксперимента требует тщательной подготовки. Первым делом необходимо составить детальный план, в котором будет определён размер выборки, flow тестовой и контрольной групп, целевая аудитория эксперимента, метрики и события аналитики, которые мы будем использовать.

Следующим этапом станет подготовка дизайна, текстов и всех элементов тестирования, которые нам понадобятся. Запускаем эксперимент и с нетерпением ждём результатов.

Перед тем, как остановить А/Б-тест, необходимо проверить результаты на статистическую значимость. Если тест окажется успешным, то решение можно внедрять в продукт. Но нужно понимать, что положительный результат показывает 1 из 10 гипотез, поэтому чем больше тестов вы проведёте, тем большего роста сможете достичь.

Где лучше всего проводить тесты мобильных приложений

Мы попробовали разные сервисы и остановились на Firebase. Это сервис аналитики для мобильных приложений от Google. У Firebase не ограничен объём событий для отчетности.

Независимо от числа событий, конверсий, транзакций или пользователей вы сможете увидеть полные данные. В приложении можно отслеживать конверсии, доходность, метрики поведения пользователей. Кроме стандартных параметров здесь можно кастомизировать более 25 дополнительных. Наиболее часто мы используем те, что касаются источника установки (рекламная сеть, тип рекламной кампании, id рекламной кампании). Также мы анализируем дату установки, совершил ли пользователь хотя бы один платёж, является ли он новым или старым (впервые установил приложение или обновил).

Какие ошибки могут быть

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

1. Участники А/Б-теста выбраны неверно

Допустим, вы тестируете tutorial на новых пользователях. Оба варианта показываете 50 тысячам юзеров и видите, что в А и Б вариантах его прошли 40 тысяч пользователей. Конверсия в таком случае составляет 80%. И разницы вроде бы нет.

Но если посмотреть глубже, окажется, что в варианте А tutorial был показан 46 тысячам юзеров, а в варианте Б — 43 тысячам. В таком случае конверсия выглядит по-другому: А — 86,7%, Б — 93,0%.

2. Результаты не проверялись на статистическую значимость

Разница между показателями А и Б групп юзеров может оказаться настолько малой, что на её основе нельзя сделать адекватные выводы. Чтобы не ошибиться, результаты теста нужно проверять на статистическую значимость. В некоторых сервисах для проведения А/Б-тестов для этого есть встроенные калькуляторы. Также иногда мы просим наших аналитиков проверить некоторые результаты тестов на статистическую значимость.

К примеру, мы тестируем 2 разных онбординга, где ключевая метрика для нас — процент пользователей, которые его прошли. Допустим, в эксперимент попала 1000 пользователей: в каждую группу по 500 пользователей. В группе A процент прошедших онбординг составил 90%, в группе B — 86%. Может показаться, что вариант А лучше, но пока результат не является статистически значимым, выводы делать рано, нужно продолжать эксперимент.

3. Не предусмотрели, как будут использоваться результаты

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

4. Анализируются ошибочные метрики

Вы решили проверить гипотезу: с увеличением количества показов рекламы в приложении увеличится прибыль. Контрольной метрикой выбрали Revenue. Стали показывать больше рекламы и увидели рост той самой заветной метрики. Однако вы не учли, что в долгосрочной перспективе такая политика может привести к снижению дохода за счёт отвала юзеров. Чтобы этого избежать, нужно следить за относительными метриками Retention, ARPU, LTV.

Источник фото на тизере:FOODISM360 on Unsplash