Co to są atrybuty i warianty produktów w WooCommerce i jak je poprawnie projektować?

Sklep sprzedaje koszulkę w pięciu rozmiarach i czterech kolorach.

Na pierwszy rzut oka konfiguracja wydaje się prosta. Tworzymy atrybut „Rozmiar”, atrybut „Kolor”, generujemy warianty i gotowe.

Problem zaczyna się później.

Jedna koszulka ma kolor zapisany jako „Czarny”, druga jako „czarny”, trzecia jako „Black”. Rozmiar XL występuje również jako „X-Large”. Część produktów posiada warianty, część osobne produkty. Jeden wariant ma własne SKU, drugi nie. Zdjęcia przypisano tylko do części kolorów. Stany magazynowe są prowadzone raz na poziomie produktu, a raz na poziomie wariantu.

Następnie sklep chce uruchomić:

• filtry kategorii,
• Google Merchant Center,
• sprzedaż na marketplace,
• integrację z ERP,
• synchronizację stanów,
• automatyczne importy produktów.

I wtedy okazuje się, że problemem nie jest już wygląd karty produktu.

Problemem staje się struktura danych.

Atrybuty i warianty WooCommerce są jednym z fundamentów katalogu produktowego. Jeżeli zostaną zaprojektowane dobrze, pomagają zarządzać ofertą, filtrowaniem, magazynem i integracjami. Jeżeli powstają przypadkowo, błędy zaczynają rozchodzić się po całym sklepie.

Co to są atrybuty produktów w WooCommerce?

Atrybuty WooCommerce opisują cechy produktu.

Mogą to być między innymi:

• kolor,
• rozmiar,
• materiał,
• pojemność,
• długość,
• moc,
• rodzaj zasilania,
• marka,
• przeznaczenie.

Atrybut może pełnić kilka różnych funkcji.

Może:

• opisywać produkt,
• tworzyć warianty,
• zasilać filtry w kategorii,
• być przekazywany do feedu produktowego,
• uczestniczyć w integracji z ERP lub marketplace.

Dlatego atrybut nie jest tylko tekstem wyświetlanym w tabeli parametrów.

W dobrze zaprojektowanym sklepie jest częścią modelu danych.

Co to są warianty produktów w WooCommerce?

Wariant jest konkretną wersją produktu wynikającą z połączenia wybranych atrybutów.

Przykład:

Produkt:

Koszulka Classic

Atrybuty:

• Kolor: Czarny, Biały, Czerwony,
• Rozmiar: S, M, L, XL.

Możliwe warianty:

• Czarny / S,
• Czarny / M,
• Czarny / L,
• Czarny / XL,
• Biały / S,
• Biały / M.

Każdy wariant może posiadać własne:

• SKU,
• cenę,
• cenę promocyjną,
• stan magazynowy,
• zdjęcie,
• masę,
• wymiary,
• status dostępności.

To oznacza, że klient nadal ogląda jeden produkt, ale technicznie sklep zarządza wieloma jego konkretnymi wersjami.

Produkt prosty a produkt wariantowy

WooCommerce rozróżnia między innymi produkt prosty i produkt wariantowy.

Produkt prosty posiada jedną podstawową konfigurację sprzedażową.

Przykład:

Kabel HDMI 2 m występujący tylko w jednej wersji.

Produkt wariantowy posiada kilka wersji wybieranych przez klienta.

Przykład:

But dostępny w kilku rozmiarach i kolorach.

Nie każdy produkt posiadający parametry powinien być produktem wariantowym.

Laptop może posiadać atrybut:

Procesor: Intel Core i7

Jeżeli klient nie może wybrać innego procesora w ramach tego samego produktu, atrybut jest tylko informacją.

Kiedy atrybut powinien tworzyć wariant?

Atrybut powinien uczestniczyć w wariancie wtedy, gdy jego wartość zmienia konkretną wersję sprzedawanego produktu.

Najczęściej oznacza to, że zmienia przynajmniej jeden z elementów:

• SKU,
• stan magazynowy,
• cenę,
• zdjęcie,
• parametr potrzebny do realizacji zamówienia.

Przykład:

Rozmiar koszulki powinien być wariantem, ponieważ sklep musi wiedzieć, czy klient kupił M czy XL.

Materiał „100 procent bawełny” nie musi być wariantem, jeżeli wszystkie wersje produktu są wykonane z tego samego materiału.

Nie każdy parametr powinien być wariantem

Jednym z częstych błędów jest tworzenie wariantu z każdej możliwej cechy.

Produkt posiada:

• kolor,
• rozmiar,
• materiał,
• krój,
• rodzaj opakowania,
• długość rękawa.

Jeżeli każdy atrybut posiada kilka wartości, liczba kombinacji może bardzo szybko rosnąć.

Przykład:

• 5 kolorów,
• 6 rozmiarów,
• 3 materiały,
• 2 kroje.

Teoretyczna liczba kombinacji:

5 × 6 × 3 × 2 = 180 wariantów.

Jeżeli część kombinacji nie istnieje, zarządzanie katalogiem staje się jeszcze trudniejsze.

Warto więc wcześniej ustalić, które cechy rzeczywiście definiują jednostkę sprzedawaną i magazynowaną.

Atrybut globalny a lokalny

WooCommerce pozwala tworzyć atrybuty globalne oraz atrybuty przypisane tylko do konkretnego produktu.

Atrybut globalny istnieje w całym katalogu.

Przykład:

• Kolor,
• Rozmiar,
• Materiał.

Może być wykorzystywany przez wiele produktów.

Atrybut lokalny jest tworzony tylko w obrębie jednego produktu.

Może mieć sens przy wyjątkowej cesze występującej tylko w jednym miejscu.

Jeżeli jednak parametr ma być później używany w filtrach, imporcie albo integracjach, zwykle znacznie lepiej sprawdza się uporządkowany atrybut globalny.

Dlaczego atrybuty globalne są ważne?

Globalny atrybut pozwala korzystać ze wspólnego słownika wartości.

Przykład:

Atrybut:

Kolor

Wartości:

• Czarny,
• Biały,
• Granatowy.

Każdy produkt odwołuje się do tych samych wartości.

Dzięki temu łatwiej:

• budować filtry,
• prowadzić importy,
• usuwać duplikaty,
• mapować dane do zewnętrznych systemów,
• utrzymać spójne nazewnictwo.

Problem z niespójnym nazewnictwem

W rozbudowanych katalogach bardzo łatwo powstają wartości:

• Czarny,
• czarny,
• CZERŃ,
• Black,
• czarny mat,
• czarny matowy.

Czasem różnice są rzeczywiście potrzebne.

Czasem oznaczają dokładnie tę samą cechę zapisaną na kilka sposobów.

Dla klienta może to oznaczać bałagan w filtrach.

Dla systemu integracyjnego są to różne wartości.

Dlatego nazewnictwo atrybutów powinno być ustalone wcześniej i konsekwentnie stosowane.

Atrybut a taksonomia

Globalne atrybuty WooCommerce są technicznie przechowywane w strukturze pozwalającej traktować ich wartości jako uporządkowane terminy.

Daje to możliwości znacznie większe niż zwykły tekst wpisany w opisie produktu.

Można na ich podstawie:

• filtrować produkty,
• tworzyć archiwa,
• budować logikę sklepu,
• przypisywać wartości programowo.

To jeden z powodów, dla których przypadkowe tworzenie lokalnych parametrów utrudnia późniejsze rozwijanie sklepu.

Atrybuty a filtry produktów

Filtry kategorii zwykle korzystają z uporządkowanych danych produktowych.

Jeżeli klient chce wyświetlić:

• tylko czarne produkty,
• rozmiar XL,
• materiał bawełna,

sklep musi wiedzieć, które produkty posiadają te wartości.

Jeżeli kolor znajduje się raz jako globalny atrybut, raz w opisie, a raz jako niestandardowe pole, filtr nie będzie obejmował całego katalogu.

Problemy z filtrowaniem często nie wynikają więc z samego widżetu filtrów.

Ich źródłem jest niespójny katalog.

Filtr a wariant

W przypadku produktów wariantowych trzeba dodatkowo ustalić, jak filtr powinien interpretować dostępność.

Produkt może posiadać:

• kolor czarny w rozmiarze S,
• kolor czerwony w rozmiarze XL.

Klient ustawia:

• Kolor: czarny,
• Rozmiar: XL.

Produkt posiada oba atrybuty, ale nie istnieje wariant czarny XL.

Źle zaprojektowany filtr może mimo to wyświetlić produkt.

To pokazuje, że filtrowanie prostych wartości i filtrowanie rzeczywistych kombinacji wariantów nie zawsze oznacza to samo.

Atrybuty a wyszukiwarka sklepu

Parametry mogą również wpływać na wyszukiwanie.

Klient może wpisać:

• but 44 czarny,
• monitor 27 cali 4K,
• kabel USB-C 2 m.

Jeżeli wyszukiwarka indeksuje odpowiednie dane, może wykorzystać atrybuty do lepszego dopasowania wyników.

Jeżeli parametry są zapisane chaotycznie, wyszukiwarka może nie rozpoznać części zapytań.

Atrybuty a UX karty produktu

Klient nie powinien analizować wewnętrznej struktury WooCommerce.

Powinien zobaczyć prosty wybór.

W zależności od rodzaju atrybutu można wykorzystać:

• listę rozwijaną,
• przyciski,
• swatche kolorów,
• miniatury,
• pola wyboru.

Sposób prezentacji powinien odpowiadać charakterowi cechy.

Kolor produktu często lepiej prezentować wizualnie niż jako listę nazw.

Rozmiary mogą działać lepiej jako czytelne przyciski.

Swatche wariantów

Swatche zastępują standardową listę wyboru bardziej wizualnym interfejsem.

Mogą przedstawiać:

• kolor,
• wzór,
• zdjęcie wariantu,
• tekst.

Ich zastosowanie może poprawić UX, ale trzeba zachować poprawną strukturę danych.

Swatch jest warstwą interfejsu.

Nie powinien zastępować atrybutu właściwego dla produktu.

Atrybuty a dostępność

Wybór wariantu powinien być możliwy również bez polegania wyłącznie na kolorze.

Jeżeli klient widzi kilka identycznych kółek bez etykiety, osoba korzystająca z technologii asystujących może mieć problem z rozpoznaniem wartości.

Warto zadbać o:

• czytelne nazwy,
• etykiety,
• obsługę klawiatury,
• informację o niedostępności wariantu.

Nieistniejące kombinacje wariantów

Nie każdy produkt posiada wszystkie kombinacje atrybutów.

Przykład:

• Czarny: S, M, L,
• Biały: M, L, XL.

Nie istnieją:

• Czarny XL,
• Biały S.

Interfejs powinien jasno komunikować, że dana kombinacja jest niedostępna.

Najlepiej, gdy niemożliwe opcje są odpowiednio blokowane lub aktualizowane wraz z kolejnymi wyborami.

Wariant niedostępny a wariant nieistniejący

To dwie różne sytuacje.

Wariant nieistniejący nigdy nie był oferowany.

Wariant niedostępny istnieje, ale aktualnie nie ma go na stanie.

Z punktu widzenia klienta różnica może mieć znaczenie.

Niedostępny wariant może:

• wrócić do sprzedaży,
• umożliwiać zapis na powiadomienie,
• pokazywać przewidywany termin dostawy.

SKU produktu i SKU wariantu

SKU jest jednym z najważniejszych identyfikatorów w katalogu.

Przy produkcie wariantowym każdy wariant może posiadać własne SKU.

Przykład:

• TSHIRT-BLK-S,
• TSHIRT-BLK-M,
• TSHIRT-BLK-L.

Jest to szczególnie ważne, gdy:

• stany są prowadzone osobno,
• towar istnieje w ERP,
• produkt jest sprzedawany na marketplace,
• zamówienia są przekazywane do magazynu.

W wielu systemach to właśnie SKU jest głównym kluczem używanym do rozpoznania konkretnej pozycji.

Dlaczego SKU wariantu jest ważne?

Klient kupuje:

Koszulka / Czarna / XL

Magazyn nie potrzebuje informacji, że sprzedano „Koszulkę”.

Potrzebuje wiedzieć, którą dokładnie wersję wydać.

Jeżeli wszystkie warianty korzystają z jednego niejednoznacznego identyfikatora, integracja może mieć problem z prawidłową realizacją.

EAN, GTIN i inne identyfikatory wariantów

W części katalogów każda wersja produktu posiada również własny kod EAN lub inny identyfikator handlowy.

Dotyczy to szczególnie fizycznych produktów sprzedawanych wielokanałowo.

Przykładowo:

• but rozmiar 42 może mieć inny EAN niż rozmiar 43,
• opakowanie 500 ml może mieć inny EAN niż 1 litr.

Jeżeli dane są później wysyłane do marketplace albo systemów reklamowych, trzeba ustalić, gdzie przechowywany jest identyfikator konkretnego wariantu.

Warianty a stan magazynowy

WooCommerce pozwala prowadzić magazyn na poziomie wariantu.

Przykład:

• Czarny S: 4 sztuki,
• Czarny M: 0 sztuk,
• Czarny L: 9 sztuk.

To właściwe podejście wtedy, gdy każda wersja posiada fizycznie osobny zapas.

Klient powinien móc kupić dostępny rozmiar nawet wtedy, gdy inny wariant jest wyprzedany.

Magazyn na poziomie produktu czy wariantu?

Decyzja zależy od charakteru produktu.

Jeżeli warianty reprezentują fizycznie różne towary, magazyn zwykle powinien być prowadzony osobno.

Jeżeli wybór jest tylko konfiguracją wykonywaną po zakupie, struktura może wyglądać inaczej.

Najważniejsze jest, aby sposób zarządzania stanem odpowiadał rzeczywistemu procesowi magazynowemu.

Atrybuty a ERP

Integracja WooCommerce z ERP wymaga ustalenia, gdzie znajduje się główne źródło danych.

ERP może przechowywać:

• produkty,
• warianty,
• SKU,
• ceny,
• stany,
• kody EAN.

WooCommerce może być tylko kanałem prezentacji i sprzedaży.

Wtedy nie powinno się ręcznie tworzyć wariantów, których ERP nie rozpoznaje.

W przeciwnym razie powstają dwa niezależne katalogi.

Który system powinien być źródłem prawdy?

Przed integracją trzeba jednoznacznie ustalić, który system kontroluje:

• nazwę produktu,
• SKU,
• ceny,
• stany,
• atrybuty,
• zdjęcia.

Nie wszystkie informacje muszą pochodzić z jednego miejsca.

Przykładowo:

• ERP kontroluje SKU, ceny i stany,
• PIM kontroluje opisy i parametry,
• WooCommerce prezentuje dane klientowi.

Najgorszy scenariusz to kilka systemów jednocześnie nadpisujących ten sam parametr.

Atrybuty WooCommerce a PIM

Przy dużym katalogu system PIM może przejąć zarządzanie informacjami produktowymi.

Może definiować:

• nazwy atrybutów,
• wartości,
• tłumaczenia,
• grupy parametrów,
• relacje pomiędzy wariantami.

WooCommerce staje się wtedy jednym z kanałów publikacji.

Takie podejście pomaga uniknąć sytuacji, w której katalog internetowy rozwija własny słownik niezależnie od pozostałych kanałów.

Atrybuty a BaseLinker

W środowisku wielokanałowym BaseLinker może pośredniczyć pomiędzy sklepem, magazynem i marketplace.

Wariant musi być jednak jednoznacznie rozpoznawalny.

Znaczenie mają między innymi:

• SKU,
• EAN,
• nazwa wariantu,
• identyfikator produktu,
• stan magazynowy.

Jeżeli struktura katalogu WooCommerce jest niespójna, integracja z BaseLinkerem nie naprawi automatycznie danych. Może jedynie szybciej przekazywać ich niespójność do kolejnych kanałów.

Atrybuty a marketplace

Marketplace często posiada własne parametry kategorii.

WooCommerce może mieć:

Materiał: Stal nierdzewna

A marketplace oczekiwać pola:

Materiał wykonania

z własną listą dopuszczalnych wartości.

Potrzebne jest wtedy mapowanie.

Im bardziej uporządkowane są wartości w WooCommerce, tym łatwiej przygotować takie reguły.

Mapowanie atrybutów

Mapowanie określa, która informacja ze sklepu odpowiada polu w drugim systemie.

Przykład:

• pa_color → color,
• pa_size → size,
• pa_material → material.

Problem pojawia się, gdy ta sama informacja jest przechowywana w różnych miejscach.

Część produktów wykorzystuje atrybut globalny, część lokalny, a część posiada wartość tylko w opisie.

Automatyczne mapowanie przestaje być wtedy wiarygodne.

Atrybuty a Google Merchant Center

Google Merchant Center wykorzystuje dane produktowe potrzebne do prezentowania produktów w systemach Google.

W przypadku wariantów szczególne znaczenie mogą mieć informacje dotyczące:

• koloru,
• rozmiaru,
• identyfikatora grupy wariantów,
• GTIN,
• dostępności,
• ceny.

Jeżeli warianty posiadają osobne ceny i stany, feed powinien poprawnie odzwierciedlać te różnice.

Źle zbudowana struktura produktu może prowadzić do:

• odrzuceń,
• niewłaściwych danych,
• reklamowania niedostępnej wersji.

Warianty a feed produktowy

Feed może przedstawiać każdy wariant jako osobną ofertę.

Przykład:

• Koszulka czarna S,
• Koszulka czarna M,
• Koszulka biała M.

Każdy rekord może posiadać własne:

• ID,
• cenę,
• link,
• stan,
• zdjęcie.

To kolejny powód, dla którego struktura wariantów powinna być zaprojektowana świadomie.

Group ID dla wariantów

Systemy reklamowe i marketplace mogą potrzebować informacji, że kilka ofert należy do jednej rodziny produktu.

Produkt nadrzędny grupuje wtedy różne warianty.

Przykład:

Jedna koszulka występująca w 20 kombinacjach nie powinna być interpretowana jak 20 całkowicie niezależnych produktów, jeżeli system docelowy obsługuje relację wariantową.

Atrybuty a SEO

Same atrybuty nie powinny automatycznie generować setek indeksowalnych stron bez przemyślenia.

Filtry mogą tworzyć kombinacje takie jak:

• buty czarne,
• buty czarne 42,
• buty czarne 42 skórzane,
• buty czarne 42 skórzane męskie.

Przy dużym katalogu liczba adresów może rosnąć bardzo szybko.

Architektura filtrów powinna więc uwzględniać również SEO techniczne.

Czy każdy filtr powinien być indeksowany?

Nie.

Część kombinacji może mieć wartość wyszukiwawczą.

Inne tworzą jedynie techniczne strony z niewielką liczbą produktów.

Decyzja powinna uwzględniać:

• popyt,
• unikalność treści,
• liczbę produktów,
• architekturę całego serwisu.

Atrybut produktowy i strona SEO to dwa różne problemy, mimo że mogą korzystać z tych samych danych.

Warianty a adres URL

Wariant może być wybierany na jednej karcie produktu bez tworzenia osobnej indeksowalnej strony.

W niektórych przypadkach warto jednak umożliwić bezpośrednie odtworzenie wyboru wariantu z linku.

Przykład:

Reklama konkretnego koloru powinna prowadzić użytkownika do właściwie ustawionego wariantu, a nie wymagać ponownego wyszukiwania go na karcie produktu.

Warianty a zdjęcia produktów

Kolor lub wzór często powinien posiadać własne zdjęcie.

Po wyborze wariantu klient powinien zobaczyć właściwą wersję produktu.

Problemy występują, gdy:

• wariant nie ma zdjęcia,
• pokazywana jest fotografia innego koloru,
• galeria nie aktualizuje się po wyborze,
• miniatura w koszyku pokazuje niewłaściwą wersję.

To nie tylko problem estetyczny.

Klient powinien mieć pewność, którą wersję kupuje.

Warianty a cena

Różne warianty mogą posiadać różne ceny.

Przykład:

• 500 ml: 39 zł,
• 1 litr: 59 zł.

Karta produktu powinna jasno pokazywać cenę wybranego wariantu.

Jeżeli przed wyborem prezentowany jest zakres:

39–89 zł

warto sprawdzić, czy taki sposób jest czytelny dla klienta.

Warianty a promocje

Promocja może dotyczyć:

• wszystkich wariantów,
• tylko wybranych,
• konkretnego rozmiaru,
• wyprzedaży wybranego koloru.

System powinien jasno przedstawiać:

• cenę regularną,
• cenę promocyjną,
• który wariant jest przeceniony.

Nie warto komunikować promocji całego produktu, jeżeli dotyczy ona tylko jednej trudno dostępnej wersji.

Warianty a rabaty B2B

Sklep B2B może posiadać dodatkowe reguły cenowe zależne od:

• klienta,
• grupy,
• ilości,
• wariantu.

W takiej sytuacji logika ceny staje się bardziej złożona.

Trzeba sprawdzić, czy wszystkie reguły działają poprawnie również w:

• koszyku,
• checkoutcie,
• feedzie,
• integracjach.

Warianty a zamówienie WooCommerce

Po zakupie zamówienie powinno jednoznacznie wskazywać wybrany wariant.

Informacje te mogą być później wykorzystywane przez:

• magazyn,
• ERP,
• system fakturowy,
• obsługę klienta,
• system zwrotów.

Jeżeli wariant zostaje zapisany wyłącznie jako niewystarczający tekst, dalsza automatyzacja może mieć problem z rozpoznaniem konkretnej pozycji.

Warianty a zwroty

Klient nie zwraca ogólnie „butów”.

Zwraca konkretną wersję:

model X / czarny / rozmiar 43.

Proces zwrotu powinien przywrócić stan właściwego wariantu, a nie całego produktu.

Ma to znaczenie zwłaszcza w integracjach magazynowych.

Warianty a raportowanie sprzedaży

Firma może chcieć analizować:

• najpopularniejsze rozmiary,
• najczęściej wybierane kolory,
• warianty o najwyższej marży,
• produkty regularnie pozostające na magazynie.

Jeżeli dane wariantów są poprawnie przechowywane, takie analizy są znacznie prostsze.

Atrybuty a analityka

Dane produktowe mogą być również wysyłane do systemów analitycznych.

Przy zdarzeniu e-commerce warto wiedzieć, którą wersję produktu użytkownik:

• oglądał,
• dodał do koszyka,
• kupił.

Jeżeli identyfikator w GA4 oznacza produkt nadrzędny, a w Google Ads lub feedzie wariant, raportowanie może przestać być spójne.

Identyfikatory powinny być wcześniej zaprojektowane.

Warianty a remarketing produktowy

Remarketing może wykorzystywać identyfikatory produktów do dopasowania reklamy do wcześniejszego zainteresowania użytkownika.

Jeżeli strona wysyła ID nadrzędnego produktu, a feed korzysta z ID wariantu, system może mieć problem z dopasowaniem produktu.

To typowy przykład problemu, który na stronie jest całkowicie niewidoczny.

Karta produktu działa poprawnie, ale dane pomiędzy systemami się nie zgadzają.

Import produktów wariantowych

Przy większym katalogu warianty często są importowane automatycznie.

Plik lub API musi jednoznacznie określać:

• produkt nadrzędny,
• wariant,
• atrybuty,
• SKU,
• cenę,
• stan.

Przykład:

Produkt nadrzędny:

TSHIRT-100

Wariant:

TSHIRT-100-BLK-XL

Relacja pomiędzy nimi musi być jednoznaczna.

Co dzieje się przy ponownym imporcie?

To jedno z najważniejszych pytań.

Import powinien wiedzieć, czy ma:

• utworzyć nowy wariant,
• zaktualizować istniejący,
• usunąć nieistniejący w źródle,
• zostawić dane utworzone ręcznie.

Jeżeli identyfikator nie jest stabilny, każdy import może tworzyć duplikaty.

Usuwanie wariantów

Usunięcie wariantu może mieć wpływ na:

• historyczne zamówienia,
• feed,
• marketplace,
• linki,
• raportowanie.

Nie zawsze warto całkowicie usuwać produkt tylko dlatego, że chwilowo nie jest dostępny.

Czasem lepsze jest:

• wyłączenie sprzedaży,
• ustawienie braku stanu,
• archiwizacja.

Warianty generowane automatycznie

WooCommerce może generować kombinacje na podstawie wybranych atrybutów.

Funkcja jest wygodna, ale należy uważać, gdy nie wszystkie kombinacje istnieją.

Automatyczne wygenerowanie 100 wariantów, z których firma sprzedaje tylko 37, tworzy niepotrzebne rekordy.

Duża liczba wariantów a wydajność

Produkty z bardzo dużą liczbą wariantów mogą zwiększać złożoność strony i zapytań do bazy.

Problem może być szczególnie widoczny przy:

• setkach wariantów jednego produktu,
• rozbudowanych wtyczkach dodatkowych opcji,
• dynamicznych cenach,
• dużej liczbie skryptów.

Jeżeli jeden produkt posiada bardzo rozbudowany konfigurator, klasyczne warianty WooCommerce nie zawsze są najlepszym modelem.

Wariant a konfigurator produktu

Wariant reprezentuje konkretną, skończoną wersję produktu.

Konfigurator może pozwalać na znacznie większą liczbę kombinacji.

Przykład:

Klient wybiera:

• wymiar,
• materiał,
• kolor,
• akcesoria,
• personalizację.

Jeżeli daje to tysiące albo miliony możliwych kombinacji, tworzenie każdego wariantu w bazie może być niepraktyczne.

Potrzebna może być inna architektura.

Warianty a produkty konfigurowane na zamówienie

Nie każdy wybór klienta wymaga fizycznego wariantu magazynowego.

Przykład:

Produkt wykonywany dopiero po zamówieniu może posiadać opcje wpływające na:

• cenę,
• produkcję,
• czas realizacji.

W takim modelu trzeba zaprojektować, czy opcja powinna być:

• wariantem,
• dodatkiem,
• polem konfiguratora.

Wybranie niewłaściwej struktury może później bardzo utrudnić rozwój sklepu.

Atrybuty a kategorie produktów

Atrybut i kategoria opisują produkt w inny sposób.

Kategoria odpowiada zwykle na pytanie:

Co to jest?

Atrybut:

Jaką posiada cechę?

Przykład:

Kategoria:

Koszulki

Atrybuty:

• Kolor: Czarny,
• Rozmiar: XL,
• Materiał: Bawełna.

Nie warto tworzyć kategorii „Czarne”, „Białe” i „Bawełniane” tylko dlatego, że sklep potrzebuje filtrów.

Atrybut a tag produktu

Tag może opisywać dodatkowe powiązanie lub temat, ale nie powinien zastępować uporządkowanego atrybutu potrzebnego w filtrach i integracjach.

Jeżeli kolor jest ważną cechą biznesową, powinien być zapisany w przewidywalnym miejscu.

Jak zaprojektować model atrybutów przed wdrożeniem?

Przy nowym lub przebudowywanym sklepie warto przygotować słownik atrybutów przed masowym dodawaniem produktów.

Dla każdego atrybutu można określić:

• nazwę,
• dozwolone wartości,
• jednostkę,
• czy tworzy wariant,
• czy jest filtrowalny,
• czy trafia do feedu,
• czy pochodzi z ERP lub PIM.

Taki dokument znacząco ogranicza późniejszą improwizację.

Jednostki w atrybutach

Warto ustalić sposób zapisywania jednostek.

Przykład:

• 2 m,
• 200 cm,
• 2000 mm.

Dla człowieka wartości mogą oznaczać to samo.

Dla filtra są całkowicie różne.

Jeżeli długość ma być sortowana lub filtrowana numerycznie, warto przechowywać ją w spójnym formacie.

Atrybut tekstowy a liczbowy

Nie każda cecha powinna być traktowana jak zwykły tekst.

Przy parametrach takich jak:

• moc,
• pojemność,
• długość,
• waga,

może być potrzebne sortowanie lub filtrowanie zakresowe.

Wtedy struktura danych powinna umożliwiać rozpoznanie wartości liczbowej.

Atrybuty obowiązkowe

Przy dużym katalogu warto ustalić, które parametry są wymagane dla danej kategorii.

Przykład:

Dla laptopa obowiązkowe mogą być:

• procesor,
• RAM,
• dysk,
• przekątna ekranu.

Dla koszulki:

• rozmiar,
• kolor,
• materiał.

Dzięki temu łatwiej wykrywać niekompletne produkty przed publikacją.

Atrybuty a jakość katalogu

Katalog może zawierać setki lub tysiące produktów, ale jego rzeczywista jakość zależy od spójności informacji.

Warto kontrolować:

• brakujące wartości,
• duplikaty,
• literówki,
• nieaktualne terminy,
• różne jednostki.

Przy dużym katalogu ręczna kontrola wszystkich rekordów przestaje być możliwa.

Automatyczna walidacja atrybutów

Można przygotować reguły sprawdzające jakość produktów.

Przykładowo system może wykrywać:

• produkt bez wymaganej marki,
• wariant bez SKU,
• wariant bez ceny,
• duplikat SKU,
• nieznaną wartość atrybutu,
• brak EAN.

Automatyzacja kontroli danych może być szczególnie przydatna przy katalogach aktualizowanych z kilku źródeł.

Atrybuty a API WooCommerce

Dane produktów i wariantów mogą być odczytywane oraz aktualizowane przez API WooCommerce.

Dzięki temu zewnętrzny system może:

• tworzyć produkty,
• aktualizować warianty,
• zmieniać stany,
• aktualizować ceny.

Skuteczność takiej integracji zależy jednak od poprawnie zaprojektowanej struktury danych.

API nie rozwiązuje problemu niespójnego katalogu. Automatyzuje tylko operacje wykonywane na tym katalogu.

Warianty a webhooki

Zmiana danych produktu może również uruchamiać dalsze procesy.

Przykładowo zmiana stanu może zostać przekazana do:

• systemu magazynowego,
• marketplace,
• innego kanału sprzedaży.

Przy wielu integracjach należy uważać na pętle synchronizacji, w których system A aktualizuje B, a B wysyła tę samą zmianę z powrotem do A.

Atrybuty a migracja sklepu

Podczas migracji z innej platformy nie należy automatycznie kopiować starej struktury bez analizy.

Poprzedni sklep może posiadać:

• inne nazwy parametrów,
• duplikaty,
• lokalne pola,
• niestandardowe warianty.

Migracja jest dobrym momentem na uporządkowanie modelu danych.

W przeciwnym razie nowy sklep przejmuje wszystkie problemy starego.

Atrybuty a wielojęzyczność

Sklep działający w kilku językach musi rozróżnić wartość techniczną od jej prezentacji.

Przykład:

• PL: Czarny,
• EN: Black,
• DE: Schwarz.

System powinien nadal wiedzieć, że jest to ten sam logiczny kolor.

Tworzenie osobnych niezależnych wartości dla każdego języka może utrudniać synchronizację i filtrowanie.

Atrybuty a wiele walut

Sama waluta nie powinna zwykle tworzyć wariantu.

Wariant produktu jest tą samą jednostką niezależnie od tego, czy klient widzi cenę w PLN, EUR czy USD.

System walutowy powinien zmieniać prezentację ceny, a nie duplikować katalog.

Atrybuty a różne rynki

W niektórych przypadkach ten sam produkt może posiadać inne:

• nazwy,
• jednostki,
• parametry obowiązkowe

w zależności od rynku.

Warto jednak zachować wspólny identyfikator produktu i wariantu, jeżeli fizycznie jest to ten sam towar.

Kiedy warto rozdzielić warianty na osobne produkty?

Niektóre warianty mogą być na tyle różne, że lepiej prezentować je jako osobne produkty.

Może to mieć sens, gdy:

• posiadają całkowicie inne zastosowanie,
• mają osobne treści SEO,
• różnią się znacząco ceną i specyfikacją,
• klienci wyszukują je niezależnie.

Decyzja powinna uwzględniać zarówno UX, SEO, jak i zarządzanie katalogiem.

Kiedy nie rozdzielać wariantów?

Jeżeli jedyną różnicą jest rozmiar lub kolor, tworzenie kilkudziesięciu niemal identycznych kart produktu może:

• utrudniać nawigację,
• duplikować treść,
• rozpraszać opinie i dane sprzedażowe.

Jeden produkt wariantowy jest wtedy zwykle bardziej logiczny.

Najczęstsze błędy w atrybutach i wariantach WooCommerce

Tworzenie atrybutów lokalnych dla wszystkiego

Każdy produkt posiada własny niezależny zestaw wartości.

Niespójne nazewnictwo

Ta sama wartość występuje pod kilkoma nazwami.

Duplikowanie atrybutów

Powstają osobno „Kolor”, „Kolory” i „Barwa”.

Tworzenie wariantu z każdej cechy

Liczba kombinacji zaczyna rosnąć wykładniczo.

Brak SKU wariantów

Magazyn i integracje nie posiadają stabilnego identyfikatora.

Duplikaty SKU

Dwa różne warianty są interpretowane jako ten sam produkt.

Magazyn na niewłaściwym poziomie

Stan całego produktu nie odpowiada stanom konkretnych wersji.

Nieistniejące kombinacje

Klient może wybrać wariant, który fizycznie nie jest oferowany.

Brak zdjęć wariantów

Po wyborze koloru nadal widoczny jest inny produkt.

Niespójne jednostki

Ten sam parametr jest zapisany w cm, mm i metrach.

Parametry tylko w opisie

Informacja wygląda poprawnie dla klienta, ale nie może być wykorzystana przez filtr i integrację.

Ręczna edycja danych synchronizowanych z ERP

Kolejna synchronizacja nadpisuje zmianę.

Brak źródła prawdy

WooCommerce, ERP i marketplace mogą niezależnie zmieniać te same dane.

Automatyczny import bez stabilnych identyfikatorów

Każde uruchomienie tworzy kolejne warianty.

Feed korzystający z innych ID niż analityka

Remarketing i raportowanie nie potrafią dopasować produktu.

Filtry oparte na nieuporządkowanych danych

Problem UX jest próbowany do naprawienia wtyczką zamiast strukturą katalogu.

Generowanie ogromnej liczby wariantów

WooCommerce jest używany jak konfigurator dla procesu, który wymaga innej architektury.

Pytania do samodzielnego audytu atrybutów i wariantów WooCommerce

1. Czy wiem, które cechy produktu powinny być atrybutami?
2. Czy wiem, które atrybuty rzeczywiście tworzą warianty?
3. Czy używam atrybutów globalnych dla powtarzalnych cech?
4. Czy nie mam kilku atrybutów oznaczających to samo?
5. Czy wartości posiadają spójne nazewnictwo?
6. Czy używam jednej konwencji jednostek?
7. Czy wszystkie warianty posiadają jednoznaczne SKU?
8. Czy w katalogu nie występują duplikaty SKU?
9. Czy każdy wariant posiada właściwą cenę?
10. Czy każdy wariant posiada poprawny stan?
11. Czy magazyn jest prowadzony na właściwym poziomie?
12. Czy nieistniejące kombinacje są wykluczone?
13. Czy klient widzi, które warianty są chwilowo niedostępne?
14. Czy po wyborze wariantu zmienia się właściwe zdjęcie?
15. Czy karta produktu pokazuje właściwą cenę?
16. Czy atrybuty są używane w filtrach?
17. Czy filtry uwzględniają rzeczywiste kombinacje wariantów?
18. Czy wyszukiwarka wykorzystuje ważne parametry?
19. Czy atrybuty są poprawnie mapowane do marketplace?
20. Czy feed produktowy rozpoznaje warianty?
21. Czy Merchant Center otrzymuje właściwy kolor i rozmiar?
22. Czy wariant posiada poprawny GTIN lub EAN, jeśli jest wymagany?
23. Czy ID produktu w analityce odpowiada ID używanemu w feedzie?
24. Czy remarketing potrafi dopasować właściwy produkt?
25. Czy ERP i WooCommerce korzystają ze spójnych identyfikatorów?
26. Czy wiadomo, który system jest źródłem ceny?
27. Czy wiadomo, który system jest źródłem stanu?
28. Czy import aktualizuje istniejące produkty zamiast tworzyć duplikaty?
29. Czy dane są walidowane przed publikacją?
30. Czy liczba wariantów nie jest zbyt duża dla klasycznego modelu WooCommerce?
31. Czy konfigurator nie byłby lepszym rozwiązaniem dla bardzo złożonych produktów?
32. Czy struktura katalogu będzie nadal działała po dodaniu kolejnych kanałów sprzedaży?

Jak zaprojektować atrybuty i warianty WooCommerce krok po kroku?

Etap 1: zinwentaryzuj katalog

Najpierw trzeba określić, jakie rodzaje produktów występują w sklepie i czym rzeczywiście się różnią.

Etap 2: oddziel cechy informacyjne od sprzedażowych

Nie każdy parametr musi definiować wariant.

Etap 3: przygotuj listę globalnych atrybutów

Powtarzalne cechy powinny korzystać ze wspólnego słownika.

Etap 4: uporządkuj wartości

Należy usunąć duplikaty, literówki i niepotrzebne warianty nazewnictwa.

Etap 5: ustal jednostki

Wartości liczbowe powinny być przechowywane w przewidywalnym formacie.

Etap 6: zdefiniuj strukturę SKU

Każdy wariant wymagający osobnej identyfikacji powinien posiadać stabilne SKU.

Etap 7: ustal źródła danych

Trzeba zdecydować, czy atrybuty, ceny i stany powstają w WooCommerce, ERP czy PIM.

Etap 8: przygotuj mapowanie integracji

Atrybuty WooCommerce powinny posiadać odpowiedniki w systemach docelowych.

Etap 9: przygotuj warianty

Należy tworzyć tylko rzeczywiście istniejące kombinacje.

Etap 10: skonfiguruj magazyn

Stan powinien odpowiadać rzeczywistej jednostce magazynowej.

Etap 11: skonfiguruj prezentację

Lista, przyciski, kolory i zdjęcia powinny pomagać klientowi szybko wybrać właściwą wersję.

Etap 12: przetestuj filtry

Warto sprawdzić zarówno pojedyncze wartości, jak i kombinacje parametrów.

Etap 13: przetestuj koszyk i checkout

Zamówienie musi zawierać dokładnie tę wersję, którą klient wybrał.

Etap 14: przetestuj feed

Każdy wariant powinien posiadać właściwe ID, cenę, stan i parametry.

Etap 15: przetestuj integracje

ERP, BaseLinker i marketplace powinny poprawnie rozpoznawać konkretną jednostkę.

Etap 16: wdroż kontrolę jakości

Duży katalog powinien automatycznie wykrywać brakujące i nieprawidłowe dane.

Najważniejsze wnioski

Atrybuty i warianty WooCommerce są podstawą prawidłowej struktury katalogu produktowego.

Atrybut opisuje cechę produktu. Wariant reprezentuje konkretną wersję, którą klient może kupić.

Dobrze zaprojektowana struktura:

• korzysta z globalnych atrybutów dla powtarzalnych cech,
• posiada spójne nazewnictwo wartości,
• tworzy warianty tylko z rzeczywiście istotnych cech,
• przypisuje stabilne SKU do konkretnych wersji,
• prowadzi magazyn na właściwym poziomie,
• pozwala budować użyteczne filtry,
• przekazuje poprawne dane do feedów i Merchant Center,
• umożliwia jednoznaczne mapowanie do ERP i marketplace,
• utrzymuje spójność analityki i remarketingu,
• może być automatycznie aktualizowana bez tworzenia duplikatów.

Najczęstszym błędem jest traktowanie atrybutów jak zwykłych opisów dodawanych przy okazji tworzenia produktu. Dopóki sklep posiada kilkadziesiąt pozycji, konsekwencje mogą być niewielkie. Przy setkach lub tysiącach produktów każda niespójność zaczyna się jednak multiplikować.

Źle zdefiniowany kolor powoduje problem w filtrze. Ten sam problem trafia do feedu. Następnie do Merchant Center, marketplace i raportowania. Brak SKU wariantu powoduje problem z magazynem, a później z realizacją zamówienia.

Dlatego strukturę katalogu warto traktować jak projekt danych, a nie wyłącznie konfigurację karty produktu.

Jeżeli sklep posiada dużą liczbę produktów, wariantów albo dane pochodzące z kilku źródeł, mogę przeanalizować strukturę katalogu i wskazać miejsca wymagające uporządkowania. Sprawdzam atrybuty, warianty, SKU, filtry, feedy oraz sposób wymiany informacji pomiędzy WooCommerce i zewnętrznymi systemami. Przy bardziej złożonych projektach mogę również zaprojektować automatyzację przepływu i kontroli danych, tak aby rozwój sklepu nie oznaczał ręcznego poprawiania tych samych informacji w kilku miejscach.