Как Google агрегирует данные из разных индексов для создания специализированной выдачи по медиазапросам (Фильмы, Сериалы)

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

Media-related object (Медиа-связанный объект)

Сущность, к которой относится запрос, такая как телевизионная программа, фильм, актер или режиссер.

Plurality of different corpuses (Множество различных корпусов)

Несколько различных источников данных или индексов, которые система опрашивает параллельно. Например, веб-индекс, индекс изображений, база данных структурированной информации.

Structured corpus (Структурированный корпус)

База данных, содержащая организованную информацию о медиаобъектах, такую как расписание программ, списки актеров, даты выхода.

Unstructured corpus (Неструктурированный корпус)

Неструктурированные данные, такие как контент веб-страниц (веб-индекс).

One Box

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

Page Formatter (Формировщик страницы)

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

Head End (Головная станция/Провайдер)

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

Crawler и Classifier (Краулер и Классификатор)

Компоненты для сбора контента из сети (Crawler) и его последующего анализа и категоризации (Classifier) для хранения в соответствующих корпусах.

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

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

1. Система получает первый поисковый запрос и определяет, является ли он медиа-связанным (media-related).
2. Если ДА: Идентифицируется media-related object.
3. Система собирает результаты поиска из plurality of different corpuses. (Результаты включают список эпизодов, даты/время показов, обзор программы, а также веб-контент/изображения, полученные через второй запрос, основанный на первом).
4. Генерируется код для форматирования этих разнородных результатов для совместного отображения на веб-странице.
5. Формат отображения отличается от формата для запросов, которые не были определены как медиа-связанные.
6. Код обеспечивает отображение результатов из каждого корпуса в отдельной, отличной от других области дисплея (distinct area).

Claim 3 (Зависимый от 1): Уточняет типы корпусов. Сбор данных происходит как минимум из одного структурированного (structured corpus) и одного неструктурированного корпуса (unstructured corpus).

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

1. Получение запроса и определение его связи с медиапрограммой.
2. Отправка запросов к поисковым системам, адресующим множество корпусов. Подчеркивается, что для каждого корпуса выполняется отдельный поиск (separate search is conducted for each corpus).
3. Получение множества результатов в ответ на эти отдельные поиски.
4. Агрегация результатов из разных корпусов для одновременного отображения в смежных областях (adjacent areas).
5. Агрегация включает идентификацию отдельных областей (distinct areas) для группировок результатов из каждого корпуса и генерацию кода для создания веб-страницы.

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

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

CRAWLING и INDEXING
На этих этапах Crawler собирает данные (веб-страницы, изображения, данные от провайдеров расписаний). Classifier определяет тип контента и направляет его в соответствующие корпусы (Structured corpus, Unstructured corpus, индекс изображений).

QUNDERSTANDING – Понимание Запросов
Система должна определить, что запрос является media-related (триггер для активации механизма) и идентифицировать соответствующий media-related object (сущность).

RANKING – Ранжирование
Система генерирует внутренние запросы и отправляет их параллельно в соответствующие корпусы. Каждый корпус (Веб, Картинки, Структурированные данные) выполняет свой собственный поиск и ранжирование.

METASEARCH – Метапоиск и Смешивание
Это основной этап применения патента. Search result aggregator (часть Page Formatter) собирает Топ-N результаты от каждого задействованного корпуса. Page Formatter определяет макет (layout) страницы и генерирует код (Markup) для отображения агрегированных результатов в едином интерфейсе (например, One Box или детальная страница сущности).

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

• Исходный поисковый запрос пользователя.
• Данные из различных корпусов.
• Информация о пользователе (местоположение для определения локального Head end).

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

• Код (Markup) для отображения агрегированной страницы, содержащей результаты из множества различных источников.

На что влияет

• Конкретные типы контента и ниши: В первую очередь влияет на отображение информации о сущностях в нише развлечений (Entertainment), таких как фильмы, сериалы, актеры, режиссеры.
• Специфические запросы: Информационные и навигационные запросы, связанные с медиа-сущностями (например, "the tonight show", "актеры сериала lost").
• Определенные форматы контента: Патент описывает архитектуру, которая позволяет создавать SERP features, такие как Knowledge Panels, карусели изображений и видео, списки эпизодов и расписания показов.

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

• Триггеры активации: Алгоритм активируется, когда система с достаточной уверенностью определяет, что запрос является media-related.
• Условия работы алгоритма: В описании патента указано, что это может быть основано на совпадении с терминами в "белом списке" (whitelist) медиа-терминов, использовании специальных префиксов (например, "tv:") или наличии в запросе других индикаторов (название телесети, имя актера).

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

1. Получение запроса: Система получает поисковый запрос от пользователя.
2. Определение типа запроса: Система анализирует запрос, чтобы определить, является ли он медиа-связанным.
3. Обработка не-медиа запроса: Если запрос не связан с медиа, возвращаются стандартные результаты поиска.
4. Идентификация медиаобъекта: Если запрос связан с медиа, система идентифицирует соответствующий media-related object (сущность).
5. Определение контекста (Опционально): Проверяется местоположение пользователя или его провайдер (Head end) для локализации расписаний.
6. Параллельный поиск по корпусам: Система генерирует и отправляет один или несколько внутренних запросов к различным корпусам данных. Для каждого корпуса выполняется отдельный поиск. Может генерироваться вторичный запрос для поиска изображений.
7. Сбор результатов: Система получает наборы результатов от каждого корпуса.
8. Агрегация результатов: Компонент Page Formatter агрегирует полученные разнородные результаты.
9. Генерация интерфейса: Page Formatter генерирует код для отображения агрегированных результатов в едином интерфейсе. Интерфейс структурирован так, чтобы выделять отдельные области (distinct areas) для каждого типа данных.
10. Отображение: Агрегированная страница предоставляется пользователю.

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

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

Патент фокусируется на агрегации данных из различных источников:

• Контентные факторы (Неструктурированный корпус): Текст веб-страниц, сниппеты, URL. Используются для заполнения блока веб-результатов (Web Data).
• Структурные факторы (Структурированный корпус): Критически важные данные. Включают расписания программ (Scheduled Data), метаданные фильмов и сериалов (актеры, режиссеры, даты выхода), биографии (Structured Media Content).
• Мультимедиа факторы: Изображения и видео, полученные из соответствующих индексов (Image corpus, Video corpus).
• Географические факторы / Пользовательские факторы: Упоминается использование информации о местоположении пользователя и провайдере услуг (Head end) для локализации результатов, в частности, расписаний ТВ-программ.

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

Патент описывает архитектуру агрегации и форматирования, а не метрики ранжирования.

• Определение медиа-интента: Система использует метрику (не детализированную в патенте) для определения, является ли запрос media-related. Упоминается использование "белого списка" (whitelist) терминов.

Конкретные формулы или алгоритмы расчета оценок ранжирования внутри каждого корпуса в патенте не приводятся.

1. Архитектура Универсального Поиска: Патент описывает фундаментальный механизм того, как Google реализует Universal Search и Blended Search для специфических вертикалей, в данном случае — медиа. Это не алгоритм ранжирования, а механизм формирования выдачи.
2. Параллельный опрос множественных корпусов: Ключевой концепцией является одновременный опрос различных индексов (plurality of different corpuses) — веб, картинки, структурированные данные — для ответа на один запрос пользователя.
3. Идентификация интента как триггер: Определение запроса как media-related переключает логику обработки запроса со стандартного поиска на специализированный процесс агрегации и меняет формат представления результатов.
4. Фокус на сущностях (Entity-Oriented): Патент демонстрирует подход, ориентированный на идентификацию сущностей (media-related object) и агрегацию всей доступной информации вокруг них. Это является архитектурной основой для работы Knowledge Graph и отображения Knowledge Panels.
5. Важность структурированных данных: Явное разделение на structured corpus и unstructured corpus подчеркивает, что структурированные данные критически важны для формирования информативных и точных агрегированных ответов.

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

• Оптимизация под сущности (Entity Optimization): Необходимо работать над тем, чтобы ваши медиа-сущности (фильмы, сериалы, ключевые персоны) были четко определены и распознаны Google. Это увеличивает вероятность формирования агрегированной выдачи по связанным запросам и использования вашего контента в ней.
• Использование структурированных данных (Schema.org): Активно внедряйте микроразметку (Movie, TVSeries, Episode, Person), чтобы предоставлять Google данные для Structured corpus. Это помогает заполнять блоки с расписаниями, списками актеров и эпизодов в агрегированной выдаче.
• Оптимизация в вертикальных поисках (Images/Video SEO): Поскольку система агрегирует данные из разных корпусов, критически важно иметь сильное присутствие в Google Images и Video/YouTube. Оптимизируйте изображения (постеры, кадры) и видео (трейлеры, обзоры) — их метаданные, качество и релевантность — чтобы они отбирались для показа в агрегированных блоках.
• Обеспечение согласованности данных: Убедитесь, что информация о сущности согласована на вашем сайте, в социальных сетях и авторитетных базах данных (например, iMDB, Wikipedia), чтобы укрепить сигналы для Structured corpus.

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

• Игнорирование вертикальных поисков: Фокусировка исключительно на ранжировании в основном веб-поиске и игнорирование оптимизации изображений и видео. Это приведет к потере видимости в агрегированных блоках, которые часто занимают значительную часть выдачи по медиазапросам.
• Отсутствие или ошибки в микроразметке: Непредоставление структурированных данных для медиаконтента усложняет Google извлечение точной информации для заполнения специализированных блоков, снижая шансы на участие в агрегированной выдаче.
• Фокус только на ключевых словах, а не на сущностях: Оптимизация страниц под текстовые запросы без учета связей между сущностями. Система работает на уровне объектов (media-related object), поэтому важно выстраивать эти связи.

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

Патент подтверждает стратегию Google по переходу от выдачи в виде "10 синих ссылок" к богатой, агрегированной выдаче, основанной на сущностях и намерениях пользователя. Он описывает архитектуру, которая позволяет Google отвечать на запрос, используя наиболее подходящие типы контента из разных индексов. Для Senior SEO-специалистов это подчеркивает необходимость мыслить за пределами традиционного веб-поиска и фокусироваться на общей видимости сущности (Entity Visibility) во всех релевантных корпусах данных Google (Web, Images, Video, Structured Data).

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

Сценарий: Оптимизация страницы нового сериала на сайте стримингового сервиса.

1. Цель: Максимизировать видимость сериала в агрегированной выдаче Google по его названию.
2. Действия по Structured Corpus: Внедрить детальную разметку Schema.org (TVSeries для главной страницы сериала, Episode для каждой серии с указанием дат выхода, Person для актеров).
3. Действия по Image Corpus: Подготовить высококачественные постеры и кадры. Оптимизировать их (размер, формат, alt-тексты, названия файлов) и разместить на страницах сериала и эпизодов. Добавить их в Image Sitemap.
4. Действия по Video Corpus: Разместить официальный трейлер на YouTube, оптимизировать его заголовок и метаданные. Внедрить разметку VideoObject на сайте.
5. Ожидаемый результат: При запросе названия сериала Google формирует агрегированную выдачу (Knowledge Panel или специализированный блок). Данные из микроразметки используются для заполнения списка эпизодов и информации об актерах. Оптимизированные изображения попадают в карусель Google Images, а трейлер — в блок Google Video. Сайт сервиса получает видимость через эти агрегированные элементы.