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: co to za produkt, ile kosztuje, w jakiej walucie i czy jest teraz dostępny. 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 i ten komplet jest identyczny w każdym miejscu, z którego można go odczytać.

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.

Praktycznie: 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 i trzymaj te wartości identyczne w sklepie, feedzie i schema. Czego nie robić: nie wymyślaj kodu, nie kopiuj cudzego i nie używaj ponownie kodu po wycofanym produkcie. 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 jako sama liczba, priceCurrency w kodzie ISO (PLN, EUR), availability zapisana jako pełny adres schema.org, na przykład https://schema.org/InStock albo https://schema.org/OutOfStock, oraz url prowadzący do karty produktu. Pełny URL 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: czy feed zawiera wszystkie produkty, które realnie sprzedajesz, czy pola obowiązkowe są wypełnione dla każdej pozycji i czy dane są w nim tak samo świeże 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. Po pierwsze, system, który znajduje dwie różne ceny tego samego produktu, nie ma powodu uznać akurat Twojej oferty za wiarygodną i taniej mu pominąć niejednoznaczne źródło. Po drugie, 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. 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. I dołóż automatyczne porównanie feedu ze stanem sklepu, uruchamiane po każdej większej aktualizacji cen: prosty raport różnic 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. Zacznij od produktów odpowiadających za większość obrotu i dla nich doprowadź do kompletu cztery pola oferty plus identyfikator. Potem zajmij się wariantami, bo to tam najczęściej gubi się GTIN i dostępność. Dopiero na końcu wchodź w długi ogon, gdzie poprawa jest tania, ale efekt rozłożony w czasie. 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ł.