Анализ патента Google, описывающего инфраструктуру для клиентского поиска (например, Google Desktop). Система фиксирует действия пользователя (события) с контентом (статьями) и решает, индексировать ли их, используя критерии, основанные на частоте событий, доступных ресурсах и предполагаемых интересах пользователя (имплицитно выведенных из его поведения).
Описание
Какую задачу решает
Патент решает проблемы производительности и эффективности традиционных систем клиентского (локального) поиска. Он устраняет необходимость в ресурсоемком пакетном индексировании всего контента, заменяя его системой, которая захватывает взаимодействия пользователя (events) с контентом (articles) в реальном времени и выборочно (selectively) решает, какие события индексировать. Это предотвращает перегрузку индекса неважными или слишком частыми событиями (например, автосохранениями) и позволяет системе адаптироваться к поведению пользователя и доступным ресурсам.
Что запатентовано
Запатентована система и метод для выборочного хранения и индексирования данных о событиях на клиентском устройстве. Суть изобретения заключается в механизме оценки каждого захваченного события на соответствие определенным критериям (criterion). Только если событие удовлетворяет критерию, оно индексируется. Критерии могут быть явными (заданными пользователем) или неявными (выведенными системой на основе поведения пользователя, частоты событий или доступности ресурсов).
Как это работает
Система работает на клиентском устройстве:
- Захват событий: Специальный компонент (Capture Processor) отслеживает взаимодействие пользователя с приложениями и контентом (просмотр веб-страниц, редактирование документов, получение email).
- Оценка и Фильтрация: Индексатор (Indexer) получает событие и оценивает его на соответствие критериям. Критерии могут включать: тип контента, частоту подобных событий, время/место захвата или неявные предпочтения пользователя.
- Выборочное Индексирование: Если событие не удовлетворяет критерию или является дубликатом, оно не индексируется.
- Структурирование: Индексированные события связываются с Related Event Object (например, все просмотры одного URL группируются вместе) для эффективного хранения и поиска.
Актуальность для SEO
Низкая. Патент описывает инфраструктуру, тесно связанную с продуктом Google Desktop Search, поддержка которого прекращена. Хотя базовые концепции захвата пользовательских данных и выборочного индексирования остаются актуальными для операционных систем и браузеров (Chrome, Android), конкретная реализация, описанная в патенте, устарела.
Важность для SEO
Влияние на современные SEO-стратегии минимальное (3/10). Патент описывает внутренние процессы Google для клиентского (локального) поиска и не имеет прямого отношения к алгоритмам ранжирования веб-сайтов в основном поиске Google. Однако он представляет ценность как детальный пример того, как Google способен захватывать, анализировать и интерпретировать гранулярные данные о поведении пользователей на контролируемых платформах.
Детальный разбор
Термины и определения
- Article (Статья)
- Любой элемент контента, с которым взаимодействует пользователь: веб-страница (HTML, PDF), email, документ Word, сообщение IM, медиафайл и т.д.
- Capture Processor (Процессор захвата)
- Компонент системы, отвечающий за мониторинг активности на клиентском устройстве и захват событий и связанных с ними данных.
- Criterion (Критерий)
- Условие, используемое для оценки события. Если событие удовлетворяет критерию, оно индексируется; если нет — игнорируется.
- Event (Событие)
- Любое действие или происшествие, связанное со статьей, приложением или устройством. Примеры: просмотр веб-страницы, сохранение файла, получение email, движение мыши, ввод текста.
- Event Capture Criterion (Критерий захвата события)
- Критерий, основанный на контексте захвата события (когда, где, как): например, время суток, местоположение устройства, активный профиль пользователя.
- Historical Events (Исторические события)
- События, произошедшие до установки системы или когда она была неактивна (например, существующие файлы на диске).
- Indexable/Non-indexable Events (Индексируемые/Неиндексируемые события)
- Классификация событий по важности. Индексируемые события (просмотр, сохранение) сохраняются в индексе. Неиндексируемые (движение мыши) могут использоваться для обновления текущего состояния пользователя, но не сохраняются.
- Real-time Events (События реального времени)
- События, происходящие в настоящий момент.
- Related Event Object (Объект связанных событий)
- Структура данных, которая группирует связанные события. Например, все события просмотра одного и того же URL или все события редактирования одного документа.
Ключевые утверждения (Анализ Claims)
Патент описывает инфраструктурные процессы для клиентского поиска без прямых рекомендаций для SEO.
Claim 1 (Независимый пункт): Описывает базовый метод выборочного хранения данных.
- Система захватывает событие (event), связанное со статьей (article).
- Система оценивает событие на соответствие критерию (criterion).
- Если событие соответствует критерию, оно индексируется.
- Создается объект связанных событий (related event object), объединяющий набор связанных событий, включая текущее.
- Объект связанных событий сохраняется в первом расположении хранилища данных.
- По крайней мере часть индексированного события сохраняется во втором расположении.
- Создается указатель (pointer) между объектом связанных событий и сохраненной частью индексированного события.
Ядро изобретения — это комбинация выборочного индексирования на основе критериев (шаги 2-3) и структурированного хранения с использованием объектов связанных событий (шаги 4-7).
Claim 3 (Зависимый от 1): Уточняет процесс фильтрации.
Система сначала определяет, является ли событие индексируемым или неиндексируемым. Индексирование происходит только если событие определено как индексируемое И удовлетворяет критерию.
Claim 6 (Зависимый от 1): Описывает автоматическое создание правил.
Критерий генерируется неявно (implicitly generating the criterion), то есть без прямого указания пользователя, вероятно, на основе анализа его поведения.
Claim 15 (Зависимый от 1): Описывает адаптацию к ресурсам и частоте.
Система корректирует критерий на основе одного или нескольких факторов: общего объема сохраненных данных о событиях, частоты захвата событий (event capture frequency) или оставшейся емкости хранилища данных.
Claim 18 и 25 (Зависимые от 1): Определяют типы критериев.
Критерий может быть основан на контексте захвата события (event capture criterion — Claim 18) или на характеристиках самой статьи (article criterion — Claim 25).
Где и как применяется
Важно понимать, что патент описывает архитектуру клиентского поиска (например, Google Desktop), а не основного веб-поиска Google. Он применяется на локальном устройстве пользователя.
CRAWLING – Сканирование и Сбор данных (Локальный контекст)
Capture Processor выступает в роли локального краулера. Он постоянно отслеживает активность пользователя в реальном времени (Real-time Events) и периодически сканирует файловую систему или кэши приложений для обнаружения Historical Events.
INDEXING – Индексирование и извлечение признаков (Локальный контекст)
Это основной этап применения патента. Indexer получает события и выполняет ключевые функции:
- Нормализация: Преобразование данных события в индексируемый текст.
- Фильтрация (Selective Storing): Применение критериев (Criterion) для решения, индексировать ли событие. Это включает проверку типа события (индексируемое/неиндексируемое) и соответствие правилам (явным или неявным).
- Дедупликация: Использование контрольных сумм для предотвращения повторного индексирования идентичных событий.
- Структурирование: Связывание события с Related Event Object.
Входные данные:
- События (Events) и связанный с ними контент (Articles).
- Данные о производительности системы.
- Поведенческие данные пользователя (используются для генерации неявных критериев).
Выходные данные:
- Структурированные данные в локальном хранилище (Index, Database, Repository).
- Обновленные Related Event Objects.
На что влияет
В контексте локального поиска:
- Типы контента: Влияет на все типы локального контента (документы, email, история браузера, IM). Система может применять разные критерии к разным типам контента (например, индексировать все документы Word, но только некоторые логи .log).
- Частота обновления: Система активно подавляет индексирование слишком частых событий, таких как многократные автосохранения одного и того же документа.
Когда применяется
Алгоритм применяется постоянно, при захвате каждого нового события на клиентском устройстве.
- Триггеры активации фильтрации:
- Превышение порога частоты событий (event capture frequency) для определенного типа или конкретной статьи.
- Низкий объем доступного места в хранилище.
- Неявные сигналы о незаинтересованности пользователя в определенном типе контента (например, пользователь никогда не ищет и не кликает на результаты из IM).
- Явные инструкции пользователя на исключение (например, не индексировать определенные папки или сайты).
Пошаговый алгоритм
Процесс выборочного хранения и индексирования события:
- Получение события: Индексатор извлекает следующее событие из очереди.
- Нормализация контента: Данные статьи, связанные с событием, конвертируются в канонический индексируемый текст (THIS_INDEX_TEXT). Для этого используются специализированные обработчики (handlers) для разных форматов (HTML, PDF и т.д.).
- Генерация контрольной суммы: Вычисляется контрольная сумма (C_TEXT, fingerprint, например, MD5 или SHA1) для индексируемого текста.
- Проверка критериев (Фильтрация): Система оценивает, удовлетворяет ли событие критерию.
- Проверяется тип события (индексируемое/неиндексируемое).
- Проверяется соответствие явным правилам (включения/исключения).
- Проверяется соответствие неявным критериям (частота, ресурсы, поведение пользователя).
- Если НЕТ: Событие не индексируется. Процесс завершен.
- Проверка на дубликаты: Система проверяет, существует ли уже индексированное событие с такой же контрольной суммой C_TEXT.
- Если ДА: Событие не индексируется. Могут быть обновлены статистики доступа. Процесс завершен.
- Присвоение ID события: Новому уникальному событию присваивается Event ID.
- Обработка объекта связанных событий: Система определяет, существует ли Related Event Object для данного события (например, по URI файла или URL).
- Если ДА: Загружается существующий объект.
- Если НЕТ: Создается новый объект и ему присваивается Related Event ID.
- Сохранение данных:
- Оригинальный и/или индексируемый текст сохраняются в Репозитории.
- Событие и объект связанных событий обновляются и сохраняются в Базе Данных (создаются указатели между ними).
- Обновление индекса: Индексируемый текст добавляется в Полнотекстовый Индекс.
Какие данные и как использует
Данные на входе
Система использует данные, захваченные на локальном устройстве.
- Контентные факторы: Содержимое статей (текст, изображения), метаданные (заголовки, отправители/получатели email, формат файла).
- Технические факторы: URL веб-страниц, пути к локальным файлам.
- Временные факторы: Время события (используется для определения частоты).
- Пользовательские факторы (Контекст захвата): Активный профиль пользователя, используемое приложение, местоположение устройства (если доступно), сетевое подключение.
- Поведенческие факторы (Для генерации критериев): История прошлых поисков пользователя, клики на результаты (clickthroughs), частота доступа к определенным статьям или типам статей. Эти данные используются для неявного вывода о важности контента для пользователя.
- Системные факторы: Доступная емкость хранилища, загрузка процессора (может влиять на скорость и объем индексирования).
Какие метрики используются и как они считаются
- Capture Score (Оценка важности события): Упоминается как возможный механизм для определения, является ли событие indexable или non-indexable.
- Event Capture Frequency (Частота захвата событий): Метрика, отслеживающая, как часто происходят однотипные события (например, сохранение конкретного файла). Используется для подавления индексирования слишком частых событий.
- Frequency Threshold (Порог частоты): Пороговое значение для Event Capture Frequency. Если частота превышает порог, индексирование может быть пропущено (например, индексировать не чаще, чем раз в 30 минут).
- Fingerprint / Checksum: Криптографический хэш (MD5, SHA1) от индексируемого текста. Используется для дедупликации событий.
Выводы
Патент описывает инфраструктурные процессы Google для клиентского поиска и не содержит прямых рекомендаций для SEO. Основные выводы для понимания технологий Google:
- Гранулярный захват поведения пользователей: Патент демонстрирует техническую способность Google (уже в 2004 году) детально фиксировать взаимодействие пользователя с контентом на уровне отдельных событий (просмотры, редактирования, время взаимодействия).
- Приоритет эффективности и релевантности (Selective Indexing): Ключевая идея — индексировать не все подряд, а только то, что полезно и эффективно. Система активно фильтрует шум (дубликаты, слишком частые события).
- Неявные критерии на основе поведения: Система автоматически адаптирует правила индексирования (Criterion), основываясь на поведении пользователя. Если пользователь не интересуется определенным типом контента, система может перестать его индексировать.
- Адаптация к частоте (Frequency-based Criteria): Внедрен механизм для борьбы с переиндексацией часто изменяющегося контента, что схоже с концепцией управления краулинговым бюджетом в веб-поиске.
- Структурирование через связанные события: Использование Related Event Objects для группировки всех взаимодействий с одной единицей контента (например, URL) позволяет эффективно агрегировать сигналы и статистику (например, общее время взаимодействия).
Практика
Best practices (это мы делаем)
Поскольку патент описывает систему локального поиска, прямых SEO-рекомендаций нет. Однако, исходя из продемонстрированных возможностей Google по анализу поведения пользователей, можно подтвердить важность следующих общих стратегий:
- Фокус на User Experience (UX) и Вовлеченности: Патент подтверждает, что Google обладает технологиями для детального измерения взаимодействия пользователя с контентом (частота доступа, время просмотра). Если подобные технологии используются в Chrome/Android и влияют на ранжирование, то создание контента, который пользователи часто посещают и с которым долго взаимодействуют, является критически важным.
- Создание запоминающегося и полезного контента: В патенте система учится на поведении пользователя и может перестать индексировать контент, который пользователь игнорирует. Это подчеркивает необходимость создания контента, который стимулирует повторные визиты и взаимодействие.
Worst practices (это делать не надо)
Патент не описывает механизмы борьбы с SEO-манипуляциями в веб-поиске.
Стратегическое значение
Стратегическое значение патента для SEO заключается в понимании глубины аналитических возможностей Google. Он детально описывает фреймворк для захвата и интерпретации гранулярных поведенческих данных на контролируемых платформах. Это служит сильным напоминанием для Senior SEO-специалистов, что поведенческие факторы (даже если они собираются не этим конкретным методом) являются важной частью экосистемы Google, и долгосрочная стратегия должна быть сосредоточена на реальном вовлечении пользователей.
Практические примеры
Практических примеров применения данного патента в работе по SEO продвижению сайтов нет, так как он описывает систему локального (клиентского) поиска.
Вопросы и ответы
Описывает ли этот патент, как Google ранжирует сайты в интернете?
Нет. Патент строго сфокусирован на системе клиентского (локального) поиска, такой как Google Desktop. Он описывает, как Google индексирует файлы и активность пользователя на его собственном компьютере. Механизмы, описанные здесь, не применяются напрямую к сканированию интернета Googlebot или ранжированию в основном веб-поиске.
Использует ли Google данные из этой системы (Google Desktop) для ранжирования в веб-поиске?
В патенте нет информации об использовании этих локально собранных данных для влияния на глобальный индекс или ранжирование в веб-поиске. Патент описывает только процесс создания и поддержания локального индекса (local index) для нужд пользователя этого устройства.
Что такое «Related Event Object» и как это связано с SEO?
Related Event Object — это способ группировки всех локальных событий, связанных с одним элементом контента. Например, все просмотры пользователем страницы CNN.com группируются вместе. В SEO это концептуально похоже на то, как Google агрегирует сигналы вокруг канонического URL, но технически это разные системы.
Патент упоминает захват поведения пользователя. Подтверждает ли это использование поведенческих факторов в SEO?
Патент подтверждает техническую возможность Google детально отслеживать и анализировать поведение пользователя (частоту доступа, клики, время просмотра) на локальном уровне. Он также показывает, как Google использует это поведение для принятия решений (в данном случае, о том, что индексировать локально). Хотя это не доказывает использование ПФ в веб-ранжировании, это демонстрирует глубокий интерес и технологические возможности Google в этой области.
Что означают «неявные критерии» (implicit criteria)?
Неявные критерии — это правила, которые система выводит автоматически, не спрашивая пользователя. В патенте описано, как система может заметить, что пользователь никогда не ищет сообщения из мессенджеров, и на основании этого неявно создать критерий, предписывающий прекратить их индексацию для экономии ресурсов.
Зачем система фильтрует события по частоте (Frequency-based Criteria)?
Это делается для повышения эффективности и предотвращения перегрузки индекса. Например, если пользователь сохраняет документ каждые 30 секунд, нет смысла индексировать каждую версию. Система устанавливает порог (например, раз в 30 минут) и индексирует только события, происходящие реже этого порога, экономя ресурсы.
Актуален ли этот патент, если Google Desktop больше не поддерживается?
Конкретная реализация, связанная с Google Desktop, устарела. Однако базовые принципы — захват событий, выборочное индексирование на основе поведения и частоты — являются фундаментальными и могут применяться в других продуктах Google, таких как Chrome, Android или внутренних системах индексирования.
Что такое «индексируемые» и «неиндексируемые» события?
Система классифицирует события по важности. Индексируемые события (например, сохранение документа или просмотр веб-страницы) считаются достаточно важными для сохранения в индексе. Неиндексируемые события (например, движение мыши или выделение текста) считаются менее важными и не индексируются, хотя могут использоваться для других целей.
Как система определяет дубликаты событий?
Перед индексированием система преобразует контент события в текст и вычисляет его контрольную сумму (хэш или fingerprint). Если в индексе уже есть событие с такой же контрольной суммой, новое событие считается дубликатом и не индексируется повторно.
Какова основная ценность этого патента для SEO-специалиста?
Основная ценность заключается в понимании технологической философии Google. Патент демонстрирует, что Google придает большое значение эффективности индексирования и стремится использовать поведение пользователя для определения важности контента. Это косвенно подчеркивает важность UX и вовлеченности в общей SEO-стратегии.