AI shopping: jak przygotować feed produktowy pod rozmowę

Jeśli zarządzasz feedem produktowym dla Google Shopping, optymalizujesz go zwykle pod klasyczne dopasowanie: tytuł, cena, EAN, zdjęcie, dostępność. To nadal baza. Problem zaczyna się wtedy, gdy klient nie wpisuje już krótkiej frazy typu „kurtka gore-tex damska xl”, tylko pyta konwersacyjnie: „szukam czegoś na deszczową jesień w górach” albo „potrzebuję ciepłej kurtki dla 5-latka na camping”. W tym modelu sam zestaw podstawowych pól przestaje wystarczać.

AI shopping nie kasuje klasycznego feeda. Podnosi poprzeczkę dla jakości danych. Google pisze dziś o Shopping Graph jako katalogu obejmującym ponad 60 mld listingów produktowych i równolegle rozwija doświadczenia zakupowe oparte na AI i agentic commerce. To oznacza jedno: feed musi lepiej opisywać kontekst użycia produktu, warianty, logistykę i ograniczenia, a nie tylko nazwę oraz cenę.

Ten artykuł pokazuje, które atrybuty warto rozszerzyć, jak przeprowadzić audit i jakich błędów unikać przy wdrożeniu.

Jak agenty konwersacyjne czytają feed inaczej niż klasyczna wyszukiwarka

W praktyce agenty czytają feed przez pryzmat intencji, ograniczeń i kontekstu zakupu, więc sam tytuł, cena i kategoria to za mało.

Klasyczny feed Google Shopping był optymalizowany pod jedno zadanie: dopasować słowa z zapytania do pól produktu. Tytuł z maksymalną liczbą wariantów nazwy, opis wypełniony frazami, precyzyjna kategoria i cena często wystarczały, by wejść do gry.

Model konwersacyjny działa inaczej. Zamiast szukać wyłącznie zgodności słów, próbuje zrozumieć potrzebę użytkownika i zestawić ją z danymi o produkcie.

Feed tradycyjny: kolumny pod dopasowanie

W klasycznym modelu feed e-commerce opiera się głównie na:

• `title` — nazwa produktu i wariantu
• `description` — opis produktu
• `google_product_category` — taksonomia Google
• `price` / `sale_price`
• `availability` — dostępność

To nadal ważne pola. Problem w tym, że nie opisują dobrze sytuacji użycia.

Feed dla agentów: dane pod intent i kontekst

Zapytanie typu „Potrzebuję czegoś ciepłego na camping w październiku dla dziecka 5 lat” nie zawiera gotowej nazwy produktu. Zawiera za to:

• warunek użycia
• sezon lub pogodę
• profil użytkownika
• potrzebę funkcjonalną

Jeśli feed nie niesie tych wymiarów poza rozmiarem i kategorią, agent ma mało punktów styku z intencją. Wygrywa nie ten sklep, który upchnął więcej słów kluczowych, tylko ten, który lepiej opisał produkt.

Google w maju 2026 opisał Shopping Graph jako katalog obejmujący ponad 60 mld listingów produktowych, a nie 45 mld jak w komunikatach z 2024 roku. To ważna korekta, bo pokazuje skalę i aktualność całego systemu: Introducing the Universal Cart and more ways to help you shop.

Więcej o warstwie konwersacyjnej przeczytasz też w artykule po co nam agenty konwersacyjne.

Które atrybuty naprawdę mają znaczenie

Największy wpływ mają dane o dostawie, kontekście użycia, wariantach i ograniczeniach regulacyjnych.

Nie chodzi o wrzucenie wszystkiego do feeda. Chodzi o uzupełnienie tych pól, które pomagają systemowi lepiej zrozumieć produkt.

Dostępność i logistyka

Samo `availability: in_stock` często nie wystarcza, jeśli użytkownik pyta o termin dostawy lub odbiór.

Google potwierdza, że `shipping` służy do nadpisywania ustawień konta na poziomie produktu, a `shipping_label` do grupowania produktów pod konkretne koszty i czasy dostawy: shipping, shipping_label.

Kontekst użycia i specyfikacja

Tu najczęściej widać różnicę między feedem „minimalnym” a feedem, który daje się czytać semantycznie.

Atrybut `product_highlight` jest oficjalnym atrybutem Merchant Center. Google opisuje go jako krótkie, skanowalne punkty, które odpowiadają na najczęstsze pytania klientów i podkreślają najważniejsze cechy produktu: product_highlight.

Zamiast zostawiać sam tytuł:

Kurtka zimowa dziecięca z kapturem, 116 cm

lepiej dopisać w `product_highlight`:

• Ocieplana do -15°C
• Wodoodporna membrana 10 000 mm
• Dobra na camping i piesze wycieczki
• Wiek 4-6 lat
• Sezon jesień-zima

Atrybut `product_detail` pozwala dodać techniczne dane w parach `section_name`, `attribute_name`, `attribute_value`. Google pisze wprost, że poprawia to możliwość wyświetlania konkretnych produktów na podstawie zapytań użytkowników: product_detail.

Przykład:

product_detail: Parametry:Temperatura użytkowania:-15°C do 5°C
product_detail: Parametry:Wodoszczelność:10 000 mm
product_detail: Zastosowanie:Typ aktywności:Outdoor, camping

Warianty i dopasowanie

Jeśli warianty są źle opisane, agent dostaje bałagan zamiast spójnego produktu.

Najważniejsze pola to:

• `item_group_id` — grupowanie wariantów jednego produktu
• `size_type` — np. `regular`, `petite`, `maternity`
• `size_system` — np. `EU`, `US`, `UK`
• `age_group` — np. `kids`, `adult`

To szczególnie ważne w odzieży, obuwiu i produktach dziecięcych, gdzie użytkownik często podaje wiek, rozmiar albo system numeracji.

Ograniczenia i polityki

Ta warstwa jest ważna, ale łatwo ją opisać nieprecyzyjnie.

• `condition` rozróżnia produkt nowy, odnowiony i używany.
• `return_policy_label` służy do przypisywania niestandardowej polityki zwrotów do grupy produktów. Google podkreśla, że polityka zwrotów jest ważnym czynnikiem decyzji zakupowej: return_policy_label, return policies.
• `excluded_destination` pozwala wyłączyć produkt z wybranych miejsc emisji.
• `certification` nie jest polem na dowolne hasła typu „CE”. W aktualnej dokumentacji Google dotyczy wspieranych certyfikacji regulacyjnych, np. EPREL w UE, EFTA i UK, więc trzeba używać go zgodnie ze specyfikacją, a nie jako ogólnego pola na zgodność produktu: certification.

Przed i po: prosty przykład z e-commerce odzieżowego

Różnica jest prosta: po rozszerzeniu feed niesie więcej sygnałów o zastosowaniu produktu, a nie tylko jego nazwę.

Poniższy przykład jest ilustracyjny.

Produkt: Kurtka dziecięca zimowa, 116 cm, granatowa.

Feed przed rozszerzeniem:

title: Kurtka zimowa dziecięca granatowa 116
description: Kurtka zimowa dla dzieci z kapturem, ocieplana...
google_product_category: 212
availability: in_stock
price: 249.00 PLN

Feed po rozszerzeniu:

title: Kurtka zimowa dziecięca granatowa 116
product_highlight[1]: Ocieplana do -15°C
product_highlight[2]: Wodoodporna membrana 10 000 mm
product_highlight[3]: Camping i górskie wycieczki
product_highlight[4]: Wiek 4-6 lat, sezon jesień-zima
product_detail[1]: Parametry:Min. temperatura:-15°C
product_detail[2]: Parametry:Wodoszczelność:10 000 mm
product_detail[3]: Zastosowanie:Aktywność:Outdoor, camping
age_group: kids
size_system: EU
size_type: regular
item_group_id: KD-ZIMOWA-GRANATOWA
shipping_label: standard_48h
return_policy_label: 30_day_return

Przy zapytaniu typu „ciepła kurtka na camping dla 5-latka na październik” drugi feed daje systemowi dużo więcej punktów zaczepienia.

Powiązany artykuł o strukturze danych produktowych: AI Shopping Feed Schema

Jak rozszerzyć feed krok po kroku

Najbezpieczniej zacząć od audytu jednej kategorii, potem zmapować brakujące pola i dopiero wtedy skalować wdrożenie.

Krok 1: Audit

Zacznij od eksportu obecnego feeda i sprawdź:

1. Czy `product_highlight` jest wypełniony dla kluczowych SKU.

2. Czy `product_detail` zawiera techniczne parametry tam, gdzie mają znaczenie.

3. Czy `age_group` i `size_system` są ustawione dla odzieży i obuwia.

4. Czy `item_group_id` poprawnie grupuje warianty.

5. Czy `shipping` i `shipping_label` oddają realne warunki dostawy.

6. Czy `return_policy_label` jest podpięty tam, gdzie polityka zwrotów różni się od domyślnej.

7. Czy pola regulacyjne są użyte tylko tam, gdzie naprawdę pasują do specyfikacji Google.

Jeśli ponad połowa produktów w kategorii nie ma tych danych, to jest właściwy punkt startu.

Krok 2: Mapowanie źródeł danych

Nowe atrybuty muszą mieć źródło, a nie być dopisywane ręcznie na ślepo.

Przy małym katalogu część pól da się uzupełnić ręcznie albo regułami. Przy większym zwykle potrzebujesz PIM, middleware albo własnego eksportera.

Krok 3: Wdrożenie i kontrola jakości

1. Dodaj nowe kolumny do źródła danych albo uzupełnij je regułami.

2. Wgraj zmiany do Merchant Center.

3. Sprawdź zakładkę `Needs attention` i stronę szczegółów problemów.

4. Zweryfikuj ręcznie kilkanaście produktów.

5. Obserwuj zmiany w wyświetleniach, kliknięciach i jakości danych.

Google nadal wspiera Content API for Shopping, ale równolegle rozwija Merchant API jako główny kierunek integracji programistycznej. Jeśli budujesz nową integrację, warto brać to pod uwagę: Merchant API, API access.

Nie wdrażaj wszystkiego na cały katalog naraz. Jedna kategoria daje szybszą diagnostykę i mniejsze ryzyko bałaganu.

7 błędów przy rozszerzaniu feeda

Najczęstsze wpadki to duplikowanie opisów, błędne grupowanie wariantów i aktualizacje zbyt rzadkie względem stanu magazynowego.

1. Kopiowanie opisu do `product_highlight`.

To mają być krótkie punkty, nie akapit z description.

2. Pusty `item_group_id` dla wariantów.

Bez poprawnego grupowania system dostaje wiele rozłącznych pozycji zamiast jednego produktu z odmianami.

3. Traktowanie `shipping_label` jak informacji dla klienta.

To etykieta techniczna do reguł dostawy w Merchant Center, a nie pole, które użytkownik zobaczy.

4. Brak kontroli po aktualizacji feeda.

Po zmianie atrybutów trzeba sprawdzić błędy i ostrzeżenia, a nie zakładać, że wszystko przeszło poprawnie.

5. Mieszanie `product_detail` i `product_highlight`.

Pierwsze pole służy do ustrukturyzowanych specyfikacji, drugie do zwięzłych benefitów.

6. Wpisywanie dowolnych certyfikatów do `certification`.

To pole ma ścisłą specyfikację. Jeśli nie pasuje do wspieranego formatu, lepiej go nie używać.

7. Zbyt rzadkie odświeżanie danych o dostępności.

Jeśli stan magazynowy rotuje szybko, feed aktualizowany raz w tygodniu będzie wprowadzał użytkownika w błąd.

Co dalej

Jeśli chcesz przygotować feed pod AI shopping, nie zaczynaj od pełnej przebudowy całego katalogu. Zacznij od jednej kategorii, w której decyzja zakupowa zależy od kontekstu: odzieży outdoorowej, dziecięcej, elektroniki albo produktów z wieloma wariantami. Tam najłatwiej zobaczysz, czy dodatkowe dane naprawdę poprawiają jakość dopasowania.

Na najbliższy miesiąc wystarczą trzy ruchy:

1. Zrób audit obecnego feeda na poziomie 20-50 kluczowych SKU.

2. Uzupełnij `product_highlight` i `product_detail` tam, gdzie produkt potrzebuje kontekstu użycia.

3. Popraw grupowanie wariantów oraz dane o dostawie.

To nie jest projekt „wszystko albo nic”. Dobrze opisane 20% katalogu zwykle da więcej niż powierzchowny enrichment całego feeda.

FAQ

Czy rozszerzenie feeda wymaga zmian w kodzie sklepu?

Nie zawsze. Część rzeczy ustawisz regułami i konfiguracją w Merchant Center. Jeśli chcesz wzbogacić feed o nowe pola z CMS, ERP albo PIM, zwykle potrzebujesz zmiany w eksporcie lub integracji.

Jak długo trwa pojawienie się zmian w Merchant Center?

Pierwsze zmiany i błędy często widać w ciągu 24-48 godzin, ale pełna ponowna weryfikacja problemów produktowych może potrwać 3-5 dni roboczych, a przy bardziej złożonych kwestiach dłużej.

Czy te atrybuty wpływają na kampanie Performance Max?

Pośrednio tak, bo PMax korzysta z danych produktowych z Merchant Center. Im lepiej opisany produkt, tym więcej jakościowych sygnałów dostaje automatyzacja. Nie znalazłem jednak aktualnego źródła Google, które nazywa `product_highlight` osobnym ranking factor dla PMax, więc lepiej tego tak nie formułować.

Co zrobić, jeśli mój feed generuje się z ERP i nie mogę tam dodać nowych pól?

Sprawdź supplemental data source w Merchant Center. To uzupełniające źródło danych, które pozwala wzbogacić istniejące produkty bez przebudowy głównego eksportu: Create a product data source.

Czy warto rozszerzać feed przy małym katalogu, do 500 produktów?

Tak. Mały katalog bywa łatwiejszy do dopracowania, bo możesz ręcznie podnieść jakość najważniejszych SKU zamiast budować od razu rozbudowaną automatyzację.