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

Что такое SEO (Search Engine Optimization) знают все — это оптимизация веб-страницы, в результате которой сайт получит максимально возможный рейтинг в поисковых системах и привлечет органический трафик. Простым языком — это способ увеличить количество посещений сайта и нужных посетителей.

ASO (App Store Optimization) — оптимизация для маркетплейса приложений. Иногда его еще называют SEO для приложений. Только ASO направлен не на привлечение органического трафика, а на то, чтобы приложение получило высокий рейтинг в маркетплейсе и пользователи скачивали приложение (то есть организовать органическую загрузку приложения без помощи ботов или специальных сервисов продвижения приложений). ASO направлено как на повышение позиций в поисковой выдаче, так и на трафик, связанный с просмотрами (например, ранжирование по категориям и размещение в разделе «Похожие приложения» на странице похожего приложения).

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

С ASO вы завязаны на ограничениях, которые устанавливают маркетплейсы приложений. Даже у Apple App Store и Google Play есть значительные различия в требованиях. Например, заголовок каждого приложения имеет ограничение по количеству символов, снимки экрана должны соответствовать определенным размерам и т. д.

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

Факторы, которые влияют на ASO и SEO, тоже различаются. Да, их огромный список, но если вкратце, на ASO влияют название приложения и краткое описание, локализация, скриншоты и другие визуальные элементы и прочее. На SEO влияют UX, метаданные, вовлеченность пользователей и так далее.

Нужно очень аккуратно подходить к использованию ключевых слов как для приложения, так и для веба. Никто не будет читать напичканный ключевыми словами текст — он мало информативен и бесполезен для читателя. И хорошо, что в этом нет необходимости как для App Store (он еще и накажет вас за это), так и для веб-страниц (Google довольно умен, он поймет, о чем текст и без них).

Одно из самых больших отличий заключается в том, что в маркетплейсе допускается ограниченное количество символов для метаданных. Например, в App Store разрешен подзаголовок до 30 символов, а в Google Play — заголовок приложения до 50 символов. Как видите, разгуляться тут с ключевыми словами негде, особенно по сравнению с вебом, где границы бесконечны.

Вы можете использовать каждое ключевое слово только один раз, чтобы не выйти за пределы максимального количества символов, поэтому подходите к этому более стратегически. В Apple App Store использование ключевого слова более одного раза никак не повлияет на ваш рейтинг. Но в Google Play Store или в SEO это важно — использование ключевых слов более одного раза может повысить рейтинг.

Примеры популярных платформ и инструментов: AppTweak, Ahrefs, MobileAction, SEMRush, KeyCollector.

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

Хотя инструменты, используемые для подбора ключевых слов в ASO и SEO, могут различаться (например, AppTweak для ASO и Ahrefs для SEO), используемые метрики и последующие процессы оценки одинаковы. Это связано с тем, что как ASO, так и SEO стремятся к одному и тому же конечному результату — найти правильные ключевые слова и поднять свои позиции в рейтинге.

Сайты и приложения — это две разные сущности, так что и пользовательские привычки не могут быть одинаковыми. Приложения в основном предназначены только для мобильных устройств и планшетов, а сайты доступны и на десктопе. Мы живем в обществе, ориентированном на мобильные устройства, где средний потребитель США тратит на телефон около четырех часов в день. Исследования показали, что почти три из них тратятся на приложения (примечание — в России среднее количество времени, проведенного в мобильном интернете, на человека составляет 3 часа 14 минут в день).

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

Специфика мобильных устройств позволяет использовать дополнительные способы продвижения, отслеживая данные о поведении пользователей: например, push-уведомления и геомаркетинг. Геомаркетинг — это когда используется географическое местоположение пользователя, а push-уведомления приходят, когда вы физически находитесь рядом с магазином. Вы также можете воспользоваться данными о времени — в какие моменты пользователи наиболее активно пользуются смартфонами.

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

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

Напомним, атрибуция — это механизм объяснения причин поведения человека.

Мобильная атрибуция, как правило, более сложная, чем веб. В основном это связано с тем, что по «пути» пользователя что-то может пойти не так во многих местах, а именно: Кампания — Маркетплейс — Загрузка — Обязательство. И здесь маркетплейс не дает представления об атрибуции.

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

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

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

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

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

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

Целевая страница приложения — это страница приложения в маркетплейсе.

Целевая страница сайта — это посадочная страница сайта.

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

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

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

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

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

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

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

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

A/B-тестирование приложений может проводиться на разных платформах. Если вам нужна бесплатная опция для Android, то Google Play Experiment — это то, что вам нужно. А вот iOS не предоставляет никаких инструментов A/B-тестирования.

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

Наши советы для A/B тестирования приложений:

1. Тестируйте визуалы и тексты; обычно это скриншоты, видео и УТП.
   
   
2. Протестируйте разные скриншоты и другие визуалы и сопоставьте их друг с другом. Важно: убедитесь, что в каждой переменной есть только одно изменение, чтобы вы могли легко определить, что повлияло на результаты.
   
   
3. Проанализируйте результаты, чтобы можно было как вносить изменения, так и делать последующие тесты на их основе. Что именно заставляет людей выполнять действие? Чтобы понять это, иногда нужно незначительно изменить концепцию или объединить УТП из одной концепции и скриншоты из другой.
   
   

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

Есть разные инструменты, например, Optimizely или Google и Яндекс метрики и разные протоколы, которые нацелены на разные поведенческие тенденции, разные устройства и разные платформы.