Dane produktowe: feed i schema jako fundament

Audyt z poprzedniego rozdziału niemal zawsze kończy się tą samą diagnozą: asystent nie tyle nie zna Twojego sklepu, co nie ma skąd wziąć pewnych faktów o jego produktach. Zanim więc zaczniesz planować nowe treści, zamknij lukę u fundamentu. Widoczność sklepu w odpowiedziach AI zaczyna się od danych produktowych, a nie od bloga.

Wg źródeł branżowych rekomendacje zakupowe asystentów opierają się w dużej mierze na ustrukturyzowanych danych produktowych i kompletnym feedzie zakupowym. To znaczy, że katalog opisany dobrze po ludzku, ale słabo po maszynowemu, przegrywa z konkurencją, która podała cenę, walutę, dostępność i identyfikator wprost. Ten rozdział mówi, co konkretnie ustawić i w jakiej kolejności.

Asystent potrzebuje faktu, nie opisu

Model układający rekomendację zakupową musi w jednym kroku ustalić cztery rzeczy:

• Tożsamość: co to za produkt.
• Cena: ile kosztuje.
• Waluta: w jakiej walucie jest podana cena.
• Dostępność: czy jest teraz na stanie.

Zdanie „349 zł w zestawie, ostatnie sztuki, wysyłka jeszcze dziś” jest dla człowieka w pełni czytelne, a dla maszyny to trzy fakty do zinterpretowania i pomylenia. Te same informacje zapisane jako osobne, nazwane pola nie wymagają żadnej interpretacji.

Twoim pierwszym zadaniem nie jest więc lepszy opis, tylko doprowadzenie katalogu do stanu, w którym każdy produkt ma komplet jednoznacznych pól, identyczny w każdym miejscu, z którego można go odczytać.

Czego nie kupisz budżetem

Warto od razu powiedzieć rzecz, która bywa dla zarządu zaskoczeniem: wg źródeł branżowych wydatki reklamowe nie wpływają na to, co asystent rekomenduje. Budżet mediowy kupuje ekspozycję w reklamie, nie miejsce w wygenerowanej odpowiedzi. Dla mniejszego sklepu to dobra wiadomość, bo o wejście do porównania konkuruje się jakością danych, a nie stawką. Dla dużego to wiadomość zła, bo zaniedbanego katalogu nie da się nadrobić budżetem.

GTIN: ten sam produkt w wielu sklepach

GTIN to globalny numer jednostki handlowej ze standardu GS1, w Europie znany najczęściej jako trzynastocyfrowy kod EAN z opakowania (w USA UPC, dla książek ISBN). Ma jedno zadanie: pozwala stwierdzić, że „Sony WH-1000XM5 czarne” z Twojego sklepu i „Słuchawki bezprzewodowe Sony WH1000XM5 Black” z innego to ten sam produkt.

Bez wspólnego identyfikatora system musi porównywać nazwy, a nazwy produktów w eCommerce prawie nigdy się nie pokrywają. Produkt bez GTIN nie jest gorszy, jest tylko trudniejszy do połączenia z resztą rynku, więc łatwiej wypada z zestawienia.

Jak uzupełnić GTIN w praktyce

Uzupełnij GTIN wszędzie tam, gdzie producent go nadał, i podaj go w dwóch miejscach naraz: w feedzie i w danych strukturalnych (pole gtin, dla kodów EAN także gtin13). Identyfikator należy do wariantu, nie do produktu nadrzędnego: każdy rozmiar i kolor ma własny kod.

Przy produktach własnej marki, którym nikt GTIN-u nie nadał, użyj pary brand i mpn plus stabilnego SKU. Trzymaj te wartości identyczne w sklepie, feedzie i schema.

Są trzy rzeczy, których nie wolno robić:

• Nie wymyślaj kodu: GTIN nadaje producent w standardzie GS1.
• Nie kopiuj cudzego: nawet bliźniaczo podobny produkt ma własny numer.
• Nie używaj ponownie kodu po wycofanym produkcie: jeden numer opisuje jedną pozycję handlową.

Błędny identyfikator jest gorszy niż jego brak, bo sklejasz swoją ofertę z zupełnie innym produktem.

Product i Offer: komplet, nie fragment

Po stronie danych strukturalnych fundament tworzą dwa obiekty. Product odpowiada za tożsamość: name, image, brand, sku i gtin oraz opis. Offer odpowiada za decyzję zakupową i musi być kompletny:

• price: sama liczba, bez waluty i bez dopisków.
• priceCurrency: kod ISO waluty, na przykład PLN albo EUR.
• availability: pełny adres schema.org, na przykład https://schema.org/InStock albo https://schema.org/OutOfStock.
• url: adres prowadzący do karty produktu.

Pełny adres zamiast słowa „dostępny” to nie formalność: wskazuje jedno pojęcie ze słownika identycznego dla każdego sklepu na świecie, więc porównanie odbywa się bez tłumaczenia.

Jeśli cena ma termin ważności, dołóż priceValidUntil. Jeśli dostawa i zwroty są u Ciebie argumentem sprzedażowym, opisz je polami oferty, a nie zdaniem w opisie.

Szczegółowy rozkład typów, właściwości i typowych błędów opisaliśmy w tekście o danych strukturalnych pod AI, a gotowy generator JSON-LD dla Product i FAQ znajdziesz w Bibliotece AI. Na potrzeby tego rozdziału wystarczy jedna zasada: jeśli którekolwiek z czterech pól oferty jest puste albo przybliżone, produkt przestaje być policzalny.

Higiena feedu zakupowego

Feed produktowy to ten sam katalog wyeksportowany w formacie, który czytają systemy zewnętrzne. Traktuj go jak produkcyjny interfejs sklepu, a nie jak plik dla działu marketingu. Trzy pytania kontrolne:

• Kompletność: czy feed zawiera wszystkie produkty, które realnie sprzedajesz?
• Wypełnienie pól: czy pola obowiązkowe są uzupełnione dla każdej pozycji?
• Świeżość: czy dane w feedzie są tak samo aktualne jak na stronie?

Poniżej defekty, które w praktyce najczęściej wypychają produkt z porównania.

Defekty ułożone od pojedynczego produktu do spójności całego katalogu. Nazwy pól podane tak, jak zapisujesz je w danych strukturalnych i feedzie.

Spójność jako warunek zaufania

Te same fakty pojawiają się w trzech miejscach: na stronie, w danych strukturalnych i w feedzie. Muszą zgadzać się co do złotówki i co do statusu. Sprzeczność ma dwie konsekwencje i obie są kosztowne:

• Utrata wiarygodności: system, który znajduje dwie różne ceny tego samego produktu, nie ma powodu uznać akurat Twojej oferty za wiarygodną, a pominięcie niejednoznacznego źródła jest dla niego tańsze.
• Ryzyko kary: rozjazd między JSON-LD a tym, co widzi użytkownik, to wprost spam danych strukturalnych i realne ryzyko ręcznego działania Google, czyli utraty widoczności także w klasycznych wynikach.

Nagrodą za spójność nie jest bonus, tylko brak kary i możliwość wejścia do porównania.

Wdrożeniowo sprowadza się to do dwóch decyzji:

• Jedno źródło pól: generuj JSON-LD z tych samych pól, z których renderuje się widok karty produktu, zamiast utrzymywać osobny szablon z wartościami wpisywanymi ręcznie.
• Automatyczny raport różnic: po każdej większej aktualizacji cen porównuj feed ze stanem sklepu. Prosty raport dla ceny, dostępności i identyfikatora wystarczy, żeby złapać większość rozjazdów, zanim zrobi to za Ciebie system zewnętrzny.

Od czego zacząć przy dużym katalogu

Nie porządkuj katalogu alfabetycznie ani od pierwszej kategorii w menu. Kolejność jest inna:

• Produkty z większością obrotu: dla nich doprowadź do kompletu cztery pola oferty plus identyfikator.
• Warianty: to tam najczęściej gubi się GTIN i dostępność.
• Długi ogon: poprawa jest tania, ale efekt rozłożony w czasie, więc wchodzi na końcu.

Kolejność ma znaczenie, bo pierwsze dwa kroki obejmują zwykle niewielką część indeksu i dają się zrobić w kilka dni, a nie w kwartał.

Dane produktowe same z siebie nie sprawią, że asystent poleci Twój sklep; niczego takiego nikt nie gwarantuje i warto odrzucać oferty, które to obiecują. Sprawiają natomiast, że Twoja oferta jest policzalna i porównywalna, a to warunek wstępu do jakiejkolwiek rekomendacji. Dopiero na tym fundamencie ma sens praca nad treścią, którą model może zacytować, i o tym jest kolejny rozdział.