Как Google позволяет внешним экспертам настраивать поисковую выдачу и таргетировать рекламу с помощью контекстных файлов

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

Context File (Файл Контекста)

Набор инструкций, предоставляемый внешним источником (например, вертикальным сайтом), который программирует работу поисковой системы. Включает правила для препроцессинга, управления поиском и постпроцессинга.

Context Processor (Процессор Контекста)

Компонент системы, который интерпретирует и выполняет инструкции из Context File. Может располагаться на стороне PSE, вертикального сайта или клиента.

Programmable Search Engine (PSE) (Программируемая поисковая система)

Поисковая система, операционная модель которой может быть изменена внешними объектами с помощью Context Files (например, Google CSE).

Vertical Content Site (Вертикальный контент-сайт)

Тематический сайт, созданный экспертами в определенной области. Предоставляет Context Files для PSE.

Site/Page Annotation File (Файл аннотаций сайта/страницы)

Тип Context File, содержащий метаданные о сайтах/страницах в Интернете. Включает URL, дескрипторы (метки/теги), ранги (оценки качества) и комментарии, предоставленные вертикальным сайтом.

Knowledge Base File (Файл базы знаний)

Тип Context File, описывающий знания о концепциях, фактах и объектах в виде графа классов и экземпляров (например, определение моделей камер и их свойств). Используется для понимания сущностей в запросе.

Search Engine Control Data (Данные управления поисковым движком)

Инструкции в Context File, определяющие, какие коллекции документов (Corpus) искать и какие параметры ранжирования (SearchControlParams) применять.

Ad Selector (Селектор рекламы)

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

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

Анализ основан на Claims опубликованной заявки US20160299983A1, которая является продолжением (continuation) более ранних заявок.

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

1. Сервер (front end server) получает запрос через интерфейс на стороннем веб-сайте (host website) и информацию о связанном Context File.
2. Context Processor получает Context File. Этот файл содержит инструкции по модификации обработки запроса на основе контекста и определяет коллекцию документов (document collection) для поиска.
3. Поисковая система ищет документы в указанной коллекции, используя запрос и инструкции.
4. Поисковая система фильтрует документы указанного типа из найденных результатов на основе инструкций из Context File.
5. Селектор (selector) выбирает дополнительный контент (рекламу) на основе КАК запроса, ТАК И Context File.
6. Модуль отображения (display module) интегрирует рекламу и отфильтрованные результаты на одной странице и отправляет ее клиенту.

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

Ядро изобретения — это использование внешнего Context File для двойной цели: 1) кастомизации поиска (ограничение коллекции, фильтрация результатов) и 2) выбора релевантной рекламы на основе этого же контекста.

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

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

INDEXING – Индексирование и извлечение признаков
Система собирает и индексирует Context Files от вертикальных сайтов через интерфейс регистрации (Context Registration Interface) или краулер (Context File Crawler). Файлы кэшируются (Cached Context Files). Агрегация этих файлов может использоваться для создания глобальных контекстов (Global Context Files).

QUNDERSTANDING – Понимание Запросов
Этап препроцессинга. Context Processor использует Context File для анализа интента и реформулирования запроса (Query revision). Это может включать добавление или замену терминов на основе правил и данных из Knowledge Base File.

RANKING – Ранжирование
Этап управления поисковым движком. Context File определяет:

• Выбор коллекции (Corpus): Ограничение поиска определенным набором документов.
• Настройка параметров: Изменение весов атрибутов ранжирования через SearchControlParams.

RERANKING / METASEARCH – Переранжирование и Смешивание
Этап постпроцессинга и интеграции рекламы.

• Фильтрация и Ранжирование: Результаты фильтруются (Restriction) или переупорядочиваются на основе меток и оценок из Site/Page Annotation File.
• Аннотирование и Навигация: Добавление комментариев и ссылок на связанные контексты (Related Contexts).
• Выбор Рекламы: Ad Selector выбирает рекламу на основе запроса и контекста, учитывая ставки рекламодателей (Bids).

На что влияет

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

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

• Триггеры активации: Алгоритм активируется, когда запрос связан с Context File. Это происходит, если:
  • Запрос введен через интерфейс на вертикальном сайте (например, Google CSE).
  • Пользователь подписан на контекст провайдера для использования в общем поиске.
  • Поисковая система автоматически определяет релевантный вертикальный контекст для запроса.
• Условия работы: Конкретные операции (например, модификация запроса) выполняются, если в Context File присутствуют соответствующие инструкции и выполнены их условия (например, запрос соответствует объекту в Knowledge Base).

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

Процесс обработки запроса с контекстом

1. Получение Запроса и Ставок: Система получает ставки от рекламодателей на комбинации «Ключевое слово + Контекст». Параллельно от клиента поступает запрос (часто через вертикальный сайт) и связанный Context ID.
2. Получение Context File: Context Processor извлекает соответствующий Context File.
3. Препроцессинг Запроса: Context Processor применяет правила из Context File (например, Query Modification) для создания переформулированного запроса и извлекает данные управления поиском (например, выбор коллекции документов).
4. Выполнение Поиска: Поисковая система выполняет переформулированный запрос в указанных коллекциях с использованием заданных параметров.
5. Постпроцессинг Результатов: Context Processor обрабатывает результаты: фильтрует (Restriction), ранжирует, добавляет аннотации и ссылки на связанные контексты (Related Contexts), используя данные из Site/Page Annotation File.
6. Выбор Рекламы: Ad Selector получает запрос и Context ID. Он выбирает рекламу, сравнивая ставки (Bids), соответствующие этой комбинации «Запрос + Контекст».
7. Интеграция и Отображение: Ad Display Module интегрирует обработанные результаты поиска и выбранную рекламу на финальной странице и отправляет ее пользователю.

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

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

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

• Структурированные данные (Context Files):
  • Site/Page Annotation File: Содержит URL, дескрипторы/метки (Descriptors, Tags), ранги/оценки качества (Rank) и комментарии (Comment).
  • Knowledge Base File: Данные об объектах, классах и их свойствах.
  • Инструкции и правила: Правила модификации запросов, параметры управления поиском (SearchControlParams), правила фильтрации.
• Пользовательские факторы: Свойства пользователя (user.property, user.InstanceOf), ID, IP-адрес, тип устройства. Используются для выбора контекстного файла или применения правил.
• Поведенческие факторы: Упоминается возможность использования истории активности пользователя на сайте (клики, время пребывания) для определения контекста или типа пользователя.
• Рекламные данные: База данных ставок (Bids Database) на комбинации ключевых слов и контекстов.

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

• Rank (Ранг/Оценка в Аннотациях): Субъективная оценка качества или полезности страницы/сайта, присвоенная владельцем вертикального сайта. Используется для фильтрации и переранжирования результатов в данном контексте.
• Веса атрибутов ранжирования (Weights): Context File может изменять веса стандартных атрибутов ранжирования поискового движка (например, вес PageRank, частота термина в тексте) через SearchControlParams.
• Bid Amount (Размер ставки): Денежная стоимость, которую рекламодатель готов заплатить за показ/клик по рекламе в определенном контексте. Используется для выбора и ранжирования рекламы.
• Оценка свойств (Evaluation): Механизм проверки соответствия запроса, пользователя или результата условиям, определенным в Knowledge Base или Annotation File (например, query.denot.InstanceOf).

1. Контекст как ключ к пониманию интента: Патент демонстрирует фундаментальный подход, где контекст пользователя (интент, уровень знаний, ситуация), определенный через Context Files, является ключевым фактором для определения релевантности, превосходящим по важности сами ключевые слова.
2. Делегирование экспертизы (Wisdom of Crowds): Google предоставляет механизм для интеграции знаний нишевых экспертов (владельцев вертикальных сайтов). Система позволяет им программно управлять поиском: переписывать запросы, выбирать источники и фильтровать выдачу.
3. Агрегация внешних сигналов качества: Поисковая система может агрегировать аннотации и оценки (Rank) от множества вертикальных сайтов. Это формирует коллективную экспертную оценку качества и категоризацию контента, которая может использоваться глобально (Global Context Files).
4. Структурированные данные как язык управления поиском: Knowledge Base Files и Annotation Files являются формами структурированных данных, которые используются для прямого влияния на интерпретацию запросов и результатов.
5. Монетизация интента (Context-Based Advertising): Патент явно описывает использование контекста для таргетинга рекламы. Это позволяет Google монетизировать не просто ключевые слова, а конкретные намерения пользователей (например, контекст покупки ценится выше контекста поддержки), используя механизм ставок на «Ключевое слово + Контекст».

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

• Фокус на удовлетворении конкретных интентов (Контекстов): Разрабатывайте контент, четко ориентированный на конкретные сценарии использования (покупка, сравнение, поддержка, обучение). Структура сайта должна отражать эти контексты, помогая пользователям и системам понять текущий интент.
• Использование структурированных данных (Schema.org): Хотя патент использует свои форматы (Knowledge Base File), в современной практике это реализуется через Schema.org. Максимально подробно размечайте сущности и их свойства, чтобы предоставить поисковой системе аналог Knowledge Base о вашем контенте.
• Построение авторитета в вертикали (Topical Authority и E-E-A-T): Становитесь тем самым «вертикальным контент-сайтом», чья экспертиза ценится. Патент предполагает, что Google может использовать агрегированные данные от экспертов (аналог Annotations) для оценки контента. Чем выше ваш авторитет, тем сильнее ваши сигналы.
• Создание контента для разных сегментов аудитории: Учитывайте разные типы пользователей (например, новички vs. профессионалы). Создавайте контент, удовлетворяющий их специфические потребности, и используйте сигналы, которые помогут системе классифицировать этот контент (например, использование профессиональной терминологии vs. базовых объяснений).

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

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

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

Патент подтверждает стратегический сдвиг Google в сторону контекстуальной и персонализированной выдачи. Он заложил основу не только для Custom Search, но и для механизмов контекстной рекламы, основанных на интенте. Для долгосрочной SEO-стратегии это означает переход от оптимизации страниц к управлению сущностями и контекстами. Понимание того, как Google категоризирует контент и интерпретирует интент пользователя с помощью структурированных данных и внешних сигналов (E-E-A-T), является ключевым.

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

Сценарий: Оптимизация сайта по фототехнике под разные контексты (Имитация работы PSE)

1. Анализ интентов: Определяем ключевые контексты для запроса "Nikon D100": (A) Покупка (сравнение, цены), (B) Владение (поддержка, аксессуары).
2. Создание контента (Аналог Annotation File): Создаем отдельные кластеры контента. Кластер А: Обзоры экспертов, руководства по покупке. Кластер B: FAQ по настройке, инструкции.
3. Структурирование данных (Аналог Knowledge Base): Используем Schema.org. Размечаем страницу продукта как Product. Размечаем обзоры как Review, статьи поддержки как FAQPage.
4. Внутренняя перелинковка (Аналог relContext): На главной странице продукта размещаем четкие навигационные ссылки, ведущие в разные контекстные кластеры: "Сравнить цены", "Читать обзоры", "Поддержка".
5. Ожидаемый результат: Поисковая система лучше понимает назначение каждой страницы. Пользователи в контексте "Покупка" с большей вероятностью увидят обзоры, а в контексте "Владение" — страницы поддержки, даже если их исходный запрос был общим.