Итерационный подход помогает сохранять актуальность продукта на странице приложения в сторе и вести непрерывный поиск конверсионных элементов. А когда бренд достигает определенного масштаба, итерационное ASO встает в один ряд с телерекламой и другими охватными медиаразмещениями. В статье покажем, как можно наладить систематическую работу над ASO, как правильно организовать процесс обновления, каким приложениям подойдет итерационный подход и каких результатов можно ожидать.
Постоянно — это не значит 24/7. Каждый специалист самостоятельно выстраивает частоту обновлений метаданных страницы приложения. Важно регулярно возвращаться к работе над ASO и не выпускать ее из фокуса внимания.
Здесь подходит аналогия с посещением стоматолога: за здоровьем полости рта желательно следить постоянно, но это не значит, что нужно переехать к доктору. Кому-то достаточно планового осмотра раз в полгода, кому-то чаще.
Работа над ASO строится по похожему принципу. Иногда можно только следить за количеством показов/просмотров, конверсией или за позициями по поисковым запросам и не заниматься оптимизацией, если показатели устраивают.
Еще бывает, что у приложения хорошие метрики, и кажется, что можно взять паузу. Но если вы видите, что ваши конкуренты продолжают работать над ASO и даже наращивают инвестиции в это направление, то, вероятно, имеет смысл скопировать эту стратегию. В этом случае оптимизация в магазине приложений работает на охват и узнаваемость продуктов.
Или совсем грустная ситуация: позиции приложения постепенно падают и установок становится все меньше, — похоже, пора поработать над ASO.
Под итерационным подходом к ASO мы понимаем систематическую работу над страницей приложения в сторе. За одну итерацию рекомендуется проверять одну гипотезу. Периодичность этих итераций зависит от множества факторов: категория/вертикаль приложения, активность конкурентов, частота обновляемого контента или функций в приложении и так далее. По нашему опыту, обновлять ASO нужно не реже раза в квартал. В среднем с постоянными клиентами мы проводим около 12 итераций в год с частотой раз в месяц. Ниже приведем несколько аргументов в пользу такого подхода.
В итерационной работе над ASO встает справедливый вопрос: что конкретно нужно регулярно обновлять? И как выбрать элементы для теста? Необходимо составить план с обоснованными гипотезами, согласовать его с отделом разработки (это необходимо в случае, если приложение представлено в App Store, так как практически любое изменение на странице можно внести только с обновлением билда) и далее заниматься отрисовкой, внедрением и отслеживанием результатов.
1. Оформление
Это смена цвета фона, шрифта, добавление персонажей или других графических элементов на скриншотах. Такие изменения достаточно заметны для пользователя, поэтому для проведения A/B-теста вам понадобится небольшое количество трафика — разница будет сразу очевидна. К тому же эти изменения не требуют долгой проработки. Времени понадобится немного, а эффект вы получите существенный.
2. Сезонность
В этом случае нужно поработать не только над дизайном скриншотов, но и над текстом и даже над содержанием приложения. Кому-то в этой итерации достаточно будет добавить пару снежинок, а кому-то придется заменить товары на актуальные и, как следствие, поменять весь набор скриншотов. Такие глобальные изменения, как правило, требуются для приложений в вертикали e-commerce. Если продукция не зависит от сезона (например, банковские услуги), то достаточно добавить несколько сезонных элементов.
3. Функциональность
В этом случае основная работа ведется над функционалом приложения без смены общего оформления страницы. Этот уровень гипотез подходит для продуктов, которые предоставляют широкий набор инструментов. Если ваше приложение предназначено только для просмотра погоды, то нет необходимости что-то тестировать в этой области. Но если в продукте широкий функционал: трекинг выпитой воды, подсчет количества потребленных калорий, учет физических нагрузок, — стоит взяться за тестирование в этой области.
Чтобы собрать гипотезы в масштабном проекте, рекомендуем изучить статистику по использованию фичей и определить, какие из них наиболее популярны. Хаотичное добавление новых функций на скриншоты не принесет результата. Напротив, это может размыть ценность приложения в глазах пользователей. Если у приложения достаточное количество трафика, надежнее всего будет провести A/B-тесты, чтобы понять, какие функции больше всего нравятся вашей аудитории.
4. Психология
Это самый сложный уровень гипотез, так как нужно правильно провести ресерч, изучить данные и корректно реализовать фичу под запрос аудитории.
К тому же при тестировании будет много исследовательской работы, — нужно тонко подобрать гипотезы, внимательно изучить результаты и правильно их интерпретировать.
Приведем пример. Как вы разместите текст и графику при создании скриншотов в горизонтальной ориентации? Что будет справа, а что слева? Скорее всего, вы ответили, что картинка слева, а текст справа. И это правильный ответ. Но почему именно так? Оказывается, текст и графика в такой последовательности гораздо лучше воспринимаются человеком, потому что так работают полушария мозга.
Какие еще гипотезы можно протестировать на уровне психологии?
Это взгляд персонажа/человека на скрине на кнопку «Загрузить», изменение направления стрелок на важные элементы. Не всегда такие приемы будут работать. Но если вы находитесь в «творческом тупике», перебрав все другие уровни гипотез, то психология поможет найти решение.
Мы рекомендуем идти от первой (оформление страницы приложения) к четвертой (психология). Все гипотезы расположены в порядке увеличения уровня сложности реализации и уменьшения возможного влияния.
На каждом уровне гипотез можно провести несколько тестов — например, сначала протестировать цвета фона скриншотов, потом расположение текста и изменение шрифта. После того как заканчиваются идеи на одном уровне, переходим к следующему.
Первое и основное: итерационный подход к оптимизации помогает найти наиболее конверсионные элементы страницы приложения.
Второе: частотность обновлений влияет на видимость приложения в сторах.
Алгоритмы App Store и Google Play лучше ранжируют приложения с большим количеством обновлений. Также это один из ключевых факторов для получения фичеринга. Более того, фичеринг может получить не только само приложение и его страница, но и in-app-ивент. Учитывая, что ивенты есть далеко не у всех, шанс получить фичеринг заметно вырастает.
Третье: возможность попасть в подборки.
Сторы часто делают тематические подборки, например на Хэллоуин, и добавляют в нее все приложения, которые «украсили» свою страницу к мероприятию.
По нашему опыту, изменения страницы приложения крупных брендов не так сильно влияют на решение об установке. Дело в том, что такие приложения чаще всего ищут целенаправленно: пользователь уже знаком с функционалом и у него сформированы ожидания и предпочтения.
Например, у человека есть любимый продуктовый магазин, а значит, и доставку он скорее всего заказывает через приложение этого магазина. Или пользователь уже привык к определенному интерфейсу приложения и предлагаемым условиям, и ему нет смысла искать какое-то другое приложение.
Значит ли это, что крупным брендам не нужно работать над ASO? Нет, не значит, но цели ASO крупных брендов немного отличаются от остальных.
Для больших брендов карточка приложения — это одна из важных точек коммуникации с аудиторией. Огромное количество людей ежедневно скачивают приложение, и даже небольшое изменение на странице может существенно подстегнуть продажи. Даже если конверсия изменится незначительно (при большом объеме общего трафика изменения в одном из каналов привлечения могут быть заметны не сразу или вовсе незаметны), оптимизация страницы будет иметь отложенный эффект и повлияет на потенциальных покупателей на более поздних этапах воронки.
Цели регулярной оптимизации в таком случае не сводятся к подсчету конверсии. Чаще гораздо важнее показывать движение и развитие своего бренда, показывать его актуальность, его целостность стиля, заботу о пользователях.
Какие цифры все же следует учитывать? Можно проанализировать данные, разделив показы и установки по источникам трафика. Пользователи могут приходить от разных источников, таких как поисковые запросы, подборки, реклама или другие приложения. Важно оценить конверсию для каждого источника, особенно для тех, кто случайно обнаружил приложение. Это позволяет понять, как изменения в ASO влияют на разные источники трафика.
Переходим к практической части. Далее расскажем, из каких этапов состоит работа над итерационным ASO. Для наглядности будем оптимизировать страницу вымышленного приложения в вертикали «Доставка продуктов».
Первое, что нужно сделать, — составить среднесрочный план изменений, например на год. Предположим, наш воображаемый продукт — крупный игрок на рынке, и у отдела маркетинга уже есть план активностей. Учитывая особенности работы с большими брендами, для нас приоритетными становятся гипотезы второго уровня: сезонность и праздники.
Предположим, что приложение работает на территории России, поэтому мы проходимся по календарю праздников и учитываем времена года. Важно принимать во внимание то ГЕО, на которое работает приложение: от этого зависит набор праздников и наличие или отсутствие сезонности.
В нашем случае обновление ASO будет актуально к 4 сезонам.
Анализируем значимые календарные праздники. Для России это:
После этого обсуждаем с отделом маркетинга, какие активности планируются к этим мероприятиям и находим пересечения. Если пересечений нет, то обсуждаем возможность обновления графики к этому мероприятию.
У нашего воображаемого приложения появился план обновления графики к 4 сезонам и 8 праздникам.
Теперь расписываем наш план по месяцам и смотрим, нет ли перегруза или, наоборот, пробела в каком-то месяце. Если есть месяц/период, когда обновления не требуются, то можно провести A/B-тест графических элементов, которые не связаны с праздниками и сезонами.
Чаще всего работа начинается с отрисовки нового комплекта скриншотов. На это есть несколько причин:
Обязательно учитываем пожелания маркетологов, брендбук и базовые принципы хорошего ASO касательно цвета, текста и расположения графических элементов. После этого проводим A/B-тестирование, чтобы убедиться в эффективности новой графики.
Приступаем к разработке скриншотов к 14 февраля. Сначала нужно обсудить с отделом маркетинга планы к текущему мероприятию: появление новых продуктов/товаров, подборок, функционала или новых условий доставки.
Предположим, мы узнали, что вскоре появится новый раздел с подарками: конфеты, цветы, открытки, игрушки, а также возможность анонимно заказать доставку с валентинкой. Со своей стороны ищем символику праздника и параллельно внимательно изучаем брендбук компании, чтобы действовать строго в рамках дизайн-кода продукта.
Заказ доставки с валентинкой — это новый функционал для приложения, а значит, сосредоточимся на скриншотах: вынесем важную информацию на первые слайды. Также подготовим in-app event, в котором расскажем о новой возможности с открытками. С учетом ограничений брендбука вот какие скриншоты и ивенты у нас получились.
Следующий набор скриншотов — к 23 Февраля. По той же методике узнаем, что нового будет в приложении и готовим креативы. К празднику готовится подборка с подарками и с товарами для стола. При подготовке креативов стоит обратить внимание на целевую аудиторию приложения: несмотря на то, что 23 Февраля принято считать мужским праздником, подготовкой подарков занимаются в основном женщины. Поэтому не стоит делать креативы слишком брутальными, иначе можно не попасть в аудиторию.
После этой итерации также стоит оценить конверсию из показа в установку и внутренние метрики приложения: количество заказов, переходов в новую подборку, количество купленных подарков. Из-за того, что праздники идут буквально друг за другом, вряд ли получится запустить A/B-тест и понять, какой комплект отрабатывает лучше (для корректного тестирования нужно было бы вернуть нейтральный комплект графики).
Следующий праздник — 8 Марта. План на подготовку креативов сохраняется с предыдущих итераций. Вспоминаем, кто наша целевая аудитория: по аналогии с 23 Февраля, это не только женщины, но и мужчины. К тому же наш заказчик добавил возможность доставки не только продуктов, но и цветов, об этом точно стоит рассказать на одном из трех первых скриншотов.
Опираясь на нашу ЦА, продумываем варианты взаимодействия с приложением. Скорее всего, многие будут заказывать продукты для оформления праздничного стола, некоторые люди в самый последний момент вспоминают, что неплохо было бы купить подарки коллегам или учителям. Помимо этого, важно помнить, что в этот день женщины поздравляют друг друга, что тоже стоит учесть при подготовке графики.
На скриншотах мы решили рассказать о новой функции — доставке цветов, подборке с готовыми подарками и о доставке продуктов за 20 минут.
Общий принцип того, как подходить к созданию креативов, мы изложили выше, в последующих итерациях этот план действий сохранится, но нужно будет учесть особенности сезона или праздника.
Выше подробно разобрали то, как выполнять итерации к сезону, но тут хотелось бы рассказать, какие итерации можно провести в классическом понимании ASO. Например, отрисовать второй комплект скриншотов, дизайн которых остается практически без изменений, а меняется только ориентация скриншотов. Или же подготовить новое оформление скриншотов для проверки гипотезы, какая иллюстрация наиболее привлекательна для пользователей.
После отрисовки графики необходимо оба варианта загрузить в кабинет разработчика и запустить тест. Затем оцениваем результат и намечаем вектор дальнейшего движения.
Действительно, есть некоторые ниши, для которых такой подход работы с графикой неактуален.
1. Приложения, которым достаточно базово подготовить ASO и больше не возвращаться к нему
Например, у вас приложение для сигнализации автомобиля. Такое приложение поставят только владельцы авто, использующие именно эту сигнализацию. Откуда приходят пользователи в приложение? Вряд ли из поиска. Чаще всего про приложение им рассказывают именно в клиентском сервисе. Для такой категории приложений достаточно базово оформить страницу и не переделывать, пока не появится новый функционал или же компания не проведет ребрендинг.
2. Приложения с небольшим функционалом и неживописным интерфейсом
Например, приложение-таймер или приложение-игра судоку. Да, от качества графических креативов будет зависеть конверсия из показа в установку. Можно провести несколько итераций тестирования, но рано или поздно вы упретесь в потолок. Давайте для наглядности пройдемся по гипотезам. Вряд ли будет уместно обновлять ASO под праздники или сезоны. Функционала в приложении тоже немного, поэтому этот уровень гипотез тоже пропускаем. Психологический подход и разнообразие фишек тут неуместны. То есть такому приложению достаточно несколько простых итераций, и после этого уже нет острой необходимости их проводить.
3. Приложения, которые получают органический трафик, но не имеют устойчивого бренда
Например, приложение «Карты» от неизвестного разработчика. Здесь уже можно тестировать как оформление, так и функционал приложения. А что касается сезонов и психологии? Очевидно, люди довольно редко скачивают приложение с картами. Скорее всего, однажды скачав удобное приложение для определенных стран, они пользуются им постоянно. В случаях таких приложений нужно трезво оценивать возможный эффект от итерационного ASO и рассчитывать свои ресурсы.
Итерационное ASO — ресурсоемкий подход к оптимизации приложения, который требует систематической работы над страницей приложения. Такой формат подходит для приложений, которые производят обновления по сезонам и праздникам. Выбранная нами для примера категория доставки еды действительно одна из наиболее подходящих в таком случае. Итерационный подход будет полезен тем командам, которые готовы к постоянному совершенствованию страницы в сторе и закладываются на регулярное тестирование гипотез для получения надежного долгосрочного результата.
Ракзбираем, как работают кастомные страницы и за счёт чего они помогают снизить CPI. Внутри много примеров и реальный кейс VK Музыки. А ещё: список совместимых с CPP рекламных источников и нюансы настройки в разных трекинговых системах.