Search suggest android что это

Использование Android Search Dialog. Часть 3 — Custom Suggestions

Это заключительная статья по использованию Android Search Dialog (предыдущие находятся здесь и здесь). В ней я расскажу, как добавить в диалог динамические подсказки к поиску, а также, как интегрировать поиск по вашему приложению в системный Quick Search Box (QSB). Преимущество QSB в том, что с его помощью можно получать информацию из практически любого места в OS.

Теория

Подсказки к поиску создаются при помощи данных вашего приложения, по которым осуществляется поиск. Когда пользователь выбирает одну из них, то Search Manager посылает Intent к Activity, которое отвечает за поиск. Обычно, когда пользователь нажимает иконку поиска в диалоге, то отправляется Intent типа Search, однако, при выборе подсказки в данном случае можно определить другой тип Intent, так чтобы мы могли его перехватить и совершить соответствующие действия, например, создание нового диалога, или вызов Activity для отображения информации и т.д.
Данные поискового запроса переносятся через Intent как и раньше, однако теперь мы будем использовать URI, чтобы определять тип запроса через контент-провайдер.

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

Итак, когда Search Manager определяет наше Activity как отвечающее за поиск и обеспечивающее подсказки к поиску, то происходит следующая последовательность действий:

1. Когда Search Manager получает текст поискового запроса, то он отправляет свой запрос к контент-провайдеру, обеспечивающему подсказки.
2. Контент-провайдер возвращает курсор, указывающий на подсказки, которые совпадают с текстом поискового запроса.
3. Search Manager отображает подсказки, используя курсор

После того как список подсказок был отображен, может случиться следующее:

• Если пользователь изменяет текст запроса, то все вышеперечисленные шаги повторятся.
• Если пользователь запускает поиск, то подсказки игнорируются, и к Activity отправляется Intent типа Search.
• Если пользователь выбирает подсказку, то к Activity доставляется Intent другого типа (тип определяется в конфигурационном файле), переносящий URI в качестве данных. URI будет использоваться для поиска записи в таблице, соответствующей выбранной подсказке.

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

• Изменить конфигурационный файл диалога, добавив к нему информацию о контент-провайдере и типе Intent, используемом для подсказок
• Создать таблицу в БД SQLite, которая будет предоставлять столбцы, требуемые Search Manager’ом для подсказок
• Создать новый контент-провайдер, имеющий доступ к таблице подсказок, и определить его в манифесте
• Добавить Activity, которое будет отображать информацию при выборе подсказок

Изменяем конфигурационный файл

Напоминаю, что конфигурационный файл (res/xml/searchable.xml) требуется для отображения диалога и его изменения, например, для использования голосового поиска. Чтобы использовать динамические подсказки, необходимо добавить в файл параметр: android:searchSuggestAuthority. Он будет совпадать со строкой авторизации контент-провайдера. Кроме этого добавим параметр android:searchMode=«queryRewriteFromText», его значение указывает на то, что строка поиска в диалоге будет перезаписываться при навигации по подсказкам, например с помощью трекбола. Также добавим параметры, задающие оператор выборки, тип Intent отправляемого при выборе подсказки, и минимальное количество напечатанных символов в диалоге, необходимое для запроса к контент-провайдеру.

Создаем контент-провайдер

По сути наш контент-провайдер ничем не отличается от других. Но нужно сделать так, чтобы для каждой строки из таблицы подсказок выбирались нужные столбцы, те которые требует Search Manager. Мы будем запрашивать данные по подсказкам с помощью метода контент-провайдера query(). Причем вызываться он будет каждый раз, когда пользователь печатает новый символ в диалоге. Таким образом, метод query() должен возвращать курсор на записи в таблице, совпадающие с запросом, и тогда Search Manager сможет отобразить подсказки. Смотрите описание метода в комментариях к коду.
Сам текст запроса будет дописываться к URI, так что с его получением проблем не будет, нужно просто использовать стандартный метод getLastPathSegment().

Создание таблицы подсказок

Когда Search Manager получает курсор, указывающий на записи, то он ожидает определенный набор столбцов для каждой записи. Обязательными являются два: _ID — уникальный идентификатор каждой подсказки, и SUGGEST_COLUMN_TEXT_1 — текст подсказки.
Необязательных столбцов существует много, например используя SUGGEST_COLUMN_ICON_1, вы можете определить для каждой записи иконку, отображаемую с левой стороны подсказки (очень удобно, например, для поиска по контактам).

Определение типа данных для Intent

Так как мы передаем данные по запросу через URI, то нам нужен механизм для определения того, какая подсказка была выбрана. Тут есть два пути. Первый, заключается в том, чтобы определить отдельный столбец SUGGEST_COLUMN_INTENT_DATA, в котором будут уникальные данные для каждой записи, тогда можно получать данные из Intent через getData() или getDataString(). Второй вариант — определить тип данных для всех Intent в конфигурационном файле (res/xml/searchable.xml) а потом дописывать к URI уникальные данные для каждого Intent, используя столбец SUGGEST_COLUMN_INTENT_DATA_ID.
Мы будем использовать второй вариант, причем отдельных столбцов в таблице я не создавал, так как можно просто создать отображение из SUGGEST_COLUMN_INTENT_DATA_ID в rowId таблицы. Добавлю еще, что ради спортивного интереса в SQLite для поиска использовался FTS3, то есть пришлось создавать виртуальную таблицу, для которой нельзя накладывать ограничения на столбцы (constraints), такие как PRIMARY KEY или NULL/NOT NULL. Зато у виртуальных таблиц есть уникальный идентификатор строки, на него и установим отображение. То есть data для Intent будет иметь следующий вид: к URI будет дописываться «/» и rowId строки в таблице.

Создание Activity для отображения информации

Интерфейс находится в res/layout/record_activity.xml. Всё чем занимается Activity — получение данных из Intent, запрос курсора через контент-провайдер и отображение записи в текстовом поле.

Теперь внесем информацию о контент-провайдере и новом Activity в манифест, также, так как у нас теперь два Activity, то укажем то, которое по умолчанию отвечает за поиск.

Перехват Intent в Activity, отвечающем за поиск

После всех вышеперечисленных шагов нужно обработать Intent в главном Activity, которое отвечает за поиск. Так как мы определили тип Intent для подсказок как View, то нужно просто добавить проверку на него. В случае если условие выполнится, то запускается RecordActivity, используя Intent, в данные которого записывается URI + «/» + id подсказки в таблице.

Источник

ASO оптимизация. Составление семантического ядра для магазинов приложений

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

Это будет первая статья цикла “Популяризация ASO”. В этом цикле я опишу все этапы оптимизации приложения, какими сервисами пользуюсь и на что нужно обращать внимание при проведении оптимизации.

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

Понятие семантического ядра

App Store Optimization — это оптимизация метаданных для улучшения метрик приложения и улучшения поисковой видимости в выдаче магазинов приложений.

Семантическое ядро — это набор поисковых слов и словосочетаний (ключевых слов), которые наиболее точно характеризуют ваше приложение.

В первую очередь хотелось бы обратить ваше внимание на то, что сбор семантического ядра (далее – “СЯ”) – это одна из самых важных и трудозатратных задач в оптимизации приложения. Но именно на его основе мы и выбираем, какие ключевые слова (далее – “КЧ”) мы будем использовать.

Ключевые слова могут иметь:

• высокую частотность (ВЧ);
• среднюю частотность (СЧ);
• низкую частотность (НЧ).

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

Для наглядности, рассмотрим этапы составления СЯ на примере приложения моего хорошего знакомого, который любезно согласился предоставлять и разглашать все данные по приложению – “Travel Quests” (на момент публикации статьи, приложение еще не вышло в App Store).
Перед составлением СЯ очень важно ответить для себя на несколько вопросов.

Подготовительная работа

Кто ваша целевая аудитория?

Здесь нужно понимать, на кого рассчитано ваше приложение. Приведу пример: у вас есть игра, но она подходит для игры только маленьким девочкам (например, в ней нужно одевать кукол, мальчики и девочки постарше вряд ли захотят в такое играть, ведь так?). Поэтому нужно четко сегментировать аудиторию при составлении СЯ.

Какое ценностное предложение несет приложение?

О чем, вообще, ваше приложение? Какую задачу оно позволит решить пользователю, если он установит ваше приложение? Ответы на эти вопросы будут вашими первыми релевантными запросами.

Каковы основные отличия от конкурентов?

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

Кто ваши конкуренты?

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

Какой основной рынок вашего приложения?

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

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

Как подобрать ключи?

Для составления СЯ нам необходимо подобрать ключевые слова, из которых мы потом будем выбирать наиболее подходящие для продвижения. Тут вернемся к нашему приложению Travel Quests. Собственно, из названия можно понять, что это сервис этот связан с квестами и путешествиями. Поэтому ориентироваться будем на людей, которые хотят отправиться в поездку и ищут различные варианты для проведения активного и полезного отдыха.

Релевантные запросы в данном случае: «путешествие», «путеводитель», «гид» и т.д. Помимо них отметим еще несколько околорелевантных запросов, т.е. тех, которые впрямую не указывают на функционал нашего приложения, но трафик по которым мы тоже можем получить. В данном случае это могут быть слова «музей», «туры» (Travel Quests — это не турфирма, но такой запрос попадает в нашу целевую аудиторию) и др. Релевантность запросов определяется чисто субъективно, чем больше вариантов вы проработаете, тем более качественное СЯ вы в итоге составите.

Когда собственные идеи иссякли, для поиска релевантных слов можно использовать следующие методы:

Оцениваем частотность

Как я уже говорил выше, получить статистику по частотности запросов в App Store и Google Play нельзя, но это не значит, что ее никак нельзя оценить.

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

Для App Store есть еще один инструмент, который Apple недавно представила разработчикам — SearchAds. По нему можно приблизительно оценить количество трафика по тому или иному запросу. Но сейчас это работает только для рынка США. Если ваше приложение нацелено как раз на американский рынок, то пользоваться SearchAds обязательно!

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

Suggest & Search

Итак, регистрируемся в AppFollow, затем «Suggest & Search» (сейчас раздел называется по-другому — Keyword research, находится в левом меню). Увидим такое окно:

Выбираем интересующий нас девайс: iPhone/iPad или Android. В следующем поле мы вбиваем слова, саджесты которых хотим увидеть. Последним пунктом в выпадающем списке, выбираем нужную нам локаль.

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

Замечу, что если вы проверяете саджесты для Android, то Google Play их выдает с учетом вашего IP-адреса. Т.е. если вы находитесь в России, а вам нужно посмотреть саджесты для США, обязательно поменяйте свой IP на американский (бесплатные VPN в помощь), иначе выдачу вам дадут по стране, где вы находитесь. Если же вы собираете СЯ из России для российского Google Play, то все ОК.

Именно по саджестам правильнее всего собирать семантическое ядро, т.к. далеко не все запросы, которые предлагает Keyword Planner или Яндекс.Wordstat пользуются популярностью в мобильном поиске.

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

Google Sheets

Существует и более быстрый способ выгрузки саджестов — через Google Sheets. Для этого создаем новый документ в Google Docs и устанавливаем Add-on AppFollow. Дальше будет немного картинок и немного кода, поэтому для удобства чтения я спрятал это все под спойлер.

В любой ячейке прописываем формулу: =getSuggest(«mario», «US», «android»). Вместо «mario» пишите слово или словосочетание, по которому хотите получить список саджестов. «US» это локаль приложения, если вам нужно собрать запросы для другой локали (US\UK\ES\DE и т.д), то просто меняете «US» на нужную вам кодировку. «Android» — это платформа. Не забудьте проставлять кавычки.

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

Если у вас по какой-либо причине не устанавливается дополнение AppFollow, то вот ссылка на GitHub, где выложен код нужного нам скрипта. Копируем этот код и вставляем его в редакторе скриптов Google Sheets, затем сохраняем. Теперь можно пользоваться этой фичей.

Выбираем важное

Итак, с помощью ручного ввода, AppFollow или Google Sheets мы собрали список саджестов. В итоге, у нас получилась таблица, где мы указываем наши запросы, а ниже список саджестов для того или иного маркета в той или иной локали. Получилось что-то вроде этого:

Собрав выдачу по всем возможным саджестам, отмечаем цветами релевантные и околорелевантные запросы. В этой таблице релевантные запросы выделены синей заливкой, а околорелевантные — желтой.

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

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

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

Задавайте вопросы, пишите с чем не согласны, спрашивайте если что-то не совсем понятно. Пишите в комментах, или на facebook, буду рад ответить на все вопросы!

Полезные ссылки на статьи по ASO: раз, два, три, четыре.

Источник