Optymalizacja katalogu PrestaShop: kategorie, atrybuty i nawigacja fasetowa

Optymalizacja katalogu PrestaShop zaczyna się od rozstrzygnięcia, które nic nie kosztuje, a decyduje o wszystkim później: co w Twoim sklepie jest kategorią, co atrybutem, a co cechą produktu. PrestaShop traktuje te trzy byty zupełnie inaczej, a konsekwencje wyboru ciągną się przez filtry, stany magazynowe, eksporty do porównywarek i każdą kolejną integrację. Sklepy, w których ten podział ustalono przypadkiem, płacą za to latami.

Ten tekst pokazuje, jak uporządkować katalog w działającym sklepie, bez przenoszenia go na nową platformę i bez zatrzymywania sprzedaży na czas prac.

Kategoria, atrybut, cecha: trzy byty, które łatwo pomylić

PrestaShop rozdziela sposoby opisywania produktu i każdy z nich służy do czegoś innego. Rozróżnienie brzmi technicznie, ale przekłada się wprost na to, co widzi klient i co da się później zautomatyzować.

Reguła, która rozstrzyga większość wątpliwości: jeśli klient wybiera wartość na karcie produktu przed dodaniem do koszyka, to atrybut. Jeśli wartość jest stała i służy do porównania albo do zawężania listingu, to cecha. Jeśli klient szuka po tym w menu, to kategoria.

Rozmiar w odzieży jest atrybutem, bo klient go wybiera i każdy rozmiar ma osobny stan magazynowy. Materiał jest cechą, bo koszula z bawełny to inny produkt niż koszula z lnu, a nie inny wariant tego samego. Marka bywa jednym i drugim, i tu popełnia się najwięcej błędów: producent ma w PrestaShop własny byt z własnym listingiem i własnym adresem, więc dublowanie go jako cechy tworzy dwie ścieżki do tego samego zbioru produktów.

Koszt pomyłki

Kolor zapisany jako cecha zamiast atrybutu oznacza, że sklep nie zna stanu magazynowego dla poszczególnych kolorów. Zamówienia na wyczerpany wariant przechodzą, obsługa dzwoni do klientów, a stany w systemie ERP przestają zgadzać się ze sklepem. Odwrotna pomyłka też boli: pojemność opakowania zapisana jako atrybut mnoży kombinacje, przez co listing produktów w panelu staje się nieczytelny, a eksport do porównywarek generuje warianty, których nie da się rozróżnić po nazwie.

Poprawianie tego na działającym sklepie jest wykonalne, ale wymaga kolejności: najpierw nowa struktura na środowisku testowym, potem migracja danych z zachowaniem powiązań z zamówieniami historycznymi, na końcu przekierowania ze starych adresów. Nie jest to operacja, którą robi się w piątek po południu.

Drzewo kategorii: głębokość kontra szerokość

Drzewo kategorii narasta warstwami. Ktoś dokłada podkategorię pod kampanię sezonową, ktoś inny pod nowego dostawcę, a po dwóch latach sklep ma pięć poziomów zagnieżdżenia i kategorie, w których leży po jednym produkcie.

Dwa objawy, po których poznasz, że drzewo wymaga uwagi:

• Kategorie-sieroty. Zawierają jeden produkt albo żadnego. Zaśmiecają menu, generują cienkie listingi i trafiają do mapy strony jako adresy bez treści.
• Zagnieżdżenie ponad cztery poziomy. Klient przestaje wiedzieć, gdzie jest, okruszki nawigacji rozjeżdżają się na telefonie, a produkt oddala się od strony głównej na tyle, że traci na widoczności.

Porządkowanie polega zwykle na spłaszczeniu drzewa i przeniesieniu części rozróżnień do filtrów. Kategoria „Buty damskie zimowe skórzane” opisuje trzy zawężenia naraz i ma sens tylko wtedy, gdy klienci realnie tak szukają. W większości sklepów wystarczy kategoria „Buty damskie” plus filtry sezonu i materiału, bo to daje te same wyniki bez mnożenia adresów.

Przy każdej zmianie w drzewie pilnujesz dwóch rzeczy: okruszków nawigacji, które budują orientację klienta i strukturę dla wyszukiwarek, oraz przekierowań ze starych adresów kategorii. Rola samych okruszków opisana jest w tekście o breadcrumbs w sklepie internetowym.

Nawigacja fasetowa: gdzie filtry zaczynają kosztować

Nawigacja fasetowa jest w PrestaShop mechanizmem, który zamienia atrybuty i cechy w filtry na listingu. Działa dobrze do momentu, w którym liczba kombinacji zaczyna rosnąć szybciej niż katalog.

Problem ma dwie twarze. Pierwsza jest widoczna dla klienta: filtry, które prowadzą do pustych wyników. Klient zaznacza rozmiar i kolor, dostaje komunikat o braku produktów i wychodzi, choć w sklepie są rzeczy, które by kupił. Druga twarz jest niewidoczna: każde zapytanie filtrujące obciąża bazę, a przy dużym katalogu i wielu atrybutach listing zaczyna generować zapytania, które trwają dłużej niż cała reszta strony.

Co z tym zrobić

Zacznij od ograniczenia liczby filtrów do tych, których klienci używają. Dane masz w analityce: filtry, które nie są klikane, wydłużają listę i obciążają zapytania, nie dając nic w zamian. Trzy filtry, po których klienci realnie zawężają wybór, są warte więcej niż dwanaście teoretycznie użytecznych.

Drugi krok to ukrywanie wartości, które w danej kategorii nie występują. Filtr rozmiaru butów na listingu kategorii z torebkami nie ma po co się pokazywać, a PrestaShop pozwala przypisywać zestawy filtrów do konkretnych kategorii.

Trzeci to rozstrzygnięcie, co robić z adresami wyników filtrowania. Domyślnie każda kombinacja filtrów tworzy adres, który wyszukiwarka może zaindeksować. Przy czterech filtrach po pięć wartości daje to setki adresów z niemal identyczną treścią. Zwykle indeksujemy pojedyncze, wartościowe zawężenia, na które są realne wyszukiwania, a resztę zamykamy. Temat rozwijamy w tekście o optymalizacji SEO PrestaShop.

Jeśli po tych trzech krokach listing nadal jest wolny, przyczyna leży w warstwie danych i serwera, nie w konfiguracji filtrów. Tym zajmujemy się w ramach optymalizacji wydajności PrestaShop.

Jakość danych produktowych: pole, które decyduje o filtrze

Najlepiej zaprojektowany filtr nie zadziała, jeśli dane pod nim są niespójne. Typowy katalog po kilku latach ma kolor zapisany jako „czarny”, „Czarny”, „black” i „czarny mat”, i wszystkie cztery są dla PrestaShop osobnymi wartościami. Filtr pokazuje cztery pozycje, klient zaznacza jedną i widzi ćwierć produktów, które powinien zobaczyć.

Źródło rozjazdu jest zwykle to samo: dane wpływają do sklepu z kilku miejsc naraz. Część produktów wprowadza zespół ręcznie, część przychodzi plikiem od dostawcy, część z systemu ERP. Każde źródło ma własną konwencję, a sklep przyjmuje wszystkie.

Doraźnie porządkuje się to scaleniem wartości i regułą nazewnictwa spisaną tam, gdzie zespół realnie zajrzy. Docelowo problem rozwiązuje się piętro wyżej, przez centralne zarządzanie danymi produktowymi, gdzie wartości słownikowe są ustalone raz, a sklep jest tylko odbiorcą. Ten kierunek opisujemy przy okazji integracji Akeneo z PrestaShop.

Pola, które warto sprawdzić w pierwszej kolejności

• Nazwa produktu. Czy zawiera to, czego klienci szukają, i czy konwencja jest wspólna dla całego katalogu. Nazwa jest jednocześnie tytułem strony i głównym polem indeksu wyszukiwarki.
• Referencja i symbol producenta. Klienci B2B wpisują je do wyszukiwarki wprost. Puste pole referencji to utracone trafienia.
• Krótki opis. Pojawia się na listingu i w podglądach. Skopiowany z opisu długiego zamienia listing w ścianę tekstu.
• Zdjęcie główne. Brakujące albo w innym kadrze niż reszta psuje listing bardziej niż jakikolwiek błąd konfiguracji.
• Dostępność i termin wysyłki. Produkt bez tej informacji przenosi decyzję klienta na później, a „później” oznacza inny sklep.

Zdjęcia i opisy: warstwa, która decyduje na listingu

Listing kategorii jest ekranem, na którym klient podejmuje decyzję w kilka sekund, a materiał, na podstawie którego ją podejmuje, sprowadza się do zdjęcia, nazwy i ceny. Dwa z tych trzech elementów pochodzą z katalogu i oba bywają zaniedbane.

Kadr i tło zdjęcia głównego. Produkty fotografowane w różnych kadrach dają listing, który wygląda na niedokończony, nawet jeśli każde zdjęcie z osobna jest dobre. Przy zdjęciach od kilku dostawców to stan domyślny. Ujednolicenie kadru i tła dla produktów w jednej kategorii zmienia odbiór listingu mocniej niż jakakolwiek zmiana w układzie strony.

Proporcje i rozmiar plików. PrestaShop generuje miniatury w zdefiniowanych rozmiarach, ale robi to na podstawie oryginału. Zdjęcia wgrywane w rozdzielczości aparatu obciążają serwer przy każdym przeliczeniu miniatur i zajmują miejsce, a widoczna korzyść pojawia się dopiero przy powiększeniu na karcie produktu. Ustal jeden rozsądny rozmiar oryginału i trzymaj się go przy imporcie.

Tekst alternatywny. Opisuje zdjęcie osobom korzystającym z czytników ekranu i wyszukiwarkom. PrestaShop pozwala go uzupełnić przy każdym obrazie, a przy imporcie da się go wygenerować z nazwy produktu. Puste pole to strata bez żadnej rekompensaty.

Przy opisach obowiązuje jedna zasada praktyczna: krótki opis służy listingowi, długi karcie produktu, i nie powinny być tym samym tekstem. Skopiowanie długiego opisu do pola krótkiego zamienia listing w ścianę tekstu, w której zdjęcia przestają się wyróżniać.

Produkty niedostępne i wycofane

Katalog rośnie także w dół: produkty schodzą z oferty, dostawca wycofuje serię, model dostaje następcę. Sklepy rzadko mają ustaloną zasadę, co się wtedy dzieje, i to widać.

Trzy scenariusze i konsekwencje każdego z nich:

Najczęstszy błąd to usunięcie produktu bez przekierowania. Adres, który zbierał ruch z wyszukiwarek przez dwa lata, zaczyna zwracać 404, klient trafia na komunikat o błędzie zamiast na zamiennik, a sklep traci sprzedaż, o której nikt się nie dowie, bo nie pojawi się w żadnym raporcie.

Osobnego rozstrzygnięcia wymagają produkty chwilowo niedostępne. PrestaShop pozwala zdecydować, czy przy braku stanu magazynowego dopuszczać zamówienia, i ta decyzja powinna zależeć od produktu, nie od globalnego ustawienia. Towar wracający na magazyn co tydzień można sprzedawać w przedsprzedaży, o ile klient widzi termin. Towar sprowadzany na zamówienie wymaga innej komunikacji, a produkt wycofany nie powinien dawać się zamówić w ogóle.

Warto też ustawić powiadomienie o powrocie produktu na magazyn. To najprostszy sposób, żeby wizyta zakończona brakiem dostępności nie była wizytą straconą, i jednocześnie źródło danych o tym, na które produkty jest popyt przewyższający zaopatrzenie.

Optymalizacja katalogu PrestaShop krok po kroku na działającym sklepie

Katalog obsługuje sprzedaż codziennie, więc porządki prowadzi się przyrostowo. Kolejność, która sprawdza się w sklepach z historią:

1. Inwentaryzacja. Eksport listy kategorii z liczbą produktów, listy atrybutów i cech z liczbą wartości, listy produktów bez zdjęcia i bez referencji. Cztery pliki, jedno popołudnie.
2. Decyzje na papierze. Docelowe drzewo kategorii i docelowy słownik atrybutów. To jest moment na spory, nie w trakcie wdrażania zmian.
3. Scalanie wartości. Ujednolicenie zapisów w atrybutach i cechach. Zmiana niewidoczna dla klienta, a naprawiająca filtry od ręki.
4. Zmiany w drzewie. Kategoria po kategorii, każda z przekierowaniem ze starego adresu. Po każdej partii sprawdzasz raport błędów 404.
5. Przegląd filtrów. Dopiero po uporządkowaniu danych, bo wcześniej filtrujesz bałagan.
6. Zasada na przyszłość. Spisana konwencja nazewnictwa i wskazana osoba, która akceptuje nowe atrybuty. Bez tego wracasz do punktu wyjścia w rok.

Zmiany struktury katalogu wykonuj na kopii sklepu, a nie na produkcji. Dotyczy to zwłaszcza konwersji cech na atrybuty, bo operacja dotyka kombinacji i powiązań z zamówieniami historycznymi. Zasady pracy z danymi produktowymi i strukturę encji opisuje dokumentacja deweloperska PrestaShop.

Co sprawdzić po zmianach

Lista kontrolna po każdej partii zmian w katalogu, wykonalna w kwadrans:

• raport błędów 404 nie rośnie, a nowe pozycje mają przekierowania
• trzy najczęściej odwiedzane listingi zawężają się do rozsądnej liczby produktów w dwóch kliknięciach
• żaden filtr nie prowadzi do pustego wyniku na kategoriach, do których jest przypisany
• mapa strony nie zawiera kategorii bez produktów
• eksport do porównywarek i do systemu ERP przechodzi bez błędów walidacji
• okruszki nawigacji na karcie produktu pokazują ścieżkę, która ma sens

Uporządkowany katalog jest warunkiem sensownego działania wyszukiwarki wewnętrznej i podstawą, na której opiera się cała reszta prac. Filtr działa na wartościach atrybutów, indeks wyszukiwania buduje się z pól produktu, a eksport do porównywarek i do systemu ERP czyta dokładnie te same dane. Bałagan w jednym miejscu ujawnia się we wszystkich trzech naraz, zwykle w odstępie tygodni, więc trudno połączyć objawy z przyczyną.

Praktyczny wniosek na koniec: katalog jest jedynym obszarem sklepu, w którym porządek utrzymuje się wyłącznie przez procedurę, a nie przez konfigurację. Ustawienie da się zapisać raz, konwencja nazewnictwa musi być pilnowana przy każdym nowym produkcie. Wskazanie osoby, która akceptuje nowe atrybuty, jest w tym obszarze warte więcej niż jakiekolwiek narzędzie. Szerszy kontekst i kolejność wszystkich obszarów rozkładamy w przewodniku o optymalizacji PrestaShop.