Jeden katalog produktów dla wielu kanałów: najlepsze praktyki

Dlaczego jeden katalog produktów to fundament sprzedaży omnichannel

Chaos przy wielu osobnych katalogach produktowych

Rozdzielone katalogi produktów to prosta droga do tego, żeby Allegro “żyło swoim życiem”, Amazon swoim, a sklep internetowy jeszcze innym. Skutki widać bardzo szybko: różne nazwy, inne ceny, nieaktualne zdjęcia, brakujące parametry. Raz klient dzwoni, że na Allegro ma taniej niż w sklepie, innym razem dział magazynu nie rozumie, co to za produkt z dziwnym SKU, który pojawił się w zamówieniu z marketplace.

Każdy dodatkowy, osobny katalog to osobne miejsce do pilnowania zmian. Nowa cena? Trzeba kliknąć w kilku systemach. Zmiana opisu? Aktualizacja w sklepie, potem Allegro, potem Amazon. W praktyce kończy się to sytuacją, w której:

• część kanałów ma inne stany magazynowe niż faktycznie w ERP,
• ceny w marketplace różnią się od tych w sklepie (często zupełnie przypadkiem),
• produkty są zdublowane, bo ktoś dodał je ręcznie “na szybko”.

Przy małej liczbie produktów da się to jeszcze okiełznać. Gdy asortyment rośnie, a liczba kanałów zwiększa się do trzech–czterech, ręczne sterowanie katalogami zaczyna przypominać żonglowanie piłkami… z zamkniętymi oczami.

Jeden katalog jako źródło prawdy

Centralny katalog produktów pełni rolę jednego źródła prawdy – tu powstaje, tu jest aktualizowany i stąd “idzie w świat” każdy produkt. Niezależnie, czy produkt trafi na sklep internetowy, Allegro, Amazon, do systemu B2B czy do POS w sklepie stacjonarnym, jego fundamentem są te same dane podstawowe i identyfikatory.

Taki katalog nie musi oznaczać jednego programu. Może to być:

• moduł towarowy w ERP, rozszerzony o dane sprzedażowe i content,
• system PIM spięty z ERP, który trzyma bogate dane produktowe,
• platforma e‑commerce, która pełni rolę frontu produktowego, a ERP kontroluje magazyn i ceny.

Klucz jest jeden: jeden rekord produktu = jeden produkt w całej firmie, a nie osobne byty w każdym kanale.

Dzięki temu zmiana ceny, dodanie nowego zdjęcia czy dopisanie atrybutu “kolor” odbywa się w jednym miejscu i automatycznie jest propagowane do wszystkich podłączonych kanałów. Redukuje to ręczną pracę, ale przede wszystkim eliminuje rozjazdy danych.

Spójność danych a konwersja, zwroty i obsługa klienta

Spójne dane produktowe wpływają nie tylko na porządek wewnątrz firmy. Przekładają się bezpośrednio na:

• konwersję – jasny opis, komplet atrybutów i dobre zdjęcia zwiększają współczynnik zakupu,
• liczbę zwrotów – im dokładniejszy opis i parametry, tym mniej rozczarowanych klientów, którzy “spodziewali się czegoś innego”,
• czas obsługi klienta – konsultanci nie muszą się zastanawiać, który opis jest aktualny i dlaczego produkt w jednym kanale ma inne wymiary niż w drugim,
• reklamacje – łatwiej udowodnić, co było sprzedawane, gdy produkt wszędzie jest opisany tak samo.

Jeśli klient widzi ten sam produkt w Twoim sklepie i na Allegro, ale z innymi parametrami i ceną, traci zaufanie. Z kolei jeśli w każdym kanale dostaje spójny komunikat, a informacje o produkcie się zgadzają, rośnie poczucie profesjonalizmu marki – nawet jeśli sprzedaż fizycznie idzie przez różne marketplace.

Centralny katalog a tempo zmian i rozwój

Porządny, centralny katalog działa jak dźwignia. Zamiast przepuszczać każdą zmianę przez kilka paneli, wystarczy:

• dodać nową kolekcję do katalogu,
• uzupełnić atrybuty i content,
• przypiąć produkty do nowych kanałów / marketplace przez integrację.

Zmiana polityki cenowej? Można ją wdrożyć regułami cenowymi powiązanymi z kanałami, zamiast ręcznie “przeklikiwać” cenniki na Allegro czy Amazon. Dołączenie nowego marketplace? Architektura, w której katalog jest centralny, pozwala po prostu dodać kolejny “odbiornik” danych, a nie budować kolejny katalog od zera.

Centralny katalog to też łatwiejsze raportowanie. ERP lub PIM mają klarowne informacje o tym, co się sprzedaje i gdzie. Nie trzeba scalać danych z kilku niekompatybilnych katalogów, bo każdy SKU jest tym samym SKU w każdym kanale sprzedaży.

Gdzie trzymać jeden katalog: ERP, PIM, e‑commerce czy hybryda?

Rola ERP, PIM i platformy sklepowej w omnichannel

W architekturze omnichannel trzy typy systemów najczęściej walczą o miano “mistrza katalogu”:

• ERP – zwykle odpowiada za stany magazynowe, podstawowe dane towarowe, ceny, dokumenty (Faktury, WZ, PZ). Jest mocny w liczbach, ale słaby w ładnym contencie.
• PIM (Product Information Management) – specjalizuje się w danych produktowych: atrybutach, opisach, zdjęciach, wariantach, tłumaczeniach, wersjach treści pod różne kanały.
• Platforma e‑commerce – ma katalog produktów potrzebny do działania sklepu, ale nie zawsze nadaje się na centralne repozytorium dla całej firmy, zwłaszcza gdy pojawia się B2B, POS czy wiele marketplace.

Decyzja, gdzie trzymać centralny katalog produktów, zależy od skali, złożoności oferty i tego, jak mocno firma wchodzi w omnichannel. Najrozsądniejsza praktyka: jasno podzielić odpowiedzialności między systemy i nie próbować robić z ERP pełnoprawnego PIM, jeśli oferta jest rozbudowana.

Kiedy wystarczy trzymać katalog w ERP

ERP jako główne źródło danych produktowych sprawdza się, gdy:

• asortyment jest dość prosty (niewiele kategorii, mało atrybutów),
• nie ma dużej liczby wersji opisów, języków czy zdjęć,
• kanały sprzedaży mają podobne wymagania (np. sklep + Allegro, bez mocno rozbudowanego Amazona czy wielu rynków zagranicznych),
• zespół nie planuje bardzo bogatych kart produktowych z wieloma sekcjami contentu.

W takim scenariuszu ERP przechowuje dane bazowe (nazwy, EAN, kody, ceny, jednostki, wagi), a integracja z platformą sklepu i marketplace’ami rozszerza je o szablony opisów i zdjęć. Katalog jest stosunkowo prosty, lecz uporządkowany, a ERP pełni rolę nadrzędnego źródła danych liczbowych.

Najczęstszy błąd w tym modelu to “dokręcanie” do ERP coraz to nowych pól opisowych, zdjęć i specyfikacji aż system staje się nieczytelny i trudny w utrzymaniu. Jeśli zaczyna się dodawać dziesiątki własnych pól tylko po to, by obsłużyć wymagania marketplace, zwykle oznacza to, że czas na PIM lub model hybrydowy.

Kiedy PIM staje się koniecznością

PIM jest naturalnym wyborem, gdy rośnie złożoność katalogu. Potrzeba go szczególnie wtedy, gdy:

• każda kategoria ma własne specyficzne atrybuty (np. elektronika, moda, części motoryzacyjne, chemia gospodarcza),
• te same produkty mają różne opisy i zdjęcia dla różnych kanałów (np. skrócone opisy na marketplace, rozbudowane w sklepie),
• firma działa w kilku językach lub na różnych rynkach (PL, DE, CZ itd.),
• kilka działów pracuje nad contentem (marketing, techniczny, SEO, tłumaczenia).

PIM pozwala kontrolować wersjonowanie danych, workflow akceptacji i kompletną strukturę atrybutów. ERP zwalnia się z roli “kombajnu” do wszystkiego, koncentrując się na magazynie i finansach, a PIM staje się mózgiem produktowym, który dystrybuuje dane do sklepu, Allegro, Amazon, B2B i innych kanałów.

W dużych katalogach (kilkadziesiąt tysięcy SKU i więcej) PIM często jest jedynym rozsądnym sposobem, by utrzymać jakość danych produktowych przy sensownych kosztach pracy zespołu. Bez niego łatwo zamienić marketing produktowy w niekończące się kopiuj–wklej.

Model hybrydowy: ERP + PIM / sklep jako front produktowy

W praktyce najczęściej wygrywa model hybrydowy. Schemat jest zwykle podobny:

• ERP – trzyma indeks towarowy, stany magazynowe, podstawowe ceny, podatki, jednostki, EAN.
• PIM lub platforma sklepu – trzyma strukturę kategorii, atrybutów, opisy, zdjęcia, materiały dodatkowe, powiązania między produktami (zestawy, akcesoria, zamienniki).
• Integracja – spina ERP z PIM/sklepem i przekazuje dane do marketplace.

ERP jest punktem wyjścia do tworzenia produktu (numer katalogowy, podstawowe parametry), a PIM lub platforma sklepu rozwija go o resztę. Dla wielu firm e‑commerce, które startowały od sklepu, to właśnie sklep staje się naturalnym “frontem katalogu”, a ERP przychodzi później, gdy rośnie skala.

Przykładowe architektury dla różnych skal biznesu

Prosty schemat architektury można zestawić w formie tabeli:

Przeskok między poziomami nie musi być rewolucją. Sensownie zbudowany katalog w ERP i sklepie można później stosunkowo łatwo przenieść do PIM – o ile od początku myśli się o spójnych identyfikatorach i strukturze.

Struktura jednego katalogu: kategorie, atrybuty, warianty

Własna hierarchia kategorii zamiast kopiowania marketplace

Kuszące jest skopiowanie drzewa kategorii Allegro lub Amazona do firmy – “skoro tam sprzedajemy, to zróbmy tak samo”. Problem w tym, że każde marketplace ma własną logikę kategoryzacji, mocno podporządkowaną filtrom i wyszukiwarce w swoim serwisie. To, co jest wygodne dla Allegro, niekoniecznie jest wygodne dla Twojej organizacji.

Centralny katalog powinien mieć własną, przemyślaną hierarchię kategorii, opartą na tym, jak wygląda asortyment, procesy zakupowe i sposób myślenia klientów. Przykładowo:

• najpierw podział na główne branże (Moda, Elektronika, Dom i Ogród),
• następnie grupy produktów (np. Moda → Obuwie → Obuwie męskie),
• dalej bardziej szczegółowe (Obuwie męskie → Buty sportowe, Eleganckie, Zimowe).

Mapowanie do struktury Allegro, Amazon itp. odbywa się na poziomie integracji, a nie w samym katalogu. Dzięki temu zmiana w strukturze marketplace nie rozwala wewnętrznej logiki i nie wymusza reorganizacji w ERP/PIM.

Atrybuty globalne i atrybuty specyficzne dla kategorii

Dane produktowe dzielą się na dwie grupy:

• atrybuty globalne – występujące praktycznie przy każdym produkcie, np. marka, EAN, SKU, kod producenta, kolor podstawowy, materiał główny, kraj produkcji,
• atrybuty kategorii – specyficzne dla danej grupy produktów, np. rozmiar buta, pojemność dysku, długość kabla, rodzaj gwintu żarówki, napięcie zasilania.

Porządek wymaga, żeby atrybuty globalne były zdefiniowane raz i stosowane w całym katalogu. Atrybuty kategorii powinny być przypisane tylko tam, gdzie mają sens. Próba wrzucenia “rozmiaru buta” jako atrybutu ogólnego kończy się albo masą pustych wartości, albo błędami przy innych produktach.

Dobrą praktyką jest budowa słowników wartości dla często używanych atrybutów (np. kolor, rozmiar, marka), aby uniknąć sytuacji typu “czerwony / czerwony jasny / czerwony-jasny / Red”. Jeden słownik = spójne dane, łatwe filtrowanie i bezproblemowe mapowanie na marketplace.

Projektowanie wariantów: produkt główny i SKU podrzędne

Produkty wariantowe są jednym z trudniejszych elementów katalogu. Klasyczny przykład: koszulka w pięciu kolorach i czterech rozmiarach. Z punktu widzenia klienta to “jedna koszulka w różnych wersjach”, ale z punktu widzenia magazynu – kilkanaście odrębnych SKU (np. TSHIRT-RED-M, TSHIRT-RED-L itd.).

Zdrowy model zakłada:

Model wariantowy krok po kroku

Produkty wariantowe najlepiej zorganizować w oparciu o jasny podział na produkt nadrzędny (tzw. model) i konkretne warianty (SKU). Dzięki temu katalog jest czytelny zarówno dla magazynu, jak i dla frontu sprzedaży.

Praktyczny model najczęściej wygląda tak:

• Produkt nadrzędny (model) – ma własny identyfikator (np. TSHIRT-CLASSIC), opis ogólny, główne zdjęcia, kategorie, część atrybutów wspólnych (marka, skład materiału, linia, grupa docelowa).
• Wariant (SKU podrzędne) – ma unikalny kod SKU (TSHIRT-CLASSIC-RED-M), własny EAN, atrybuty różnicujące (kolor, rozmiar, długość, pojemność), często też własne zdjęcia (np. zdjęcie każdego koloru).

Na poziomie katalogu istotne jest, aby wyraźnie rozdzielić atrybuty wspólne od wariantowych. Dzięki temu nie trzeba wprowadzać tego samego składu materiału czy marki przy 40 wariantach tej samej koszulki, a zmiana ogólnego opisu automatycznie “przechodzi” na wszystkie warianty.

Dla e‑commerce i marketplace’ów często wystawia się produkt nadrzędny jako kartę prezentującą, a warianty jako wybory (kolor, rozmiar) na froncie. Magazyn i ERP pracują już wyłącznie na poziomie SKU, bo to one mają konkretne stany i ceny zakupu.

Warianty a logika magazynowa i sprzedażowa

Z katalogiem wariantowym wiąże się kilka technicznych decyzji, które mają konsekwencje latami. Najważniejsze z nich:

• Czy każdy wariant ma osobny SKU i EAN? – odpowiedź w prawie każdym przypadku brzmi: tak. Ułatwia to przyjęcia na magazyn, zwroty, reklamacje oraz wystawianie dokumentów sprzedaży.
• Czy warianty mogą mieć różne ceny? – w wielu branżach tak (np. większy rozmiar, inna pojemność). Katalog musi to przewidywać, inaczej integracja z Allegro czy Amazon zaczyna kombinować “na skróty”.
• Jakie atrybuty budują wariant? – najlepiej ograniczyć się do 1–3 osi (np. kolor, rozmiar, pojemność). Kombinacja 5 osi kończy się katalogowym potworem, w którym nikt nie ogarnia, jakie warianty są naprawdę sprzedawane.

Spotykany błąd to mieszanie w jednym produkcie wariantów rozmiaru i zupełnie różnych funkcjonalności (np. inne wersje technologiczne). Wtedy klient widzi na stronie rozmiary, które tak naprawdę oznaczają różne modele – dokładna recepta na bałagan w zwrotach.

Powiązania między produktami: zestawy, akcesoria, zamienniki

W dobrze zorganizowanym katalogu produkty nie żyją w próżni. Dla omnichannelu kluczowe są powiązania, które z jednej strony zwiększają sprzedaż dodatkową, a z drugiej – pomagają klientowi dobrać właściwy towar.

Najczęściej stosowane typy powiązań to:

• zestawy (bundles) – kilka SKU sprzedawanych jako jedna oferta (np. laptop + torba + myszka),
• akcesoria – produkty uzupełniające (np. ładowarka do telefonu, filtr do odkurzacza),
• zamienniki – produkty kompatybilne, które mogą zastąpić oryginał,
• produkty powiązane tematycznie – “klienci kupili również”, “pasuje do stylu” itd.

Dla jednego katalogu istotne jest, aby powiązania były definiowane w jednym miejscu (zwykle w PIM lub sklepie) i dystrybuowane dalej do wszystkich kanałów. Jeżeli każdy marketplace ma własnoręcznie ustawiane rekomendacje, z czasem powstają cztery różne światy, a zmiana jednego produktu w zestawie wymaga poprawiania wszystkiego po kolei.

Szczególnie ważne są zamienniki techniczne w branżach typu automotive czy części zamienne. Mapowanie zamienników w katalogu centralnym (np. przez numery OE/OEM) pozwala później zautomatyzować podpowiedzi zarówno w sklepie, jak i na marketplace’ach. Ręczne dopisywanie “zamiennik/odpowiednik” w opisach to szybka droga do sprzecznych informacji.

Jakie dane produktowe są naprawdę krytyczne dla wielu kanałów

Trzy poziomy danych: minimalne, sprzedażowe, wzbogacone

Żeby katalog dobrze działał w wielu kanałach, trzeba rozróżniać poziomy “głębokości” danych. Innych informacji oczekuje system magazynowy, innych klient, a jeszcze innych wymagają marketplace’y.

Praktycznie można to podzielić na trzy grupy:

• Dane minimalne (techniczne) – niezbędne, aby produkt w ogóle mógł istnieć w systemach:
  • unikalny identyfikator (SKU, indeks),
  • nazwa techniczna / robocza,
  • grupa podatkowa, jednostka miary, waga logistyczna,
  • EAN / kod kreskowy (jeżeli występuje),
  • podstawowa kategoria wewnętrzna.
• Dane sprzedażowe – potrzebne do skutecznej sprzedaży w sklepie, B2B i na marketplace:
  • nazwa handlowa (czytelna dla klienta),
  • opis krótki i podstawowy opis długi,
  • główne zdjęcia (packshot + zdjęcie kontekstowe, jeżeli ma sens),
  • kluczowe atrybuty (te, które pojawiają się w filtrach i porównywarkach),
  • marka, model, główne cechy wyróżniające.
• Dane wzbogacone (content plus) – nie są krytyczne technicznie, ale robią różnicę w konwersji:
  • galeria zdjęć, infografiki, wizualizacje,
  • tabele rozmiarów, instrukcje PDF, karty katalogowe,
  • wideo produktowe, konfiguratory, poradniki,
  • treści SEO, slogany, claimy marketingowe.

Jedno źródło prawdy nie oznacza, że każdy produkt musi mieć od razu komplet wszystkiego. Ważne, żeby każde pole miało jasną definicję i właściciela (kto je uzupełnia, kto odpowiada za jakość), a proces wdrożenia omnichannel nie polegał na desperackim uzupełnianiu tysięcy kart “na wczoraj”.

Dane krytyczne z perspektywy marketplace

Marketplace’y są bezlitosne: brak kluczowych danych oznacza niższą widoczność lub w ogóle brak możliwości wystawienia oferty. Nawet najlepiej ustawiony katalog wewnętrzny na niewiele się zda, jeśli nie dostarcza minimalnego zestawu pól wymaganych przez Allegro, Amazon czy inne platformy.

Typowe krytyczne elementy to:

• identyfikatory produktowe – EAN/UPC, numer producenta, czasem numer katalogowy linii produktowej,
• kategoria marketplace – wskazana w sposób możliwie precyzyjny, zgodnie ze słownikiem danej platformy,
• kluczowe atrybuty wyszukiwane w filtrach – np. rozmiar, kolor, pojemność, materiał, kompatybilność,
• określenie stanu produktu – nowy, odnowiony, używany,
• parametry logistyczne – wymiary paczki, waga, wymagane informacje ADR lub inne ograniczenia wysyłki.

W praktyce najrozsądniej jest wdrożyć w katalogu “profil marketplace’owy” – zestaw pól, które zawsze muszą być uzupełnione, jeżeli produkt ma być sprzedawany poza własnym sklepem. PIM potrafi pilnować kompletności tych pól (tzw. completeness), ale nawet w prostszym modelu ERP + sklep można zbudować raporty wykrywające braki.

Spójność nazw i opisów: klient widzi, algorytm ocenia

Wielokanałowość szybko obnaża chaos w nazewnictwie. Ten sam produkt potrafi mieć w ERP skrótową nazwę techniczną, w sklepie – wersję “marketingową”, a na Allegro – trzeci wariant napisany “pod SEO”. Efekt: trudności z raportowaniem, zamieszanie przy obsłudze klienta i ryzyko zdublowanych ofert.

Rozsądne podejście to:

• jedna nazwa bazowa (systemowa) – czytelna wewnętrznie, powiązana ze SKU i kodem producenta,
• szablony nazw kanałowych – generowane z tych samych pól, ale zgodne z wytycznymi kanału (np. “Marka Model, kluczowy parametr, wariant”),
• opis główny + warianty opisów per kanał – przechowywane w PIM/sklepie jako osobne pola, ale odnoszące się do tych samych identyfikatorów.

Dzięki temu da się jednocześnie spełnić wymagania algorytmów marketplace (słowa kluczowe, długość tytułu, struktura opisu) i zachować spójność danych na poziomie katalogu. Zespół obsługi klienta nie musi wtedy zgadywać, czy “SuperPhone X Pro Black 128 GB” z Amazona to to samo, co “SPX-128-BLK” w ERP.

Mapowanie katalogu na Allegro, Amazon i inne marketplace

Warstwa pośrednia: mapa kategorii i atrybutów

Podstawowa zasada: logika katalogu wewnętrznego nie powinna być kopią logiki marketplace. Zamiast tego pomiędzy nimi powinna działać warstwa mapowania – zwykle obsługiwana przez PIM, integrator lub dedykowany moduł sklepu.

Mapa obejmuje dwa główne obszary:

• kategorie – każda kategoria wewnętrzna ma zdefiniowane odpowiedniki na poszczególnych marketplace’ach (czasem inne dla Allegro, inne dla Amazon),
• atrybuty – atrybut wewnętrzny (np. “Kolor”) jest powiązany z konkretnym parametrem danego kanału (“color_name”, “kolor”, “Main Color”), wraz z transformacją wartości, jeśli jest potrzebna.

To właśnie ta warstwa przyjmuje na siebie wszystkie “dziwactwa” poszczególnych platform – inne słowniki kolorów, różne wymagane pola, lokalne nazwy atrybutów. Dzięki temu sam katalog może pozostać w miarę logiczny i jednolity.

Mapowanie kategorii w praktyce

Budowa mapy kategorii jest procesem ciągłym, bo marketplace’y regularnie zmieniają i rozbudowują swoje drzewa. Żeby to miało ręce i nogi, warto przyjąć kilka zasad:

• każda kategoria wewnętrzna ma przypisane kategorie zewnętrzne – najlepiej w konfiguracji, a nie “na sztywno” w kodzie integracji,
• kategorie zewnętrzne są wersjonowane – tak, aby po zmianie struktury marketplace można było zaktualizować mapę bez naruszania historii,
• wyjątki są dokumentowane – jeżeli część produktów z jednej kategorii wewnętrznej musi trafić do różnych kategorii na marketplace, reguły powinny być przechowywane tam, gdzie każdy je znajdzie, a nie tylko w głowie jednego integratora.

Przykład z praktyki: kategoria wewnętrzna “Buty sportowe męskie” mapuje się na:

• Allegro → Moda → Obuwie → Męskie → Sportowe,
• Amazon.de → Schuhe & Handtaschen → Herren → Sportschuhe.

Różnice w głębokości drzewa i nazewnictwie nie są problemem, o ile mapa jest utrzymywana w jednym, przejrzystym miejscu.

Mapowanie atrybutów i wartości

Sama kategoria nie wystarczy – marketplace’y oczekują zestawu parametrów, zwykle różnego dla każdej kategorii. Tutaj znowu centrum dowodzenia powinien stanowić katalog, a nie arkusz Excela gdzieś na serwerze “do szybkich poprawek”.

Przy mapowaniu atrybutów kluczowe są trzy elementy:

• powiązanie nazw atrybutów – np. “Kolor (wewnętrzny)” → “color” na Amazon, → “Kolor dominujący” na Allegro,
• transformacja wartości – np. wewnętrzny słownik “ciemnoczerwony” mapuje się na “Red” na Amazon, a na “czerwony” na Allegro,
• uzupełnianie wymagań minimalnych – jeżeli marketplace wymaga np. “type” lub “target_audience” dla danej kategorii, trzeba zadbać, by katalog dostarczał te informacje.

Bez zcentralizowanego mapowania kończy się to kopiowaniem tych samych danych do kilku osobnych integracji, a przy każdej zmianie wymagań Allegro/Amazon zaczyna się wielkie łatanie. Jedno źródło prawdy plus jedna mapa atrybutów znacząco ograniczają ten sport ekstremalny.

Lokalizacja treści a marketplace

Przy sprzedaży zagranicznej dochodzi temat języków. W katalogu centralnym treści produktowe powinny być przechowywane w wielu wersjach językowych, ale nadal odnoszących się do jednego produktu. Każdy marketplace “dostaje” wtedy odpowiednią wersję.

Dobre praktyki:

• dla każdego produktu – pola opisowe i nazwy w językach, w których sprzedajesz (PL, EN, DE itd.),
• dla atrybutów tekstowych – słowniki wartości tłumaczone per język (np. “black / schwarz / czarny”),
• dla marketplace – możliwość wyboru, które pola opisowe są używane w którym kraju (np. inne nazwy dla Amazon.de, inne dla własnego sklepu w Niemczech).

Specyfika Allegro vs Amazon: jeden katalog, różne strategie

Allegro i Amazon często wrzuca się do jednego worka “marketplace’y”, ale z perspektywy katalogu produktowego zachowują się zupełnie inaczej. Jeżeli jeden katalog ma obsłużyć oba kanały, parę kwestii trzeba dobrze poukładać.

Najważniejsze różnice:

• model kart produktowych – na Amazonie kluczowe są globalne karty ASIN; na Allegro wciąż dominuje model “moja oferta, mój opis” (choć karty katalogowe też zyskują na znaczeniu),
• waga identyfikatorów – na Amazon praktycznie bez EAN/UPC lub numeru producenta nie da się żyć; Allegro bywa trochę bardziej wyrozumiałe, ale i tam brak identyfikatorów coraz częściej uderza w widoczność,
• polityka treści – Amazon ma dużo bardziej restrykcyjne wytyczne (zakazane frazy, formatowanie, styl), Allegro jest bardziej “lokalne” i elastyczne.

W praktyce oznacza to, że w jednym katalogu musisz trzymać:

• rdzeń danych wspólny (identyfikatory, wymiary, marka, atrybuty techniczne),
• warianty opisów i tytułów – osobne szablony pod Allegro i Amazon, generowane z tych samych pól bazowych,
• flagi kanałowe – czy dany produkt nadaje się na Amazon (np. kwestia brand registry, ograniczenia kategorii), czy tylko na Allegro / sklep.

Dobrym nawykiem jest wydzielenie w katalogu pól specyficznych dla Amazon (np. bullet points, search terms, subject matter) i pól specyficznych dla Allegro (np. osobne parametry wymagane tylko w niektórych kategoriach). Dzięki temu nie trzeba kombinować z dopisywaniem tych danych na etapie integracji – są częścią produktu od początku.

Obsługa wielu marketplace’ów: skalowanie mapy, nie chaosu

Allegro i Amazon to dopiero początek. Dochodzą lokalne platformy (Mall, eMAG, Kaufland, eBay), często z własnymi kaprysami. Bez mądrego podejścia łatwo wpaść w pułapkę: “dla tego marketplace’a mamy taki Excel, dla tamtego – inny”.

Przy większej liczbie kanałów sprawdza się układ:

• warstwa bazowa – katalog z własnym drzewem kategorii i neutralnymi atrybutami,
• warstwa kanałowa – konfiguracja per marketplace: mapowanie kategorii, atrybutów, słowniki wartości, szablony tytułów i opisów,
• warstwa techniczna – integracje API/plikowe, które nie zawierają już logiki biznesowej, tylko przenoszą dane tam, gdzie trzeba.

Każdy nowy marketplace to wtedy dopisanie kolejnej konfiguracji, a nie przebudowa katalogu od zera. Produkty pozostają te same, zmienia się tylko sposób, w jaki są “tłumaczone” na język danego kanału.

Ceny i stany magazynowe w jednym katalogu, wielu kanałach

Dlaczego jeden produkt potrzebuje wielu cen

Produkt jest jeden, ale rzeczywistości cenowe są co najmniej trzy: sklep internetowy, marketplace’y, czasem jeszcze sprzedaż hurtowa. Jeżeli katalog ma być faktycznie centralnym punktem zarządzania, musi sobie poradzić z różnymi modelami cenowymi.

Najczęściej spotykane scenariusze:

• inna cena bazowa per kanał – np. w sklepie taniej, na marketplace drożej (prowizje),
• promocje ograniczone do kanału – rabat tylko w sklepie lub tylko na Amazonie,
• ceny walutowe – ten sam produkt sprzedawany na różnych rynkach z lokalną walutą i podatkami.

Rozwiązaniem jest model, w którym cena nie jest cechą produktu “ogólnie”, tylko cechą produktu w konkretnym kontekście (kanał, kraj, grupa klientów). W katalogu dobrze się sprawdza struktura:

• cena bazowa (netto/brutto) + waluta,
• kanał (np. “WEB_PL”, “ALLEGRO”, “AMAZON_DE”),
• opcjonalnie – typ ceny (regularna, promocyjna, hurtowa),
• daty obowiązywania.

Na tej podstawie integracje wybierają i wysyłają odpowiednią cenę w odpowiednim momencie, a zespół ma jasność, skąd wzięła się konkretna kwota na danym marketplace. Znika też zjawisko “tajemniczych promocji”, które ktoś kiedyś włączył bez dokumentacji.

Polityka cenowa a algorytmy marketplace

Marketplace’y premiują atrakcyjne ceny, ale nie zawsze oznacza to “jak najtaniej”. Amazon bierze pod uwagę dostępność, czas wysyłki i historię sprzedaży; Allegro – również jakość sprzedawcy. Katalog musi więc wspierać dynamiczne podejście do cen, ale w kontrolowany sposób.

Praktyczny układ wygląda tak:

• katalog przechowuje ramy – minimalna, maksymalna cena dla produktu w danym kanale,
• moduł repricingu (zewnętrzny lub własny) operuje w tych ramach, reagując na konkurencję i parametry oferty,
• wszystkie zmiany cen są logowane z odniesieniem do produktu i kanału (żeby dało się odtworzyć, co się zadziało po weekendzie).

Bez centralnej informacji o dopuszczalnym zakresie cen łatwo obudzić się z produktem sprzedawanym poniżej kosztów, bo automat za bardzo się “postarał” w walce o Buy Box.

Stany magazynowe: jeden zapas, wiele półek

Sprzedaż wielokanałowa bez dobrego zarządzania stanami to proszenie się o kłopoty: podwójne sprzedaże, anulacje, marudni klienci. Katalog powinien być spięty z systemem, który traktuje zapas jako wspólną pulę – niezależnie od tego, czy produkt wystawiony jest w pięciu miejscach naraz.

Podstawowe modele:

• stock globalny – jeden stan, rozsyłany do wszystkich kanałów; limity sprzedaży ustalane po stronie marketplace (np. maksymalna ilość na ofertę),
• stock dzielony logicznie – np. 80% zapasu na wszystkie kanały, 20% zarezerwowane wyłącznie dla własnego sklepu lub sieci salonów,
• stock per magazyn – przy sprzedaży międzynarodowej; część zapasu w lokalnych magazynach FBA/FBM, część w centrali.

Kluczowe jest, by źródłem stanów był jeden system (najczęściej ERP/WMS), a katalog przechowywał informację, jak ten stan dzielić i prezentować w kanałach. Przykład: produkt ma w ERP 100 sztuk, ale w katalogu jest ustawiona reguła, że na Allegro pokazujemy maksymalnie 20, na Amazonie 30, a reszta trafia do sklepu.

Rezerwacje i zwroty: gdzie kończy się katalog

Katalog nie musi być systemem rezerwacji, ale powinien “rozumieć”, że stan dostępny to nie tylko fizyczny zapas, lecz także zamówienia w toku, zwroty w drodze i rezerwacje z innych źródeł (np. hurt). Dobrze zaprojektowany model danych przewiduje:

• pole na stan dostępny do sprzedaży (ATP – Available To Promise), aktualizowane przez ERP,
• flagę, czy produkt ma być automatycznie ukrywany przy stanie 0, czy może sprzedawać się w przedsprzedaży,
• parametry lead time (czas wysyłki) zależne od dostępności – inne dla produktów na stanie, inne dla “na zamówienie”.

Dzięki temu nie trzeba ręcznie biegać po ofertach na Allegro czy Amazonie, żeby wyłączać produkty “na chwilę brakujące”. Katalog wie, jaki jest status produktu, a integracje po prostu przekładają to na komunikaty w kanałach.

Procesy tworzenia i aktualizacji produktów: od dostawcy do marketplace

Standard danych od dostawcy: im wcześniej porządek, tym mniej bólu

Chaos w katalogu często zaczyna się już na wejściu – u dostawcy lub producenta. Każdy ma swój format: PDF, Excel, XML, czasem skan katalogu z targów z dopisaną ceną długopisem. Jeżeli te dane trafiają do systemu “jak leci”, trudno później oczekiwać, że Allegro czy Amazon dostaną od nas pięknie ustrukturyzowaną ofertę.

Dlatego opłaca się narzucić minimalny standard danych wejściowych. W praktyce sprowadza się to do:

• udostępnienia szablonu wymiany danych (np. CSV/XML/Excel) z jasno opisanymi polami,
• wymogu dostarczania identyfikatorów (EAN, kod producenta) i podstawowych parametrów technicznych,
• zdefiniowania, które pola są obowiązkowe, jeżeli produkt ma trafić na marketplace (profil marketplace’owy już na etapie onboardingu produktu).

Im więcej porządku w danych od dostawcy, tym mniej ręcznej roboty po stronie zespołu produktowego. A ludzie od oferty mają wtedy czas na faktyczne rozwijanie sprzedaży, zamiast przepisywać parametry z PDF-a.

Workflow tworzenia produktu: od szkicu do “go live”

Produkty rzadko rodzą się od razu kompletne. Najpierw ktoś wprowadza minimum danych, potem inna osoba dokłada zdjęcia, jeszcze ktoś poprawia opisy. Jeżeli katalog ma obsłużyć ten proces, potrzebuje stanów i ról, a nie tylko tabelki “produkty”.

Przykładowy workflow:

1. Draft – produkt założony technicznie (SKU, podstawowe identyfikatory), brak treści marketingowych; widoczny tylko wewnętrznie.
2. Do uzupełnienia – produkt przekazany do zespołu contentu; brakuje zdjęć, opisów, części atrybutów.
3. Gotowy do publikacji – komplet danych bazowych, profil marketplace’owy spełniony; produkt może pojawić się w sklepie i na marketplace’ach.
4. Aktywny – produkt wystawiony w kanałach, monitorowany pod kątem sprzedaży i opinii.
5. Wycofywany – stopniowe wygaszanie, blokada nowych ofert, ale zachowanie historii dla raportowania.

Do każdego etapu można przypisać checklistę pól, które muszą być uzupełnione, oraz właściciela (dział zakupów, marketingu, logistyki). PIM-y mają to zwykle out-of-the-box, ale nawet prostszy model w ERP czy sklepie daje ogromną różnicę w jakości danych.

Aktualizacje: kto, kiedy i co może zmienić

Największe awarie w katalogu biorą się często nie z braku danych, tylko z “twórczości własnej” różnych działów. Ktoś poprawi opis, ktoś inny cenę, ktoś trzeci atrybut logistyczny – bez koordynacji. Potem na Amazonie nagle pojawia się czajnik z opisem telefonu, a w sklepie monitor o wadze 0,1 kg.

Żeby tego uniknąć, warto jasno podzielić odpowiedzialności:

• dział zakupów – dane handlowe: dostawca, warunki zakupu, kategorie, podstawowe identyfikatory,
• dział produktowy/marketing – opisy, zdjęcia, atrybuty marketingowe, słowa kluczowe,
• logistyka – wymiary, waga, klasyfikacja transportowa, informacje o opakowaniach,
• dział cen i sprzedaży – ceny, polityka rabatowa, dostępność kanałowa.

Katalog (lub PIM) powinien wspierać ten podział uprawnieniami i historią zmian. Dzięki temu widać, kto i kiedy zmienił konkretne pole, a w razie problemów można szybko przywrócić poprzednią wersję. To takie “Ctrl+Z” dla całego omnichannelu.

Automaty vs. praca ręczna: gdzie postawić granicę

Kuszące jest zautomatyzowanie wszystkiego – od pobierania danych od dostawcy po wystawianie oferty na Amazonie. Rzeczywistość szybko pokazuje, że pełen automat często produkuje pełen bałagan. Rozsądne podejście to automatyzacja powtarzalnego, ręczna kontrola tego, co wpływa na konwersję i wizerunek marki.

Dobra linia podziału wygląda tak:

• w pełni automatycznie:
  • aktualizacja stanów magazynowych i cen (w ustalonych ramach),
  • uzupełnianie prostych atrybutów z feedów dostawców (np. kolor, materiał, wymiary),
  • mapowanie kategorii, gdy reguły są jasne i stabilne.
• półautomatycznie (z akceptacją):
  • tworzenie nowych produktów na podstawie danych od dostawcy,
  • generowanie szablonowych opisów i tytułów,
  • zmiany zasadnicze w nazwach kategorii czy strukturze atrybutów.
• ręcznie:
  • kluczowe treści marketingowe (główne opisy, infografiki),
  • decyzje o tym, czy produkt w ogóle ma trafić na dany marketplace,
  • wyjątkowe przypadki (produkty premium, skomplikowane konfiguracje).

Taki podział pozwala skalować ofertę (automaty robią swoje), a jednocześnie nie oddaje całkowitej kontroli nad wizerunkiem produktów w ręce algorytmów. Rynek zna już zbyt wiele historii o “genialnych” automatycznych tłumaczeniach, żeby iść tą drogą bezrefleksyjnie.

Feedback z kanałów z powrotem do katalogu

Co warto zapamiętać

• Jeden centralny katalog produktów jest „jednym źródłem prawdy” – każdy produkt ma jeden rekord i jeden identyfikator, z którego korzystają wszystkie kanały (sklep, marketplace’y, B2B, POS).
• Wiele rozdzielonych katalogów prowadzi do chaosu: rozjazdów cen, stanów magazynowych, opisów i zdjęć, co generuje błędy w zamówieniach, konflikty między działami i dodatkową ręczną pracę.
• Spójne dane produktowe bezpośrednio poprawiają wyniki: zwiększają konwersję, zmniejszają liczbę zwrotów, skracają czas obsługi klienta i ułatwiają rozpatrywanie reklamacji, bo wszędzie widać ten sam produkt w tej samej wersji.
• Centralny katalog przyspiesza rozwój i zmiany – nowa kolekcja, korekta cen czy wejście na kolejny marketplace oznacza uzupełnienie danych w jednym miejscu i podpięcie nowego „odbiornika”, zamiast budowania kolejnego katalogu od zera.
• Decyzja, gdzie trzymać główny katalog (ERP, PIM, platforma e‑commerce lub hybryda), powinna wynikać ze skali, złożoności oferty i liczby kanałów – nie ma jednego „świętego Graala”, ale musi być jasno określony system nadrzędny.
• ERP jako centrum katalogu sprawdza się przy prostym asortymencie i zbliżonych wymaganiach kanałów; gdy rośnie liczba atrybutów, wersji opisów i rynków, pojawia się potrzeba dedykowanego PIM zamiast „rozciągania” ERP ponad jego naturalne możliwości.

Bibliografia

• Omnichannel retail – A Deloitte Point of View. Deloitte (2015) – Omnichannel, spójność danych produktowych, wpływ na doświadczenie klienta
• Product Information Management for Dummies. Wiley (2015) – Wprowadzenie do PIM, centralny katalog, zarządzanie atrybutami i kanałami
• The Forrester Wave: Product Information Management Solutions. Forrester Research (2021) – Analiza systemów PIM, rola jednego źródła prawdy w omnichannel
• GS1 General Specifications. GS1 (2024) – Standardy identyfikacji produktów (EAN/GTIN), spójność SKU w wielu kanałach