Wiedza Testin
Wariant produktu czy osobny produkt? Jak uporządkować katalog sklepu
Sklep ma sprzedawać jeden model bluzy w trzech kolorach i pięciu rozmiarach. Czy dodać piętnaście osobnych produktów, czy jedną kartę z wyborem wariantu? Ta decyzja wpływa na zdjęcia, stany magazynowe, filtrowanie, adresy stron i codzienną obsługę katalogu. Warto podjąć ją przed importem danych.
Wariant to odmiana tego samego produktu, a osobny produkt powinien mieć własny, uzasadniony sens dla kupującego. Nie ma jednej reguły pasującej do całego asortymentu. Najlepszy model katalogu opisuje rzeczywistą ofertę i pozwala klientowi bez pomyłki zamówić konkretną wersję.
Kiedy wariant, a kiedy osobny produkt
Kolor, rozmiar lub pojemność często pozwalają opisać odmiany jednego modelu. Gdy różnice zmieniają przeznaczenie, konstrukcję albo zestaw funkcji, osobne karty mogą być czytelniejsze. Sprawdź, czy kupujący porównuje wersje tego samego przedmiotu, czy faktycznie wybiera między różnymi rozwiązaniami.
- Jeden model koszulki, kilka rozmiarów i kolorów
- Naturalny kandydat do jednej grupy wariantów. Wybrany rozmiar i kolor muszą jednoznacznie trafić do zamówienia.
- Dwa odkurzacze o różnych funkcjach i konstrukcji
- Osobne produkty zwykle ułatwią porównanie specyfikacji, wyposażenia i zastosowania.
- Ta sama farba w różnych pojemnościach
- Możliwy model wariantów, ale przed wdrożeniem sprawdź ceny, magazyn, jednostki oraz sposób obsługi w używanych integracjach.
To przykłady projektowe, nie uniwersalne wymogi konkretnej platformy. Osobny zestaw z dodatkowymi akcesoriami może wymagać innego sposobu obsługi niż sam wybór koloru.
Przygotuj dane przed budowaniem kart
Zacznij od niewielkiego arkusza dla reprezentatywnej części asortymentu. Powinien obejmować prosty produkt, produkt z wieloma wariantami i trudniejszy przypadek, na przykład zestaw. Nie importuj od razu całego katalogu z nieujednoliconymi nazwami.
- Identyfikator grupy: który model łączy poszczególne wersje.
- Identyfikator wariantu: SKU lub inny identyfikator używany w Twojej obsłudze sprzedaży.
- Atrybuty: kolor, rozmiar, materiał lub inne rzeczywiste różnice.
- Cena i dostępność: dane właściwe dla konkretnej wersji, a nie przypadkowo całej grupy.
- Zdjęcie: kadr odpowiadający wybranemu kolorowi lub konfiguracji.
- Specyfikacja: cechy wspólne oraz informacje zmieniające się po wyborze wariantu.
Ustal słownik atrybutów. „Granatowy”, „navy” i „ciemny niebieski” nie powinny tworzyć trzech przypadkowych filtrów, jeżeli w Twoim katalogu oznaczają to samo. Z kolei dwóch faktycznie różnych odcieni nie warto łączyć tylko dla wygody importu.
Co powinno się zmieniać po wyborze wariantu
Wybór wersji musi prowadzić do spójnego stanu karty. Klient nie powinien oglądać zdjęcia czerwonej koszulki, czytać ceny niebieskiej i dodawać do koszyka rozmiaru, którego nie wybrał.
- Otwórz kartę i wybierz konkretny wariant.
- Sprawdź zdjęcie, cenę, dostępność oraz nazwę wybranej wersji.
- Dodaj produkt do koszyka i potwierdź te same cechy.
- Przejdź do podsumowania zamówienia i sprawdź, czy wersja pozostaje jednoznaczna.
- Powtórz test dla wariantu niedostępnego i po zmianie wyboru.
Ustal, jak sygnalizować brak na stanie oraz czy możliwe jest powiadomienie o dostępności. Nie sprowadzaj problemu do ukrycia całej karty. Ten temat rozwijamy osobno w poradniku o produkcie niedostępnym w sklepie internetowym.
Zaprojektuj adresy i udostępnianie wersji
Jeżeli klient kopiuje link do zielonej kurtki w rozmiarze M, po jego otwarciu powinien zobaczyć właściwą wersję. Zaplanuj to razem z wykonawcą, zamiast traktować adresy jako skutek uboczny działania selektora.
Google opisuje identyfikowanie wariantów przez osobne adresy, na przykład parametr koloru lub fragment ścieżki. Przy wariantach opartych na opcjonalnych parametrach zaleca adres bazowy jako canonical. Nie oznacza to, że każde wdrożenie z osobnymi kartami ma otrzymać identyczną konfigurację. Zasady i przykłady przedstawia dokumentacja adresów sklepów Google.
Przed zmianą istniejącego katalogu sprawdź stare linki, widoczność stron i integracje. Zmiana modelu wariantów może wymagać także mapy adresów, aktualizacji pliku produktowego oraz poprawienia odnośników wewnętrznych.
Dane produktowe powinny odpowiadać ofercie
Dane strukturalne nie naprawią niewłaściwie opisanego katalogu. Powinny przedstawiać produkt i wariant widoczny dla kupującego, z właściwą ceną i dostępnością.
Google dokumentuje ProductGroup jako sposób powiązania wariantów oraz Product dla poszczególnych produktów. Uwzględnia przy tym zarówno jedną kartę z selektorem, jak i warianty dostępne na wielu stronach. Wymaga też możliwości otwarcia odpowiednio wybranego wariantu przez osobny URL. Szczegóły zależą od modelu strony: oficjalna dokumentacja danych wariantów.
To kwalifikacja do określonych sposobów prezentacji, a nie gwarancja ich wyświetlenia. Dobór danych Product zależy również od tego, czy na stronie można kupić produkt; rozróżnienie opisuje wprowadzenie Google do danych produktowych.
Sprawdź magazyn i integracje na małej próbce
Dobra karta produktu może maskować bałagan w zapleczu. Sprawdź, jaki identyfikator trafia do zamówienia, systemu magazynowego i dokumentów sprzedaży. Ustal, gdzie zmienia się cenę i stan oraz co dzieje się przy ponownym imporcie. Zweryfikuj zasady dla Twojej konkretnej integracji — nie zakładaj, że wszystkie narzędzia obsługują warianty identycznie.
Przed pełnym wdrożeniem poproś osobę, która będzie codziennie obsługiwać sklep, o dodanie nowej wersji i aktualizację stanu. Jeżeli te czynności wymagają ręcznego poprawiania kilku miejsc, warto wyjaśnić przyczynę przed rozbudową katalogu.
Krótka lista przed importem całego katalogu
- Każdy model i wariant mają uzgodniony identyfikator.
- Nazwy atrybutów są spójne i zrozumiałe dla kupującego.
- Zdjęcie, cena, dostępność i koszyk odpowiadają tej samej wersji.
- Udostępniony adres otwiera właściwy wariant.
- Uzgodniono model canonical oraz danych produktowych.
- Testowa próbka przechodzi poprawnie przez używane integracje.
- Osoba obsługująca sklep potrafi wykonać podstawowe zmiany.
W projekcie sklepu internetowego katalog jest częścią zakresu wdrożenia, a nie materiałem do dodania na samym końcu. Uporządkowanie go wcześniej pozwala podejmować decyzje o kartach, filtrach i integracjach na podstawie rzeczywistej oferty.
