Close Menu
    Telegram
    SEO HARDCORE
    • Разборы патентов
      • Патенты Google
      • Патенты Яндекс
    • Скоро
      SEO инструменты
    • Скоро
      SEO аналитика
    SEO HARDCORE
    Разборы патентов • Патенты Google

    Как Google собирает, объединяет и использует историю поиска и браузинга с разных устройств для персонализации выдачи

    SYSTEMS AND METHODS FOR MANAGING MULTIPLE USER ACCOUNTS (Системы и методы управления несколькими учетными записями пользователей)
    • US7783631B2
    • Google LLC
    • 2010-08-24
    • 2005-03-31
    2005 EEAT и качество Патенты Google Персонализация Поведенческие сигналы

    Google использует фундаментальную архитектуру для персонализации поиска. Система собирает историю действий пользователя (запросы, клики по результатам и рекламе, просмотренные страницы) с разных устройств и браузеров. Эти фрагментированные данные объединяются в единый профиль при входе в аккаунт. Собранная история используется для изменения порядка результатов поиска, выделения ранее посещенных сайтов и определения «предпочтительных местоположений» пользователя.

    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх

    Описание

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

    Патент решает две основные проблемы:

    • Фрагментация пользовательских данных: Пользователи взаимодействуют с интернетом через разные устройства и приложения (например, домашний компьютер, рабочий ноутбук, разные браузеры). Без централизованной системы история действий остается разрозненной и не может быть эффективно использована для улучшения поискового опыта.
    • Недостаток персонализации: Стандартные результаты поиска не учитывают индивидуальный контекст и прошлый опыт пользователя. Система стремится повысить релевантность выдачи, адаптируя ее на основе истории предыдущих поисковых и браузинговых действий пользователя.

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

    Запатентована система для сбора, хранения, управления и использования истории действий пользователя. Ключевым элементом является механизм, позволяющий связывать активность, отслеживаемую через разные идентификаторы клиента (Client ID, например, cookie в браузере), с единым идентификатором пользователя (User ID, аккаунт). Система позволяет объединять (merge) историю, накопленную на разных клиентах, в единый профиль. Этот профиль используется для персонализации результатов поиска и определения предпочтений пользователя (Preferred Locations).

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

    Система работает по следующей схеме:

    • Сбор данных: Активность пользователя (запросы, клики, просмотры страниц) отслеживается, часто с помощью клиентского компонента (Client Assistant), и отправляется на сервер.
    • Идентификация: Каждое действие связывается либо с Client ID (если пользователь не вошел в систему), либо с User ID (если вошел).
    • Ассоциация и объединение: Когда пользователь входит в систему с нового устройства (нового Client ID), система предлагает связать этот Client ID с его User ID и объединить ранее накопленную историю этого клиента с общим профилем.
    • Обработка и хранение: Данные хранятся в Базе данных информации о пользователе (User Information Database). На основе этих данных вычисляются производные метрики (Derived Data), такие как профили интересов или оценки сайтов.
    • Использование (Персонализация): При получении нового запроса система корректирует стандартные результаты поиска, учитывая историю пользователя (например, повышая ранее посещенные сайты или используя Stay-time).

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

    Критически высокая. Хотя патент подан в 2005 году, он описывает фундаментальные механизмы сбора данных и персонализации, которые стали стандартом. Мультиплатформенность и объединение данных пользователя с разных устройств являются основой современных экосистем Google. Механизмы персонализации на основе истории поиска и поведения остаются ключевым элементом ранжирования.

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

    Патент имеет высокое стратегическое значение для SEO. Он описывает конкретные механизмы, с помощью которых Google использует поведенческие данные для изменения ранжирования в реальном времени для конкретного пользователя. Это подчеркивает важность работы над вовлеченностью (Engagement), удержанием пользователей (Retention) и узнаваемостью бренда. Патент также демонстрирует ограничения традиционных инструментов отслеживания позиций, поскольку реальная выдача сильно зависит от истории конкретного пользователя.

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

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

    Client Assistant (Клиентский помощник)
    Компонент на стороне клиента (например, тулбар или плагин браузера), отвечающий за мониторинг действий пользователя и передачу этих данных на сервер.
    Client ID (Идентификатор клиента)
    Уникальный идентификатор, связанный с конкретным экземпляром клиентского приложения или устройства (например, cookie). Используется для отслеживания активности на конкретном устройстве.
    Derived Data (Производные данные)
    Информация, вычисленная на основе Event-Based Data. Примеры: профиль интересов пользователя, агрегированные оценки (Score) для контента, Query Sessions.
    Event-Based Data (Данные, основанные на событиях)
    Сырые данные о действиях пользователя. Включают типы событий: Query Event (запрос), Result Click Event (клик по результату), Ad Click Event (клик по рекламе), Browsing Event (просмотр страницы).
    History Score (Оценка истории)
    Метрика, связанная с событием. Может учитывать время, прошедшее с момента события (например, снижаться со временем).
    Preferred Locations (Предпочтительные местоположения)
    Набор сайтов, страниц или рекламных объявлений, которые система определила как предпочтительные для пользователя на основе анализа его истории (частота посещений, Stay-time и т.д.).
    Query Session (Сессия запросов)
    Группа связанных запросов и действий (кликов), выполненных в течение ограниченного периода времени (браузинг-сессии).
    Score (Оценка)
    Производная оценка, присваиваемая контенту (ContentID). Учитывает частоту кликов, Stay-time, время последнего посещения. Используется для ранжирования Preferred Locations и персонализации.
    Stay-time (Время пребывания)
    Оценка времени, которое пользователь провел на странице. Используется как показатель интереса к контенту при расчете Score.
    User ID (Идентификатор пользователя)
    Уникальный идентификатор, связанный с учетной записью пользователя (например, аккаунт Google). Служит для объединения данных с разных Client ID.
    User Information Database (База данных информации о пользователе)
    Центральное хранилище, содержащее записи пользователей (User Records), включающие Event-Based Data и Derived Data.

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

    Патент фокусируется на инфраструктуре управления данными с разных источников (Claims 1-25).

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

    1. Хранение первой информации о браузинге (от первого клиента), связанной с User ID.
    2. Хранение второй информации о браузинге (от второго клиента), связанной с его Client ID. (Обе включают информацию о просмотренных веб-страницах).
    3. Если второй Client ID не связан с User ID, система условно связывает его на основании инструкции от пользователя.
    4. После связывания система условно объединяет (merging) вторую информацию о браузинге с первой в соответствии с условиями объединения.

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

    После того как Client ID связан с User ID, последующая информация о браузинге с этого клиента связывается с User ID независимо от того, вошел ли пользователь в службу входа (log-in service). Это позволяет системе постоянно собирать данные с устройства, как только оно было связано с аккаунтом.

    Claim 5 (Зависимый от 1): Детализирует процесс объединения (merging).

    После связывания Client ID с User ID система проверяет, выполнены ли условия для объединения данных. Если да, пользователю отправляется предложение объединить данные (merge offer). Объединение происходит в соответствии с ответом пользователя. Это позволяет импортировать историю, накопленную до входа в аккаунт, в общий профиль.

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

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

    CRAWLING – Сканирование и Сбор данных (Data Acquisition)
    Патент описывает механизм сбора пользовательской активности. Client Assistant выступает в роли агента сбора данных, мониторящего запросы, клики и просмотры страниц на стороне клиента и передающего их в User Information Database.

    INDEXING – Индексирование (User Data Processing)
    Полученные сырые данные (Event-Based Data) индексируются и обрабатываются. Система вычисляет Derived Data — например, строит профиль интересов, рассчитывает Stay-time, определяет Preferred Locations и группирует активность в Query Sessions.

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

    RANKING / RERANKING – Ранжирование и Переранжирование
    Основное применение для SEO. Система использует данные из User Information Database для корректировки результатов поиска. Это может включать:

    • Повышение (boosting) результатов, которые пользователь посещал ранее.
    • Повышение результатов с сайтов, классифицированных как Preferred Locations.
    • Понижение (demoting) результатов, которые ранее были показаны, но не выбраны пользователем.
    • Добавление блока персонализированных результатов или визуальных индикаторов.

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

    • Действия пользователя: запросы, клики (результаты, реклама), посещенные URL, временные метки.
    • Идентификаторы: Client ID, User ID (при входе).
    • Настройки подписки пользователя (разрешение на сбор данных).

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

    • Записи в User Information Database (Event-Based Data).
    • Вычисленные Derived Data (профили, Preferred Locations).
    • Персонализированный набор результатов поиска.

    На что влияет

    • Все типы контента и запросов: Механизм универсален и применяется ко всем типам поисковой активности, включая веб-поиск, поиск товаров (Product Events) и взаимодействие с рекламой (Ad Click Events).
    • Повторные и уточняющие запросы: Наибольшее влияние оказывается на запросы, связанные с темами, которые пользователь изучал ранее, так как система имеет больше данных для персонализации.

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

    • Сбор данных: Постоянно, если пользователь подписан на сбор истории (subscribed) и не активировал функцию «snooze» (временная приостановка записи). Согласно Claim 3, сбор может продолжаться даже после выхода из аккаунта, если устройство было связано с ним ранее.
    • Объединение данных (Merging): Активируется, когда пользователь входит в аккаунт (User ID) с устройства (Client ID), которое имеет необъединенную историю.
    • Персонализация: При каждом поисковом запросе, для которого у системы есть релевантная история пользователя.

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

    Процесс А: Сбор и обработка данных

    1. Мониторинг: Client Assistant или сервер отслеживает действия пользователя.
    2. Передача и прием: Информация о действии передается на Query Server.
    3. Идентификация источника: Система определяет Client ID и/или User ID.
    4. Определение типа данных: Классификация события (запрос, клик, просмотр и т.д.).
    5. Проверка подписки: Система проверяет, разрешил ли пользователь запись этого типа данных и не активен ли режим «snooze».
    6. Фильтрация (Опционально): Удаление нежелательных событий.
    7. Сохранение: Запись события в User Information Database.
    8. Пересчет производных данных: Обновление Derived Data (например, Preferred Locations, профиль пользователя), которые зависят от нового события.

    Процесс Б: Управление несколькими источниками (Кросс-девайс)

    1. Вход в систему: Пользователь входит в сервис (используя User ID).
    2. Обнаружение клиента: Система получает Client ID текущего устройства/браузера.
    3. Проверка связи: Определяется, связан ли этот Client ID с данным User ID.
    4. Предложение связи (если не связан и условия выполнены): Пользователю предлагается связать этот клиент с его аккаунтом.
    5. Ассоциация: При согласии пользователя Client ID связывается с User ID.
    6. Предложение объединения (Merge): Система предлагает объединить историю, ранее накопленную под этим Client ID, с данными User ID.
    7. Объединение данных: При согласии данные объединяются.
    8. Запись активности: Текущая активность записывается под User ID.

    Процесс В: Персонализация поиска

    1. Получение запроса.
    2. Выполнение запроса: Поиск по основному репозиторию документов.
    3. Получение результатов: Формирование базового набора результатов.
    4. Корректировка на основе истории: Система анализирует User Information Database и корректирует результаты. Это включает изменение порядка (reordering), добавление индикаторов посещений или отображение блока истории поиска.

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

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

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

    • Поведенческие факторы:
      • Queries (Запросы): Текст запросов, введенных пользователем.
      • Result Clicks (Клики по результатам): Какие ссылки в выдаче были выбраны пользователем.
      • Ad Clicks (Клики по рекламе): Взаимодействие с рекламными объявлениями.
      • Browsing Data (Данные браузинга): Посещенные URL (ContentID), не обязательно через поиск.
      • Stay-time (Время пребывания): Оценка времени, проведенного на посещенных страницах.
    • Пользовательские факторы:
      • User ID и Client ID: Идентификаторы аккаунта и устройства/браузера.
      • User-modified ranking values: Явные оценки или веса, заданные пользователем для конкретных сайтов.
      • Annotations/Labels: Метки или аннотации, добавленные пользователем к контенту.
    • Временные факторы:
      • Timestamp: Время каждого события. Используется для определения свежести (Recency), частоты (Frequency) и последовательности действий.

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

    • Score (Оценка контента): Агрегированная метрика для определения важности ресурса для пользователя. Рассчитывается на основе частоты посещений, Stay-time, свежести последнего визита. Может уменьшаться, если ресурс был показан в выдаче, но не выбран.
    • History Score: Метрика, связанная с конкретным событием, которая может уменьшаться со временем (time-based ranking value).
    • Instance Visit Score / Total Visit Score: Оценка отдельного посещения (Instance), которая снижается со временем. Общая оценка (Total) страницы может быть суммой оценок всех отдельных посещений.
    • User Profile (Профиль пользователя): Упоминается как пример Derived Data, генерируемый из событий. Может представлять собой взвешенный набор категорий интересов (например, темы ODP).

    Выводы

    1. Единый профиль пользователя как цель: Google стремится создать унифицированное представление о пользователе, агрегируя данные со всех устройств и приложений. Механизм связывания Client ID с User ID и последующее объединение историй является ключевым для этого.
    2. Постоянное отслеживание (Claim 3): После первой ассоциации клиента с аккаунтом сбор данных с этого клиента может продолжаться и связываться с User ID, даже если пользователь не вошел в систему в данный момент.
    3. Поведенческие данные как основа персонализации: Патент детально описывает использование имплицитных сигналов (запросы, клики, просмотры, Stay-time) для изменения ранжирования. Предпочтения пользователя выводятся алгоритмически.
    4. «Preferred Locations» как автоматическое избранное: Система автоматически определяет важные для пользователя сайты на основе частоты и глубины взаимодействия. Эти сайты могут получать преимущество в персонализированном ранжировании.
    5. Влияние истории на ранжирование: Патент прямо указывает на корректировку результатов поиска. Это включает повышение ранее посещенных страниц или сайтов, а также потенциальное понижение игнорируемых результатов.
    6. Значимость Stay-time: Время пребывания на сайте рассматривается как важный показатель интереса и используется при расчете оценок (Score) контента для пользователя.

    Практика

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

    • Фокус на вовлеченности и времени пребывания (Stay-time): Поскольку Stay-time используется для определения предпочтений пользователя (Preferred Locations), необходимо оптимизировать контент и UX так, чтобы удерживать внимание пользователя. Это подтверждает важность качественного контента и CRO (Conversion Rate Optimization) для SEO.
    • Стимулирование повторных визитов (Retention): Частота посещений является ключевым фактором для повышения сайта в персонализированной выдаче. Стратегии должны быть направлены на формирование лояльной аудитории (email-рассылки, качественный контент, формирование сильного бренда).
    • Оптимизация под путь пользователя (User Journey): Понимая, что прошлые поиски и клики влияют на будущие результаты (через Query Sessions и профилирование), необходимо выстраивать контентную стратегию, которая поддерживает пользователя на разных этапах изучения темы и решения задачи.
    • Оптимизация CTR сниппетов: Патент указывает, что Score может быть негативно скорректирован, если пользователь видит результат в выдаче, но не кликает на него. Работа над привлекательностью сниппетов критична для поддержания видимости в персонализированной выдаче.

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

    • Кликбейт и короткие сессии: Привлечение трафика с помощью обманчивых заголовков приведет к коротким Stay-time. Это негативно скажется на оценке (Score) контента для данного пользователя и может привести к понижению в его персонализированной выдаче.
    • Игнорирование UX и удобства навигации: Сложности в потреблении контента, ведущие к быстрому уходу пользователя, будут интерпретироваться как низкий интерес, что ухудшит персонализированное ранжирование.
    • Полная зависимость от стандартных трекеров позиций: Патент подчеркивает, что выдача динамична и зависит от истории пользователя. Опираться только на данные о позициях в «стерильной» выдаче недостаточно для оценки реальной видимости сайта у целевой аудитории.

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

    Этот патент подтверждает, что поведенческие факторы являются неотъемлемой частью ранжирования через механизмы персонализации. Для Senior SEO-специалистов это означает, что стратегия не может быть ограничена только технической оптимизацией и ссылками; она должна включать глубокую работу над качеством продукта, пользовательским опытом и формированием бренда. Успех в SEO все больше зависит от того, насколько хорошо сайт удовлетворяет интент пользователя и становится для него предпочтительным источником информации (Preferred Location).

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

    Сценарий: Повышение сайта в персонализированной выдаче через контент-маркетинг

    1. Действие: SEO-команда создает серию глубоких экспертных статей по теме «Выбор треккинговых ботинок». Статьи хорошо структурированы и содержат детальные обзоры.
    2. Поведение пользователя: Пользователь находит первую статью, проводит на ней значительное время (высокий Stay-time). Через несколько дней он возвращается на сайт (повторный визит) и читает вторую статью.
    3. Механизм патента: Система Google фиксирует эти события (Browsing Events, Result Clicks). На основе частоты визитов и Stay-time система увеличивает Score этого сайта для данного пользователя и может классифицировать его как Preferred Location по этой тематике.
    4. Результат: Когда пользователь вводит новый запрос, например, «лучшие бренды треккинговых ботинок», сайт команды получает значительное повышение (boost) в его персонализированной выдаче, опережая конкурентов, которые могли иметь более сильные классические факторы ранжирования, но с которыми пользователь ранее не взаимодействовал.

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

    Как этот патент влияет на работу инструментов отслеживания позиций (Rank Trackers)?

    Патент демонстрирует, что «объективных» позиций практически не существует для пользователей с историей. Поскольку результаты корректируются на основе истории пользователя, данные в стандартных трекерах (которые эмулируют «чистый» поиск) могут сильно отличаться от того, что видят реальные пользователи. Это требует смещения фокуса с мониторинга абсолютных позиций на анализ реального трафика, видимости в рамках целевых сегментов и метрик вовлеченности.

    Что такое «Stay-time» и как Google его измеряет согласно патенту?

    Stay-time — это оценка времени, проведенного пользователем на странице. Патент предлагает несколько методов измерения. Один из них — через Client Assistant (например, тулбар), который мониторит активность локально. Другой метод — измерение времени между кликом по результату на странице выдачи и следующим кликом на той же странице выдачи (pogo-sticking). Высокий Stay-time используется как показатель интереса.

    Означает ли этот патент, что Google отслеживает пользователей, даже если они вышли из аккаунта?

    Да, в двух случаях. Во-первых, активность отслеживается анонимно через Client ID (cookie браузера) и может быть позже объединена с аккаунтом (Claim 5). Во-вторых, если пользователь хоть раз связал Client ID с User ID, то согласно Claim 3, сбор данных с этого клиента продолжается и связывается с User ID независимо от того, выполнен ли вход в систему в данный момент.

    Как сделать свой сайт «Preferred Location» для целевой аудитории?

    Preferred Locations определяются автоматически на основе имплицитных сигналов. Для этого необходимо максимизировать частоту посещений (Frequency), свежесть посещений (Recency) и время пребывания (Stay-time). На практике это достигается через создание высококачественного контента, который решает задачи пользователя, удобный UX и стратегии удержания аудитории (брендинг, рассылки).

    В чем разница между Client ID и User ID?

    Client ID идентифицирует устройство или приложение (например, конкретный браузер через cookie). User ID идентифицирует пользователя (например, аккаунт Google). Один пользователь (User ID) может иметь несколько Client ID (телефон, рабочий компьютер, домашний планшет). Цель системы — связать все Client ID с соответствующим User ID для создания полного профиля.

    Что происходит, когда пользователь удаляет историю поиска или отключает ее сохранение?

    Патент предусматривает механизмы редактирования и подписки. Если пользователь удаляет события или отключает подписку (unsubscribe), эти данные становятся недоступными. Это влияет на персонализацию и вызывает пересчет производных данных (Derived Data), таких как Preferred Locations или профиль интересов, уже без учета удаленной информации.

    Использует ли система данные о посещении сайтов не через поиск (прямые заходы)?

    Да. Патент описывает сбор Browsing Events (события браузинга), которые не обязательно связаны с поисковым запросом. Если система может отслеживать эту активность (например, через Client Assistant или другие механизмы, такие как браузер Chrome, если он выполняет эту функцию), эти данные также используются для профилирования и определения Preferred Locations.

    Может ли сайт быть понижен в выдаче на основе истории пользователя?

    Да. В патенте упоминается, что оценка (Score) контента может быть негативно скорректирована, если пользователь видит результат в выдаче, но не кликает на него. Также, если взаимодействие с сайтом приводит к низкому Stay-time, это может снизить его рейтинг в персонализированной выдаче этого пользователя.

    Что такое «Query Session» и как это используется?

    Query Session — это группа тематически или темпорально связанных запросов и кликов. Система анализирует эти сессии для понимания контекста и интересов пользователя. При поиске система может предлагать запросы из прошлых сессий или использовать данные сессии для ранжирования результатов, которые лучше соответствуют общему интересу сессии, а не только последнему запросу.

    Актуален ли этот патент, учитывая современные инициативы по отказу от third-party cookies?

    Патент актуален, так как описывает сбор First-Party данных (данных, которые Google собирает о своих пользователях в рамках своей экосистемы). Механизмы User ID (вход в аккаунт) и сбор данных через собственные приложения (например, Chrome, если он выступает в роли Client Assistant) не зависят от third-party cookies и обеспечивают надежный сбор данных для персонализации.

    Навигация
    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх
    Telegram
    © 2025 SEO HARDCORE

    Type above and press Enter to search. Press Esc to cancel.