Jak przygotować katalog produktów na 5 rynków, bez tworzenia 5 kopii tego samego produktu?

Producent sprzedający ten sam produkt w Polsce, Czechach, Słowacji, Niemczech i Austrii nie musi utrzymywać pięciu niezależnych katalogów. Może korzystać ze wspólnych danych produktowych, zachowując osobne opisy, ceny, dostępność i ofertę dla każdego rynku. Jak zaprojektować taki katalog i uniknąć problemów, które pojawiają się przy ekspansji zagranicznej?

Dlaczego kopiowanie katalogu produktów na kolejne rynki to ryzykowny pomysł?

Załóżmy, że producent oświetlenia posiada 2000 SKU i prowadzi sprzedaż internetową w Polsce.

Firma planuje wejście do Czech. Najszybsze rozwiązanie wydaje się oczywiste: skopiować istniejący katalog, przetłumaczyć opisy, zmienić walutę, przygotować lokalne ceny i uruchomić sklep.

Po kilku miesiącach podobny proces powtarza się przy wejściu na Słowację. Później dochodzą Niemcy i Austria.

W pewnym momencie firma ma pięć katalogów zawierających w dużej mierze te same produkty.

Problem pojawia się przy pierwszej większej aktualizacji.

Producent zmienia specyfikację jednego z modeli lamp. W nowej partii stosowany jest inny zasilacz, dlatego zmienia się jeden z parametrów technicznych i dokumentacja produktu.

W polskim katalogu dane zostają poprawione. W czeskim również. Niemiecki zespół aktualizuje opis, ale nie wymienia załączonej instrukcji. Z kolei na rynku austriackim pozostaje stara wartość parametru.

W efekcie klienci w różnych krajach otrzymują niespójne informacje o tym samym produkcie.

A przecież firma wykonała tylko jedną zmianę w specyfikacji.

Przy kilku produktach można jeszcze próbować kontrolować takie sytuacje ręcznie. Przy tysiącach SKU, wielu językach i regularnych aktualizacjach zaczyna to pochłaniać coraz więcej czasu.

Najbardziej odczuwalne problemy to:

Powtarzanie tej samej pracy. Jeden parametr techniczny trzeba aktualizować osobno w kilku katalogach.
Rozbieżności między rynkami. Ten sam produkt może mieć różne wymiary, materiały lub inne parametry, mimo że jego rzeczywista specyfikacja jest identyczna.
Trudniejsze zarządzanie wariantami. Nowy rozmiar, kolor lub wersja produktu wymaga odpowiedniego dodania i powiązania w każdym katalogu.
Większe ryzyko podczas importów. Masowa aktualizacja danych może przypadkowo nadpisać lokalne opisy, ceny lub ustawienia.
Rosnąca liczba wyjątków. Po pewnym czasie trudno ustalić, czy dana różnica między katalogami jest zamierzona, czy wynika z pominiętej aktualizacji.

Dlatego przed uruchomieniem kolejnego rynku warto ustalić, które dane rzeczywiście muszą być niezależne, a które powinny pozostać wspólne.

Jeden produkt, kilka lokalnych ofert. Jak podzielić dane?

Podstawą dobrze przygotowanego katalogu międzynarodowego jest rozdzielenie informacji o samym produkcie od informacji dotyczących jego sprzedaży w konkretnym kraju.

W praktyce warto uwzględnić cztery zakresy danych.

1. Dane wspólne dla wszystkich rynków

To informacje, które identyfikują produkt i opisują jego rzeczywiste właściwości.

Przykładowo:

SKU,
EAN/GTIN, jeśli dotyczy tej samej jednostki handlowej,
struktura produktów i wariantów,
parametry techniczne,
podstawowe wymiary i materiały,
większość zdjęć produktowych,
relacje pomiędzy produktami.

Jeżeli producent sprzedaje dokładnie tę samą lampę w pięciu krajach, jej moc nie powinna być zapisywana jako pięć niezależnych parametrów.

Wspólna wartość może zostać wykorzystana we wszystkich wersjach produktu.

2. Dane zależne od języka

Do tej grupy należą informacje wymagające tłumaczenia lub dostosowania komunikacji.

Przede wszystkim:

nazwy produktów,
krótkie i długie opisy,
nazwy parametrów i ich wartości tekstowe,
instrukcje i materiały językowe,
wybrane treści marketingowe.

Warto rozdzielić samą wartość techniczną od etykiety widocznej dla klienta.

Przykładowo parametr opisujący materiał może posiadać jeden wewnętrzny kod ALU, a obok niego etykiety:

PL: aluminium,
CZ: hliník,
SK: hliník,
DE: Aluminium.

Dzięki temu tłumaczenie etykiety nie zmienia znaczenia parametru w ERP, PIM i pozostałych systemach.

3. Dane zależne od rynku

Tutaj znajdują się informacje, które mogą różnić się nawet pomiędzy krajami korzystającymi z tego samego języka.

Przykłady:

lokalne ceny,
waluty,
promocje,
zakres oferowanych produktów,
możliwość realizacji zamówienia,
terminy dostawy,
regionalne treści SEO,
wybrane materiały i informacje wymagane na konkretnym rynku.

Niemcy i Austria są dobrym przykładem.

Oba rynki mogą korzystać z tej samej podstawowej niemieckiej nazwy i opisu produktu. Firma może jednak prowadzić inną politykę cenową, oferować inny asortyment albo stosować odmienne warunki dostawy.

Dlatego język i rynek powinny być rozpatrywane oddzielnie.

4. Dane zależne od kanału sprzedaży

Producent może sprzedawać te same produkty w sklepie D2C, na marketplace i przez platformę B2B.

Każdy kanał może potrzebować innego zestawu informacji.

Przykładowo marketplace może wymagać określonej struktury tytułu, dodatkowych atrybutów lub przypisania produktu do własnej klasyfikacji kategorii. Sklep D2C może natomiast korzystać z rozbudowanych opisów, materiałów wideo i własnej struktury kategorii.

Te różnice również powinny być uwzględnione w modelu danych, zamiast tworzenia kolejnej niezależnej kartoteki produktu.

Przykładowy podział danych w katalogu międzynarodowym

Informacja	Zakres danych
SKU produktu	Wspólny
EAN/GTIN	Wspólny dla tej samej jednostki handlowej
Struktura wariantów	Wspólna
Moc, materiał, wymiary	Wspólne dla identycznej wersji produktu
Nazwa produktu	Językowy, ewentualnie z wyjątkiem regionalnym
Etykiety parametrów	Językowy
Opis marketingowy	Językowy lub regionalny
SEO title i meta description	Lokalny dla docelowej wersji strony
Cena i promocja	Rynkowy lub zależny od cennika
Oferta produktowa	Rynkowy
Dostępność sprzedażowa	Zależna od magazynu, kanału i zasad realizacji
Wymagane instrukcje i dokumenty	Zależne od produktu, języka i rynku
Kategoria na marketplace	Zależna od kanału sprzedaży

Taki podział pozwala utrzymywać wspólne dane bez ograniczania pracy osób odpowiedzialnych za lokalne sklepy.

Jest jednak jeden warunek: każdy rodzaj informacji musi mieć określone źródło i zasady aktualizacji.

Pięć rynków nie oznacza pięciu języków ani pięciu niezależnych produktów

Wróćmy do producenta oświetlenia, który sprzedaje na pięciu rynkach.

Rynek	Język	Waluta
Polska	Polski	PLN
Czechy	Czeski	CZK
Słowacja	Słowacki	EUR
Niemcy	Niemiecki	EUR
Austria	Niemiecki	EUR

Firma obsługuje pięć rynków, ale potrzebuje czterech podstawowych wersji językowych.

Weźmy jeden produkt:

SKU: LMP-100

Jest to czarna lampa biurkowa LED o mocy 12 W.

W centralnym katalogu przechowujemy wspólne informacje:

SKU: LMP-100,
moc: 12 W,
kolor: czarny,
materiał obudowy: aluminium,
wysokość: 40 cm,
zdjęcia produktu,
powiązania z wariantami.

Do tego dochodzą wersje językowe i ustawienia sprzedaży.

Rynek	Nazwa produktu	Przykładowe różnice
Polska	Lampa biurkowa LED 12 W	Opis PL, ceny PLN, lokalne SEO
Czechy	Stolní LED lampa 12 W	Opis CZ, ceny CZK, lokalne SEO
Słowacja	Stolová LED lampa 12 W	Opis SK, ceny EUR, lokalne SEO
Niemcy	LED-Schreibtischlampe 12 W	Opis DE, oferta DE, lokalne SEO
Austria	LED-Schreibtischlampe 12 W	Oferta AT, lokalne ceny i ewentualne różnice w treści

Przykład ma charakter ilustracyjny.

Teraz załóżmy, że producent zmienia wysokość lampy z 40 na 42 cm.

Jeżeli nadal mamy do czynienia z tą samą jednostką asortymentową, aktualizujemy właściwy parametr w systemie źródłowym. Zmiana powinna następnie trafić do wszystkich odpowiednich kanałów i wersji produktu.

Nie trzeba ręcznie edytować pięciu niezależnych wartości.

To jednak nie zwalnia z kontroli lokalnych opisów. Jeżeli niemiecki copywriter wpisał wcześniej „40 cm” bezpośrednio w treści marketingowej, zmiana parametru technicznego nie musi automatycznie poprawić tego fragmentu.

Dlatego przy projektowaniu katalogu warto ograniczać ręczne powielanie danych technicznych w opisach. Tam, gdzie to możliwe, lepiej korzystać z uporządkowanych atrybutów lub wprowadzić proces weryfikacji treści po zmianie specyfikacji.

Właśnie w takich szczegółach widać różnicę między uporządkowanym katalogiem a zbiorem niezależnie przygotowywanych kart produktowych.

Czy jeden produkt powinien mieć to samo SKU na wszystkich rynkach?

Zasadniczo tak, pod warunkiem że mówimy o tej samej jednostce asortymentowej.

Jeśli firma sprzedaje identyczną lampę w Polsce i Niemczech, lokalizacja opisu albo zmiana waluty nie jest wystarczającym powodem, aby nadawać jej nowy SKU.

Przykładowo:

Prawidłowy model dla tego samego produktu:

Polska: LMP-100
Czechy: LMP-100
Słowacja: LMP-100
Niemcy: LMP-100
Austria: LMP-100

Wspólny identyfikator ułatwia powiązanie danych pomiędzy ERP, PIM, Magento, WMS i pozostałymi systemami.

Trzeba jednak uważać na sytuacje, w których pozornie identyczna oferta dotyczy w rzeczywistości różnych produktów handlowych.

Kiedy osobny SKU ma sens?

Wyobraźmy sobie producenta elektroniki, który przygotowuje urządzenie w dwóch wersjach:

z wtyczką przeznaczoną na rynek europejski,
z wtyczką przeznaczoną na rynek brytyjski.

Jeżeli produkty są osobno produkowane, magazynowane i kompletowane, powinny być odpowiednio rozróżniane w systemach.

Podobnie może wyglądać sytuacja z zestawami o innym składzie, produktami o zmienionej specyfikacji czy osobnymi jednostkami handlowymi.

Wtedy utworzenie odrębnego SKU może być konieczne.

Natomiast dopisek DE, CZ czy AT w SKU, dodawany wyłącznie po to, aby przygotować lokalną wersję językową, zwykle wprowadza niepotrzebną komplikację.

Temat szczegółowo omówiliśmy w artykule Dlaczego SKU powinno być praktycznie niezmienne?.

Jak podzielić odpowiedzialność za dane między ERP, PIM i Magento?

Nawet dobrze przygotowany podział na dane wspólne i lokalne nie rozwiąże problemu, jeśli kilka systemów będzie mogło niezależnie zmieniać tę samą informację.

W firmach produkcyjnych dane produktowe najczęściej funkcjonują w kilku miejscach.

ERP może odpowiadać za kartoteki towarowe, dane logistyczne, ceny i operacje magazynowe. PIM może przechowywać opisy, parametry, tłumaczenia i multimedia. Magento potrzebuje informacji umożliwiających wyświetlenie produktu i obsługę sprzedaży.

Dlatego przed przygotowaniem katalogu na nowe rynki należy określić, który system jest źródłem prawdy dla poszczególnych pól.

ERP – tożsamość produktu i dane operacyjne

W przykładowej architekturze producenta ERP może odpowiadać za:

nadawanie SKU,
podstawowe kartoteki produktów,
jednostki miary,
wybrane parametry logistyczne,
cenniki, jeśli są zarządzane w ERP,
dane o zapasach, jeżeli ERP pełni taką funkcję.

Nowy produkt powstaje w ERP, a następnie jego identyfikator i odpowiednie dane są przekazywane do pozostałych systemów.

PIM – wspólne informacje produktowe i ich lokalizacja

PIM może odpowiadać za przygotowanie informacji wykorzystywanych w poszczególnych kanałach sprzedaży.

Przykładowo:

nazwy i opisy,
parametry techniczne,
tłumaczenia,
strukturę wariantów,
zdjęcia i dokumentację,
powiązania między produktami,
kompletność danych przed publikacją.

W takim modelu jeden produkt może mieć zestaw wspólnych właściwości oraz wiele lokalnych wersji treści.

Magento – prezentacja oferty i sprzedaż

Magento otrzymuje dane produktowe potrzebne do obsługi lokalnych sklepów.

Może zarządzać między innymi:

widocznością produktów,
przypisaniem produktów do odpowiednich website’ów,
ustawieniami sprzedażowymi,
promocjami,
procesem zakupowym,
wybranymi elementami merchandisingowymi.

Ceny i dostępność mogą natomiast pochodzić z ERP, WMS lub innych systemów, zależnie od przyjętej architektury.

Nie wszystkie informacje muszą przechodzić przez PIM. Aktualizacje stanów magazynowych mogą trafiać bezpośrednio do Magento, jeśli taki przepływ lepiej odpowiada procesom firmy.

Najważniejsze, aby dla każdego pola było jasne, kto może je edytować, kto publikuje jego wartość i które systemy są odbiorcami.

Więcej na ten temat pisaliśmy w artykule Gdzie powinien być master danych produktowych: ERP, PIM czy Magento?.

Jak wykorzystać PIM do zarządzania katalogiem na pięciu rynkach?

System PIM staje się szczególnie przydatny wtedy, gdy firma musi przygotowywać ten sam produkt dla wielu języków, rynków i kanałów sprzedaży.

Przykładowo Pimcore umożliwia zbudowanie modelu danych obejmującego produkty, warianty, atrybuty, tłumaczenia i zasoby cyfrowe.

W praktyce producent może przechowywać jeden zestaw wspólnych parametrów, a osobno przygotowywać treści lokalne.

Pimcore posiada między innymi mechanizm Localized Fields, pozwalający zarządzać wartościami pól w różnych językach. Obsługuje również dziedziczenie i konfigurację języków zapasowych, co opisano w oficjalnej dokumentacji Pimcore.

Trzeba jednak zwrócić uwagę na dwa zagadnienia.

Tłumaczenie nie zawsze wystarcza do lokalizacji

Jeżeli Niemcy i Austria mają korzystać z różnych cen, ofert lub wybranych opisów, samo zapisanie niemieckiej wersji językowej nie wystarczy.

Model danych powinien umożliwiać przypisanie odpowiednich informacji do konkretnego rynku.

Można to rozwiązać przez zaprojektowanie dodatkowych pól, relacji lub struktur przechowujących regionalne odstępstwa.

Sposób implementacji zależy od architektury PIM i wymagań firmy.

Dziedziczenie danych musi mieć określone zasady

Przykładowo producent może przyjąć następujące reguły:

Jeśli produkt nie ma osobnego zdjęcia dla Austrii, korzysta ze zdjęcia wspólnego.
Jeżeli nie przygotowano regionalnego opisu dla Austrii, może wykorzystać zatwierdzony opis niemiecki.
Jeżeli zmienia się wspólna wartość techniczna, aktualizacja trafia do wszystkich odpowiednich wersji.
Jeżeli brakuje obowiązkowej instrukcji lub wymaganej informacji lokalnej, produkt nie uzyskuje statusu gotowego do publikacji.

Istotne jest zwłaszcza ostatnie rozróżnienie.

Automatyczne dziedziczenie danych może oszczędzać pracę, ale nie powinno maskować braków w informacjach wymaganych do sprzedaży.

Jeżeli produkt musi posiadać instrukcję w określonym języku, brak dokumentu powinien być widoczny w systemie.

Warto kontrolować kompletność oddzielnie dla każdego rynku

Produkt może być w pełni przygotowany do sprzedaży w Polsce, ale nadal wymagać tłumaczenia instrukcji na język czeski.

Dlatego status „gotowy do publikacji” powinien uwzględniać wymagania konkretnego rynku lub kanału.

Przy dużym katalogu taki mechanizm pozwala szybko ustalić, co faktycznie blokuje publikację kolejnych produktów.

Jak Magento 2 obsługuje wiele rynków bez kopiowania produktów?

Magento 2 posiada natywne mechanizmy umożliwiające zarządzanie wieloma sklepami i wersjami językowymi w jednej instalacji.

Ich podstawą jest hierarchia:

Website → Store → Store View

Każdy z tych poziomów pełni inną funkcję.

Website – ustawienia sprzedaży

Website jest najwyższym poziomem struktury sklepu.

Pozwala rozdzielać określone elementy konfiguracji sprzedażowej, w tym bazową walutę i wybrane ustawienia cenowe.

W Magento zakres cen katalogowych może być globalny albo przypisany do website. Oznacza to, że możliwość stosowania niezależnych cenników trzeba uwzględnić już podczas projektowania struktury sklepów.

Jeżeli polski i niemiecki rynek wymagają odrębnych cen bazowych, sama konfiguracja kolejnych Store View nie zapewni takiej niezależności w standardowym modelu cenowym.

Store – struktura katalogu

Store pozwala organizować katalog produktów, między innymi z wykorzystaniem odrębnej kategorii głównej.

Może to mieć znaczenie, gdy poszczególne sklepy wymagają innej struktury nawigacji.

Jednocześnie produkty mogą nadal korzystać ze wspólnych kartotek.

Store View – lokalizacja treści

Store View jest wykorzystywany przede wszystkim do obsługi języków i odpowiednich wersji prezentacyjnych.

Dzięki temu ten sam produkt może mieć polską, czeską i niemiecką nazwę, opis oraz inne atrybuty, których zakres pozwala na lokalizację.

Nie wszystkie pola mają jednak taki sam zakres. Część wartości jest globalna, część obowiązuje na poziomie website, a inne można ustawiać indywidualnie dla Store View.

Dlatego struktura danych w PIM musi odpowiadać temu, jak informacje będą przechowywane i wykorzystywane w Magento.

Szczegóły opisuje dokumentacja Adobe Commerce dotycząca Website, Store i Store View.

Czy każdy kraj potrzebuje osobnego Website?

Niekoniecznie.

Jeżeli różnice dotyczą głównie języka, dodatkowe Store View mogą okazać się wystarczające.

Jeżeli rynki wymagają niezależnych cen, przypisania produktów, walut bazowych lub innych ustawień sprzedażowych, trzeba rozważyć odpowiednią konfigurację Website.

Ważne jest także zarządzanie dostępnością.

W standardowym Magento Inventory Management wirtualne zasoby magazynowe, czyli stocks, są powiązane z kanałami sprzedaży na poziomie website.

Utworzenie pięciu Store View nie oznacza więc automatycznie uzyskania pięciu niezależnych dostępności magazynowych.

Jeżeli firma ma jeden magazyn obsługujący kilka krajów, należy ustalić zasady wspólnego wykorzystania zapasów. Jeśli różne rynki mają korzystać z odrębnych źródeł lub ograniczeń dostępności, trzeba uwzględnić to w architekturze.

O wyborze struktury Magento powinny decydować rzeczywiste różnice w sprzedaży, a nie sama liczba krajów.

Jak uniknąć nadpisywania lokalnych danych przez integrację?

To jeden z problemów, które warto rozwiązać jeszcze przed pierwszym importem.

Załóżmy, że producent zarządza informacjami produktowymi w PIM, a sprzedaż prowadzi na Magento.

Polska i niemiecka wersja produktu mają osobne opisy.

Pracownik odpowiedzialny za rynek niemiecki poprawia lokalną treść, uwzględniając uwagi dotyczące sposobu prezentacji produktu.

Następnego dnia integracja uruchamia masową synchronizację.

Zamiast przesłać wyłącznie zmieniony parametr techniczny, przekazuje cały zestaw danych produktu. W wyniku błędnie zaprojektowanego mapowania niemiecki opis zostaje nadpisany polskim.

Import zakończył się bez błędu technicznego. Problem dostrzega dopiero osoba przeglądająca niemiecki sklep.

Takie sytuacje wynikają z braku jasno określonych zasad aktualizacji pól.

Co trzeba ustalić przed uruchomieniem synchronizacji?

Przede wszystkim:

Zakres pola. Czy jego wartość jest globalna, językowa, regionalna czy zależna od kanału?
Źródło prawdy. Który system odpowiada za aktualizację?
Kierunek przepływu. Kto wysyła informację, a kto ją odbiera?
Zasady nadpisywania. Czy aktualizacja wspólnego parametru może zmienić wartość lokalną?
Obsługę pustych wartości. Czy brak danych oznacza usunięcie, dziedziczenie czy niekompletną informację?
Reakcję na błąd. Co stanie się, jeśli aktualizacja dotrze tylko do części rynków?

Szczególnie ważny jest punkt dotyczący pustych wartości.

Brak pola w komunikacie integracyjnym, wartość null i świadomie wyczyszczone pole nie powinny automatycznie oznaczać tego samego.

Jeżeli system nie odróżnia tych sytuacji, może przypadkowo usuwać poprawne dane lokalne.

Warto również zapewnić możliwość ustalenia, które aktualizacje nie dotarły do odbiorców. Sama informacja, że import został uruchomiony, nie potwierdza jeszcze poprawnej synchronizacji wszystkich produktów.

Problem rozbieżności pomiędzy systemami omówiliśmy szerzej w artykule Co zrobić, gdy ERP, PIM i Magento mają różne wartości tego samego parametru?.

Czy lokalne katalogi wymagają osobnego SEO?

Tak. Wspólne dane techniczne nie oznaczają, że wszystkie wersje produktu powinny mieć identyczne treści SEO.

Klienci w poszczególnych krajach mogą używać innych określeń, porównywać odmienne właściwości produktów i wyszukiwać inne frazy.

Dlatego przy przygotowywaniu lokalnych wersji katalogu warto osobno zadbać o:

nazwy i opisy dopasowane do zapytań użytkowników,
SEO title i meta description,
adresy URL,
lokalne nazewnictwo kategorii,
linkowanie wewnętrzne,
powiązania pomiędzy wersjami językowymi i regionalnymi.

Przykładowo niemiecka i austriacka wersja strony mogą korzystać z podobnych treści, ale mieć różne ceny, informacje o dostawie i wybrane komunikaty sprzedażowe.

W takim przypadku należy poprawnie skonfigurować wersje regionalne, między innymi przy wykorzystaniu oznaczeń de-DE oraz de-AT.

Google opisuje ten mechanizm w dokumentacji dotyczącej stron wielojęzycznych i regionalnych.

Ważne jest również prawidłowe określenie adresów kanonicznych.

Nie należy automatycznie wskazywać polskiej strony jako canonical dla wszystkich wersji językowych. Może to utrudniać traktowanie lokalnych adresów jako samodzielnych stron przeznaczonych do indeksowania.

W przypadku bardzo podobnych wersji regionalnych należy wspólnie zaplanować konfigurację canonical i hreflang, zgodnie z zasadami Google.

Dlaczego samo tłumaczenie opisów bywa niewystarczające?

Załóżmy, że polski producent sprzedaje krzesło biurowe.

Na rynku polskim klienci często trafiają na produkt przez zapytania związane z konkretną kategorią, przeznaczeniem lub materiałem.

W Niemczech odpowiednia fraza może mieć inną konstrukcję i inny poziom szczegółowości.

Dosłowne przetłumaczenie polskiego tytułu nie zawsze będzie najlepiej odpowiadać sposobowi wyszukiwania produktu przez niemieckiego klienta.

Dlatego warto pozostawić lokalnym zespołom możliwość przygotowywania tytułów, opisów i metadanych pod dany rynek, bez naruszania wspólnej specyfikacji produktu.

Jak przygotować katalog przed wejściem na kolejny rynek?

Przed rozpoczęciem tłumaczeń i konfiguracji nowego sklepu warto przeprowadzić audyt obecnego katalogu.

Nie musi to od razu oznaczać dużego projektu technologicznego. Na początku potrzebne są przede wszystkim odpowiedzi na kilka konkretnych pytań.

1. Czy produkty mają stabilne identyfikatory?

Sprawdź, czy SKU są unikalne, czy warianty są prawidłowo powiązane oraz czy identyczne produkty nie funkcjonują już pod różnymi kodami.

Szczególną uwagę warto zwrócić na katalogi importowane od dostawców lub tworzone niezależnie przez kilka działów firmy.

2. Które pola mogą się różnić między rynkami?

Przygotuj tabelę pól produktu i określ ich zakres.

Przykładowo:

Pole	Zakres	System źródłowy
SKU	Globalny	ERP
Moc urządzenia	Globalny	PIM
Nazwa produktu	Językowy	PIM
Opis marketingowy	Językowy/regionalny	PIM
Zdjęcie główne	Globalny z możliwością wyjątku	PIM/DAM
Cena sprzedaży	Rynkowy/cennikowy	ERP lub system cenowy
Zakres oferty	Rynkowy	PIM lub system sprzedażowy
Stan magazynowy	Magazynowy	ERP/WMS
SEO title	Lokalny dla strony	PIM lub Magento

To przykładowy podział. W konkretnej firmie źródła mogą wyglądać inaczej.

Najważniejsze, żeby odpowiedzialność za pola była ustalona przed rozpoczęciem integracji.

3. Czy produkt jest taki sam na każdym rynku?

Trzeba rozróżnić zmianę sposobu sprzedaży od rzeczywistej zmiany produktu.

Jeżeli różnią się jedynie nazwy, opisy, ceny i kanały dostawy, zwykle można zachować wspólny SKU.

Jeżeli zmienia się fizyczna specyfikacja, zestaw lub osobno magazynowana jednostka handlowa, może być potrzebny oddzielny produkt.

4. Jakie lokalne informacje są obowiązkowe?

Nie wszystkie różnice wynikają z marketingu.

W zależności od kategorii produktów i docelowego rynku mogą pojawić się wymagania dotyczące instrukcji, ostrzeżeń, oznaczeń, danych producenta, dokumentacji lub innych informacji udostępnianych konsumentowi.

Wymagania trzeba zweryfikować dla konkretnego asortymentu.

Katalog powinien umożliwiać sprawdzenie, czy produkt posiada komplet danych potrzebnych do publikacji na danym rynku.

5. Czy lokalne zespoły mogą bezpiecznie edytować treści?

Jeżeli firma zatrudnia osoby odpowiedzialne za poszczególne kraje, powinny mieć możliwość pracy nad lokalnymi informacjami bez przypadkowej zmiany danych wspólnych.

Warto określić uprawnienia, proces zatwierdzania treści i sposób zgłaszania zmian w specyfikacji produktu.

6. Co wydarzy się po zmianie jednego parametru?

To bardzo dobry test całej architektury.

Wybierz produkt sprzedawany we wszystkich krajach i zmień jego wspólny parametr.

Następnie sprawdź:

czy poprawna wartość trafiła do wszystkich lokalnych sklepów,
czy nie zostały nadpisane tłumaczenia,
czy system prawidłowo zaktualizował filtry produktowe,
czy opisy marketingowe nie zawierają starej informacji,
czy integracja zgłosiła błędy, jeśli któryś z odbiorców nie przetworzył aktualizacji.

Warto wykonać również odwrotny test: zmienić opis tylko na jednym rynku i sprawdzić, czy pozostałe wersje produktu nie zostały naruszone.

7. Jak będzie dodawany szósty rynek?

To pytanie pozwala ocenić, czy rozwiązanie rzeczywiście nadaje się do dalszej ekspansji.

Jeżeli uruchomienie kolejnego kraju wymaga ponownego kopiowania całego katalogu, ręcznego mapowania tysięcy SKU i poprawiania integracji, warto wrócić do projektu modelu danych.

Docelowo dodanie rynku powinno polegać przede wszystkim na skonfigurowaniu odpowiedniej oferty, przygotowaniu wymaganych treści i ustawień sprzedaży oraz zweryfikowaniu danych potrzebnych do publikacji.

Czy producent potrzebuje PIM, żeby sprzedawać w pięciu krajach?

Nie zawsze.

Jeżeli firma posiada niewielki katalog, prostą strukturę produktów i jeden główny kanał sprzedaży, zarządzanie danymi bezpośrednio w platformie e-commerce może być wystarczające.

Magento 2 pozwala przecież obsługiwać wiele sklepów i lokalnych wersji produktowych.

PIM zaczyna mieć większe uzasadnienie, gdy skala pracy z informacjami produktowymi rośnie.

Przykładowo producent posiada 8000 SKU, sprzedaje na pięciu rynkach, prowadzi równolegle B2B i D2C, udostępnia katalog dystrybutorom oraz publikuje produkty na marketplace.

Do tego dochodzą częste zmiany parametrów, dokumentacji i materiałów marketingowych.

W takiej sytuacji zarządzanie informacjami produktowymi wyłącznie w Magento może oznaczać, że platforma sprzedażowa pełni również funkcję centralnego repozytorium danych dla całej firmy.

PIM pozwala oddzielić przygotowanie informacji o produktach od sposobu ich sprzedaży.

Jednak samo wdrożenie systemu nie zagwarantuje porządku.

Jeżeli firma zaimportuje do PIM pięć niezależnych katalogów bez uporządkowania identyfikatorów, parametrów i zasad lokalizacji, przeniesie dotychczasowe problemy do nowego narzędzia.

Dlatego projekt PIM powinien rozpocząć się od modelu danych i procesów, a dopiero później przejść do konfiguracji i integracji.

Kiedy osobne katalogi mogą mieć uzasadnienie?

Są sytuacje, w których firma rzeczywiście potrzebuje istotnego rozdzielenia oferty.

Może to dotyczyć producentów prowadzących kilka niezależnych marek, sprzedających odmienne linie produktowe lub obsługujących rynki o różnych wymaganiach.

Przykładowo firma może:

oferować inne produkty w zależności od kraju,
posiadać regionalne warianty o odmiennej specyfikacji,
stosować różne struktury kategorii,
obsługiwać odrębne kanały B2B i D2C,
zarządzać kilkoma markami z niezależną polityką handlową.

W takich przypadkach lokalne katalogi sprzedażowe mogą być różne.

Wciąż jednak warto zachować wspólne źródło informacji dla tych produktów, które rzeczywiście są identyczne.

Nie ma powodu pięciokrotnie przechowywać tej samej wartości technicznej tylko dlatego, że produkt występuje w pięciu ofertach.

Co producent zyskuje dzięki wspólnemu katalogowi produktów?

Najbardziej oczywistą korzyścią jest mniejsza liczba ręcznych aktualizacji.

Jednak w praktyce znacznie ważniejsza może być przewidywalność pracy z danymi.

Kiedy producent zmienia specyfikację, wiadomo, skąd powinna pochodzić nowa wartość i do których kanałów ma trafić.

Kiedy lokalny zespół poprawia opis, nie musi obawiać się, że naruszy parametry wykorzystywane przez pozostałe rynki.

Kiedy firma uruchamia nowy sklep, może wykorzystać istniejące dane techniczne, zdjęcia, identyfikatory i relacje wariantów.

Ma to również znaczenie dla klientów.

Niespójne parametry, nieaktualne instrukcje czy błędne informacje o dostępności utrudniają podjęcie decyzji zakupowej i mogą prowadzić do dodatkowych pytań, reklamacji lub zwrotów.

Dobrze przygotowany katalog ogranicza ryzyko takich sytuacji.

Nie oznacza to, że ekspansja przestaje wymagać pracy. Nadal potrzebne są tłumaczenia, lokalne SEO, przygotowanie warunków sprzedaży i weryfikacja wymagań poszczególnych rynków.

Firma nie powinna jednak wykonywać ponownie pracy, która została już wykonana przy przygotowaniu wspólnej części produktu.

Podsumowanie: jak zarządzać jednym katalogiem na pięciu rynkach?

Jeżeli producent sprzedaje ten sam produkt w pięciu krajach, powinien zachować wspólne dane opisujące jego tożsamość i właściwości, a osobno zarządzać informacjami wymagającymi lokalizacji.

W praktyce oznacza to:

wspólne SKU i strukturę wariantów dla tych samych produktów handlowych,
jedno źródło podstawowych parametrów technicznych,
osobne treści językowe i regionalne,
ceny i dostępność zgodne z zasadami sprzedaży na danym rynku,
określoną odpowiedzialność ERP, PIM i Magento,
kontrolę nad dziedziczeniem danych i ich synchronizacją.

Najwięcej problemów powstaje wtedy, gdy firma najpierw kopiuje katalog na kolejny rynek, a dopiero później próbuje uporządkować różnice.

Przy dwóch krajach taki sposób pracy może wydawać się wystarczający. Przy pięciu zaczyna wymagać coraz większej liczby ręcznych kontroli i wyjątków.

Dlatego model danych najlepiej przygotować jeszcze przed uruchomieniem kolejnego rynku.

Planujesz ekspansję e-commerce na kolejne kraje?

W Aurora Creation pomagamy producentom i markom porządkować dane produktowe, projektować integracje ERP, PIM i Magento oraz rozwijać sprzedaż międzynarodową.

Jeżeli problemem jest zarządzanie rozbudowanym katalogiem, sprawdź nasze usługi Pimcore.

Jeśli korzystasz już z Magento 2 i chcesz uruchomić sprzedaż w kolejnym kraju, poznaj AURORA CROSS – usługę dodania rynku do istniejącego sklepu w stałym zakresie, za 8000 zł netto. Niestandardowe integracje i przebudowa architektury danych wymagają osobnego ustalenia zakresu.

Przed ekspansją warto sprawdzić, czy obecny katalog i integracje pozwalają rozwijać sprzedaż bez niepotrzebnego powielania produktów.

FAQ: katalog produktów na wiele rynków

Czy jeden produkt może mieć to samo SKU w kilku krajach?

Tak. Jeżeli producent sprzedaje tę samą jednostkę asortymentową na kilku rynkach, może wykorzystywać jeden SKU we wszystkich lokalnych ofertach. Zmiana języka, waluty lub opisu nie wymaga automatycznie utworzenia nowego identyfikatora.

Czy każdy rynek powinien posiadać osobny katalog produktów?

Nie. Jeden centralny katalog może zasilać wiele lokalnych sklepów, przekazując wspólne informacje i odpowiednie dane dla każdego rynku. Lokalne oferty mogą różnić się cenami, zakresem asortymentu, dostępnością oraz treściami bez konieczności tworzenia niezależnych kopii produktów.

Jak zarządzać tłumaczeniami produktów na pięć rynków?

Najlepiej powiązać tłumaczenia z tym samym produktem i zarządzać nimi w systemie obsługującym wiele języków, np. PIM lub odpowiednio skonfigurowanym Magento. Trzeba również uwzględnić różnice regionalne, ponieważ dwa kraje korzystające z tego samego języka mogą potrzebować innych treści.

Czy Magento 2 obsługuje wiele rynków w jednej instalacji?

Tak. Magento 2 pozwala tworzyć wiele Website, Store i Store View w jednej instalacji oraz korzystać ze wspólnych kartotek produktów. Wybór odpowiedniej struktury zależy od tego, czy poszczególne rynki wymagają odrębnych języków, cen, ofert i ustawień sprzedaży.

Czy Niemcy i Austria mogą korzystać z tych samych opisów produktów?

Tak. Niemcy i Austria mogą współdzielić podstawową niemiecką wersję językową produktu, jeżeli treść odpowiada potrzebom obu rynków. Jednocześnie można przewidzieć regionalne odstępstwa dotyczące oferty, cen, SEO lub innych informacji sprzedażowych.

Czy do zarządzania katalogiem międzynarodowym konieczny jest PIM?

Nie. Przy niewielkim katalogu i prostej sprzedaży wystarczające mogą być funkcje platformy e-commerce. PIM warto rozważyć, gdy rośnie liczba produktów, języków, kanałów sprzedaży i osób odpowiedzialnych za przygotowanie informacji produktowych.

Jak uniknąć duplikowania produktów podczas integracji ERP, PIM i Magento?

Należy stosować stabilne identyfikatory produktów, ustalić źródło prawdy dla poszczególnych pól i zaprojektować jednoznaczne mapowanie danych. Integracja powinna rozpoznawać istniejący produkt oraz aktualizować odpowiednie wartości, zamiast tworzyć nową kartotekę dla każdego rynku.

Jak uporządkować katalog, jeśli firma ma już pięć jego niezależnych wersji?

Najpierw trzeba zidentyfikować powtarzające się produkty, zweryfikować ich SKU i porównać dane wspólne oraz lokalne. Następnie można przygotować docelowy model katalogu, zasady migracji i synchronizacji. Proces powinien uwzględniać istniejące powiązania z zamówieniami, magazynem, ofertami i pozostałymi systemami.