Как Google позволяет использовать приватные структурированные данные для управления ранжированием в кастомном поиске

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

Access-restricted data key (Ключ доступа к данным в запросе)

Ключ (например, API key), предоставляемый вместе с поисковым запросом для авторизации доступа к приватным данным. (Query Key).

Access-restricted search related structured data (Структурированные данные с ограниченным доступом / Приватные данные)

Приватные структурированные данные, связанные с URL, которые хранятся в поисковой базе, но недоступны для публичного сканирования и требуют авторизации для доступа.

Biasing parameter (Параметр изменения веса / Смещение)

Параметр в поисковом запросе, используемый для повышения или понижения (promote/demote) определенных результатов в выдаче, но не исключающий другие результаты.

Database data access key (Ключ доступа к данным в базе)

Ключ, сохраненный в базе данных и связанный с приватными данными. Используется для проверки Access-restricted data key, пришедшего в запросе. (Stored Key).

PageMap

Один из форматов представления структурированных данных, упоминаемый в патенте. Представляет данные как объекты с атрибутами и значениями, часто кодируется как XML-блок.

Private URL access key (Приватный ключ доступа к URL)

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

Restriction parameter (Параметр ограничения / Фильтрация)

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

Search related structured data (Структурированные данные, связанные с поиском)

Данные о документе, организованные в виде объектов и атрибутов (например, Microdata, RDFa, PageMap).

Verified user (Верифицированный пользователь)

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

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

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

1. Система получает поисковый запрос для веб-сайта (search query for a website).
2. Система получает access-restricted data key (Query Key), соответствующий запросу.
3. Происходит сравнение Query Key с database data access key (Stored Key) в базе данных.
4. Если ключи совпадают, доступ к релевантным приватным данным разрешается.
5. Если ключи не совпадают, доступ запрещается.

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

• (Claim 3) Stored Key может быть присоединен (appended) к самим структурированным данным в базе (например, имя атрибута хранится как 1234-title вместо title).
• (Claim 4, 5) Если доступ разрешен, присоединенный ключ удаляется из данных перед их передачей на внешнее устройство (например, возвращается title).

Claim 9 (Зависимый): Ключевое ограничение области применения.

• Приватные структурированные данные недоступны через стандартное сканирование (crawling) веб-сайта.

Claim 10, 11, 12 (Зависимые): Описывают применение полученных данных.

• (Claim 10) Query Key может быть присоединен к restriction parameter (фильтрация) или biasing parameter (изменение веса) в поисковом запросе.
• (Claim 11, 12) Поисковые результаты формируются на основе полученных приватных структурированных данных, которые используются для применения этих параметров.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе происходит загрузка и сохранение приватных данных. Verified user передает Access-restricted search related structured data и Database data access key через защищенный канал. Это может быть:

• Прямая загрузка через API (например, HTTP POST).
• Сканирование приватной версии URL с использованием Private URL access key.

Эти данные сохраняются в Content Database и ассоциируются с URL. Этот процесс происходит вне стандартного цикла CRAWLING публичного контента.

RANKING / RERANKING – Ранжирование и Переранжирование
Основное применение патента. Когда поисковый запрос (обычно от кастомной или внутренней поисковой системы) поступает в систему, он содержит Access-restricted data key. Система аутентификации проверяет ключ. Если он валиден, система извлекает связанные приватные структурированные данные для релевантных документов. Эти данные затем используются для вычисления финальной релевантности, применения фильтров (restriction parameters) или корректировки весов (biasing parameters).

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

• Поисковый запрос (часто сайт-специфичный).
• Access-restricted data key (Query Key).
• Параметры сортировки, фильтрации или изменения веса.

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

• Результаты поиска, отсортированные или отфильтрованные на основе приватных данных.
• Опционально: Сами приватные структурированные данные (например, в формате XML), возвращаемые авторизованному клиенту.

На что влияет

• Конкретные типы контента и Ниши: Патент наиболее актуален для закрытых или полузакрытых экосистем:
  • E-commerce и Маркетплейсы: Использование данных о товарах (маржинальность, остатки, внутренний рейтинг поставщика), которые не должны быть публичными.
  • App Stores (Магазины приложений): Использование внутренних оценок качества приложений или издателей (например, для деприоритизации проблемных издателей – persistently problematic publishers).
  • Корпоративные порталы (Enterprise Search): Использование данных о документах (уровень доступа, внутренняя классификация).

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

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

• Наличие данных: В поисковой базе данных существуют Access-restricted search related structured data для URL, релевантных запросу.
• Наличие ключа в запросе: Поисковый запрос явно содержит Access-restricted data key (либо в URL запроса, либо как часть параметров фильтрации/сортировки).
• Валидация ключа: Ключ в запросе совпадает (точно или алгоритмически) с Database data access key, сохраненным в базе.

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

Процесс А: Обработка поискового запроса в реальном времени

1. Получение запроса: Система получает поисковый запрос, который может включать параметры фильтрации, сортировки или изменения веса.
2. Получение ключа доступа: Система извлекает Access-restricted data key (Query Key) из запроса.
3. Аутентификация: Система сравнивает Query Key с Database data access key (Stored Key) в базе данных.
4. Проверка доступа:
   • Если ключи не совпадают: Доступ к приватным данным запрещен. Поиск выполняется только на основе публичных данных.
   • Если ключи совпадают: Доступ разрешен.
5. Извлечение данных: Система извлекает релевантные Access-restricted search related structured data.
6. Обработка данных (Опционально): Если ключ был интегрирован в имена атрибутов в базе (например, 1234-rating), система удаляет ключ из имени (например, rating).
7. Применение в ранжировании: Система использует извлеченные приватные данные для выполнения запрошенных операций: фильтрации (restriction), изменения веса (biasing) или сортировки.
8. Возврат результатов: Система возвращает финальный набор результатов.

Процесс Б: Загрузка приватных данных (Офлайн или по запросу)

1. Инициация загрузки: Авторизованный пользователь (Verified user) инициирует запрос на ассоциацию приватных данных с URL.
2. Аутентификация пользователя: Система проверяет права пользователя на управление данными для этого URL.
3. Получение данных и ключа: Система получает структурированные данные и Database data access key (Stored Key). (Через API или приватный краулинг).
4. Сохранение: Система сохраняет данные и ключ в Content Database, ассоциируя их с URL. Данные помечаются как недоступные для публичного сканирования.

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

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

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

• Структурные факторы: Основные данные — это структурированные данные, предоставленные владельцем сайта. Упоминаются форматы: PageMap, Meta tags, Microformats, RDFa, Microdata.
• Технические факторы: URL документа, с которым ассоциируются данные.
• Системные данные (Аутентификация):
  • Access-restricted data key (передается в запросе).
  • Database data access key (хранится в базе).
  • Private URL access key (используется для загрузки данных через приватный краулинг).

Примеры приватных данных, упомянутые в патенте (Claim 7 и Description):

• access-restricted ranking (Ранжирование с ограниченным доступом).
• access-restricted rating (Рейтинг).
• access-restricted flag (Флаг, например, для пометки проблемных издателей или поставщиков).
• access-restricted number of downloads (Количество загрузок).
• access-restricted number of views (Количество просмотров).
• Perceived quality (Внутренняя оценка качества документа или его автора).

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

• Методы аутентификации: Сравнение Access-restricted data key и Database data access key. Патент упоминает, что совпадение может быть точным или алгоритмическим (например, один ключ является реверсом другого).
• Параметры запроса: Приватные данные используются для вычисления значений Restriction parameter (жесткая фильтрация) и Biasing parameter (повышение/понижение веса результатов). Конкретные формулы расчета весов не приводятся.

1. Инфраструктура для приватного поиска, а не публичного SEO: Патент описывает инфраструктурный механизм для безопасного хранения и использования приватных данных в поиске. Он не описывает алгоритмы ранжирования публичного веб-поиска Google.
2. Недоступность данных для краулинга: Ключевая особенность системы в том, что Access-restricted search related structured data недоступны при стандартном публичном сканировании сайта (Claim 9). Они загружаются отдельно авторизованными лицами.
3. Строгий контроль доступа: Доступ к данным строго контролируется с помощью механизма ключей (API keys). Только авторизованные системы, знающие ключ, могут использовать эти данные.
4. Применение в кастомных и вертикальных решениях: Механизм предназначен для Google Custom Search Engine (CSE), Enterprise Search или внутренних поисковых систем крупных платформ (например, магазинов приложений, Google Shopping). Он позволяет использовать конфиденциальные бизнес-данные (например, маржинальность, внутренние рейтинги) для управления выдачей.
5. Гибкость индекса Google: Патент подтверждает способность инфраструктуры Google индексировать, хранить и использовать в ранжировании структурированные данные, полученные не только из публичного HTML-кода, но и через API или другие защищенные каналы.

ВАЖНО: Патент является инфраструктурным и имеет минимальное прямое применение для SEO-продвижения в публичном поиске Google. Описанные ниже практики применимы только для управления кастомными или внутренними поисковыми системами, основанными на технологиях Google (например, Google Custom Search Engine).

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

Применимо только для управления Custom Search:

• Интеграция бизнес-метрик в поиск: Если вы используете CSE, используйте этот механизм для загрузки внутренних данных. Загружайте данные о маржинальности, количестве остатков, конверсии или внутренних рейтингах качества товаров/контента.
• Улучшение сортировки и фильтрации: Используйте загруженные приватные данные для реализации кастомной сортировки (например, по маржинальности) или фильтрации (например, скрыть товары проблемных поставщиков) на вашем сайте через CSE.
• Обеспечение безопасности ключей: Тщательно контролируйте доступ к Access-restricted data key. Он должен использоваться только в сервер-к-серверу коммуникации и никогда не раскрываться в браузере пользователя.

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

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

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

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

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

Применимо для управления Custom Search или Вертикальным поиском:

Сценарий 1: E-commerce. Повышение высокомаржинальных товаров в CSE.

1. Задача: Интернет-магазин использует CSE для поиска по сайту и хочет повысить в выдаче товары с маржой >30%, не раскрывая маржу публично.
2. Действие: Магазин загружает через API приватные структурированные данные для каждого товара, указывая атрибут margin_level: high и ключ доступа KEY123.
3. Реализация: При запросе к CSE сервер магазина добавляет Access-restricted data key=KEY123 и параметр изменения веса (Biasing parameter), который повышает документы с атрибутом margin_level: high.
4. Результат: В поиске на сайте высокомаржинальные товары ранжируются выше. Конкуренты и пользователи не видят данных о марже.

Сценарий 2: App Store/Google Shopping. Пессимизация проблемных издателей.

1. Задача: Платформа (например, Google) хочет понизить в поиске приложения/товары от издателей, на которых поступает много жалоб (problematic publishers).
2. Действие: Google загружает во внутреннюю базу приватные данные с флагом publisher_status: problematic для соответствующих приложений и ключ доступа INTERNAL_KEY.
3. Реализация: При поиске в App Store/Shopping система использует Access-restricted data key=INTERNAL_KEY и параметр сильного понижения веса для контента с флагом publisher_status: problematic.
4. Результат: Контент проблемных издателей понижается в выдаче на основе непубличных данных.