Как Яндекс автоматически создает гео-уведомления на основе истории поисковых запросов пользователя

Описание

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

Патент решает задачу упрощения использования технологий геозонирования (geo-fencing). Вместо ручной настройки уведомлений, что особенно сложно для категорийных интересов (например, «все кофейни поблизости»), система автоматизирует этот процесс. Изобретение использует историю веб-поиска пользователя как индикатор намерения, позволяя автоматически связывать онлайн-интерес с офлайн-контекстом (Online-to-Offline, O2O) и проактивно уведомлять пользователя о релевантных объектах поблизости.

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

Запатентована система и метод предоставления уведомлений на основе геолокации, привязанных к результатам предыдущих веб-поисков пользователя. Суть изобретения заключается в автоматическом создании виртуальных периметров (geo-fences) вокруг физических локаций, присутствовавших в результатах поиска. Система отслеживает текущее местоположение пользователя и инициирует уведомление, когда он попадает в одну из этих зон.

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

Пользователь выполняет поиск на первом устройстве (First Client Device). Система идентифицирует пользователя (например, через аккаунт Яндекс), анализирует результаты поиска и сохраняет физические локации этих результатов в базе данных, связывая их с идентификатором пользователя. В дальнейшем система мониторит текущее местоположение устройства пользователя (того же или другого, связанного с аккаунтом — Second Client Device). Если устройство оказывается в пределах заданного расстояния (First Threshold Value) от сохраненной локации, система отправляет на устройство уведомление, которое может включать рекламу.

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

Высокая. Концепция O2O (Online-to-Offline) и использование геолокационных данных для повышения вовлеченности являются ключевыми для современных поисковых и картографических сервисов. Автоматическое связывание истории поиска с проактивными уведомлениями крайне актуально для локального маркетинга, хотя практическая реализация может быть ограничена политиками конфиденциальности и ограничениями ОС на фоновое отслеживание.

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

Влияние на SEO значительно для локального бизнеса (6/10). Патент не описывает алгоритмы ранжирования, но он критически важен для стратегий Local SEO и O2O. Он демонстрирует механизм, который увеличивает долгосрочную ценность попадания в топ выдачи по локальным запросам. Видимость в SERP может конвертироваться в будущий пешеходный трафик через автоматические уведомления. Это не меняет того, *как* ранжироваться, но усиливает то, *почему* локальное ранжирование важно для бизнеса с физическими точками.

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

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

Client Device (First/Second) (Клиентское устройство Первое/Второе)

Электронные устройства пользователя (смартфон, ПК, планшет). First Client Device используется для инициирования поиска. Second Client Device может быть другим устройством, на которое приходят уведомления, если оно связано с тем же идентификатором.

Geo-fence (Геозона)

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

Location Information (Информация о местоположении)

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

Threshold Value (First/Second/Third) (Пороговое значение Первое/Второе/Третье)

Заданные параметры расстояния, используемые для триггеров:

• First Threshold Value: Расстояние до объекта, при котором отправляется уведомление пользователю (основная геозона).
• Second Threshold Value: Расстояние до объекта, при котором система прекращает отправку повторяющихся уведомлений (например, пользователь прибыл).
• Third Threshold Value: Расстояние до объекта, при котором система может отправить уведомление самому бизнесу о приближении пользователя.

User Account / Device Identification (Идентификация пользователя/устройства)

Информация (логин, e-mail, cookie, IMEI, IMSI), позволяющая системе связать поисковую сессию и текущее местоположение пользователя, в том числе на разных устройствах.

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

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

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

1. Получение от первого клиентского устройства (First Client Device) идентификатора пользователя/устройства и поискового запроса.
2. Выполнение поиска и отправка результатов поиска на устройство.
3. Получение информации о местоположении (Location Information) для по крайней мере некоторых из этих результатов поиска.
4. Сохранение этих результатов и их местоположений в базе данных в ассоциации с идентификатором.
5. Получение информации о текущем местоположении устройства (первого ИЛИ второго клиентского устройства), связанного с этим идентификатором.
6. Сравнение текущего местоположения с местоположением сохраненных результатов поиска и первым пороговым значением (First Threshold Value).
7. Если текущее местоположение находится в пределах порогового значения, отправка информации на устройство для генерации уведомления.

Claim 3 и 4 (Зависимые пункты): Уточняют механизм кросс-девайсности.

Уведомление может быть отправлено на второе устройство (Second Client Device), отличное от того, с которого был сделан поиск. Для этого второе устройство должно быть связано с тем же идентификатором (например, через вход в ту же учетную запись).

Claim 6-9 (Зависимые пункты): Описывают логику повторения и прекращения уведомлений.

Проверка местоположения повторяется периодически. Повторение прекращается по истечении времени, после определенного количества повторений или если устройство оказывается в пределах Second Threshold Value (пользователь прибыл на место).

Claim 11 (Зависимый пункт): Описывает монетизацию.

Уведомление может включать рекламную информацию (advertising information), например, купоны.

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

Если устройство находится в пределах Third Threshold Value, система может отправить информацию о пользователе/устройстве на электронное устройство, связанное с этим результатом поиска (т.е. уведомить бизнес о приближении клиента).

Claim 18 (Зависимый пункт): Уточняет триггер сохранения.

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

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

Изобретение не является частью классической архитектуры ранжирования, а представляет собой пользовательскую функцию (feature), работающую на стыке поисковых и геолокационных сервисов.

CRAWLING & INDEXING (Косвенно)
Для функционирования системы необходимо, чтобы в индексе Яндекса содержались точные и актуальные геолокационные данные (координаты) о сущностях (бизнесах, организациях, местах), которые появляются в результатах поиска.

RANKING & BLENDER (Обработка выдачи)
После того как выдача сформирована и отправлена пользователю, система (компонент пост-обработки или анализа сессий) сохраняет результаты, имеющие географическую привязку, в отдельную базу данных, ассоциируя их с идентификатором пользователя.

Location Services & Notification Infrastructure (Основное применение)
Основная работа происходит в инфраструктуре геолокационных сервисов. Эта система отслеживает местоположение клиентских устройств (вероятно, через установленные приложения Яндекса с доступом к GPS/Wi-Fi данным) и постоянно сравнивает его с сохраненными гео-зонами из истории поиска пользователя.

• Входные данные: Идентификатор пользователя/устройства, История поисковых запросов, Результаты поиска, Геолокация результатов поиска, Текущая геолокация устройства, Пороговые значения расстояния.
• Выходные данные: Уведомление пользователю (может включать рекламу, маршрут). Опционально: уведомление бизнесу.

На что влияет

• Конкретные типы контента и Ниши: Критическое влияние на Local SEO и все тематики с физическим присутствием: ритейл, рестораны (HoReCa), услуги, авто, медицина (YMYL с локацией), e-commerce с пунктами самовывоза. Не влияет на чисто информационные ресурсы.
• Специфические запросы: Локальные коммерческие и транзакционные запросы (например, «купить», «[услуга] в», «кафе поблизости»).

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

Алгоритм применяется в фоновом режиме после выполнения поискового запроса и при физическом перемещении пользователя.

• Триггеры активации:
  1. Выполнение пользователем поиска с результатами, имеющими географическую привязку.
  2. Сохранение этих результатов (автоматически или вручную по Claim 18).
  3. Перемещение устройства пользователя и обновление его местоположения.
  4. Вхождение устройства в пределы заданного порога (First Threshold Value) от локации сохраненного результата.
• Условия прекращения: Мониторинг прекращается по истечении заданного времени, после определенного количества проверок, или когда пользователь достиг цели (вошел во вторую гео-зону – Second Threshold Value).

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

Этап 1: Исходная поисковая сессия и Создание Геозон

1. Инициация и Идентификация: Пользователь вводит запрос на Устройстве 1. Устройство отправляет запрос и идентификатор пользователя (ID) на сервер.
2. Обработка и выдача: Сервер формирует выдачу и возвращает результаты на Устройство 1.
3. Извлечение Локаций: Сервер анализирует результаты выдачи и определяет их географические координаты.
4. (Опционально, Claim 18) Выбор пользователя: Система отслеживает, какие результаты выбрал (кликнул/сохранил) пользователь.
5. Сохранение Гео-целей: Релевантные результаты и их локации сохраняются в базе данных в привязке к ID пользователя. Создаются виртуальные гео-зоны на основе First Threshold Value.

Этап 2: Мониторинг и Уведомление

1. Мониторинг локации: Устройство 1 (или Устройство 2, связанное с тем же ID) периодически определяет и отправляет свое текущее местоположение.
2. Сравнение и Проверка порога: Сервер сравнивает текущее местоположение с сохраненными гео-целями.
3. Триггер уведомления (Пользователь): Если выполнено условие входа в гео-зону (First Threshold Value), сервер инициирует отправку уведомления на устройство. Уведомление может содержать рекламу (Claim 11).
4. Триггер уведомления (Бизнес) (Опционально, Claim 14): Если выполнено условие входа в более узкую зону (Third Threshold Value), сервер может уведомить бизнес о приближении пользователя.
5. Управление жизненным циклом: Мониторинг прекращается при срабатывании одного из условий остановки (время, количество проверок, достижение Second Threshold Value).

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

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

• Географические факторы: Являются основой системы. Координаты результатов поиска (извлеченные из бизнес-справочников, микроразметки). Данные о текущем местоположении клиентского устройства (GPS, Wi-Fi positioning, Cell-ID).
• Пользовательские факторы: Идентификатор аккаунта пользователя (User Account ID) или устройства (Device ID, IMEI, Cookie). Критически важны для связи истории поиска с текущим местоположением и кросс-девайсной работы.
• Контентные факторы: Текст поискового запроса. Метаданные результатов поиска (название организации, категория, адрес), используемые в тексте уведомления.
• Поведенческие факторы: (Опционально, Claim 18) Данные о взаимодействии пользователя с результатами поиска (клики, сохранения) могут использоваться как триггер для сохранения локации.
• Рекламные данные (Опционально): Рекламная информация (акции, купоны), получаемая от рекламодателей для включения в уведомления.

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

• Расстояние: Основная вычисляемая метрика. Рассчитывается как дистанция между текущими координатами устройства и координатами сохраненного результата поиска.
• Threshold Values (Пороговые значения): Предопределенные константы, задающие радиусы геозон (First, Second, Third Threshold Value). Условие срабатывания: Расстояние < Threshold Value.
• Временные метрики: Используются для управления частотой проверок (first period of time) и общим временем жизни мониторинга (second period of time).
• Счетчики: Используются для ограничения количества проверок местоположения (number of repetitions).

Выводы

1. Поиск как триггер для O2O: Яндекс рассматривает поисковую сессию не как конечный этап, а как начало взаимодействия, которое может быть продолжено в офлайне с помощью автоматических геолокационных триггеров.
2. Кросс-девайсная функциональность: Система изначально спроектирована для работы между различными устройствами (поиск на десктопе, уведомление на смартфоне), что подчеркивает важность единой экосистемы и идентификации пользователя.
3. Критичность качества локальных данных: Эффективность системы напрямую зависит от точности и полноты геолокационных данных о бизнесах, проиндексированных Яндексом (в частности, в Яндекс.Бизнес и Картах).
4. Новый канал локального маркетинга и лидогенерации: Система предусматривает интеграцию рекламы в уведомления (Claim 11) и возможность уведомлять бизнес о приближении заинтересованного пользователя (Claim 14), открывая возможности для проактивного сервиса и контекстного продвижения.
5. Гибкость активации: Система может работать как полностью автоматически, так и на основе явного выбора пользователя (Claim 18), что позволяет балансировать между удобством и контролем.

Практика

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

Патент не описывает ранжирование, но дает четкие указания для стратегии Local SEO, направленной на максимизацию офлайн-взаимодействия (O2O).

• Абсолютная точность данных в Яндекс.Бизнес и Картах: Убедитесь, что адрес и географические координаты (точка на карте) организации указаны с максимальной точностью. Ошибки в геолокации приведут к некорректному срабатыванию или отсутствию уведомлений.
• Максимизация видимости в локальном поиске: Обеспечение высоких позиций по локальным и категорийным запросам является необходимым условием. Если бизнес не попал в результаты поиска пользователя, система уведомлений не сможет его использовать.
• Оптимизация сниппетов и заголовков для уведомлений: Название и категория организации, отображаемые в поиске, могут быть использованы в тексте push-уведомления. Они должны быть понятными и мотивирующими к действию вне контекста поисковой сессии.
• Использование микроразметки LocalBusiness: Внедрите на сайте микроразметку Schema.org с точным указанием адреса и координат (geo), чтобы помочь Яндексу однозначно связать веб-страницу с физической локацией.
• Стимулирование кликов (Если реализован Claim 18): Если система сохраняет только те результаты, по которым кликнул пользователь, работа над CTR сниппетов становится еще более важной для активации этого механизма.

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

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

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

Этот патент подтверждает стратегический приоритет Яндекса в развитии локального поиска и инструментов для Online-to-Offline конверсий. Он показывает, что ценность поискового трафика не ограничивается немедленными кликами. Попадание в SERP создает отложенный эффект: система может «догнать» пользователя позже, когда он будет физически рядом. Это усиливает необходимость комплексной работы над представленностью компании в гео-сервисах Яндекса как ключевом элементе воронки продаж.

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

Сценарий 1: Кросс-девайсная отложенная покупка

1. Действие пользователя: Пользователь ищет на рабочем ПК (Устройство 1) «купить зимние шины в». Он просматривает несколько сайтов.
2. Действие системы: Яндекс сохраняет координаты магазинов шин из результатов поиска и связывает их с User Account пользователя (если реализован Claim 18, то сохраняются только те, на которые он кликнул).
3. Отложенный триггер: Через несколько дней пользователь едет по делам, используя Яндекс Навигатор на смартфоне (Устройство 2). Он проезжает в 500 метрах (First Threshold Value) от одного из сохраненных магазинов.
4. Результат: Яндекс отправляет уведомление: «Вы искали зимние шины. Магазин находится в 500 метрах. Скидка 10% сегодня (Claim 11)».

Сценарий 2: Локальный поиск и взаимодействие с бизнесом

1. Действие пользователя: Турист ищет в приложении Яндекс «лучшие стейкхаусы в центре».
2. Действие системы: Яндекс сохраняет локации релевантных ресторанов.
3. Отложенный триггер: Вечером турист гуляет и приближается к одному из этих стейкхаусов. Он получает уведомление с напоминанием и маршрутом.
4. Взаимодействие с бизнесом (Claim 14): Когда пользователь находится в 50 метрах (Third Threshold Value), система уведомляет хостес ресторана о приближении заинтересованного клиента.

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