Kiedy klient pyta asystenta AI o „ciche buty do biegania po asfalcie do 500 zł”, model nie ogląda Twojej karty produktu. Sięga po dane ustrukturyzowane: feed, API sklepu albo informacje wydobyte z kodu strony. Jeśli feed nie zawiera atrybutu o poziomie tłumienia, przeznaczeniu nawierzchni i realnej dostępności rozmiaru, produkt po prostu nie wejdzie do zestawu kandydatów. To zmienia priorytety pracy nad danymi produktowymi: feed przestaje być plikiem dla porównywarki, a staje się interfejsem dla maszyny, która rekomenduje. Szerszy kontekst tej zmiany opisaliśmy w przewodniku o przygotowaniu sklepu na agentic commerce, tutaj schodzimy poziom niżej: do pól, jakości i harmonogramu.
Feed dla porównywarki a feed dla agenta
Klasyczny feed zakupowy powstawał pod dopasowanie po zapytaniu i cenie. Liczyły się tytuł, cena, dostępność i obrazek, bo decyzję podejmował człowiek patrzący na siatkę wyników. Agent AI działa inaczej. Najpierw rozkłada zapytanie na warunki (przeznaczenie, budżet, ograniczenia, termin dostawy), potem szuka produktów, które te warunki spełniają w sposób możliwy do zweryfikowania, a na końcu buduje uzasadnienie rekomendacji. Każdy z tych trzech kroków karmi się innym rodzajem danych.
Konsekwencja jest prosta: feed pod agenta musi zawierać atrybuty rozstrzygające, nie tylko identyfikacyjne. Porównywarka pokaże dziesięć par butów i pozwoli użytkownikowi wybrać. Agent musi odrzucić osiem z nich, zanim cokolwiek pokaże, a odrzuca na podstawie tego, co ma w danych. Brak atrybutu jest traktowany jak brak cechy, nie jak niewiadoma.
Druga różnica dotyczy zaufania. Model, który raz zarekomendował produkt niedostępny albo w złej cenie, dostaje sygnał zwrotny z koszyka lub z checkoutu. Świeżość danych przestaje być kwestią higieny, a staje się warunkiem uczestnictwa w kanale.
Pola obowiązkowe i pola, które robią różnicę
Podstawa nie zmieniła się od lat i jest dobrze udokumentowana w specyfikacji danych produktowych Google Merchant Center: identyfikator, tytuł, opis, link, obrazek, cena, dostępność, marka, GTIN, MPN, stan. Bez tego zestawu produkt nie istnieje w żadnym kanale. Różnicę robią jednak pola, które większość sklepów zostawia pustymi.
| Grupa pól | Przykłady | Do czego używa ich agent |
|---|---|---|
| Identyfikacja | id, gtin, mpn, brand | Łączenie ofert tego samego produktu między sklepami |
| Handlowe | price, sale_price, availability, shipping, return_policy | Filtrowanie po budżecie i terminie, ocena ryzyka zakupu |
| Rozstrzygające | material, size_system, age_group, klasa energetyczna, atrybuty własne | Odsiew kandydatów na etapie warunków zapytania |
| Kontekstowe | product_highlight, product_detail, kategoria własna | Budowa uzasadnienia rekomendacji i porównań |
Pola typu product_detail są niedoceniane, bo nie wpływają bezpośrednio na wyświetlenie reklamy. Dla agenta to jedyne miejsce, w którym cecha produktu występuje jako para nazwa i wartość, czyli w formie, którą da się porównać między ofertami bez parsowania prozy. Jeśli sprzedajesz sprzęt, w którym decyduje parametr (pojemność, moc, zasięg, klasa szczelności), przeniesienie tych parametrów z opisu do ustrukturyzowanych par jest najtańszą pojedynczą zmianą, jaką możesz zrobić w feedzie.
Warto też zadbać o spójność feedu z danymi w kodzie strony. Model, który pobiera kartę produktu bezpośrednio, czyta dane strukturalne w JSON-LD, a rozbieżność między ceną w feedzie a ceną w schema.org/Product jest czytelnym sygnałem, że źródłu nie można ufać.
Identyfikatory produktu i warianty
Najwięcej szkód w dużych katalogach robi zła obsługa wariantów. Reguła jest jedna: każdy wariant kupowalny osobno to osobny wiersz w feedzie z własnym id i własnym stanem magazynowym, powiązany z rodzeństwem przez item_group_id. Sklepy, które wystawiają jeden wiersz na model i deklarują dostępność, jeśli istnieje jakikolwiek rozmiar, generują rekomendacje, których nie da się zrealizować.
Druga sprawa to stabilność identyfikatorów. Jeśli id zmienia się przy każdej migracji albo przy zmianie kategorii, tracisz całą historię, którą zewnętrzne systemy zbudowały wokół tego produktu. Identyfikator powinien być pochodną SKU, nigdy pochodną ścieżki URL czy nazwy handlowej.
GTIN wciąż bywa traktowany jako pole opcjonalne. W praktyce to podstawowy klucz łączenia tej samej oferty między sklepami, recenzjami i bazami producentów. Produkt bez GTIN ma mniejszą szansę na to, że zewnętrzne opinie zostaną przypisane właśnie do niego, a to wprost przekłada się na siłę rekomendacji.
Opisy: długość, struktura, atrybuty
Opis w feedzie ma inne zadanie niż opis marketingowy na stronie. Model nie potrzebuje obietnicy, potrzebuje faktów w kolejności od najbardziej rozstrzygających. Sprawdza się prosty układ: pierwsze zdanie definiuje, czym produkt jest i dla kogo, kolejne dwa lub trzy podają parametry i ograniczenia, dopiero potem pojawia się kontekst użycia.
Długość między 300 a 700 znaków zwykle wystarcza. Krótsze opisy nie niosą cech, dłuższe zaczynają powtarzać treść z pól strukturalnych i podnoszą ryzyko sprzeczności. Unikaj wrzucania do opisu tabel wymiarów, list kompatybilności i regulaminów dostawy: to materiał na osobne pola albo na kartę produktu, nie na jedno pole tekstowe.
Jeśli chcesz, żeby model cytował Twoją specyfikację dosłownie, pisz zdania samodzielne, które nie wymagają kontekstu poprzedniego akapitu. Ta sama zasada działa poza feedem, w treściach porównawczych i zestawieniach, o czym pisaliśmy przy okazji tabel porównawczych pod AI.
Częstotliwość odświeżania i cena w czasie rzeczywistym
Harmonogram odświeżania powinien wynikać z tego, jak szybko zmienia się dane pole, a nie z tego, kiedy wygodnie uruchomić eksport nocny.
- Cena i dostępność: aktualizacja ciągła lub w oknach 15–60 minut, dla asortymentu promocyjnego częściej.
- Stan magazynowy wariantów: ten sam reżim co cena, bo to najczęstsze źródło nietrafionych rekomendacji.
- Opisy, atrybuty, obrazki: raz na dobę wystarcza, przy dużym katalogu nawet raz na 24–48 godzin.
- Struktura kategorii i mapowania: przy każdej zmianie taksonomii, z pełnym przeładowaniem feedu.
Przy katalogach powyżej kilku tysięcy SKU pełny eksport co godzinę przestaje być realny. Standardem staje się model mieszany: pełny feed raz na dobę plus strumień zmian przyrostowych dla ceny i dostępności. Jeśli platforma udostępnia API stanów magazynowych, warto je wystawić obok feedu, bo agent może zweryfikować dostępność tuż przed rekomendacją.
Pilnuj też zgodności stref czasowych i formatu waluty. Cena zapisana bez waluty albo z separatorem dziesiętnym zależnym od locale to klasyczny powód, dla którego część katalogu wypada z przetwarzania bez żadnego widocznego błędu.
Kontrola jakości danych przy dużym katalogu
Przy dziesiątkach tysięcy SKU ręczna kontrola nie ma sensu. Potrzebny jest zestaw testów uruchamianych przy każdym eksporcie, który zatrzymuje publikację, gdy metryki wyjdą poza próg.
- Kompletność: odsetek wierszy z wypełnionym GTIN, marką i atrybutami rozstrzygającymi dla danej kategorii.
- Spójność: zgodność ceny i dostępności między feedem, stroną produktu i danymi strukturalnymi.
- Stabilność: udział wierszy, którym zmienił się identyfikator względem poprzedniego eksportu (powyżej 1 procent to sygnał alarmowy).
- Rozkład: liczba wariantów na grupę, wykrywanie grup z jednym wariantem tam, gdzie powinno być kilkanaście.
- Duplikaty: ten sam GTIN w wielu grupach produktowych.
Dobrą praktyką jest trzymanie progów w repozytorium obok kodu eksportu i traktowanie ich jak testów jednostkowych. Eksport, który obniża kompletność GTIN z 94 na 71 procent, powinien się nie powieść, zamiast cicho wjechać na produkcję. W projektach ten mechanizm ratuje więcej ruchu niż jakakolwiek optymalizacja tytułów, co widać w analizie indeksacji katalogu 12 tysięcy SKU.
Najczęstsze błędy w feedach
Powtarzalne problemy, które widać w audytach niezależnie od branży:
- Tytuł zbudowany jak nagłówek reklamy zamiast jak nazwa produktu z marką, modelem i kluczowym parametrem.
- Dostępność deklarowana na poziomie modelu, nie wariantu.
- Atrybuty zaszyte w opisie zamiast w polach strukturalnych.
- Różne ceny w feedzie i na stronie po nałożeniu promocji koszykowej.
- Kategoria własna kopiująca strukturę menu sklepu zamiast opisywać typ produktu.
- Obrazki z nałożonymi banerami promocyjnymi, które utrudniają rozpoznanie produktu.
- Feed generowany z cache strony, przez co opóźnienie danych sięga kilkunastu godzin.
Każdy z tych błędów da się wykryć automatycznie, więc nie ma powodu, żeby żyły w katalogu miesiącami. Kolejność naprawy warto ustawić według udziału przychodu w dotkniętych kategoriach, a nie według liczby wierszy. Jeśli planujesz przy okazji porządki w treściach kategorii, pomocna będzie strategia treści w modelu hub and spoke, która porządkuje relacje między stronami kategorii a poradnikami zakupowymi.
Od czego zacząć
Jeśli masz jeden sprint na poprawę feedu, wykorzystaj go tak: najpierw rozbij warianty na osobne wiersze z realnym stanem magazynowym, potem przenieś trzy najważniejsze parametry kategorii z opisu do pól strukturalnych, na końcu wepnij testy kompletności i spójności do procesu eksportu. To kolejność, która daje najwięcej efektu przy najmniejszym ryzyku regresji, bo każdy krok jest odwracalny i mierzalny osobno.
FAQ
Czy feed dla agentów AI to osobny plik?
Zwykle nie. W większości przypadków wystarczy jeden dobrze zbudowany feed produktowy z pełnym zestawem atrybutów oraz spójne dane strukturalne na stronie. Osobny eksport ma sens dopiero wtedy, gdy kanał wymaga własnego schematu pól.
Ile pól powinien mieć feed pod agentów AI?
Nie chodzi o liczbę, tylko o pokrycie cech rozstrzygających w danej kategorii. W praktyce to zestaw obowiązkowy plus od trzech do ośmiu atrybutów, które realnie decydują o wyborze produktu przez klienta.
Jak często odświeżać cenę i dostępność?
Cena i dostępność powinny być aktualizowane w sposób ciągły albo w oknach 15–60 minut. Opisy, atrybuty i obrazki spokojnie wystarczy odświeżać raz na dobę.
Czy brak GTIN dyskwalifikuje produkt?
Nie dyskwalifikuje, ale znacząco osłabia. Bez GTIN trudniej powiązać ofertę z opiniami i danymi producenta, więc produkt ma mniejszą szansę trafić do rekomendacji przy zapytaniach porównawczych.
Co zrobić, gdy platforma nie pozwala dodać własnych atrybutów?
Najprostsze obejście to warstwa pośrednia, która pobiera dane z platformy, wzbogaca je o atrybuty z osobnego źródła i dopiero taki połączony zestaw publikuje jako feed. Rozwiązanie sprawdza się też wtedy, gdy część danych pochodzi z systemu PIM.
Czy dłuższy opis produktu poprawia szanse na rekomendację?
Tylko do momentu, w którym opis niesie nowe fakty. Powyżej tego progu rośnie ryzyko sprzeczności z polami strukturalnymi, a to szkodzi bardziej niż brak kilku zdań.