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

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

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.