Как Google использует структурированные данные для отображения прямых ссылок на песни в результатах поиска (Rich Snippets)

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

Database of Music Data (База данных музыкальных данных)

Хранилище, содержащее данные, извлеченные из музыкальных веб-страниц. Хранит соответствие между URL ресурса и элементами музыкальных данных (песни, альбомы и т.д.).

HTML5 Microdata (Микродата HTML5)

Спецификация HTML для встраивания машиночитаемых данных в HTML-документы с использованием атрибутов (например, itemprop, itemscope). Один из типов разметки, который система парсит для получения музыкальных данных.

Markup Language Music Data (Музыкальные данные на языке разметки)

Общий термин для структурированных данных (таких как XML или HTML5 microdata), встроенных в веб-страницу, которые описывают музыкальный контент. В патенте указано, что эти данные могут быть невидимы для пользователя и предназначены специально для поисковых систем.

Music Query (Музыкальный запрос)

Запрос, который система классифицирует как направленный на поиск музыки. Показ вторичных ссылок может быть ограничен только этим типом запросов.

Music Resource (Музыкальный ресурс)

Ресурс (например, веб-страница, аудио- или видеофайл), с которого можно получить доступ к музыкальному контенту (встраиваемому, потоковому или загружаемому).

Popularity Threshold (Порог популярности)

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

Quality Measure / Quality Threshold (Мера качества / Порог качества)

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

Secondary Music Search Result Link (Вторичная ссылка результата поиска музыки)

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

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

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

1. Система получает поисковый запрос.
2. Идентифицируется множество соответствующих ресурсов (matching resources).
3. Определяется, что конкретный ресурс имеет запись в database of identified music web pages. Эта база данных содержит записи, основанные на markup language music data, идентифицирующем одну или несколько песен.
4. Генерируется представление результатов поиска. Для конкретного ресурса генерируется результат, включающий одну или несколько secondary music search result links, ведущих на соответствующие музыкальные веб-страницы из базы данных.
5. Представление предоставляется в ответ на запрос.

Claim 6 (Зависимый): Уточняет условия генерации для контроля загруженности SERP. Генерация вторичных ссылок происходит не более чем для порогового числа результатов поиска.

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

Claim 8 (Зависимый): Вводит критерий качества для вторичных ссылок. Генерация результата с вторичными ссылками включает определение того, что quality measure конкретной вторичной ссылки удовлетворяет порогу.

Claim 9 (Зависимый от 8): Уточняет природу quality measure. Эта мера качества основана, по крайней мере частично, на популярности песни, соответствующей данной вторичной ссылке.

Claim 10 (Зависимый): Описывает офлайн-процесс наполнения базы данных. Процесс включает парсинг музыкальных веб-страниц, содержащих markup language music data, и ассоциацию этих страниц с распарсенными данными в базе данных.

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

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

CRAWLING и INDEXING – Сканирование, Сбор данных и Индексирование
Это критически важный этап для работы системы. Во время сканирования и индексирования система должна обнаружить markup language music data (например, HTML5 microdata) на страницах. Система парсит эти данные и сохраняет их в специализированной Database of Music Data. Эта база данных хранит соответствия между URL и музыкальными сущностями (песнями, альбомами).

RANKING – Ранжирование
На этом этапе происходит стандартный отбор и ранжирование документов в ответ на запрос пользователя.

RERANKING / METASEARCH (Презентационный слой)
Основное применение патента происходит на этапе формирования финального представления SERP. Система анализирует топовые результаты, полученные на этапе RANKING.

1. Проверка наличия данных: Система проверяет, имеют ли URL результатов записи в Database of Music Data.
2. Применение порогов и фильтров: Система применяет ряд условий для принятия решения о показе secondary links: пороги качества, популярности, ограничения на количество результатов с такими ссылками на SERP и проверку на конфликты с другими типами вторичных ссылок.
3. Генерация представления: Если условия выполнены, система генерирует модифицированное представление результата, включая вторичные ссылки с соответствующими данными (название песни, продолжительность и т.д.).

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

• Набор ранжированных URL (результаты этапа RANKING).
• Database of Music Data (результат этапа INDEXING).
• Метрики качества и популярности для ресурсов и песен.
• Параметры пороговых значений (Clutter, Quality, Popularity).

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

• Документ представления SERP (например, HTML), в котором некоторые результаты поиска дополнены secondary music search result links.

На что влияет

• Конкретные типы контента: Влияет исключительно на ресурсы, идентифицированные как музыкальные веб-страницы, предоставляющие доступ к аудио- или видеоконтенту и использующие соответствующую структурированную разметку.
• Специфические запросы: Система может применяться только тогда, когда запрос классифицирован как Music Query. Классификация может происходить на основе белых списков или машинного обучения с использованием сигналов, таких как анализ топовых результатов или терминов запроса.
• Конкретные ниши или тематики: Музыкальная индустрия, стриминговые сервисы, сайты исполнителей, медиа-порталы.

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

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

• Триггер 1 (Наличие данных): URL результата поиска имеет соответствующую запись в Database of Music Data.
• Триггер 2 (Качество): Основной результат поиска удовлетворяет порогу качества. Также Quality Measure (например, релевантность) самой вторичной ссылки должна удовлетворять порогу.
• Триггер 3 (Популярность): Популярность песни, на которую ведет вторичная ссылка, превышает Popularity Threshold.
• Ограничение 1 (Загруженность SERP): Общее количество результатов на странице, включающих вторичные ссылки, не превышает установленного лимита (Clutter Threshold).
• Ограничение 2 (Конфликт типов): В данном результате поиска не отображаются другие типы вторичных ссылок (например, события, люди).
• Ограничение 3 (Тип запроса): Запрос идентифицирован как Music Query.

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

Процесс А: Офлайн-обработка (Индексирование)

1. Сканирование: Система сканирует ресурсы в сети.
2. Парсинг разметки: Система ищет и парсит markup language music data (например, HTML5 microdata, XML) на страницах.
3. Извлечение данных: Извлекаются элементы данных: название песни, исполнитель, альбом, продолжительность, URL музыкального ресурса.
4. Сохранение: Извлеченные данные сохраняются в Database of Music Data, ассоциируясь с URL исходной страницы.
5. Оценка популярности: Система определяет меру популярности для музыкального контента (например, на основе количества просмотров видео или популярности запросов) и сохраняет её.

Процесс Б: Онлайн-обработка (Генерация SERP)

1. Получение запроса: Система получает запрос от пользователя.
2. Идентификация результатов: Стандартный механизм поиска идентифицирует и ранжирует релевантные ресурсы.
3. Классификация запроса (Опционально): Система определяет, является ли запрос Music Query. Если нет, процесс останавливается.
4. Анализ результатов: Для топовых результатов поиска система проверяет наличие записей в Database of Music Data.
5. Применение фильтров к результату: Для результата, имеющего музыкальные данные, проверяются условия:
   • Превышен ли лимит результатов со вторичными ссылками на SERP?
   • Удовлетворяет ли основной результат порогу качества?
   • Присутствуют ли конфликтующие типы вторичных ссылок?
6. Применение фильтров к вторичным ссылкам: Если результат прошел фильтры, система анализирует потенциальные вторичные ссылки:
   • Удовлетворяет ли Quality Measure (релевантность) ссылки порогу?
   • Превышает ли популярность соответствующей песни Popularity Threshold?
7. Генерация представления: Если все условия выполнены, система генерирует представление результата, включая отобранные secondary music search result links.
8. Предоставление SERP: Модифицированная страница результатов предоставляется пользователю.

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

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

• Структурные факторы (Ключевые данные): Markup Language Music Data (HTML5 microdata, XML). Это основной источник информации для генерации ссылок. Конкретные поля: название песни (title), имя исполнителя (artist name), название альбома (album name), продолжительность (duration), год выпуска, ссылка на обложку альбома, URL ресурса.
• Поведенческие факторы / Сигналы популярности: Упоминаются данные для определения популярности песни: количество просмотров (view count) видео, популярность запросов (query popularity). Также логи запросов используются для определения того, является ли запрос музыкальным.
• Факторы качества: Используются некие метрики качества (Quality Measure) для оценки как основного результата, так и релевантности вторичной ссылки.

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

Патент определяет несколько ключевых метрик и порогов для управления отображением вторичных ссылок:

• Quality Measure (Мера качества вторичной ссылки): Метрика, оценивающая качество или релевантность вторичной ссылки. Должна удовлетворять порогу.
• Popularity (Популярность песни): Метрика, основанная на популярности контента (например, view count). Используется как часть Quality Measure (Claim 9) и должна превышать Popularity Threshold.
• Quality Threshold (Порог качества основного результата): Если основной результат не удовлетворяет этому порогу, вторичные ссылки для него не показываются.
• Clutter Threshold (Порог загруженности SERP): Максимальное количество результатов на странице, которые могут включать вторичные ссылки (Claim 6).
• Music Query Classification (Классификация музыкального запроса): Бинарная классификация запроса (музыкальный/не музыкальный), основанная на анализе логов, белых списках или классификаторах машинного обучения.

1. Структурированные данные как источник расширенных результатов: Патент четко демонстрирует, как Google использует структурированную разметку (HTML5 microdata) для извлечения конкретных данных и последующего обогащения SERP. Это подчеркивает важность предоставления машиночитаемых данных для поисковых систем.
2. Предварительная обработка данных: Система полагается на офлайн-процессы индексирования для парсинга разметки и сохранения её в специализированной базе данных (Database of Music Data). Это позволяет быстро принимать решения об обогащении результатов в реальном времени.
3. Отображение Rich Results строго условно: Внедрение разметки не гарантирует показ расширенных результатов. Патент описывает многоуровневую систему фильтрации:
   • Качество: И основной результат, и вторичная ссылка должны соответствовать порогам качества/релевантности.
   • Популярность: Контент (песня) должен быть достаточно популярным.
   • Контекст SERP: Система ограничивает количество расширенных результатов на странице (Clutter Threshold) и разрешает конфликты между разными типами вторичных ссылок.
   • Интент запроса: Запрос должен быть классифицирован как музыкальный.
4. Приоритет пользовательского опыта: Цель изобретения — улучшение UX путем предоставления прямых ссылок на контент, минуя промежуточные навигационные страницы.

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

• Внедрение структурированных данных для медиа-контента: Для сайтов с музыкальным или видеоконтентом необходимо внедрять релевантную разметку. Хотя патент упоминает HTML5 microdata, современные стандарты (Schema.org через JSON-LD) работают по тем же принципам. Используйте типы MusicRecording, MusicAlbum, MusicGroup.
• Обеспечение точности и полноты данных: Убедитесь, что разметка содержит точную информацию: названия, продолжительность, исполнителей и прямые ссылки на ресурсы (URL). Точность данных критична для их использования системой.
• Фокус на качестве и популярности контента: Поскольку показ вторичных ссылок зависит от порогов качества и популярности, необходимо не только внедрять разметку, но и работать над авторитетностью сайта и продвижением самого контента (песен, видео). Разметка на непопулярный контент вряд ли приведет к показу расширенных результатов.
• Мониторинг отображения в SERP: Отслеживайте, для каких страниц и запросов Google показывает вторичные ссылки. Анализируйте случаи, когда они не показываются, чтобы понять, какие пороги (качество или популярность) могут быть не достигнуты.

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

• Игнорирование структурированных данных: Отсутствие разметки на музыкальном сайте лишает его возможности получить расширенное представление в SERP и прямой трафик на страницы контента.
• Внедрение некорректной или спамной разметки: Предоставление ложной информации (неправильные названия, подмена ссылок) противоречит принципам качества, заложенным в патенте, и может привести к санкциям или игнорированию разметки.
• Разметка невидимого контента (с оговорками): Хотя патент упоминает, что разметка может быть невидима пользователю, современные рекомендации Google требуют, чтобы размеченные данные преимущественно соответствовали видимому контенту страницы. Злоупотребление скрытой разметкой рискованно.
• Фокус только на разметке без работы над контентом: Рассчитывать на получение расширенных результатов только за счет технического внедрения разметки, игнорируя качество сайта и популярность контента, неэффективно из-за описанных в патенте порогов.

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

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

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

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

1. Задача: Увеличить видимость и трафик на страницы популярных песен.
2. Действия на основе патента:
   • Внедрить разметку (например, Schema.org MusicRecording, следуя принципам HTML5 microdata) на всех страницах песен.
   • В разметке указать точное название, исполнителя, альбом, продолжительность и URL для прослушивания.
   • Провести кампанию по продвижению ключевых треков для увеличения их популярности (Popularity Threshold).
   • Улучшить общие сигналы качества сайта (Quality Threshold).
3. Ожидаемый результат: При поиске по имени исполнителя или альбому, результат, ведущий на сайт сервиса, будет дополнен secondary music search result links, ведущими прямо на самые популярные треки. Это увеличит занимаемое пространство в SERP и CTR.