Как Google интегрирует интерактивные мини-приложения (Subsidiary Applications) в результаты поиска и адаптирует их под контекст пользователя

Описание

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

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

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

Запатентована система рендеринга интерактивных Subsidiary Applications (вспомогательных или мини-приложений) в ответ на поисковый запрос. Это легковесные интерфейсы, предоставляемые третьими сторонами (Third Party Entities), но отображаемые внутри интерфейса первой стороны (First Party System, например, Google Search/Assistant). Они предоставляют пользователю доступ к ограниченному, но высокорелевантному набору функций стороннего сервиса без необходимости установки полного приложения. Ключевым элементом изобретения является механизм превентивной адаптации (preemptively adapted state) интерфейса этих мини-приложений на основе контекстуальных параметров (parameters), таких как предыдущие действия пользователя или данные его аккаунта.

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

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

• Получение запроса и контекста: Первая сторона (Google) получает запрос пользователя и определяет связанные с ним контекстуальные параметры (например, предыдущий запрос, местоположение, данные аккаунта).
• Идентификация третьих сторон: Система определяет релевантные сторонние сервисы, зарегистрированные для предоставления Subsidiary Applications по данному запросу.
• Запрос и получение GUI данных: Система запрашивает (или использует предварительно загруженные) данные для рендеринга интерфейса (Entity-Specific GUI Data).
• Контекстуальная адаптация: Интерфейс мини-приложения адаптируется к контексту. Это может происходить двумя способами: (1) Google передает контекстуальные параметры третьей стороне, и та возвращает уже адаптированный интерфейс; или (2) Google самостоятельно взаимодействует с интерфейсом (симулируя ввод), чтобы перевести его в нужное состояние.
• Рендеринг: Адаптированное интерактивное мини-приложение отображается пользователю (например, в SERP) вместе с другими результатами поиска.

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

Высокая. Патент напрямую связан с эволюцией Google Поиска от информационной системы к платформе для выполнения действий (Task Completion Platform). Интеграция действий (Actions), бронирований, заказов и других интерактивных элементов непосредственно в SERP и Google Assistant является стратегическим направлением развития. Описанные механизмы контекстной адаптации критически важны для обеспечения бесшовного и персонализированного пользовательского опыта в 2025 году.

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

Патент имеет высокое стратегическое значение для SEO (85/100). Он описывает механизмы, которые позволяют Google становиться операционным слоем интернета, где пользователи могут взаимодействовать с бизнесом напрямую через интерфейс Google, минуя традиционные веб-сайты. Для SEO это означает смещение фокуса с оптимизации для привлечения трафика на сайт к оптимизации для обеспечения взаимодействия и транзакций непосредственно в выдаче. Участие в этой экосистеме (через API, интеграции с Google) становится критически важным для видимости по транзакционным и действенным запросам.

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

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

Contextual Parameters / Parameter (Контекстуальные параметры)

Данные, определяющие контекст запроса. Включают предыдущие запросы, контент, отображаемый на устройстве, историю просмотров, данные из email, текущее местоположение, время и другие данные, связанные с устройством или аккаунтом пользователя. В Claims используется термин Parameter.

Entity-Specific GUI Data (GUI-данные, специфичные для сущности)

Данные, предоставляемые третьей стороной первой стороне, которые определяют внешний вид и интерактивные элементы Subsidiary Application.

First Party System (Система первой стороны)

Система, которая получает и обрабатывает поисковый запрос пользователя (например, Google Search или Google Assistant).

Interactive Element (Интерактивный элемент)

Компонент GUI вспомогательного приложения (например, выпадающее меню, текстовое поле, кнопка), с которым может взаимодействовать пользователь для выполнения действия.

Preemptively Adapted State (Превентивно адаптированное состояние)

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

Query Data (Данные запроса)

Данные, генерируемые первой стороной на основе запроса пользователя и передаваемые третьим сторонам. Могут включать содержание запроса, контекстуальные параметры и данные аутентификации.

Subsidiary Application (Вспомогательное/Дочернее приложение)

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

Third Party Entity (Сущность третьей стороны)

Поставщик услуг или контента (например, ресторан, служба доставки), который контролирует Subsidiary Application и предоставляет Entity-Specific GUI Data.

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

Патент US12271373B2 является патентом-продолжением (continuation) и фокусируется конкретно на механизме контекстной адаптации интерактивных элементов внутри мини-приложений.

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

1. Сервер первой стороны получает запрос от клиентского устройства через интерфейс, контролируемый первой стороной.
2. Определяется parameter для запроса. Этот параметр является дополнением к самому запросу и основан на (а) past interaction (прошлом взаимодействии) на устройстве ИЛИ/И (б) data of a user account (данных аккаунта пользователя).
3. Определяется, что запрос связан с third party subsidiary application.
4. В ответ на эту связь И наличие параметра система вызывает:
5. Рендеринг entity-specific GUI для этого мини-приложения в интерфейсе клиента.
6. Рендеринг этого GUI с interactive element, который превентивно адаптирован (preemptively adapted) в состояние, основанное на определенном параметре.

Claim 2, 5 (Зависимые): Уточняют, что past interaction может быть предыдущим поисковым запросом (Claim 2) или контентом, который отображался на устройстве (Claim 5).

Claim 3, 4 (Зависимые): Уточняют, что data of a user account могут включать историю браузера (browsing history data) (Claim 4).

Claim 6 (Зависимый): Описывает первый метод адаптации (Адаптация через третью сторону).

Первая сторона передает parameter на сторонний сервер. Эта передача заставляет сторонний сервер предоставить entity-specific GUI уже с адаптированным интерактивным элементом.

Claim 7 (Зависимый): Описывает второй метод адаптации (Адаптация первой стороной).

Первая сторона самостоятельно взаимодействует с интерактивным элементом entity-specific GUI (например, симулируя ввод), чтобы превентивно перевести его из состояния по умолчанию в состояние, основанное на параметре.

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

1. Получение запроса от поискового сервера (первой стороны) на предоставление контента для мини-приложения. Запрос содержит parameter.
2. Генерация контента мини-приложения так, чтобы interactive element был превентивно адаптирован на основе этого параметра.
3. Передача контента поисковому серверу для рендеринга адаптированного GUI.

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

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

QUNDERSTANDING – Понимание Запросов
На этом этапе система должна не только понять интент запроса, но и извлечь контекстуальные параметры (Parameter) из предыдущих взаимодействий (past interactions) или данных аккаунта (user account data). Это необходимо для последующей адаптации интерфейса.

RANKING / METASEARCH – Ранжирование и Метапоиск
Система определяет, какие Subsidiary Applications релевантны запросу. В описании патента упоминается, что эти приложения могут ранжироваться на основе релевантности запросу и контексту, а также показателей взаимодействия. Происходит смешивание стандартных результатов поиска с этими интерактивными блоками.

RERANKING / Генерация SERP
На этом этапе происходит ключевой процесс изобретения — превентивная адаптация (preemptive adaptation). Перед тем как отобразить GUI пользователю, система либо запрашивает адаптированный GUI у третьей стороны, либо адаптирует его самостоятельно.

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

• Запрос пользователя.
• Данные о прошлых взаимодействиях (предыдущие запросы, просмотренный контент).
• Данные аккаунта пользователя (история браузера и т.д.).
• Entity-Specific GUI Data от третьих сторон.

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

• Интерактивный GUI (Subsidiary Application), отображаемый в интерфейсе первой стороны, с интерактивными элементами, находящимися в превентивно адаптированном состоянии.

На что влияет

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

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

• Триггеры активации: Когда система идентифицирует запрос как действенный И когда существуют зарегистрированные третьи стороны, предоставляющие Subsidiary Applications, релевантные этому запросу.
• Условия для адаптации: Механизм адаптации активируется, когда система может извлечь релевантные контекстуальные параметры (parameters) из прошлых действий или данных пользователя, которые могут быть использованы для предустановки опций в мини-приложении.

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

Процесс обработки запроса и адаптации

1. Получение запроса: Система первой стороны получает запрос через интерфейс клиентского приложения.
2. Анализ контекста и извлечение параметра: Система анализирует past interactions (предыдущие запросы, просмотренный контент) и/или data of a user account (история браузера). Извлекается контекстуальный parameter. (Например, если предыдущий запрос был «веганская кухня», параметр может быть «cuisine=vegan»).
3. Идентификация приложений: Определяются релевантные subsidiary applications от третьих сторон.
4. Получение GUI данных: Система получает Entity-Specific GUI Data (это может быть запрос в реальном времени или доступ к кэшированным данным).
5. Выполнение превентивной адаптации: Система адаптирует интерактивные элементы мини-приложений на основе извлеченного параметра. Применяется один из двух методов:
   • Метод A (Адаптация третьей стороной): Первая сторона передает parameter третьей стороне. Третья сторона возвращает Entity-Specific GUI Data, в котором интерактивные элементы уже находятся в адаптированном состоянии (Claim 6).
   • Метод B (Адаптация первой стороной): Первая сторона самостоятельно взаимодействует (например, через симуляцию ввода) с интерактивными элементами стандартного GUI, чтобы перевести их в адаптированное состояние (Claim 7).
6. Рендеринг GUI: Система отображает GUI вспомогательного приложения в интерфейсе (SERP). Интерактивные элементы уже находятся в адаптированном состоянии.
7. Обработка взаимодействий: Пользователь взаимодействует с адаптированным GUI. Взаимодействия обрабатываются и передаются третьей стороне для выполнения задачи.

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

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

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

• Поведенческие факторы (Past Interaction):
  • Предыдущие поисковые запросы (previous search queries), выданные клиентским устройством до текущего запроса.
  • Контент, который отображался на клиентском устройстве (content being rendered at the client device) в момент запроса или незадолго до него.
• Пользовательские факторы (Data of a User Account):
  • История браузера (browsing history).
  • Контент, определенный из электронной почты пользователя (упоминается в описании).
  • Другие данные, связанные с аккаунтом пользователя.
• Географические факторы: Текущее местоположение (current location) (упоминается в описании как возможный контекстуальный параметр).
• Временные факторы: Текущее время дня (current time of day), день недели (упоминаются в описании как возможные контекстуальные параметры).
• Системные данные: Entity-Specific GUI Data, предоставляемые третьими сторонами.

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

Патент фокусируется на механизме адаптации, а не на ранжировании. Ключевые элементы данных:

• Parameter: Единица контекстуальных данных, извлеченная из поведенческих или пользовательских факторов. Используется как входные данные для процесса адаптации.
• State (Состояние): Конфигурация интерактивного элемента. Система изменяет состояние по умолчанию на Preemptively Adapted State.

В описании патента (не в Claims) также упоминаются метрики для управления отображением и верификации:

• Relevance (Релевантность): Используется для ранжирования Entity-Specific GUI Data от разных поставщиков.
• Interaction Rate (Частота взаимодействий): Метрики взаимодействия могут использоваться для корректировки того, насколько заметно отображается Subsidiary Application. Низкий уровень взаимодействия может привести к пессимизации.
• Verification Metrics (Метрики верификации): Используются перед связыванием приложения с запросом. Например, проверка того, что у третьей стороны есть релевантный веб-сайт с достаточным selection rate по этому запросу.

Выводы

1. Google как платформа для выполнения задач (Task Completion): Патент подтверждает стратегию Google по превращению Поиска и Ассистента в среду, где пользователи могут выполнять действия напрямую, не переходя на сторонние сайты и не устанавливая приложения. Subsidiary Applications — это механизм реализации этой стратегии.
2. Контекст и персонализация критичны: Ядро изобретения — это не просто показ мини-приложений, а их превентивная адаптация (preemptive adaptation) под контекст пользователя. Google активно использует данные о поведении пользователя (недавние запросы, просмотренный контент) и данные аккаунта для персонализации этих интерактивных элементов.
3. Два пути адаптации интерфейса: Google предусматривает гибкость в реализации адаптации: либо третья сторона сама адаптирует интерфейс на основе переданных параметров (Метод A), либо Google делает это самостоятельно, симулируя ввод (Метод B). Это снижает порог входа для интеграции сервисов.
4. SEO смещается к оптимизации действий (Action Optimization): Для бизнесов, предоставляющих услуги, критически важно быть представленными в виде Subsidiary Applications. Это требует перехода от традиционного SEO к оптимизации интеграций, API и структурированных данных, позволяющих Google взаимодействовать с сервисом.
5. Усиление «Zero-Click» тенденций: Предоставление адаптированного интерактивного функционала прямо в SERP снижает необходимость перехода на сторонние сайты для выполнения транзакций, что влияет на модели атрибуции и органический трафик.

Практика

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

• Оптимизация для действий (Action Optimization): Необходимо активно интегрировать бизнес-функции с платформами Google, которые поддерживают интерактивные взаимодействия. Цель — обеспечить возможность рендеринга вашего сервиса как Subsidiary Application. Это включает работу с Google Business Profile, Merchant Center и специфическими API интеграции.
• Внедрение глубокой разметки для действий: Использовать структурированные данные (Schema.org Actions, например, OrderAction, ReserveAction), которые описывают действия, доступные на сайте. Это помогает Google понять функциональность сервиса и потенциально использовать ее для создания интерактивных элементов в выдаче.
• Адаптация сервисов под прием контекстуальных параметров: Если интеграция происходит через API (Метод A, Claim 6), необходимо убедиться, что бэкенд сервиса способен принимать контекстуальные параметры (parameters) от Google (например, предпочитаемую дату, тип услуги, местоположение) и возвращать превентивно адаптированный интерфейс или предзаполненные данные.
• Анализ пути пользователя (User Journey Mapping): Изучайте цепочки запросов пользователей. Понимание того, какой контекст Google может использовать (past interactions), поможет оптимизировать контент и сервисы под эти сценарии для лучшей превентивной адаптации.

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

• Игнорирование интерактивных возможностей SERP: Полагаться исключительно на традиционные «синие ссылки» и привлечение трафика на сайт по транзакционным запросам. Это приведет к потере видимости и конверсий в пользу конкурентов, интегрированных напрямую в интерфейс Google.
• Создание сложных и нестандартных интерфейсов для выполнения задач: Сложные интерфейсы труднее интегрировать в формат Subsidiary Application, который предполагает легковесность и быстроту. Изобретение направлено на упрощение и ускорение взаимодействия.
• Пренебрежение структурированными данными и API: Отсутствие качественной разметки действий и открытых интерфейсов для интеграции не позволит Google идентифицировать и использовать функциональность сервиса в качестве мини-приложения.

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

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

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

Сценарий 1: Контекстная адаптация заказа еды (на основе цепочки запросов)

1. Предыдущее действие (Контекст): Пользователь ищет в Google «лучшие веганские рестораны в центре». Google фиксирует это как past interaction.
2. Текущий запрос: Сразу после этого пользователь ищет «заказать еду».
3. Извлечение параметра: Google определяет контекстуальный parameter = «веганская кухня».
4. Активация механизма: Google идентифицирует релевантные Subsidiary Applications агрегаторов доставки еды.
5. Адаптация (Метод A): Google передает агрегатору запрос на GUI данные вместе с параметром «веганская кухня».
6. Рендеринг: В SERP отображается мини-приложение агрегатора. Интерактивный элемент «Тип кухни» уже превентивно адаптирован (preemptively adapted) — фильтр «Веганская» предустановлен.
7. Результат: Пользователь видит релевантные опции быстрее, что сокращает время выполнения задачи.

Сценарий 2: Использование истории браузера при бронировании

1. Контекст: Пользователь ранее просматривал в браузере статьи о путешествии на Майорку (зафиксировано в browsing history data).
2. Текущий запрос: Пользователь вводит запрос [дешевые авиабилеты].
3. Извлечение параметра: Google извлекает parameter (пункт назначения=Майорка) из истории браузера.
4. Активация механизма: Идентифицируется subsidiary application (например, виджет Google Flights или стороннего агрегатора).
5. Рендеринг: Виджет поиска авиабилетов отображается в SERP с уже предзаполненным полем «Куда» значением «Майорка» (preemptively adapted).

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