Как Google превращает поисковую выдачу в интерактивные "Мини-приложения" (Mini-Apps) от разных поставщиков

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

Alternate Provider Agent (Агент альтернативных поставщиков)

Модуль поисковой системы, отвечающий за определение интента, поиск Mini-Apps у различных поставщиков, их ранжирование и управление переносом данных между ними.

Collapsed State (Свернутое состояние)

Состояние Mini-App в SERP, когда его функциональность скрыта. Обычно отображается только название поставщика или базовая информация.

Expanded State (Развернутое состояние)

Активное состояние Mini-App в SERP, когда его интерфейс и интерактивные элементы полностью доступны для взаимодействия пользователем.

Intent Library (Библиотека интентов)

Хранилище данных, содержащее предопределенные намерения пользователей и связанные с ними ключевые слова, задачи и свойства. Используется для сопоставления запроса с доступными Mini-Apps.

Library Page (Страница библиотеки)

Специальный формат отображения результатов поиска, где несколько связанных Mini-Apps (часто объединенных в Workflow) представлены в развернутом состоянии на одной странице.

Mini-App (Мини-приложение)

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

Ordered Task List (Упорядоченный список задач)

Часть Workflow. Определяет последовательность задач, которую пользователь, вероятно, захочет выполнить. Используется для определения порядка ранжирования Mini-Apps в Workflow.

Session Information (Информация о сессии)

Временные данные, введенные пользователем в Mini-App во время текущего сеанса поиска. Используются для переноса данных между приложениями разных поставщиков.

Workflow (Рабочий процесс)

Сгенерированная системой последовательность связанных задач (Ordered Task List) и набор Mini-Apps, подобранных для выполнения этих задач.

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

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

1. Получение запроса.
2. Определение интента из Intent Library.
3. Идентификация как минимум одного Mini-App от первого поставщика и одного от второго поставщика на основе интента.
4. Ранжирование идентифицированных Mini-Apps.
5. Рендеринг результатов поиска: первое приложение в развернутом состоянии (expanded state), остальные — в свернутом (collapsed state).
6. Получение ввода данных пользователем в первое приложение.
7. Получение выбора другого Mini-App пользователем.
8. В ответ на выбор: Свертывание первого приложения, Развертывание выбранного приложения и Заполнение выбранного приложения данными, введенными ранее в первое приложение, путем маппинга полей.

Ядром изобретения является не только отображение приложений в SERP, но и механизм бесшовного переноса пользовательского ввода между приложениями разных поставщиков.

Claim 7 (Независимый пункт - Система): Описывает систему, фокусирующуюся на генерации рабочих процессов.

1. Определение интента по запросу.
2. Генерация рабочего процесса (Workflow), связанного с интентом. Workflow включает упорядоченный список задач (Ordered Task List) и набор Mini-Apps.
3. Ранжирование выбранных Mini-Apps в соответствии с Ordered Task List.
4. Рендеринг результатов (первое развернуто, остальные свернуты).

Здесь акцент смещается на оркестрацию задач: система не просто отвечает на запрос, а предсказывает и выстраивает последовательность действий.

Claim 2 (Зависимый от 1) и Claim 8 (Зависимый от 7): Детализируют критерии ранжирования. Ранжирование может основываться на определенной аффилированности (affiliation) или связи (association) между пользователем и поставщиком услуг.

Claim 3, 9, 10 (Зависимые): Уточняют, как определяется аффилированность: имя поставщика указано в запросе, или пользователь залогинен в аккаунт, связанный с поставщиком.

Claim 5 (Зависимый от 1) и Claim 19 (Зависимый от 12): Описывают альтернативный критерий выбора/ранжирования. Mini-App может быть выбрано на основе определенного отсутствия связи (lack of relationship) между пользователем и поставщиком.

Это указывает на двойной режим работы: система может продвигать знакомые пользователю сервисы или целенаправленно предлагать новые альтернативы.

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

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

QUNDERSTANDING – Понимание Запросов
На этом этапе система должна не просто понять тему запроса, но и определить конкретное действие (intent), которое пользователь хочет совершить, используя Intent Library.

RANKING – Ранжирование
Происходит ранжирование не веб-страниц, а интерактивных приложений (Mini-Apps). Критерии ранжирования специфичны: аффилированность пользователя с брендом, новизна бренда для пользователя или порядок в предсказанном рабочем процессе (Workflow).

METASEARCH – Метапоиск и Смешивание
Mini-Apps смешиваются с традиционными результатами поиска или формируют отдельный интерактивный блок (например, Library Page). Система управляет UI Layout и состоянием приложений (expanded/collapsed).

Взаимодействие компонентов:

• Alternate Provider Agent является центральным компонентом, который взаимодействует с Query Engine, Intent Library и репозиторием Mini-App Data.
• На клиенте браузер обрабатывает взаимодействие пользователя и использует Session Information для переноса данных между приложениями.

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

• Поисковый запрос.
• Данные пользователя (история поиска, данные об аккаунтах, логины — с разрешения пользователя) для определения аффилированности.
• Intent Library.
• Репозиторий Mini-App Data (API, код приложений, метаданные от поставщиков).

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

• SERP, содержащая блок интерактивных Mini-Apps с определенным UI Layout (например, стекинг, карусель, Library Page).

На что влияет

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

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

• Триггеры активации: Алгоритм активируется, когда система с высокой уверенностью определяет, что интент пользователя соответствует задаче, которую можно выполнить с помощью зарегистрированных в системе Mini-Apps.
• Условия: Наличие в репозитории как минимум двух альтернативных Mini-Apps от разных поставщиков (согласно Claim 1) или наличие данных для генерации Workflow (согласно Claim 7).

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

Процесс А: Обработка запроса и отображение альтернатив (Claim 1)

1. Получение запроса: Система получает запрос от пользователя.
2. Определение интента: Запрос сопоставляется с Intent Library для определения намерения.
3. Идентификация кандидатов: Alternate Provider Agent ищет Mini-Apps от нескольких поставщиков (Поставщик А, Поставщик Б), соответствующих интенту.
4. Ранжирование: Приложения ранжируются на основе критериев (например, аффилированность пользователя с Поставщиком А).
5. Рендеринг SERP: Отображается список результатов. Приложение Поставщика А развернуто, Поставщика Б — свернуто.
6. Взаимодействие пользователя: Пользователь вводит данные в приложение Поставщика А. Данные сохраняются в Session Information.
7. Переключение: Пользователь кликает на приложение Поставщика Б.
8. Обновление интерфейса и перенос данных: Система сворачивает А, разворачивает Б и автоматически заполняет поля в Б данными из Session Information.

Процесс Б: Генерация и отображение рабочего процесса (Claim 7)

1. Определение интента: Определяется сложный интент, подразумевающий несколько шагов.
2. Генерация Workflow: Система предсказывает последовательность задач (Ordered Task List) на основе агрегированных данных о поведении пользователей или других ML-моделей.
3. Выбор Mini-Apps: Подбираются приложения для каждой задачи в списке.
4. Ранжирование по Workflow: Приложения выстраиваются в порядке, соответствующем Ordered Task List.
5. Рендеринг SERP: Отображается результат (например, в формате Library Page, где все приложения могут быть развернуты, или стандартном виде).
6. Выполнение задач: Пользователь последовательно взаимодействует с приложениями для завершения процесса.

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

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

Система использует несколько ключевых типов данных:

• Поведенческие и Пользовательские факторы:
  • Данные сессии (Session Information): Ввод пользователя в реальном времени (текст в полях форм). Критически важны для переноса данных между приложениями.
  • Данные об аффилированности: (С разрешения пользователя) История поиска, сохраненные логины, данные об учетных записях у поставщиков услуг. Используются для определения связи (affiliation/association) пользователя с брендом при ранжировании.
  • Агрегированные данные пользователей: Анонимизированные данные о последовательности действий пользователей при выполнении задач. Используются для генерации Workflows и Ordered Task List.
• Контентные факторы (Данные от поставщиков):
  • Mini-App Data: Код приложения, HTML, стили, изображения, API для выполнения функций.
  • Intent Descriptions: Метаданные или ключевые слова, предоставленные поставщиком для сопоставления приложения с интентами в Intent Library.
  • Workflow Data: Информация от поставщиков о том, какие из их приложений могут функционировать последовательно.

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

• Соответствие Интенту (Intent Matching): Метрика, определяющая, насколько точно запрос соответствует интентам в Intent Library и насколько Mini-App соответствует этому интенту. Упоминается использование ML-алгоритмов (например, нейронных сетей) для определения весов факторов при определении интента.
• Аффилированность пользователя (User Affiliation): Оценка связи пользователя с поставщиком. Рассчитывается на основе наличия аккаунта, истории взаимодействий или явного указания бренда в запросе.
• Новизна (Lack of Relationship): Метрика, обратная аффилированности. Используется для идентификации поставщиков, с которыми пользователь ранее не взаимодействовал.
• Прогнозируемый порядок задач (Predicted Task Sequence): Используется при генерации Workflows. Система предсказывает вероятность того, что пользователь выполнит Задачу Б после Задачи А. На основе этого строится Ordered Task List, который диктует ранжирование приложений в Workflow.

1. От Поиска Информации к Выполнению Задач: Патент описывает инфраструктуру для превращения Google из поискового движка в движок выполнения задач (Task Completion Engine). Цель — позволить пользователю действовать, не покидая SERP.
2. Mini-Apps как новый формат контента: Вводится новый тип результатов поиска — интерактивные приложения. Это следующий шаг эволюции после Rich Snippets и Featured Snippets.
3. Конкуренция функциональности в SERP: Поставщики конкурируют не только контентом, но и удобством и функциональностью своих Mini-Apps непосредственно в выдаче.
4. Бесшовный перенос данных между конкурентами: Ключевой механизм патента — возможность переноса данных сессии (Session Information) между приложениями разных поставщиков. Это радикально упрощает сравнение услуг для пользователя (например, сравнение условий кредита в разных банках).
5. Двойная логика ранжирования: Лояльность vs Новизна. Система может ранжировать Mini-Apps, отдавая предпочтение знакомым пользователю брендам (Affiliation) или, наоборот, целенаправленно продвигать новые сервисы (Lack of Relationship).
6. Оркестрация сложных задач (Workflows): Google берет на себя роль оркестратора, предсказывая последовательность действий пользователя и выстраивая Mini-Apps в нужном порядке (Ordered Task List).

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

Хотя Google пока не предоставил публичного механизма для регистрации Mini-Apps, описанного в патенте, стратегически готовиться необходимо уже сейчас:

• Идентификация ключевых задач пользователей: Определите основные транзакционные и инструментальные интенты в вашей нише (расчет стоимости, бронирование, проверка статуса). Это кандидаты на превращение в Mini-Apps.
• Развитие API и микросервисной архитектуры: Для работы Mini-Apps необходимо иметь возможность предоставлять функциональность через внешние интерфейсы (API). Убедитесь, что ваши ключевые сервисы доступны и быстры.
• Оптимизация под быстрое выполнение задач: Интерфейсы для ключевых задач должны быть максимально упрощены. Если система будет реализована, победит тот, чье Mini-App быстрее и понятнее решает проблему пользователя в SERP.
• Укрепление бренда и аффилированности: Поскольку аффилированность (Affiliation) является фактором ранжирования Mini-Apps, работа над узнаваемостью бренда, лояльностью клиентов и стимулирование использования аккаунтов приобретает дополнительное значение в SEO.
• Анализ смежных интентов (Workflows): Изучайте, какие задачи пользователи выполняют до и после взаимодействия с вашим сервисом. Это позволит стратегически планировать разработку связанных Mini-Apps, которые могут быть объединены Google в Workflow.

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

• Игнорирование интерактивных форматов SERP: Рассматривать выдачу только как список из 10 синих ссылок. Необходимо учитывать, что интерактивные блоки могут перехватывать большую часть внимания и кликов.
• Фокус только на информационном трафике: Полагаться на привлечение трафика по транзакционным запросам только на веб-сайт. Если задача может быть решена в SERP, многие пользователи не перейдут на сайт.
• Усложнение пользовательских путей: Создание многошаговых форм и сложных интерфейсов для простых задач. Такие решения проиграют конкуренцию в формате Mini-Apps.

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

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

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

Сценарий: Сравнение условий ипотеки в SERP

1. Запрос пользователя: "Ипотечный калькулятор".
2. Действие системы: Google определяет интент и отображает блок Mini-Apps. На первом месте (развернуто) — калькулятор Банка А (например, из-за аффилированности пользователя). Калькуляторы Банка Б и Банка В свернуты.
3. Взаимодействие: Пользователь вводит сумму, срок и первый взнос в Mini-App Банка А и видит результат расчета.
4. Сравнение (Переключение): Пользователь кликает на свернутое Mini-App Банка Б.
5. Результат (Перенос данных): Калькулятор Банка А сворачивается. Калькулятор Банка Б разворачивается, и поля суммы, срока и взноса уже автоматически заполнены теми же данными. Пользователь мгновенно видит расчет по условиям Банка Б без повторного ввода.