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

Описание

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

Патент решает задачу улучшения пользовательского опыта путем сокращения пути от поискового запроса до использования релевантного нативного приложения. Вместо того чтобы заставлять пользователя просматривать SERP и вручную выбирать приложение, система стремится предугадать намерение и автоматически запустить (или установить и запустить) нужное приложение. Одновременно патент внедряет механизмы защиты от нежелательных автозапусков, используя строгие критерии ранжирования и поведенческую обратную связь (short launches) для обеспечения точности.

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

Запатентована система, которая выборочно выполняет (implementing) нативное приложение в ответ на поисковый запрос без вмешательства пользователя. Это происходит только тогда, когда система определяет, что запрос имеет Focus Intent (сфокусированное намерение) на конкретное приложение, и это приложение удовлетворяет строгим критериям ранжирования (занимает первое место и значительно опережает следующее приложение). Система также использует Launch Preference, основанную на поведении пользователей, чтобы избежать повторных нежелательных автозапусков.

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

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

  • Определение намерения: Анализируется запрос на наличие Focus Intent. Обычно это происходит, когда запрос точно соответствует названию приложения (навигационный запрос), а не является общим (информационным).
  • Проверка критериев ранжирования (Scoring Criterion): Если намерение обнаружено, система проверяет ранжирование приложения. Оно должно быть высоко релевантным (№1) и доминирующим (значительно опережать результат №2 среди приложений по Search Score).
  • Проверка предпочтений (Launch Preference Criterion): Опционально проверяется история автозапусков. Если пользователи часто сразу закрывают это приложение после автозапуска (short launches), система может отказаться от его запуска.
  • Автоматическое выполнение: Если все критерии выполнены, система отправляет инструкцию на устройство пользователя для запуска (или установки и запуска) приложения, минуя SERP.
  • Возврат к SERP: После закрытия приложения пользователю может быть показана стандартная страница результатов поиска.

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

Высокая. Интеграция поиска и прямого взаимодействия с приложениями (App Deep Linking) остается ключевым направлением для Google с ростом мобильного трафика. Хотя автоматический запуск из стандартного веб-поиска может применяться консервативно, механизмы, описанные в патенте (оценка интента, поведенческая обратная связь), крайне актуальны для ранжирования приложений в целом и могут активно использоваться в контексте голосового поиска и Google Assistant.

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

Влияние на традиционное веб-SEO минимальное. Однако патент имеет высокое значение (75/100) для ASO (App Store Optimization) и App SEO. Он демонстрирует механизмы, с помощью которых Google может полностью исключить SERP из пользовательского пути. Для владельцев приложений это критически важно: доминирование в ранжировании по брендовым запросам может привести к прямому запуску приложения. Однако негативный опыт после запуска (short launches) может привести к потере этой привилегии. Патент подчеркивает важность не только привлечения трафика, но и качества самого продукта.

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

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

Focus Intent (Сфокусированное намерение)
Сигнал о том, что пользователь имеет очень высокий уровень интереса к конкретному нативному приложению. Определяется, когда запрос не является информационным, а скорее навигационным. Например, когда термины запроса совпадают с названием приложения.
Implementing a native application (Выполнение нативного приложения)
Действие, которое означает установку и запуск нативного приложения на устройстве пользователя в ответ на запрос, ИЛИ запуск уже установленного приложения.
Launch Determiner (Определитель запуска)
Компонент системы, который принимает решение о том, следует ли автоматически запускать нативное приложение в ответ на запрос.
Launch Preference (Предпочтение запуска)
Метрика, основанная на обратной связи от пользователей. Рассчитывается на основе количества short launches относительно общего числа автоматических запусков приложения.
Native Application (Нативное приложение)
Приложение, специально разработанное для работы на определенной операционной системе и аппаратном обеспечении устройства, работающее независимо от браузера.
Scoring Criterion (Критерий оценки)
Набор правил, используемых для определения возможности автозапуска на основе Search Scores. Включает требование занимать первую позицию и требование превышать оценку второго приложения на пороговую разницу (threshold difference).
Search Score (Оценка поиска)
Числовое значение, определяющее релевантность ресурса или приложения запросу и используемое для их ранжирования относительно друг друга.
Short Launch (Короткий запуск)
Событие, когда нативное приложение закрывается пользователем в течение короткого предопределенного периода времени (например, 10 секунд) после автоматического запуска. Является индикатором того, что пользователь не желал запуска приложения.

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

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

  1. Система получает запросы и результаты (ресурсы и приложения) с оценками (Search Scores).
  2. Определяется, имеет ли запрос Focus Intent на одно или несколько приложений.
  3. Только если Focus Intent есть, система определяет, следует ли выполнить одно из этих приложений. Это определение включает специфическое условие доминирования:
    • Приложение НЕ выполняется, только если оно занимает первое место, И его оценка НЕ превышает оценку второго ранжированного нативного приложения на пороговую разницу (threshold difference).
  4. (Иными словами, для выполнения требуется быть №1 и значительно опережать №2 среди приложений).
  5. Если выполнение решено: система предоставляет инструкцию устройству для выполнения приложения без вмешательства пользователя (without user intervention).
  6. В противном случае: предоставляются стандартные результаты поиска.

Claim 2 (Зависимый): Уточняет, что «выполнение» (implementing) может означать запуск уже установленного приложения.

Claim 3, 4, 5 (Зависимые): Детализируют определение Focus Intent. Намерение определяется, когда запрос ссылается на имя приложения (Claim 3), включает термины, точно соответствующие имени (Claim 4), или когда каждый термин запроса точно соответствует имени приложения (Claim 5).

Claim 6, 7 (Зависимые): Вводят концепцию Launch Preference. Определение запуска дополнительно основывается на предпочтении запуска, которое вычисляется на основе взаимодействий пользователей с результатами предыдущих запросов (Claim 6). Launch Preference основано на соотношении количества short launches к общему количеству автозапусков (Claim 7).

Claim 10 (Зависимый): Описывает механизм показа SERP после автозапуска. Система предоставляет результаты поиска и вторую инструкцию, которая заставляет устройство отобразить эти результаты в ответ на закрытие пользователем автоматически запущенного приложения.

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

Изобретение применяется на нескольких этапах поиска, изменяя стандартную логику предоставления результатов.

INDEXING – Индексирование
Система индексирует веб-ресурсы (Web Index) и нативные приложения (Application Index). Извлекаются названия приложений и глубокие ссылки для последующего использования.

QUNDERSTANDING – Понимание Запросов
Система анализирует запрос для классификации его интента. Launch Determiner (или связанный компонент) выявляет Focus Intent на конкретное приложение, сопоставляя запрос с названиями приложений из индекса.

RANKING – Ранжирование
На этом этапе генерируются стандартные результаты поиска как для веб-ресурсов (с помощью Resource Scorer), так и для нативных приложений (с помощью Application Scorer). Search Scores нормализуются для возможности сравнения приложений и веб-ресурсов.

RERANKING – Переранжирование / METASEARCH – Метапоиск и Смешивание
Это основная фаза применения патента, где действует Launch Determiner.

  1. Анализ результатов: Система проверяет Search Scores топовых результатов.
  2. Принятие решения о запуске: Launch Determiner применяет Scoring Criterion (позиция №1 и доминирование среди приложений) и опционально Launch Preference Criterion (анализ short launches из History Logs).
  3. Изменение выдачи: Вместо предоставления стандартного SERP система может отправить инструкцию для автоматического запуска приложения.

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

  • Поисковый запрос.
  • Список идентифицированных ресурсов и приложений с их Search Scores.
  • (Опционально) Данные из History Logs о предыдущих автозапусках и short launches.
  • (Опционально) Информация о том, какие приложения установлены на устройстве пользователя.

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

  • Либо инструкция для автоматического запуска/установки приложения.
  • Либо стандартный SERP.

На что влияет

  • Специфические запросы: Влияет в первую очередь на навигационные и брендовые запросы, которые точно соответствуют названиям популярных приложений (например, [Facebook], [Best Chess]). Не влияет на информационные или категориальные запросы (например, [скачать игры], [приложения для шахмат]).
  • Конкретные типы контента: Влияет исключительно на нативные мобильные приложения.

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

  • Триггеры активации: Механизм активируется только при одновременном выполнении нескольких условий:
    1. Запрос имеет Focus Intent на конкретное приложение.
    2. Это приложение удовлетворяет Scoring Criterion: занимает первую позицию в ранжировании.
    3. Это приложение доминирует: его Search Score превышает Search Score второго ранжированного приложения на определенную пороговую разницу (threshold difference).
  • Исключения: Механизм НЕ применяется, если:
    • Запрос является информационным.
    • Несколько приложений имеют близкие Search Scores (недостаточное доминирование).
    • Launch Preference ниже порога (слишком много short launches в прошлом).

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

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

  1. Получение данных: Система получает запрос от пользователя и результаты поиска (ресурсы и приложения) с соответствующими Search Scores.
  2. Определение Focus Intent: Система анализирует, имеет ли запрос сфокусированное намерение на одно из приложений (например, совпадает ли текст запроса с названием приложения).
    • Если НЕТ: Предоставить стандартный SERP.
    • Если ДА: Перейти к шагу 3.
  3. Выбор приложения-кандидата: Выбирается приложение, на которое направлен Focus Intent.
  4. Применение Scoring Criterion: Проверяется выполнение критериев ранжирования:
    1. Занимает ли приложение первую позицию?
    2. Превышает ли Search Score приложения оценку второго ранжированного приложения на пороговую разницу (проверка доминирования)?
    • Если НЕТ (по любому пункту): Предоставить стандартный SERP.
    • Если ДА: Перейти к шагу 5.
  5. (Опционально) Применение Launch Preference Criterion: Система вычисляет Launch Preference на основе истории short launches (соотношение коротких запусков к общему числу автозапусков). Проверяется, удовлетворяет ли эта метрика пороговому значению.
    • Если НЕТ (слишком много отказов): Предоставить стандартный SERP.
    • Если ДА: Перейти к шагу 6.
  6. Автоматическое выполнение: Система предоставляет инструкцию устройству пользователя, которая вызывает запуск (или установку и запуск) нативного приложения без вмешательства пользователя.
  7. (Опционально) Фоновая загрузка SERP: Одновременно с запуском система может предоставить инструкцию для отображения SERP после того, как пользователь закроет приложение.

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

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

Патент фокусируется на механизме принятия решений на основе уже рассчитанных оценок и поведенческих данных.

  • Контентные факторы: Название приложения. Критически важно для определения Focus Intent путем сравнения с текстом запроса.
  • Поведенческие факторы: Критически важные данные из History Logs. Ключевым является отслеживание short launches – событий, когда пользователь закрывает автоматически запущенное приложение в течение короткого времени. Также используется общее количество автозапусков (total launches).
  • Пользовательские факторы: Опционально может использоваться информация о том, установлено ли приложение на устройстве пользователя. Launch Preference может рассчитываться агрегированно или для конкретного пользователя.
  • Системные данные: Search Scores, рассчитанные поисковой системой для веб-ресурсов и нативных приложений в ответ на запрос.

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

  • Focus Intent: Бинарная метрика (Да/Нет). Определяется на основе степени совпадения текста запроса с названием приложения и классификации запроса (навигационный vs информационный).
  • Scoring Criterion: Основан на Search Scores. Включает:
    • Проверку позиции (например, Позиция = 1).
    • Проверку доминирования:

Выводы

  1. Приоритет действия над выбором при четком намерении: Патент описывает механизм, позволяющий Google полностью пропустить этап выбора результата (SERP), если уверенность в намерении пользователя (Focus Intent) и качестве результата высока.
  2. Требование абсолютного доминирования в ранжировании: Недостаточно быть на первом месте. Система требует значительного отрыва (threshold difference) от второго результата среди приложений, чтобы избежать ошибок при наличии похожих приложений или неоднозначности в запросе.
  3. Поведенческая обратная связь как предохранитель: Метрика Launch Preference, основанная на short launches, является критически важным механизмом контроля качества. Google измеряет реальную удовлетворенность пользователей автозапуском и корректирует поведение системы, если пользователи часто сразу закрывают приложение.
  4. Критичность UX/Onboarding для ASO: Качество самого приложения, особенно его стартового экрана или процесса онбординга, напрямую влияет на вероятность его автоматического запуска в будущем. Это тесно связывает продуктовую аналитику и ASO.
  5. Важность брендинга и нейминга: Определение Focus Intent в значительной степени зависит от совпадения запроса с названием приложения. Это подчеркивает важность уникального и четкого брендинга для мобильных приложений.

Практика

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

Рекомендации касаются в основном ASO (App Store Optimization) и App SEO.

  • Обеспечение доминирования по брендовым запросам: Необходимо максимизировать Search Score приложения по запросам, содержащим его название. Цель – не просто занять первое место, но и обеспечить максимальный отрыв от других приложений, чтобы удовлетворить требование threshold difference.
  • Оптимизация стартового экрана и Онбординга: Критически важно минимизировать показатель short launches. Стартовый экран приложения должен мгновенно вовлекать пользователя. Быстрая загрузка и интуитивно понятный интерфейс обязательны для улучшения Launch Preference.
  • Уникальное и запоминающееся название приложения: Выбирайте названия, которые легко идентифицируются как уникальный бренд. Это повышает вероятность определения Focus Intent и снижает конкуренцию с похожими названиями.
  • Внедрение App Indexing: Обеспечение технической возможности индексации приложения (например, через Firebase App Indexing) является базовым требованием для его присутствия в поиске и участия в подобных механизмах.
  • Стимулирование установки приложения: Хотя патент допускает автоустановку, автозапуск уже установленных приложений является более простым сценарием. Важно иметь стратегию по увеличению установочной базы.

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

  • Использование общих названий для приложений: Название приложения вроде «Калькулятор» или «Шахматы» затрудняет определение Focus Intent и создает высокую конкуренцию, что снижает вероятность достижения доминирования, необходимого для автозапуска.
  • Агрессивный онбординг или долгая загрузка: Длительные заставки, сложные процессы регистрации или медленная загрузка после запуска приложения провоцируют пользователей на немедленное закрытие (short launch). Это приведет к снижению Launch Preference и отключению автозапуска.
  • Копирование названий конкурентов (Мимикрия): Создание приложений с очень похожими названиями (например, «Best Chess» и «Best Chess Openings») может привести к тому, что ни одно из них не достигнет необходимого порога доминирования (threshold difference), и автозапуск не будет активирован ни для одного из них.

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

Патент подчеркивает стратегическую важность интеграции ASO и продуктовой аналитики. Ранжирование (привлечение) и удержание пользователя тесно связаны. Google использует поведение пользователей внутри продукта (short launches) как сигнал для корректировки поисковой выдачи (в данном случае – для решения об автозапуске). Это демонстрирует, что для достижения максимальной видимости в поиске необходимо не только оптимизировать метаданные, но и предоставлять высококачественный продукт. Также это показывает эволюцию поиска от предоставления информации к выполнению действий.

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

Сценарий 1: Успешный автозапуск (Доминирующий бренд)

  1. Запрос: Пользователь вводит [YouTube] в строку поиска Google на телефоне.
  2. Анализ: Система определяет Focus Intent. Приложение YouTube ранжируется №1 с огромным отрывом от любого другого приложения. Launch Preference высокая (пользователи редко закрывают YouTube сразу).
  3. Действие: Google отправляет инструкцию на устройство.
  4. Результат: Приложение YouTube запускается немедленно. SERP не отображается.

Сценарий 2: Отмена автозапуска (Близкие конкуренты)

  1. Запрос: Пользователь вводит [Best Chess].
  2. Анализ: Система определяет Focus Intent. В результатах есть приложение «Best Chess» (Score 0.9) и «Best Chess Openings» (Score 0.85).
  3. Действие: Хотя «Best Chess» на первом месте, разница в оценках (0.05) ниже пороговой (threshold difference). Критерий доминирования не выполнен.
  4. Результат: Автозапуск не происходит. Пользователю показывается стандартный SERP с обоими приложениями в топе (как показано на FIG. 4D патента).

Сценарий 3: Отмена автозапуска (Негативный опыт)

  1. Запрос: Пользователь вводит [Super Fast Cleaner].
  2. Анализ: Система определяет Focus Intent. Приложение доминирует в ранжировании. Однако история показывает, что в 70% случаев после автозапуска пользователи закрывают его в течение 5 секунд (short launch), так как оно сразу требует оплату.
  3. Действие: Launch Preference ниже порога. Критерий предпочтений не выполнен.
  4. Результат: Автозапуск не происходит. Пользователю показывается стандартный SERP.

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

Что такое «Focus Intent» и как Google его определяет?

Focus Intent (сфокусированное намерение) – это сигнал о том, что пользователь с высокой вероятностью хочет использовать конкретное нативное приложение. Google определяет его, анализируя текст запроса. Если запрос является навигационным и точно соответствует названию приложения (например, [Instagram]), то Focus Intent считается высоким. Если запрос информационный или категориальный (например, [лучшие фоторедакторы]), то Focus Intent отсутствует.

Достаточно ли моему приложению быть на первом месте, чтобы оно запускалось автоматически?

Нет, недостаточно. Патент четко указывает два обязательных условия ранжирования, помимо наличия Focus Intent. Во-первых, приложение должно занимать первую позицию. Во-вторых, его Search Score должен значительно превышать оценку второго ранжированного приложения (threshold difference). Это требование доминирования предотвращает автозапуск в спорных ситуациях.

Что такое «Short Launch» и почему это важно?

Short Launch (короткий запуск) происходит, когда пользователь закрывает автоматически запущенное приложение в течение короткого времени (например, 10 секунд). Это сильный сигнал для Google о том, что автозапуск был нежелателен. Если таких событий много, Launch Preference приложения снижается, и Google перестанет его автоматически запускать по этому запросу.

Как я могу повлиять на «Launch Preference» моего приложения?

На Launch Preference можно повлиять, улучшая пользовательский опыт сразу после запуска приложения. Необходимо минимизировать short launches. Убедитесь, что приложение быстро загружается, стартовый экран релевантен запросу пользователя, а процесс онбординга (если он есть) не вызывает раздражения и не блокирует доступ к основным функциям.

Будет ли Google автоматически устанавливать мое приложение, если оно не установлено?

Да, патент предусматривает такую возможность. Термин «Implementing a native application» включает как запуск уже установленного приложения, так и установку с последующим запуском. Однако в патенте указано, что пороги для принятия решения об автоматической установке могут быть выше, чем для запуска уже установленного приложения, так как установка требует больше ресурсов и времени.

Влияет ли этот патент на ранжирование веб-сайтов?

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

Что произойдет после того, как я закрою автоматически запущенное приложение?

Патент описывает механизм (Claim 10), при котором после закрытия приложения пользователю может быть показана стандартная страница результатов поиска (SERP). Это особенно вероятно, если закрытие произошло быстро (short launch), так как это сигнал, что пользователь, возможно, все же хотел увидеть результаты поиска.

Как стратегия именования приложения влияет на автозапуск?

Стратегия именования критична. Уникальные брендовые названия облегчают определение Focus Intent и помогают достичь доминирования в ранжировании. Использование общих терминов или копирование названий конкурентов снижает шансы на автозапуск, так как система может не определить четкое намерение или разница в Search Scores будет недостаточной.

Как этот патент связан с App Indexing (Firebase)?

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

Применяется ли этот механизм к голосовому поиску?

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

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

Как Google персонализирует мобильную выдачу, повышая в ранжировании приложения, которые пользователь часто использует (Affinity Score)
Google рассчитывает «Affinity Score» для мобильных приложений на основе того, как часто и долго пользователь их использует (относительное вовлечение). При поиске с мобильного устройства система повышает в ранжировании результаты (deep links), ведущие в приложения с высоким Affinity Score, делая выдачу более персонализированной.
  • US10248698B2
  • 2019-04-02

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

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

  • SERP

Как Google позволяет пользователям "углубиться" в контент установленного мобильного приложения прямо из веб-выдачи
Google использует этот механизм для интеграции контента из нативных приложений в веб-поиск. Если приложение установлено у пользователя и система определяет высокую релевантность его контента запросу, в выдачу добавляется специальный элемент (например, "Больше результатов из приложения X"). Клик по этому элементу запускает новый поиск, показывая множество deep links только из этого приложения, не покидая интерфейс поиска.
  • US10579687B2
  • 2020-03-03

  • SERP

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

  • Ссылки

Как Google корректирует ранжирование, основываясь на типе устройства пользователя и полезности контента для этого устройства
Google использует систему для корректировки поисковой выдачи в зависимости от типа устройства пользователя (например, Android, iOS, десктоп). Контент, полезный для данного устройства, повышается в ранжировании, а бесполезный — понижается. Однако корректировка происходит только при наличии полезных альтернатив и только если это не противоречит явному намерению пользователя (интенту).
  • US9652508B1
  • 2017-05-16

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

  • SERP

Как Google индексирует контент внутри мобильных приложений для показа в результатах поиска (App Indexing)
Google использует механизм для индексации контента, который пользователи просматривают в нативных мобильных приложениях. Система получает данные о просмотренном контенте и deep links напрямую от приложения на устройстве. Эта информация сохраняется в индексе (персональном или публичном) и используется для генерации результатов поиска, позволяя пользователям переходить к контенту внутри приложений напрямую из поисковой выдачи.
  • US10120949B2
  • 2018-11-06

  • Индексация

  • SERP

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

Как Google выбирает между веб-сайтом (десктоп/мобайл) и нативным приложением для показа в результатах поиска
Google анализирует различные форматы доступа к контенту (например, десктопный сайт, мобильный сайт, нативное приложение). Система оценивает качество, скорость, стабильность и совместимость каждого варианта с устройством пользователя. В результатах поиска Google покажет ссылку на тот формат, который имеет наивысшую оценку качества для конкретного пользователя и устройства.
  • US9146972B2
  • 2015-09-29

  • SERP

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

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

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

Как Google кластеризует похожие страницы, анализируя, куда пользователи переходят дальше (Co-visitation)
Google анализирует навигационные пути пользователей для определения схожести документов. Если после просмотра Страницы А и Страницы Б пользователи часто переходят к одному и тому же набору последующих страниц, Google считает Страницу А и Страницу Б похожими и объединяет их в кластер. Этот механизм позволяет определять тематическую близость на основе поведения пользователей.
  • US8650196B1
  • 2014-02-11

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

  • SERP

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

Как Google фильтрует персонализированные предложения запросов на основе контента просматриваемой страницы
Google использует механизм для генерации предложений следующего запроса после того, как пользователь покинул страницу выдачи. Система создает кандидатов на основе истории поиска пользователя, а затем фильтрует их, проверяя релевантность контенту страницы, которую пользователь просматривает в данный момент. Это гарантирует, что предложения соответствуют как интересам пользователя, так и текущему контексту просмотра.
  • US8392435B1
  • 2013-03-05

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

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

  • SERP

Как Google использует историю уточнений запросов для выявления и повышения авторитетных сайтов по широким запросам
Google анализирует последовательности запросов пользователей, чтобы понять, как они уточняют свои поисковые намерения. Если пользователи часто переходят от широкого или неточного запроса к более конкретному, который ведет на авторитетный ресурс, Google связывает этот ресурс с исходным широким запросом. Это позволяет показывать авторитетный сайт выше в выдаче, даже если пользователь сформулировал запрос неточно.
  • US8326826B1
  • 2012-12-04

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

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

  • EEAT и качество

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

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

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

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

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

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

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

  • SERP

Как Google использует личную историю поиска и профиль интересов для персонализации подсказок Autocomplete
Google персонализирует поисковые подсказки (Autocomplete), используя профиль интересов пользователя, созданный на основе его прошлых запросов и кликов. Система сравнивает тематику потенциальных подсказок с интересами пользователя и повышает в списке те варианты, которые соответствуют его предпочтениям, с учетом актуальности этих интересов.
  • US20140108445A1
  • 2014-04-17

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

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

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

Как Google использует машинное обучение (Learning to Rank) для имитации оценок асессоров и улучшения ранжирования
Google использует технологию Learning to Rank для обучения статистических моделей, которые имитируют оценки человеческих асессоров. Модели анализируют объективные сигналы (статические и поведенческие) для пары запрос/документ и предсказывают, насколько релевантным этот документ сочтет человек. Эти прогнозы затем используются для ранжирования результатов поиска.
  • US8195654B1
  • 2012-06-05

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

  • SERP

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

  • Local SEO

  • SERP

  • Ссылки

Как Google определяет язык и языковую релевантность страницы, анализируя контекст входящих и исходящих ссылок
Google использует контекст входящих и исходящих ссылок для определения языковой релевантности ресурса. Система анализирует язык анкоров, URL, контент ссылающихся и целевых страниц, а также качество ссылок и тип страницы (например, «языковой шлюз»). Это позволяет точно идентифицировать релевантные языки, даже если на самой странице мало текста.
  • US9098582B1
  • 2015-08-04

  • Ссылки

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

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

Как Google использует социальные связи для обнаружения ссылочного спама и накрутки кликов
Google может анализировать связи между владельцами сайтов в социальных сетях, чтобы оценить независимость ссылок между их ресурсами. Если владельцы тесно связаны (например, друзья), ссылки между их сайтами могут получить меньший вес в ранжировании, а клики по рекламе могут быть классифицированы как спам (накрутка).
  • US8060405B1
  • 2011-11-15

  • Антиспам

  • Ссылки

  • SERP