Как Яндекс детально отслеживает и синхронизирует поведение пользователей в поиске между устройствами

Описание

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

Патент решает задачу обеспечения непрерывности пользовательского опыта при использовании поиска на разных устройствах (cross-device experience). Он устраняет фрагментацию поисковой сессии, позволяя пользователю продолжить поиск с того же места на другом устройстве. С точки зрения инфраструктуры поиска, патент описывает механизм для централизованного и детального логирования пользовательских взаимодействий (user interactions), который преодолевает ограничения локальной истории браузера и позволяет собирать более полные поведенческие данные.

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

Запатентованы способ и система для синхронизации сессий просмотра страниц (в частности, поисковых сессий). Суть изобретения заключается в создании и хранении на сервере детальной истории взаимодействий пользователя (Server-Stored History). Эта история формируется путем перехвата контрольных сообщений (Control Messages) между клиентским устройством и сервером, что позволяет фиксировать даже те действия, которые не отражаются в стандартной локальной истории браузера (например, какой именно результат на SERP был выбран).

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

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

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

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

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

Влияние на SEO значительно (7/10). Патент не описывает алгоритм ранжирования, но он детально раскрывает инфраструктуру и методологию, которую Яндекс использует для сбора поведенческих данных (Povedencheskie Faktory — PF). Он подтверждает, что Яндекс централизованно отслеживает всю поисковую сессию — от запроса до кликов на SERP и последующей навигации (включая возвраты к выдаче) — и связывает эти данные с профилем пользователя между устройствами. Это подчеркивает критическую важность оптимизации поведенческих факторов на всех этапах взаимодействия пользователя с сайтом.

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

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

Browser History (Браузерная история / Локальная история)

История посещенных URL, которая хранится локально на электронном устройстве пользователя средствами браузера.

Control Messages (Контрольные сообщения)

Сообщения (например, HTTP-запросы, ответы, AJAX-вызовы), которыми обмениваются клиентское устройство и сервер во время сессии просмотра. Перехват этих сообщений является основой механизма сбора данных.

First/Second Session (Первая/Вторая сессия просмотра страниц)

Последовательные сеансы взаимодействия пользователя с поисковой системой или веб-ресурсами. Вторая сессия может происходить на том же или другом устройстве.

Модуль серверного сессионного хранилища (Server session storage module)

Компонент на стороне сервера (в патенте Модуль 160), отвечающий за перехват контрольных сообщений, логирование взаимодействий и хранение Server-Stored History.

Server-Stored History (Хранящаяся на сервере история)

Централизованно сохраненный детальный лог пользовательских взаимодействий в рамках сессии. Включает данные, которые могут быть «невидимыми» для локальной Browser History.

Synchronization Function (Функция синхронизации)

Пользовательская настройка (в браузере или аккаунте), разрешающая сохранение и передачу Server-Stored History между устройствами.

User Interactions (Пользовательские взаимодействия)

Любые действия пользователя в рамках сессии: ввод текста, выбор предложений, клики по результатам поиска, переходы по ссылкам, использование навигации (кнопка «назад»).

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

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

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

1. Сервер получает запрос на вторую сессию после начала первой сессии.
2. Проверяется условие: пользователь подключил функцию синхронизации.
3. Если условие выполнено, сервер инициирует отображение второй сессии.
4. Ключевой элемент: Вторая сессия включает в себя Server-Stored History из первой сессии.
5. Критическое уточнение: Server-Stored History включает как минимум одно пользовательское взаимодействие, которое является невидимым для локальной Browser History.

Это означает, что Яндекс патентует не просто синхронизацию посещенных URL, а синхронизацию более глубоких данных о поведении — например, не просто факт посещения SERP и целевого сайта, а то, какой именно результат на SERP был нажат для перехода.

Claim 5: Уточняет, что Server-Stored History включает указание на то, какие поисковые результаты были выбраны пользователем.

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

Claim 9 и 10 (Механизм сбора данных): Описывают, как формируется Server-Stored History.

1. Во время первой сессии сервер получает и сохраняет указания на взаимодействия.
2. Получение данных происходит путем перехвата контрольных сообщений (Control Messages), которыми обмениваются устройство и сервер.

Это подтверждает, что система работает как прокси или сниффер на уровне приложений, логируя весь обмен данными.

Claim 11 (Привязка данных): Сохранение взаимодействий происходит в связи с пользовательским профилем. Это указывает на использование аутентификации (например, Яндекс Паспорт, упомянутый в описании) для кросс-девайсного трекинга.

Claim 15 (Независимый пункт — Сервер): Описывает сервер, настроенный для выполнения вышеописанного способа.

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

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

CRAWLING – Сканирование и Сбор данных (Data Acquisition)
Это основная область применения патента, но в контексте сбора поведенческих данных, а не контента сайтов. Модуль серверного сессионного хранилища действует как система сбора данных в реальном времени, перехватывая и логируя взаимодействия пользователя с поисковой системой и посещаемыми ресурсами.

RANKING – Ранжирование (Косвенное влияние)
Патент не описывает процесс ранжирования. Однако собранные данные (Server-Stored History) являются сырьем для расчета поведенческих факторов (PF), которые затем используются на этапах L3/L4 ранжирования. Детальные логи о кликах, последовательности действий и пост-клик активности необходимы для обучения ML-моделей (CatBoost) и расчета метрик качества (Proxima, Proficit).

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

• Клиентское устройство (Браузер/Приложение): Генерирует Control Messages в ответ на действия пользователя.
• Сервер: Обрабатывает запросы и генерирует ответы (SERP, контент).
• Модуль серверного сессионного хранилища: Перехватывает Control Messages между Клиентом и Сервером, извлекает из них User Interactions и сохраняет их в привязке к профилю пользователя.

Входные данные: Контрольные сообщения (HTTP-запросы/ответы, данные форм, AJAX).

Выходные данные: Структурированный лог взаимодействий (Server-Stored History), привязанный к профилю пользователя.

На что влияет

• Пользовательский опыт: Основное прямое влияние — обеспечение непрерывности поиска между устройствами.
• Сбор поведенческих данных: Влияет на полноту и детализацию данных, собираемых Яндексом обо всех типах запросов (информационные, коммерческие и т.д.) и взаимодействии со всеми типами контента. Система позволяет точно атрибутировать поведение пользователя (успех или неудача сессии) к конкретным сайтам и запросам.

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

Алгоритм работает в двух режимах:

1. Режим логирования: Активируется при любом взаимодействии пользователя с системой (запрос, клик, навигация). В патенте указано, что сохранение истории может выполняться в ответ на активацию пользователем функции синхронизации.
2. Режим синхронизации (отображения истории): Активируется при начале новой сессии, при условии, что пользователь аутентифицирован и функция синхронизации включена (Claim 1).

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

Фаза 1: Сбор данных (Первая сессия)

1. Предварительное условие: Пользователь аутентифицирован (например, через Яндекс Паспорт) и активировал функцию синхронизации.
2. Мониторинг взаимодействий: Пользователь выполняет действия (например, вводит запрос в браузере).
3. Генерация сообщений: Браузер генерирует Контрольные сообщения и отправляет их на Сервер. (Например, сообщение 1006 с термином запроса, как описано в патенте).
4. Обработка и ответ: Сервер обрабатывает запрос и отправляет ответ. (Например, сообщение 1008 с SERP).
5. Перехват и Логирование: Модуль серверного сессионного хранилища перехватывает эти сообщения (и входящие, и исходящие). Он извлекает детали взаимодействия (например, «Отображена SERP X»).
6. Отслеживание кликов и навигации: Пользователь кликает по результату. Браузер генерирует сообщение (1010). Модуль перехватывает его и логирует («Выбран результат Y на SERP X»). Также отслеживаются последующие переходы (сообщение 1014) и возвраты назад (сообщение 1018).
7. Централизованное хранение: Все залогированные взаимодействия сохраняются как Server-Stored History и ассоциируются с профилем пользователя.

Фаза 2: Синхронизация (Вторая сессия)

1. Начало сессии: Пользователь начинает новую сессию (на том же или другом устройстве) и аутентифицируется.
2. Запрос синхронизации: Устройство отправляет запрос на вторую сессию.
3. Проверка условий: Сервер проверяет, включена ли функция синхронизации для этого профиля.
4. Извлечение истории: Если функция включена, сервер извлекает Server-Stored History, связанную с предыдущими сессиями.
5. Передача и Отображение: Сервер инициирует отображение второй сессии, включая доступ к извлеченной истории.

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

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

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

• Поведенческие факторы: Это основные данные, которые собирает система. В патенте явно упоминается сбор следующих взаимодействий:
  • Ввод поискового запроса.
  • Выбор из списка поисковых предложений (саджестов).
  • Выбор конкретных результатов поиска на SERP (клики по сниппетам).
  • Переходы между различными веб-ресурсами (пост-клик навигация).
  • Использование навигации браузера (например, активация кнопки «назад» для возврата к предыдущей странице).
• Пользовательские факторы: Данные аутентификации пользователя (для привязки истории к профилю), настройки функции синхронизации (включена/выключена).
• Технические факторы: Сырые данные контрольных сообщений (Control Messages), которыми обмениваются клиент и сервер.

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

Патент не описывает расчет метрик ранжирования (таких как CTR, Dwell Time, Bounce Rate или Proxima). Он описывает инфраструктуру для сбора сырых данных, необходимых для последующего расчета этих метрик.

Ключевым элементом является формирование Server-Stored History — детального, структурированного лога событий, привязанного ко времени и пользователю.

Метод сбора данных основан на перехвате и анализе контрольных сообщений (Claim 10). Это позволяет системе точно фиксировать последовательность действий пользователя (User Journey).

Выводы

1. Подтверждение инфраструктуры для сбора ПФ: Патент детально описывает, как Яндекс собирает поведенческие данные. Это не абстрактный трекинг, а конкретный механизм перехвата контрольных сообщений для фиксации каждого шага пользователя.
2. Глубина трекинга превосходит локальную историю: Яндекс логирует не только посещенные URL, но и гранулярные взаимодействия, «невидимые» локально (Claim 1). Это включает точное знание того, какой результат на SERP привел к клику (Claim 5).
3. Отслеживание пост-клик активности: Система явно отслеживает поведение пользователя после ухода с SERP, включая навигацию между ресурсами (Claim 6) и действия внутри ресурса (Claim 7), такие как использование кнопки «назад». Это критически важно для оценки качества сайта (например, фиксация быстрого возврата к выдаче).
4. Централизация и кросс-девайсный трекинг: Данные хранятся централизованно и привязываются к профилю пользователя (Claim 11). Это позволяет Яндексу иметь единое представление о поведении пользователя независимо от используемого устройства.
5. Основа для Метрик Качества: Хотя патент сфокусирован на синхронизации как пользовательской функции, описанная инфраструктура является фундаментом для сбора данных, необходимых для расчета метрик Proxima и Профицит.

Практика

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

• Оптимизация сниппетов для повышения CTR: Поскольку система детально фиксирует, какой результат был выбран на SERP (Claim 5), привлекательность сниппета критически важна для генерации первичного позитивного поведенческого сигнала (выигрыш клика).
• Максимизация вовлеченности и удержание пользователя: Система отслеживает пост-клик активность, включая навигацию и использование кнопки «назад». Необходимо минимизировать быстрые возвраты к выдаче (pogo-sticking). Обеспечивайте высокую релевантность контента, отличный UX и понятную внутреннюю навигацию, чтобы пользователь оставался на сайте и решал свою задачу.
• Оптимизация всего пути пользователя (User Journey): Яндекс видит всю сессию. Важно не просто привлечь трафик на лендинг, но и обеспечить позитивный опыт при дальнейшем взаимодействии с сайтом. Анализируйте пути пользователей и устраняйте тупики в навигации.
• Стимулирование лояльности и повторных визитов: Поскольку данные привязываются к профилю пользователя кросс-девайсно, формирование лояльной аудитории, которая регулярно взаимодействует с вашим ресурсом с разных устройств, усиливает позитивные поведенческие сигналы в долгосрочной перспективе.

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

• Кликбейт и обман ожиданий пользователя: Использование заголовков или сниппетов, которые привлекают клик, но не соответствуют содержанию страницы. Это приведет к быстрому возврату пользователя к выдаче (активация кнопки «назад»), что явно отслеживается системой (сообщение 1018 в описании) и будет зафиксировано как негативный сигнал.
• Игнорирование UX и скорости загрузки: Плохой пользовательский опыт, медленная работа сайта или навязчивая реклама провоцируют отказ пользователя от взаимодействия с сайтом. Эти поведенческие паттерны будут детально залогированы.
• Накрутка поведенческих факторов (ПФ): Хотя патент не описывает антифрод-системы, он демонстрирует уровень детализации логов, доступных Яндексу. Детальные логи взаимодействий облегчают обнаружение аномальных паттернов поведения, характерных для ботов или мотивированного трафика.

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

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

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

Сценарий 1: Фиксация негативного сигнала (Pogo-sticking)

1. Действие пользователя: Пользователь вводит запрос «купить холодильник Samsung модель XYZ».
2. Логирование (Яндекс): Система фиксирует запрос и отображение SERP.
3. Действие пользователя: Пользователь кликает на Сайт А (позиция 2).
4. Логирование (Яндекс): Модуль перехватывает сообщение (1010) и логирует: «Выбран результат 2 (Сайт А)».
5. Действие пользователя: Сайт А медленно грузится или цена не соответствует сниппету. Пользователь немедленно нажимает кнопку «назад».
6. Логирование (Яндекс): Модуль перехватывает сообщение о возврате (1018) и логирует: «Возврат к SERP с Сайта А через Х секунд». Это формирует негативный поведенческий сигнал для Сайта А.

Сценарий 2: Фиксация позитивного сигнала (Решение задачи)

1. Действие пользователя: Пользователь ищет «как приготовить пасту карбонара». Кликает на Сайт Б.
2. Логирование (Яндекс): Фиксируется клик на Сайт Б.
3. Действие пользователя: Пользователь изучает рецепт, затем переходит по внутренней ссылке на статью «выбор бекона для карбонары» на Сайте Б.
4. Логирование (Яндекс): Модуль перехватывает сообщение (1014) и логирует переход на внутреннюю страницу. Это указывает на вовлеченность.
5. Результат: Длительное время сессии и внутренняя навигация фиксируются как позитивные сигналы, подтверждающие качество и релевантность Сайта Б.

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