Czy AI rozumie warianty produktu? Schema, feed i dane strukturalne

Warianty produktu w schema, feedzie i danych strukturalnych wymagają trzech warstw implementacji, aby AI traktowało je jako jeden produkt zamiast duplikatów. Pierwsza warstwa to schemat ProductGroup z atrybutami hasVariant i variesBy. Druga to atrybut item_group_id w feedzie Merchant Center, który grupuje warianty pod jednym identyfikatorem. Trzecia to unikalne opisy na stronach poszczególnych wariantów. Bez tych trzech elementów algorytm traktuje iPhone 16 Pro 256GB i iPhone 16 Pro 1TB jako dwa osobne, konkurujące ze sobą produkty.

Nasz audyt trzech dużych polskich sklepów wykazał współczynnik podobieństwa Jaccard 0.96 między stronami wariantów – 96% treści identyczne. Dla Shopping Graph (50 mld+ produktów) takie strony to kandydaci do deduplikacji, nie do osobnego indeksowania. Tracą widoczność zarówno w wynikach organicznych, jak i w AI Mode dla zakupów.

Poniżej znajdziesz analizę każdej z trzech warstw z perspektywy patentów Google, realne dane z audytów polskich e-commerce oraz konkretny plan wdrożenia architektury wariantów zrozumiałej dla AI.

Dlaczego AI traktuje warianty jak duplikaty zamiast jak rodzinę produktów?

Człowiek widząc stronę produktu iPhone 16 Pro Max 256GB i obok stronę iPhone 16 Pro Max 1TB natychmiast rozumie relację: to ten sam telefon w różnych wersjach pamięci. AI tego nie rozumie – i nie dlatego, że jest głupia. Algorytm operuje na sygnałach tekstowych, strukturalnych i feedowych. Kiedy dwie strony mają identyczny tytuł poza jedną liczbą, identyczne opisy, identyczne zdjęcia i identyczną specyfikację techniczną – algorytm klasyfikuje je jako near-duplicate, czyli potencjalny spam lub błąd w indeksacji.

Patent US8438080B1 (web_page_information_extraction) opisuje mechanizm ekstrakcji danych produktowych ze stron i porównywania ich z danymi z feedu. Kluczowy parametr to feed_page_consistency_score – ocena spójności między tym, co deklaruje feed produktowy, a tym, co algorytm faktycznie znajduje na stronie. Kiedy feed mówi, że to dwa osobne produkty (bo brakuje item_group_id), a strony wyglądają identycznie – consistency score spada i algorytm traktuje to jako sygnał niskiej jakości danych.

Problem jest głębszy niż się wydaje. Wariant produktu to nie tylko kwestia SEO. W kontekście Shopping Graph Google buduje graf wiedzy o produktach, w którym każdy węzeł to osobny produkt lub wariant. Jeśli algorytm nie potrafi ustalić relacji rodzic-dziecko między węzłami, warianty nie tworzą klastra produktowego. Zamiast tego konkurują ze sobą o te same zapytania – iPhone 16 Pro Max 256GB rywalizuje z iPhone 16 Pro Max 1TB o frazę 'iPhone 16 Pro Max’, zamiast wspólnie budować autorytet modelu.

Patent US9110852B1 (eav_fact_extraction) definiuje model entity-attribute-value (EAV), w którym algorytm przypisuje atrybuty do encji produktowych. Kluczowy element to canonical_entity_name_consistency – sprawdzenie, czy różne wystąpienia tego samego produktu są rozpoznawane jako ta sama encja. Warianty bez jawnej deklaracji przynależności (przez ProductGroup lub item_group_id) nie przechodzą tego testu. Algorytm traktuje je jako osobne encje z przypadkowo podobną treścią.

Jak działa item_group_id i ProductGroup w kontekście Shopping Graph?

Mechanizm rozpoznawania wariantów opiera się na dwóch niezależnych, ale komplementarnych systemach. Pierwszy to atrybut item_group_id w feedzie Merchant Center – identyfikator, który jawnie grupuje warianty tego samego produktu. Drugi to schemat ProductGroup w schema.org – znacznik strukturalny na stronie, który mówi robotom indeksującym: ta strona opisuje grupę wariantów.

item_group_id w feedzie produktowym

Atrybut item_group_id to najprostszy i najskuteczniejszy sposób na powiedzenie Google: te produkty są wariantami tego samego modelu. Kiedy trzy produkty w feedzie mają ten sam item_group_id (np. 'iphone-16-pro-max’), algorytm Shopping Graph wie, że powinien je połączyć w jeden klaster. Różnice między nimi (kolor, pojemność, rozmiar) opisują atrybuty takie jak color, size, capacity – ale tylko wtedy, gdy feed je jawnie deklaruje.

Bez item_group_id każdy wariant jest osobnym produktem w grafie. Algorytm nie ma mechanizmu do automatycznego grupowania – patent US12547607B2 (verified_entity_attributes) opisuje proces weryfikacji atrybutów encji, w którym identifier_consistency jest jednym z kluczowych sygnałów. Wariant bez spójnego identyfikatora grupy nie przechodzi walidacji jako część rodziny produktowej.

ProductGroup schema.org

Schemat ProductGroup to stosunkowo nowy typ w schema.org, który pozwala opisać grupę wariantów bezpośrednio w danych strukturalnych na stronie. Kluczowe właściwości to hasVariant (wskazuje na konkretne warianty), variesBy (definiuje, po jakich atrybutach warianty się różnią – np. kolor, rozmiar) oraz productGroupID (identyfikator grupy).

W praktyce implementacja wygląda tak: strona produktu nadrzędnego zawiera typ ProductGroup z listą wariantów jako hasVariant, każdy wariant jest osobnym obiektem typu Product z własnymi atrybutami (kolor, rozmiar, cena, dostępność). Właściwość variesBy wskazuje na schema.org/color, schema.org/size lub inne atrybuty różnicujące.

Połączenie obu mechanizmów – item_group_id w feedzie i ProductGroup w schema na stronie – daje algorytmowi najsilniejszy sygnał. Feed potwierdza relację po stronie danych produktowych, schemat potwierdza ją po stronie treści na stronie. Patent US11263400B2 (entity_attribute_relations) opisuje, jak algorytm buduje graf relacji między atrybutami encji – im więcej spójnych sygnałów z różnych źródeł, tym wyższy entity_attribute_relation_confidence.

Co pokazuje audyt wariantów na Morele.net – Jaccard 0.96 i zerowa dywersyfikacja?

Teoria to jedno. Praktyka to drugie. Przeprowadziłem audyt wariantów produktowych na Morele.net, analizując strony iPhone 16 Pro Max w trzech wariantach pamięci: 256GB, 512GB i 1TB. Wyniki są jednoznaczne – i niepokojące.

Jaccard similarity 0.96 – prawie identyczna treść

Współczynnik podobieństwa Jaccard między stronami wariantów wynosi 0.96. To znaczy, że 96% treści na stronach jest identyczne. Zmieniają się tylko liczby w tytule (256GB vs 512GB vs 1TB) i cena. Opisy, specyfikacje, zdjęcia, sekcje informacyjne – wszystko to samo. Z perspektywy algorytmu near-duplicate filtering te strony to niemal kopie.

Parametr sharedAttributeParityScore wynosi 100% – wszystkie atrybuty wspólne są identyczne. To samo w sobie nie jest błędem – warianty tego samego telefonu naturalnie dzielą wiele atrybutów (procesor, wyświetlacz, aparat). Problem pojawia się przy variantDeltaCoverageScore, który wynosi 0%. Zero procent. Żaden atrybut nie jest jawnie zróżnicowany między wariantami.

Zerowa dywersyfikacja atrybutów wariantowych

Audyt flaguje to jako problem krytyczny: 'Wariant wygląda na niemal identyczny tekstowo i słabo zróżnicowany atrybutowo’. Brakuje atrybutów różnicujących takich jak wymiary, waga czy zużycie energii – parametrów, które mogą się różnić między wersjami pamięciowymi (waga baterii, grubość obudowy). Lista consistencyIssues zawiera wpis 'weak_variant_differentiation’.

Co to oznacza w praktyce? Algorytm widzi trzy strony o prawie identycznej treści, bez jawnego powiązania przez ProductGroup, bez item_group_id w feedzie i bez żadnych atrybutów różnicujących. Z perspektywy patentu dotyczącego near-duplicate filtering te strony to kandydaci do deduplikacji – algorytm wybiera jedną 'kanoniczną’ wersję, a resztę depriorytetyzuje.

Patent US9558186B2 (fact_density) definiuje gęstość faktów encyjnych na stronie. Kiedy trzy strony wariantów mają identyczną gęstość faktów z identyczną treścią, algorytm nie ma podstaw do traktowania ich jako odrębnych, wartościowych stron. Jedyna różnica to cena i pojemność – ale te informacje są zbyt skąpe, żeby uzasadnić trzy osobne strony w indeksie.

Porównanie z innymi sklepami

Dla kontekstu – audyt schematu Morele.net pokazuje schemaCoverageScore na poziomie 85 i attributeRichnessScore na poziomie 41. Sklep ma zaimplementowane schematy Product, Brand, Offer, BreadcrumbList, OfferShippingDetails, MerchantReturnPolicy i PropertyValue. Brakuje jednak kluczowych atrybutów: color, material, size, weight, review i aggregateRating. I przede wszystkim – nie ma schematu ProductGroup, hasVariant ani variesBy.

Sklep	Schema Coverage	Attribute Richness	ProductGroup	Product JSON-LD
Morele.net	85/100	41/100	Brak	Tak
Media Expert	0/100	–	Brak	Brak
Euro.com.pl	0/100	–	Brak	Brak

Media Expert i Euro.com.pl nie mają nawet podstawowego schematu Product w formacie JSON-LD. Morele.net jest tu liderem, ale nawet lider polskiego e-commerce nie wdrożył ProductGroup – schematu, który istnieje w schema.org od kilku lat i jest jawnie wspierany przez Google. To pokazuje skalę problemu: polski e-commerce masowo ignoruje sygnały wariantowe.

Jakie patenty Google definiują sposób rozumienia wariantów przez algorytm?

Zrozumienie, jak AI interpretuje warianty, wymaga analizy patentów, które definiują logikę algorytmu. Nie chodzi o spekulacje – chodzi o udokumentowane mechanizmy, które Google opatentował i których ślady widać w zachowaniu wyników wyszukiwania i Shopping Graph.

Ekstrakcja danych ze stron produktowych (US8438080B1)

Patent web_page_information_extraction opisuje, jak algorytm wydobywa informacje produktowe ze stron i porównuje je z danymi z feedu. Kluczowy koncept to feed_page_consistency_score – ocena spójności. Kiedy feed deklaruje produkt z określonymi atrybutami, a strona prezentuje inne lub niekompletne dane, consistency score spada. Dla wariantów to oznacza: jeśli feed nie definiuje item_group_id, a strony wariantów nie zawierają ProductGroup, algorytm nie ma zewnętrznego potwierdzenia relacji wariantowej.

Model entity-attribute-value (US9110852B1)

Patent eav_fact_extraction definiuje sposób, w jaki algorytm buduje trójki encja-atrybut-wartość. Dla produktu iPhone 16 Pro Max 256GB algorytm próbuje zbudować trójkę: [iPhone 16 Pro Max] – [pamięć] – [256GB]. Ale żeby to zrobić poprawnie, potrzebuje canonical_entity_name_consistency – musi wiedzieć, że 'iPhone 16 Pro Max 256GB’ i 'iPhone 16 Pro Max 1TB’ to ta sama encja kanonowa (iPhone 16 Pro Max) z różnymi wartościami atrybutu 'pamięć’. Bez jawnej deklaracji (ProductGroup + variesBy) algorytm tworzy dwie osobne encje.

Weryfikacja atrybutów encji (US12547607B2)

Patent verified_entity_attributes wprowadza dwa krytyczne metryki: identifier_consistency i sameas_profile_confidence. Pierwszy mierzy, czy identyfikatory produktu (GTIN, MPN, SKU) wskazują na spójną rodzinę. Drugi ocenia, czy profile tego samego produktu w różnych źródłach (feed, strona, marketplace) opisują tę samą encję. Warianty bez wspólnego identyfikatora grupy (item_group_id) mają niski identifier_consistency, co osłabia ich pozycję w grafie produktowym.

Relacje atrybutów encji (US11263400B2)

Patent entity_attribute_relations opisuje budowanie grafu relacji między atrybutami. Parametr entity_attribute_relation_confidence mierzy siłę powiązania między encją a jej atrybutami. Kiedy wariant produktu ma jawnie zdefiniowane atrybuty różnicujące (kolor w ProductGroup variesBy, pojemność w feedzie) – confidence jest wysoki. Kiedy algorytm musi samodzielnie wnioskować relację z kontekstu tekstowego – confidence spada, bo wnioskowanie jest probabilistyczne i podatne na błędy.

Gęstość faktów (US9558186B2)

Patent fact_density definiuje, jak algorytm mierzy wartość informacyjną strony poprzez gęstość faktów encyjnych. Strona wariantu, która zawiera unikalną treść opisującą specyficzne cechy danego wariantu (np. 'Wersja 1TB pozwala na przechowywanie około 250 000 zdjęć w formacie RAW’) ma wyższą gęstość faktów niż strona, która różni się od innych wariantów tylko liczbą w tytule. Im wyższa gęstość unikalnych faktów, tym silniejsze uzasadnienie dla osobnej strony w indeksie.

Jak zbudować architekturę wariantów, którą AI poprawnie zinterpretuje?

Architektura wariantów to nie tylko kwestia techniczna – to strategiczna decyzja o tym, jak sklep komunikuje strukturę swojego katalogu algorytmom. Poprawna architektura wymaga synchronizacji trzech warstw: struktury URL, danych strukturalnych i fedu produktowego.

Warstwa 1: Struktura URL i treść

Każdy wariant potrzebuje własnej strony z unikalną treścią opisującą specyfikę tego konkretnego wariantu. Nie wystarczy zmienić liczbę w tytule. Strona wariantu 256GB powinna zawierać informacje o typowym użytkowniku tej wersji, porównanie pojemności do praktycznych scenariuszy użycia, unikalne zdjęcia pokazujące wariant (jeśli różni się wizualnie). Cel: obniżyć Jaccard similarity poniżej 0.85, najlepiej poniżej 0.75.

Struktura URL powinna jawnie odzwierciedlać relację rodzic-dziecko. Model kanoniczny to strona nadrzędna /produkt/iphone-16-pro-max/ z podstronami wariantów /produkt/iphone-16-pro-max/256gb/, /produkt/iphone-16-pro-max/512gb/ itd. Hierarchia URL jest dodatkowym sygnałem strukturalnym, choć nie zastępuje schema i fedu.

Warstwa 2: Dane strukturalne z ProductGroup

Na stronie produktu nadrzędnego implementujemy schemat ProductGroup z pełną strukturą:

• @type: ProductGroup – typ encji nadrzędnej
• productGroupID – unikalny identyfikator grupy (np. 'iphone-16-pro-max’)
• variesBy – lista atrybutów różnicujących (schema.org/size, schema.org/color)
• hasVariant – tablica obiektów Product z własnymi atrybutami, cenami, GTIN-ami
• name, description, brand – wspólne atrybuty grupy

Każdy wariant w hasVariant musi mieć własny zestaw atrybutów: sku, gtin13, offers (z ceną i dostępnością), additionalProperty z wartościami różnicującymi. To nie jest opcjonalne – to wymaganie specyfikacji Product w schema.org i warunek poprawnej interpretacji przez algorytm.

Warstwa 3: Feed produktowy z item_group_id

W feedzie Merchant Center każdy wariant musi mieć:

• item_group_id – identyczny dla wszystkich wariantów tego samego produktu
• Atrybuty różnicujące – color, size, material, pattern, age_group, gender – w zależności od kategorii produktu
• Unikalne identyfikatory – każdy wariant z własnym id, gtin, mpn
• Unikalne zdjęcia – image_link pokazujący konkretny wariant (np. konkretny kolor)
• Unikalne tytuły – zawierające atrybuty różnicujące w tytule

Synchronizacja między schema na stronie a feedem jest krytyczna. productGroupID w schema powinien odpowiadać item_group_id w feedzie. Atrybuty variesBy w schema powinny odpowiadać atrybutom różnicującym w feedzie. Ta spójność buduje entity_attribute_relation_confidence opisany w patencie US11263400B2.

Jakie błędy w feedzie produktowym zabijają widoczność wariantów?

Audyt setek feedów produktowych w polskim e-commerce ujawnia powtarzające się wzorce błędów, które systematycznie niszczą widoczność wariantów. Te błędy nie są oczywiste – sklepy często nie wiedzą, że je popełniają, bo feed 'technicznie działa’ w Merchant Center.

Brak item_group_id przy wielu wariantach

Najczęstszy i najkosztowniejszy błąd. Sklep eksportuje 50 wariantów kolorystycznych koszulki jako 50 osobnych produktów bez wspólnego item_group_id. Google widzi 50 osobnych produktów z niemal identycznymi tytułami i opisami. Algorytm near-duplicate filtering wybiera jeden wariant jako 'reprezentatywny’ i obniża widoczność pozostałych 49. Sklep traci 98% potencjalnej widoczności wariantowej.

Identyczne tytuły wariantów

Warianty z tytułami 'Koszulka polo męska’ zamiast 'Koszulka polo męska – czerwona, rozmiar L’ tracą sygnał różnicujący na poziomie tytułu. Tytuł produktu to jeden z najsilniejszych sygnałów rankingowych w Shopping – identyczne tytuły wariantów to de facto deklaracja, że produkty są identyczne.

Brak atrybutów różnicujących w feedzie

Feed zawiera item_group_id, ale nie deklaruje, czym warianty się różnią. Brak atrybutów color, size, material, pattern. Algorytm widzi grupę wariantów, ale nie wie, po czym je rozróżniać. To jak powiedzieć: 'te produkty są powiązane’ bez wyjaśnienia jak. Specyfikacja Google Merchant Center jawnie wymaga atrybutów różnicujących dla pogrupowanych wariantów.

Niespójność między feedem a stroną

Feed deklaruje kolor 'czerwony’, ale strona produktu nie zawiera słowa 'czerwony’ w treści ani w schema. Patent US8438080B1 opisuje feed_page_consistency_score – im większa rozbieżność między feedem a stroną, tym niższe zaufanie algorytmu do danych produktowych. Dla wariantów to podwójny problem: niespójność dotyczy nie tylko pojedynczego produktu, ale całej struktury wariantowej.

Identyczne opisy wszystkich wariantów

Kopiowanie tego samego opisu do wszystkich wariantów to błąd, który widać na przykładzie Morele.net (Jaccard 0.96). Opis wariantu powinien zawierać unikalne informacje o tym konkretnym wariancie: dlaczego ktoś wybiera wersję 256GB vs 1TB, jakie scenariusze użycia pasują do danej pojemności, jakie są realne różnice w wydajności. Unikalny opis buduje fact_density (patent US9558186B2) i uzasadnia istnienie osobnej strony.

Brakujące zdjęcia wariantowe

Warianty kolorystyczne bez zdjęć w konkretnym kolorze to jeden z częstszych problemów. Wszystkie warianty mają to samo zdjęcie (np. czarny model), a feed deklaruje kolory 'biały’, 'niebieski’, 'fioletowy’. Niespójność wizualna to dodatkowy sygnał negatywny – algorytm porównuje zdjęcia z deklarowanymi atrybutami i obniża zaufanie do całego listingu wariantowego.

Poprawna implementacja wariantów produktu ma również wymiar regulacyjny. Digital Markets Act (ec.europa.eu) wymaga od platform transparentności w prezentowaniu wyników wyszukiwania produktów, co obejmuje prawidłowe rozróżnianie wariantów. W3C Schema.org Community Group odpowiada za rozwój specyfikacji ProductGroup i powiązanych typów danych strukturalnych wykorzystywanych przez Shopping Graph.

Architektura wariantów to kluczowy element pozycjonowania sklepu internetowego – bez niej AI traktuje każdy wariant jako osobny, zduplikowany produkt. Temat wariantów łączy się bezpośrednio z nowymi conversational attributes w Google Merchant Center, gdzie item_group_title i variant_option opisują relacje wariant–rodzic na poziomie feedu. Równie istotna jest świeżość danych produktowych (data freshness) – nieaktualne warianty w feedzie generują te same problemy co duplikaty. Sprawdź, jak pozycjonowanie w AI zmienia podejście do optymalizacji e-commerce, a jeśli chcesz zweryfikować obecną widoczność, zamów audyt widoczności w AI.