Как Google проектирует пользовательский интерфейс (UI/UX) для вертикального поиска отелей

Описание

Какую задачу решает

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

Что запатентовано

Запатентован набор методов и систем для реализации пользовательского интерфейса (UI) поиска отелей. Изобретение описывает структуру интерфейса, включающую отдельные зоны для списка результатов, «шорт-листа» (Shortlist) и карты. Описаны конкретные функции взаимодействия: добавление отелей в шорт-лист для сравнения, отображение Relative Price (относительной цены), inline-расширение результатов, а также представление результатов в виде массива (Array View) или на карте с географическими фильтрами и оверлеями.

Как это работает

Патент описывает различные UI-механизмы:

• Многозонный интерфейс: Результаты представляются в интерфейсе, разделенном на непересекающиеся зоны (например, список, карта, шорт-лист).
• Шорт-лист (Shortlist): Пользователь может добавлять интересующие отели в отдельную зону для последующего сравнения.
• Относительная цена (Relative Price): Для каждого отеля может отображаться индикатор, показывающий, насколько текущая цена отличается от исторической средней цены этого отеля.
• Inline Expansion и Hotel Cards: Пользователь может просматривать детали отеля либо через расширение блока в списке результатов (Inline Expansion), либо через Hotel Card (отдельное окно или оверлей), которое позволяет «пролистывать» следующие отели без возврата к списку.
• Фильтрация по отзывам: Пользователь может ввести текстовую фразу (например, «бесплатный wifi»), и система отобразит сниппеты из отзывов, содержащие эту фразу, поверх соответствующих результатов (Review Overlay).
• Карта и Tourist Spotlight: Отображение результатов на карте с возможностью ограничения поиска определенным полигоном и включения градиентного оверлея (Tourist Spotlight), подсвечивающего популярные туристические зоны.

Актуальность для SEO

Высокая. Хотя патент подан в 2012 году, описанные в нем UI/UX концепции (шорт-листы, фильтры, карты, карточки отелей, относительные цены) стали стандартом индустрии и лежат в основе текущих продуктов Google (Google Hotels/Travel) и других метапоисковых систем бронирования.

Важность для SEO

Патент имеет минимальное прямое влияние на традиционные SEO-стратегии (ранжирование в основном веб-индексе). Он не описывает алгоритмы ранжирования, а фокусируется исключительно на презентационном слое вертикального поиска отелей. Однако для специалистов по локальному SEO и оптимизации видимости отелей (Hotel SEO) патент важен, так как он раскрывает, какие данные Google использует и как представляет их пользователю, что напрямую влияет на кликабельность (CTR) и конверсию внутри продукта Google Hotels.

Детальный разбор

Термины и определения

Hotel Card (Карточка отеля)

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

Hotel Results Interface (Интерфейс результатов поиска отелей)

Общий пользовательский интерфейс для представления результатов поиска по заданным параметрам (локация, даты).

Inline Expansion / Expanded Listing (Встроенное расширение / Развернутый список)

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

Polygon Filtering (Фильтрация полигоном)

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

Relative Price (Относительная цена)

Индикатор, показывающий, как цена отеля на выбранные даты соотносится с его исторической ценой (historic price). Используется как для отображения в результатах, так и в качестве фильтра.

Results Array (Массив результатов / Сетка)

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

Review Overlay (Оверлей с фрагментом отзыва)

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

Shortlist (Шорт-лист / Список избранного)

Отдельная область интерфейса (second region), куда пользователь может добавлять выбранные отели из списка результатов для последующего сравнения.

Tourist Spotlight (Туристическая подсветка)

Функция карты, представляющая собой градиентный оверлей (gradient overlay), который визуально выделяет (подсвечивает) географические области, популярные среди туристов.

Ключевые утверждения (Анализ Claims)

Это преимущественно UI/UX патент. Ключевые утверждения защищают конкретные конфигурации интерфейса и методы взаимодействия.

Claim 1 (Независимый пункт): Описывает базовую структуру интерфейса с шортлистом.

1. Система получает параметры поиска отелей и результаты.
2. Представляет результаты в первой области (first region) интерфейса. Интерфейс имеет как минимум две различные, неперекрывающиеся и одновременно отображаемые области.
3. Получает выбор пользователя отеля из результатов.
4. Представляет информацию о выбранном отеле во второй области (second region) интерфейса (т.е. Shortlist).

Claim 6 (Независимый пункт): Описывает группировку результатов в интерфейсе.

1. Система получает параметры и результаты поиска отелей.
2. Представляет результаты в интерфейсе в виде нескольких групп (plurality of groups).
3. Каждая группа связана с определенным критерием (group criteria) и включает результаты, удовлетворяющие этому критерию (например, по звездному рейтингу, как указано в Claim 7).

Claim 9 (Независимый пункт): Описывает интерфейс, сочетающий список и карту.

1. Система получает параметры и результаты поиска отелей.
2. Представляет результаты в первой области (first region).
3. Представляет карту результатов поиска во второй области (second region).
4. Локация каждого результата отображается в виде иконки на карте. Области не перекрываются и отображаются одновременно.

Зависимые пункты (Детализация функций):

• Claim 2: Уточняет, что в списке результатов отображается индикатор Relative Price по сравнению с историческими ценами.
• Claim 4: Уточняет механизм Inline Expansion — расширение выбранного результата внутри списка.
• Claim 10: Уточняет функцию карты Tourist Spotlight — отображение градиентного оверлея, выделяющего области с определенной характеристикой ярче других.

Где и как применяется

Изобретение относится к презентационному слою специализированной вертикальной поисковой системы (Google Hotels) и затрагивает финальные этапы обработки поискового запроса.

METASEARCH – Метапоиск и Смешивание
На этом этапе формируется специализированная выдача для запросов, связанных с отелями. Патент описывает структуру этой выдачи (Hotel Results Interface). Система агрегирует данные из индекса отелей (цены, наличие мест, характеристики, отзывы, изображения) и компонует их с использованием описанных UI-элементов (списки, карты, карточки).

RERANKING – Переранжирование (Презентационный слой)
Хотя патент не описывает алгоритмы изменения порядка ранжирования, он детально описывает механизмы, которые позволяют пользователю переупорядочивать (Sorting) и фильтровать (Filtering) предварительно ранжированный набор результатов в реальном времени внутри интерфейса. Сюда относятся фильтры по цене, рейтингу, Relative Price, удобствам, а также географические фильтры на карте (полигоны).

Входные данные:

• Параметры запроса пользователя (локация, даты).
• Набор ранжированных результатов поиска отелей.
• Данные для каждого отеля: метаданные, изображения, отзывы, текущие цены, исторические данные о ценах (Historic Prices).
• Геопространственные данные (координаты отелей, данные о популярных туристических зонах).

Выходные данные:

• Сформированный пользовательский интерфейс (Hotel Results Interface) с результатами, представленными в выбранном формате (список, массив, карта) и с примененными фильтрами и сортировкой.

На что влияет

• Конкретные типы контента: Влияет исключительно на представление сущностей типа «Отель» в специализированном поиске (Google Hotels).
• Специфические запросы: Коммерческие и локационные запросы, связанные с бронированием жилья (например, «отели в Стамбуле»).
• Мультимедиа: Патент подчеркивает важность визуального представления, описывая использование изображений и видео в Inline Expansion, Hotel Cards и Results Array.
• Отзывы: Текст отзывов используется для генерации сниппетов и для фильтрации по ключевым фразам (Review Overlay).

Когда применяется

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

• Триггеры активации: Различные функции активируются в ответ на действия пользователя:
  • Выбор отеля активирует Inline Expansion или Hotel Card.
  • Нажатие «Add to Shortlist» перемещает отель во вторую зону интерфейса.
  • Ввод текста в поле фильтрации по отзывам активирует поиск по тексту отзывов и отображение Review Overlay.
  • Включение опции Show Tourist Spotlight активирует градиентный оверлей на карте.

Пошаговый алгоритм

Патент описывает несколько взаимодействующих процессов. Ниже приведен основной процесс обработки и отображения результатов в UI.

1. Получение параметров поиска: Система получает входные данные от пользователя (локация, даты и т.д.).
2. Получение результатов: Система извлекает набор отелей, соответствующих параметрам.
3. Презентация интерфейса: Система генерирует Hotel Results Interface. Это включает разделение интерфейса на зоны (список результатов, карта, зона для шорт-листа).
4. Отображение результатов: Результаты отображаются в первой зоне. Для каждого результата вычисляется и отображается Relative Price (если доступно). Результаты могут быть сгруппированы по критериям (например, по рейтингу).
5. Обработка взаимодействий пользователя (Цикл):
   • Фильтрация/Сортировка: При получении ввода для фильтрации (например, по Relative Price) или сортировки, система модифицирует набор отображаемых результатов.
   • Взаимодействие с картой: При переключении в режим карты система отображает индикаторы отелей. Может быть активирован Tourist Spotlight или применен фильтр по географическому полигону.
   • Выбор отеля (Детализация): При выборе конкретного отеля система может выполнить Inline Expansion или отобразить Hotel Card (оверлей с деталями и навигацией к другим отелям).
   • Добавление в шорт-лист: При соответствующем выборе пользователя отель добавляется во вторую зону интерфейса (Shortlist).
6. Бронирование: При выборе опции бронирования пользователь направляется к провайдеру.

Какие данные и как использует

Данные на входе

Патент фокусируется на UI и предполагает наличие следующих данных:

• Контентные факторы (Отзывы): Текст отзывов из различных источников. Используется для отображения сниппетов и для функции фильтрации по текстовым фразам (Review Overlay). Средний пользовательский рейтинг.
• Мультимедиа факторы: Изображения и видео отелей. Активно используются в Hotel Cards, Inline Expansion и Results Array. Также используются данные Street View.
• Географические факторы: Адреса и координаты отелей для отображения на карте. Данные о границах районов и популярности туристических зон (для Tourist Spotlight и полигонов).
• Структурные факторы (Данные отеля): Рейтинг (звездность), список удобств (amenities), контактная информация.
• Коммерческие данные: Текущие цены на номера от различных провайдеров бронирования.
• Временные факторы (Исторические цены): Исторические данные о ценах на конкретный отель (Historic Prices), необходимые для расчета Relative Price.
• Пользовательские факторы (Социальные): В одном из вариантов упоминается отображение рейтингов от пользователей из социальной сети ищущего.

Какие метрики используются и как они считаются

• Relative Price (Относительная цена): Метрика, сравнивающая текущую цену с исторической. Патент не дает формулы, но указывает, что это индикатор того, насколько цена отличается от «типичной» или «средней» за указанный период времени. Может выражаться в процентах (например, «17% MORE», «34% LESS»).
• Tourist Popularity (Неявная метрика для Tourist Spotlight): Данные, используемые для генерации Tourist Spotlight. Патент не уточняет расчет, но указывает, что «яркие области более популярны у посетителей».

Выводы

1. Фокус на UI/UX вертикального поиска: Патент полностью посвящен улучшению пользовательского интерфейса специализированного поиска отелей. Он не раскрывает алгоритмов ранжирования, но детально описывает, как результаты представляются пользователю.
2. Google как платформа метапоиска: Патент подтверждает стратегию Google по развитию собственных вертикальных продуктов (Metasearch). Цель — удержать пользователя в экосистеме Google на всех этапах поиска и принятия решения.
3. Важность структурированных данных и медиа: Видимость в этом интерфейсе сильно зависит от качества и полноты данных, которые Google получает об отеле (цены, фото, удобства, отзывы). Интерфейс спроектирован для агрегации фото, видео и Street View.
4. Использование отзывов для фильтрации: Патент описывает механизм использования текста отзывов не только для оценки качества, но и как инструмент интерактивной фильтрации по конкретным характеристикам с отображением релевантных сниппетов (Review Overlay).
5. Контекстуализация цены (Relative Price): Введение метрики Relative Price показывает стремление помочь пользователю оценить выгодность предложения, используя исторические данные о ценах как бенчмарк.
6. Геопространственные сигналы для UX: Использование Tourist Spotlight и фильтрации по полигонам на карте помогает пользователю ориентироваться, визуально выделяя релевантные или популярные районы.

Практика

Best practices (это мы делаем)

Рекомендации применимы для SEO-специалистов, работающих с сайтами в нише Travel/Hospitality и оптимизирующих присутствие в Google Hotels и Local Search.

• Обеспечение полноты данных для вертикали: Убедитесь, что Google получает максимально полные и точные данные об объекте (через Google Business Profile, фиды данных, API). Это включает полный список удобств (Amenities), точные координаты и актуальные цены.
• Оптимизация визуальных активов: Предоставлять высококачественные, разнообразные и актуальные фотографии и видео. Это критично для привлекательности отеля в Results Array, Inline Expansion и Hotel Cards.
• Стратегия работы с отзывами: Активно собирать отзывы, выделяющие конкретные преимущества отеля (например, «быстрый wifi», «новый бассейн»). Поскольку система может извлекать сниппеты из отзывов для функции Review Overlay, наличие таких упоминаний улучшает видимость при использовании соответствующих фильтров пользователями.
• Мониторинг цен и конкурентоспособность: Отслеживать Relative Price в интерфейсе Google. Понимание того, как Google позиционирует цену отеля (как выгодную или завышенную по сравнению с историей), важно для оценки общей конверсионности предложения.

Worst practices (это делать не надо)

• Игнорирование вертикального поиска: Полагаться только на традиционное органическое SEO в нише отелей неэффективно. Основной трафик и конверсии происходят внутри интерфейса Google Hotels, описанного в патенте.
• Предоставление неточных или устаревших данных: Неактуальные цены, неверное расположение или отсутствие информации об удобствах приведут к плохому пользовательскому опыту и потере видимости при применении фильтров в интерфейсе.
• Игнорирование качества изображений: Использование старых, некачественных фотографий приведет к низкой кликабельности в визуально ориентированном интерфейсе.

Стратегическое значение

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

Практические примеры

Сценарий: Оптимизация видимости отеля с бассейном (Использование Review Overlay)

1. Анализ интерфейса: SEO-специалист замечает, что в интерфейсе Google Hotels есть возможность фильтрации по текстовым отзывам.
2. Действия (Отзывы): Стимулировать гостей оставлять отзывы, упоминающие бассейн (например, «отличный бассейн на крыше»).
3. Механизм (по патенту): Когда пользователь вводит запрос для фильтрации отзывов «бассейн на крыше», система сканирует отзывы.
4. Ожидаемый результат: На карточке отеля появляется оверлей с позитивным сниппетом из отзыва («Отличный бассейн на крыше…»), что повышает CTR и вероятность бронирования.

Сценарий: Использование «Relative Price» для привлечения внимания

1. Анализ: Предстоит период низкого спроса. Необходимо привлечь пользователей, ищущих выгодные предложения.
2. Действие: Отель временно снижает цены значительно ниже своего исторического среднего уровня. Данные обновляются в фиде для Google.
3. Результат: В интерфейсе Google Hotels рядом с ценой отеля появляется индикатор Relative Price (например, «25% LESS»). Пользователи, применяющие фильтр по относительной цене или ищущие выгодные сделки, обращают внимание на этот отель.

Вопросы и ответы