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

    Как Google анализирует видимый контент на экране пользователя для предоставления контекстной информации без ввода запроса (Contextual Search)

    CONTEXTUAL INFORMATION FOR A DISPLAYED RESOURCE (Контекстная информация для отображаемого ресурса)
    • US11003667B1
    • Google LLC
    • 2021-05-11
    • 2016-05-27
    2016 Патенты Google Персонализация Семантика и интент

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

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

    Описание

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

    Патент решает проблему «трения» и временных затрат при поиске информации о контенте, который пользователь просматривает в данный момент. Традиционный подход требует от пользователя переключения контекста и ручного ввода запроса. Изобретение направлено на предоставление мгновенной контекстной информации и действий без необходимости ввода явных поисковых терминов (query parameters). В патенте также отмечается, что это повышает эффективность поисковой системы за счет снижения количества ошибочных или неточных запросов.

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

    Запатентована система предоставления контекстной информации, активируемая посредством Query-Independent Request (запроса, не зависящего от ввода ключевых слов), например, жеста или долгого нажатия. Система анализирует Active Resource (активный ресурс), отображаемый на переднем плане устройства, идентифицирует Search Items (сущности) строго в видимой области экрана и определяет их релевантность. Ключевая инновация — адаптивный расчет Relevance Score, который учитывает визуальное представление контента и тип ресурса (например, веб-страница vs. чат).

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

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

    • Триггер: Пользователь инициирует Query-Independent Request (например, долгое нажатие).
    • Сбор данных: Система захватывает представление текущего видимого экрана. Это может быть структурированное представление (Document Object Model — DOM) или снимок экрана (требующий OCR).
    • Идентификация сущностей: Система извлекает текст и идентифицирует Search Items, сверяясь с Item Knowledge Graph.
    • Оценка релевантности: Рассчитывается Relevance Score. Оценка динамически зависит от типа ресурса (например, в чате текст снизу важнее) и визуального представления (размер, цвет, позиция).
    • Выбор и предоставление: Выбираются сущности с наивысшими оценками. Для них генерируются Contextual Cards с информацией и действиями (например, позвонить, проложить маршрут).

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

    Высокая. Описанная технология легла в основу функций, известных как Google Now on Tap, и интегрирована в современные механизмы Google Assistant (анализ контекста экрана), Google Lens и такие функции, как «Circle to Search». Понимание контента без явного запроса остается ключевым направлением развития поиска.

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

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

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

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

    Active Resource (Активный ресурс)
    Контент, который в данный момент отображается на устройстве пользователя в приложении, работающем на переднем плане (foreground). Примеры: веб-страница, чат, интерфейс приложения.
    Contextual Card / Contextual User Interface Element (Контекстная карточка / Контекстный элемент пользовательского интерфейса)
    Элемент интерфейса (например, всплывающая карточка), который содержит контекстную информацию о выбранном Search Item и предлагает связанные действия (например, позвонить, навигация, открыть приложение).
    Document Object Model (DOM) (Объектная модель документа)
    Структурированное представление активного ресурса. Используется системой для извлечения текста и понимания его визуального оформления (размер, цвет, позиция, шрифт) и структуры.
    Item Identification Engine (Механизм идентификации элементов)
    Компонент сервера, который извлекает текст из представления ресурса (через OCR или парсинг DOM) и идентифицирует Search Items.
    Item Knowledge Graph (Граф знаний элементов)
    База знаний (аналог Google Knowledge Graph), используемая для идентификации сущностей (Search Items) и хранения информации о них.
    Query-Independent Request (Запрос, не зависящий от ввода ключевых слов)
    Запрос контекстной информации, инициированный пользователем без ввода текстовых или голосовых поисковых терминов (query parameters).
    Relevance Score (Оценка релевантности)
    Метрика, отражающая уверенность системы в том, что пользователь хотел бы видеть контекстную информацию именно об этой сущности. Рассчитывается на основе визуального представления и типа ресурса.
    Search Item (Поисковый элемент / Сущность)
    Концепция или объект (например, именованная сущность, узел в графе знаний), идентифицированный в контенте активного ресурса.

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

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

    1. Система получает Query-Independent Request для Active Resource, отображаемого в приложении на переднем плане.
    2. Идентификация Search Items. Ключевое ограничение: анализ проводится путем выбора только той части контента, которая в данный момент отображается на дисплее (first portion).
    3. Определение типа активного ресурса (например, текстовый чат или веб-страница).
    4. Определение Relevance Score для каждого элемента на основе (i) определенного типа ресурса и (ii) местоположения (location) текста на дисплее.
    5. Критическая инновация: Оценки релевантности для текста в определенных местах выше, чем в других, и эти приоритетные места различаются в зависимости от типа ресурса.
    6. Выбор элементов на основе оценок и предоставление Contextual User Interface Elements.

    Claim 2, 3 и 4 (Зависимые): Детализируют методы извлечения контента.

    • (Claim 2): Извлечение текста путем получения скриншота и применения обработки изображений (например, OCR).
    • (Claim 3 и 4): Извлечение текста путем получения представления данных (например, DOM) и его парсинга.

    Claim 5 и 6 (Зависимые): Детализируют расчет Relevance Score.

    • Оценка релевантности основывается на внешнем виде (appearance) контента (Claim 5), в частности, на размере, цвете или позиции текста (Claim 6).

    Claim 18 (Зависимый от 1): Конкретизирует расчет Relevance Score для типа ресурса «текстовый чат» (textual conversation).

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

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

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

    INDEXING – Индексирование и извлечение признаков
    Система полагается на предварительно созданный Item Knowledge Graph. Процессы индексирования, наполняющие Граф Знаний, критически важны для способности системы распознавать сущности и предоставлять информацию о них.

    QUNDERSTANDING – Понимание Запросов (Интерпретация Контекста)
    Основное применение патента. Вместо анализа введенного запроса, система интерпретирует визуальный контекст экрана как имплицитный (неявный) запрос. Это включает парсинг DOM или анализ скриншота для понимания визуальной структуры, а также извлечение сущностей с помощью Item Identification Engine.

    RANKING – Ранжирование (Сущностей)
    Система ранжирует идентифицированные Search Items. Relevance Scoring Engine вычисляет Relevance Score, используя сигналы визуальной значимости (размер, цвет) и расположения, причем логика ранжирования адаптируется под тип ресурса.

    METASEARCH – Метапоиск и Смешивание
    Contextual Card Provider генерирует финальный результат — Contextual Cards. Он агрегирует информацию из Item Knowledge Graph и определяет доступные действия (Apps, Navigation, Call).

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

    • Query-Independent Request.
    • Данные об активном ресурсе: Скриншот ИЛИ представление данных (DOM) видимой части экрана.
    • Дополнительная информация: Тип ресурса, местоположение устройства, URL (если доступен), идентификатор пользователя (для персонализации).

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

    • Один или несколько Contextual User Interface Elements (карточек).

    На что влияет

    • Конкретные типы контента: Влияет на любой контент, отображаемый на устройстве: веб-страницы, электронные письма, текстовые чаты (textual conversations), интерфейсы приложений.
    • Визуальный дизайн и верстка (UX): Патент прямо указывает, что визуальное представление (размер, цвет, форматирование) и расположение контента (позиция на экране) используются для определения важности сущностей.
    • Структура DOM: Чистота и семантика DOM влияют на способность системы точно извлекать текст и его визуальные атрибуты.
    • Сущности (Entities): Система ориентирована на контент, содержащий распознаваемые сущности, присутствующие в Item Knowledge Graph.

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

    • Триггеры активации: Алгоритм активируется только по явному действию пользователя (например, долгое нажатие кнопки, определенный жест, обведение элемента на экране).
    • Условия применения: Применяется только к контенту, который в данный момент виден на экране (foreground application) и только к видимой его части (Claim 1).

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

    Этап 1: Запрос и сбор данных

    1. Обнаружение намерения: Клиентский модуль на устройстве обнаруживает триггер.
    2. Сбор контекста: Модуль собирает информацию о видимой части Active Resource (генерация скриншота или запрос DOM).
    3. Отправка запроса: Модуль отправляет Query-Independent Request на сервер, включая собранные данные (скриншот/DOM) и метаданные.

    Этап 2: Идентификация и анализ

    1. Извлечение текста и структуры: Item Identification Engine извлекает текст и данные о его внешнем виде. Если это скриншот — используется OCR. Если DOM — парсинг модели.
    2. Определение типа ресурса: Система определяет тип Active Resource (например, веб-страница, чат).
    3. Идентификация сущностей: Извлеченный текст сопоставляется с Item Knowledge Graph для идентификации Search Items (сущностей). Рассчитываются Match Scores.

    Этап 3: Ранжирование и выбор

    1. Расчет релевантности: Relevance Scoring Engine рассчитывает Relevance Score для каждой сущности. Расчет динамически учитывает:
      • Тип ресурса (например, для чатов текст снизу важнее – Claim 18).
      • Визуальное представление (больший размер, цвет, центрирование повышают оценку – Claim 6).
      • Расположение (текст в меню или рекламе может понижаться, как указано в описании патента).
    2. Выбор сущностей: Item Selection Engine выбирает сущности, превышающие порог релевантности (Relevance Threshold) или Топ-N сущностей.

    Этап 4: Генерация и предоставление ответа

    1. Генерация карточек: Contextual Card Provider запрашивает информацию и доступные действия из Item Knowledge Graph и генерирует Contextual Cards.
    2. Предоставление ответа: Карточки отправляются на устройство пользователя и отображаются поверх активного ресурса.

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

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

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

    • Контентные факторы: Текст, извлеченный из Active Resource (через DOM или OCR).
    • Технические факторы (Представление ресурса): DOM (предпочтительно) или Скриншот. URL ресурса.
    • Структурные и Визуальные факторы (Ключевые): Данные, используемые для расчета Relevance Score:
      • Тип ресурса (например, textual conversation, веб-страница).
      • Позиция текста на экране (координаты).
      • Внешний вид (Appearance): Размер шрифта, цвет, форматирование (жирность), выравнивание.
      • Структурное расположение (из DOM): Положение в иерархии документа (например, основной контент vs. меню/реклама).
    • Географические факторы: Местоположение устройства может использоваться для уточнения локальных сущностей.
    • Пользовательские факторы: Идентификатор пользователя может использоваться для персонализации (например, фокус на элементах, с которыми пользователь недавно взаимодействовал, как указано в описании).

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

    • Match Score (Оценка соответствия): (Упоминается в описании). Оценка уверенности в идентификации сущности при сопоставлении текста с Item Knowledge Graph.
    • Relevance Score (Оценка релевантности): Основная метрика для ранжирования сущностей на экране. Отражает важность Search Item в текущем контексте. Рассчитывается как функция от визуальных и структурных факторов: RelevanceScore=f(Position,Size,Color,ResourceType)RelevanceScore = f(Position, Size, Color, ResourceType)
      • Динамическая нормализация по типу ресурса: Правила меняются динамически. Например: Если тип = «Чат», повышать оценку для текста ближе к низу экрана (Claim 18). Если тип = «Веб-страница», приоритет может быть у текста вверху или в центре.
      • Влияние визуальных факторов: Текст, который визуально выделяется, получает повышение оценки (Claim 6).
      • Пессимизация: Текст в областях, идентифицированных как неважные (меню, реклама), может получать понижение оценки (указано в описании).
    • Relevance Threshold (Порог релевантности): Пороговое значение Relevance Score, которое элемент должен превысить для отображения (Claim 7).

    Выводы

    1. Визуальная иерархия интерпретируется как семантическая важность: Патент подтверждает, что Google использует визуальное представление контента (размер, цвет, позицию) как прямой сигнал для определения важности сущностей на странице в режиме контекстного поиска. Визуально доминирующий контент считается более релевантным.
    2. Интерпретация сигналов зависит от контекста (Типа Ресурса): Система динамически меняет правила оценки важности. Патент явно указывает (Claim 18), что в чатах приоритет отдается контенту внизу (последние сообщения), тогда как на веб-страницах логика иная.
    3. Анализ строго ограничен видимой областью (Viewport): Система анализирует только то, что пользователь видит на экране в момент активации функции (Claim 1). Контент за пределами видимой области игнорируется в этом процессе.
    4. Анализ Рендеринга (DOM или OCR): Google может анализировать контент как путем парсинга структуры документа (DOM), что предпочтительно для точности, так и путем визуального анализа (Screenshot + OCR), что обеспечивает универсальность.
    5. Критическая зависимость от Графа Знаний: Весь процесс построен вокруг идентификации Search Items и их сопоставления с Item Knowledge Graph для предоставления информации и действий.

    Практика

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

    Хотя патент не влияет на органическое ранжирование напрямую, он дает критическое понимание того, как Google интерпретирует визуальное представление и структуру контента.

    • Соблюдение четкой визуальной иерархии (UX/Design): Используйте дизайн для выделения ключевых сущностей (название продукта, бренда, локации). То, что выглядит важным для пользователя (размер, контраст, расположение), будет считаться важным и для системы при расчете Relevance Score (Claim 6).
    • Оптимизация видимой области (Viewport Optimization): Размещайте ключевые сущности в основном контенте, предпочтительно в видимой области экрана. Поскольку анализ ограничен видимым контентом (Claim 1), важно, чтобы основная тема была очевидна без прокрутки.
    • Обеспечение чистого DOM и семантической верстки (Technical SEO): Обеспечьте логичную структуру DOM. Это облегчает системе извлечение контента и точное определение визуальных характеристик элементов, если она использует парсинг DOM (Claim 3), а не OCR.
    • Оптимизация под Граф Знаний (Entity SEO): Убедитесь, что ваши ключевые сущности точно представлены в Графе Знаний и имеют связанные действия (телефон, адрес). Система использует Item Knowledge Graph для генерации карточек.
    • Использование текста вместо изображений (Entity Clarity): Предоставляйте важную информацию в виде текста. Хотя система может использовать OCR (Claim 2), парсинг DOM более надежен.

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

    • Запутанная визуальная иерархия и перегруженный дизайн: Использование макетов, где второстепенная информация (реклама, навигация) визуально доминирует над основным контентом. Это может привести к неправильному расчету Relevance Score и выбору неверных сущностей.
    • Размещение ключевой информации только в «неважных» зонах: Размещение важных сущностей только в футере или боковых меню. Система может пессимизировать такие зоны (согласно описанию патента).
    • Использование изображений для критически важного текста: Зависимость от OCR менее надежна и может привести к ошибкам в идентификации Search Items.

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

    Патент подтверждает стратегию Google по переходу к контекстному и мультимодальному поиску. Для SEO это означает, что визуальный дизайн и пользовательский опыт (UX) становятся факторами, влияющими на интерпретацию контента поисковой системой в режимах типа Google Assistant или Google Lens. Успех требует фокуса на сущностях и создании контента, который четко структурирован как семантически, так и визуально.

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

    Сценарий: Оптимизация страницы локального бизнеса

    Цель: Убедиться, что при использовании функции контекстного поиска на странице контактов система корректно идентифицирует бизнес и предлагает действия «Позвонить» и «Проложить маршрут».

    1. Обеспечение данных для Графа Знаний: Убедиться, что бизнес присутствует в Google Business Profile с корректным адресом и телефоном (данные для Item Knowledge Graph).
    2. Визуальное представление на сайте:
      • Разместить название бизнеса, адрес (NAP) в верхней части страницы (приоритетная позиция для веб-страницы).
      • Использовать крупный шрифт и контрастный цвет для NAP (влияет на Relevance Score согласно Claim 6).
      • Предоставить данные в текстовом формате (не картинкой) для надежного парсинга DOM (Claim 3).
    3. Ожидаемый результат: Пользователь активирует функцию. Система анализирует DOM. Благодаря визуальному выделению и расположению, NAP получает высокий Relevance Score. Система идентифицирует сущность бизнеса и генерирует Contextual Card с кнопками «Call» и «Navigate».

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

    Описывает ли этот патент алгоритмы ранжирования в обычном поиске Google?

    Нет, этот патент не описывает ранжирование веб-страниц в SERP. Он описывает систему контекстного поиска (технологии типа Google Assistant Screen Context или Circle to Search), которая анализирует контент, отображаемый на экране устройства, и ранжирует идентифицированные там сущности на основе их визуального представления.

    Как система определяет, что на экране является важным?

    Система рассчитывает Relevance Score для каждой найденной сущности. Эта оценка основывается на визуальных характеристиках текста (размер, цвет, позиция на экране — Claim 6). Визуально выделяющийся контент считается более важным. Также критически важен тип контента, который определяет правила интерпретации позиции.

    Анализирует ли система весь документ или только видимую часть?

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

    Как система определяет, что важнее: то, что вверху экрана, или то, что внизу?

    Это зависит от типа активного ресурса (ResourceType). Патент явно указывает (Claim 18), что если ресурс является текстовым чатом (textual conversation), то контент ближе к низу экрана (более свежий) получает более высокий Relevance Score. Для веб-страниц логика может быть обратной (приоритет вверху или в центре).

    Как система получает доступ к контенту на экране: через OCR или анализ кода (DOM)?

    Патент описывает оба варианта. Система может получить структурированное представление ресурса, такое как Document Object Model (DOM), и распарсить его (Claim 3). Альтернативно, она может получить снимок экрана и использовать методы обработки изображений (включая OCR) для извлечения текста (Claim 2).

    Какова роль Knowledge Graph в этом патенте?

    Item Knowledge Graph играет ключевую роль. Система использует его для сопоставления текста, извлеченного с экрана, с конкретными сущностями (Search Items). Если сущность не может быть идентифицирована в графе знаний, контекстная информация по ней не будет предоставлена.

    Как повлиять на то, какие сущности система выберет на моей странице?

    Используйте дизайн для управления вниманием. Сделайте основную сущность страницы (например, название продукта) наиболее визуально заметной – используйте крупный шрифт, контрастный цвет и размещайте ее на видном месте. Это увеличит ее Relevance Score.

    Может ли этот механизм ошибочно принять рекламу или меню за основной контент?

    Патент учитывает эту возможность. В описании упоминается, что Relevance Scoring Engine может определять, что текст появляется в рекламном блоке или навигационном меню, и в этом случае Relevance Score для извлеченных из него сущностей будет понижен.

    Что такое «Query-Independent Request»?

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

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

    SEO-специалистам следует тесно сотрудничать с дизайнерами и UX-специалистами. Дизайн сайта должен не только быть удобен для пользователей, но и подчеркивать визуальную важность ключевых сущностей. Это обеспечивает корректную интерпретацию контента системами контекстного поиска.

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

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