Как Google определяет, когда и насколько заметно показывать персональные данные (бронирования, покупки) в результатах поиска

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

Auxiliary Pane (Вспомогательная панель)

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

Display Prominence (Значимость/Заметность отображения)

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

Electronic Documents (Электронные документы)

Источники для генерации User-Specific Data Records. Включают электронные письма (Emails), мгновенные сообщения, элементы календаря и т.д.

Knowledge Panel (Панель знаний)

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

Location Score (Оценка местоположения)

Метрика, используемая в некоторых Triggering Rules для определения близости местоположения, связанного с общим результатом поиска, к местоположению из личных данных пользователя (например, аэропорту назначения).

Search Results Pane (Панель результатов поиска)

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

Threshold Time (Пороговое время)

Заданный интервал времени (например, 24 часа), используемый для определения Display Prominence путем сравнения с разницей во времени до события.

Triggering Rules (Триггерные правила)

Набор условий, определяющих, следует ли отображать User-Specific Data Records в ответ на конкретный запрос. Правила анализируют запрос, стандартные результаты поиска и контекст.

User-Specific Data Records (Записи данных, специфичные для пользователя)

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

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

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

1. Система получает запрос от пользователя и стандартные результаты поиска.
2. Обрабатываются Triggering Rules на основе запроса и/или результатов.
3. Определяется, что набор User-Specific Data Records должен быть отображен.
4. Определяется Display Prominence для как минимум одной записи. Определение значимости включает:
   • Определение времени события, указанного в записи, и времени подачи запроса.
   • Вычисление разницы во времени между событием и запросом.
   • Сравнение разницы с пороговым значением (Threshold Time).
   • Если разница во времени соответствует (например, превышает) порог, значимость устанавливается на первое значение (низкая значимость).
   • Если разница во времени не соответствует (например, не превышает) порог, значимость устанавливается на второе значение (высокая значимость).
5. Результаты поиска и личные записи предоставляются для отображения в соответствии с установленной значимостью.

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

Claim 5 (Зависимый от 1): Уточняет одно из триггерных правил.

Отображение набора личных записей активируется на основании того, должна ли быть отображена Knowledge Panel в ответ на поисковый запрос.

Claim 6 (Зависимый от 1): Уточняет другое триггерное правило.

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

Claim 7 (Зависимый от 1): Уточняет еще одно триггерное правило.

Отображение активируется, если термин в поисковом запросе совпадает с информацией, содержащейся в User-Specific Data Records пользователя.

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

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

INDEXING – Индексирование (персональных данных)
На этом этапе происходит обработка приватных данных пользователя. Система (например, индексатор Gmail) извлекает информацию из Electronic Documents (писем, календаря), структурирует ее в User-Specific Data Records и сохраняет в защищенном хранилище. Это происходит отдельно от индексирования публичного веба.

QUNDERSTANDING – Понимание Запросов
На этом этапе система анализирует запрос на предмет наличия ключевых слов-триггеров (например, «мой рейс») или сущностей, которые могут быть связаны с личными данными пользователя.

RANKING – Ранжирование
Система генерирует стандартный набор веб-результатов. Эти результаты затем используются для анализа в Triggering Rules.

METASEARCH – Метапоиск и Смешивание
Основной этап применения патента. Система выполняет следующие действия:

1. Применение Triggering Rules: Анализируются запрос, результаты этапа RANKING и сигналы от других систем (например, Knowledge Panel), чтобы решить, активировать ли показ личных данных.
2. Запрос к Data Record System: Если правила сработали, система запрашивает релевантные User-Specific Data Records.
3. Определение Display Prominence: Система анализирует временные метки в полученных записях и вычисляет значимость (высокая или низкая) на основе срочности.
4. Смешивание (Blending): Личные записи интегрируются в SERP. Записи с высокой значимостью помещаются в Search Results Pane (основная колонка), а с низкой — в Auxiliary Pane (боковая колонка).

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

• Поисковый запрос и Идентификатор пользователя.
• Стандартные результаты поиска (и связанные с ними категории/локации).
• Сигналы о срабатывании других элементов выдачи (например, Knowledge Panel).
• User-Specific Data Records.
• Текущее время.

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

• Смешанная страница результатов поиска (SERP), включающая стандартные результаты и блоки с личными данными, позиционированные в соответствии с их Display Prominence.

На что влияет

• Специфические запросы: Наибольшее влияние на брендовые запросы (названия авиакомпаний, отелей, магазинов), а также на общие запросы, связанные с действиями («мои рейсы», «отследить посылку»). Также влияет на запросы с неявным интентом, связанным с предстоящими событиями.
• Конкретные ниши или тематики: Travel (авиабилеты, отели), E-commerce (статусы заказов), Entertainment (билеты на мероприятия).
• Пользовательские факторы: Применяется только к авторизованным пользователям, давшим согласие на использование их данных.

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

Алгоритм применяется при выполнении двух условий:

1. Авторизация пользователя: Пользователь должен быть авторизован в системе.
2. Срабатывание Triggering Rules: Должно быть выполнено хотя бы одно из условий активации. Патент описывает несколько вариантов правил:
   • Явные триггеры: Запрос содержит ключевые слова (например, «мой рейс») или точно соответствует данным в записи (например, номер рейса).
   • Триггеры на основе Knowledge Panel: Если отображается Knowledge Panel и информация в ней коррелирует с личными данными.
   • Триггеры на основе результатов поиска: Если стандартные результаты поиска коррелируют с личными данными (например, сайт авиакомпании или результаты поиска рядом с местом назначения пользователя, используя Location Score).
   • Триггеры на основе персональных результатов: Если в выдаче появляется электронное письмо, которое также является источником структурированной записи.

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

1. Получение запроса: Система получает поисковый запрос от авторизованного пользователя.
2. Получение стандартных результатов: Генерируется стандартный набор поисковых результатов.
3. Обработка триггерных правил: Система обрабатывает одно или несколько Triggering Rules, используя запрос и/или стандартные результаты в качестве входных данных.
4. Принятие решения о показе: Определяется, следует ли отображать User-Specific Data Records.
   • Если НЕТ: Генерируется стандартная SERP без личных данных. Процесс завершается.
   • Если ДА: Система идентифицирует и извлекает релевантные личные записи.
5. Определение значимости отображения (Display Prominence): Для каждой релевантной записи выполняется:
   • Извлечение времени события (например, время вылета).
   • Вычисление разницы во времени между текущим моментом и временем события.
   • Сравнение разницы с пороговым значением (Threshold Time).
   • Присвоение уровня значимости (Высокий, если разница меньше порога; Низкий, если больше).
6. Генерация SERP с личными данными: Система генерирует финальную страницу выдачи. Записи с высокой значимостью размещаются в Search Results Pane. Записи с низкой значимостью размещаются в Auxiliary Pane.
7. Предоставление результатов: Финальная SERP отображается пользователю.

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

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

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

• Пользовательские факторы: Идентификатор пользователя и его согласие на использование личных данных.
• Контентные факторы (Приватные): Содержимое Electronic Documents (письма, календарь). Из них извлекаются структурированные User-Specific Data Records: категории, даты, время, идентификаторы (номера рейсов), локации (коды аэропортов).
• Временные факторы: Даты и время событий из записей; текущее время подачи запроса.
• Географические факторы: Локации из личных записей (например, пункт назначения). Они могут сравниваться с локациями, связанными с общими результатами поиска, для активации триггеров (используя Location Score).
• Системные данные: Стандартные результаты поиска и сигналы от системы Knowledge Panel.

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

• Display Prominence (Значимость отображения): Дискретная метрика (например, Высокая/Низкая). Рассчитывается путем сравнения разницы во времени до события с порогом.

  Если (Время События - Текущее Время) < Threshold Time, то Значимость = Высокая; иначе Значимость = Низкая.

• Threshold Time (Пороговое время): Предопределенное значение (например, 24 часа), используемое для определения срочности.
• Location Score (Оценка локации): Используется в одном из вариантов Triggering Rules. Оценивает близость между локациями из стандартных результатов поиска и локациями из личных записей. Чем ближе расстояние, тем выше оценка. Патент упоминает пороги (например, <10 миль для максимума, >100 миль для минимума).

1. Интеграция личных данных в общий поиск: Патент описывает конкретные механизмы, с помощью которых Google интегрирует структурированные данные из личных источников (Gmail, Календарь) в стандартную поисковую выдачу, превращая поиск в персонального ассистента.
2. Срочность определяет позицию: Ключевым механизмом является Display Prominence, основанная на времени. Срочные события получают приоритетное размещение в основной колонке выдачи (Search Results Pane), в то время как менее срочные смещаются в боковую панель (Auxiliary Pane).
3. Сложные триггеры активации: Система использует сложные Triggering Rules, которые анализируют контекст запроса, стандартные результаты поиска (включая их географию через Location Score) и наличие Knowledge Panel, чтобы определить уместность показа личных данных при общих запросах.
4. Влияние на структуру SERP и CTR: Для SEO это означает, что по многим брендовым и категорийным запросам органические результаты могут быть значительно смещены вниз блоками персональных данных с высокой значимостью. Это радикально меняет распределение внимания и CTR в выдаче.
5. Критичность структурированных данных в коммуникациях: Для того чтобы информация корректно извлекалась и отображалась в этих блоках, критически важно, чтобы транзакционные письма (подтверждения бронирований, заказов) содержали корректную структурированную разметку (Schema.org).

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

• Внедрение Schema.org в Email-коммуникации: Это ключевая рекомендация. Для компаний в сферах Travel, E-commerce и Events критически важно размечать транзакционные электронные письма с помощью Schema.org (например, FlightReservation, HotelReservation, ParcelDelivery). Это гарантирует, что Google сможет корректно извлечь данные и сформировать User-Specific Data Records.
• Интеграция действий (Actions): При использовании микроразметки добавляйте потенциальные действия (например, «Check-in», «Track Package»). Как показано в патенте, эти действия могут отображаться в блоке при высокой Display Prominence, повышая его ценность.
• Анализ CTR с учетом персонализации: При анализе эффективности органического поиска, особенно по брендовым запросам, необходимо учитывать наличие этих персональных блоков. Они могут значительно снижать CTR органических результатов, так как предоставляют пользователю прямой ответ.
• Мониторинг выдачи по брендовым запросам: Регулярно проверять (в авторизованном режиме после совершения тестовых бронирований), как отображаются персональные блоки по запросам, связанным с вашим брендом, и корректны ли данные.

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

• Игнорирование влияния на органический трафик: Ошибочно предполагать, что позиция №1 по брендовому запросу гарантирует клик. Если система активирует блок с высокой Display Prominence, он перехватит значительную часть внимания.
• Использование нестандартных форматов подтверждений: Отправка подтверждений бронирования в виде изображений или PDF без текстового слоя и без использования микроразметки в HTML-письме затрудняет Google извлечение данных и снижает вероятность показа персонального блока.
• Игнорирование стандартов микроразметки Email: Отсутствие Schema.org разметки в транзакционных письмах снижает вероятность корректного отображения информации о компании в этом персонализированном блоке.

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

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

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

Сценарий: Оптимизация отображения авиабилетов в поиске (Демонстрация динамической значимости)

Задача: Авиакомпания хочет, чтобы ее клиенты видели детали своего рейса в поиске.

1. Действие: SEO-специалист и команда разработки внедряют разметку FlightReservation в HTML-шаблон электронного письма.
2. Результат (для пользователя): Клиент покупает билет. Google парсит письмо в Gmail и создает User-Specific Data Record.
3. Активация в поиске (за 5 дней до вылета): Пользователь ищет название авиакомпании. Triggering Rule срабатывает. Система определяет, что время до вылета > 24 часов (Threshold Time). Display Prominence = Низкая. Блок отображается в боковой панели (Auxiliary Pane).
4. Активация в поиске (за 20 часов до вылета): Пользователь снова ищет название авиакомпании. Система определяет, что время до вылета < 24 часов. Display Prominence = Высокая. Блок отображается в основной колонке (Search Results Pane) выше органических результатов, возможно, с активной кнопкой «Check-in».