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

Описание

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

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

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

Запатентована система и метод для генерации и оценки пересмотренных запросов. Ключевым элементом является механизм расчета Expected Utility (Ожидаемой полезности) для предложенного запроса. Этот расчет базируется на анализе исторических данных поисковых сессий (session data): как часто пользователи переходили от исходного запроса к предложенному и насколько улучшалось качество результатов (измеряемое через удовлетворенность пользователей, например, длительность кликов).

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

Система работает в двух основных режимах:

  1. Архитектура ревизии: Front-End Server получает запрос и передает его на Revision Server. Тот опрашивает различные модули ревизии (Query Revisers), такие как модули расширения, сужения, синтаксического анализа и сессионный модуль. Каждый модуль возвращает потенциальные пересмотренные запросы с оценкой уверенности (Confidence Measure). Revision Server выбирает лучшие варианты, проверяет их результаты и предоставляет пользователю.
  2. Сессионная ревизия (Основной фокус патента): Session-Based Reviser анализирует логи сессий, выявляя частые пары запросов (Q1 -> Q2). Для каждой пары рассчитывается Quality Score (на основе длительности кликов по результатам). Затем вычисляется Expected Utility как произведение частоты перехода (Q1->Q2) на прирост качества (Score(Q2) - Score(Q1)). Это позволяет предлагать запросы, которые статистически чаще приводят к удовлетворенности пользователя.

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

Высокая. Понимание намерений пользователя и автоматическое улучшение запросов являются центральными задачами поиска. Использование поведенческих данных (сессий, кликов, удовлетворенности) для переписывания запросов (Query Revision) и формирования блоков типа «Похожие запросы» или «Люди также ищут» остается критически важным компонентом современных поисковых систем.

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

Патент имеет критическое значение (9/10) для SEO. Он раскрывает конкретный механизм, как Google использует агрегированные поведенческие данные для оценки качества результатов и понимания связей между запросами. Это подчеркивает важность не только привлечения клика, но и обеспечения полного удовлетворения пользователя (long clicks), так как это напрямую влияет на Quality Score, ассоциированный с запросом, и определяет, какие запросы Google будет предлагать в качестве альтернатив.

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

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

Client (Клиент)
Пользовательское устройство или приложение (например, браузер), отправляющее запрос.
Confidence Measure (Мера уверенности/достоверности)
Вероятностная оценка того, что пересмотренный запрос является хорошей ревизией и приведет к результатам, более релевантным информационной потребности пользователя, чем исходный запрос. Для сессионного ревизора эта мера равна Expected Utility.
Expected Utility (Ожидаемая полезность)
Ключевая метрика для оценки качества пересмотренного запроса (Q2) по отношению к исходному (Q1). Рассчитывается как произведение частоты перехода от Q1 к Q2 на прирост качества результатов Q2 по сравнению с Q1.
Front-End Server (Внешний сервер)
Сервер, принимающий запросы от клиентов и координирующий работу поисковой системы и сервера ревизий.
Log Files (Лог-файлы)
Хранилище данных о поисковых сессиях, включая последовательности запросов и клики пользователей (user click data).
Query Pair (Пара запросов)
Последовательность из двух запросов (Q1, Q2), введенных одним пользователем в рамках одной сессии.
Query Revisers (Модули ревизии запросов)
Набор модулей, каждый из которых реализует определенную стратегию пересмотра запросов (например, Broadening Reviser, Refinement Reviser, Syntactical Reviser, Session-Based Reviser).
Quality Score (Оценка качества)
Метрика удовлетворенности пользователя результатами поиска по определенному запросу. Рассчитывается на основе поведения пользователей, в частности, длительности кликов (duration of a click) по результатам.
Revised Query (Пересмотренный запрос)
Запрос, сгенерированный системой как альтернатива или улучшение исходного запроса пользователя.
Revision Server (Сервер ревизий)
Центральный компонент, который координирует работу различных Query Revisers, оценивает их предложения и выбирает лучшие пересмотренные запросы.
Reviser Confidence Estimator (Оценщик достоверности ревизий)
Модуль, использующий предиктивную модель (например, логистическую регрессию) для динамического расчета Confidence Measure на основе признаков исходного и пересмотренного запросов и исторических данных о кликах.
Session Tracker (Трекер сессий)
Компонент, отслеживающий действия пользователя в рамках сессии и сохраняющий их в Log Files.

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

Патент содержит два основных аспекта: общую архитектуру интеграции разных методов ревизии и конкретный метод сессионной ревизии с расчетом Expected Utility. Основные Claims сосредоточены на втором аспекте.

Claim 1 (Независимый пункт): Описывает метод предоставления пересмотренных запросов на основе сессионных данных и ожидаемой полезности.

  1. Система получает исходный запрос (Q1).
  2. Идентифицируются часто вводимые последующие запросы (Q2) из исторических данных сессий (session data) других пользователей.
  3. Определяется частота (frequency of occurrence) каждого Q2 как преемника Q1.
  4. Отбираются кандидаты, чья частота превышает первый порог (Threshold 1).
  5. Определяется Quality Score для Q1 и каждого кандидата Q2 на основе данных о кликах (user click data), которые показывают степень взаимодействия пользователей с результатами поиска.
  6. Отбираются улучшенные запросы (Q_imp), чей Quality Score выше, чем у Q1.
  7. Рассчитывается Expected Utility для каждого Q_imp путем умножения разницы в Quality Score (Q_imp - Q1) на частоту встречаемости (Q1 -> Q_imp).
  8. Предоставляется ссылка на результаты для тех Q_imp, чья Expected Utility превышает второй порог (Threshold 2).

Claim 4 (Зависимый от 1): Детализирует расчет Quality Score.

Оценка качества базируется на длительности первого клика по результату. Результату без клика присваивается оценка 0. Для результата с кликом оценка рассчитывается путем применения S-образной кривой к длительности клика (время между первым и последующим кликом). Более длительные клики получают оценку, приближающуюся к 1.

Claim 7 (Зависимый от 5 и 1): Уточняет измерение длительности клика.

Длительность клика измеряется как разница во времени между первым кликом на результат и последующим кликом пользователя.

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

Изобретение применяется на нескольких этапах поисковой архитектуры, в основном связанных с пониманием запроса и улучшением результатов.

CRAWLING & INDEXING
Напрямую не применяется, но система использует индекс для получения результатов как для исходных, так и для пересмотренных запросов.

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

  • Офлайн-обработку: Анализ Log Files с помощью Session Tracker для выявления пар запросов, расчета Quality Scores и предварительного вычисления Expected Utility. Также обучение предиктивной модели в Reviser Confidence Estimator.
  • Онлайн-обработку: Revision Server получает запрос от Front-End Server и координирует работу Query Revisers для генерации кандидатов в реальном времени, используя предварительно рассчитанные данные или динамическую оценку.

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

METASEARCH & RERANKING
На этих этапах система принимает решение о том, показывать ли пересмотренные запросы пользователю и в каком виде. Revision Server выбирает лучшие ревизии на основе Confidence Measures (включая Expected Utility) и критериев разнообразия результатов. Система может решить показать ссылку на отдельную страницу с ревизиями или интегрировать их в основную выдачу (например, блоки «Похожие запросы»).

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

  • Исходный запрос пользователя.
  • Исторические данные сессий (Log Files): последовательности запросов, клики, временные метки.
  • Признаки запросов (длина, слова, тематический кластер).

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

  • Набор пересмотренных запросов (Revised Queries).
  • Оценки уверенности (Confidence Measures) или Expected Utility для каждого пересмотренного запроса.
  • Результаты поиска для выбранных пересмотренных запросов (для предварительного просмотра).

На что влияет

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

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

  • Условия активации: Система генерации пересмотренных запросов активируется при получении запроса от пользователя.
  • Пороговые значения для сессионной ревизии:
    • Threshold 1 (Частота): Последующий запрос Q2 должен встречаться после Q1 с определенной минимальной частотой (в патенте упоминается пример 1%).
    • Threshold 2 (Expected Utility): Ожидаемая полезность перехода Q1->Q2 должна превышать минимальный порог (в патенте упоминается пример 0.02).
    • Прирост качества: Quality Score(Q2) должен быть выше, чем Quality Score(Q1).
  • Пороговые значения для общей архитектуры:
    • Confidence Measure должна быть достаточно высокой для показа ревизии.
    • Пересмотренный запрос должен давать минимальное количество результатов.
    • Пересмотренный запрос должен давать минимальное количество «новых» результатов по сравнению с исходным запросом (для обеспечения разнообразия).

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

Процесс А: Общая обработка ревизий (Архитектура)

  1. Получение запроса: Front-End Server получает запрос от Client и передает его Search Engine и Revision Server.
  2. Генерация кандидатов: Revision Server опрашивает все доступные Query Revisers (Broadening, Syntactical, Refinement, Session-Based).
  3. Получение ревизий и оценок: Каждый Reviser возвращает набор потенциальных пересмотренных запросов (R) с соответствующими мерами уверенности (C).
  4. Оценка уверенности (Опционально): Если используется динамическая оценка, Revision Server или Revisers обращаются к Reviser Confidence Estimator для расчета C на основе предиктивной модели.
  5. Сортировка и фильтрация: Revision Server сортирует все полученные ревизии по убыванию C.
  6. Валидация результатов: Revision Server итеративно обрабатывает список, отправляя запросы R в Search Engine и анализируя топ результатов.
  7. Отбор ревизий: Ревизия отбирается, если она удовлетворяет критериям: минимальное количество результатов, минимальное количество «новых» результатов (разнообразие), и общее количество отобранных ревизий не превышает максимум.
  8. Предоставление пользователю: Revision Server формирует список отобранных ревизий (и, возможно, превью результатов) и передает Front-End Server для показа пользователю.

Процесс Б: Сессионная ревизия и расчет Expected Utility (Фокус Claims)

  1. Сбор данных (Офлайн): Session Tracker записывает последовательности запросов и клики пользователей в Log Files.
  2. Анализ частотности (Офлайн): Система анализирует логи для выявления повторяющихся пар запросов (Q1, Q2) и рассчитывает частоту перехода F(Q1->Q2).
  3. Расчет Quality Score (Офлайн): Для каждого запроса Q рассчитывается Quality Score (S(Q)) на основе длительности кликов по его результатам (используя S-образную кривую).
  4. Получение исходного запроса (Онлайн): Пользователь вводит Q1.
  5. Поиск кандидатов: Session-Based Reviser ищет Q2, для которых F(Q1->Q2) превышает Threshold 1.
  6. Фильтрация по качеству: Отбираются кандидаты Q2, для которых S(Q2) > S(Q1).
  7. Расчет Expected Utility: Для оставшихся кандидатов рассчитывается EU = F(Q1->Q2) * (S(Q2) - S(Q1)).
  8. Фильтрация по полезности: Отбираются ревизии, для которых EU превышает Threshold 2.
  9. Предоставление результатов: Отобранные ревизии передаются Revision Server (в Процесс А, шаг 3).

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

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

Система в первую очередь полагается на поведенческие данные.

  • Поведенческие факторы (User Behavior):
    • Последовательности запросов (Query Sequences): Данные из Log Files о том, какие запросы пользователи вводят друг за другом в рамках одной сессии.
    • Данные о кликах (Click Data): Информация о том, на какие результаты пользователи кликают.
    • Временные метки кликов (Timestamps): Точное время каждого клика, используемое для расчета длительности взаимодействия с контентом.
  • Контентные/Системные факторы (используются в предиктивной модели Reviser Confidence Estimator):
    • Текст исходного и пересмотренного запросов.
    • Длина запросов.
    • Количество результатов для запросов.
    • Тематический кластер запросов (topic cluster).
    • Оценка ранжирования (information retrieval score, например, PageRank) для топовых результатов.
    • Идентификатор метода ревизии, сгенерировавшего запрос.

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

  • Frequency of Occurrence (Частота встречаемости): Доля сессий, в которых за запросом Q1 последовал запрос Q2.

Выводы

  1. Удовлетворенность пользователя (Long Clicks) как мера качества: Патент явно определяет Quality Score запроса через длительность кликов по результатам. Длительные клики (long clicks) интерпретируются как высокая удовлетворенность. Это подтверждает критическую важность поведенческих факторов, основанных на времени взаимодействия с контентом.
  2. Связи между запросами определяются поведением, а не только семантикой: Система выявляет связанные запросы не просто по схожести ключевых слов, а по тому, как пользователи реально переходят от одного запроса к другому в рамках одной сессии (Query Pairs).
  3. Баланс между частотностью и качеством (Expected Utility): Система не просто предлагает самый частый следующий запрос. Она взвешивает частоту перехода на прирост качества. Высокочастотный переход с низким приростом качества может проиграть менее частотному переходу, который дает значительное улучшение удовлетворенности.
  4. Гибкая архитектура для переписывания запросов: Google использует модульную систему (Revision Server и Query Revisers), которая позволяет тестировать и интегрировать различные стратегии улучшения запросов (расширение, сужение, синтаксис, сессии) и выбирать лучшую на основе Confidence Measure.
  5. Использование ML для предсказания успеха ревизии: Упоминание Reviser Confidence Estimator и использование логистической регрессии показывает, как Google применяет машинное обучение для предсказания вероятности того, что пользователь воспользуется предложенным запросом и будет удовлетворен им.

Практика

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

  • Оптимизация под удовлетворенность пользователя (Long Clicks): Сосредоточьтесь на создании контента, который полностью отвечает на запрос пользователя и удерживает его на странице для глубокого изучения. Это увеличивает вероятность long clicks, что повышает Quality Score, ассоциированный с запросами, ведущими на ваш сайт.
  • Анализ путей пользователя и последовательностей запросов: Изучайте, какие запросы приводят пользователей на ваш сайт и какие запросы они используют до и после этого (используя данные GSC, аналитику и анализ логов). Создавайте контент, который отвечает на эти последовательные информационные потребности.
  • Оптимизация под смежные интенты (Related Queries): Если ваш контент хорошо отвечает на запрос Q2, который часто следует за популярным запросом Q1, вы можете получить дополнительный трафик, когда Google предложит Q2 в качестве ревизии. Необходимо обеспечить высокое качество ответа на Q2, чтобы максимизировать Expected Utility.
  • Улучшение разнообразия и полноты контента: Поскольку система при выборе ревизий учитывает необходимость показа «новых» результатов (diversity), авторитетные сайты, широко освещающие тему, имеют больше шансов быть показанными в результатах пересмотренных запросов.

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

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

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

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

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

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

  1. Анализ сессий (Данные Google): Google видит, что пользователи часто вводят Q1: [как чистить кожаную обувь]. Затем 30% пользователей вводят Q2: [лучший крем для кожаной обуви].
  2. Анализ качества:
    • Результаты по Q1 имеют средний Quality Score 0.4 (клики около 35 секунд).
    • Результаты по Q2 имеют средний Quality Score 0.7 (клики около 50 секунд), так как обзоры продуктов более вовлекающие.
  3. Расчет Expected Utility: Прирост качества = 0.7 - 0.4 = 0.3. EU = 30% * 0.3 = 0.09. Это выше порога 0.02.
  4. Действие Google: Google будет активно предлагать запрос Q2 пользователям, которые ввели Q1.
  5. Действие SEO-специалиста:
    • Убедиться, что статья о чистке обуви (Q1) максимально полезна, чтобы увеличить ее собственный Quality Score.
    • Создать высококачественный обзор кремов (Q2) и связать его со статьей Q1.
    • Цель — стать лучшим результатом по Q2 с максимальным long click, чтобы закрепиться в выдаче, когда Google предлагает эту ревизию.

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

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

Expected Utility — это метрика, которую Google использует для оценки того, насколько полезным будет предложить пользователю пересмотренный запрос. Она рассчитывается путем умножения частоты, с которой пользователи переходят от запроса А к запросу Б, на прирост качества результатов запроса Б по сравнению с А. Для SEO это важно, потому что это показывает, что Google предпочитает те пути пользователя (последовательности запросов), которые ведут к наибольшему увеличению удовлетворенности.

Как Google измеряет «Quality Score» (Оценку качества) запроса согласно патенту?

Quality Score измеряется на основе удовлетворенности пользователя результатами, которая оценивается по длительности кликов (duration of clicks). Система использует S-образную кривую: короткие клики получают низкую оценку (например, 20 сек = 0.1), а длительные клики — высокую (например, 60 сек = 0.9). Если кликов нет, оценка равна 0. Это подчеркивает важность создания вовлекающего контента.

Означает ли это, что нужно искусственно затягивать время пребывания пользователя на странице?

Нет, это означает, что контент должен быть настолько качественным и релевантным, чтобы пользователь естественным образом тратил время на его изучение (long click). Искусственные методы удержания без предоставления ценности не приведут к удовлетворенности. Важно именно время активного взаимодействия, которое сигнализирует Google, что информационная потребность была удовлетворена.

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

Описанный механизм, особенно работа Session-Based Reviser и расчет Expected Utility, является вероятной основой для генерации предложений в блоках «Похожие запросы» или «Люди также ищут». Google предлагает те запросы, которые статистически доказали свою полезность для других пользователей, искавших исходный запрос.

Что такое «Query Pair» (Пара запросов) в контексте этого патента?

Query Pair — это два последовательных запроса (Q1, Q2), введенных одним и тем же пользователем в рамках одной поисковой сессии. Анализ этих пар позволяет Google понять, как пользователи естественным образом уточняют или изменяют свои информационные потребности в процессе поиска.

Система предлагает только самый частый следующий запрос?

Нет. Система балансирует частоту перехода и прирост качества. Если самый частый следующий запрос (Q2) дает лишь небольшое улучшение качества по сравнению с исходным (Q1), он может проиграть менее частотному запросу (Q3), который дает значительно больший прирост удовлетворенности (Quality Score).

Что такое «Reviser Confidence Estimator»?

Это компонент системы, который использует модель машинного обучения (например, логистическую регрессию) для предсказания вероятности того, что предложенный пересмотренный запрос окажется успешным (т.е. приведет к long click). Он анализирует различные признаки исходного и предложенного запросов для динамического расчета меры уверенности (Confidence Measure).

Как обеспечить разнообразие (Diversity) при предложении пересмотренных запросов?

Патент описывает механизм, при котором Revision Server проверяет результаты предложенных запросов. Чтобы ревизия была принята, она должна содержать минимальное количество «новых» результатов, которых не было в топе исходного запроса или в уже принятых ревизиях. Это гарантирует, что пользователю предлагаются разные варианты.

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

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

Как SEO-специалисту использовать эти знания в стратегии построения контента?

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

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

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

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

  • SERP

Как Google использует данные о кликах и пропусках для валидации и удаления неэффективных синонимов в поиске
Google постоянно тестирует правила подстановки (синонимы) для расширения запросов. Этот патент описывает механизм оценки эффективности этих правил с помощью анализа поведения пользователей (клики и пропуски результатов). Если пользователи часто пропускают результаты, содержащие подставленный термин, система автоматически удаляет это правило, очищая понимание запросов от нерелевантных синонимов.
  • US8965875B1
  • 2015-02-24

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

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

  • EEAT и качество

Как Google предсказывает ваш следующий запрос на основе контента, который вы просматриваете, и истории поиска других пользователей
Google использует систему контекстной информации, которая анализирует контент на экране пользователя (например, статью или веб-страницу) и предсказывает, что пользователь захочет искать дальше. Система не просто ищет ключевые слова на странице, а использует исторические данные о последовательностях запросов (Query Logs). Она определяет, что другие пользователи искали после того, как вводили запросы, связанные с текущим контентом, и предлагает эти последующие запросы в качестве рекомендаций.
  • US20210232659A1
  • 2021-07-29

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

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

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

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

  • Индексация

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

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

Как Google использует анализ сессий и CTR для переписывания низкоэффективных запросов в высокоэффективные
Google анализирует поведение пользователей внутри поисковых сессий. Если пользователь быстро переходит от запроса с низким CTR (низкоэффективный) к запросу с высоким CTR (высокоэффективный), система связывает их как относящиеся к одному интенту. В дальнейшем, при получении низкоэффективного запроса, Google использует связанный высокоэффективный запрос для поиска и подмешивания более релевантного контента.
  • US8234265B1
  • 2012-07-31

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

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

  • SERP

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

Как Google персонализирует Sitelinks и сниппеты, используя интересы пользователя и тренды для прямого перехода на нужные страницы
Google использует механизм для динамического обогащения результатов поиска, особенно при навигационных запросах. Система анализирует сущности (продукты, категории) на целевом сайте и сравнивает их с известными интересами пользователя и текущими трендами. При совпадении Google отображает персонализированные прямые ссылки (например, динамические Sitelinks) на эти конкретные разделы или товары прямо в выдаче.
  • US20140188927A1
  • 2014-07-03

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

  • SERP

  • Ссылки

Как Google модифицирует PageRank, используя модель «Разумного серфера» для взвешивания ссылок на основе вероятности клика
Google использует машинное обучение для прогнозирования вероятности клика по ссылкам на основе их характеристик (позиция, размер шрифта, анкор) и реального поведения пользователей. Эта модель («Разумный серфер») модифицирует алгоритм PageRank, придавая больший вес ссылкам, которые с большей вероятностью будут использованы, и уменьшая вес игнорируемых ссылок.
  • US7716225B1
  • 2010-05-11

  • Ссылки

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

  • SERP

Как Google определяет язык поискового запроса, используя язык интерфейса, статистику слов и поведение пользователей
Google использует вероятностную модель для точной идентификации языка поискового запроса. Система комбинирует три ключевых фактора: статистику частотности слов в разных языках, язык интерфейса пользователя (например, Google.fr) и исторические данные о том, на какие результаты пользователи кликали ранее. Это позволяет корректно обрабатывать многоязычные и неоднозначные запросы для применения правильных синонимов и стемминга.
  • US8442965B2
  • 2013-05-14

  • Мультиязычность

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

Как Google выявляет ссылочный спам (Link Farms и Web Rings), анализируя чувствительность PageRank к изменениям в структуре ссылок
Google использует математический метод для обнаружения искусственного завышения PageRank. Система анализирует, насколько резко меняется ранг страницы при изменении «коэффициента связи» (coupling factor/damping factor). Если ранг страницы слишком чувствителен к этим изменениям (имеет высокую производную), это сигнализирует о наличии манипулятивных структур, таких как ссылочные фермы или веб-кольца.
  • US7509344B1
  • 2009-03-24

  • Антиспам

  • Ссылки

  • Техническое SEO

Как Google использовал специальные токены в запросе (например, «+») для прямой навигации на верифицированные социальные страницы в обход SERP
Google может интерпретировать специальные токены в поисковом запросе (например, «+») как намерение пользователя найти официальную социальную страницу сущности. Если система идентифицирует верифицированный профиль, соответствующий запросу с высокой степенью уверенности, она может перенаправить пользователя прямо на эту страницу, минуя стандартную поисковую выдачу.
  • US9275421B2
  • 2016-03-01

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

  • SERP

  • Ссылки

Как Google определяет связанность документов с использованием Co-citation, анализа текста вокруг ссылок и паттернов пользовательского доступа
Google использует методы для ограничения результатов поиска на основе заданного контекста (например, набора URL-адресов или категории). Патент детализирует, как система определяет «связанность» между документами, используя такие методы, как анализ совместного цитирования (co-citation), анализ текста, окружающего ссылки в цитирующих документах, и анализ корреляции паттернов доступа пользователей.
  • US7305380B1
  • 2007-12-04

  • Ссылки

  • SERP

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

Как Google использует контекст внешних страниц для понимания и идентификации видео и аудио контента
Google анализирует внешние веб-страницы, которые ссылаются на медиафайлы или встраивают их (например, видео YouTube). Система извлекает метаданные из контекста этих страниц — заголовков, окружающего текста, URL. Надежность данных проверяется частотой их повторения на разных сайтах. Эта информация используется для улучшения понимания содержания медиафайла и повышения эффективности систем идентификации контента (Content ID).
  • US10318543B1
  • 2019-06-11

  • Ссылки

  • Индексация

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

Как Google проактивно уведомляет пользователей об изменении цен или доступности товаров на основе их предполагаемого намерения покупки
Google анализирует действия пользователя (поисковые запросы, посещения сайтов), чтобы выявить намерение в отношении сущностей (например, продуктов или авиабилетов). Если намерение сильное и происходит значительное изменение (падение цены или изменение доступности), Google проактивно отправляет уведомление со ссылками для завершения действия (например, покупки).
  • US20180357238A1
  • 2018-12-13

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

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

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

Как Google использует контекст пользователя для генерации неявных поисковых запросов и проактивного показа результатов
Система Google отслеживает контекст пользователя в реальном времени (набираемый текст, открытые документы, письма). На основе этого контекста автоматически генерируются множественные неявные запросы. Система объединяет результаты из разных источников (локальных и глобальных) и проактивно показывает их пользователю, используя поведенческие данные (клики) для улучшения релевантности.
  • US7664734B2
  • 2010-02-16

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

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

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

Как Google выбирает каноническую (основную) версию документа, основываясь на авторитетности источника и полноте контента
Google использует систему для выбора канонической (основной) версии документа среди его дубликатов. Система присваивает «приоритет авторитетности» каждой версии, основываясь на источнике (например, официальный издатель) и праве публикации. Основной версией выбирается та, которая имеет высокий авторитет и является полной. При отсутствии идеального варианта выбирается версия с наибольшим объемом информации (например, самая длинная или с наибольшим PageRank).
  • US8095876B1
  • 2012-01-10

  • EEAT и качество

  • Техническое SEO

  • Ссылки