Как Google группирует варианты товаров (цвет, размер) от разных продавцов, анализируя заголовки и структуру данных

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

Graph Component / Connected Component (Компонент графа / Связный компонент)

Подграф, в котором Product Catalog Entries (вершины) связаны, потому что они имеют общие Merchant Cluster IDs (ребра). Представляет собой группу глобально идентифицированных вариантов продукта.

Merchant Cluster / Merchant Variant Product Group (Кластер продавца / Группа вариантов продукта продавца)

Группа товарных предложений (Product Offers) от одного конкретного продавца, которые система идентифицировала как варианты одного и того же базового продукта.

Merchant Cluster Identifier (Идентификатор кластера продавца)

Уникальный идентификатор, присваиваемый Merchant Cluster.

Product Catalog Entry (Запись каталога продуктов)

Запись, созданная системой, представляющая один уникальный вариант продукта. Она агрегирует предложения от нескольких продавцов для этого конкретного варианта.

Product Offer (Товарное предложение)

Данные, предоставленные продавцом для конкретного продукта, который он продает (включает заголовок, цену, идентификаторы).

Variant Attribute Type (Тип атрибута варианта)

Категория атрибута (например, "Цвет", "Размер", "Память").

Variant Attribute Value (Значение атрибута варианта)

Конкретное значение атрибута (например, "Синий", "XL", "8GB").

Variant Key (Ключ варианта)

Нормализованный заголовок продукта, в котором значения атрибутов заменены их типами (например, "Бренд Модель [Цвет]"). Используется для выявления потенциальных вариантов в фиде продавца.

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

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

1. Система получает товарные предложения (Product Offers) от множества продавцов, содержащие заголовки и значения атрибутов вариантов.
2. Для каждого продавца система идентифицирует наборы предложений, которые, вероятно, являются вариантами (на основе заголовков), и присваивает каждому набору Merchant Cluster Identifier.
3. Система группирует предложения в Product Catalog Entries, где каждая запись соответствует конкретному варианту продукта.
4. Система ассоциирует Merchant Cluster Identifier из предложения с Product Catalog Entry, к которой оно принадлежит.
5. Система группирует Product Catalog Entries, которые имеют пересекающиеся (общие) Merchant Cluster Identifiers.
6. Ключевой механизм нормализации: Для каждой такой группы система определяет, какой Merchant Cluster Identifier ассоциирован с наибольшим количеством Product Catalog Entries.
7. Система классифицирует записи, связанные с этим доминирующим идентификатором, как официальный набор вариантов одного продукта.
8. Система определяет значения атрибутов для этого набора и обеспечивает их представление (Claim 4 уточняет, что используются значения из доминирующего кластера).

Ядро изобретения (пункты 6 и 7) — это механизм разрешения конфликтов. Если Продавец А считает, что у товара есть варианты Красный и Синий, а Продавец Б считает, что есть варианты Алый и Лазурный, система смотрит, чей кластер (А или Б) охватывает большее количество уникальных продуктов (Product Catalog Entries). Кластер с наибольшим охватом "побеждает" и определяет канонические варианты и их названия.

Claim 3 (Зависимый от 1): Детализирует, как происходит идентификация вариантов на уровне продавца (Шаг 2 в Claim 1).

1. Идентификация предложений продавца, у которых заголовки имеют совпадающие названия продуктов и совпадающие *типы* атрибутов вариантов (т.е. одинаковый Variant Key).
2. Проверка, имеют ли эти предложения *различные* *значения* атрибутов.
3. Если да, классификация их как вероятных вариантов.

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

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

Изобретение в основном применяется на этапе индексирования и обработки данных, критически важных для E-commerce поиска (например, Google Shopping).

CRAWLING – Сканирование и Сбор данных
Система получает данные о товарах (Product Offers). Это происходит преимущественно через загрузку продуктовых фидов (например, Google Merchant Center).

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

• Нормализация и NLP: Анализ заголовков (Product Titles), извлечение атрибутов, генерация Variant Keys.
• Кластеризация (Уровень продавца): Идентификация Merchant Clusters и присвоение им ID.
• Генерация каталога: Агрегация Product Offers в Product Catalog Entries (дедупликация и группировка на основе идентификаторов GTIN/MPN и других данных).
• Идентификация вариантов (Глобальный уровень): Построение графа связей, идентификация Connected Components, определение канонических групп вариантов и нормализация значений атрибутов.

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

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

• Product Offers (Заголовки, Идентификаторы, Описания).
• Словари значений и шаблонов атрибутов (используются для извлечения данных из заголовков).

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

• Product Catalog Entries, аннотированные канонической информацией о вариантах (к какой группе они принадлежат и каково их нормализованное значение атрибута).

На что влияет

• Конкретные типы контента: Влияет исключительно на товарные предложения (E-commerce).
• Специфические запросы: Влияет на коммерческие запросы, где пользователи ищут продукты с определенными характеристиками (например, "синие кроссовки Nike Air Max").
• Форматы контента: Влияет на представление данных в Google Shopping, товарных каруселях и Rich Results, позволяя группировать варианты в единый интерфейс.
• Конкретные ниши или тематики: Наибольшее влияние в нишах с широким ассортиментом вариантов: одежда, обувь, электроника.

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

Алгоритм применяется в процессе обработки и индексации товарных фидов или при обновлении продуктового каталога. Он активируется, когда система обнаруживает множественные предложения от одного или нескольких продавцов, которые потенциально относятся к вариантам одного и того же продукта.

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

Алгоритм состоит из двух основных фаз: группировка на уровне продавца и глобальная группировка.

Фаза А: Группировка вариантов на уровне продавца

1. Извлечение атрибутов: Для каждого товарного предложения продавца анализируется заголовок. Используются словари или сопоставление с шаблонами (например, регулярные выражения для размеров, рекурсивные определения типа "светлый [Цвет]") для извлечения Variant Attribute Values (например, "Красный").
2. Генерация Variant Key: Извлеченные значения заменяются соответствующим Variant Attribute Type (например, "Цвет"). Полученный нормализованный заголовок становится Variant Key (например, "Музыкальный Плеер - Цвет").
3. Идентификация вариантов: Группируются все предложения, имеющие одинаковый Variant Key.
4. Проверка уникальности: Анализируются извлеченные значения атрибутов внутри группы. Если каждое предложение имеет уникальный набор значений атрибутов (например, одно Красное, другое Синее, дубликатов нет), процесс продолжается.
5. Присвоение кластера: Если значения уникальны, эти предложения классифицируются как варианты. Этой группе (Merchant Cluster) присваивается уникальный Merchant Cluster Identifier.

Фаза Б: Глобальная группировка вариантов и нормализация

1. Генерация каталога: Все товарные предложения (от всех продавцов) агрегируются в Product Catalog Entries. Каждая запись представляет один уникальный вариант продукта (используя GTIN, MPN и т.д. для идентификации).
2. Аннотирование: Для каждой Product Catalog Entry определяются все Merchant Cluster Identifiers, связанные с предложениями, которые она содержит. Создаются пары (Merchant Cluster ID, Catalog Entry ID).
3. Построение графа (Связывание): Создается связь (ребро графа) между любыми двумя Product Catalog Entries, которые имеют хотя бы один общий Merchant Cluster Identifier.
4. Анализ связных компонентов: Запускается алгоритм для идентификации Graph Components (групп записей, связанных прямо или косвенно). Каждый компонент представляет собой набор связанных вариантов продукта.
5. Выбор доминирующего кластера (Нормализация/Разрешение конфликтов): Для каждого Graph Component подсчитывается, сколько Product Catalog Entries связано с каждым присутствующим в компоненте Merchant Cluster Identifier.
6. Определение канонического варианта: Выбирается Merchant Cluster Identifier, связанный с наибольшим количеством записей. Это "доминирующий кластер".
7. Нормализация значений атрибутов: Значения атрибутов, извлеченные из доминирующего кластера, используются как канонические значения для представления вариантов в пользовательском интерфейсе. (Например, если доминирующий кластер использует "Синий", используется это значение, а не "Blu" из меньшего кластера).

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

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

• Контентные факторы: Product Title (Заголовок товара) является основным источником данных, используемым для идентификации вариантов в этом патенте.
• Технические факторы (Идентификаторы): Упоминаются Product Identifiers (GTIN, UPC, MPN, ISBN, EAN, JAN, Бренд/Модель). Они используются на этапе генерации каталога для группировки предложений в Product Catalog Entries.

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

• Сопоставление с шаблонами / Регулярные выражения (Pattern Matching/Regex): Используется для извлечения значений атрибутов из заголовков (например, поиск соответствия шаблону "D'xD"" для размеров).
• Поиск по словарю (Dictionary Lookups): Сравнение терминов в заголовках с известными значениями атрибутов.
• Проверка уникальности (Uniqueness Check): Определение уникальности значений атрибутов внутри группы с одинаковым Variant Key.
• Анализ графа (Connected Components): Алгоритм теории графов, используемый для глобальной группировки связанных вариантов.
• Подсчет частоты (Dominant Cluster): Ключевая метрика нормализации. Кластер, связанный с наибольшим количеством Product Catalog Entries, определяет каноническую структуру и наименования.

1. Критичность заголовков товаров (Titles): Патент подчеркивает, что Product Titles играют ключевую роль в идентификации вариантов, даже при наличии структурированных данных. Система активно анализирует текст заголовков для понимания структуры ассортимента.
2. Внутренняя консистентность данных продавца: Процесс начинается на уровне отдельного продавца. Google полагается на последовательность и консистентность в данных (особенно в шаблонах заголовков) внутри фида продавца для формирования Merchant Clusters. Неконсистентные данные затрудняют этот процесс.
3. Глобальная идентификация как задача теории графов: Для объединения данных от разных продавцов Google строит граф, связывая продукты на основе того, как их группируют сами продавцы. Это позволяет системе находить связи между вариантами, даже если продавцы используют разную терминологию.
4. Нормализация по принципу большинства (Dominant Cluster): Разрешение конфликтов в названиях и структуре вариантов основано на "правиле большинства" или полноте данных. Продавец (или группа продавцов), который предоставляет наиболее полный и последовательно структурированный набор вариантов, часто определяет каноническое представление для всего каталога Google.
5. Важность корректных идентификаторов: Хотя анализ заголовков используется для определения *связей* между вариантами, корректные уникальные идентификаторы (GTIN, MPN) для *каждого* варианта необходимы для точного формирования Product Catalog Entries, которые являются основой для глобальной группировки.

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

Рекомендации сфокусированы на оптимизации товарных фидов (например, Google Merchant Center) и структуры данных на сайте E-commerce.

• Оптимизация Product Titles для ясности вариантов: Убедитесь, что заголовки товаров четко включают ключевые атрибуты вариантов (Цвет, Размер, Объем). Используйте последовательные и консистентные шаблоны (например, Бренд + Линейка + Продукт + Атрибут варианта). Это помогает системе генерировать корректные Variant Keys.
• Обеспечение абсолютной внутренней консистентности: Варианты одного и того же продукта должны использовать абсолютно одинаковую базовую структуру заголовка, различаясь только значениями атрибутов. Например, "Рубашка Поло Хлопок - Синий" и "Рубашка Поло Хлопок - Красный", а не "Синяя Рубашка Поло" и "Красная рубашка из хлопка".
• Использование четких и недвусмысленных значений атрибутов: Избегайте непонятных сокращений или внутреннего жаргона (например, используйте "Зеленый", а не "Зел" или код цвета). Это увеличивает вероятность того, что ваша терминология будет принята как каноническая (если ваш кластер станет доминирующим).
• Предоставление полного охвата вариантов: Предложение полного ассортимента вариантов, четко и последовательно описанных, увеличивает размер вашего Merchant Cluster. Это повышает вероятность его выбора в качестве доминирующего/канонического источника данных.
• Точность уникальных идентификаторов (GTIN/MPN): Убедитесь, что для *каждого отдельного варианта* (SKU) указан корректный и уникальный идентификатор. Это критически важно для того, чтобы система могла правильно сгруппировать предложения в Product Catalog Entries.

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

• Неконсистентные структуры заголовков: Использование разных форматов заголовков для разных вариантов одного и того же продукта. Это мешает системе идентифицировать их как Merchant Cluster.
• Пропуск информации о вариантах в заголовках: Полагаться исключительно на структурированные данные (атрибуты в фиде или schema.org) для дифференциации вариантов, не указывая их в Product Title. Патент показывает, что заголовки активно анализируются.
• Использование двусмысленных атрибутов или сокращений: Использование терминологии, которая может быть непонятна системе или конфликтовать с общепринятыми названиями.
• Некорректные идентификаторы: Использование GTIN базового продукта для всех его вариантов. Это приводит к некорректному формированию Product Catalog Entries и разрушает группировку вариантов.

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

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

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

Сценарий: Оптимизация фида для группировки вариантов футболок

Ситуация ДО оптимизации (Плохо):
Продавец предоставляет фид с неконсистентными заголовками.

• Offer 1: Title: "Крутая футболка ACME, Красная, L", GTIN: 111
• Offer 2: Title: "ACME Футболка Синяя Размер М", GTIN: 222
• Offer 3: Title: "Зеленая футболка ACME (S)", GTIN: 333

Результат: Система не может надежно сгенерировать Variant Key из-за разных структур. Товары отображаются в поиске как отдельные продукты, не связанные друг с другом.

Ситуация ПОСЛЕ оптимизации (Хорошо):
Продавец стандартизирует заголовки по шаблону: Продукт + Бренд + Цвет + Размер.

• Offer 1: Title: "Футболка Classic Хлопок ACME - Красный - L", GTIN: 111
• Offer 2: Title: "Футболка Classic Хлопок ACME - Синий - M", GTIN: 222
• Offer 3: Title: "Футболка Classic Хлопок ACME - Зеленый - S", GTIN: 333

Процесс системы:

1. Извлечение: Система извлекает значения (Красный, L; Синий, M; Зеленый, S).
2. Генерация Variant Key: Система генерирует ключ: "Футболка Classic Хлопок ACME - [Цвет] - [Размер]".
3. Группировка: Все три предложения имеют одинаковый ключ и уникальные значения. Они группируются в Merchant Cluster.
4. Результат: Товары корректно идентифицируются как варианты. В Google Shopping и Поиске они отображаются как один продукт с возможностью выбора цвета и размера.