Jeszcze dwa lata temu feed produktowy był plikiem technicznym, którym zajmował się jeden specjalista od kampanii zakupowych. Dziś ten sam plik decyduje o czymś znacznie większym: czy asystent AI w ogóle zobaczy twój produkt, gdy użytkownik napisze „znajdź mi buty trailowe do 600 zł z dobrą amortyzacją”. Agent nie otwiera karty produktu, nie ogląda zdjęć i nie czyta nagłówka H1. Czyta dane. Jeśli dane są ubogie, produkt po prostu nie wchodzi do puli kandydatów.
Ten tekst rozkłada feed na czynniki pierwsze pod kątem rekomendacji AI. Jest częścią szerszego materiału o tym, jak przygotować sklep na zakupy realizowane przez AI, więc jeśli dopiero zaczynasz porządkować temat, zacznij od tamtej całości i wróć tutaj po szczegóły.
Dlaczego feed jest teraz interfejsem sklepu dla AI
Model językowy pracujący w trybie zakupowym potrzebuje danych, które da się porównać między sklepami. Opis marketingowy na stronie tego nie zapewnia, bo każdy sklep pisze go inaczej. Feed zapewnia, bo ma ustalone pola o ustalonym znaczeniu. To właśnie dlatego kanały zakupowe w asystentach budowane są na feedach, a nie na scrapowaniu HTML. Widać to po kierunku, w którym idą platformy: OpenAI uruchomił kanały produktowe, do których sprzedawcy wgrywają feed, a Google od dawna karmi swoje systemy AI tym samym plikiem, którym karmi kampanie.
Praktyczny wniosek jest prosty. Feed przestał być kanałem reklamowym, a stał się reprezentacją twojego asortymentu w świecie maszyn. Jeśli produkt nie istnieje w feedzie albo istnieje w wersji okrojonej, dla agenta jest niekompletny i przegrywa z ofertą konkurenta, która ma komplet atrybutów.
Pola obowiązkowe kontra pola, które realnie różnicują
Większość sklepów zatrzymuje się na polach wymaganych przez walidator: identyfikator, tytuł, opis, link, obrazek, dostępność, cena. To wystarcza, żeby feed przeszedł weryfikację, ale nie wystarcza, żeby wygrać rekomendację. Walidator sprawdza poprawność formalną, a model porównuje treść.
Warto rozdzielić te dwie grupy w głowie i w harmonogramie wdrożenia:
| Grupa | Pola | Co daje |
|---|---|---|
| Wymagane | id, title, description, link, image_link, price, availability | Obecność w kanale, nic ponadto |
| Różnicujące | gtin, mpn, brand, item_group_id, color, size, material, product_highlight, shipping, product_detail | Trafność dopasowania i przewaga w porównaniach |
Pola różnicujące odpowiadają na pytania, które użytkownik faktycznie zadaje asystentowi: z jakiego materiału, w jakim rozmiarze, ile czekam na dostawę, czym to się różni od modelu obok. Jeśli feed na te pytania nie odpowiada, model albo pominie produkt, albo opisze go ogólnikami, co w praktyce oznacza to samo.
GTIN, MPN i identyfikatory: dlaczego ich brak boli
GTIN to globalny numer handlowy, czyli kod, po którym ten sam produkt można rozpoznać w dziesiątkach sklepów. Dla agenta AI jest to najtańszy sposób na sklejenie ofert i zbudowanie porównania cenowego. Bez GTIN twoja oferta jest osobnym bytem, którego nie da się zestawić z niczym innym, więc wypada z porównań, w których użytkownik pyta o najlepszą cenę lub najszybszą dostawę.
MPN, czyli numer katalogowy producenta, pełni podobną funkcję tam, gdzie GTIN nie występuje, na przykład w częściach zamiennych i produktach niszowych. Marka w polu brand domyka układankę, bo sama para MPN i brand pozwala jednoznacznie zidentyfikować pozycję. Zasada praktyczna: uzupełnij GTIN wszędzie, gdzie producent go nadaje, a tam gdzie nie nadaje, konsekwentnie wypełniaj MPN plus brand. Definicję i strukturę samego kodu opisuje hasło o Global Trade Item Number, warto do niego zajrzeć, jeśli w firmie trwa spór, co właściwie wpisywać.
Jedno zastrzeżenie: pusty GTIN jest lepszy niż zmyślony. Błędny identyfikator sklei twoją ofertę z cudzym produktem i wygenerujesz rekomendacje dla czegoś, czego nie sprzedajesz.
Warianty, rozmiary i kolory bez duplikacji ofert
Najczęstszy błąd w feedach modowych i wyposażenia wnętrz to traktowanie każdego wariantu jako osobnego, niepowiązanego produktu. Powstaje wtedy dwanaście ofert tej samej koszulki, które konkurują ze sobą i rozmywają sygnał. Agent widzi dwanaście podobnych pozycji, nie potrafi zdecydować, którą pokazać, i najczęściej nie pokazuje żadnej.
Rozwiązaniem jest item_group_id. Wszystkie warianty jednego modelu dostają identyczną wartość w tym polu, a różnią się w polach wariantowych: color, size, material, pattern. Dzięki temu model rozumie strukturę: jeden produkt, wiele opcji. Kiedy użytkownik pyta o rozmiar 42 w kolorze czarnym, agent trafia w konkretny wariant, zamiast losować z listy klonów.
Wartości w polach wariantowych trzymaj w słowniku kontrolowanym. „Czarny”, „czarne”, „black” i „czarny mat” to dla systemu cztery różne kolory, a to psuje filtrowanie po stronie asystenta.
Opisy w feedzie: długość, fakty, jednostki
Opis w feedzie ma inne zadanie niż opis na stronie. Na stronie sprzedajesz emocją, w feedzie dostarczasz faktów do porównania. Model nagradza konkret: wymiary z jednostkami, wagę, pojemność, skład, zakres temperatur, standardy i certyfikaty. Karze ogólniki w rodzaju „najwyższa jakość” i „idealny na każdą okazję”, bo nie da się ich zweryfikować ani zestawić z ofertą obok.
Praktyczne ramy, które sprawdzają się w większości kategorii:
- Pierwsze zdanie mówi wprost, czym produkt jest i dla kogo, bez metafor.
- Parametry liczbowe zawsze z jednostką (350 g, 24 cm, 40 l, IP67), nigdy jako gołe liczby.
- Długość w przedziale 300–800 znaków, bo krótsze opisy nie niosą treści, a dłuższe rozmywają kluczowe fakty.
- Zero HTML, zero powtórzonego tytułu, zero informacji o promocji, która wygaśnie za tydzień.
Osobno warto wypełnić product_highlight, jeśli kanał je obsługuje. To krótkie punkty, z których modele chętnie budują listy zalet w odpowiedziach.
Dostępność i czas dostawy jako sygnał rekomendacji
Asystent zakupowy odpowiada na pytania osadzone w czasie: „co dostanę przed piątkiem”. Dlatego availability i dane wysyłkowe przestały być kosmetyką. Produkt oznaczony jako dostępny, który w rzeczywistości jest na zamówienie, generuje złe rekomendacje i szybko obniża zaufanie kanału do całego twojego feedu.
Trzy rzeczy warto ustawić porządnie. Po pierwsze, częstotliwość aktualizacji: przy rotującym asortymencie raz na dobę to za rzadko, celuj w aktualizacje przyrostowe co kilka godzin. Po drugie, shipping z realnym kosztem i regionem zamiast jednej uśrednionej wartości. Po trzecie, czas przygotowania i czas transportu podawane osobno, bo agent sumuje je, żeby oszacować datę doręczenia.
Ten sam komplet danych pracuje potem w kampaniach, co dobrze widać w materiale o tym, jak działa Performance Max na feedzie pod AI. Jedna porządna warstwa danych obsługuje oba światy, więc nie buduj dwóch osobnych pipeline’ów.
Atrybuty niestandardowe: kiedy warto je dodać
Pola niestandardowe (w Google Merchant Center są to etykiety niestandardowe i product_detail) kuszą, bo można w nie wrzucić wszystko. To zła strategia. Dodawaj je wtedy, gdy spełniają jeden z trzech warunków: opisują cechę, o którą klienci realnie pytają, pozwalają segmentować asortyment do reguł biznesowych, albo niosą parametr specyficzny dla kategorii, dla którego nie ma pola standardowego.
Dobre przykłady to zakres wieku dla zabawek, moc silnika dla narzędzi, kompatybilność z konkretnym modelem urządzenia, klasa energetyczna. Złe przykłady to wewnętrzne kody magazynowe, notatki działu zakupów i pola techniczne twojego ERP. Wszystko, co dodajesz, powinno dawać się nazwać po ludzku, bo tak trafi do odpowiedzi modelu.
Warto też zadbać o spójność z danymi na stronie. Jeśli feed mówi 350 g, a karta produktu mówi 380 g, model widzi sprzeczność i traci pewność co do całej oferty. Struktura danych w HTML powinna odzwierciedlać feed, a nie żyć własnym życiem, i tu pomaga trzymanie się słownika schema.org/Product.
Jak testować feed przed wdrożeniem
Testowanie feedu pod AI różni się od zwykłej walidacji. Walidator powie ci, czy plik jest poprawny. Nie powie, czy jest użyteczny. Kolejność, która działa:
- Walidacja techniczna w narzędziu kanału, do zera błędów krytycznych i ostrzeżeń dotyczących identyfikatorów.
- Audyt pokrycia: policz, jaki procent ofert ma GTIN,
item_group_id, opis dłuższy niż 300 znaków i wypełnione pola wariantowe. Poniżej 90 procent pokrycia masz problem systemowy, nie wyjątki. - Test na próbce: weź 20 losowych produktów i sprawdź, czy z samych danych feedu da się odpowiedzieć na pięć typowych pytań klienta. Jeśli nie da się, brakuje pola.
- Test spójności: porównaj feed z kartą produktu dla tej samej próbki, szukając rozjazdów w cenie, dostępności i parametrach.
- Test w praktyce: zapytaj asystenta o kategorię i sprawdź, czy i jak opisuje twoje produkty.
Ostatni punkt najczęściej wypada z procesu, a jest najbardziej informacyjny. Jak podejść do niego metodycznie, opisujemy w poradniku o tym, jak sprawdzić czy ChatGPT poleca twoją stronę. Ta sama metoda działa na produktach, wystarczy zmienić pytania na zakupowe.
Na koniec rzecz organizacyjna. Feed jest produktem, nie plikiem, więc potrzebuje właściciela i cyklu przeglądów. Kwartalny audyt pokrycia atrybutów wyłapuje regresje, które wchodzą razem z nowymi kolekcjami i zmianami w ERP, zanim odbiją się na widoczności.
FAQ
Czy feed produktowy wystarczy, żeby AI polecało moje produkty?
Nie wystarczy sam, ale bez niego reszta nie zadziała. Feed daje agentowi porównywalne dane, a karta produktu i dane strukturalne w HTML potwierdzają je i uzupełniają o kontekst. Traktuj te warstwy jako jeden system, w którym wartości muszą się zgadzać.
Co zrobić, gdy producent nie nadaje GTIN?
Wypełnij konsekwentnie MPN oraz brand i oznacz brak identyfikatora zgodnie ze specyfikacją kanału. Nie wymyślaj kodów i nie kopiuj cudzych, bo błędny GTIN sklei twoją ofertę z innym produktem i zepsuje rekomendacje.
Jak długi powinien być opis w feedzie?
W większości kategorii 300–800 znaków. Krótsze opisy nie niosą faktów potrzebnych do porównania, dłuższe rozmywają kluczowe parametry. Ważniejsza od długości jest gęstość konkretów: wymiary, waga, skład i jednostki.
Czy warianty produktu powinny być osobnymi ofertami?
Tak, ale muszą być powiązane wspólnym item_group_id. Wtedy każdy rozmiar i kolor jest osobno kupowalny, a system rozumie, że to jeden model w kilku opcjach. Bez tego pola powstają duplikaty, które konkurują ze sobą.
Jak często aktualizować feed?
Przy stabilnym asortymencie wystarczy raz na dobę. Przy szybkiej rotacji cen i stanów magazynowych potrzebujesz aktualizacji przyrostowych co kilka godzin, bo błędna dostępność to najszybszy sposób na utratę zaufania kanału.
Które pole daje największy przyrost widoczności przy najmniejszym nakładzie?
Najczęściej item_group_id w sklepach z wariantami oraz GTIN w sklepach z asortymentem markowym. Oba są zwykle dostępne w ERP, a ich uzupełnienie porządkuje strukturę całego katalogu.