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

Описание

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

Патент решает проблему эффективного и точного сопоставления большого объема инвентаря третьих сторон (товаров, медиаконтента, услуг) с конкретными Search Entities (сущностями в Knowledge Graph). Он также решает проблему конкуренции в рекламных аукционах: система позволяет поставщикам разных услуг, связанных с одной и той же сущностью (например, стриминг фильма против продажи DVD), конкурировать в отдельных аукционах, привязанных к конкретным действиям (Online Actions), а не только к общим ключевым словам.

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

Запатентована система и метод для обработки структурированных фидов данных (Feeds). Система анализирует элементы фида (Feed Items), содержащие идентификационные данные, тип элемента и предполагаемое онлайн-действие. Ключевым элементом изобретения является механизм точного разрешения (matching) этих элементов в уникальные Search Entities и генерации пар «сущность-действие» (Entity-Action Pairs). Эти пары затем используются для выбора контента, часто через механизм аукциона.

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

Система работает в несколько этапов:

• Получение фида: Третья сторона (например, стриминговый сервис) загружает фид, содержащий инвентарь (например, список фильмов) с идентификаторами, ценами и целевыми страницами.
• Разрешение сущностей: Система анализирует каждый элемент фида и использует идентификаторы (identification data) и тип элемента (item type) для поиска уникального соответствия в графе знаний (Knowledge Graph).
• Генерация пар: Для успешных соответствий генерируется Entity-Action Pair, например, {Фильм «Шериф Боб», Подписаться на сервис}.
• Привязка к аукциону: Эти пары связываются с параметрами аукциона (Auction Parameters), заданными поставщиком.
• Обработка запроса: Когда пользователь ищет сущность (например, «Шериф Боб»), система определяет релевантные действия и проводит отдельные аукционы для каждого действия (один для стриминга, другой для покупки DVD), используя сгенерированные пары.

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

Высокая. Механизмы, описанные в патенте, лежат в основе современных функций поиска, таких как Google Shopping, блоки «Смотреть сейчас» (Watch Now) для фильмов и сериалов, бронирование отелей и ресторанов. Точное сопоставление структурированных данных с сущностями Knowledge Graph является критически важным элементом для транзакционного и интерактивного поиска. Патент также явно упоминает обработку голосовых запросов.

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

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

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

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

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

Настройки, предоставленные третьей стороной, которые контролируют участие в аукционе контента (например, ставки, бюджеты, таргетинг). Они связываются с Entity-Action Pairs.

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

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

Feed (Фид)

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

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

Отдельная запись в фиде, соответствующая конкретному предложению. Включает Identification Data, Feed Item Type и Online Action.

First-party Content (Основной контент)

Контент, непосредственно запрошенный пользователем, например, стандартные результаты поиска (синие ссылки).

Identification Data (Идентификационные данные)

Данные в Feed Item, используемые для сопоставления с Search Entity (например, название, дата выпуска, уникальные идентификаторы типа GTIN или MID).

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

Упоминается как структурированный граф, используемый в семантическом поиске, где узлы представляют Search Entities, а связи — отношения между ними. Используется для разрешения элементов фида.

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

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

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

Уникальный идентификатор, соответствующий именованной сущности в реальном мире (человек, место, фильм, товар и т.д.). Ядро Knowledge Graph.

Third-party Content (Сторонний контент)

Дополнительный контент, предоставляемый в сочетании с основным, часто спонсируемый (например, реклама, ссылки на покупку в Knowledge Panel).

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

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

Claim 1 и Claim 11 (Независимые пункты): Описывают комплексную систему от получения запроса до показа контента.

1. Система получает поисковый запрос от клиентского устройства (явно указано, что запрос может быть получен через микрофон).
2. Система использует предварительно обработанный фид данных от первого поставщика. Обработка фида включает:
   1. Идентификацию элемента фида (с данными ID, типом и действием).
   2. Определение первой Search Entity на основе данных ID и типа.
   3. Генерацию первой пары Entity-Action Pair (Сущность 1 + Действие 1).
   4. Ассоциацию этой пары с первым параметром ставки (bidding parameter), специфичным для этой пары.
3. Система определяет, что запрос содержит термин, указывающий на первую Search Entity.
4. В ответ на это система идентифицирует несколько релевантных пар: Первую пару (Сущность 1 + Действие 1), Вторую пару (Сущность 1 + Действие 2, где Действие 2 отличается от Действия 1) и Третью пару (Сущность 2 + Действие 1). Каждая пара имеет свои параметры ставок.
5. Система определяет, на основе сравнения соответствующих Online Actions, что нужно провести первый аукцион контента для Первой и Третьей пар (у них одинаковое Действие 1), исключая Вторую пару (у нее другое Действие 2).
6. Проводится первый аукцион.
7. Первая пара выбирается на основе сравнения параметров ставок Первой и Третьей пар.
8. Система предоставляет клиентскому устройству контент от первого поставщика в ответ на выбор Первой пары.

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

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

Изобретение охватывает процессы обработки данных как на этапе подготовки индекса, так и на этапе обработки запроса.

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

QUNDERSTANDING – Понимание Запросов
Search Query Analyzer анализирует входящий запрос (текстовый или голосовой) для идентификации релевантных Search Entities.

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

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

• Структурированные фиды (Feeds) от третьих сторон.
• Auction Parameters (ставки, бюджеты).
• Knowledge Graph (база сущностей и связей).
• Поисковый запрос пользователя (Search Query).

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

• База данных Entity-Action Pairs, привязанных к поставщикам.
• Отчеты об ошибках обработки фидов (Reports).
• Результаты аукционов (выбранный сторонний контент).
• Сформированная страница результатов (Result Data) с интегрированными действиями.

На что влияет

• Конкретные типы контента и ниши: Наибольшее влияние оказывается на сферы, где инвентарь хорошо структурирован и может быть связан с конкретными сущностями:
  • Медиа: Фильмы, сериалы, музыка (стриминг, покупка цифровых копий).
  • E-commerce: Товары (покупка).
  • Локальный поиск и услуги: Рестораны, отели (бронирование, заказ).
• Специфические запросы: Влияет на запросы с четким интентом, связанным с известной сущностью (например, название фильма, модель товара, название ресторана).
• Форматы контента: Влияет на появление интерактивных блоков в Knowledge Panels и специализированных результатах (например, карусели товаров, блоки с кнопками действий).

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

• Условие 1 (Данные): Когда третья сторона предоставила валидный структурированный фид, и система смогла сопоставить элементы фида с Search Entities.
• Условие 2 (Запрос): Когда поисковый запрос пользователя четко идентифицируется как относящийся к Search Entity, для которой существуют зарегистрированные Entity-Action Pairs.
• Триггеры активации: Идентификация сущности в запросе и наличие связанных с ней действий в базе данных.

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

Процесс А: Обработка фида (Предварительный этап)

1. Получение и валидация фида: Система получает фид от третьей стороны и проверяет его формат и наличие обязательных полей (ID, тип, действие, целевая страница, цена).
2. Парсинг элементов: Фид разбирается на отдельные Feed Items.
3. Разрешение сущностей (Entity Resolution): Для каждого элемента система пытается найти уникальную соответствующую Search Entity. Это может включать:
   1. Поиск по уникальным идентификаторам (если предоставлены).
   2. Эвристический поиск по Knowledge Graph с использованием названия, даты выпуска и других атрибутов.
   3. Использование моделей машинного обучения для определения наиболее вероятного соответствия.
4. Обработка ошибок: Если сущность не найдена или найдено несколько соответствий, система регистрирует ошибку для отчета поставщику (например, «Unknown Search Entity» или «Multiple Search Entity Matches»).
5. Генерация Entity-Action Pair: Для успешно разрешенных элементов генерируется пара, объединяющая Search Entity и Online Action из фида.
6. Ассоциация с аукционом: Сгенерированная пара связывается с Auction Parameters поставщика (например, привязывается к существующей рекламной кампании).

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

1. Получение запроса: Система получает запрос (включая голосовой ввод).
2. Идентификация сущности: Анализатор запросов определяет основную Search Entity, связанную с запросом.
3. Извлечение релевантных пар: Система извлекает все Entity-Action Pairs, связанные с этой сущностью или релевантными связанными сущностями.
4. Ранжирование действий: Система может ранжировать различные типы действий (например, стриминг выше покупки) на основе интента запроса или популярности действия.
5. Группировка для аукциона (Ключевой этап): Система группирует пары по типу Online Action. Пары с действием «Стриминг» попадают в одну группу аукциона, пары с действием «Купить DVD» — в другую.
6. Проведение аукционов: Для каждой группы проводится отдельный аукцион с использованием соответствующих ставок поставщиков. Аукцион может учитывать как ставку, так и Quality Score.
7. Выбор контента и формирование выдачи: Победители аукционов включаются в выдачу. Layout Generator определяет визуальное представление, часто внутри Knowledge Panel, с указанием действия, цены и ссылки на целевую страницу из фида.

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

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

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

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

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

• Точность сопоставления сущностей: Метрика, определяющая успешность разрешения Feed Item в уникальную Search Entity. Ошибки включают «Unknown Search Entity» и «Multiple Search Entity Matches».
• Bid Amount (Размер ставки): Используется в аукционе для определения победителя.
• Quality Score (Показатель качества): Упоминается, что система может использовать показатель качества (например, основанный на click through rate) в дополнение к ставке для определения победителя аукциона.
• Reserve Price (Резервная цена): Минимальная цена, которую должна превысить ставка, чтобы контент был показан.
• Ранжирование отношений (Relationship Ranking): Метрика, определяющая, насколько тесно Entity-Action Pair связана с поисковым запросом. Влияет на визуальное представление (приоритезацию) контента в выдаче.

Выводы

1. Структурированные фиды — ключ к интерактивной выдаче: Патент подтверждает, что предоставление структурированных фидов является основным механизмом для интеграции инвентаря (товаров, услуг, медиа) в интерактивные и транзакционные элементы SERP, такие как Knowledge Panels.
2. Критичность разрешения сущностей (Entity Resolution): Ядром системы является способность однозначно сопоставить элемент фида с Search Entity в Knowledge Graph. Неоднозначные или неполные данные в фиде приведут к потере показов.
3. Действия (Actions) определяют конкуренцию: Система намеренно разделяет аукционы по типу действия. Это стратегически важно: ритейлеры конкурируют с ритейлерами, а стриминговые сервисы — со стриминговыми сервисами, даже если речь идет об одной и той же сущности.
4. Важность уникальных идентификаторов: Для минимизации ошибок сопоставления (особенно при наличии схожих сущностей, например, ремейков фильмов или разных изданий книг) критически важно использовать уникальные идентификаторы (GTIN, ISBN, MID и т.д.) в фидах.
5. Интеграция с голосовым поиском: Патент явно упоминает обработку запросов, полученных через микрофон, и предоставление аудио-ответов, что указывает на интеграцию этих механизмов с голосовыми помощниками (Google Assistant) и умными колонками.

Практика

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

• Максимальное использование структурированных фидов: Для e-commerce обязательно использовать Google Merchant Center. Для других вертикалей (медиа, локальный бизнес, услуги) необходимо использовать доступные механизмы структурированных данных (например, Media Feeds для издателей, Google Business Profile API) для передачи инвентаря в формате, аналогичном описанному в патенте.
• Приоритет уникальных идентификаторов: Всегда включать глобальные уникальные идентификаторы (GTIN, ISBN, MPN, специфичные для индустрии ID) в фиды. Это напрямую помогает системе в процессе Entity Resolution и минимизирует ошибки типа «Multiple Matches».
• Точность и полнота данных в фиде: Обеспечивать максимальную точность данных (названия, даты, цены, доступность, целевые URL). Данные должны быть достаточными для того, чтобы система могла отличить вашу сущность от похожих.
• Мониторинг отчетов об ошибках: Регулярно анализировать отчеты об ошибках обработки фидов (например, в Merchant Center). Ошибки «Unknown Entity» или «Multiple Matches» указывают на проблемы с идентификацией, которые необходимо исправлять для получения показов.
• Оптимизация под конкретные действия (Actions): Понимать, какие действия релевантны для вашего бизнеса (купить, подписаться, забронировать) и убедиться, что фиды четко структурированы для поддержки этих действий и связаны с соответствующими рекламными кампаниями (если применимо).

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

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

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

Этот патент подчеркивает стратегический переход Google от индексирования неструктурированного текста к работе с базами данных структурированного инвентаря, привязанного к Knowledge Graph. Для бизнеса это означает, что традиционное SEO (оптимизация страниц) должно быть дополнено стратегией управления данными (Data Management Strategy). Успех в поиске все больше зависит от качества, точности и способа передачи структурированных данных о товарах и услугах поисковой системе.

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

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

1. Проблема: Стриминговый сервис загружает фид с тысячами фильмов, но редко появляется в блоке «Смотреть сейчас» в Knowledge Panels фильмов.
2. Анализ (на основе патента): Отчеты об ошибках показывают высокий процент «Multiple Search Entity Matches», особенно для старых фильмов и фильмов с общими названиями. Система не может однозначно определить сущность.
3. Действие: Команда по управлению данными обогащает фид. Вместо использования только полей Title и Release Year, они добавляют уникальные идентификаторы фильмов (например, EIDR или IMDb ID) в поле MID (Movie Identifier).
4. Результат: При следующей обработке фида система использует эти ID для точного разрешения сущностей. Процент ошибок значительно снижается, и сервис начинает стабильно появляться в Knowledge Panels для фильмов из своего каталога.

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