Как Яндекс использует алгоритм «Heart Beat» для определения завершенности просмотра и предложения следующего эпизода в поисковых подсказках

Описание

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

Патент решает задачу повышения релевантности поисковых подсказок (Suggests) для контента, состоящего из последовательных частей (например, сериалов, аудиокниг). Он устраняет проблему, когда система предлагает следующий эпизод (N+1), хотя пользователь фактически не завершил просмотр текущего эпизода (N), а лишь кликнул на него и быстро ушел (например, из-за плохого качества видео). Это улучшает пользовательский опыт (UX), предлагая продолжение только тогда, когда предыдущая часть была потреблена.

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

Запатентована система генерации персонализированных поисковых подсказок для последовательно семантически связанных документов (Sequentially Semantically Linked Documents). Ядром изобретения является механизм определения факта «завершения использования» (Completed Using) документа. Это определяется не просто кликом, а достижением конца документа ИЛИ превышением заранее определенного порога использования (Pre-determined Usage Threshold), который рассчитывается статистически с помощью алгоритма «Heart Beat» (Heart Beat Algorithm).

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

Когда пользователь вводит запрос, система идентифицирует, что он ищет конкретный сериал, и анализирует его историю просмотров (User ID). Ключевым этапом является применение алгоритма Heart Beat. Этот алгоритм использует офлайн рассчитанные статистические данные о паттернах просмотра, чтобы определить временной порог завершения. Если пользователь досмотрел эпизод до конца или время просмотра превысило порог Heart Beat, эпизод признается завершенным. Система генерирует поисковую подсказку, предлагающую следующий по порядку эпизод.

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

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

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

Влияние на SEO минимальное (2/10). Патент не описывает механизмы ранжирования в основной поисковой выдаче (SERP). Он касается исключительно генерации поисковых подсказок (Search Suggestions/Саджестов). Для SEO-специалистов, продвигающих сайты с видеоконтентом, это влияет на то, как пользователи находят контент через подсказки, но не влияет на позиции сайта в органическом поиске напрямую.

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

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

Completed Using (Завершение использования)

Статус документа (эпизода), который присваивается, если пользователь либо достиг конца документа, либо превысил Pre-determined Usage Threshold.

Heart Beat Algorithm (Алгоритм «Heart Beat»)

Статистический алгоритм для расчета Pre-determined Usage Threshold. Он анализирует исторические данные о продолжительности просмотров и определяет вероятность того, что просмотр определенной длительности считается завершенным.

Pre-determined Usage Threshold (Заранее определенный порог использования)

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

Query Detection Module (Модуль обнаружения запросов)

Компонент системы (упомянутый в описании), отвечающий за парсинг запроса, определение того, относится ли он к категории «сериалов», и извлечение названия.

Sequentially Semantically Linked Documents (Последовательно семантически связанные документы)

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

Series Structure Module (Модуль структуры сериалов)

База данных (упомянутая в описании), хранящая информацию о структуре известных сериалов: название (в виде хэша), количество сезонов, количество эпизодов в каждом сезоне и показатель качества/кликабельности (Score или Clickability parameter).

Suggest (Подсказка, Саджест)

Предложение по завершению или уточнению поискового запроса, отображаемое пользователю.

Video Listing Module (Модуль списка видео)

База данных (упомянутая в описании), хранящая названия всех известных и проиндексированных сериалов, а также их возможные вариации и транслитерации.

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

Патент фокусируется на методе генерации релевантной подсказки для следующего эпизода, основанном на точном определении завершения просмотра предыдущего.

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

1. Система получает запрос пользователя на веб-ресурс.
2. Определяется, что веб-ресурс содержит множество последовательно семантически связанных документов (т.е. это сериал).
3. Это определение включает получение структурной информации: хэш названия, количество сезонов, количество эпизодов в сезоне и оценка (score) для каждого документа.
4. Определяется конкретный документ, который пользователь завершил использовать (Completed Using).
5. Критически важно: Определение завершения использования происходит путем проверки:
   • Пользователь достиг конца документа; ИЛИ
   • Если конец не достигнут, пользователь достиг заранее определенного порога использования.
6. Порог использования определяется путем:
   • Выполнения статистического анализа паттернов просмотра пользователей.
   • Использования алгоритма Heart Beat для определения «пульса» (heart beat) и расчета порога на основе этого анализа.
7. Генерируется и передается подсказка (Suggest), включающая следующий по порядку документ после завершенного.

Claim 2 (Зависимый пункт): Уточняет логику ранжирования подсказок при незавершенном просмотре.

Если конкретный документ НЕ был определен как завершенный, система генерирует вторую подсказку, представляющую этот конкретный (незавершенный) документ. Эта вторая подсказка ранжируется выше, чем подсказка следующего документа.

Claim 7 (Зависимый): Уточняет механизм расчета Heart Beat.

Расчет включает сбор статистики использования документов того же типа, определение временных интервалов и назначение для каждого интервала параметра вероятности того, что документ считается завершенным. На основе этих вероятностей рассчитывается параметр Heart Beat.

Claim 8 (Зависимый): Уточняет, что Heart Beat может быть персонализирован для конкретного пользователя на основе его личной статистики просмотров.

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

Изобретение применяется на этапе обработки запроса и генерации поисковых подсказок, а также требует предварительной офлайн-обработки данных.

CRAWLING & INDEXING (Офлайн-процессы)

• Индексация структуры: Система индексирует ресурсы, идентифицирует сериализованный контент и сохраняет его структуру (сезоны, эпизоды) в Series Structure Module.
• Расчет порогов (Heart Beat): Система собирает логи поведения пользователей (время просмотра). Алгоритм Heart Beat анализирует эти данные офлайн для расчета Pre-determined Usage Thresholds.

QUERY PROCESSING – Понимание Запросов (Онлайн)
Основное место применения патента. Когда пользователь вводит запрос в интерфейс (например, омнибокс).

1. Идентификация: Query Detection Module анализирует запрос и определяет, что ищется сериал.
2. Персонализация: Система использует User ID для доступа к логам просмотров.
3. Анализ поведения: Применяются пороги Heart Beat для определения последнего фактически завершенного эпизода.
4. Генерация подсказки: Система использует Series Structure Module для определения следующего эпизода и генерирует соответствующую поисковую подсказку.

На что влияет

• Конкретные типы контента: В первую очередь видеосериалы (TV series). В патенте также явно упоминаются аудиокниги (audio books) и другой аудиоконтент.
• Специфические запросы: Влияет на запросы, связанные с названиями сериализованного контента.
• Интерфейс поиска: Влияет на содержание блока поисковых подсказок (саджестов), а не на ранжирование в SERP.
• Конкретные ниши: Медиа, развлечения, онлайн-кинотеатры, сервисы аудиокниг.

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

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

• Пользователь вводит запрос в поисковую строку.
• Система идентифицирует запрос как относящийся к сериализованному контенту.
• У пользователя есть история взаимодействия (просмотров) с этим контентом (User ID идентифицирован).

Ключевое условие для предложения именно следующего эпизода — система должна определить, что предыдущий эпизод был «завершен» (достигнут конец или порог Heart Beat).

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

Процесс А: Офлайн-подготовка (Расчет Heart Beat)

1. Сбор данных: Агрегация логов просмотров контента пользователями (User ID, Идентификатор контента, Длительность просмотра).
2. Сегментация: Группировка данных по типу контента и/или по конкретному пользователю (для персонализации, согласно Claim 8).
3. Статистический анализ: Для разных временных интервалов (например, 5 мин, 10 мин, 20 мин) рассчитывается вероятность того, что просмотр считается завершенным (Claim 7).
4. Определение порога: Установка Pre-determined Usage Threshold (например, время, при котором вероятность завершения > 0.9).

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

1. Получение данных: Система получает запрос и User ID.
2. Идентификация сериала: Система определяет, какой сериал ищет пользователь.
3. Анализ истории: Система извлекает логи просмотров пользователя для этого сериала.
4. Определение завершенного эпизода: Система анализирует последний просмотренный эпизод и применяет критерии завершения:
   • Проверка, достиг ли пользователь конца эпизода.
   • Если нет, проверка, превышена ли продолжительность просмотра порога Heart Beat.
5. Генерация и ранжирование подсказок:
   • Сценарий 1 (Завершен): Генерируется подсказка для следующего эпизода. Она получает наивысший приоритет.
   • Сценарий 2 (Не завершен): Генерируется подсказка для текущего (недосмотренного) эпизода. Она ранжируется выше, чем подсказка для следующего эпизода (согласно Claim 2).
6. Отображение: Подсказки отправляются на устройство пользователя.

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

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

• Поведенческие факторы: Ключевые данные. История просмотров, продолжительность просмотров (временные интервалы), статус завершения (достиг ли пользователь конца файла). Агрегированные данные используются для офлайн-расчетов.
• Пользовательские факторы: Идентификатор пользователя (User ID) для отслеживания истории и персонализации порогов.
• Контентные/Структурные факторы: Данные из Series Structure Module: хэш названия, структура сезонов и эпизодов.
• Текстовые факторы: Текст текущего запроса пользователя. Названия сериалов и их вариации. Ключевые слова-маркеры («сезон», «эпизод»).
• Факторы качества/популярности: В патенте упоминается хранение оценки (score) для документов, которая может быть основана на кликабельности (clickability parameter).

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

• Pre-determined Usage Threshold (Порог использования): Временная метрика, рассчитываемая офлайн алгоритмом Heart Beat.
• Вероятностная функция (Probability Function): Метрика, используемая внутри алгоритма Heart Beat. Она присваивает вероятность завершения просмотра для различных временных интервалов. Пример из патента:
  $$ P(1\,мин) = 0.1 $$
  $$ P(20\,мин) = 0.9 $$
• Метод сбора данных о просмотре: Патент (Claim 10) описывает механизм активного трекинга: система периодически опрашивает приложение (например, видеоплеер), чтобы подтвердить активность пользователя. Если подтверждение не получено, фиксируется время окончания сессии.

Выводы

1. Патент не о ранжировании, а о подсказках (Suggests): Основной вывод — патент описывает механизм улучшения UX через персонализированные поисковые подсказки для сериализованного контента, а не алгоритм ранжирования в SERP.
2. Статистическое определение «потребления» контента (Heart Beat): Ключевая идея — использование алгоритма Heart Beat. Завершение просмотра определяется не только достижением 100% длительности, но и превышением статистически рассчитанного порога времени просмотра.
3. Персонализация порогов: Система предусматривает возможность расчета индивидуальных порогов Heart Beat для конкретного пользователя или типа контента на основе их специфических паттернов просмотра (Claim 8).
4. Логика при незавершенном просмотре: Если порог не достигнут, система активно предлагает досмотреть текущий эпизод, ранжируя его в подсказках выше, чем следующий (Claim 2).
5. Требование к структурированным данным: Для работы системы Яндекс должен иметь точное представление о структуре контента (сезоны, эпизоды, их порядок). Это подчеркивает важность четкой разметки контента на сайтах-источниках.

Практика

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

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

• Использование микроразметки Schema.org: Критически важно внедрять структурированные данные (например, TVSeries, Episode, Movie или Audiobook, Chapter). Это поможет Series Structure Module Яндекса точно понять структуру и порядок следования контента.
• Четкий и консистентный нейминг эпизодов: Используйте стандартизированные и понятные заголовки (Title, H1) для эпизодов (например, «Название сериала S01E05»). Это облегчает парсинг структуры контента.
• Оптимизация удержания (Retention): Обеспечивайте высокое качество видеопотока, быструю загрузку плеера и отсутствие технических проблем. Если пользователи смотрят контент долго (превышая порог Heart Beat), система будет корректно предлагать им следующие эпизоды, улучшая навигацию и возвращаемость аудитории через поиск.
• Оптимизация под кликабельность (CTR): Так как в патенте упоминается хранение показателя кликабельности (score / clickability parameter) для эпизодов, важно работать над привлекательными сниппетами и заголовками.

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

• Неконсистентный нейминг и запутанная структура: Использование разных форматов названий или отсутствие четкой связи между эпизодами и сезонами может помешать Яндексу корректно выстроить структуру.
• Низкое качество контента/стриминга: Если пользователи массово покидают просмотр в первые минуты из-за плохого качества или технических проблем, система не засчитает просмотр как завершенный (не пройдет порог Heart Beat).
• Вводящие в заблуждение заголовки (Кликбейт): Привлечение трафика обманным путем приведет к быстрым отказам и низкому времени просмотра, что негативно скажется на определении завершенности.

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

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

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

Сценарий: Оптимизация онлайн-кинотеатра для улучшения удержания

1. Проблема: Пользователи часто получают в подсказках Яндекса предложение досмотреть текущий эпизод, хотя они считают, что закончили его (например, выключили на титрах).
2. Анализ (на основе патента): Возможно, статистический порог Heart Beat для данного типа контента установлен слишком близко к 100% длительности, или система некорректно отслеживает время просмотра на сайте.
3. Действия:
   • Проверить корректность работы счетчиков и плеера, убедиться, что данные о времени просмотра корректно передаются (если используются технологии Яндекса).
   • Убедиться, что внедрена микроразметка Schema.org/TVSeries и Schema.org/Episode, чтобы система точно знала полную длительность эпизода и его структуру.
4. Ожидаемый результат: Система корректно отслеживает время просмотра. Алгоритм Heart Beat (возможно, адаптируясь к поведению пользователя, если включена персонализация) засчитывает просмотр как завершенный, даже если титры были пропущены. Пользователь получает релевантную подсказку следующего эпизода.

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