Po co porządkować kartotekę towarów przed integracją z marketplace
Różnica między „działa jakoś” a skalowalną sprzedażą omnichannel
Sprzedaż na jednym kanale wybacza wiele bałaganu w danych produktowych. Gdy dochodzi Allegro, własny sklep, czasem Amazon czy inne marketplace’y, ten sam bałagan zaczyna mnożyć błędy, a każdy błąd jest wzmacniany automatyzacją. Integrator tylko przenosi to, co ma w kartotece – nie naprawia logiki biznesowej.
Dobrze przygotowana kartoteka towarów w ERP pozwala jednym kliknięciem wystawić setki ofert na różne kanały, z jednego miejsca kontrolować stany magazynowe, ceny i dostępność. Jeśli te dane są spójne, integrator po prostu „pompuje” je dalej. Jeśli są niespójne – przyspiesza powstawanie problemów: podwójna sprzedaż tego samego produktu, różne ceny w różnych kanałach, błędne EAN-y powodujące blokadę ofert.
Różnica między „działa jakoś” a skalowalną sprzedażą omnichannel jest więc prosta: w pierwszym wariancie każda zmiana w ofercie wymaga ręcznej kontroli, sprawdzania, przepisywania treści. W drugim – pracujesz na jednym, uporządkowanym źródle danych, które automatycznie dystrybuuje poprawne informacje do wszystkich marketplace’ów. Im większa skala sprzedaży, tym bardziej to widać.
Brudne dane a blokady ofert, zwroty i kary od marketplace
Allegro, Amazon i inne marketplace’y mają coraz bardziej rygorystyczne wymagania co do jakości danych. Brak EAN, błędne kategorie, mylące opisy, błędne atrybuty (np. zły rozmiar, materiał) – wszystko to przekłada się na:
odrzucone lub wstrzymane oferty (np. brak wymaganych parametrów, błędny EAN),
większy udział zwrotów (klient kupił coś innego, niż myślał na podstawie opisu i zdjęć),
negatywne opinie i niższe pozycjonowanie ofert w wynikach wyszukiwarki marketplace,
kary lub ograniczenia konta za powtarzające się niezgodności (szczególnie w przypadku błędnych opisów stanu, rozmiaru, kategorii).
Źródłem większości takich kłopotów nie jest sam marketplace, ale niedopracowana kartoteka towarów w ERP. Jeśli dane są wpisywane przypadkowo lub niejednolicie, integracja tylko ujawnia ten chaos i przenosi go na zewnątrz – do miejsca, gdzie każda pomyłka kosztuje realne pieniądze.
Jakość kartoteki a poziom automatyzacji procesów
Automatyzacja w modelu omnichannel opiera się na zaufaniu do danych. Jeśli ERP „wie”, że dany indeks ma określoną wagę, stawkę VAT, zestaw atrybutów i poprawny EAN, to integrator może automatycznie:
wystawić poprawną ofertę na Allegro i w sklepie internetowym,
zgodnie policzyć koszty wysyłki i podatki,
zarezerwować i pomniejszyć stan magazynowy,
wygenerować poprawne dokumenty sprzedaży i rozliczeń.
Gdy danych brakuje lub są niespójne, automatyzacja musi być „łagodzona” ręcznymi wyjątkami: listami produktów, których nie wystawiamy automatycznie, ręcznym poprawianiem opisów czy ręcznym uzupełnianiem wag i wymiarów do wysyłki. To zabija sens integracji – zamiast odciążyć, systemy generują kolejne zadania.
Mini-case: firma z porządkiem vs. firma z bałaganem
Dwa sklepy z podobnym asortymentem wprowadzały sprzedaż na Allegro. Pierwszy poświęcił kilka tygodni na uporządkowanie kartoteki: ujednolicenie nazw, uzupełnienie EAN-ów, scalanie duplikatów, rozdzielenie zestawów od produktów pojedynczych, przygotowanie atrybutów pod kategorie Allegro. Integracja zajęła technicznie kilka dni, a potem sprzedaż rosła już przy minimalnej obsłudze ręcznej.
Drugi sklep podłączył integrator „na żywca”, do istniejącej kartoteki budowanej przez lata. Efekt? Oferty duplikowały się, część była blokowana z powodu braków danych, a różne kanały pokazywały odmienne ceny i stany. W praktyce przez pierwsze miesiące zespół spędzał czas na gaszeniu pożarów zamiast rozwijania sprzedaży. Finalnie i tak trzeba było wrócić do punktu wyjścia – porządkowania kartoteki w ERP.
Źródło: Pexels | Autor: Christina Morillo
Jaką rolę pełni ERP i kartoteka w modelu omnichannel
Kartoteka jako „źródło prawdy” o produkcie
W modelu omnichannel ERP powinien pełnić rolę źródła prawdy o produkcie. Oznacza to, że wszystkie kluczowe informacje – identyfikatory, stany, ceny, podstawowe opisy – mają jedno główne miejsce przechowywania. To z ERP korzystają integratory, sklepy internetowe, systemy WMS, a czasem nawet systemy księgowe.
Ręczne wklepywanie ofert na Allegro, a osobno w sklepie i osobno w katalogu B2B może działać, dopóki mamy kilkadziesiąt produktów. Powyżej pewnej skali każda zmiana (np. nowa cena zakupu, zmiana VAT, aktualizacja opisu technicznego) wymaga przepisywania tych samych danych w trzech–czterech miejscach. Błąd jest tylko kwestią czasu.
Jeśli kartoteka w ERP jest dobrze zaprojektowana, konfiguracja nowego kanału sprzedaży polega głównie na mapowaniu pól: który atrybut z ERP odpowiada któremu polu na Allegro, jaki symbol to SKU, jaka kategoria wewnętrzna ma się mapować na konkretną kategorię marketplace. Nie trzeba wtedy „łatać” danych każdorazowo pod nowy kanał – wystarczy raz dobrze zaprojektować strukturę.
Co typowo przechowuje kartoteka towarów
Standardowa kartoteka towarów w ERP przechowuje znacznie więcej niż tylko nazwę i cenę. W modelu nastawionym na integrację z marketplace’ami powinna zawierać co najmniej:
dane identyfikacyjne: indeks wewnętrzny, symbol produktu, EAN/GTIN, kod producenta, ewentualnie inne kody (np. logistyczne),
dane logistyczne: waga, wymiary, jednostka miary, typ produktu (towar, komplet, usługa),
dane podatkowe: stawka VAT, ewentualne oznaczenia specjalne (np. MPP, marża turystyczna),
dane sprzedażowe: ceny (podstawowa, promocyjna, hurtowa), waluty, rabaty, zasady naliczania,
dane magazynowe: stany, rezerwacje, magazyny, minimalne i maksymalne zapasy,
dane marketingowe: skrócone i dłuższe opisy, słowa kluczowe, atrybuty (kolor, rozmiar, materiał itd.),
Im więcej z tych informacji jest w jednym miejscu, tym łatwiej automatyzować podstawowe procesy: tworzenie ofert, przeliczanie cen, synchronizację stanów czy generowanie danych pod kampanie reklamowe (np. feed produktowy dla Google Merchant Center).
Przepływy danych między ERP, marketplace i integratorem
W typowym scenariuszu omnichannel przepływ danych można uprościć do kilku kierunków:
ERP → marketplace przez integrator: dane produktowe (oferty), ceny, stany magazynowe,
marketplace → ERP: zamówienia (pozycje, dane klienta), informacje o płatnościach, numery przesyłek,
ERP → kurier / system wysyłkowy: dane do etykiet, waga, wymiary, zawartość,
To, jak wygodne i bezbłędne będą te przepływy, zależy wprost od jakości i spójności kartoteki. Prawidłowe powiązanie indeksu ERP z SKU na Allegro, poprawne stawki VAT, jasne rozróżnienie produktów prostych i zestawów – to wszystko decyduje, czy integracja zamówień i rozliczeń będzie rzeczywistą automatyzacją, czy tylko „pół-automatem” wymagającym ciągłej kontroli.
Gdzie kończy się ERP, a zaczyna integrator
ERP odpowiada za logikę biznesową, kartotekę towarów, stany, ceny i dokumenty. Integrator (Baselinker, Shoper, Selesto, autorskie moduły, własne API) jest przede wszystkim warstwą komunikacyjną – tłumaczy dane z ERP na format zrozumiały dla marketplace’ów i odwrotnie.
Praktyczna zasada brzmi: dane referencyjne i logika są w ERP, reguły wystawiania ofert i mapowania kategorii – w integratorze. Nie ma sensu rozbijać podstawowych informacji produktowych na wiele systemów, bo każda modyfikacja wymaga wtedy synchronizacji struktur. Lepiej dążyć do modelu, w którym integrator „czyta” dobrze ułożoną kartotekę, a jego główne zadania to:
mapowanie atrybutów i kategorii na konkretne marketplace,
obsługa wielu kont / wielu krajów na tym samym marketplace,
buforowanie i kolejkowanie aktualizacji, aby nie „zabić” API platform.
Minimalny zestaw danych produktowych potrzebny do integracji
Dane identyfikacyjne: symbol produktu, EAN, SKU, kody producenta
Podstawą jest jasna identyfikacja produktu. W kartotece, która ma się integrować z Allegro i innymi kanałami, minimalny zestaw identyfikatorów obejmuje:
indeks wewnętrzny (kod w ERP) – techniczny identyfikator wykorzystywany wewnątrz firmy i systemów,
symbol / SKU – kod, który pojawi się w integratorach i na marketplace’ach (może być identyczny z indeksem lub osobny),
EAN/GTIN – globalny kod kreskowy łączący oferty i ułatwiający automatyczne rozpoznawanie produktu przez marketplace,
kod producenta – przydatny przy produktach markowych i w pracy z dostawcami,
nazwa produktu – uporządkowana, według przyjętego schematu (np. Marka + Model + Kluczowy parametr).
Brak EAN-u nie zawsze uniemożliwia sprzedaż (np. przy produktach własnych), ale mocno utrudnia życie. Allegro i Amazon coraz częściej wymagają prawidłowych kodów GTIN, aby połączyć oferty od różnych sprzedawców. Dobrze nadany EAN zmniejsza też ryzyko duplikacji ofert.
Dane logistyczne: waga, wymiary, jednostki i podatki
Żeby sprzedaż na marketplace’ach mogła zostać w pełni zautomatyzowana, kartoteka musi zawierać realistyczne dane logistyczne. W praktyce chodzi co najmniej o:
waga jednostkowa (najlepiej brutto, wraz z opakowaniem),
jednostka miary (szt., komplet, opakowanie, metr itd.),
stawka VAT oraz ew. oznaczenia specjalne (dla branż z wyjątkami podatkowymi),
kraj pochodzenia – coraz częściej wymagany przy sprzedaży międzynarodowej i wybranych kategoriach.
Te dane są wykorzystywane nie tylko przez marketplace, ale także przez systemy kurierskie i księgowe. Bez nich trudno zautomatyzować tworzenie etykiet, wyliczanie kosztów wysyłki czy generowanie poprawnych dokumentów sprzedaży przy międzynarodowej ekspansji.
Dane sprzedażowe: ceny, waluty, dostępność
Marketplace’y oczekują zawsze aktualnych cen i informacji o dostępności. W kartotece powinny być uwzględnione co najmniej:
cena podstawowa (brutto/netto w zależności od przyjętego modelu w ERP),
cena promocyjna lub dodatkowe poziomy cen (np. hurt, B2B), jeśli będą wykorzystywane,
wprowadzone waluty, jeśli sprzedaż ma odbywać się na rynkach zagranicznych,
stan dostępny oraz logika zamawialności (sprzedaż tylko z magazynu, przedsprzedaż, dropshipping),
minimalne ilości zakupu, jeśli występują (np. sprzedaż tylko w paczkach po 10 sztuk).
Model omnichannel wymaga jasnego określenia, które ceny obowiązują w którym kanale. Część firm stosuje oddzielne poziomy cen w ERP przypisane do poszczególnych marketplace’ów, inne korzystają z reguł przeliczania po stronie integratora (np. narzut +x% na Amazon). W obu przypadkach potrzebna jest przejrzysta, spójna struktura cenowa w kartotece.
Dane marketingowe: opisy, zdjęcia i podstawowe atrybuty
Minimalny pakiet marketingowy niezbędny do poprawnego wystawienia oferty na marketplace obejmuje:
skrótowy opis / tytuł – często ograniczony znakami (np. tytuł aukcji Allegro),
dłuższy opis – treści, które można potem przetwarzać lub skracać pod konkretne kanały,
minimum jedno zdjęcie – najlepiej w wysokiej rozdzielczości, na neutralnym tle,
informacje o gwarancji i warunkach użytkowania, jeśli są istotne.
Struktura nazw i opisów pod kątem wielu kanałów
Jedna, uniwersalna nazwa rzadko sprawdza się we wszystkich kanałach. Allegro, własny sklep, porównywarka cen i Amazon mają inne limity znaków, inne wytyczne i inny sposób wyświetlania oferty. Dlatego w kartotece lepiej od razu wydzielić kilka pól tekstowych, zamiast trzymać wszystko w jednym „opisie ogólnym”.
Praktyczne podejście to:
nazwa techniczna w ERP – krótka, zrozumiała dla magazynu, handlowca i serwisu (np. bez zbędnych haseł marketingowych),
nazwa sprzedażowa – bardziej „marketingowa”, gotowa do użycia jako tytuł oferty, ale nadal oparta na stałym schemacie,
opis podstawowy – neutralny, bez odniesień do konkretnego marketplace, możliwie modułowy: bloki tekstu, które można mieszać, skracać i tłumaczyć,
opis rozszerzony – pełen, z tabelą parametrów, instrukcją użytkowania, informacjami o gwarancji, materiałach itp.
Dzięki temu integrator może pobierać zawsze te same pola z ERP, a tylko w razie potrzeby je skracać, czyścić z HTML lub dodawać elementy charakterystyczne dla danego kanału (np. schemat sekcji w szablonie Allegro).
Standardy zdjęć: jedno źródło, wiele wymagań
Zdjęcia produktów to jeden z najczęstszych problemów przy integracji. Marketplace’y wymagają nie tylko odpowiedniej rozdzielczości, ale też tła, proporcji, braku znaków wodnych czy reklam konkurencyjnych serwisów. Jeśli każde zdjęcie jest trzymane „gdzieś na dysku”, trudno nad tym zapanować.
W kartotece warto zdefiniować przynajmniej taki zestaw danych graficznych:
zdjęcie główne – standardowe „packshot” na białym lub jasnym tle, w wysokiej rozdzielczości,
zdjęcia dodatkowe – detale, zdjęcia kontekstowe (produkt w użyciu), różne ujęcia,
miniatury – wersje zoptymalizowane rozmiarowo, jeśli system ERP lub PIM to obsługuje,
kolejność zdjęć – zapisana jako osobne pole lub atrybut, tak aby integrator wiedział, które zdjęcie jest pierwsze, drugie itd.
Przydaje się także prosty schemat nazewnictwa plików (np. oparty na SKU + numer zdjęcia). Dzięki temu łatwiej później znaleźć i podmienić grafiki, a także generować linki, które będą używane przez integratora w feedach produktowych.
Atrybuty jako podstawa filtrowania i pozycjonowania
Atrybuty produktów, takie jak kolor, rozmiar, materiał czy pojemność, nie są tylko „ładnym dodatkiem”. Algorytmy marketplace’ów korzystają z nich do filtrowania, rekomendacji i pozycjonowania ofert. Dobrze ułożone atrybuty w kartotece przekładają się więc na realną widoczność produktów.
W praktyce chodzi o trzy elementy:
lista atrybutów globalnych – wspólna dla całej oferty (np. kolor, materiał, waga),
atrybuty specyficzne dla kategorii – np. „rodzaj gwintu” w oświetleniu, „rodzaj zasilania” w elektronarzędziach,
spójne słowniki wartości – zamiast „czerwony / czerwony mat / czerwony (RAL 3000)” warto mieć ustalony, krótszy zestaw nazw i dodatkowe pole opisowe, jeśli trzeba doprecyzować szczegóły.
Dobrą praktyką jest, by pola atrybutów w ERP były możliwie generyczne (np. „kolor_podstawowy”, „material_korpusu”), a dopiero warstwa integratora tłumaczyła je na konkretne atrybuty Allegro czy innego marketplace’u.
Źródło: Pexels | Autor: Tima Miroshnichenko
Struktura kartoteki: produkty proste, warianty i zestawy
Produkty proste – fundament każdej kartoteki
Produkty proste to pojedyncze pozycje bez wariantów rozmiaru czy koloru. Dla integracji z marketplace’ami są one najłatwiejsze, ale to na nich opiera się później logika wariantów i zestawów. Dlatego ważne jest, aby każdy produkt prosty był kompletny informacyjnie: miał swoje identyfikatory, wagę, stawkę VAT i podstawowe atrybuty.
Przy produktach prostych łatwo popełnić błąd typu „jeden indeks, różne opakowania” – np. ten sam towar sprzedawany w opakowaniu 1 szt. i 10 szt. Powinny to być dwa różne produkty w kartotece, z różnymi jednostkami i kodami, nawet jeśli fizycznie to ten sam wyrób.
Produkty wariantowe: kolory, rozmiary, wersje
Większość branż (odzież, obuwie, elektronika, wyposażenie wnętrz) działa na produktach wariantowych. Na jednej karcie produktowej występuje wiele opcji – np. różne rozmiary lub kolory. Marketplace’y oczekują, że takie relacje będą jasno opisane i odwzorowane w strukturze danych.
W kartotece wygodnie sprawdza się podział na:
produkt główny (rodzic) – opisuje „rodzinę” produktu: ogólny opis, główne zdjęcia, wspólne cechy,
warianty (dzieci) – zawierają konkretne atrybuty różnicujące (np. kolor = „czarny”, rozmiar = „M”) oraz unikalne kody (indeks, EAN).
Każdy wariant powinien być w kartotece osobnym rekordem z własnym stanem magazynowym i własnym EAN-em. Produkt główny może być technicznym „parasolem”, który nie jest bezpośrednio sprzedawany – jego zadaniem jest spinać warianty w logiczną całość dla integratora i marketplace’ów.
Na Allegro czy Amazonie taka struktura pozwala pokazać kupującemu wszystkie dostępne opcje w jednym miejscu, zamiast tworzyć kilkanaście osobnych ofert dla każdego koloru i rozmiaru. Integrator potrzebuje więc jasnej informacji, które rekordy w ERP są wariantami tego samego produktu.
Zestawy i komplety: sprzedaż wiązana w praktyce
Zestawy (bundles, komplety) to produkty składające się z kilku innych pozycji z kartoteki. Mogą to być zarówno stałe komplety (np. „łóżko + materac”), jak i zestawy promocyjne tworzone okresowo (np. „drukarka + 2 tonery w prezencie”). Z punktu widzenia integracji i magazynu to jeden z trudniejszych obszarów.
W kartotece najlepiej zdefiniować:
produkt-zestaw – osobny indeks z własną ceną, EAN-em (jeśli istnieje) i opisem sprzedażowym,
skład zestawu – listę produktów prostych (komponentów) z ilościami, które wchodzą w skład kompletu,
zasady rezerwacji stanów – informację, czy stan zestawu jest liczony dynamicznie na podstawie komponentów, czy utrzymywany jako osobny zasób magazynowy.
Przykładowo: jeśli sprzedajesz „zestaw ogrodowy: stół + 4 krzesła”, integrator, wystawiając ofertę na Allegro, powinien widzieć ten zestaw jako osobny produkt. ERP musi z kolei zadbać o to, aby sprzedaż kompletu odpowiednio obniżała stany stołu i krzeseł. To wymaga przejrzystej definicji relacji między nimi.
Produkty wirtualne, usługi i dodatki
Coraz więcej firm sprzedaje nie tylko fizyczne towary, ale też usługi lub dodatki – np. montaż, konfigurację sprzętu, dodatkową gwarancję. Z perspektywy marketplace’ów są to zwykle osobne typy ofert, czasem z innymi ograniczeniami i warunkami.
W kartotece warto oznaczyć:
typ pozycji – towar fizyczny, usługa, dostęp cyfrowy,
powiązania z produktami fizycznymi – np. „montaż dotyczy tylko drzwi z tej kategorii”,
zasady dostępności – usługa może mieć praktycznie nieskończony stan, ale ograniczenia czasowe (terminy, regiony, godziny pracy ekip).
Dzięki temu integrator może poprawnie wystawiać zarówno same produkty, jak i oferty łączone (np. produkt + montaż) w ramach jednego procesu, bez ręcznego tworzenia kombinacji na każdym marketplace.
Identyfikatory produktów: EAN, SKU, indeks w ERP i inne kody
Spójna polityka nadawania SKU i indeksów
SKU (Stock Keeping Unit) i indeks w ERP bywają używane zamiennie, ale nie muszą oznaczać tego samego. Indeks bywa technicznym identyfikatorem w bazie, a SKU – kodem widocznym na dokumentach, w integratorach i na marketplace’ach. Kluczowe jest, aby cała organizacja stosowała jeden, ustalony schemat.
Popularne podejścia to:
SKU = indeks ERP – najprostszy wariant, łatwy w utrzymaniu,
SKU jako kod „czytelny dla człowieka” – np. zawierający skrót kategorii, producenta i numery wariantu,
rozdzielenie indeksu technicznego i SKU – indeks jest tylko w bazie, a SKU występuje w systemach zewnętrznych; obydwa pola są trwale powiązane.
Niezależnie od wyboru schematu, ważne jest unikanie ponownego używania tego samego SKU dla innych produktów. Marketplace’y traktują SKU jako jedno ze źródeł identyfikacji, więc „recykling” kodów po wycofanych produktach prowadzi do bałaganu w ofertach i raportach.
EAN/GTIN – kiedy konieczny, a kiedy opcjonalny
Globalne kody kreskowe (EAN/GTIN) pełnią kilka ról jednocześnie: ułatwiają pracę magazynowi, przyspieszają identyfikację produktów u dostawców i przede wszystkim pozwalają marketplace’om rozpoznać, że sprzedajesz ten sam produkt co inni sprzedawcy. Dzięki temu oferta może zostać „podpięta” pod istniejącą kartę katalogową platformy.
W strukturze kartoteki dobrze jest przyjąć zasadę:
każdy wariant produktu ma swój unikalny EAN,
produkty bez EAN (np. wyroby własne, produkty customowe) są oznaczone wyraźnym atrybutem,
zakazane jest współdzielenie jednego kodu EAN pomiędzy różnymi indeksami (np. różne kolory lub rozmiary).
Na Allegro i Amazonie brak EAN-u coraz częściej blokuje możliwość wystawienia oferty w niektórych kategoriach. W takich sytuacjach jedynym wyjściem jest uzyskanie własnej puli kodów (np. poprzez organizację GS1) i uporządkowanie ich przypisania do kartoteki.
Oprócz SKU i EAN-u przydają się też inne identyfikatory: kody producenta, numery katalogowe dostawców, symbole części zamiennych. Nie wszystkie będą widoczne na marketplace’ach, ale znacznie ułatwiają zarządzanie kartoteką, zwłaszcza gdy pracują na niej różne działy: zakupy, sprzedaż, serwis.
Przykładowy zestaw dodatkowych kodów obejmuje:
kod producenta – zwykle ten, który pojawia się w oficjalnych katalogach,
kod dostawcy – pomocny, gdy ten sam produkt kupujesz od kilku źródeł, każde z innym symbolem,
kody logistyczne – np. oznaczenia opakowań zbiorczych, palet, opakowań transportowych.
Te pola w większości przypadków nie są wymagane przez Allegro, ale integrator może je wykorzystać np. do wiązania produktów z feedami dostawców, automatycznego uzupełniania opisów czy weryfikacji poprawności EAN-ów.
Identyfikatory wewnętrzne integratorów i marketplace’ów
Każdy marketplace i część integratorów tworzy własne identyfikatory techniczne dla produktów i ofert. Przy większej skali sprzedaży warto pozwolić ERP-owi przechowywać te numery, nawet jeśli na początku wydają się zbędne.
Można tu wyróżnić m.in.:
ID oferty na Allegro,
ID produktu w katalogu marketplace (jeśli platforma rozróżnia „produkt” i „ofertę”),
ID wewnętrzne integratora – często służące do mapowania między różnymi kanałami.
Jeśli te identyfikatory są spięte z kartoteką ERP, łatwiej później wykonywać masowe operacje: zamykać i wznawiać oferty, zmieniać parametry w wybranym segmencie asortymentu, czy analizować historię sprzedaży danego indeksu we wszystkich kanałach naraz.
Źródło: Pexels | Autor: RDNE Stock project
Atrybuty, kategorie i mapowanie na Allegro oraz inne marketplace
Drzewo kategorii wewnętrzne vs. drzewo kategorii marketplace
Każda firma ma swój własny podział asortymentu: dział, grupa, podgrupa, linia produktowa. Allegro, Amazon czy inne platformy mają natomiast własne drzewa kategorii, zaprojektowane z myślą o użytkownikach tych serwisów. Próba „przepisania” struktury jednej do drugiej 1:1 zwykle kończy się konfliktem.
Rozsądniejsze jest podejście dwuwarstwowe:
wewnętrzna klasyfikacja produktów – stabilna, dostosowana do procesów w firmie,
warstwa mapowania na kategorie zewnętrzne – trzymana w integratorze lub w dodatkowej tabeli w ERP.
Standardowe atrybuty wspólne dla wielu kanałów
Atrybuty produktowe (parametry) to nic innego jak opisane cechy towaru: wymiary, kolor, materiał, przeznaczenie. Marketplace’y wykorzystują je do filtrowania, wyszukiwania i podpowiadania klientów. Im lepiej są opisane, tym łatwiej produkt znajduje kupującego – także algorytmy lepiej go klasyfikują.
Najprościej zacząć od zdefiniowania zestawu atrybutów bazowych, które są potrzebne niezależnie od kanału sprzedaży. To taki „wspólny mianownik”, który ERP przechowuje raz, a integrator przetwarza na format poszczególnych marketplace’ów.
Typowy rdzeń atrybutów obejmuje m.in.:
wymiary i waga – osobno dla produktu i dla opakowania (logistyka, kurierzy, Fulfillment by Amazon itp.),
kolor / wariant kolorystyczny – najlepiej w formie słownika, a nie dowolnego tekstu,
rozmiar / długość – np. rozmiary odzieży, długość przewodu, pojemność zbiornika,
materiał – bawełna, MDF, stal nierdzewna, szkło hartowane,
marka / producent – wykorzystywana później do mapowania na markę z katalogu Allegro czy Amazona.
W pierwszym kroku celem nie jest odwzorowanie wszystkich pól Allegro 1:1, tylko uporządkowanie tego, co powtarza się w większości kategorii. Resztę można dobudowywać stopniowo, od najważniejszych grup asortymentu.
Atrybuty specyficzne dla kategorii i kanałów
Większość marketplace’ów ma rozbudowane listy parametrów obowiązkowych i opcjonalnych, różne dla każdej kategorii. W elektronice będzie to np. pojemność dysku, typ złącza, rodzaj matrycy, a w kosmetykach – rodzaj skóry, składniki aktywne, forma aplikacji.
W ERP opłaca się wydzielić atrybuty specyficzne dla kategorii. Działa to w praktyce tak:
każda wewnętrzna kategoria (np. „Laptopy 15–16 cali”) ma przypisany zestaw parametrów technicznych,
produkty z tej kategorii muszą mieć wypełnione dane w tym zestawie, zanim trafią do integratora,
integrator mapuje te parametry na odpowiednie pola Allegro, Amazona czy innego marketplace’u.
Dzięki temu nie trzeba tworzyć osobnych pól „tylko pod Allegro”. Atrybut „pojemność dysku” istnieje w kartotece jako cecha produktu, a dopiero niżej warstwa integracji decyduje, czy i jak wysłać go do danego kanału.
Mapowanie słowników wartości na wymagania marketplace
Wszystkie platformy próbują standaryzować wartości atrybutów. Kolor „czarny” może być wymagany jako „czarny”, „black” albo „Czarny (Black)”. Jeśli ERP pozwala wpisywać wartości zupełnie dowolnie, szybko pojawiają się dziesiątki odmian: „czarny”, „Czarny”, „czar”, „bk”. Algorytmy filtrowania po drugiej stronie tego nie lubią.
Rozwiązaniem jest centralny słownik wartości po stronie ERP:
każdy atrybut ma zdefiniowaną listę dopuszczalnych wartości (np. lista kolorów, lista materiałów),
integrator trzyma tabelę mapującą te wartości na słowniki wymagane przez poszczególne marketplace’y,
gdy Allegro zmienia słownik (np. łączy dwa kolory), poprawkę wprowadza się tylko w mapowaniu, a nie w tysiącach rekordów.
W praktyce bardzo pomaga prosty mechanizm „aliasów”: „czarny mat”, „czarny połysk” mogą być w ERP osobnymi wartościami, ale do Allegro wysyłane jako „czarny”, a do innej platformy – jako dwie osobne opcje, jeśli na to pozwala.
Pola pomocnicze do kontroli kompletności danych
Same atrybuty to nie wszystko. Przy większej kartotece potrzebne są też mechanizmy kontroli, czy dane są wystarczające do wystawienia ofert. Zamiast ręcznie sprawdzać dziesiątki pól, lepiej wprowadzić proste wskaźniki jakości danych.
W ERP lub w integratorze sprawdza się np.:
status kompletności danych – np. „podstawowe”, „gotowy na Allegro”, „gotowy na Amazon”,
licznik brakujących atrybutów krytycznych – z możliwością raportowania, które konkretnie pola są puste,
flagi jakości treści – np. „opis marketingowy ok”, „brak zdjęć lifestyle’owych”, „brak tłumaczenia na EN”.
Taki prosty system kolorów lub statusów (czerwony–żółty–zielony) pozwala działowi produktowemu skupić się najpierw na towarach, które są najbliżej wejścia na nowe marketplace’y.
Opisy, zdjęcia i dane marketingowe przygotowane pod marketplace
Opis techniczny a opis sprzedażowy
Opis produktu można rozumieć na dwa sposoby. Z jednej strony to suchy zestaw informacji technicznych, z drugiej – tekst, który ma przekonać klienta i pokazać korzyści. W kartotece dobrze jest oddzielić te dwie warstwy.
Praktyczny układ pól w ERP wygląda często tak:
opis techniczny – skrócony, bez „marketingowych” wtrętów; może być bazą do kart katalogowych B2B,
opis marketingowy – pisany językiem korzyści, z akapitami, nagłówkami, listami wypunktowanymi,
opis skrócony – kilka zdań używanych jako „lead” na karcie produktu lub w listingach.
Integrator może następnie korzystać z tych pól na różne sposoby: Allegro otrzymuje opis marketingowy, a inna platforma – bardziej techniczny, jeśli tak lepiej pasuje do jej standardu. Dzięki temu nie trzeba utrzymywać osobnych „wersji Allegro” w zewnętrznych plikach.
Długość i struktura tekstu a wymagania kanałów
Każdy marketplace ma swoje limity: maksymalną długość tytułu, ograniczenia liczby znaków w polach czy zakazy dotyczące formatowania HTML. Warto więc zawczasu przygotować teksty tak, aby łatwo je było przycinać lub dzielić.
Sprawdza się m.in.:
tytuł bazowy produktu – nieco dłuższy, „pełny”, przechowywany w ERP,
pole na skrócony tytuł – mieszczący się spokojnie w limitach Allegro lub innego kanału,
opis podzielony na sekcje – np. „najważniejsze cechy”, „zastosowanie”, „specyfikacja techniczna”, co ułatwia budowanie szablonów opisów.
Jeżeli ERP nie pozwala na rozbudowane formatowanie, można dodać prosty system „znaczników” (np. ###NAGŁÓWEK###), które integrator zamieni później na odpowiednie style. Dzięki temu w kartotece przechowywana jest czysta treść, a wygląd dopasowuje się do wymagań kanału.
SEO dla marketplace a nazewnictwo w ERP
Marketplace to w praktyce wyszukiwarka produktów. Klienci wpisują frazy typu „granatowa sukienka midi”, a algorytm dobiera wyniki. Jeśli nazwa w ERP brzmi „Sukienka Verona 12345 granat M”, to część ważnych słów wciąż się tam znajduje, ale można to zrobić lepiej.
Dobrym kompromisem jest:
nazwa wewnętrzna – krótka, wygodna dla magazynu i dokumentów (np. „Verona 12345 granat M”),
nazwa sprzedażowa – bogatsza w słowa kluczowe, przeznaczona do marketplace’ów (np. „Granatowa sukienka midi Verona z wiskozy, rozmiar M”).
W kartotece obie nazwy łączy ten sam indeks. Integrator decyduje, którą wersję wysłać do danego kanału. W razie potrzeby można dodatkowo dodać pola z słowami kluczowymi, jeśli któryś marketplace umożliwia ich zasilanie osobno.
Bank zdjęć powiązany z kartoteką
Zdjęcia są często przechowywane „gdzieś na dysku” lub w osobnym DAM-ie (Digital Asset Management). Dla integratora kluczowe jest jednak, aby każdy produkt miał jednoznaczne powiązanie z zestawem plików graficznych i informacją, które z nich są używane w jakiej kolejności.
W kartotece przydają się co najmniej:
lista URL-i zdjęć lub ID plików z systemu DAM,
typ zdjęcia – główne, zbliżenie detali, aranżacyjne (lifestyle), zdjęcie opakowania,
kolejność wyświetlania, aby integrator wiedział, które zdjęcie wysłać jako pierwsze,
informacja o wariancie – które zdjęcia należą do konkretnego koloru czy rozmiaru.
W przypadku produktów wielowariantowych najlepiej powiązać zdjęcia zarówno z produktem „parasolem”, jak i z wariantami. Fotografie wspólne (np. pokazujące szczegóły konstrukcji) podpinane są do produktu głównego, a zdjęcia konkretnego koloru – do danego wariantu.
Wymagania techniczne zdjęć na marketplace’ach
Każdy marketplace wymusza pewne parametry zdjęć: minimalną rozdzielczość, tło (często białe), brak znaków wodnych, zakaz dodawania cen i logotypów. Jeśli fotograf produkuje grafiki „jak leci”, później trzeba część z nich odrzucać lub przerabiać, co kosztuje czas i pieniądze.
Dobrą praktyką jest:
zdefiniowanie standardu zdjęć bazowych – np. rozdzielczość, format, tło, marginesy,
oznaczenie w kartotece, czy dany produkt ma już zdjęcia zgodne z tym standardem,
trzymanie metadanych o zdjęciu (np. orientacja, proporcje), aby integrator mógł zdecydować, które nadają się do miniatur.
Część firm prowadzi nawet dwa zbiory: zdjęcia „pełne” pod sklep internetowy i osobny komplet „ugrzeczniony” pod marketplace’y, gdzie regulaminy są surowsze. Kartoteka powinna wspierać takie rozróżnienie choćby przez flagę typu „do marketplace”.
Coraz więcej platform pozwala dołączać do ofert pliki z instrukcjami, kartami katalogowymi czy certyfikatami bezpieczeństwa. W branżach takich jak elektronarzędzia, AGD czy produkty dla dzieci ma to realny wpływ na konwersję i liczbę reklamacji.
W strukturze danych warto powiązać z produktem:
instrukcje montażu / obsługi – najlepiej w kilku językach, jeśli planowana jest sprzedaż międzynarodowa,
karty charakterystyki (np. dla chemii, kosmetyków),
certyfikaty – np. atesty bezpieczeństwa, deklaracje zgodności, oznaczenia energetyczne,
ulotki produktowe – przydatne przy sprzedaży B2B i na platformach hurtowych.
Integrator może z tych zasobów korzystać na dwa sposoby: albo załączać pliki tam, gdzie platforma to umożliwia, albo podawać linki prowadzące do materiałów hostowanych na serwerze sprzedawcy. Kluczowe jest, aby identyfikator produktu był spoiwem między kartoteką, plikami i ofertą.
Wielojęzyczność treści produktowych
Sprzedaż na kilku rynkach naraz wymaga uporządkowanego podejścia do tłumaczeń. Ręczne kopiowanie opisów z Excela do kolejnych wersji językowych zwykle kończy się chaosem. Dużo lepiej traktować język jako dodatkowy wymiar kartoteki.
W praktyce każdy kluczowy element treści (tytuł, opis, parametry opisowe) może mieć:
język bazowy – np. polski lub angielski jako wersja źródłowa,
pola tłumaczeń – osobne kolumny lub powiązane rekordy dla DE, EN, CZ itd.,
status tłumaczenia – „w tłumaczeniu”, „do aktualizacji”, „zatwierdzone”.
Integrator korzysta wtedy z odpowiedniej warstwy językowej w zależności od rynku docelowego. Jeśli dla któregoś języka brakuje opisu, może np. wstrzymać publikację oferty albo tymczasowo użyć wersji angielskiej, zgodnie z przyjętymi zasadami.
Ceny, promocje i komunikaty sprzedażowe w kartotece
Choć ceny kojarzą się bardziej z polityką handlową niż z opisem produktu, w modelu omnichannel są częścią „paczki” danych wysyłanych na marketplace. Kartoteka nie musi przechowywać całej logiki rabatowej, ale powinna mieć jasno zdefiniowane pola, z których korzystają kanały zewnętrzne.
Najczęściej przydają się:
cena bazowa (katalogowa) – wspólna dla wszystkich kanałów lub dla wybranego segmentu,
cena minimalna – poniżej której systemy automatyczne (np. repricer) nie powinny schodzić,
flagi promocyjne – czy produkt kwalifikuje się do konkretnych akcji: „Smart!”, „Outlet”, „Wyprzedaż kolekcji”,
Najczęściej zadawane pytania (FAQ)
Dlaczego muszę porządkować kartotekę towarów przed integracją z Allegro?
Bo integracja nie naprawia błędów, tylko je mnoży. Jeśli w ERP są braki w EAN-ach, niespójne nazwy, duplikaty czy pomylone stawki VAT, integrator przeniesie ten chaos do Allegro, sklepu i innych kanałów. Przy kilku produktach da się to „ogarnąć ręcznie”, przy setkach ofert każda pomyłka kosztuje czas, zwroty i gorszą widoczność ofert.
Uporządkowana kartoteka pozwala jednym kliknięciem wystawiać setki poprawnych ofert, mieć spójne ceny i stany oraz unikać typowych blokad typu „błędny EAN” czy „brak wymaganych parametrów”. To fundament, na którym dopiero opłaca się budować automatyzację.
Jakie dane o produkcie są kluczowe do sprzedaży na Allegro i innych marketplace’ach?
Podstawą są dane identyfikacyjne i logistyczne, czyli m.in.: indeks wewnętrzny, symbol produktu, EAN/GTIN, kod producenta, waga, wymiary, jednostka miary oraz informacja, czy to towar, komplet czy usługa. Bez tego integrator nie wystawi poprawnie oferty ani nie policzy sensownie wysyłki.
Druga grupa to dane podatkowe i sprzedażowe: stawka VAT, ceny (podstawowa, promocyjna, ewentualnie hurtowa), waluty i zasady rabatowania. Trzecia – marketingowa: nazwy, krótkie i długie opisy, atrybuty (rozmiar, kolor, materiał), relacje między produktami (zestawy, warianty, zamienniki). Im więcej z tego jest w ERP, tym mniej „dopisywania” w samym Allegro.
Jakie błędy w kartotece najczęściej powodują blokady ofert na Allegro?
Najczęstsze powody problemów to brak lub błędny EAN, źle dobrane kategorie, mylące opisy oraz nieprawidłowe atrybuty, np. zły rozmiar czy materiał. Allegro i Amazon coraz mocniej to egzekwują – odrzucają oferty, wstrzymują je, a przy powtarzających się błędach potrafią ograniczyć konto.
Źródłem tych kłopotów zwykle nie jest sam marketplace, tylko kartoteka w ERP: dane wpisywane „na szybko”, różne formaty nazw, duplikaty produktów, mieszanie zestawów z pojedynczymi towarami. Gdy integrator zaczyna to wysyłać do Allegro, problemy wychodzą na wierzch i zamieniają się w zwroty, reklamacje i negatywne opinie.
Jak przygotować kartotekę w ERP do sprzedaży omnichannel krok po kroku?
Najprościej zacząć od porządków: usunięcia lub scalenia duplikatów, ujednolicenia nazw i symboli, rozdzielenia produktów pojedynczych od zestawów. Potem warto uzupełnić EAN-y, kody producenta, wagi i wymiary – bez tego trudno zautomatyzować oferty i wysyłkę. Dobrym ruchem jest też ustalenie jednego schematu nazewnictwa (np. „Marka – model – cecha kluczowa”).
Kolejny etap to dopasowanie kartoteki do wymagań marketplace’ów: przygotowanie atrybutów pod kategorie Allegro, zwłaszcza rozmiary, kolory, materiały, typ produktu. Na końcu sprawdza się spójność stawek VAT, cen i jednostek miary. Dobrze przygotowana kartoteka sprawia, że konfiguracja integratora sprowadza się głównie do mapowania pól, a nie „łataniu” każdego produktu osobno.
Czy wystarczy, że mam dobrze opisane produkty w Allegro, jeśli w ERP jest bałagan?
To działa tylko na krótką metę. Jeśli Allegro, sklep i inne kanały żyją „własnym życiem”, każda zmiana – nowa cena, nowa stawka VAT, aktualizacja opisu – wymaga ręcznego powtarzania w kilku miejscach. Przy większej liczbie SKU błąd jest kwestią czasu, a integracja zamówień i stanów staje się bardzo trudna.
W modelu omnichannel ERP pełni rolę „źródła prawdy” o produkcie. To z niego pobierają dane integrator, sklep internetowy, WMS czy system księgowy. Jeśli w ERP jest porządek, nie trzeba za każdym razem „ręcznie ratować” ofert w Allegro – zmiany wprowadza się raz, a systemy rozsyłają je dalej.
Jaką rolę pełni integrator (np. Baselinker) w porównaniu z ERP przy sprzedaży na Allegro?
ERP przechowuje logikę biznesową: kartotekę towarów, stany magazynowe, ceny, stawki VAT i dokumenty sprzedaży. Integrator jest warstwą komunikacyjną – tłumaczy dane z ERP na format Allegro, sklepu, Amazona i innych kanałów, a w drugą stronę przekazuje zamówienia i informacje o płatnościach.
Praktycznie oznacza to tyle, że: dane referencyjne (np. EAN, waga, opis) utrzymuje się w ERP, a w integratorze definiuje się reguły wystawiania ofert, mapowania kategorii, dopasowania atrybutów. Jeśli kartoteka w ERP jest dopracowana, integrator może bez większych wyjątków automatycznie wystawiać i aktualizować oferty zamiast tworzyć długą listę „problemowych” produktów do ręcznego ogarniania.
Jak brak spójnych danych w kartotece wpływa na automatyzację zamówień i wysyłek?
Przy spójnych danych ERP „wie”, jaka jest waga produktu, stawka VAT, EAN, atrybuty i powiązania między indeksami. Dzięki temu integrator może automatycznie wystawić ofertę, zsynchronizować stany, pobrać zamówienie, zarezerwować towar, policzyć koszty wysyłki i wygenerować poprawne dokumenty. Obsługa ręczna ogranicza się wtedy do wyjątków biznesowych, a nie do poprawiania każdego zamówienia.
Gdy danych brakuje lub są niespójne, trzeba tworzyć wyjątki: listy produktów niewystawianych automatycznie, ręczne poprawki opisów, dopisywanie wag przed nadaniem paczek. Zamiast zyskać automatyzację, firma przenosi pracę z przeglądarki do integratora. Na dużej skali to różnica między spokojną obsługą a ciągłym „gaszeniem pożarów”.
Co warto zapamiętać
Porządek w kartotece towarów to różnica między „działa jakoś” a skalowalną sprzedażą omnichannel – dopiero spójne dane pozwalają jednym kliknięciem wystawiać setki ofert i bezpiecznie je automatyzować.
Integrator nie naprawia bałaganu w ERP – tylko go zwielokrotnia w Allegro, sklepie i innych kanałach, co skutkuje duplikatami ofert, różnymi cenami i ryzykiem podwójnej sprzedaży tych samych produktów.
Brudne dane (brak EAN, błędne kategorie, mylące opisy, złe atrybuty) bezpośrednio przekładają się na blokady ofert, zwroty, negatywne opinie i kary od marketplace’ów, czyli realne straty finansowe.
Poziom automatyzacji zawsze jest ograniczony jakością kartoteki – im więcej braków i niespójności, tym więcej „ręcznych wyjątków”, łatania opisów i ręcznego liczenia wysyłek, co zabija sens integracji.
ERP powinien być jednym „źródłem prawdy” o produkcie; gdy wszystkie kluczowe dane są trzymane i poprawiane w jednym miejscu, dodanie nowego kanału sprzedaży sprowadza się głównie do mapowania pól.
Uporządkowanie kartoteki przed startem na Allegro (scalanie duplikatów, ujednolicenie nazw, komplet EAN-ów, rozdzielenie zestawów od pojedynczych produktów) zwykle skraca wdrożenie i ogranicza późniejsze gaszenie pożarów.
Dobra kartoteka to nie tylko nazwa i cena – integracja wymaga także poprawnych danych identyfikacyjnych, logistycznych, podatkowych, sprzedażowych i magazynowych, inaczej systemy nie są w stanie działać w pełni automatycznie.
