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

Описание

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

Патент решает проблему сбора и структурирования информации о компаниях (enterprises), которая необходима для создания функциональных локальных каталогов (например, Google Local/Maps). Базовые данные (NAP) часто доступны, но детализированная информация (часы работы, способы оплаты, парковка) разбросана по интернету в неструктурированном виде и в разных форматах. Изобретение направлено на автоматическое преобразование этих разрозненных данных в единый, машиночитаемый структурированный формат и разрешение конфликтов между источниками.

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

Запатентована система (Structure Generation Engine), которая собирает данные о компаниях из множества источников (коммерческие поставщики, сайты компаний, каталоги). Система извлекает неструктурированные факты в виде пар ключ-значение, нормализует их в структурированный формат, определяет, к какой именно компании они относятся (Clustering или Entity Resolution), и присваивает фактам уровни достоверности (Confidence Levels) на основе перекрестной проверки данных.

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

Система работает в несколько этапов:

• Сбор данных: Данные поступают от коммерческих поставщиков и через сканирование веб-сайтов компаний и каталогов с помощью краулеров.
• Извлечение данных: Из контента извлекаются текстовые строки, содержащие факты (пары ключ-значение).
• Парсинг и Нормализация: Ключи классифицируются (например, распознается «Часы работы»), а значения преобразуются в машиночитаемый формат. Патент детально описывает сложный процесс нормализации неоднозначных данных, таких как часы работы.
• Кластеризация: Факты группируются по компаниям. Система определяет, относятся ли разные наборы фактов к одной и той же компании, используя данные о названии, адресе, телефоне (NAP) и географической близости.
• Сравнение фактов: Сравниваются факты из разных источников. Совпадающие факты получают высокий Confidence Level. Фактам также присваивается вес (Weight) в зависимости от надежности источника, свежести и полноты информации.
• Представление: В каталоге отображаются факты с наибольшей достоверностью и весом.

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

Высокая. Описанные механизмы являются фундаментом для работы Google Maps, Local Pack и Knowledge Panels для локального бизнеса. Процессы извлечения информации (Information Extraction), разрешения сущностей (Entity Resolution/Clustering) и определения достоверности информации остаются критически важными задачами для Google в 2025 году и основой для построения Knowledge Graph.

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

Влияние на SEO, особенно на локальное (Local SEO), критическое (9/10). Патент описывает, как именно Google собирает, интерпретирует и валидирует основную информацию о бизнесе, найденную в интернете. Понимание этих механизмов напрямую влияет на стратегии оптимизации локального присутствия. Он подчеркивает важность консистентности данных (NAP) для правильной кластеризации, необходимость предоставления четкой и легко парсируемой информации на сайте компании, и объясняет, как Google разрешает конфликты данных между разными источниками.

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

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

Clustering (Кластеризация)

Процесс сопоставления извлеченных фактов с конкретной компанией (Enterprise). Аналог процесса разрешения сущностей (Entity Resolution). Использует сравнение названия, телефона, местоположения (NAP) и географической близости для определения того, относятся ли разные наборы фактов к одному и тому же объекту.

Confidence Level (Уровень достоверности)

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

D-Collapse (Схлопывание дней)

Шаг в процессе нормализации часов работы. Последовательности символов, обозначающих дни недели (например, «M-W» или «Пн-Ср»), схлопываются в единое представление, например, в битовый вектор, указывающий открытые дни.

Enterprise (Компания/Организация)

Объект, о котором собирается информация (бизнес, школа, государственное учреждение и т.д.).

Key Normalization (Нормализация ключа)

Процесс классификации типа данных в строке (например, определение того, что строка содержит данные о часах работы или парковке).

Neighborhoods (Окрестности/Районы)

Географические зоны, используемые в процессе кластеризации. Факты в пределах одной окрестности сравниваются для определения принадлежности к одной компании, учитывая «радиус ошибки» в адресах.

Similarity Score (Оценка схожести)

Метрика для кластеризации, рассчитываемая при сравнении двух наборов фактов на основе NAP и местоположения.

Structure Generation Engine (Механизм генерации структуры)

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

T-Insertion (Вставка времени)

Шаг в процессе нормализации часов работы. Обработка случаев, когда отсутствует граничное значение времени (например, указано только время закрытия «до 7 вечера»). Система может вставить предполагаемое время начала работы на основе контекста.

Value Normalization (Нормализация значения)

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

Weight (Вес)

Метрика, присваиваемая факту для разрешения конфликтов. Может основываться на свежести факта (Recency), надежности источника (Trustworthiness) или полноте информации (Completeness).

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

Хотя общее описание патента (Description) охватывает всю систему генерации структурированной информации (включая кластеризацию и сравнение), Формула изобретения (Claims) сосредоточена очень узко — на конкретном методе нормализации часов работы (business hours).

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

1. Система получает электронный документ с неструктурированными данными о часах работы.
2. Данные извлекаются модулем извлечения (data extraction module).
3. Модуль парсинга (data parsing module) создает структурированное представление. Этот процесс включает модуль нормализации значений (Value Normalization Module), который выполняет:
• Классификация символов: Парсинг строки для определения символов, представляющих дни недели (Days), и символов, представляющих время работы (Times).
• Схлопывание дней (Collapsing / D-Collapse): Схлопывание символов дней для формирования строки с символом, представляющим последовательность дней.
• Интерпретация: Интерпретация символов для определения часов работы в эти дни.
4. Ключевое утверждение: Структурированное представление включает вектор (vector), описывающий последовательность дней с использованием битов, указывающих дни недели, когда компания открыта.

Claim 3 и 15 (Зависимые): Уточняют процесс нормализации, добавляя шаг вставки времени (T-Insertion).

• Система идентифицирует описание часов работы, в котором отсутствует граничное значение (bounding value), и вставляет символ, представляющий время работы, в качестве этого значения.

Claim 4, 5, 16, 17 (Зависимые): Уточняют, что символы также классифицируются как разделители (separators) и модификаторы (modifiers, например, «открыто»/»закрыто»).

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

Изобретение является ключевой частью конвейера обработки данных для локального поиска и баз знаний о сущностях (Knowledge Graph).

CRAWLING – Сканирование и Сбор данных
Data Acquisition Module активно собирает данные. Используются Web Crawling Modules (как общего, так и специального назначения для сайтов с известной структурой) для обхода сайтов компаний (Enterprise Web Sites) и каталогов (Directory Web Sites). Также принимаются данные от коммерческих поставщиков.

INDEXING – Индексирование и извлечение признаков
Основная работа системы происходит на этом этапе. Structure Generation Engine выполняет глубокую обработку:

1. Извлечение (Extraction): Идентификация и извлечение строк, содержащих факты.
2. Парсинг и Нормализация (Parsing/Normalization): Преобразование текста в структурированные данные (Key/Value Normalization).
3. Кластеризация (Clustering): Ассоциация фактов с конкретными компаниями (Entity Resolution). Использует сравнение NAP и географическую близость.
4. Сравнение фактов (Comparison): Оценка достоверности фактов путем сравнения данных из разных источников, расчет Confidence Levels и Weights.

Результаты сохраняются в Structured Data Database.

RANKING / METASEARCH (Ранжирование / Метапоиск)
Структурированные данные используются для ответов на сложные запросы (например, «рестораны, открытые сейчас») и для отображения информации в профилях компаний (Local Pack, Maps, Knowledge Panels). Fact Presentation Module определяет, как отображать эти факты пользователю и нужна ли атрибуция источника.

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

• Неструктурированные и полуструктурированные веб-страницы.
• Структурированные данные от коммерческих поставщиков (например, NAP фиды).

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

• Нормализованные структурированные факты о компаниях, сгруппированные по Cluster ID.
• Метрики достоверности (Confidence Levels) и веса (Weights) для каждого факта.

На что влияет

• Конкретные типы контента и ниши: В первую очередь влияет на Local SEO и представление сущностей. Критически важно для видимости локального бизнеса (рестораны, ритейл, услуги) в Google Maps и панелях знаний.
• Специфические запросы: Локальные запросы и запросы, требующие точных фактических ответов о часах работы, услугах, способах оплаты и т.д.

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

• Триггеры активации: Алгоритмы извлечения и нормализации активируются при обработке контента, содержащего информацию о компаниях. Кластеризация и сравнение активируются при обнаружении новых или обновленных данных для объединения информации из нескольких источников.
• Частота применения: Процессы применяются непрерывно в рамках общего цикла сканирования и индексирования интернета.

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

А. Общий процесс генерации структурированных данных

1. Сбор данных (Acquisition): Получение данных из фидов и с помощью краулинга веб-сайтов.
2. Извлечение данных (Extraction): Извлечение строк, содержащих пары ключ-значение, с использованием парсеров (регулярные выражения или wrapper induction).
3. Парсинг и Нормализация (Parsing/Normalization):
   • Нормализация ключа: Определение типа факта.
   • Нормализация значения: Преобразование значения в машиночитаемый формат.
4. Кластеризация (Clustering):
   • Группировка фактов по географическим окрестностям (Neighborhoods) на основе широты/долготы.
   • Расчет оценки схожести (Similarity Score) между наборами фактов на основе NAP.
   • Объединение наборов фактов, если оценка схожести превышает порог. Присвоение Cluster ID.
5. Сравнение фактов (Comparison):
   • Сравнение нормализованных фактов для одной компании из разных источников.
   • Расчет Confidence Level на основе степени согласия источников.
   • Присвоение Weight на основе надежности источника, свежести и полноты данных.
6. Представление фактов (Presentation):
   • Выбор фактов для отображения на основе Confidence Level и Weight.
   • Подавление дубликатов.
   • Определение необходимости атрибуции источника (факты с низкой достоверностью отображаются с ссылкой).

Б. Детальный алгоритм нормализации часов работы (Фокус Claims)

Применяется к строке, например, «open M-W 9 to 5, TH to 7».

1. Классификация символов: Строка парсится для классификации каждого символа как: Время (T), День (D), Разделитель (-), Открыто/Закрыто (O/C) или Игнорируемый (X). (Пример: «OD-DT-TD-T»).
2. Схлопывание дней (D-Collapse): Последовательности символов D схлопываются в один символ D, представляющий диапазон дней (например, в виде битового вектора). (Пример: «ODT-TD-T»).
3. Вставка времени (T-Insertion): Система проверяет наличие пропущенных граничных значений (например, «TH to 7» не имеет времени начала). При необходимости вставляется предполагаемое время (например, время начала из предыдущего блока «9»). (Пример: «ODT-TDT-T»).
4. Интерпретация времени: Система применяет эвристики для определения AM/PM или следующего дня (например, время начала 8-11 обычно AM).
5. Нормализованное представление: Часы работы представляются в виде структурированного вектора для каждого дня недели.

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

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

• Контентные факторы: Текст веб-страниц и каталогов. Извлекаются строки, описывающие факты: часы работы, способы оплаты, наличие парковки, правила бронирования, услуги, бренды.
• Идентификационные данные (NAP): Название (Name), Адрес (Address), Телефон (Phone number). Критически важны для кластеризации.
• Технические факторы: URL источника данных используется для атрибуции и потенциально для оценки надежности источника (Weight).
• Географические факторы: Адрес компании преобразуется в широту и долготу для определения географической близости и группировки по Neighborhoods во время кластеризации.
• Структурные факторы: Структура HTML (например, таблицы) может использоваться для извлечения пар ключ-значение.

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

• Similarity Score (Оценка схожести): Используется для кластеризации. Рассчитывается путем сравнения NAP и местоположений. Для сравнения названий используются метрики текстуального сходства на основе общих слов и биграмм, взвешенных по частоте в корпусе.
• Confidence Level (Уровень достоверности): Используется для оценки точности факта. Рассчитывается на основе степени согласия между несколькими источниками, предоставляющими один и тот же факт.
• Weight (Вес): Используется для выбора наилучшей версии факта при конфликтах. Рассчитывается на основе:
  • Надежности источника (Trustworthiness).
  • Свежести факта (Recency).
  • Полноты информации (Completeness) (например, часы работы с указанием времени весят больше, чем просто указание дней).

Выводы

1. Агрессивное структурирование данных: Google активно стремится преобразовать неструктурированный контент интернета в машиночитаемые факты. Это основа для построения Knowledge Graph и локального индекса.
2. Сложность интерпретации данных (Нормализация): Патент детально показывает (и защищает в Claims) сложный эвристический процесс нормализации часов работы (D-Collapse, T-Insertion). Это подчеркивает важность предоставления информации в четком и недвусмысленном формате.
3. Критичность разрешения сущностей (Clustering): Процесс кластеризации является ключевым. Система должна точно определить, к какой компании относится факт, используя NAP и географическую близость. Консистентность NAP критична для этого процесса.
4. Достоверность через консенсус и взвешивание: Google не полагается на один источник. Confidence Level определяется путем перекрестной проверки (консенсус). При конфликтах используется Weight, который учитывает надежность (авторитет) и свежесть источника.
5. Презентация зависит от достоверности: Факты с высокой достоверностью показываются без атрибуции (воспринимаются как истинные), факты с низкой достоверностью или ненормализованные факты показываются с атрибуцией (ссылкой на источник), перекладывая интерпретацию на пользователя.

Практика

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

• Абсолютная консистентность NAP: Обеспечьте идеальное совпадение названия, адреса и телефона (NAP) на вашем сайте, в Google Business Profile и во всех внешних каталогах. Это критически важно для процесса кластеризации (Clustering), чтобы Google мог уверенно сопоставить все факты с вашей компанией и повысить Confidence Level.
• Четкое и стандартное форматирование ключевой информации: Используйте максимально простые и стандартные форматы для часов работы, способов оплаты, услуг. Учитывая сложность нормализации часов работы, предпочтительнее использовать формат (Пн-Пт: 09:00–17:00), а не сложные текстовые описания.
• Использование структурированных данных (Schema.org): Внедряйте микроразметку (например, LocalBusiness, openingHoursSpecification). Это позволяет предоставить данные в уже нормализованном виде, минуя сложный и подверженный ошибкам процесс парсинга неструктурированного текста.
• Управление экосистемой цитирования (Citation Management): Активно управляйте присутствием компании в авторитетных каталогах (Directory Web Sites). Поскольку Google использует эти данные для верификации и присвоения Weights, важно, чтобы информация там была точной, полной и актуальной.
• Полнота информации на собственном сайте: Убедитесь, что ваш сайт (Enterprise Web Site) содержит наиболее полную информацию. Система предпочитает наиболее полные факты (с большим Weight).

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

• Неконсистентные данные NAP или использование трекинговых номеров: Различия в адресах или использование разных телефонных номеров в разных источниках могут негативно сказаться на процессе кластеризации и привести к фрагментации данных или созданию дубликатов.
• Сложное или образное описание фактов: Использование нестандартных или неоднозначных текстовых описаний (например, «работаем допоздна» или «до последнего клиента»). Это затрудняет нормализацию и может привести к ошибкам интерпретации.
• Игнорирование неточностей в сторонних источниках: Допущение наличия устаревшей информации в каталогах снижает общий Confidence Level и может привести к тому, что Google предпочтет неверные данные из-за большего веса источников.
• Размещение ключевой информации в изображениях: Размещение часов работы или NAP в виде изображений делает невозможным их извлечение и нормализацию с помощью описанных текстовых парсеров.

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

Этот патент имеет фундаментальное значение для Local SEO. Он раскрывает инфраструктуру Google для понимания локального бизнес-ландшафта и подтверждает переход к entity-based search. Стратегия локального продвижения должна строиться вокруг облегчения работы Structure Generation Engine: помогать Google легко находить, правильно интерпретировать (нормализовать), корректно ассоциировать (кластеризовать) и верифицировать (сравнивать) информацию о вашем бизнесе. Успех зависит от управления всей информационной экосистемой, а не только от оптимизации собственного сайта.

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

Сценарий 1: Оптимизация часов работы для нормализации

• Плохо (Трудно нормализовать): На сайте указано: «Мы открыты с утра до вечера в будни, по субботам до 6, а в праздники звоните уточняйте». Система может не справиться с интерпретацией «утра» и «вечера» (требуется T-Insertion и эвристика), и может проигнорировать информацию о праздниках.
• Хорошо (Легко нормализовать): Использование четкой структуры: «Часы работы: Пн-Пт 09:00–18:00; Сб 10:00–18:00; Вс Выходной». Это позволяет системе точно применить классификацию символов и D-Collapse.
• Идеально (Структурированные данные): Использование Schema.org openingHours: «openingHours»: «Mo-Fr 09:00-18:00», «Sa 10:00-18:00». Это устраняет необходимость в парсинге неструктурированного текста.

Сценарий 2: Улучшение кластеризации и достоверности через консистентность

• Ситуация: Ресторан имеет адрес «ул. Лесная, д. 5». На сайте указан этот адрес. В каталоге А указано «ул. Лесная, 5». В каталоге Б указано «Лесная ул., дом 5, корпус 1» (ошибочно) и старый телефон.
• Проблема (по патенту): Различия в адресе и телефоне снижают Similarity Score. Система может не связать факты из каталога Б с рестораном или создать дубликат. Confidence Level адреса и телефона снижен из-за конфликта.
• Действие SEO-специалиста: Провести аудит всех упоминаний. Привести все упоминания к единому стандарту (идентичному сайту и GBP). Исправить данные в каталоге Б.
• Результат: Система кластеризации рассчитывает высокий Similarity Score для всех упоминаний и корректно объединяет все факты в один кластер. Confidence Level повышается, и в выдаче отображаются корректные данные.

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