Почему важно тестировать страницу приложения в App Store и как это делать правильно

У нас в компании Payment Systems два проекта: приложение «Штрафы ГИБДД» и bip.ru — cайт и приложение для оформления ОСАГО. «Штрафы» работают уже семь лет, а bip.ru запустили совсем недавно.

Полгода назад мы искали ASO-специалиста, который оптимизировал бы страницы приложений для роста органического трафика. На собеседованиях среди прочих вопросов мы спрашивали кандидатов: «Как правильно тестировать страницу приложения в App Store и почему маркетологи часто в этом ошибаются?» Не ответил никто.

Проблема не только в специалистах: идеального инструмента для такого тестирования просто нет. А нужен он всем разработчикам — то, как приложение выглядит в App Store и Google Play, напрямую влияет на количество установок. Тексты и графика (иконка, скриншоты) на странице приложения «продают» его пользователю. Они объясняют работу приложения, показывают его преимущества и случаи, в которых приложение может пригодиться. Соответственно, чем страница лучше, тем больше людей его установит. Оптимизация страницы приложения может значительно увеличить конверсию.

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

Для начала разберем сами тесты. A/B-тесты помогают сравнить текущую версию страницы приложения с новым вариантом. Сделанный по правилам тест позволяет объективно оценить разницу между ними по ключевой метрике. Обычно это конверсия из показа страницы в установку приложения или из показа приложения в поисковой выдаче в установку. Мы также советуем оценивать Retention rate и платежные метрики пользователей.

Чтобы провести качественное тестирование, необходимо соблюсти два правила:

1. Меняем только один фактор.

Например, мы решили изменить CTA на первом скриншоте. Раньше у нас было: «Купи ОСАГО онлайн», а теперь мы пишем: «Сравни цены от 15 страховых». Это значит, что все остальные элементы (включая рейтинг, позиции приложения и соотношение типов трафика) должны оставаться неизменными.

2. Выборку для теста нужно рассчитывать: она должна быть достаточно большой.

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

Если маркетолог и помнит о важности выборки, расширять ее долго и дорого. Все потому, что размер выборки зависит от средней конверсии ключевой метрики. Например, для теста с конверсией 5% выборка должна составлять 7663 пользователя на каждый вариант A/B теста, то есть всего нам нужно привести 15326 пользователей. Это много: далеко не каждое приложение получает такой объем показов даже за неделю. Рекламный трафик за такое количество показов страницы приложения стоит от 20 000 рублей.

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

1. Перенос варианта–победителя из Google Play

Небольшие компании-разработчики часто делают так: графику тестируют в Google Play, а победившие скриншоты просто переносят в App Store.

Мы пробовали тестировать в App Store вариант с хорошей конверсией в Google Play. Чтобы стать рабочим, он должен показать прирост конверсии и в App Store. На практике так почти не бывает: сработавший в Google Play вариант либо проваливается в App Store, либо не показывает значимых отличий по сравнению с текущим вариантом. Результаты таких тестов совсем не подходят для App Store по двум причинам:

В Google Play другой дизайн. Когда мы ищем приложение в Google Play, мы видим только иконку, название, рейтинг, количество установок. А поиск в App Store выдает три скриншота, которые лучше продают приложение. У страниц приложений тоже много мелких отличий. Например, скриншоты в Google Play сразу видны целиком, а в App Store только частично.

В Google Play другие люди. У одного и того же приложения в App Store и Google Play может отличаться пропорция органических и платных пользователей. К тому же средняя цена на телефоны Android ниже, чем на телефоны Apple. Это может говорить о различии в поведенческих привычках.

2. Тестирование «До/После»

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

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

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

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

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

3. Встроенный механизм тестирования креативов Apple Search Ads

Механизм работает так: в рекламном объявлении автоматически показываются первые три скриншота из тех, которые уже есть в приложении. Всего их может быть до 10. При этом маркетолог может выбрать в настройках три любые скриншота и тестировать несколько вариантов сетов. С точки зрения дизайна теста это практически идеальный вариант.

Но этот способ не стал для нас альтернативой тестирования «До/После», поскольку мы сразу понимали его ограничения и нам хотелось максимума гибкости в тестировании. Вот его основные недостатки:

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

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

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

4. Специальные системы для тестирования

Можно провести тестирование в специальных системах, например, SplitMetrics или StoreMaven. Они эмулируют страницу App Store на отдельном веб-сайте, а разработчики могут привлекать на него рекламный трафик.

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

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

Но и тут есть недостатки:

Это дорого. Подобные сервисы обойдутся минимум в $6000, а для больших проектов и в $30000. Вдобавок придется потратиться на трафик для теста. У некоторых систем есть пробная версия. Она дешевле, но пару тысяч долларов заплатить все равно придется.

Тест на рекламном, а не органическом трафике. Так как пользователи попадают на страницу для тестирования только через рекламу, результаты могут оказаться нерелевантными для органического трафика. Сами системы обычно предлагают использовать дисплейный трафик из Facebook и Google. Однако, если основной трафик приложения — органический поисковый, лучше привлекать пользователей через поисковую рекламу.

Мы проанализировали возможности Splitmetrics и StoreMaven: они позволяли протестировать 90% гипотез из нашего бэклога. Однако, мы хотели тестировать идеи без ограничений вообще. Например, попробовать добавить на эмулированную страницу рекламное размещение как в настоящем App Store.

Мы потратили 3 недели и 100 тыс. руб и создали свою систему для тестирования. Наши дизайнеры и разработчики собрали страницу, которая копирует поисковую выдачу App Store, и интегрировали аналитику Amplitude. Потом мы провели несколько тестов, которые подтвердили работоспособность системы.

По сути мы убрали из аналогичных сервисов все, что не влияет на тест, и даже аналитику собираем по минимуму. Мы эмулируем только поисковую выдачу без страницы приложения. Этого вполне достаточно для нужных нам тестов, включая тесты видео. Дальше инструмент можно кастомизировать под новые задачи.

По нашей оценке, пока это лучший вариант для тестирования графики:

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