Nowy sklep na żywym organizmie
RMC Baltic to dystrybutor oryginalnych części samochodowych, nowych i używanych, sprzedający jednocześnie przez własny sklep, marketplace'y i telefon. Katalog liczy ponad 25 tysięcy pozycji, prawie ćwierć miliona zdjęć, a każdą część identyfikuje numer katalogowy producenta auta.
Zadanie brzmiało prosto: nowy sklep. Warunki były trudniejsze. Bez migracji danych, bez zmiany ani jednego adresu podstrony i bez dotykania automatyzacji, na których stoi cała obsługa zamówień. Sklep miał zmienić się pod spodem i na wierzchu, a zaplecze firmy miało tego nie zauważyć.
Audyt: sklep sprzedawał, ale nic nie mierzył
Zaczęliśmy od audytu na działającym serwisie, bez dostępu do panelu. Wyszło 28 znalezisk w sześciu obszarach: 6 krytycznych, 14 wysokich, 8 średnich. Każde z liczbą, nie z opinią.
W sklepie nie było Google Analytics 4 ani Tag Managera, jedynym tagiem były konwersje Google Ads. Nie było też okna zgód, więc deklaracja Consent Mode wstawiana automatycznie przez wtyczkę Google stała na stałe w pozycji „odmowa". Firma nie wiedziała nic o koszykach, wartości zamówień ani źródłach sprzedaży, a reklamy rozliczały się z modelu, nie z rzeczywistych transakcji.
Reszta listy była równie konkretna. Strona główna i kategorie generowały się około pięciu sekund. Menu z kilkuset odnośnikami siedziało w kodzie każdej podstrony. Na stronie zamówienia klient miał 517 odnośników prowadzących poza proces zakupu i pełną treść regulaminu wklejoną pod formularzem. Numer katalogowy był sklejony z kodem magazynowym w jednym polu. Polityka prywatności opisywała narzędzia, których w sklepie nie było, a regulamin opierał reklamacje na uchylonych przepisach.
Audyt pokazał też, co działa dobrze, i to miało znaczenie dla decyzji. Sklep nie stał na page builderze, karty produktów odpowiadały szybko, układ nie skakał. Fundament nadawał się do zachowania. Do wymiany była warstwa nad nim.
Strona główna generowana w 4,5-4,9 s
Brak GA4, brak okna zgód, Consent Mode zablokowany
517 odnośników na stronie zamówienia
Dostępność 80 na 100, zablokowane powiększanie na telefonie
Numer OE sklejony z kodem magazynowym
Brak nagłówków bezpieczeństwa na serwerze
Dokumenty prawne niezgodne ze stanem sklepu
Strona główna w 0,21 s do pierwszego bajtu
GA4 ze zdarzeniami zakupowymi, zero ciasteczek przed zgodą
19 odnośników na stronie zamówienia
Dostępność 100 na czterech kluczowych ekranach
Numery rozdzielone, wyszukiwarka z normalizacją zapisu
Pięć nagłówków bezpieczeństwa, ukryte wersje oprogramowania
Nowe projekty dokumentów prawnych
Najpierw ustalenia, potem kod
Zanim powstała oferta, zbudowaliśmy klikalną makietę na 24 prawdziwych produktach z katalogu klienta, z prawdziwymi numerami, cenami i zdjęciami. Dział sprzedaży klienta przygotował 46 pytań o zasady działania nowego sklepu. Odpowiedzieliśmy na każde osobno, a dokument z odpowiedziami jest jednym z dokumentów wiążących projekt.
Zakres zamknęliśmy w dziewiętnastu pozycjach, od strony głównej po środowisko testowe. Każda funkcja w kodzie ma odniesienie do konkretnej pozycji zakresu, znaleziska z audytu albo ekranu makiety. Przy odbiorze nie było rozmowy o tym, co „miało być". Był dokument, w którym przy każdej pozycji stoi stan i dowód.
Fundament na obecnym sklepie
Pamięć podręczna obiektów i nagłówki bezpieczeństwa włączone w nocnym oknie serwisowym, na starym motywie. Okno zgód i pomiar jako moduł niezależny od motywu
Nowy motyw
Klasyczny motyw w PHP, bez procesu budowania i bez zamkniętych zależności. Strona główna, katalog z filtrami, karta produktu, koszyk, kasa, konto klienta
Dane produktowe i indeks numerów
Rozdzielenie numerów katalogowych, kodów magazynowych i EAN, własny indeks wyszukiwania z numerami zastępczymi, dane dla Google
Moduły branżowe
Osobna wtyczka: zwroty bez logowania, reklamacje z numeracją i statusami, dopasowanie części do pojazdu, zapytanie po numerze VIN
Integracja i przełączenie
Kopia produkcji, kontrakt pól zamówienia, cztery bramki, przełączenie motywu na żywym sklepie i nadzór po starcie
216 reguł, których nie wolno było ruszyć
Sercem operacji klienta jest BaseLinker. To on pobiera zamówienia ze sklepu co minutę, wystawia faktury przez Fakturownię, zakłada przesyłki u kurierów, drukuje karty zamówień i etykiety, wysyła e-maile i SMS-y. Sklep jest dla niego tylko jednym ze źródeł.
Wykaz automatyzacji spisaliśmy sami, z panelu, w trybie tylko do odczytu. Wyszło 216 reguł w 40 grupach, z czego 179 aktywnych. Piętnaście dotyczy wprost zamówień ze sklepu, a 180 działa dla wszystkich kanałów bez warunku źródła, więc też obejmuje sklep.
Warunki tych reguł czytają dane, które przychodzą ze sklepu: nazwę metody dostawy i płatności dosłownie, NIP, znacznik „chcę fakturę", identyfikator paczkomatu, komentarz kupującego. Wystarczy, że nowa kasa zapisze NIP pod innym kluczem albo zmieni nazwę płatności o jedną literę, a faktura nie powstanie, przesyłka nie zostanie założona, a zamówienie za pobraniem pójdzie ścieżką przedpłaty. Nikt nie dostanie komunikatu o błędzie. Reguła po prostu nie zadziała.
Porównaliśmy 200 zamówień z 75 dni: to, co zapisał sklep, z tym, co odebrał BaseLinker. Tak powstał kontrakt siedmiu pól, od których zależą reguły. Nowa kasa zapisuje dokładnie te same klucze, a narzędzie porównujące daje jeden z dwóch werdyktów: ZGODNE albo STOP. Na celowo zepsutym NIP-ie i nazwie płatności zwraca STOP. Bez werdyktu ZGODNE produkcja nie była zmieniana.
Testy bez ryzyka dla prawdziwych zamówień
Każde zamówienie testowe wpuszczone do produkcyjnego BaseLinkera odpaliłoby lawinę: fakturę w systemie księgowym, SMS do klienta, wydruk etykiety, zlecenie dla kuriera. Przyjęliśmy więc zasadę jednego kierunku. Środowisko testowe tylko czyta z konta klienta i nie ma czym pisać.
- Skrypt importu odrzuca każdą metodę API spoza odczytu i kończy pracę, zanim cokolwiek wyśle
- Środowisko testowe bez wtyczki integracji, bez kluczy REST i bez webhooków, sprawdzane przed każdym przeglądem kodu
- Klucz dostępu poza repozytorium i poza listą procesów serwera
- Dane osobowe z zamówień nie trafiają na serwer testowy, import pobiera wyłącznie katalog
- Kopia produkcji przed przełączeniem: odcięta od internetu, zanonimizowana z kontrolą, poczta do skrzynki testowej
Katalog testowy odtworzyliśmy z BaseLinkera, a nie z bazy sklepu, bo to tam klient prowadzi dane. Pełny import zdjęć oznaczał prawie ćwierć miliona plików. Pierwsze podejście przerwaliśmy, bo pliki w oryginalnej wielkości nie zmieściłyby się na dysku. Drugie pobierało je od razu zmniejszone, czterema procesami, przez około czternaście godzin.
Przełączenie w czterech bramkach
Nowy motyw wszedł na tę samą instalację, tę samą bazę i te same adresy. Stary motyw został na serwerze nietknięty, w osobnym katalogu, jako droga powrotu jednym przełącznikiem. Zanim cokolwiek zmieniło się na produkcji, kopia produkcji musiała przejść cztery bramki.
Kontrakt pól zamówienia
Te same zamówienia wzorcowe na starym i nowym motywie: kurier, pobranie, paczkomat, faktura, odbiór osobisty, zagranica, płatność kartą, euro, kupon. Werdykt ZGODNE
Paczkomaty
Przycisk mapy i ukryte pola punktu odbioru obecne w nowej kasie, bo od nich zależą reguły zakładające przesyłki
Bramka płatności
Zamówienie z wersji polskiej i angielskiej dochodzi do operatora płatności tak samo jak na starym motywie
Wygląd na prawdziwych danych
1311 adresów kopii sprawdzonych pod kątem odpowiedzi serwera, log PHP bez błędów, przegląd ręczny stron, kart i kasy
Bramki nie były formalnością. Czwarta złapała puste strony zbudowane w page builderze starego motywu, odnośniki do nieistniejących stron i błąd na karcie produktu bez danych pojazdu. Próba generalna dzień wcześniej, w czterech przebiegach, wyłapała cztery kolejne rzeczy, z których każda przeszkodziłaby w trakcie właściwego przełączenia.
Samo przełączenie trwało kilka minut: kopia zapasowa na żądanie, wgranie dwóch katalogów, aktywacja wtyczki i motywu, przebudowa indeksu numerów. Potem test gotowości na produkcji (52 sprawdzenia, 0 błędów) i zamówienie kontrolne, które w BaseLinkerze dostało właściwy status, NIP, firmę, metodę dostawy i płatności.
Wyszukiwarka, która rozumie numery
W sklepie z częściami klient przychodzi z numerem przepisanym z części, z faktury albo z katalogu. Każdy zapisuje go inaczej. Nowa wyszukiwarka normalizuje zapis: ten sam produkt znajduje się po numerze ze spacjami, z myślnikami, z kropkami, z końcowym sufiksem producenta i bez niego.
- Własna tabela indeksu numerów zamiast przeszukiwania pól produktów, które przy 25 tysiącach pozycji było za wolne
- Numery zastępcze, poprzednicy i następcy części w tym samym indeksie
- Rozdzielanie numerów sklejonych w jednym polu z kodami magazynowymi i symbolami
- Numer producenta jako MPN w danych dla Google, przy każdej karcie z numerem OE
Dopasowanie części do pojazdu na podstawie samego modelu i rocznika to w tej branży prosta droga do zwrotu. Ustaliliśmy więc twardą regułę: dopóki sklep nie ma danych dopasowań, każda karta mówi „zgodność wymaga weryfikacji po numerze VIN" i daje formularz zapytania. Przy odbiorze sprawdziliśmy 20 kart: 20 razy weryfikacja, 0 razy „pasuje".
Cennik dostaw odczytany co do złotówki
Klient nie chciał drugi raz opisywać rzeczy, które w jego systemach już działają, i miał rację. Konfigurację wysyłki, płatności i walut odczytaliśmy sami z panelu i odwzorowaliśmy w nowym sklepie. Koszty liczy nasza metoda wysyłki oparta na wadze paczki, zgodna z dotychczasowym cennikiem.
Przegląd kodu po odwzorowaniu znalazł cztery błędy naraz, każdy zmieniający kwotę dostawy. Najciekawszy: w dotychczasowym cenniku reguła kategorii z pustym kosztem nie dolicza zera, tylko wyklucza metodę dostawy. Zderzak nie może pojechać do paczkomatu i stary sklep tego pilnował, choć nigdzie nie było to zapisane. Nowy pilnuje tego samo, z ostrzeżeniem w panelu, gdy reguła wskazuje nieistniejącą kategorię.
- Płatność dopasowana do dostawy: przy dostawie za pobraniem nie da się zapłacić z góry i odwrotnie
- Nazwy metod dostawy i płatności identyczne jak wcześniej, bo rozpoznają je reguły w BaseLinkerze
- Cennik na stronie „Dostawa" generowany z ustawień wysyłki, a nie przepisywany ręcznie
- Koszt dostawy widoczny już na karcie produktu, liczony tymi samymi metodami co w kasie
Pomiar i zgody zrobione uczciwie
Okno zgód działa jako osobny moduł, niezależny od motywu. Domyślnie odmowa, analityka i marketing ruszają po akceptacji, przyciski „akceptuję" i „odrzucam" są równorzędne. Treść okna uwzględnia wymogi Prawa komunikacji elektronicznej i RODO, a projekty nowych polityk prywatności i cookies czekają na akceptację prawnika klienta.
Kontener Tag Managera i konfigurację Analytics 4 wgraliśmy przez API, a nie klikaniem w panelu, więc są w repozytorium i dają się odtworzyć: 29 tagów, kluczowe zdarzenia od zakupu po kliknięcie w telefon i zapytanie o VIN, retencja danych i grupy odbiorców. Kontrola na produkcji: przed zgodą zero ciasteczek analitycznych i reklamowych, zero żądań do Google i Meta. Zamówienia trafiają do GA4 z wartością zgodną z BaseLinkerem.
Wydajność bez przebudowy
Audyt wskazywał na strony generujące się po pięć sekund. Spodziewaliśmy się, że naprawa będzie wymagała przebudowy strony głównej. W nocnym oknie serwisowym, z pomiarem po każdej zmianie, okazało się, że wystarczy pamięć podręczna obiektów, dostępna w abonamencie klienta, tylko nieużywana.
Jedna zmiana w oknie spowolniła sklep o ponad sekundę, bo wtyczka pamięci nie miała jeszcze połączenia z serwerem. Cofnęliśmy ją po sześciu minutach, zgodnie z zasadą: przy pierwszym objawie cofamy, przyczyny szukamy poza oknem. Usługi, które w panelu hostingu okazały się płatnymi dodatkami, a nie przełącznikami w abonamencie, zostały wstrzymane. Zgodę mieliśmy na prace serwisowe, nie na zakupy w imieniu klienta.
Zakup w nowym sklepie da się przejść wyłącznie klawiaturą, co sprawdza osobny test. Po przełączeniu audyt wersji mobilnej na 396 zrzutach ekranu znalazł m.in. przewijanie kasy w poziomie i plakietkę zabezpieczenia formularza zasłaniającą przycisk zakupu. Poprawki weszły na produkcję tego samego dnia.
Pierwsze 48 godzin
Od wieczora przed przełączeniem działał strażnik sklepu: co kilka minut czas odpowiedzi strony głównej, katalogu, karty i koszyka, regularnie przejście koszyka do kasy oraz porównanie każdego nowego zamówienia z tym, co odebrał BaseLinker.
Kilka godzin po starcie hosting klienta przestał odpowiadać na około dwie godziny. Przyczyna leżała w infrastrukturze dostawcy, ale znaleźliśmy dwie rzeczy po naszej stronie. Pamięć podręczna nie miała trybu łagodnego, więc przy restarcie jej serwera każde żądanie kończyło się błędem, zamiast po prostu działać wolniej. A BaseLinker pyta sklep o zamówienia tylko z ostatnich trzech godzin, a po awarii przestał odpytywać sklep. Gdy integrację uruchomiono ponownie, zamówienie złożone wieczorem było już poza tym oknem i nie zostało pobrane. Dodaliśmy tryb łagodny i moduł, który dla zapytań BaseLinkera wydłuża okno do 72 godzin. Zamówienie weszło samo, a każda przerwa do trzech dni nadrabia się od tej pory bez udziału człowieka.
Jedenaście przeglądów kodu
Każdy większy etap kończył się przeglądem kodu z listą znalezisk i decyzją przy każdym: wdrożone, odrzucone z uzasadnieniem albo odłożone. Przeglądów było jedenaście, od fundamentu motywu po poprawki z audytu odbioru. Jeden z nich złapał furtkę testową, która na produkcji byłaby otwarta dla każdego, bo serwer klienta deklarował się jako środowisko lokalne.
Raz klient wszedł na środowisko testowe po informacji, że poprawki są wdrożone, i trafił na puste strony, brak logotypu i favikony. Testy sprawdzały funkcje, a nie to, co człowiek widzi w pierwszej minucie. Od tej pory przed każdym pokazem uruchamiamy test gotowości: wszystkie strony z menu i stopki, logo, favikona, odpowiedź serwera. Ten sam test był później jedną z bramek przełączenia.
Technologie
WooCommerce
PHP 8.5
Motyw klasyczny bez procesu budowania
Własna wtyczka modułów branżowych
BaseLinker
Fakturownia
InPost Paczkomaty
Redis
Google Tag Manager
GA4 z Consent Mode v2
Google Merchant Center
Schema.org JSON-LD
hreflang
Docker
Playwright
Lighthouse
Rezultaty
Czego ten projekt uczy
W dużej firmie sklep rzadko jest systemem samodzielnym. Jest wejściem do łańcucha, w którym zamówienie zamienia się w fakturę, przesyłkę, wydruk w magazynie i wiadomość do klienta. Najtrudniejsza część wymiany sklepu leży poza sklepem, w automatyzacjach, które czytają jego dane i nie zgłaszają błędów, gdy dane się zmienią.
Dlatego nie zaczynaliśmy od pytania, jak sklep ma wyglądać, tylko od pytania, czego nie wolno zepsuć. Spisany wykaz reguł, kontrakt pól zamówienia, kopia produkcji, bramki z jednoznacznym werdyktem i strażnik po starcie to nie biurokracja. To jedyny sposób, żeby wymienić sklep firmie, która w tym czasie normalnie sprzedaje.
