Как Google использует фиды данных для связи продуктов и услуг с сущностями в Knowledge Graph и показа коммерческих предложений в Knowledge Panel

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

Auction Module (Аукционный модуль)

Компонент системы, отвечающий за проведение аукционов контента на основе ключевых слов запроса или пар Entity-Action Pairs.

Auction Parameters (Параметры аукциона)

Данные, контролирующие участие в аукционе от имени поставщика контента: ставки (bids), бюджеты, расписание, таргетинг. Могут быть специфичными для конкретной пары Entity-Action Pair.

Entity-Action Identifier (Идентификатор сущности-действия)

Компонент, который (1) в офлайн-режиме сопоставляет элементы фида с сущностями и действиями; (2) в онлайн-режиме определяет релевантные сущности и действия на основе поискового запроса.

Entity-Action Pair (Пара сущность-действие)

Структура данных, связывающая Search Entity с конкретным Online Action. Например, {Фильм X, Стриминг} или {Фильм X, Покупка DVD}.

Feed (Фид данных)

Структурированный файл (TXT, XML, JSON и т.д.), загружаемый поставщиком контента и содержащий каталог его предложений (товаров, услуг, медиаконтента).

Feed Analyzer (Анализатор фида)

Компонент, который принимает, валидирует и обрабатывает загруженный фид, передавая элементы на идентификацию.

Feed Item (Элемент фида)

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

Knowledge Graph (Граф знаний)

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

Knowledge Panel (Панель знаний)

Блок на странице результатов поиска, отображающий информацию о конкретной сущности, включая факты и результаты аукционов по Entity-Action Pairs.

Online Action (Онлайн-действие)

Действие, которое пользователь может совершить в отношении сущности онлайн (например, стриминг, покупка, бронирование, подписка).

Search Entity (Поисковая сущность)

Концепция, представляющая именованную сущность в реальном мире (человек, место, фильм, продукт и т.д.).

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

Патент содержит утверждения, описывающие как онлайн-процесс обработки запроса и проведения аукционов, так и офлайн-процесс загрузки и обработки фидов.

Claim 1 (Независимый пункт): Описывает процесс использования Entity-Action Pairs в реальном времени при обработке запроса.

1. Система поддерживает множество Entity-Action Pairs и специфические параметры ставок (bidding parameters) для каждой пары.
2. Получается первый поисковый запрос, содержащий термин, указывающий на первую поисковую сущность (E1).
3. В ответ на запрос идентифицируются как минимум две различные пары для этой сущности: первая пара {E1, Действие 1} и вторая пара {E1, Действие 2}.
4. Идентифицируется вторая поисковая сущность (E2), не указанная в запросе, но связанная с E1 через Knowledge Graph.
5. Проводятся два отдельных аукциона: первый аукцион для {E1, Действие 1} на основе параметров ставок, специфичных для этой пары, и второй аукцион для {E1, Действие 2} на основе параметров ставок, специфичных для второй пары.
6. Определяются наборы стороннего контента для участия в каждом аукционе. Этот контент включает исполняемые инструкции (executable instructions) для автоматического выполнения соответствующего действия приложением на клиентском устройстве при активации.
7. Выбираются победители: первый элемент контента на основе ставок для Действия 1 и второй элемент контента на основе ставок для Действия 2.
8. Выбирается ссылка, связанная со второй сущностью (E2).
9. Победители аукционов и ссылка на E2 предоставляются для отображения с результатами поиска. Активация ссылки на E2 заменяет исходный запрос на новый запрос, связанный с E2.

Claim 2 (Зависимый от 1): Детализирует офлайн-процесс генерации данных, используемых в Claim 1, посредством загрузки фида.

1. Система получает файл данных (фид) от поставщика стороннего контента. Фид содержит элементы контента, каждый из которых включает идентификационные данные, тип элемента и онлайн-действие, и связан с продуктом или услугой поставщика.
2. На основе идентификационных данных и типа элемента идентифицируется первая поисковая сущность (соответствующая именованной физической сущности).
3. На основе файла данных генерируется первая пара Entity-Action Pair, включающая идентифицированную сущность и онлайн-действие из элемента фида.
4. Эта пара ассоциируется с первым параметром ставки, специфичным для данной пары.

Claims 3, 5, 6 (Зависимые от 2): Описывают генерацию журналов ошибок и успехов. Система генерирует логи для элементов фида, которые (3) соответствуют множеству сущностей, (5) не соответствуют ни одной сущности, или (6) успешно сопоставлены с единственной сущностью.

Claim 4 (Зависимый от 2): Уточняет, что идентификация поисковой сущности включает поиск в Knowledge Graph.

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

Изобретение охватывает инфраструктуру обработки данных (офлайн) и процесс обработки запросов (онлайн).

INDEXING – Индексирование (и связанные системы обработки данных/рекламы)
Основная часть работы по обработке фидов происходит на этом этапе (офлайн). Feed Analyzer принимает и валидирует фиды. Entity-Action Identifier использует данные из Knowledge Graph (который поддерживается на этапе индексирования) для сопоставления элементов фида с сущностями. Сгенерированные Entity-Action Pairs сохраняются и ассоциируются с Auction Parameters.

QUNDERSTANDING – Понимание Запросов
На этом этапе (онлайн) Search Query Analyzer и Entity-Action Identifier анализируют запрос пользователя для выявления основной сущности и релевантных действий (интента).

RANKING / METASEARCH – Ранжирование и Метапоиск
После идентификации релевантных Entity-Action Pairs система запускает Auction Module для проведения параллельных, независимых аукционов для каждого действия. Результаты этих аукционов затем смешиваются (blending) с основными результатами поиска. Layout Generator определяет, как отобразить эти результаты, чаще всего в рамках Knowledge Panel.

Входные данные (Офлайн):

• Фид данных (Feed) от поставщика контента.
• Auction Parameters (ставки, кампании).
• Данные Knowledge Graph.

Выходные данные (Офлайн):

• Сгенерированные Entity-Action Pairs, связанные с параметрами аукциона.
• Отчеты об ошибках сопоставления (Reports).

Входные данные (Онлайн):

• Поисковый запрос пользователя.

Выходные данные (Онлайн):

• Результаты поиска, включающие Knowledge Panel с выбранным сторонним контентом (победителями аукционов).

На что влияет

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

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

Алгоритм применяется при выполнении следующих условий:

• Триггеры активации (Онлайн): Поисковый запрос пользователя тесно связан с известной Search Entity. Система также определяет, что для этой сущности существуют релевантные Online Actions.
• Наличие данных (Офлайн): Сторонние поставщики загрузили фиды данных, которые были успешно обработаны и сопоставлены с соответствующими Entity-Action Pairs, и для этих пар заданы активные Auction Parameters.

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

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

1. Получение фида: Система получает фид данных от поставщика контента.
2. Валидация: Feed Analyzer проверяет формат фида и наличие обязательных полей в элементах фида (Feed Items).
3. Идентификация сущности: Для каждого элемента фида Entity-Action Identifier использует идентификационные данные (название, уникальные ID, тип) для поиска соответствующей уникальной Search Entity в Knowledge Graph.
4. Обработка ошибок сопоставления:
   • Если сущность не найдена ИЛИ найдено несколько сущностей, генерируется ошибка для отчета.
   • Если найдена уникальная сущность, процесс продолжается.
5. Идентификация действия: Система определяет Online Action на основе данных в фиде (явно указанное действие или вывод на основе URL/цены).
6. Генерация пары: Генерируется Entity-Action Pair.
7. Ассоциация с аукционом: Сгенерированная пара связывается с Auction Parameters (например, привязывается к существующей рекламной кампании и её ставкам).
8. Отчетность: Генерируются отчеты (Reports) об успешных сопоставлениях и ошибках.

Процесс Б: Онлайн-обработка запроса и аукцион

1. Получение запроса: Система получает поисковый запрос от пользователя.
2. Анализ запроса: Search Query Analyzer генерирует стандартные результаты поиска.
3. Идентификация сущности и действий: Entity-Action Identifier определяет основную сущность запроса (E1) и релевантные Online Actions (A1, A2...), а также связанные сущности (E2).
4. Запуск аукционов: Если для релевантных действий существуют данные в системе, Auction Module запускает отдельные аукционы для каждой пары (например, аукцион для {E1, A1} и отдельный аукцион для {E1, A2}).
5. Выбор победителей: Для каждого аукциона выбираются победители на основе ставок и, возможно, показателей качества (Quality Score).
6. Генерация выдачи: Layout Generator формирует итоговую страницу, включая стандартные результаты, Knowledge Panel с фактами о E1, контент победителей аукционов для A1 и A2, и ссылки на связанные сущности E2.

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

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

Патент фокусируется на использовании структурированных данных из фидов.

• Структурные и Контентные факторы (из фида):
  • Feed Item ID: Уникальный идентификатор элемента в фиде.
  • Type: Тип элемента (movie, album, song, book).
  • Идентификаторы сущности: Название (Movie title), год выпуска (Release year), уникальные отраслевые идентификаторы (например, MID для фильмов, ISBN для книг, GTIN для товаров).
  • Action: Название действия (subscribe, purchase, stream, book).
  • Landing Page: URL страницы, где можно совершить действие.
  • Price / Subscription period: Цена и период подписки.
• Системные данные:
  • Knowledge Graph Data: Факты и связи о сущностях, используемые для сопоставления.
  • Auction Parameters: Ставки (bids), бюджеты, данные кампаний.

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

• Метрики сопоставления сущностей: Система использует эвристики или модели машинного обучения для поиска в Knowledge Graph и определения степени соответствия между элементом фида и сущностью. Точность сопоставления критична.
• Метрики аукциона: Стандартные метрики для выбора контента (рекламы). Патент упоминает использование ставок (bids) и возможность использования показателей качества (Quality Score), таких как CTR, для определения победителя аукциона. Также упоминаются резервные цены (Reserve Prices).
• Ранжирование действий: В онлайн-режиме система может ранжировать различные Online Actions, связанные с сущностью, на основе их релевантности поисковому запросу.

1. Инфраструктура для Entity-Based Advertising: Патент описывает ключевую часть инфраструктуры Google для монетизации Knowledge Graph. Он показывает, как Google переходит от рекламы на основе ключевых слов к рекламе на основе сущностей и действий.
2. Автоматизация и масштабирование через фиды: Ключевым элементом является автоматическая обработка больших объемов данных через фиды, что позволяет поставщикам легко управлять тысячами предложений без ручной настройки для каждой сущности.
3. Критичность уникальных идентификаторов: Для точного сопоставления (matching) элементов фида с сущностями в Knowledge Graph критически важно использование уникальных отраслевых идентификаторов (GTIN, ISBN, MIDs и т.д.). Неоднозначные данные (например, только название) ведут к ошибкам сопоставления (Multiple matches или Unknown entity).
4. Разделение аукционов по действиям: Система намеренно разделяет аукционы для разных Online Actions (например, стриминг vs покупка). Это создает отдельные рынки для разных бизнес-моделей, связанных с одной и той же сущностью.
5. Механизм наполнения Knowledge Panel: Патент детально объясняет, как коммерческие предложения (ссылки на стриминг, магазины, бронирование) попадают в Knowledge Panel. Это результат успешной обработки фида и победы в аукционе по конкретной паре Entity-Action Pair.

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

• Использование структурированных фидов данных: Для e-commerce, медиа-сервисов, систем бронирования необходимо использовать структурированные фиды (Google Merchant Center, Hotel Ads Feeds, Media Actions feeds и т.д.) для передачи информации о предложениях. Это основной механизм для попадания в коммерческие блоки Knowledge Panel.
• Максимальное использование уникальных идентификаторов: Всегда включайте в фиды глобальные уникальные идентификаторы (GTIN для товаров, ISBN для книг, специфические ID для медиа, например EIDR). Это радикально повышает точность сопоставления с сущностями в Knowledge Graph и минимизирует ошибки типа «Unknown Search Entity» или «Multiple Search Entity Matches».
• Точность и полнота данных в фиде: Убедитесь, что данные о ценах, наличии, URL целевых страниц (Landing Pages) и типах действий (Action) точны и актуальны. Это напрямую влияет на участие в аукционе и пользовательский опыт.
• Оптимизация сущностей (Entity SEO): Работайте над тем, чтобы ваши продукты, услуги или контент были четко распознаваемы как сущности в Knowledge Graph. Используйте микроразметку Schema.org на сайте, чтобы помочь Google понять ваши сущности и их атрибуты, что может улучшить процесс сопоставления фидов.

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

• Предоставление неоднозначных данных в фидах: Загрузка фидов, содержащих только названия сущностей без уникальных идентификаторов или уточняющих атрибутов (например, год выпуска фильма). Это приводит к ошибкам сопоставления и потере показов.
• Игнорирование отчетов об ошибках: Не отслеживать и не исправлять ошибки в обработке фидов, о которых сообщает система (как описано в патенте).
• Фокус только на ключевых словах в платных кампаниях: Полагаться исключительно на традиционные кампании по ключевым словам и игнорировать возможности, предоставляемые через фиды и Entity-Action Pairs для показа в Knowledge Panel.

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

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

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

Сценарий: Оптимизация фида для интернет-магазина книг

1. Проблема: Магазин загружает фид в Google Merchant Center, указывая только название книги и автора. В отчетах появляется много ошибок «Multiple Search Entity Matches».
2. Анализ (на основе патента): Система не может однозначно сопоставить элемент фида с сущностью в Knowledge Graph, так как существуют разные издания или книги с похожими названиями.
3. Решение: Модифицировать процесс генерации фида, чтобы включить уникальный идентификатор ISBN (International Standard Book Number) для каждой книги в поле GTIN.
4. Ожидаемый результат: Entity-Action Identifier использует ISBN для точного сопоставления. Количество ошибок уменьшается, увеличивается охват показа предложений магазина в Knowledge Panel по запросам об этих книгах (пара {Книга X, Купить}).

Сценарий: Показ предложений стримингового сервиса

1. Цель: Стриминговый сервис хочет, чтобы его предложение отображалось в блоке «Смотреть сейчас» в Knowledge Panel для фильмов из его каталога.
2. Действие (на основе патента): Сервис формирует специализированный медиа-фид (Media Actions feed), где для каждого фильма указан его идентификатор (например, EIDR), тип действия (Action: WATCH), цена/тип подписки и прямая ссылка (Deep Link) на просмотр фильма на платформе.
3. Результат: Google обрабатывает фид, генерирует Entity-Action Pairs ({Фильм X, Смотреть}) и связывает их с рекламной кампанией сервиса. При поиске фильма Google проводит аукцион среди всех сервисов, предоставивших данные для этого действия, и показывает победителей в Knowledge Panel.