Google отслеживает недавние поисковые запросы пользователя в рамках сессии. Если после поиска информации или товара (например, «Harry Potter») пользователь вводит навигационный запрос (например, «Amazon»), система предсказывает его намерение и автоматически выполняет поиск «Harry Potter site:amazon.com». Эти конкретные результаты вставляются непосредственно в основную страницу выдачи по запросу «Amazon».
Описание
Какую задачу решает
Патент решает проблему неэффективного пути пользователя (user journey). Типичный сценарий: пользователь выполняет информационный или товарный поиск (например, «лучший ноутбук»), затем выполняет отдельный навигационный запрос (например, «Amazon»), переходит на сайт и вынужден повторно вводить исходный запрос во внутреннем поиске сайта. Изобретение направлено на сокращение этого пути, предугадывая намерение пользователя и автоматически выполняя поиск по целевому сайту за него.
Что запатентовано
Запатентована система, которая прогнозирует намерение пользователя путем анализа его недавней истории поиска (Recent Queries) в сочетании с последующим навигационным запросом (Navigational Query). Если система обнаруживает, что пользователь недавно искал определенные элементы (товары, контент) и затем ищет конкретный веб-сайт, она автоматически генерирует и выполняет альтернативный запрос (Alternate Query), ограниченный доменом целевого сайта, чтобы предоставить прямые ссылки на эти элементы.
Как это работает
Механизм работает следующим образом:
- Отслеживание сессии: Система сохраняет недавние запросы пользователя в рамках текущей сессии (Search History).
- Идентификация навигации: Система определяет, что новый запрос является навигационным, используя базу данных Nav_Name List.
- Прогнозирование и валидация: Система предполагает, что пользователь хочет найти недавно искавшиеся элементы на этом сайте. Она может проверить, связаны ли эти элементы с сайтом, используя базу данных Nav_Item List (на основе поведения других пользователей) или каталоги сайтов (Web Site Catalogs).
- Генерация альтернативного запроса: Автоматически создается Alternate Query, например, [недавний термин] site:[целевой домен].
- Параллельный поиск и слияние: Выполняются оба запроса. Результаты объединяются в выдаче с жесткой приоритизацией (Priority Attributes): Топовые навигационные результаты > Топовые альтернативные результаты > Остальные навигационные результаты.
Актуальность для SEO
Высокая. Сокращение трения в пути пользователя, понимание контекста сессии (Journeys) и предоставление быстрых ответов остаются ключевыми целями Google. Описанный механизм или его вариации часто наблюдаются в современной поисковой выдаче, особенно для крупных e-commerce сайтов и издателей, в виде персонализированных ссылок или блоков.
Важность для SEO
Патент имеет значительное влияние (6.5/10), особенно для крупных e-commerce площадок, издателей и сайтов с большими каталогами контента (например, Wikipedia, IMDb, YouTube). Он напрямую влияет на структуру SERP по брендовым запросам, делая ее динамичной и персонализированной на основе истории сессии. Это подчеркивает важность того, чтобы Google четко понимал каталог товаров/контента сайта (Nav_Items) и ассоциировал его с брендом (Nav_Name).
Детальный разбор
Термины и определения
- Alternate Query (Альтернативный запрос)
- Запрос, автоматически сгенерированный сервером. Он объединяет термины из недавних запросов пользователя и навигационный запрос. Часто имеет формат, ограничивающий поиск конкретным сайтом (например, item site:domain.com).
- Global Search Logs (Глобальные журналы поиска)
- Агрегированные данные о поисковых запросах и кликах всех пользователей. Используются для офлайн-анализа и построения списков Nav_Name и Nav_Item.
- Navigational Query (Навигационный запрос)
- Запрос, который включает идентификатор или термин, четко связанный с конкретным веб-сайтом (например, название бренда «Amazon», домен «amazon.com» или запрос с опечаткой «wolmart»).
- Nav_Name List (Список навигационных имен)
- База данных, содержащая пары навигационных запросов и связанных с ними адресов веб-сайтов. Используется для идентификации того, что запрос пользователя является навигационным.
- Nav_Item List (Список навигационных элементов)
- База данных, содержащая элементы (товары, термины, контент), связанные с конкретными веб-сайтами из Nav_Name List. Используется для валидации того, что недавно искавшийся элемент действительно относится к целевому сайту.
- Priority Attribute (Атрибут приоритета)
- Метка, присваиваемая различным типам результатов поиска (Топовые навигационные, Альтернативные, Остальные навигационные) для определения строгого порядка их отображения в объединенной выдаче.
- Recent Queries (Недавние запросы)
- Запросы, введенные пользователем незадолго до навигационного запроса. Определяются временными рамками (например, последние 30 минут), количеством (например, последние N запросов) или границами сессии.
- Web Site Catalogs (Каталоги веб-сайтов)
- Хранилище данных об элементах, доступных на различных веб-сайтах (например, списки товаров). Может использоваться для валидации наличия элемента на сайте.
Ключевые утверждения (Анализ Claims)
Claim 1 (Независимый пункт): Описывает основной метод реагирования на последовательность запросов и структуру выдачи.
- Система получает от пользователя запрос на элементы (включающий поисковые термины).
- Система получает и сохраняет результаты (или сам запрос).
- После этого система получает от того же пользователя отдельный Navigational Query для первого веб-сайта. Важное условие: поисковый термин из первого запроса отсутствует в навигационном запросе.
- В ответ на получение навигационного запроса, если первый запрос является «недавним» (recent query), система получает поисковый термин из недавнего запроса и выполняет Alternate Query.
- Alternate Query включает поисковый термин и навигационный запрос и выполняется в пределах домена первого веб-сайта.
- Система форматирует для отображения и передает пользователю: Альтернативные результаты, Топовые навигационные результаты и Остальные навигационные результаты.
- Определяется строгий порядок отображения на основе Priority Attribute:
- First priority attribute (высший): Топовые навигационные результаты (отображаются выше всех).
- Second priority attribute: Альтернативные результаты (отображаются ниже Топовых навигационных).
- Third priority attribute (низший): Остальные навигационные результаты (отображаются ниже Альтернативных).
Claim 5 (Зависимый от 1): Описывает механизм валидации связи между элементом и сайтом на основе глобальных данных.
Перед выполнением альтернативного запроса система подтверждает, что другой пользователь (не текущий) ранее выбирал результаты, связанные с этим поисковым термином, и что эти выбранные результаты были связаны с первым веб-сайтом. Это подтверждает релевантность элемента для данного сайта на основе исторических данных (использование данных типа Nav_Item List).
Claim 9 (Зависимый от 1): Описывает альтернативный механизм валидации на основе каталога.
Перед выполнением альтернативного запроса система сравнивает поисковый термин с сохраненным списком элементов (list of items, например, Web Site Catalogs) для первого веб-сайта, чтобы определить, что элементы, на которые ссылаются поисковые термины, связаны с этим веб-сайтом.
Claim 10 (Зависимый от 1): Уточняет, что недавний запрос и навигационный запрос получены в рамках одной и той же сессии браузера (same browsing session).
Где и как применяется
Изобретение затрагивает несколько этапов поиска, используя данные, собранные на этапе индексирования и анализа поведения пользователей, и реализуется на финальных этапах формирования выдачи.
INDEXING – Индексирование и извлечение признаков (и анализ логов)
На этом этапе (в офлайн-режиме) система анализирует глобальные логи поиска (Global Search Logs) и данные о кликах для построения баз данных Nav_Name List и Nav_Item List. Это необходимо для понимания того, какие запросы являются навигационными и какие элементы связаны с какими сайтами.
QUNDERSTANDING – Понимание Запросов
В реальном времени система должна идентифицировать текущий запрос как Navigational Query. Также система отслеживает и получает доступ к истории сессии пользователя (Recent Queries).
RANKING / METASEARCH / RERANKING – Ранжирование, Метапоиск и Переранжирование
Основное применение патента происходит на этих этапах:
- Триггер: Поступление навигационного запроса после недавних информационных/товарных запросов в рамках одной сессии.
- Валидация (Опционально): Проверка связи между недавними терминами и целевым сайтом (используя Nav_Item List или Web Site Catalogs).
- Генерация и выполнение: Создание и выполнение Alternate Query параллельно с основным навигационным запросом.
- Смешивание (Blending) и Приоритизация: Объединение результатов и присвоение им Priority Attributes (Первый, Второй, Третий) для определения финального порядка отображения.
Входные данные:
- Недавние запросы пользователя (Recent Queries).
- Текущий навигационный запрос.
- База данных Nav_Name List.
- База данных Nav_Item List и/или Web Site Catalogs.
- Идентификатор пользователя/сессии (Session-ID).
Выходные данные:
- Объединенная страница результатов поиска (SERP) с измененной структурой, включающей результаты альтернативного запроса, упорядоченные по Priority Attributes.
На что влияет
- Конкретные типы контента и ниши: Наибольшее влияние оказывается на E-commerce, крупных издателей, сайты с большими каталогами контента (видеохостинги, энциклопедии, новостные порталы, сайты государственных услуг). Влияет на страницы товаров, статей, категорий. Примеры включают YouTube, Wikipedia, IRS.
- Специфические запросы: Влияет исключительно на навигационные (брендовые) запросы.
Когда применяется
Алгоритм применяется при выполнении строгой последовательности условий:
- Условие 1 (Последовательность): Пользователь ввел один или несколько информационных/товарных запросов, за которыми следует навигационный запрос.
- Условие 2 (Временные рамки/Сессия): Запросы должны находиться в рамках одной сессии. Патент определяет критерии недавности, например:
- Временной период (например, последние 30 минут).
- Количество последних запросов (например, последние 4 запроса).
- Временной разрыв между запросами (например, не более 10 минут).
- Условие 3 (Валидация связи): Система может подтвердить (используя Nav_Item List, Web Site Catalogs или данные о кликах других пользователей), что элементы из недавних запросов связаны с сайтом из навигационного запроса.
Пошаговый алгоритм
Процесс А: Обработка запроса в реальном времени
- Получение и сохранение недавних запросов: Система непрерывно получает и сохраняет запросы от пользователя, ассоциируя их с идентификатором сессии.
- Получение навигационного запроса: Пользователь вводит новый запрос.
- Идентификация и проверка условий: Система идентифицирует запрос как навигационный и проверяет историю недавних запросов на соответствие критериям сессии (Recent Queries).
- Валидация связи (Определение ассоциации): Система определяет, связаны ли элементы из недавних запросов с целевым сайтом навигационного запроса. Это делается путем:
- Сравнения терминов с Nav_Item List для данного сайта.
- ИЛИ анализа глобальных данных о кликах (поведение других пользователей).
- ИЛИ сравнения с Web Site Catalogs.
- Генерация альтернативного запроса: Если связь подтверждена, генерируется Alternate Query (например, [термин из недавнего запроса] site:[домен сайта]).
- Выполнение параллельного поиска: Система выполняет исходный навигационный запрос и альтернативный запрос.
- Ранжирование и отбор: Определяются топовые результаты для обоих запросов.
- Слияние и приоритизация (Merging): Результаты объединяются, и им присваиваются Priority Attributes:
- Топовые навигационные результаты (Первый приоритет).
- Топовые альтернативные результаты (Второй приоритет).
- Остальные навигационные результаты (Третий приоритет).
- Передача и отображение: Объединенные результаты передаются клиенту для отображения в установленном порядке приоритета.
Процесс Б: Офлайн-генерация навигационных списков
- Анализ глобальных логов: Система анализирует Global Search Logs.
- Создание Nav_Name List: Идентифицируются запросы «X», по которым значительный процент кликов (например, >60%) приходится на сайт X. Запрос «X» добавляется как Nav_Name.
- Создание Nav_Item List: Идентифицируются запросы вида «X Y» или «Y X» (где X – Nav_Name, Y – элемент), по которым большинство кликов приходится на сайт X. Элемент «Y» добавляется как Nav_Item, ассоциированный с X.
Какие данные и как использует
Данные на входе
Патент фокусируется на использовании поведенческих данных и предварительно рассчитанных ассоциаций.
- Поведенческие факторы (Текущий пользователь/Сессия):
- Recent Queries: История запросов пользователя в рамках сессии.
- Идентификатор пользователя или сессии (например, из cookies).
- Временные метки запросов.
- Поведенческие факторы (Глобальные данные):
- Global Search Logs: Журналы запросов и данные о кликах всех пользователей. Критичны для построения Nav_Name и Nav_Item списков.
- Контентные/Структурные факторы:
- Web Site Catalogs: Каталоги сайтов (списки товаров/контента), которые могут использоваться для валидации наличия элемента на сайте (Claim 9).
Какие метрики используются и как они считаются
- Определение «Недавний» (Recency/Session Boundaries): Метрики для определения границ сессии. Упоминаются:
- Временной промежуток с момента запроса (например, 30 минут).
- Временной разрыв между запросами (например, 10 минут).
- Количество последних запросов (например, N=4).
- Построение Nav_Name List: Метрика кликов. Запрос «X» считается навигационным для сайта X, если предопределенный процент кликов (например, >60%) по результатам запроса «X» приходится на сайт X.
- Построение Nav_Item List: Метрика кликов. Элемент «Y» ассоциируется с сайтом «X», если при анализе запросов вида «X Y» или «Y X» большинство кликов приходится на сайт X.
- Priority Attributes: Дискретные метки (Первый, Второй, Третий), определяющие фиксированный порядок отображения результатов в SERP.
Выводы
- Прогнозирование и сокращение пути пользователя: Google активно использует данные сессии для прогнозирования намерений пользователя и сокращения количества шагов, необходимых для достижения цели (Task Completion). Система стремится автоматически выполнить следующий логический шаг за пользователя.
- Динамическая персонализация брендовой выдачи: Структура выдачи по брендовому (навигационному) запросу не является статической. Она изменяется в реальном времени на основе того, что пользователь искал непосредственно перед этим в рамках той же сессии.
- Важность глобальных поведенческих данных: Система полагается на Nav_Name List и Nav_Item List, которые строятся на основе анализа поведения миллионов пользователей. Это показывает, как Google структурирует данные о сайтах и их содержимом, опираясь на коллективное поведение.
- Строгая логика слияния результатов: Патент определяет четкую иерархию отображения (Priority Attributes). Главный результат сайта всегда остается на первом месте (Первый приоритет), но персонализированные результаты (Второй приоритет) имеют приоритет над вторичными ссылками сайта (Третий приоритет).
- Валидация связи «Элемент-Сайт»: Система не просто предполагает связь, она может проверять ее либо через каталоги (Claim 9), либо через подтвержденное поведение других пользователей (Claim 5), что снижает риск нерелевантных предсказаний.
Практика
Best practices (это мы делаем)
- Обеспечение четкого распознавания каталога (Для E-commerce и издателей): Необходимо гарантировать, что Google может легко идентифицировать и каталогизировать ваш контент и товары. Это повышает вероятность того, что они будут включены в Nav_Item List и/или Web Site Catalogs, и, следовательно, смогут отображаться через механизм Alternate Query. Используйте структурированные данные (Schema.org для Product/Article), XML Sitemaps и фиды (например, Google Merchant Center).
- Оптимизация под запросы «Элемент + Бренд»: Убедитесь, что ваши страницы хорошо ранжируются по запросам, включающим название элемента и название вашего бренда. Это способствует формированию устойчивой ассоциации в Nav_Item List на основе анализа поведения пользователей.
- Анализ точек входа по брендовым запросам: SEO-специалистам следует учитывать, что пользователи, ищущие бренд, могут попадать не только на главную страницу, но и напрямую на страницы конкретных товаров или статей, если они недавно интересовались этой темой. Это влияет на аналитику и оптимизацию конверсии.
- Укрепление навигационных сигналов бренда: Убедитесь, что ваш бренд четко распознается Google как Navigational Query (попадает в Nav_Name List). Это является базовым условием для активации механизма.
Worst practices (это делать не надо)
- Игнорирование структурированных данных о товарах/контенте: Отсутствие четкой разметки затрудняет для Google понимание вашего ассортимента, что снижает шансы на формирование Nav_Item List и использование этого механизма для вашего сайта.
- Сложная структура сайта и проблемы с индексацией: Если ключевые товары или статьи трудно найти, они плохо индексируются или генерируются динамически без четких URL, Google не сможет эффективно найти их при выполнении Alternate Query (аналог поиска с оператором site:).
- Неоднозначное брендирование: Использование общих терминов в качестве названия бренда может затруднить идентификацию запроса как навигационного именно к вашему сайту.
Стратегическое значение
Патент подтверждает использование Google персонализации на уровне сессии для модификации SERP в реальном времени с целью ускорения выполнения задач пользователем. Для крупных сайтов (E-commerce, медиа) это стратегически важный механизм, который может значительно увеличить видимость конкретных продуктов или контента во время брендовых поисков и ускорить путь пользователя к конверсии. Стратегия должна быть направлена на то, чтобы максимально предоставить Google данные о своем каталоге и способствовать формированию четких поведенческих паттернов у пользователей, связывающих ваш контент с вашим брендом.
Практические примеры
Сценарий: Оптимизация E-commerce сайта (Покупка электроники)
- Ситуация (Recent Queries): Пользователь ищет информацию о конкретной модели ноутбука. Запросы: «Обзор Macbook Air M3», «Сравнение цен Macbook Air M3».
- Навигационный запрос (Navigational Query, через 5 минут): Пользователь вводит «Best Buy».
- Действие системы: Google идентифицирует «Best Buy» как Nav_Name. Проверяет недавнюю историю. Видит «Macbook Air M3». Проверяет Nav_Item List или Web Site Catalog и подтверждает, что этот товар связан с сайтом Best Buy.
- Генерация Alternate Query: Система выполняет запрос Macbook Air M3 site:bestbuy.com.
- Результат (SERP по запросу «Best Buy»):
- Позиция 1 (Первый приоритет): BestBuy.com — Главная страница.
- Блок ниже (Второй приоритет): Прямые ссылки на страницы Macbook Air M3 на сайте BestBuy.com (результаты альтернативного запроса).
- Ниже (Третий приоритет): Вторичные ссылки Best Buy (Контакты, Категории и т.д.).
- Польза для SEO: Сайт Best Buy получил видимость конкретного товара и потенциально более быструю конверсию непосредственно из брендовой выдачи, направив пользователя сразу на глубокую страницу.
Вопросы и ответы
На какие типы сайтов этот патент влияет больше всего?
Наибольшее влияние оказывается на сайты с обширными каталогами товаров или контента, где пользователи часто ищут конкретные элементы. Это в первую очередь крупные E-commerce площадки (Amazon, eBay), видеохостинги (YouTube), энциклопедии (Wikipedia), базы данных (IMDb), сайты госуслуг (например, IRS) и крупные новостные издатели.
Как Google определяет, что запрос является навигационным (Nav_Name)?
Google анализирует глобальные логи поиска (Global Search Logs) и данные о кликах. Если по запросу «X» подавляющее большинство пользователей (в патенте упоминается пример более 60%) кликают на сайт X.com, то запрос «X» добавляется в Nav_Name List как навигационный для этого домена. Это основано на коллективном поведении пользователей.
Что такое Nav_Item List и как мой контент может туда попасть?
Nav_Item List — это список элементов (товаров, статей), которые Google ассоциирует с конкретным сайтом. Он формируется путем анализа запросов вида «Элемент Бренд» (например, «Air Max Nike»), по которым пользователи преимущественно кликают на сайт бренда. Чтобы ваш контент туда попал, он должен быть доступен для индексации, желательно размечен структурированными данными, и пользователи должны активно искать его в связке с вашим брендом.
Как долго Google помнит «недавние запросы» для этого механизма?
Патент предлагает несколько методов определения «недавности», основанных на границах сессии. В примерах реализации упоминаются такие пороги, как: не старше 30 минут, не более 4 последних запросов, или временной разрыв между запросами не более 10 минут. Это указывает на то, что механизм ориентирован на немедленный контекст поиска в рамках одной сессии.
Может ли результат альтернативного запроса появиться выше главного результата навигационного запроса?
Нет, согласно патенту (Claim 1), это исключено. Определена строгая иерархия приоритетов (Priority Attributes). Топовые навигационные результаты (например, главная страница) имеют Первый приоритет и всегда отображаются выше. Альтернативные результаты (например, ссылка на товар) имеют Второй приоритет и отображаются ниже главного результата.
Проверяет ли Google наличие товара на сайте перед тем, как показать альтернативные результаты?
Да, патент описывает это как шаг валидации. Система может использовать данные Nav_Item List (основанные на поведении пользователей, Claim 5) или сверяться с Web Site Catalogs (данные о контенте сайта, например, из фидов, Claim 9), чтобы подтвердить ассоциацию элемента с сайтом перед выполнением альтернативного запроса.
Является ли этот механизм формой персонализации?
Да, это форма персонализации на уровне сессии. Выдача изменяется на основе недавних действий конкретного пользователя. Однако валидация связи между элементом и сайтом (попадет ли элемент в Nav_Item List) зависит от глобальных данных о поведении всех пользователей.
Как этот патент связан с блоками Sitelinks (дополнительные ссылки сайта) в выдаче?
Этот механизм функционально похож на Sitelinks, так как предоставляет дополнительные ссылки на внутренние страницы сайта в брендовой выдаче. Однако, в отличие от стандартных Sitelinks, которые обычно основаны на структуре сайта или популярности разделов, ссылки, генерируемые этим механизмом (Alternate Query Search Results), полностью зависят от недавней истории поиска пользователя и генерируются в реальном времени для конкретной сессии.
Может ли этот механизм направлять пользователей на сайты конкурентов?
В описании патента (не в Claims) упоминается такая возможность. Если пользователь искал товар «Y», а затем ввел навигационный запрос «X1», система может также предложить поискать товар «Y» на сайтах «X2» и «X3», если все эти сайты сильно ассоциированы с товаром «Y» в Nav_Item List. Это расширяет возможности выбора для пользователя.
Как я могу оптимизировать свой сайт под этот механизм?
Ключевая стратегия – обеспечить, чтобы Google четко ассоциировал ваш контент с вашим брендом. Это достигается через оптимизацию страниц под запросы «Элемент + Бренд» для попадания в Nav_Item List, а также через предоставление точных данных о контенте через структурированную разметку и фиды для формирования Web Site Catalogs. Также критична идеальная индексация внутреннего контента.