Как Google позволял сторонним провайдерам внедрять специализированные результаты в выдачу по подписке пользователя (Google Subscribed Links)

Описание

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

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

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

Запатентована система и API (известный как «Google Subscribed Links»), позволяющий третьим сторонам определять спецификации результатов (ResultSpecs). Эти спецификации включают шаблоны запросов (Query Patterns) и шаблоны ответов (Response Templates), использующие структурированные данные (DataObjects), предоставляемые через XML-фиды. При совпадении запроса пользователя с шаблоном система генерирует специализированный результат. Ключевой особенностью является модель подписки (Subscribed Link), где пользователь часто должен разрешить показ результатов от конкретного провайдера.

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

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

• Определение данных: Сторонние провайдеры создают XML-фиды, содержащие базу знаний (DataObjects с атрибутами) и правила отображения (ResultSpecs).
• Сбор данных: Google сканирует (через Feed Crawl Server) и индексирует эти фиды на Data Servers.
• Подписка: Пользователи явно подписываются на интересующих их провайдеров (хотя упоминается и возможность авто-подписки).
• Обработка запроса: Когда пользователь выполняет поиск, Trust Server проверяет список его подписок.
• Сопоставление: Система проверяет, соответствует ли запрос какому-либо Query Pattern от подписанных провайдеров.
• Генерация и Внедрение: При совпадении система извлекает атрибуты из DataObjects, форматирует их согласно Response Template и внедряет результат в SERP.

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

Низкая для реализации / Высокая для концепции. Система «Google Subscribed Links», являющаяся прямой реализацией этого патента, была запущена, но впоследствии закрыта. Следовательно, описанный API и механизм подписки устарели. Однако патент имеет высокое фундаментальное значение. Концепции извлечения структурированных данных (DataObjects), сопоставления шаблонных запросов и генерации прямых ответов лежат в основе современных технологий, таких как Knowledge Graph, Schema.org (одним из авторов патента является R.V. Guha, ключевая фигура в Schema.org) и Rich Snippets.

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

(5/10). Прямое влияние на современные SEO-стратегии минимальное, поскольку описанный конкретный механизм (API для Subscribed Links) больше не используется. SEO-специалисты не могут взаимодействовать с этой системой. Однако патент имеет высокое стратегическое значение, демонстрируя ранние и фундаментальные усилия Google по интеграции структурированных данных и прямых ответов непосредственно в SERP, что критически важно для понимания эволюции поиска.

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

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

Attribute (Атрибут)

Параметр «имя-значение», связанный с DataObject. Используется для заполнения шаблона ответа. Например, атрибут max_speed_limit.

DataObject (Объект данных)

Единица структурированных данных, определенная провайдером. Представляет собой сущность с типом (например, «Highway»), уникальным ID, одним или несколькими QueryNames и набором Attributes.

Data Server (Сервер данных)

Сервер, хранящий базу знаний (DataObjects и ResultSpecs) и выполняющий сопоставление запросов с шаблонами.

Extract (Тег извлечения)

Тег в ResultSpec, позволяющий извлекать дополнительные DataObjects на основе атрибутов уже найденных объектов.

Feed Crawl Server (Сервер сканирования фидов)

Компонент, отвечающий за загрузку, парсинг и валидацию XML-файлов от поставщиков контента и передачу обновлений на Data Servers.

Query Pattern (Шаблон запроса)

Шаблон в теге <Query>, определяющий, какие запросы должны активировать специализированный результат. Например, «speed limit on [Highway]».

QueryName (Имя запроса)

Одна или несколько строк, по которым DataObject может быть распознан в запросе пользователя. Например, «101» и «US 101».

ResultSpec (Спецификация результата)

Основной блок конфигурации, предоставленный провайдером. Содержит Query Pattern и соответствующий Response Template.

Subscribed Link (Подписанная ссылка)

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

Trust Server (Сервер доверия)

Компонент системы, который управляет списком подписок пользователя (trusted list), запрашивает специализированные данные у Data Servers и рендерит их в HTML.

Validate (Тег валидации)

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

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

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

1. Система получает шаблон запроса (query pattern) для специализированного типа запроса. Этот шаблон включает:
   • Хотя бы один объект данных (data object) определенного типа.
   • Хотя бы одно имя запроса (query name), по которому объект распознается в запросе.
   • Хотя бы один атрибут (attribute) объекта для включения в результат.
2. Система получает шаблон специализированного результата (specialized results pattern), который использует атрибуты объекта данных.
3. Система сохраняет query pattern и specialized results pattern в хранилище.

Claim 10 (Независимый пункт): Описывает процесс обработки входящего запроса и генерации ответа.

1. Получение поискового запроса.
2. Сравнение запроса с сохраненным query pattern.
3. Если запрос совпадает с query name в шаблоне: генерация результата согласно specialized results pattern, включая атрибуты соответствующего data object.
4. Если запрос НЕ совпадает с шаблоном: генерация стандартного (generic) результата поиска.
5. Вывод сгенерированного результата.

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

1. Получение поискового запроса и сравнение его с query pattern.
2. Если запрос совпадает с query name в шаблоне:
   • Генерация специализированного результата по шаблону.
   • Генерация стандартного (generic) результата поиска.
3. Одновременный вывод (concurrently outputting) набора результатов, включающего как специализированный, так и стандартный результаты.

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

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

CRAWLING – Сканирование и Сбор данных
Feed crawl server отвечает за сканирование XML-файлов, предоставленных сторонними провайдерами, их парсинг и конвертацию во внутренний формат. Это альтернативный механизм сбора данных по сравнению со стандартным веб-краулингом.

INDEXING – Индексирование и извлечение признаков
Данные из XML-фидов (DataObjects и ResultSpecs) индексируются и сохраняются на Data servers. Индексация организована по провайдерам.

QUNDERSTANDING – Понимание Запросов
На этом этапе происходит сопоставление текста запроса с предопределенными шаблонами (Query Patterns). Система должна распознать литералы и извлечь сущности (DataObjects), соответствующие типам, указанным в шаблоне.

METASEARCH – Метапоиск и Смешивание / RERANKING – Переранжирование
Основное применение патента. Процесс работает параллельно основному ранжированию.

1. Проверка подписок: Trust Server получает запрос и ID пользователя, затем извлекает список провайдеров, на которых подписан пользователь (trusted list).
2. Извлечение результатов: Для подписанных провайдеров Trust Server запрашивает у Data Server специализированные результаты, соответствующие запросу.
3. Рендеринг и Смешивание: Trust Server рендерит полученные данные в HTML. Поисковая система (Search site) интегрирует этот HTML-блок в финальную SERP вместе со стандартными органическими результатами.

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

• Запрос пользователя и его ID.
• Список подписок пользователя (trusted list).
• XML-спецификации провайдеров (ResultSpecs, DataObjects).

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

• HTML-блок специализированного результата, готовый для вставки в SERP.

На что влияет

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

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

Алгоритм применяется только при выполнении строгого набора условий:

• Условие 1 (Идентификация пользователя): Пользователь должен быть идентифицирован (залогинен), чтобы система могла получить доступ к его списку подписок.
• Условие 2 (Наличие подписки): Пользователь должен быть подписан (явно или автоматически) на конкретного стороннего провайдера.
• Условие 3 (Совпадение шаблона): Запрос пользователя должен точно соответствовать Query Pattern, определенному этим провайдером.
• Условие 4 (Валидация, опционально): Извлеченные данные должны пройти проверку, если провайдер использовал Validate tag.

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

Процесс А: Офлайн-подготовка данных

1. Предоставление данных: Провайдеры предоставляют URL-адреса своих XML-фидов через Subscriber/provider server.
2. Сканирование: Feed crawl server загружает и парсит XML-файлы (ResultSpecs, DataObjects).
3. Индексирование: Данные валидируются, конвертируются во внутренний формат и сохраняются на Data Servers.

Процесс Б: Обработка запроса в реальном времени

1. Получение запроса: Пользователь вводит запрос на поисковом сайте.
2. Переадресация: Запрос и ID пользователя передаются через Front-end server на Trust Server(s).
3. Получение подписок: Trust Server получает список провайдеров, которым доверяет пользователь (trusted list).
4. Запрос специализированных данных: Trust Server отправляет запрос к соответствующим Data Servers для каждого доверенного провайдера.
5. Сопоставление и извлечение (на Data Server):
   • Запрос сопоставляется с Query Patterns.
   • При совпадении идентифицируются DataObjects (по QueryName) и извлекаются их Attributes.
   • (Опционально) Выполняются шаги Extract и Validate.
6. Получение и форматирование: Trust Server получает специализированные данные.
7. Рендеринг: Trust Server (или внешний компонент) рендерит данные в HTML формат согласно шаблону Response.
8. Агрегация: Front-end server передает HTML-результаты поисковой системе.
9. Генерация SERP: Поисковая система генерирует итоговую страницу, включая специализированные и стандартные результаты, и отправляет ее пользователю.

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

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

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

• Данные провайдеров (Структурные факторы из XML):
  • DataObjects: Структурированные сущности с типами, именами (QueryNames) и атрибутами (Attributes).
  • ResultSpecs: Правила, определяющие шаблоны запросов (Query) и форматы ответов (Response).
• Пользовательские факторы:
  • ID пользователя (для идентификации).
  • Список подписок пользователя (trusted list).
  • В патенте также упоминается возможность автоматической подписки (auto-subscription) на основе критериев: история поиска, демография, географическое положение, история посещения сайтов, платформа браузера/ОС.
• Встроенные типы данных: Система предоставляет встроенные типы объектов (например, City, date, timeofday), которые провайдеры могут использовать в своих шаблонах.

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

Метрики ранжирования не используются. Система основана на точном сопоставлении и логических правилах.

• Сопоставление шаблонов (Pattern Matching): Основной механизм. Используется точное совпадение текста запроса с Query Patterns. Поддерживаются:
  • Литеральное совпадение (LiteralKeywordMatcher).
  • Совпадение с типами данных (KBObjectMatcher).
  • Регулярные выражения (Perl Compatible Regular Expressions — PCREs).
• Извлечение сущностей (Entity Extraction): Идентификация DataObjects в запросе путем поиска токенов запроса в базе знаний провайдера. Используется тег Extract для последовательного извлечения связанных объектов.
• Валидация (Validation): Использование тега Validate для сравнения атрибутов двух разных извлеченных объектов. Результат отображается только при их совпадении (обеспечивает логическую согласованность).
• Ссылочные атрибуты (Reference Attributes): Возможность использовать значение атрибута одного объекта как ссылку (ID) на другой объект, что позволяет строить связи между сущностями.

Выводы

1. Фундамент структурированных данных в поиске: Патент демонстрирует раннюю стратегию Google по интеграции структурированных данных от третьих сторон для предоставления прямых ответов. Концепции DataObjects и Attributes являются прямыми предшественниками сущностей и свойств в Schema.org и Knowledge Graph.
2. Модель «Сущность-Атрибут»: Центральная идея патента — использование модели данных, основанной на сущностях и их атрибутах, что является ключевым принципом работы современного семантического поиска.
3. Персонализация через подписки (Opt-in): Система полагалась на модель явной подписки (Subscribed Links), где пользователь сам выбирал доверенные источники. Это отличается от современных систем, где Google автоматически определяет, какие SERP-функции показывать.
4. Обход традиционного ранжирования: Специализированный результат генерировался на основе точного сопоставления с шаблоном и наличия подписки, а не на основе стандартных сигналов релевантности или авторитетности.
5. Важность механизмов прямой подачи данных (Фиды): Система использует Feed crawl server для получения XML-фидов. Это демонстрирует важность механизмов прямой подачи данных в дополнение к стандартному сканированию веб-страниц.

Практика

ВАЖНОЕ ЗАМЕЧАНИЕ

Описанная в патенте система (Google Subscribed Links) устарела и была закрыта Google. Прямое практическое применение описанных методов (создание XML-фидов через этот API) в современном SEO невозможно. Приведенный ниже анализ фокусируется на концептуальном значении патента и его связи с современными практиками.

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

• Внедрение структурированных данных (Schema.org): Патент подчеркивает фундаментальную важность предоставления структурированных данных (аналогичных DataObjects и Attributes). Сегодня это реализуется через разметку Schema.org. Это подтверждает критическую важность качественного внедрения микроразметки для попадания в Rich Snippets.
• Мыслить сущностями (Entity-First Strategy): Необходимо определять ключевые сущности бизнеса и их атрибуты. Работа над SEO должна фокусироваться на оптимизации этих сущностей и их связей, что соответствует концепции DataObjects и Reference Attributes.
• Анализ шаблонных запросов (Patterned Queries): Изучайте запросы, имеющие шаблонную структуру в вашей тематике (например, «[Product] характеристики», «[City] погода»). Убедитесь, что ваш контент и разметка оптимально соответствуют этим шаблонам, чтобы системы Google могли легко извлечь необходимую информацию для прямых ответов.
• Использование фидов данных в вертикалях: В E-commerce, Travel и других вертикалях активно используйте фиды данных (например, Google Merchant Center). Патент подтверждает, что Google имеет инфраструктуру для обработки данных, поставляемых напрямую через фиды.

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

• Игнорирование микроразметки: Полагаться исключительно на неструктурированный текст. Патент показывает, что Google давно ищет способы извлекать факты и структурированные ответы напрямую, что может снижать CTR стандартных результатов.
• Предоставление неточных или противоречивых данных: Система полагается на точность Attributes. Механизмы валидации (Validate) подчеркивают важность согласованности данных. Ошибки в микроразметке могут привести к игнорированию данных.
• Попытки использовать устаревшие API: Не тратьте ресурсы на создание XML-фидов по спецификации из этого патента для основного поиска, так как система неактивна.

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

Патент является ключевым историческим документом, демонстрирующим эволюцию поиска от списка ссылок к системе ответов, основанной на сущностях. Участие R.V. Guha подчеркивает прямую связь этого патента с глобальной стратегией Google по структурированию веба (Schema.org). Для Senior SEO-специалистов это подтверждает, что инвестиции в глубокое понимание и качественную имплементацию структурированных данных являются фундаментально важными.

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

Поскольку описанная система «Subscribed Links» не используется, приведем пример того, как концепции патента применяются в современных реалиях (Schema.org).

Сценарий: Оптимизация страницы рецепта для Rich Snippet

1. Анализ (в терминах патента):
   • Определить DataObject: Тип «Recipe» (Рецепт).
   • Определить Attributes: «cookTime» (Время приготовления), «ingredients» (Ингредиенты), «rating» (Рейтинг).
   • Определить Query Pattern: Запросы вида «[Название блюда] рецепт».
2. Действие (современная реализация): Имплементировать разметку Schema.org/Recipe на странице с помощью JSON-LD. Заполнить свойства cookTime, recipeIngredient, aggregateRating.
3. Ожидаемый результат: При запросе, соответствующем шаблону (например, «рецепт лазаньи»), Google может использовать эти структурированные данные (Attributes) для генерации специализированного результата (Rich Snippet) с отображением времени приготовления и рейтинга прямо в SERP.

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