Как Google использует On-Device ML и историю навигации для прогнозирования следующих шагов пользователя и создания динамических прямых ссылок в SERP

Описание

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

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

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

Запатентована система и метод использования модели машинного обучения (Machine-Learned Action Prediction Model) для прогнозирования следующего шага пользователя после поиска. Модель, обученная на агрегированных последовательностях навигации пользователей (Action Sequences), предсказывает конкретный URL или Deep Link (Resource Locator) целевой страницы (Action Interface) на сайте из результатов поиска. Система генерирует прямой ярлык (Shortcut) на этот ресурс и отображает его в интерфейсе SERP.

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

Механизм преимущественно работает на стороне клиента (в браузере):

• Получение SERP: Браузер (Client Application) получает результаты поиска.
• Сбор контекста: Собираются Context Data, включающие текущий запрос и локальную историю навигации пользователя (последовательность посещенных URL).
• Локальное прогнозирование (On-Device ML): Контекстные данные подаются на вход локальной модели машинного обучения.
• Определение цели: Модель предсказывает наиболее вероятный Resource Locator на сайте из результатов, который соответствует намерению пользователя (например, страница /booking).
• Генерация ярлыка: Браузер создает Shortcut (прямую ссылку) на этот URL и модифицирует отображение SERP, добавляя этот ярлык к соответствующему результату.

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

Высокая. Патент опубликован в конце 2024 года. Использование машинного обучения, особенно локального (on-device ML) и федеративного обучения (Federated Learning), для глубокой персонализации и ускорения пользовательских путей (User Journeys) является передовым направлением развития поисковых и браузерных технологий. Это описывает конкретный механизм для создания высокорелевантных, динамических Sitelinks.

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

Влияние на SEO значительное (8/10). Хотя этот механизм не влияет на базовое ранжирование, он критически важен для презентационного слоя (Presentation Layer) и распределения трафика. Он определяет, какие внутренние страницы (Action Interfaces) станут прямыми точками входа из SERP, потенциально минуя главную страницу или основные посадочные страницы. Сайты с четкой структурой и предсказуемыми путями навигации, которые ML-модель может легко изучить, получат преимущество в виде улучшенного UX и ускоренной конверсии.

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

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

Action Interface (Интерфейс действия)

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

Action Sequence (Последовательность действий)

Зарегистрированная последовательность посещенных пользователем ресурсов (URL). Представляет собой путь пользователя (User Journey) и используется как основные обучающие данные для модели.

Client Application (Клиентское приложение)

Приложение, выполняющее прогнозирование и генерацию ярлыков, чаще всего веб-браузер или поисковое приложение.

Context Data (Контекстные данные)

Входные данные для модели прогнозирования. Включают текущий запрос, историю навигации (Action Sequences), данные устройства, аккаунта, местоположение, а также потенциально контент, карту сайта (sitemap) целевого ресурса или пользовательский контент (Link Notes).

Federated Learning (Федеративное обучение)

Метод обучения ML-модели без централизованного сбора необработанных пользовательских данных, упомянутый как возможный способ обучения модели (Claim 24).

Link Notes (Примечания к ссылкам)

Пользовательский контент (UGC), связанный с веб-ресурсом (например, отзывы). В описании патента упоминается как возможный тип Context Data.

Machine-Learned Action Prediction Model (Модель прогнозирования действий на основе ML)

Модель (часто Transformer), обученная предсказывать следующий Resource Locator на основе входной последовательности предыдущих действий и контекста. Может работать локально (on-device).

Resource Locator (Указатель ресурса)

Идентификатор ресурса, как правило, URL веб-страницы или deep link приложения.

Shortcut (Ярлык)

Элемент интерфейса (гиперссылка, кнопка), добавленный к результату поиска, который ведет непосредственно на предсказанный Action Interface. Функциональный эквивалент динамического Sitelink.

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

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

1. Система (например, браузер) отправляет поисковый запрос и получает результаты.
2. Используется Machine-Learned Action Prediction Model, которая была обучена на наборе Action Sequences (истории посещений веб-ресурсов в определенном порядке).
3. На основе Context Data, связанных с запросом, модель определяет Resource Locator (URL) для Action Interface, связанного с одним из результатов поиска.
4. Система генерирует Shortcut (прямую ссылку) на этот URL.
5. Система отображает результат поиска и сгенерированный Shortcut в пользовательском интерфейсе.

Claim 4 (Зависимый): Указывает на реализацию On-Device ML. Обработка Context Data моделью происходит локально на вычислительной системе (устройстве пользователя).

Claim 11 (Зависимый): Уточняет состав Context Data. Context Data могут включать данные, представляющие карту сайта (sitemap) целевого веб-ресурса.

Claim 16 (Зависимый): Уточняет архитектуру модели. Machine-Learned Action Prediction Model является моделью Трансформер (Transformer model).

Claim 22 (Зависимый): Вводит механизм отказа (Opt-out). Система определяет, что веб-ресурс не содержит индикатора отказа (opt-out indicator) от участия в прогнозировании действий.

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

1. Система получает обучающий набор Action Sequences от браузеров первой группы клиентских устройств.
2. Модель обучается предсказывать следующее действие на основе одного или нескольких предшествующих действий в последовательности.
3. Обученная модель отправляется для обновления браузеров второй группы клиентских устройств для использования в генерации ярлыков.

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

Это изобретение уникально тем, что его основная логика прогнозирования часто выполняется не на серверах Google Search, а на стороне клиента, внутри Client Application (Браузера), хотя обучение модели происходит централизованно или федеративно.

(Офлайн-процессы и Сбор данных)
Происходит сбор агрегированных и приватизированных данных об Action Sequences (истории посещений) с множества устройств. На основе этих данных обучается Machine-Learned Action Prediction Model (упоминается Federated Learning, Claim 24). Обученная модель распространяется на клиентские устройства.

INDEXING – Индексирование (Косвенно)
Данные, собранные на этом этапе (например, структура сайта, sitemap), могут использоваться как часть Context Data для модели прогнозирования (Claim 11).

RANKING – Ранжирование
Стандартные этапы поиска выполняются на сервере для генерации базовой поисковой выдачи (SERP).

METASEARCH / Presentation Layer (Клиентская сторона)
Основное применение патента. После получения SERP браузером активируется механизм:

1. Сбор локального контекста: Браузер собирает Context Data (запрос, локальная история навигации).
2. Локальное прогнозирование (On-Device): Данные обрабатываются локальной ML-моделью (Claim 4).
3. Генерация Shortcut: Модель предсказывает целевой URL (Action Interface), и браузер генерирует ярлык.
4. Модификация UI: Браузер изменяет отображение SERP, вставляя ярлык к соответствующему результату.

Входные данные (для Inference):

• Поисковый запрос.
• Список результатов поиска (SERP).
• Локальная история навигации пользователя (Action Sequences).
• Другие Context Data (данные устройства, аккаунта, местоположение, данные о структуре сайта, например, sitemap).

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

• Предсказанный Resource Locator (URL или Deep Link).
• Сгенерированный Shortcut, отображаемый в UI.

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние оказывается на сайты, ориентированные на задачи (Task-oriented): E-commerce (корзина, категории), SaaS (логин, цены, дашборд), Локальный бизнес (меню, бронирование, контакты), Финансы (запрос предложения).
• Специфические запросы: Влияет на запросы с четким транзакционным или деятельностным интентом (например, брендовые запросы, запросы услуг).

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

• Триггеры активации: Активируется при получении и рендеринге результатов поиска в Client Application.
• Пороговые значения: Применяется, если модель выдает предсказание с достаточно высоким уровнем уверенности (score) (Claim 5). Может быть сгенерировано несколько ярлыков, если несколько прогнозов имеют высокий рейтинг (Claim 6).
• Исключения: Не применяется, если владелец веб-ресурса явно отказался от участия, используя opt-out indicator (Claim 22).

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

Процесс А: Обработка запроса и генерация ярлыков (Inference на устройстве)

1. Получение запроса и результатов: Пользователь вводит запрос, браузер получает SERP.
2. Сбор контекстных данных: Браузер собирает Context Data: текст запроса, локальную историю посещений (Action Sequences), данные устройства и т.д.
3. Подготовка входных данных: Контекстные данные токенизируются и преобразуются для ввода в Machine-Learned Action Prediction Model.
4. Локальное выполнение модели: Браузер запускает модель на устройстве (On-Device).
5. Прогнозирование URL: Модель генерирует один или несколько предсказанных Resource Locators для Action Interfaces на сайтах из SERP, вместе с оценками уверенности (scores).
6. Фильтрация и валидация: Система проверяет, не отказался ли сайт от участия (opt-out), и выбирает URL с оценками, превышающими порог. Может также сверяться с verified set of action sequences (Claim 15).
7. Генерация ярлыков: Для выбранных URL создаются Shortcuts.
8. Отображение: Браузер модифицирует UI, отображая ярлыки вместе с результатами поиска.

Процесс Б: Обучение модели (Офлайн / Федеративно)

1. Сбор данных: Сбор приватизированных Action Sequences (истории навигации) с множества клиентских устройств.
2. Подготовка обучающих данных: Формирование обучающего набора, где целью является предсказание следующего шага в последовательности.
3. Обучение модели: Обучение модели (например, Transformer) предсказывать следующий URL. Используется федеративное обучение (Federated Learning) для сохранения конфиденциальности (Claims 24, 25).
4. Валидация: Проверка качества модели. Может включать генерацию verified set of action sequences на основе частоты повторения (Claim 31).
5. Распространение: Отправка обученной модели на клиентские устройства для локального использования.

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

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

Патент фокусируется на использовании данных о поведении пользователей и контексте для прогнозирования навигации.

• Поведенческие факторы (Ключевые): Action Sequences — последовательности посещенных URL. Это основной тип данных для обучения модели и ключевой компонент Context Data для инференса (Claim 2).
• Контентные факторы: Текст поискового запроса. Также упоминается возможность использования данных, представляющих контент веб-ресурса (Claim 10). В описании также упоминается UGC, такой как Link Notes (отзывы о странице), как возможный вид Context Data.
• Структурные факторы: Упоминается возможность использования данных, представляющих sitemap (карту сайта) целевого веб-ресурса (Claim 11), а также других URL на том же домене (Claim 13).
• Технические факторы: Resource Locators (URL) как входные и выходные данные.
• Пользовательские и Географические факторы: Context Data могут включать данные аккаунта пользователя (user account data), данные о местоположении (location data) и данные сенсоров устройства (sensor data) (Claim 3).

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

• Score (Оценка уверенности): Модель генерирует оценку для предсказанного Resource Locator, отражающую вероятность того, что этот URL является желаемой целью пользователя. Используется для принятия решения о генерации ярлыка (Claim 5).
• Measure of recurrence (Мера повторяемости): Используется в процессе обучения для верификации Action Sequences. Часто повторяющиеся последовательности считаются более надежными (Claim 31).
• Токенизация URL: Модель (например, Transformer) обрабатывает URL как последовательности токенов. Токен может представлять весь URL или его часть (субпорцию), например, домен, путь, параметр (Claims 17-20).

Выводы

1. Динамическая генерация Sitelinks на основе поведения: Патент описывает механизм создания высоко персонализированных ярлыков (аналог Sitelinks), основанный не столько на структуре ссылок сайта, сколько на прогнозировании следующего действия пользователя с помощью ML, обученного на реальных поведенческих данных (Action Sequences).
2. Критичность User Experience и Information Architecture: Система учится на том, как пользователи перемещаются по сайту. Логичная структура и простые пути к ключевым действиям напрямую влияют на способность модели генерировать полезные Shortcuts.
3. On-Device ML и Персонализация: Основная логика прогнозирования выполняется локально в браузере (Claim 4). Это позволяет использовать локальную историю посещений для глубокой персонализации, обеспечивая конфиденциальность и скорость.
4. Изменение точек входа трафика: Этот механизм смещает точки входа с главных или категорийных страниц глубже в структуру сайта, напрямую на Action Interfaces (страницы конверсии).
5. Важность чистых и стабильных URL: Поскольку модель предсказывает конкретный Resource Locator и обрабатывает URL как токены, использование понятных и постоянных URL для ключевых страниц критически важно для эффективности системы.
6. Контроль владельцев сайтов: Предусмотрена возможность отказа (Opt-out) от генерации таких ярлыков (Claim 22).

Практика

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

• Оптимизация Information Architecture (IA) и User Journeys: Создавайте логичную, последовательную и предсказуемую структуру навигации. Чем проще и популярнее путь к ключевым действиям, тем выше вероятность, что модель его выучит и сгенерирует соответствующий ярлык.
• Создание выделенных «Action Interfaces»: Разрабатывайте четкие страницы для ключевых действий (цены, регистрация, заказ, контакты, меню). Убедитесь, что эти страницы являются конечной точкой популярных навигационных цепочек.
• Использование чистых, дескриптивных и стабильных URL: Используйте понятные URL для ключевых страниц (например, site.com/pricing, site.com/book-now). Это облегчает токенизацию и прогнозирование Resource Locators.
• Обеспечение технической доступности структуры: Наличие корректного sitemap.xml может быть использовано моделью как контекстный сигнал (Claim 11). Чистая структура помогает системе понять иерархию страниц.
• Оптимизация Action Interfaces как лендингов: Убедитесь, что страницы ключевых действий оптимизированы для прямого входа из Google. Они должны быть быстрыми, понятными и функциональными без зависимости от контекста предыдущих страниц.

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

• Запутанная и непоследовательная навигация: Если пользователям приходится блуждать по сайту для выполнения базовых задач, модель не сможет выявить четкие паттерны (Action Sequences) и не сгенерирует полезные ярлыки.
• Использование динамических, обфусцированных или нестабильных URL: Использование URL вида site.com/page?id=123&session=xyz для важных Action Interfaces затрудняет их идентификацию и прогнозирование как стабильной цели.
• Скрытие ключевых действий за сложными формами на одной странице (SPA): Если действие происходит без смены URL, системе сложнее сгенерировать ярлык на промежуточный этап. Лучше иметь отдельные URL для ключевых шагов воронки, если требуется прямая ссылка на них.
• Игнорирование производительности внутренних страниц: Фокусировка оптимизации скорости только на главной странице, игнорируя Action Interfaces, которые могут стать основными точками входа.

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

Этот патент подтверждает стратегический сдвиг Google к превращению в «движок действий» (Action Engine), фокусируясь на завершении задач (Task Completion). Он демонстрирует, как данные о поведении пользователей (UX) напрямую трансформируются в функциональность поисковой выдачи с помощью клиентского AI. Для SEO это означает, что оптимизация архитектуры сайта и пользовательского опыта становится критическим фактором, определяющим видимость и доступность внутренних конверсионных страниц сайта прямо из SERP.

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

Сценарий 1: Оптимизация сайта ресторана

1. Анализ поведения: Пользователи часто ищут «Ресторан Ромашка», переходят на главную страницу, а затем кликают на «Меню». Эта последовательность фиксируется как популярная Action Sequence.
2. Действия SEO/UX: Убедиться, что страница меню имеет чистый URL (/menu) и легко доступна.
3. Работа системы: Machine-Learned Action Prediction Model обучается на этих данных. При следующем поиске «Ресторан Ромашка» модель предсказывает, что пользователь хочет увидеть меню.
4. Результат: В SERP рядом с основным результатом генерируется Shortcut «Меню», ведущий прямо на /menu.

Сценарий 2: Страховая компания

1. Анализ поведения: После поиска «страхование авто» пользователи часто переходят на сайт страховой компании и ищут форму расчета стоимости.
2. Действия SEO/UX: Создать оптимизированную страницу /auto/get-quote.
3. Работа системы: Модель идентифицирует этот паттерн.
4. Результат: При поиске «страхование авто» для сайта этой компании может быть сгенерирован Shortcut «Получить предложение», ведущий на /auto/get-quote.

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