SEO HARDCORE
  • Разборы патентов
    • Патенты Google
  • Скоро SEO инструменты
  • Скоро SEO аналитика
  • seohardcore
SEO HARDCORE
назад

Как Google объединяет разные стратегии и поведенческие данные для генерации и выбора лучших альтернативных запросов

INTEGRATION OF MULTIPLE QUERY REVISION MODELS (Интеграция нескольких моделей пересмотра запросов)
  • US7565345B2
  • Google LLC
  • 2005-03-29
  • 2009-07-21
  • Поведенческие сигналы
  • SERP
  • Описание
  • Разбор
  • Выводы
  • Практика
  • FAQ
  • Похожие

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

Описание

Какую проблему решает

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

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

Запатентована архитектура системы поиска, которая интегрирует несколько независимых модулей пересмотра запросов (Query Revisers), каждый из которых реализует свою стратегию. Центральный компонент, Сервер пересмотра (Revision Server), координирует работу этих модулей, собирает предложенные альтернативы, оценивает их на основе показателя уверенности (Confidence Measure) и критериев разнообразия, и выбирает лучшие варианты. Ключевой особенностью является использование поведенческих данных для оценки качества ревизий и метод презентации альтернатив с превью результатов.

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

Система работает следующим образом:

  • Оркестрация: Revision Server получает исходный запрос и параллельно рассылает его различным Query Revisers (модулям расширения, уточнения, синтаксиса, анализа сессий).
  • Генерация и Оценка: Каждый модуль возвращает потенциальные пересмотренные запросы с ассоциированным Confidence Measure. Эта мера может рассчитываться динамически на основе предсказательных моделей и логов поведения пользователей (например, вероятности длинного клика).
  • Сортировка и Фильтрация: Revision Server сортирует предложения по уверенности и применяет жесткие фильтры: наличие минимального числа результатов и наличие «новых» результатов (обеспечение разнообразия).
  • Презентация: Лучшие пересмотренные запросы представляются пользователю. Патент описывает интерфейс, где альтернативы показываются (часто на отдельной странице) вместе с превью их топовых результатов.

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

Высокая. Архитектура, описанная в патенте, является фундаментальной для современных функций поиска, таких как «Связанные запросы» (Related Searches) и «Люди также ищут» (People Also Ask). Хотя конкретные алгоритмы внутри Query Revisers эволюционировали (например, с использованием нейронных сетей), сам принцип интеграции множества моделей, оценки уверенности на основе поведенческих сигналов (long clicks) и обеспечения разнообразия предложений остается стандартом.

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

Патент имеет высокое значение (8.5/10) для SEO. Он описывает механизмы, с помощью которых Google понимает взаимосвязи между запросами и активно направляет пользователей по альтернативным путям поиска. Понимание того, как генерируются эти альтернативы (особенно через анализ сессий и метрики удовлетворенности кликов), критически важно для построения тематического авторитета и охвата всего пути пользователя (user journey), а не только оптимизации под изолированные ключевые слова.

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

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

Broadening Reviser (Модуль расширения запроса)
Query Reviser, генерирующий менее специфичные запросы. Стратегии: добавление синонимов/связанных терминов или удаление маловажных терминов.
Confidence Measure (Показатель уверенности)
Метрика, представляющая вероятность того, что пересмотренный запрос лучше отражает информационную потребность пользователя, чем исходный. Используется для сортировки и отбора альтернатив.
Expected Utility (Ожидаемая полезность)
Метрика для Session-Based Reviser. Рассчитывается как произведение частоты перехода от исходного запроса к пересмотренному и улучшения Quality Score.
Long Click (Длинный клик)
Клик на результат, после которого пользователь остается на странице в течение значительного времени (например, 60 секунд). Используется как индикатор удовлетворенности пользователя.
"New" Results («Новые» результаты)
Результаты в выдаче пересмотренного запроса, которые отсутствуют в топе исходной выдачи или в топе ранее выбранных альтернатив. Используются как критерий обеспечения разнообразия (diversity).
Quality Score (Оценка качества запроса)
Метрика, оценивающая удовлетворенность пользователя результатами запроса. Рассчитывается на основе предполагаемой продолжительности кликов (Long Clicks).
Query Pair (Пара запросов)
Последовательность двух запросов (Q1, Q2), введенных пользователем в рамках одной сессии.
Query Reviser (Модуль пересмотра запросов)
Компонент, реализующий определенную стратегию пересмотра запросов и генерирующий альтернативные запросы.
Refinement Reviser (Модуль уточнения запроса)
Query Reviser, генерирующий более специфичные (узкие) запросы.
Reviser Confidence Estimator (Оценщик уверенности ревизий)
Компонент, использующий предиктивную модель (например, логистическую регрессию), обученную на исторических данных о кликах, для динамического расчета Confidence Measures путем предсказания вероятности Long Click.
Revision Server (Сервер пересмотра)
Центральный компонент, который координирует работу Query Revisers, собирает, оценивает, фильтрует и выбирает лучшие пересмотренные запросы.
Session-Based Reviser (Модуль пересмотра на основе сессий)
Query Reviser, использующий исторические данные о Query Pairs для предложения альтернатив на основе того, что другие пользователи искали дальше.
Syntactical Reviser (Модуль синтаксического пересмотра)
Query Reviser, вносящий синтаксические изменения (добавление/удаление кавычек, обработка стоп-слов, удаление пунктуации).

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

Claim 1 (Независимый пункт): Описывает основной метод работы системы интеграции и презентации.

  1. Генерация пересмотренных запросов для исходного запроса с использованием различающихся стратегий.
  2. Вычисление Confidence Measure для каждого пересмотренного запроса на основе частоты встречаемости пары запросов (исходного и пересмотренного). (Примечание: Хотя в описании патента обсуждаются и другие методы расчета уверенности, Claim 1 фокусируется именно на частоте пар, что характерно для Session-Based Reviser).
  3. Сравнение показателей уверенности.
  4. Автоматический выбор подмножества пересмотренных запросов на основе сравнения.
  5. Оценка результатов поиска и выбор подмножества этих результатов (для предпросмотра).
  6. Предоставление исходных результатов на первой веб-странице.
  7. Предоставление одновременного отображения выбранных пересмотренных запросов и их результатов предпросмотра на второй веб-странице.

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

Claim 4 (Зависимый): Уточняет, что автоматический выбор включает сортировку пересмотренных запросов по Confidence Measure для создания рейтинга.

Claim 6 (Зависимый): Детализирует критерии выбора пересмотренных запросов. Выбор происходит, если:

  • Результаты поиска содержат минимальное количество результатов.
  • Результаты поиска содержат минимальное количество "New" Results (не присутствующих в исходной выдаче или в уже выбранных альтернативах) – это критерий разнообразия.
  • Общее количество выбранных запросов не превышает максимум.

Claim 14 (Зависимый): Детализирует метод расчета частоты встречаемости (используемой в Claim 1). Он включает анализ данных пользовательских сессий для подсчета индивидуальных запросов и пар запросов, и вычисление частоты как отношения количества пар к количеству исходных запросов.

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

Изобретение применяется на этапах понимания запроса и формирования финальной выдачи.

QUNDERSTANDING – Понимание Запросов
Это основной этап применения. Revision Server координирует работу различных Query Revisers для генерации альтернативных формулировок, которые могут лучше соответствовать намерению пользователя. Это включает семантический, синтаксический и поведенческий анализ. Также включает офлайн-процессы: анализ логов для обучения Session-Based Reviser и Reviser Confidence Estimator.

RANKING – Ранжирование
Система выполняет ранжирование для потенциальных пересмотренных запросов. Это необходимо Revision Server для получения результатов, чтобы оценить их качество и разнообразие (проверка "New" Results) перед финальным выбором.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
На этом этапе принимается решение о том, как представить выбранные альтернативные запросы пользователю (например, в блоке «Related Searches» или на отдельной странице) и насколько заметно это сделать, основываясь на Confidence Measure.

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

  • Исходный запрос пользователя.
  • Исторические данные (Log Files): логи сессий (Query Pairs), данные о кликах и их продолжительности.
  • Лингвистические данные: списки синонимов, списки фраз, стоп-слова.

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

  • Отсортированный список выбранных пересмотренных запросов.
  • Набор топовых результатов поиска для каждого выбранного запроса (предпросмотр).

На что влияет

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

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

  • Условия работы: Алгоритм генерации альтернатив применяется при обработке большинства пользовательских запросов.
  • Триггеры активации и презентации: Решение о показе альтернатив пользователю зависит от Confidence Measure.
    • Если ни одно предложение не превышает минимальный порог уверенности, альтернативы могут не показываться.
    • Если уверенность очень высока, альтернатива может быть показана очень заметно (например, вверху страницы).
    • При средней уверенности может быть показана ссылка на отдельную страницу или блок внизу выдачи.

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

Процесс обработки запроса сервером пересмотра (Revision Server)

  1. Инициализация: Получение исходного запроса (параллельно с отправкой в основной Search Engine).
  2. Генерация кандидатов (Fan-out): Параллельная отправка запроса всем сконфигурированным Query Revisers (Broadening, Syntactical, Refinement, Session-Based и т.д.).
  3. Сбор и Расчет Уверенности: Получение от каждого модуля списка потенциальных пересмотренных запросов. Для каждого рассчитывается Confidence Measure (статически, через Expected Utility или динамически через Reviser Confidence Estimator).
  4. Сортировка: Сортировка всех полученных предложений по Confidence Measure от высокого к низкому.
  5. Итеративная оценка и выбор: Обработка списка сверху вниз:
    1. Получение результатов: Запрос результатов поиска для текущего кандидата у Search Engine.
    2. Фильтрация по наличию результатов: Проверка, возвращает ли запрос минимальное количество результатов (например, > 0). Если нет, отбросить.
    3. Фильтрация по разнообразию (Diversity): Проверка, содержит ли топ результатов минимальное количество "New" Results (например, > 2), которые не присутствуют в топе исходного запроса или в топе уже выбранных альтернативных запросов. Если нет, отбросить.
    4. Выбор: Если фильтры пройдены, выбрать этот пересмотренный запрос.
    5. Проверка лимита: Если достигнуто максимальное количество выбранных запросов (например, 4), прекратить обработку.
  6. Форматирование и предоставление: Создание страницы (или блока) с выбранными запросами и их топовыми результатами для предпросмотра. Предоставление этой информации пользователю.

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

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

Система использует разнообразные данные, в зависимости от типа активных Query Revisers:

  • Поведенческие факторы (Ключевые):
    • Логи сессий (Session Logs / Log Files): Используются Session-Based Reviser для идентификации Query Pairs. Также используются Session Tracker для сбора данных.
    • Данные о кликах (Click Data / Click-through behavior): Используются для расчета Quality Score и обучения Reviser Confidence Estimator.
    • Продолжительность клика (Click Duration / Length of click): Предполагаемая продолжительность взаимодействия пользователя с результатом. Long Clicks используются как ключевой индикатор удовлетворенности.
  • Контентные/Лингвистические факторы:
    • Списки синонимов/Тезаурусы: Используются Broadening Reviser.
    • Списки фраз (Phrase Lists) и N-граммы: Используются Syntactical Reviser для определения фраз, которые стоит заключить в кавычки.
    • Списки стоп-слов: Используются Syntactical Reviser для принудительного включения (например, через оператор "+").
    • Списки имен и фамилий: Используются для идентификации имен собственных.

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

  • Confidence Measure (Показатель уверенности): Оценка вероятности успеха пересмотренного запроса. Методы расчета:
    • Статический: Заранее заданные значения для стратегии.
    • Expected Utility: Для Session-Based Reviser.
    • Динамический (Predictive Model): Использование модели машинного обучения (например, логистической регрессии) в Reviser Confidence Estimator для предсказания вероятности «длинного клика» на основе признаков запросов.
  • Quality Score (Оценка качества запроса): Оценка удовлетворенности результатами. Рассчитывается на основе продолжительности кликов. Патент описывает S-образную кривую (например, 20 сек = 0.1, 40 сек = 0.5, 60 сек = 0.9).
  • Expected Utility (Ожидаемая полезность): Формула: Frequency(Q1→Q2)∗(QualityScore(Q2)−QualityScore(Q1))Frequency(Q1 \to Q2) * (QualityScore(Q2) - QualityScore(Q1)).
  • Частота перехода (Frequency of Occurrence): Рассчитывается как отношение количества сессий, где за запросом Q1 следовал запрос Q2, к общему количеству сессий с запросом Q1.
  • Критерии фильтрации: Пороги для минимума результатов (например, 1), минимума "New" Results (например, 2) и максимума предложений (например, 4).

Выводы

  1. Интеграция множества стратегий: Google не полагается на один метод улучшения запросов. Система использует расширяемую архитектуру (Revision Server) для одновременного применения и сравнения результатов работы различных стратегий (семантических, синтаксических, поведенческих).
  2. Ранжирование предложений по уверенности (Confidence): Все сгенерированные альтернативы оцениваются с помощью Confidence Measure. Этот показатель может рассчитываться сложными методами, включая ML-модели, прогнозирующие удовлетворенность пользователя.
  3. Критическая роль поведенческих данных и удовлетворенности: Удовлетворенность пользователя (Quality Score), измеряемая через продолжительность кликов (Long Clicks), является центральной метрикой. Она используется для расчета Expected Utility и обучения моделей предсказания уверенности.
  4. Обеспечение разнообразия (Diversity) как жесткое требование: Система применяет строгий фильтр: альтернативный запрос выбирается, только если он приносит "New" Results, отличные от исходной выдачи. Это максимизирует охват интентов.
  5. Важность данных о сессиях: Анализ того, что пользователи ищут сразу после текущего запроса (Session-Based Reviser и Query Pairs), является сильным сигналом для генерации релевантных альтернатив.
  6. Контекстное представление: Патент подчеркивает важность показа альтернативных запросов вместе с их результатами (предпросмотр), чтобы пользователь мог оценить релевантность предложения до клика.

Практика

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

  • Анализ «Related Searches» и «People Also Ask»: Активно изучайте, какие альтернативные запросы предлагает Google для ваших целевых кластеров. Это прямой результат работы подобной системы. Это помогает выявить, как Google соединяет темы на основе реальных сессий (Session-Based Reviser) и какие смежные интенты он считает релевантными.
  • Построение тематического авторитета и охват User Journey: Создавайте контент, который охватывает не только основной запрос, но и те запросы, к которым пользователи часто переходят в рамках одной сессии (Query Pairs). Это увеличивает релевантность сайта для всего пути пользователя.
  • Оптимизация под удовлетворенность пользователя (Long Clicks): Поскольку Quality Score (удовлетворенность) измеряется через продолжительность кликов и используется для валидации альтернативных запросов, крайне важно создавать контент, который полностью отвечает на интент пользователя и удерживает его внимание, избегая «pogo-sticking».
  • Использование широкого семантического ядра (Синонимы и Фразы): Учитывайте работу Broadening Reviser (добавление синонимов) и Syntactical Reviser (идентификация фраз). Включайте релевантные синонимы и естественные словосочетания в контент, чтобы соответствовать различным вариантам пересмотренных запросов.

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

  • Фокус на изолированных ключевых словах: Оптимизация страницы только под одну точную формулировку запроса без учета смежных тем и следующих шагов пользователя. Система может предложить пользователю альтернативный запрос, который уведет его на другой ресурс, лучше покрывающий тему целиком.
  • Создание контента, ведущего к быстрым отказам (Short Clicks): Если контент не удовлетворяет пользователя, это снижает Quality Score для связанных запросов. Это негативно скажется на том, как часто система будет считать эти запросы (и ваш контент) полезными для пользователей.
  • Игнорирование широкого или узкого интента: Создание контента, который не учитывает возможности как расширения, так и сужения темы. Необходимо соответствовать как работе Refinement Reviser (уточнения), так и Broadening Reviser (обобщения).

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

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

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

Сценарий: Охват пути пользователя при поиске продукта

  1. Исходный запрос пользователя: [кроссовки Nike]. Запрос слишком широкий.
  2. Активация системы: Revision Server запрашивает альтернативы.
  3. Работа Revisers:
    • Refinement Reviser предлагает уточнения: [кроссовки Nike Air Max], [кроссовки Nike для бега].
    • Session-Based Reviser анализирует логи и видит, что пользователи часто переходят к запросу [сравнение Nike и Adidas] или [отзывы о Nike Pegasus] с высокой Expected Utility.
  4. Выбор и представление: Система выбирает [кроссовки Nike Air Max] и [отзывы о Nike Pegasus] как наиболее уверенные и разнообразные предложения и показывает их в блоке «Related Searches».
  5. Действия SEO-специалиста: Для успешного ранжирования недостаточно иметь общую страницу категории. Необходимо также иметь:
    1. Оптимизированные страницы подкатегорий/продуктов (Air Max, Pegasus).
    2. Контент, отвечающий на информационные и сравнительные интенты (отзывы, сравнения).
    3. Обеспечить высокий Quality Score (длинные клики) на этих страницах.
  6. Ожидаемый результат: Сайт появляется в выдаче на разных этапах поиска пользователя, захватывая трафик как по общим, так и по уточненным и связанным запросам.

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

Что такое Revision Server и какова его роль?

Revision Server — это центральный координатор в архитектуре пересмотра запросов. Его роль заключается в том, чтобы получить исходный запрос, разослать его различным модулям пересмотра (Query Revisers), собрать сгенерированные ими предложения, оценить их с помощью Confidence Measure, отфильтровать по критериям качества и разнообразия, и выбрать лучшие альтернативы для показа пользователю.

Какие основные стратегии пересмотра запросов описаны в патенте?

Патент описывает четыре основных типа модулей: Broadening Reviser (расширение запроса, например, добавление синонимов), Syntactical Reviser (синтаксические изменения, например, обработка кавычек или стоп-слов), Refinement Reviser (уточнение запроса, сужение темы) и Session-Based Reviser (предложения на основе того, что пользователи искали дальше в рамках одной сессии).

Как система решает, какое из множества предложений лучшее?

Система использует многоступенчатый отбор. Сначала предложения сортируются по Confidence Measure (Показателю уверенности). Затем для лучших кандидатов применяются жесткие фильтры: предложение должно возвращать достаточное количество результатов и привносить "New" Results (критерий разнообразия), которых нет в исходной выдаче.

Что такое «Новые результаты» ("New" Results) и почему они важны?

"New" Results — это документы в топе выдачи альтернативного запроса, которые отсутствуют в топе выдачи исходного запроса или других выбранных альтернатив. Это требование гарантирует разнообразие (diversity) предложений, максимизируя вероятность того, что хотя бы одна из предложенных альтернатив окажется полезной для пользователя и расширит его поиск, а не покажет то же самое.

Как работает Session-Based Reviser и почему он важен для SEO?

Он анализирует исторические логи сессий, чтобы найти частые пары запросов (Q1 -> Q2). Затем он рассчитывает Expected Utility для Q2, учитывая частоту перехода и улучшение удовлетворенности пользователя (Quality Score). Для SEO это критически важно, так как дает понимание реального пути пользователя (User Journey) и того, какие запросы Google считает тесно связанными на практике, что необходимо учитывать при кластеризации семантики.

Как измеряется удовлетворенность пользователя (Quality Score)?

В патенте предлагается измерять Quality Score на основе предполагаемой продолжительности кликов по результатам поиска. Длинные клики (Long Clicks) интерпретируются как признак удовлетворенности пользователя контентом. Это напрямую связано с SEO-практиками по улучшению поведенческих факторов и оптимизации под интент.

Может ли система динамически рассчитывать Confidence Measure?

Да. Патент описывает Reviser Confidence Estimator. Это модуль, который использует модель машинного обучения (например, логистическую регрессию), обученную на исторических данных о кликах. Эта модель может динамически предсказывать вероятность того, что конкретный пересмотренный запрос приведет к «длинному клику», тем самым определяя Confidence Measure на лету.

Как этот патент связан с блоком «Похожие запросы» (Related Searches)?

Описанная архитектура является базовой системой для реализации функций типа «Related Searches». Различные ревизоры, особенно Session-Based Reviser и Refinement Reviser, генерируют кандидатов, которые затем фильтруются по качеству, уверенности и разнообразию и отображаются в этом блоке.

Обязательно ли альтернативные запросы показываются на отдельной странице?

Патент описывает это как предпочтительный вариант (и защищает его в Claim 1), поскольку это позволяет показать альтернативные запросы вместе с их топовыми результатами (предпросмотр), не перегружая основную страницу выдачи. Однако также упоминается возможность показа альтернатив и на основной странице, если Confidence Measure очень высок.

Что такое «Ожидаемая полезность» (Expected Utility)?

Это метрика, используемая Session-Based Reviser. Она рассчитывается как произведение частоты, с которой пользователи переходят от Запроса А к Запросу Б, на разницу в качестве (Quality Score) между Запросом Б и Запросом А. Это позволяет сбалансировать популярность перехода и его реальную пользу для удовлетворенности пользователя.

Похожие патенты

Как Google использует данные о поведении пользователей и длительность кликов для улучшения и переписывания поисковых запросов
Google использует систему для автоматического переписывания запросов пользователей. Система анализирует миллионы прошлых поисковых сессий, чтобы определить, как пользователи уточняли свои запросы и насколько они были удовлетворены результатами (измеряя длительность кликов). На основе этого рассчитывается «Ожидаемая полезность» (Expected Utility) для предложенных вариантов запросов, что позволяет Google предлагать пользователю те формулировки, которые с наибольшей вероятностью приведут к качественному ответу.
  • US7617205B2
  • 2009-11-10
  • Поведенческие сигналы

  • Семантика и интент

  • SERP

Как Google генерирует связанные запросы (Related Searches), используя сущности из топовых результатов и сохраняя структуру исходного запроса
Google использует систему для автоматической генерации уточнений запросов (например, «Связанные запросы»). Система анализирует топовые документы в выдаче и извлекает из них ключевые сущности. Затем эти сущности комбинируются с важными терминами исходного запроса, при этом строго сохраняется исходный порядок слов, чтобы создать релевантные и естественно звучащие предложения для дальнейшего поиска.
  • US8392443B1
  • 2013-03-05
  • Семантика и интент

  • Поведенческие сигналы

Как Google использует обучение с подкреплением (Reinforcement Learning) для оптимизации ранжирования и переписывания запросов на основе успешности поисковых сессий
Google использует систему Reinforcement Learning для динамической адаптации поисковых процессов. Система анализирует поисковые сессии (последовательности запросов и кликов) и учится оптимизировать выдачу, чтобы пользователь быстрее находил нужный результат. Это достигается путем корректировки весов факторов ранжирования, переписывания запросов или даже обновления индекса на лету для конкретных ситуаций.
  • US11157488B2
  • 2021-10-26
  • Индексация

  • Поведенческие сигналы

  • Семантика и интент

Как Google выбирает предлагаемые запросы, анализируя вероятность завершения поиска и коммерческую ценность
Google использует графовую модель для анализа поисковых сессий пользователей. Система определяет, какие уточняющие запросы чаще всего приводят к завершению поиска (становятся «финальным пунктом назначения»). Эти запросы считаются обладающими наибольшей «полезностью» (Utility) и предлагаются пользователю в качестве подсказок или связанных запросов. Система также учитывает коммерческий потенциал этих запросов и может показывать для них релевантные рекламные блоки.
  • US8751520B1
  • 2014-06-10
  • SERP

  • Поведенческие сигналы

  • Семантика и интент

Как Google агрегирует поведенческие данные из похожих запросов для ранжирования редких и длиннохвостых запросов
Google использует механизм обобщения запросов для улучшения ранжирования, особенно когда исторических данных по исходному запросу недостаточно. Система создает варианты запроса (удаляя стоп-слова, используя синонимы, стемминг или частичное совпадение) и агрегирует данные о поведении пользователей (клики, dwell time) из этих вариантов. Это позволяет оценить качество документа для исходного запроса, используя статистику из семантически близких запросов.
  • US9110975B1
  • 2015-08-18
  • Поведенческие сигналы

  • Семантика и интент

  • SERP

Популярные патенты

Как Google персонализирует поисковые подсказки (Autocomplete) на основе недавно просмотренного медиаконтента
Google использует информацию о недавно потребленном пользователем медиаконтенте (видео, аудио, книги, игры) для персонализации поисковых подсказок. Система извлекает атрибуты (аспекты) из этого контента, такие как названия, имена актеров или артистов, и повышает в ранжировании те подсказки, которые соответствуют этим атрибутам. Влияние потребления медиа на подсказки зависит от времени, прошедшего с момента просмотра, типа контента и того, делился ли им пользователь.
  • US9268880B2
  • 2016-02-23
  • Персонализация

  • Семантика и интент

  • Мультимедиа

Как Google ранжирует сущности (книги, фильмы, людей), анализируя тематичность и авторитетность их упоминаний в вебе
Google использует механизм для оценки значимости конкретных сущностей (например, изданий книг или фильмов). Система анализирует, как эти сущности упоминаются на релевантных веб-страницах, учитывая уверенность распознавания (Confidence) и то, насколько страница посвящена именно этой сущности (Topicality). Эти сигналы агрегируются с учетом авторитетности и релевантности страниц для расчета итоговой оценки сущности, которая затем корректирует ее ранжирование в поиске.
  • US20150161127A1
  • 2015-06-11
  • Семантика и интент

  • EEAT и качество

  • SERP

Как Google использует ссылки, которыми делятся в почте, блогах и мессенджерах, как сигнал для корректировки ранжирования
Google запатентовал механизм (User Distributed Search), который учитывает, как пользователи делятся ссылками в коммуникациях (почта, блоги, мессенджеры). Если автор включает ссылку в сообщение, это дает ей первоначальную модификацию в ранжировании. Если получатели переходят по этой ссылке, её Ranking Score увеличивается ещё больше. Оба сигнала используются для влияния на позиции документа в будущей выдаче.
  • US8862572B2
  • 2014-10-14
  • Поведенческие сигналы

  • Ссылки

Как Google использует офлайн-сигналы и авторитетность сущностей для ранжирования контента
Google использует реальные, офлайн-сигналы авторитетности для ранжирования документов, у которых отсутствует естественная ссылочная структура (например, оцифрованные книги). Система оценивает коммерческий успех документа (данные о продажах, списки бестселлеров), репутацию связанных сущностей (автора и издателя) и может переносить ссылочный авторитет с официальных сайтов этих сущностей на сам документ для улучшения его позиций в поиске.
  • US8799107B1
  • 2014-08-05
  • EEAT и качество

  • SERP

  • Поведенческие сигналы

Как Google использует поведение пользователей в веб-поиске для динамической категоризации локальных бизнесов
Google динамически формирует категории для бизнесов, основываясь на том, как пользователи ищут их (используемые ключевые слова и клики) в веб-поиске и голосовом поиске. Эти данные формируют иерархическое понимание типов бизнеса. Эта структура затем используется для повышения точности распознавания названий компаний в голосовых запросах.
  • US8041568B2
  • 2011-10-18
  • Local SEO

  • Поведенческие сигналы

  • Семантика и интент

Как Google использует данные о наведении курсора (Hover Data) для ранжирования изображений и борьбы с кликбейтными миниатюрами
Google использует данные о взаимодействии пользователя с миниатюрами в поиске по картинкам (наведение курсора) как сигнал интереса. Для редких запросов эти сигналы получают больший вес, дополняя недостаток данных о кликах. Система также вычисляет соотношение кликов к наведениям (Click-to-Hover Ratio), чтобы идентифицировать и понижать в выдаче «магниты кликов» — привлекательные, но нерелевантные изображения, которые собирают много наведений, но мало кликов.
  • US8819004B1
  • 2014-08-26
  • Поведенческие сигналы

  • Мультимедиа

  • SERP

Как Google использует близость цитирований (ссылок) для кластеризации результатов поиска
Google может группировать результаты поиска, анализируя, как документы ссылаются друг на друга. Система оценивает силу связи между документами, проверяя контекстуальную близость общих цитирований. Ссылки, расположенные в одном предложении (co-citation) или абзаце, имеют значительно больший вес, чем ссылки, просто присутствующие в документе. Это позволяет формировать точные тематические кластеры, отсеивая группы со слабыми связями.
  • US8612411B1
  • 2013-12-17
  • Ссылки

  • SERP

Как Google консолидирует сигналы ранжирования между мобильными и десктопными версиями страниц, используя десктопный авторитет для мобильного поиска
Патент Google описывает механизм для решения проблемы недостатка сигналов ранжирования в мобильном вебе. Система идентифицирует корреляцию между мобильной страницей и её десктопным аналогом. Если мобильная версия недостаточно популярна сама по себе, она наследует сигналы ранжирования (например, обратные ссылки и PageRank) от авторитетной десктопной версии, улучшая её позиции в мобильном поиске.
  • US8996514B1
  • 2015-03-31
  • Техническое SEO

  • Ссылки

Как Google нормализует поведенческие сигналы (Dwell Time), калибруя показатели «короткого» и «длинного» клика для разных категорий сайтов
Google использует механизм для устранения предвзятости в поведенческих сигналах, таких как продолжительность клика (Dwell Time). Поскольку пользователи взаимодействуют с разными типами контента по-разному, система определяет, что считать «коротким кликом» и «длинным кликом» отдельно для каждой категории (например, Новости, Недвижимость, Словари). Это позволяет более точно оценивать качество ресурса, сравнивая его показатели с нормами его конкретной ниши.
  • US8868565B1
  • 2014-10-21
  • Поведенческие сигналы

  • SERP

Как Google использует данные сессий и разнообразие результатов для генерации блока "Связанные запросы"
Google анализирует поисковые сессии пользователей, чтобы найти запросы, которые часто следуют за одним и тем же предшествующим запросом (родственные запросы). Затем система фильтрует эти потенциальные "Связанные запросы", чтобы убедиться, что они предлагают разнообразные результаты по сравнению с исходным запросом и другими предложениями, помогая пользователям исследовать смежные, но отличные темы.
  • US8244749B1
  • 2012-08-14
  • Семантика и интент

  • Персонализация

  • Поведенческие сигналы

seohardcore