Как Google [Reader] рекомендовал подписку на RSS-фиды на основе истории посещенных пользователем сайтов

Описание

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

Патент решает проблему обнаружения контент-фидов (Content Feeds), таких как RSS или Atom. Пользователи часто посещают веб-страницы (блоги, новостные сайты), которые предоставляют фиды для синдикации контента, но могут не замечать ссылки на них и упускают возможность подписаться. Изобретение автоматизирует процесс обнаружения этих фидов на основе истории посещений пользователя и предлагает их для подписки в удобном формате.

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

Запатентована система и метод предоставления персонализированных рекомендаций подписки на контентные фиды в рамках сервиса агрегации контента (Feed Aggregation System). Система идентифицирует документы (веб-страницы), посещенные пользователем, определяет наличие связанных с ними фидов и выборочно предлагает их пользователю через интерфейс чтения фидов (Feed Reader UI). Ключевой особенностью является механизм подавления (suppression) рекомендаций, если пользователь уже подписан или ранее отклонил предложение.

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

Механизм работает в контексте приложения Feed Reader:

• Идентификация документа: Система отслеживает документы (веб-страницы), к которым обращается пользователь.
• Обнаружение фида: Каждый документ анализируется (например, парсинг HTML на наличие тегов <LINK> с атрибутами RSS/Atom) для определения наличия связанного контентного фида.
• Проверка подавления (Suppression): Система проверяет, нужно ли подавлять рекомендацию. Подавление происходит, если пользователь уже подписан на фид или если он ранее отклонял предложение подписаться на него.
• Представление рекомендаций: Фиды, прошедшие проверку, представляются пользователю, часто в пакетном режиме на специальной странице рекомендаций (Suggestions Page) в интерфейсе Feed Reader UI.
• Opt-in подписка: Пользователь должен явно принять рекомендацию, чтобы подписаться на фид.

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

Низкая. Патент подан в 2005 году и описывает функциональность, характерную для пика популярности RSS-агрегаторов, таких как Google Reader (закрыт в 2013 году). Описанные механизмы специфичны для этих приложений и в значительной степени устарели, будучи вытесненными алгоритмическими лентами и системами типа Google Discover.

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

Влияние на SEO минимальное (5/100). Патент описывает внутренние процессы и пользовательский интерфейс агрегатора контента (Feed Reader), а не поисковой системы. Он не имеет отношения к тому, как веб-сайты ранжируются в Google Search. Единственное практическое значение заключается в подтверждении важности технически корректного анонсирования фидов на сайте.

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

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

Content Feed (Контент-фид)

Ресурс (например, в формате RSS или Atom), предоставляющий список контентных элементов (content items), которые были недавно добавлены или обновлены на источнике (Feed Source).

Document (Документ)

В контексте патента — это обычно веб-страница, посещенная пользователем.

Feed Aggregation System (Система агрегации фидов)

Серверная система, которая собирает, хранит и предоставляет пользователям контент из фидов, на которые они подписаны.

Feed Reader UI (Интерфейс чтения фидов)

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

Locator (Локатор)

Идентификатор ресурса, например, URL веб-страницы или контент-фида.

Suppression (Подавление рекомендации)

Механизм предотвращения показа рекомендации подписки пользователю. Причины: активная подписка или предыдущий отказ от подписки на этот фид.

Suggestions Page (Страница рекомендаций)

Элемент Feed Reader UI, который отображает список рекомендованных фидов, основанный на истории посещений пользователя.

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

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

1. Система получает запрос на рекомендации контент-фидов, отправленный пользователем через Feed Reader UI.
2. В ответ на запрос система идентифицирует множество документов. Ключевое требование: идентифицированные документы должны быть веб-страницами, ранее посещенными пользователем, и иметь связанные контент-фиды.
3. Система предоставляет пользователю в Feed Reader UI рекомендации подписаться на подмножество этих фидов.
4. Процесс предоставления включает условную логику подавления (suppressing):
   • Если определено, что у пользователя есть текущая подписка (present subscription) на фид, рекомендация подавляется.
   • Если определено, что пользователь отклонил прошлое предложение (rejected a past suggestion) подписаться на фид, рекомендация подавляется.

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

Claim 4 (Независимый пункт): Аналогичен Claim 1, но фокусируется конкретно на механизме подавления из-за прошлых отказов.

Система, получив запрос от пользователя через Feed Reader UI, идентифицирует посещенные страницы с фидами, определяет, что пользователь ранее отклонил предложение подписаться на конкретный фид, и на основании этого подавляет рекомендацию этого фида.

Claim 2 и 14 (Зависимые): Уточняют механизм подавления из-за отказа.

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

Claim 3 и 13 (Зависимые): Уточняют, как определяется связь между документом и фидом.

Определение того, что фид связан с документом, осуществляется путем установления факта, что документ содержит локатор (например, URL) этого фида.

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

Важно понимать, что этот патент не применяется к стандартной архитектуре Google Поиска (Crawling, Indexing, Ranking и т.д.). Он описывает процессы, происходящие исключительно в рамках Feed Aggregation System и ее клиентской части Feed Reader UI (например, Google Reader).

Взаимодействие компонентов:

• Сбор данных (Data Acquisition): Происходит на стороне клиента. Модуль идентификации (Document/Feed Identification Module), который может быть частью Feed Reader, плагином или тулбаром браузера, отслеживает посещаемые пользователем документы и ищет в них связанные фиды.
• Генерация рекомендаций (Suggestion Generation): Происходит на сервере (Feed Suggestion Module). Когда пользователь запрашивает рекомендации в Feed Reader UI, сервер анализирует собранные данные.
• Фильтрация и Подавление (Filtering/Suppression): Сервер сверяет найденные фиды со списком текущих подписок пользователя и историей отказов (Suppression data).
• Представление (Presentation): Сервер генерирует страницу рекомендаций и отправляет ее в Feed Reader UI клиента.

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

• Список посещенных пользователем документов (история браузера).
• Информация о фидах (локаторы), связанных с этими документами.
• Текущий список подписок пользователя.
• Данные о подавлении (история прошлых отказов).

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

• Персонализированная страница рекомендаций в Feed Reader UI.

На что влияет

• Типы контента: Влияет на контент, распространяемый через синдикацию (RSS, Atom) — новости, блоги, подкасты.
• Пользовательский опыт (UX): Основное влияние оказывается на удобство использования агрегаторов контента, упрощая процесс обнаружения новых источников.
• Ранжирование в поиске: Патент не оказывает влияния на ранжирование сайтов в Google Поиске.

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

Алгоритм применяется в двух фазах:

1. Сбор данных: Постоянно, когда пользователь просматривает веб-страницы и активен модуль сбора данных.
2. Генерация рекомендаций: По требованию, когда пользователь явно запрашивает рекомендации через интерфейс Feed Reader UI. В некоторых реализациях это может происходить при входе пользователя в систему агрегатора.

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

Процесс А: Сбор данных и идентификация (Фоновый режим)

1. Идентификация документа: Система идентифицирует документ (веб-страницу), к которому обратился пользователь.
2. Определение наличия фида: Система анализирует документ (например, парсит HTML), чтобы определить, есть ли у него связанный контент-фид. Это включает поиск тега <LINK> с атрибутами, указывающими на RSS/Atom (например, type=»application/rss+xml»).
3. Запись данных: Если фид найден, система записывает информацию о документе, фиде и времени посещения.

Процесс Б: Генерация и обработка рекомендаций (По запросу)

1. Получение запроса: Пользователь запрашивает страницу рекомендаций через Feed Reader UI.
2. Сбор кандидатов: Сервер извлекает список фидов, связанных с ранее посещенными страницами (из Процесса А).
3. Проверка активных подписок: Система проверяет каждый фид-кандидат на наличие у пользователя активной подписки. Если подписка есть, рекомендация подавляется.
4. Проверка истории отказов: Система проверяет данные подавления (Suppression data). Если пользователь ранее отказался от фида (и флаг подавления активен), рекомендация подавляется.
5. Проверка длительности подавления (Опционально): Если подавление временно, система проверяет, истек ли заранее определенный период (predefined duration). Если истек, флаг подавления сбрасывается.
6. Представление рекомендаций: Оставшиеся кандидаты представляются пользователю на странице рекомендаций.
7. Обработка выбора пользователя: Пользователь выбирает фиды для подписки (Opt-in).
8. Подписка и Обновление статуса: Система подписывает пользователя на выбранные фиды. Для отклоненных фидов система активирует флаг подавления и (опционально) запускает счетчик длительности подавления.

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

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

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

• Технические факторы:
  • Document location: Локаторы (URL) посещенных пользователем документов.
  • Feed location: Локаторы (URL) контент-фидов, обнаруженных в этих документах.
• Контентные/Структурные факторы:
  • HTML-содержимое посещенных документов. Используется для парсинга и обнаружения информации, указывающей на наличие фида (например, теги <LINK> с атрибутами rel=»alternate» и соответствующим type).
• Пользовательские факторы:
  • История посещений пользователя (используется для идентификации релевантных документов).
  • Subscription List: Список активных подписок пользователя (используется для подавления дубликатов).
  • Suppression data: История отклоненных рекомендаций (используется для подавления нежелательных фидов).

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

• Subscription Flag (Флаг подписки): Булев индикатор, указывающий, подписан ли пользователь на конкретный фид.
• Suppression Flag (Флаг подавления): Индикатор в Suppression data, указывающий, следует ли подавлять рекомендацию из-за прошлых отказов.
• Predefined Duration (Заранее определенный период): Метрика для определения срока действия временного подавления. Может измеряться:
  • Временем, прошедшим с момента начала подавления.
  • Количеством раз, когда документ с тем же фидом был посещен с момента начала подавления.
• Suppression Counter (Счетчик подавления): Используется для отслеживания Predefined Duration.

Выводы

1. Патент описывает функциональность продукта (Feed Reader), а не поисковый алгоритм: Изобретение не имеет отношения к механизмам сканирования, индексации или ранжирования веб-поиска Google Search.
2. Рекомендации основаны на истории посещений: Ключевой механизм — это использование истории просмотра веб-страниц пользователем как источника для обнаружения потенциально интересных контент-фидов (RSS/Atom).
3. Автоматическое обнаружение фидов (Auto-Discovery): Система полагается на способность парсить посещенные документы (HTML) для поиска локаторов фидов, что подчеркивает важность технически корректной реализации автообнаружения фидов на сайтах (тег <LINK>).
4. Механизм подавления (Suppression): Система активно предотвращает повторные рекомендации. Подавление активируется, если пользователь уже подписан или если он ранее отказался от подписки на этот фид.
5. Временное подавление: Подавление из-за отказа может быть временным и истекать через predefined duration, после чего фид может быть рекомендован снова.
6. Отсутствие практической ценности для SEO-ранжирования: Патент не содержит информации, которую можно использовать для улучшения позиций сайта в поисковой выдаче.

Практика

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

Патент является инфраструктурным и описывает работу конкретного приложения (Feed Reader). Он не дает прямых рекомендаций для SEO-стратегии, направленной на улучшение ранжирования. Однако, исходя из описанных механизмов, можно сделать выводы о важности технической реализации синдикации контента.

• Обеспечение технической корректности фидов: Для сайтов, публикующих регулярные обновления (новости, блоги), необходимо иметь валидный контентный фид (RSS или Atom).
• Реализация автоматического обнаружения фидов (Feed Auto-Discovery): Это ключевая практика, вытекающая из патента. Необходимо убедиться, что фид правильно анонсирован в HTML-коде всех страниц сайта с помощью тега <LINK> в секции <head>. Патент прямо указывает на парсинг этого тега для обнаружения фида.
  Пример: <link rel=»alternate» type=»application/rss+xml» title=»Название фида» href=»URL фида»>.
• Поддержка стандартов синдикации: Использование стандартных форматов (RSS 2.0, Atom) гарантирует совместимость с различными агрегаторами и системами.

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

• Отсутствие контентного фида: Для контентных проектов отсутствие фида ограничивает возможности распространения контента через агрегаторы и другие сервисы.
• Скрытие или отсутствие анонсирования фида в HTML: Даже если фид существует, отсутствие тега <LINK> с атрибутами rel=»alternate» и соответствующим type препятствует его автоматическому обнаружению браузерами и агрегаторами, использующими механизм, описанный в патенте.

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

Стратегическое значение для SEO низкое. Патент представляет скорее исторический интерес, связанный с эпохой Google Reader и явной синдикации контента. Он не влияет на долгосрочную стратегию поискового продвижения сайтов в Google Search. Обеспечение доступности и обнаруживаемости фида является базовой технической гигиеной.

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

Сценарий: Техническая реализация автообнаружения RSS-фида

Чтобы гарантировать, что агрегаторы и браузеры могут обнаружить RSS-фид сайта (механизм, используемый в патенте):

1. Задача: Сделать так, чтобы агрегаторы могли автоматически находить RSS-фид блога, когда пользователь посещает любую его страницу.
2. Действие: Вебмастер должен убедиться, что в секции <head> HTML-кода всех страниц блога присутствует следующий тег:
   <link rel=»alternate» type=»application/rss+xml» title=»Мой Блог — RSS Фид» href=»https://example.com/blog/rss.xml»>.
3. Ожидаемый результат: Приложения (Feed Readers) и браузеры смогут автоматически идентифицировать наличие фида (спарсить этот тег) и предложить пользователю подписку, как описано в патенте.

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