Close Menu

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

    OBTAINING ACCESS-RESTRICTED SEARCH RELATED STRUCTURED DATA (Получение структурированных данных, связанных с поиском, с ограниченным доступом)
    2012 Google Shopping Индексация Патенты Google Персонализация

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

    Описание

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

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

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

    Запатентована система управления доступом к структурированным данным в поисковой базе. Система позволяет хранить приватные структурированные данные (access-restricted search related structured data), связанные с определенным URL, и защищать их ключом доступа (database data access key). Эти данные недоступны при стандартном сканировании. Доступ к данным для использования в поиске предоставляется только в том случае, если поисковый запрос содержит соответствующий авторизационный ключ (access-restricted data key).

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

    Механизм работает в двух фазах:

    1. Загрузка данных: Авторизованный владелец сайта загружает приватные структурированные данные и определяет ключ доступа. Данные сохраняются в поисковой базе и ассоциируются с URL и ключом. Загрузка может происходить через API или путем сканирования специальной приватной версии URL.
    2. Использование данных: При выполнении поиска (например, через Google Custom Search Engine) авторизованная система отправляет запрос, включающий ключ доступа. Система проверяет валидность ключа. Если ключ верный, система извлекает приватные данные и использует их для ранжирования, применения фильтров (restriction) или изменения весов (biasing) результатов.

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

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

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

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

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

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

    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. Результат: Контент проблемных издателей понижается в выдаче на основе непубличных данных.

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

    Влияет ли этот патент на ранжирование в публичном поиске Google (google.com)?

    Нет, этот патент не влияет на публичный поиск. Он описывает механизм для авторизованного доступа к приватным данным, который используется в кастомных или внутренних поисковых системах (например, Google Custom Search Engine). Публичный поиск Google не имеет «ключа доступа» для использования приватных данных отдельных сайтов.

    Могу ли я загрузить приватные структурированные данные, чтобы мой сайт лучше ранжировался в Google?

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

    Что такое «Access-restricted search related structured data»?

    Это структурированные данные (например, рейтинги, цены, статусы), которые связаны с URL, но хранятся приватно в базе данных Google. Ключевая особенность, описанная в патенте (Claim 9), заключается в том, что эти данные недоступны для публичного сканирования (crawling). Доступ к ним возможен только при предъявлении специального ключа.

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

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

    Как приватные данные попадают в индекс Google согласно патенту?

    Патент описывает два основных способа загрузки данных авторизованными пользователями. Первый – прямая загрузка через API (например, HTTP POST запрос). Второй – система сканирует специальную приватную версию URL, доступ к которой предоставляется с помощью Private URL access key, предоставленного владельцем сайта.

    Какие примеры приватных данных можно использовать?

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

    В чем разница между Biasing parameter и Restriction parameter?

    Restriction parameter используется для жесткой фильтрации: если документ не соответствует условию, он исключается из выдачи. Biasing parameter используется для изменения веса (повышения или понижения) документа в ранжировании, но не исключает его полностью. Например, можно отфильтровать (restrict) только товары в наличии, и повысить (bias) среди них товары с высокой маржой.

    Как система обеспечивает безопасность этих приватных данных?

    Безопасность обеспечивается механизмом ключей. Данные хранятся в базе и ассоциируются с Database data access key. Чтобы использовать эти данные, необходимо предоставить соответствующий Access-restricted data key в поисковом запросе. Без совпадения ключей доступ к данным не предоставляется.

    Может ли Google использовать этот механизм против моего сайта, например, в Google Shopping или App Store?

    Да, технически это возможно. В патенте упоминается использование приватных данных о качестве источника для понижения контента от «постоянно проблемных издателей» (persistently problematic publishers). Если Google классифицирует ваш аккаунт как проблемный на основе непубличных данных (например, жалобы, возвраты), этот механизм позволяет использовать такой приватный флаг для понижения вашего контента в вертикальном поиске.

    Какое значение этот патент имеет для SEO-специалиста, если он не влияет на публичный поиск?

    Для SEO-специалиста этот патент важен для понимания инфраструктурных возможностей Google. Он показывает, что Google может индексировать и использовать данные, полученные не только через краулинг. Также он критически важен, если специалист занимается управлением и оптимизацией поиска на сайте клиента, использующего Google Custom Search Engine.