Słowo multistore załatwia w rozmowach trzy zupełnie różne sytuacje. Pierwsza to sklep, który ma dołożyć angielską wersję językową. Druga to marka, która wchodzi na cztery rynki z osobnymi domenami, cenami i asortymentem. Trzecia to grupa prowadząca kilka niezależnych brandów. Każda z nich ma inną odpowiedź architektoniczną, a wybór tej niewłaściwej kosztuje najwięcej wtedy, gdy trzeba się z niej wycofać.
Ten artykuł jest o tym wyborze. Nie o tym, że multistore istnieje i bywa przydatny, tylko o tym, kiedy wystarczą wersje językowe, kiedy sensowny jest multistore, a kiedy uczciwszą odpowiedzią są osobne instalacje. Do tego o rzeczy, którą materiały producenta pomijają: co w multistore współdzieli się domyślnie i ile pracy kosztuje rozdzielenie tego, co rozdzielone być musi.
Trzy architektury, nie jedna
Zanim zapadnie decyzja, warto nazwać opcje, bo różnią się poziomem izolacji, a nie tylko liczbą stron.
Jedna instalacja, wiele wersji językowych
Jeden sklep, jeden katalog, jeden koszyk, a użytkownik przełącza język. Adresy podstron zwykle różnią się prefiksem językowym. To najprostszy wariant i najtańszy w utrzymaniu, bo wszystko jest jedną konfiguracją.
Multistore
Jedna instalacja PrestaShop obsługuje wiele sklepów, z których każdy może mieć własną domenę, własny szablon, własny asortyment i własne ustawienia modułów. Zarządzanie odbywa się z jednego panelu administracyjnego, a część danych jest współdzielona.
Osobne instalacje
Każdy sklep to niezależny PrestaShop z własną bazą danych. Pełna izolacja, pełna swoboda, a w zamian wielokrotność pracy przy każdej zmianie, aktualizacji i integracji.
Porównanie
| Kryterium | Wersje językowe | Multistore | Osobne instalacje |
|---|---|---|---|
| Osobna domena | nie | tak | tak |
| Osobny asortyment | nie | tak | tak |
| Osobne ceny i waluty | ograniczone | tak | tak |
| Osobny szablon | nie | tak | tak |
| Wspólny magazyn | tak | tak, domyślnie | tylko przez integrację |
| Wspólne konta klientów | tak | konfigurowalne | nie |
| Koszt wdrożenia zmiany w kodzie | raz | raz | razy liczba sklepów |
| Ryzyko, że zmiana zepsuje inny sklep | nie dotyczy | realne | zerowe |
| Wymagania serwerowe | najniższe | jedna instancja | najwyższe |
Ostatnie dwa wiersze pokazują sedno wyboru. Multistore obniża koszt zmian i infrastruktury, ale wprowadza współzależność między sklepami. Osobne instalacje tę współzależność eliminują i płacisz za to przy każdej pojedynczej zmianie.
Kiedy wystarczą wersje językowe
Jeśli sprzedajesz ten sam asortyment, w tej samej walucie, pod jedną marką i jedną domeną, a jedyną różnicą jest język interfejsu i opisów, multistore będzie nadmiarowy. Dołożysz sobie złożoności, której nic nie uzasadnia.
Granica jest dość wyraźna. Wersje językowe przestają wystarczać w momencie, w którym potrzebujesz różnych cen, różnych stawek podatku, innego zestawu produktów albo osobnej domeny. Każde z tych wymagań osobno wystarcza, żeby przejść na multistore.
Kiedy multistore ma sens
Multistore sprawdza się w dwóch scenariuszach i warto je rozróżniać, bo prowadzą do innych konfiguracji.
Wiele rynków, jedna marka. Ten sam brand sprzedaje w kilku krajach. Katalog jest w dużej mierze wspólny, ale ceny, waluty, stawki podatku, metody płatności i przewoźnicy różnią się per kraj. Tu multistore jest wręcz naturalnym wyborem, bo alternatywa oznacza utrzymywanie kilku kopii tego samego katalogu.
Wiele marek, jedna organizacja. Grupa prowadzi osobne brandy, często z różnym asortymentem i zupełnie różną identyfikacją wizualną, ale wspólnym zapleczem magazynowym i wspólnym zespołem. Multistore pozwala prowadzić je z jednego panelu, bez powielania integracji z systemami firmowymi.
Oba scenariusze da się zresztą łączyć. W naszym wdrożeniu dla marki kosmetycznej jedna architektura obsługuje siedem rynków europejskich, a w tym samym ekosystemie działa druga marka grupy. Szczegóły opisujemy w case study NÉONAIL.
Jeśli te marki sprzedają do firm, a nie do konsumentów, osobnym tematem jest sama platforma B2B na PrestaShop oraz to, czym jej wdrożenie różni się od sklepu detalicznego.
Kiedy lepiej wybrać osobne instalacje
To wariant, o którym mówi się najmniej, a bywa właściwy.
Osobne instalacje mają sens, gdy sklepy nie mają ze sobą nic wspólnego poza właścicielem: inny asortyment, inne procesy, inne systemy firmowe, inne zespoły. Wtedy współdzielona instancja daje same wady, bo każda zmiana wymaga sprawdzenia wpływu na sklep, którego nie dotyczyła.
Drugi przypadek to różne tempo rozwoju. Jeśli jeden sklep ma być stabilny przez lata, a drugi jest poligonem doświadczalnym z częstymi wdrożeniami, trzymanie ich na jednej instancji oznacza, że ryzyko z drugiego przenosi się na pierwszy.
Trzeci to sytuacja wyjścia. Jeśli któraś marka może zostać sprzedana albo wydzielona, rozdzielenie jej z multistore po latach jest projektem, a nie operacją administracyjną. Warto to przewidzieć na starcie.
Co w multistore jest wspólne, a co osobne
To najważniejsza sekcja tego tekstu, bo tu rozstrzyga się, czy wdrożenie okaże się wygodne, czy uciążliwe.
Katalog produktów jest współdzielony, a przypisanie do sklepu decyduje o widoczności. Ten sam produkt może mieć w różnych sklepach inną nazwę, inny opis i inne przypisanie do kategorii. To duża zaleta, bo dane wprowadza się raz.
Ceny i podatki ustawia się per sklep, razem z walutą i grupą klientów. To właśnie ta warstwa najczęściej przesądza o wyborze multistore zamiast wersji językowych.
Stany magazynowe są domyślnie wspólne, co przy jednym magazynie fizycznym jest zaletą, a przy kilku wymaga świadomej konfiguracji.
Konta klientów można współdzielić między sklepami albo trzymać osobno. Decyzja nie jest kosmetyczna: wpływa na to, czy klient zarejestrowany w jednym sklepie zaloguje się w drugim, i na to, jak liczysz bazę.
Zamówienia spływają do wspólnego widoku z oznaczeniem sklepu, co upraszcza pracę obsługi i pakowania.
Szablon i moduły konfiguruje się per sklep. Ten sam moduł płatności może mieć inne ustawienia dla każdej domeny, a każdy sklep może mieć własny wygląd.
Pułapka, o której nie mówią materiały producenta
Powyższa lista brzmi jak pełna dowolność. W praktyce granica między tym, co konfigurowalne per sklep, a tym, co działa globalnie, przebiega inaczej, niż zakłada większość osób planujących wdrożenie.
Część funkcji w PrestaShop jest z natury globalna. Włączasz ją raz i działa we wszystkich sklepach naraz, nawet jeśli w jednym z nich jest zbędna albo szkodliwa. Dotyczy to zwłaszcza modułów pisanych bez myśli o multistore, a takich jest sporo, bo autor testował je na pojedynczej instalacji.
To realny problem wdrożeniowy, nie teoretyczny. W jednym z naszych projektów kilka sklepów na wspólnej instancji trudno było prowadzić niezależnie właśnie dlatego, że funkcje synchronizowały się globalnie. Rozwiązaniem był dedykowany moduł, który pozwolił ustawiać każdy sklep osobno. Opisujemy to w case study Gerlach.
Wniosek praktyczny na etapie planowania: dla każdego modułu, na którym Ci zależy, sprawdź, czy jego ustawienia są per sklep, czy globalne. Ta jedna weryfikacja potrafi zmienić wycenę wdrożenia, bo doprowadzenie modułu do zgodności z multistore bywa osobnym zadaniem.
Druga pułapka dotyczy szablonu. Nadpisania widoków robione pod jeden sklep potrafią z czasem posklejać logikę tak, że nikt już nie wie, który fragment dotyczy którego sklepu. Ten stan wychodzi zwykle przy pierwszej aktualizacji i weryfikujemy go w ramach audytu technicznego.
Rynki zagraniczne, czyli co trzeba ustawić osobno
Uruchomienie sklepu na nowym rynku to nie jest tłumaczenie interfejsu. Lista rzeczy do rozstrzygnięcia jest dłuższa i w większości nie ma nic wspólnego z językiem.
- Stawki podatku i sposób prezentacji ceny. Różne kraje, różne stawki, a do tego różne oczekiwania co do tego, czy cena pokazywana jest z podatkiem czy bez.
- Waluta i zaokrąglenia. Osobna decyzja: przeliczamy automatycznie po kursie czy ustawiamy ceny ręcznie per rynek. Automat jest wygodny, ale daje ceny wyglądające przypadkowo.
- Weryfikacja kontrahenta. Przy sprzedaży do firm w Unii potrzebna jest realna weryfikacja numeru VAT, nie tylko sprawdzenie formatu.
- Metody płatności. Zestaw, który działa w Polsce, jest bezużyteczny w Holandii i odwrotnie. Klient powinien widzieć wyłącznie metody właściwe dla swojego rynku, bo nadmiar opcji to friction, zwłaszcza na telefonie.
- Przewoźnicy i koszty dostawy. Osobna konfiguracja per kraj, razem z progami darmowej dostawy liczonymi w lokalnej walucie.
- Wymogi prawne. Regulaminy, informacje o zwrotach i obowiązki informacyjne różnią się między krajami, nawet w ramach Unii.
W praktyce warto zbudować warstwę, która na podstawie kraju, waluty i grupy klienta decyduje, co użytkownik w ogóle widzi. To pozwala uniknąć sytuacji, w której klient z jednego rynku dostaje w koszyku metodę płatności dostępną tylko w innym.
Osobnym tematem jest szybkość działania dla użytkowników z odległych rynków, bo tam decyduje odległość do serwera, a nie architektura sklepu. Piszemy o tym w materiale o sieci CDN dla PrestaShop.
SEO w architekturze wielosklepowej
Multistore rozwiązuje jeden problem SEO i tworzy drugi.
Rozwiązuje ten, w którym wszystkie rynki siedzą pod jedną domeną i konkurują ze sobą o te same zapytania. Osobne domeny albo osobne katalogi pozwalają kierować każdą wersję do właściwego kraju.
Tworzy natomiast problem duplikacji, bo ten sam produkt opisany tym samym tekstem może istnieć w kilku sklepach. Dotyczy to zwłaszcza rynków mówiących tym samym językiem, na przykład niemieckojęzycznych. Rozwiązaniem jest poprawne oznaczenie relacji między wersjami, tak żeby wyszukiwarka wiedziała, która strona jest przeznaczona dla którego kraju i języka, oraz konsekwentne stosowanie adresów kanonicznych.
Trzy rzeczy warto ustalić przed uruchomieniem, a nie po: struktura adresów dla każdego rynku, sposób oznaczenia wersji językowych i regionalnych oraz to, czy treści produktowe będą tłumaczone, czy pisane osobno. Ostatnia decyzja jest kosztowa i najczęściej odkładana, a to ona decyduje o tym, czy nowe rynki będą miały szansę w wynikach wyszukiwania.
Koszty: gdzie multistore oszczędza, a gdzie nie
Oszczędność jest realna w trzech miejscach. Infrastruktura, bo jedna instancja zamiast kilku obniża wymagania serwerowe. Prace programistyczne, bo zmianę w kodzie albo nowy moduł wdrażasz raz dla wszystkich sklepów. Dane produktowe, bo katalog prowadzisz w jednym miejscu, zamiast synchronizować kopie.
Oszczędności nie ma tam, gdzie zwykle się jej spodziewamy. Uruchomienie kolejnego rynku to nadal projekt: konfiguracja podatków, płatności, przewoźników, tłumaczenia, testy ścieżki zakupowej. Multistore skraca część techniczną, ale nie zdejmuje pracy operacyjnej.
Dochodzi też koszt, którego w wariancie z osobnymi instalacjami nie ma: każda zmiana wymaga sprawdzenia, czy nie zepsuła sklepu, którego nie dotyczyła. Przy dwóch sklepach to drobiazg, przy siedmiu to osobna pozycja w każdym wdrożeniu.
Jak wygląda uruchomienie kolejnego sklepu
Przy dobrze zbudowanej architekturze dodanie kolejnego rynku albo marki przebiega w czterech krokach.
- Utworzenie sklepu w strukturze. Nowy sklep w grupie, przypisanie domeny, wybór szablonu.
- Konfiguracja lokalna. Język, waluta, podatki, metody płatności, przewoźnicy, progi dostawy.
- Przypisanie asortymentu. Wybór produktów widocznych w tym sklepie oraz ich lokalnych treści i cen.
- Testy i uruchomienie. Pełna ścieżka zakupowa na docelowej konfiguracji, sprawdzenie dokumentów sprzedaży i przepływu zamówień do systemów firmowych.
Klucz leży w słowie „dobrze zbudowanej”. Jeśli pierwszy sklep powstał bez myśli o kolejnych, drugi ujawni wszystkie skróty: globalne ustawienia modułów, nadpisania szablonu pisane pod jeden przypadek, integracje zakładające jeden zestaw danych. Dlatego architekturę multistore warto zaplanować, zanim będzie potrzebna, nawet jeśli drugi sklep ma powstać dopiero za rok. Tak przygotowaliśmy platformę dla marki modowej, gdzie kolejne wersje językowe i walutowe można uruchamiać z jednego panelu, opisane w case study Reporter.
Pełny zakres naszych prac w tym obszarze opisuje strona multistore na PrestaShop.
