Użytkownik szuka „sukienka na wesele” – ale nie wie jeszcze, jakie buty, torebkę i biżuterię do niej dobrać. Tradycyjne wyszukiwanie pokaże listę sukienek. Product discovery pokaże kompletną stylizację: sukienka + pasujące szpilki + kopertówka + kolczyki. Patenty Google i Adobe opisują systemy, które automatycznie rozpoznają relacje między produktami na podstawie zdjęć, atrybutów i zachowań użytkowników – i wykorzystują te relacje do rekomendacji.
W tym artykule analizuję mechanizmy product discovery w kontekście e-commerce SEO. Nie chodzi tu o „pozycjonowanie na frazy” – chodzi o to, jak sklep może budować relacje między produktami, żeby system wyszukiwania (i AI) mógł je odkrywać i rekomendować razem.
Patent nie jest dowodem, że dany mechanizm działa dokładnie tak w bieżącym algorytmie Google. Patent jest modelem analitycznym – pokazuje problem, który inżynierowie próbowali rozwiązać, i pozwala zbudować praktyczną checklistę dla e-commerce.
Czym product discovery różni się od product search?
| Aspekt | Product search | Product discovery |
|---|---|---|
| Intencja | Użytkownik wie, czego szuka („pompa IBO MHI 2500”) | Użytkownik szuka inspiracji („wyposażenie łazienki w stylu loft”) |
| Zapytanie | Konkretne: model, marka, SKU | Szerokie: kategoria, styl, okazja, problem |
| Wynik | Jeden produkt dopasowany do zapytania | Zestaw powiązanych produktów (similar + complementary) |
| Dane | Nazwa, cena, dostępność | Atrybuty, relacje, zdjęcia lifestyle, kontekst użycia |
| Metryka sukcesu | CTR na kartę produktu | Wartość koszyka, cross-sell, czas w sklepie |
W kontekście patentów: product search to dopasowanie zapytania do dokumentu (klasyczny retrieval). Product discovery to budowanie grafu relacji między produktami i wykorzystanie tego grafu do rekomendacji – nawet gdy użytkownik nie szukał konkretnego produktu.
Jak zdjęcia produktowe budują relacje między produktami?
Patent US20200372560A1 (Adobe Inc., Ayush Chopra, Balaji Krishnamurthy i in.) opisuje system, który analizuje zestawy zdjęć produktowych (product image sets) i automatycznie identyfikuje:
- Produkt główny (primary product) – produkt widoczny na zdjęciu izolowanym (białe tło, jeden przedmiot).
- Produkty towarzyszące (secondary products) – produkty widoczne na zdjęciach lifestyle razem z produktem głównym (np. sukienka + buty + torebka na jednym zdjęciu).
System buduje indeks powiązań: „ta sukienka pojawia się na zdjęciach razem z tymi butami i tą torebką” – i wykorzystuje te powiązania do rekomendacji. Gdy użytkownik szuka sukienki, system może zaproponować pasujące buty i torebkę na podstawie zdjęć, na których te produkty występują razem.
Dla sklepu e-commerce to oznacza: zdjęcia lifestyle (produkt w kontekście użycia, z innymi produktami) to nie tylko element UX – to dane wejściowe do systemu discovery. Zdjęcie pompy zainstalowanej w kotłowni razem ze zbiornikiem i automatyką mówi systemowi, że te produkty tworzą zestaw.
Jak embeddingi obrazów umożliwiają wyszukiwanie podobnych produktów?
Patenty US11782998B2 i US12032633B2 (Google LLC) opisują „embedding based retrieval for image search” – system, który zamienia zdjęcia produktów na wektory liczbowe (embeddingi) i porównuje te wektory, żeby znajdować produkty wizualnie podobne.
Jak to działa w praktyce? Omówiliśmy to szczegółowo w artykule o visual search. W kontekście product discovery kluczowe jest to, że system może:
- Znaleźć produkty wizualnie podobne do tego, co użytkownik ogląda (ta sama kategoria, inny model/marka).
- Znaleźć produkty pasujące stylistycznie (ten sam styl, kolor, materiał – inna kategoria).
- Połączyć zdjęcie z danymi strukturalnymi (Product schema) – dzięki czemu „podobne wizualnie” znaczy nie tylko „wygląda tak samo” ale „ma podobne parametry.”
Jakie typy relacji między produktami warto budować?
| Typ relacji | Przykład | Jak zbudować | Wpływ na SEO/discovery |
|---|---|---|---|
| Produkt podobny (alternative) | Pompa IBO MHI 2500 → Omnigena MHI 1300 | Sekcja „Porównaj z” / „Podobne produkty” na karcie | Zatrzymuje użytkownika w sklepie zamiast wracać do SERP |
| Produkt komplementarny (accessory) | Pompa → zbiornik hydroforowy → automatyka | Sekcja „Kupowane razem” / „Potrzebujesz też” | Zwiększa wartość koszyka, buduje product graph |
| Zestaw (bundle) | Zestaw hydroforowy: pompa + zbiornik 50L + wyłącznik | Dedykowana karta zestawu z linkami do komponentów | Nowe URL do indeksacji, odpowiada na zapytania „zestaw hydroforowy” |
| Ta sama kolekcja / seria | Kolekcja mebli „Loft”: stół + krzesła + komoda | Strona kolekcji z linkami do produktów | Buduje encję kolekcji, wspiera zapytania inspiracyjne |
| Pasuje do kontekstu (use case) | Wszystko do kuchni w stylu skandynawskim | Poradnik zakupowy linkujący do produktów | Odpowiada na zapytania inspiracyjne, buduje content cluster |
Jak polskie sklepy budują relacje produktowe?
Na podstawie audytów klientów e-commerce widzimy powtarzający się wzorzec: większość sklepów ma sekcję „Podobne produkty” generowaną automatycznie przez platformę, ale prawie żaden nie buduje relacji komplementarnych ręcznie.
| Element | Częstość w audytowanych sklepach | Wpływ na discovery |
|---|---|---|
| Sekcja „Podobne produkty” | Wysoka (generowana automatycznie) | Niski – algorytm platformy często dobiera produkty losowo lub po kategorii |
| Sekcja „Kupowane razem” | Niska (wymaga konfiguracji) | Wysoki – realne zestawy na podstawie danych zakupowych |
| Dedykowane strony zestawów | Bardzo niska | Bardzo wysoki – nowe URL, nowe zapytania, kompletna oferta |
| Zdjęcia lifestyle (produkt w kontekście) | Niska (większość ma tylko packshoty) | Wysoki – buduje relacje wizualne między produktami |
| Poradniki zakupowe linkujące do produktów | Średnia | Wysoki – odpowiada na zapytania inspiracyjne i „jak wybrać” |
| Tabele porównawcze wariantów | Niska | Wysoki – zatrzymuje użytkownika, redukuje pogo-sticking |
Jak polskie sklepy wypadają w audycie cross-sell? Dane z narzędzia MCP
Uruchomiliśmy narzędzie ECOM Cross-sell Semantic Audit na stronach klientów e-commerce (zanonimizowane). Narzędzie analizuje linki wewnętrzne na stronie i klasyfikuje je na 4 kategorie: akcesoria/kompatybilne, alternatywy/zamienniki, poradniki/content, kategoria nadrzędna. Wyniki:
| Sklep | Branża | Akcesoria | Alternatywy | Poradniki | Breadcrumby kat. | Priorytet |
|---|---|---|---|---|---|---|
| Sklep A | Budynki drewniane | 0 | 0 | 0 | 0 | P1 – brak jakiegokolwiek cross-sellu |
| Sklep B | Taping / sport / suplementy | 3 | 1 | 0 | 0 | P2 – brak poradników i breadcrumbów |
| Sklep C | Pompy / instalacje | 0 | 0 | 1 (blog) | 0 | P1 – brak cross-sellu, ale ma blog |
Wyniki potwierdzają wzorzec z wcześniejszej sekcji: większość sklepów nie buduje relacji produktowych w sposób widoczny dla crawlera. Sklep A (budynki drewniane) ma 120 linków wewnętrznych na stronie kategorii, ale żaden z nich nie jest oznaczony jako akcesoria, alternatywy ani poradnik – wszystkie prowadzą do podkategorii. Sklep B (taping) ma 3 linki do akcesoriów (co jest pozytywne), ale zero poradników typu „jak dobrać taping do kontuzji kolana” – a takie treści budują content cluster i odpowiadają na zapytania discovery.
Rekomendacje z narzędzia (wspólne dla wszystkich 3 sklepów):
- P1: Dodać blok cross-sell na kartach produktów: „Kupowane razem”, „Pasuje do”, „Porównaj z” – minimum 3-8 linków do kompatybilnych produktów.
- P2: Dodać linki do poradników wspierających decyzję zakupową: „Jak dobrać…”, „Który wybrać…”, „FAQ: najczęstsze pytania o…”
- P2: Dodać breadcrumby z BreadcrumbList schema, żeby system rozumiał hierarchię: produkt → kategoria → nadkategoria.
Co ważne: narzędzie klasyfikuje linki heurystycznie (po anchortekście i kontekście). Linki typu „Domki do 25m2” są klasyfikowane jako „inne” (nawigacja), nie jako „alternatywy” – bo nie mają kontekstu porównawczego. Żeby system (i użytkownik) rozumiał relację, anchor powinien brzmieć np. „Porównaj z domkami do 25m2” albo „Mniejsze modele: domki do 25m2.” Kontekst anchora buduje relację, nie sam link.
Jak linkowanie wewnętrzne i dane strukturalne wspierają product discovery?
Product discovery w SEO to nie tylko „sekcja podobnych produktów” – to cała architektura relacji między stronami sklepu. Kluczowe elementy:
- Breadcrumby z BreadcrumbList schema – mówią systemowi: ten produkt należy do tej kategorii, ta kategoria należy do tej nadkategorii. To najprostsza relacja hierarchiczna.
- Linkowanie produkt → kategoria – nie tylko w breadcrumbach, ale w opisie: „Ta pompa jest częścią naszej kolekcji pomp głębinowych.”
- Cross-sell w Product schema – pole
isRelatedToiisAccessoryOrSparePartForw schema.org Product. Mało sklepów je stosuje, ale system może je wykorzystać. - FAQ linkujące do produktów – „Jaki zbiornik dobrać do pompy MHI 2500? Rekomendujemy zbiornik 50L lub zbiornik 100L.”
- Poradniki jako hub – artykuł „Jak dobrać pompę do studni” linkujący do 5-10 konkretnych produktów buduje content cluster i odpowiada na zapytania inspiracyjne.
Jak pokazaliśmy w artykule o zachowaniu użytkownika w SERP: generyczne zapytanie („pompa hydroforowa”) lądujące na karcie jednego modelu daje CTR 0.3%. To samo zapytanie lądujące na stronie kategorii z porównaniem modeli daje znacznie lepsze wyniki – bo odpowiada na intencję discovery, nie search.
Case study: jak zapytania discovery rozkładają się między kartami produktów a kategoriami?
Na danych GSC sklepu z branży instalacyjnej (60 dni, zanonimizowane) widać wyraźnie, jak zapytania o różnej intencji trafiają na różne typy stron – i jak to wpływa na CTR:
| Query | Typ intencji | Typ strony docelowej | Impressions | CTR | Ocena |
|---|---|---|---|---|---|
| „pompa hydroforowa” | Discovery (szuka opcji) | Karta jednego modelu | 20 244 | 0.3% | ZLE – generic query na produkcie |
| „pompa do szamba” | Discovery (szuka opcji) | Kategoria pomp | 3 468 | 1.3% | OK – generic query na kategorii |
| „pompa do szamba” | Discovery (ten sam query) | Karta jednego modelu | 13 800 | 0.3% | ZLE – kanibalizacja: kategoria i produkt walczą o ten sam query |
| „zestaw do studni głębinowej” | Discovery (szuka zestawu) | Kategoria zestawów | 1 043 | 3.4% | DOBRZE – zapytanie o zestaw ląduje na kategorii zestawów |
| „pompa głębinowa z falownikiem” | Discovery (szuka typu) | Kategoria zestawów z falownikami | 1 158 | 4.9% | DOBRZE – precyzyjne zapytanie na dedykowanej kategorii |
| „omnitron 5000 automat” | Search (szuka modelu) | Karta tego modelu | 801 | 7.1% | IDEALNIE – branded query na właściwej karcie |
| „pompa głębinowa 2 cale” | Discovery (szuka typu) | Kategoria pomp 2-calowych | 424 | 8.0% | IDEALNIE – precyzyjne zapytanie na dedykowanej kategorii |
Wzorzec jest jednoznaczny:
- Zapytania discovery („pompa hydroforowa”, „pompa do szamba”) lądujące na kartach produktów mają CTR 0.3% z pozycji 3-5. Użytkownik szuka opcji, dostaje jeden model – wraca do SERP.
- Te same zapytania discovery lądujące na kategoriach mają CTR 1.3-4.9%. Użytkownik szuka opcji, dostaje listę z filtrami – zostaje.
- Zapytania search (branded) („omnitron 5000 automat”, „mhi 1300 inox”) lądujące na kartach produktów mają CTR 5-8.7%. Użytkownik szuka konkretnego modelu – i go znajduje.
Największy problem tego sklepu: „pompa hydroforowa” (20 244 impressions!) ląduje na karcie jednego modelu zamiast na kategorii. To jest 20 tysięcy szans na discovery, z których sklep wykorzystuje 0.3%. Gdyby to zapytanie lądowało na stronie kategorii z porównaniem modeli, filtrem po parametrach i zestawami – CTR mógłby wzrosnąć 5-10×.
Drugi problem: kanibalizacja na „pompa do szamba” – kategoria (CTR 1.3%, 3468 imp) i karta produktu (CTR 0.3%, 13800 imp) walczą o ten sam query. Google pokazuje produkt 4× częściej niż kategorię, ale kategoria konwertuje 4× lepiej. Rozwiązanie: wzmocnić kategorię linkowaniem wewnętrznym i canonical, żeby Google wybierał ją dla zapytań discovery.
Z drugiej strony: „zestaw do studni głębinowej” (CTR 3.4%) i „pompa głębinowa z falownikiem” (CTR 4.9%) to przykłady dobrze działającego discovery. Sklep ma dedykowane kategorie zestawów – i Google je rankuje. To pokazuje, że tworzenie stron zestawów i dedykowanych kategorii per use case (nie tylko per typ produktu) bezpośrednio przekłada się na lepsze wyniki.
Jak audytować sklep pod kątem product discovery?
Checklista 10 punktów:
- Czy karta produktu pokazuje produkty podobne (alternatywy w tej samej kategorii)?
- Czy karta produktu pokazuje produkty komplementarne (akcesoria, części zamienne)?
- Czy sklep ma strony zestawów (bundle) z linkami do komponentów?
- Czy produkty z tej samej kolekcji/serii są powiązane linkami?
- Czy sklep ma zdjęcia lifestyle (produkt w kontekście użycia, z innymi produktami)?
- Czy breadcrumby mają BreadcrumbList schema?
- Czy Product schema używa pól isRelatedTo / isAccessoryOrSparePartFor?
- Czy istnieją poradniki zakupowe linkujące do konkretnych produktów?
- Czy sklep ma tabele porównawcze wariantów w kategorii?
- Czy linkowanie wewnętrzne buduje relacje produkt ↔ kategoria ↔ poradnik?
Jakie wnioski płyną z patentów o product discovery?
Patenty opisują systemy, w których produkty nie istnieją w izolacji – istnieją w sieci relacji:
- Product image sets (US20200372560A1, Adobe) – zdjęcia lifestyle budują relacje między produktami. System rozpoznaje, które produkty „pasują” do siebie na podstawie ich wspólnego występowania na zdjęciach.
- Embedding retrieval (US11782998B2, Google) – wektory obrazów umożliwiają wyszukiwanie produktów „wizualnie podobnych” i „stylistycznie pasujących.” Opisaliśmy to w artykule o visual search.
- Digital supplement association (US12032633B2, Google) – system łączy zdjęcia z danymi strukturalnymi, dzięki czemu „podobne” oznacza nie tylko „wygląda tak samo” ale „ma podobne parametry i zastosowanie.”
Dla sklepu e-commerce product discovery to nie „nice to have” – to odpowiedź na zapytania inspiracyjne, które stanowią rosnącą część ruchu (szczególnie w modzie, wyposażeniu wnętrz i hobby). Sklep, który buduje relacje między produktami (cross-sell, zestawy, poradniki, zdjęcia lifestyle) odpowiada na te zapytania. Sklep, który ma tylko karty produktów z packshotami – nie.
Ten artykul jest czescia cyklu „SEO e-commerce w swietle patentow Google.” Pelna mape 74 patentow, dane z audytow 6 sklepow i checklisty do pobrania znajdziesz w kompletnej mapie 10 warstw SEO e-commerce.
Strony kategorii to naturalne miejsce dla product discovery – ale większość sklepów traktuje je jak listing z filtrem. W artykule o opisach kategorii e-commerce pokazujemy, że kategorie z poradnikiem wyboru mają engagement 94%, a bez treści wspierającej – znacznie niższy.
To jest dwunasty artykuł z cyklu „SEO e-commerce w świetle patentów Google.” Następne artykuły obejmą opisy produktów i kategorii pod kątem patentów. Jeśli potrzebujesz pozycjonowania sklepu internetowego lub audytu SEO – skontaktuj się z nami.
Źródła
Patenty
1. US20200372560A1 – „Method for exploring and recommending matching products across categories.” Adobe Inc. Ayush Chopra, Balaji Krishnamurthy i in. patents.google.com/patent/US20200372560
2. US11782998B2 – „Embedding based retrieval for image search.” Google LLC. patents.google.com/patent/US11782998
3. US12032633B2 – „Digital supplement association and retrieval for visual search.” Google LLC. patents.google.com/patent/US12032633
Dokumentacja
4. Schema.org – Product type, isRelatedTo, isAccessoryOrSparePartFor. schema.org/Product
5. Google Search Central – Product structured data. developers.google.com
6. Google Merchant Center – Product data specification. support.google.com
