Szalona Italia: od technicznego długu do własnego ekosystemu e-commerce

Są projekty, w których zaczynam od pustej kartki. Projektuję architekturę, dobieram technologie, buduję rozwiązania i od początku wiem, dlaczego każdy element znajduje się właśnie w tym miejscu.
Są też projekty zupełnie inne.
Takie, w których sklep działa, klienci składają zamówienia, reklamy są uruchomione, produkty pojawiają się w katalogu, WordPress ma kilkadziesiąt wtyczek, a na pierwszy rzut oka wszystko wygląda całkiem normalnie.
Dopiero kiedy zaczyna się zaglądać głębiej, okazuje się, że poszczególne elementy systemu nie tworzą spójnej całości.
Tak właśnie rozpoczęła się moja współpraca z Szaloną Italią, sklepem z włoskimi produktami spożywczymi, który nie potrzebował kolejnej rewolucji wizualnej.
Potrzebował czegoś znacznie ważniejszego:

uporządkowania technologicznego zaplecza, usunięcia nagromadzonego długu technicznego i stworzenia fundamentu, na którym można dalej rozwijać sprzedaż.

W ciągu pierwszego etapu prac projekt przeszedł drogę od audytu i napraw podstawowych elementów WooCommerce, przez Merchant Center, SEO, analitykę i wydajność, aż po budowę dedykowanych narzędzi sprzedażowych, których wcześniej w sklepie po prostu nie było.
I właśnie o tym jest to Case Study.

Punkt wyjścia: sklep działał. I właśnie dlatego trzeba było zajrzeć głębiej

Jednym z bardziej niebezpiecznych stanów w e-commerce nie jest sytuacja, w której coś całkowicie przestaje działać.
Wtedy problem jest oczywisty.
Znacznie trudniejsza jest sytuacja, w której system działa pozornie poprawnie.
Produkty można kupić. Koszyk przyjmuje zamówienia. Google Ads wydaje budżet. Merchant Center pokazuje produkty. WordPress się otwiera.
A jednak poszczególne elementy całego procesu funkcjonują poniżej swoich możliwości albo pracują na nieaktualnych lub błędnych danych.
Dlatego pierwszym etapem nie było projektowanie nowych funkcji.
Był nim audyt.
I bardzo szybko okazało się, że problem nie znajduje się w jednym miejscu.

Merchant Center: źródło produktowe zatrzymane w czasie

Jednym z pierwszych obszarów, które przeanalizowałem, był feed produktowy wykorzystywany przez Google Merchant Center.
I tutaj pojawiła się pierwsza poważna niespodzianka.
Główne źródło produktowe zawierało 262 produkty, podczas gdy sam sklep posiadał już 697 opublikowanych produktów.
Co więcej, liczba produktów widocznych w Merchant Center dokładnie odpowiadała staremu plikowi źródłowemu. Feed pochodził z listopada 2025 roku i nie był automatycznie aktualizowany.
Google próbował częściowo kompensować sytuację poprzez automatyczne wykrywanie produktów na stronie, ale nadal znaczna część katalogu nie trafiała do właściwego źródła produktowego.
Sama aktualność danych nie była jednak jedynym problemem.
W feedzie brakowało prawidłowego mapowania podstawowych identyfikatorów produktów. Wśród wykrytych problemów znajdowały się między innymi:

• brak prawidłowego GTIN,
• brak marki produktu,
• wykorzystywanie EAN jako MPN,
• nieprawidłowo ustawione identifier_exists,
• błędnie mapowane pola dotyczące dostępności i stanu produktu,
• nieprawidłowa konfiguracja strefy wysyłki.

To nie były poprawki kosmetyczne.
Feed produktowy jest jednym z fundamentów reklam produktowych. Jeśli Google otrzymuje niepełny albo źle opisany katalog, nawet najlepiej skonfigurowana kampania ma ograniczone możliwości działania.

Co zostało zrobione?

Uporządkowałem źródło danych, poprawiłem mapowanie, usunąłem błędne identyfikatory, wykluczyłem produkty, których nie należało przesyłać do Google, i ponownie uruchomiłem poprawnie aktualizowany feed.
Po wdrożeniu nowej konfiguracji Merchant Center zaczął pobierać aktualne dane.
W jednej z kolejnych kontroli świeży feed obejmował 450 produktów, tylko 13 produktów nie było wyświetlanych, a sekcja wymagająca uwagi była pusta.
Zamiast liczyć na automatyczne domysły Google, sklep ponownie zaczął sam kontrolować własne źródło danych produktowych.

Google Ads: najważniejszą konwersją jest zakup

Kolejnym etapem była analiza reklam.
I tutaj problem był wyjątkowo istotny, ponieważ dotyczył informacji, na podstawie których algorytm Google oceniał skuteczność kampanii.
W konfiguracji konwersji Google Ads jako jeden z istotnych sygnałów wykorzystywane było dodanie produktu do koszyka.
Taki event może być oczywiście wartościowym zdarzeniem pomocniczym.
Ale nie może zastępować sprzedaży.
Jeżeli użytkownik dodaje produkt za 15 zł do koszyka, Google może otrzymać informację o wartości tego zdarzenia. Nie oznacza to jednak, że sklep zarobił 15 zł.
Klient może przecież zamknąć stronę sekundę później.
W analizowanym koncie Google Ads raportował 0 zakupów, a algorytm otrzymywał przede wszystkim dane dotyczące zdarzeń typu add_to_cart.
Dlatego przygotowałem właściwy tag zakupu w Google Tag Managerze:

• trigger uruchamiany dokładnie na purchase,
• przekazywana wartość ecommerce.value,
• identyfikator ecommerce.transaction_id,
• waluta ecommerce.currency.

Dzięki temu Google może otrzymywać sygnał, który naprawdę ma znaczenie dla sklepu:
zamówienie zostało zrealizowane.
Nie chodzi o samo kliknięcie.
Nie chodzi o produkt umieszczony w koszyku.
Liczy się rzeczywista sprzedaż.

Shopping bez jednej wielkiej grupy "Wszystkie produkty"

Kolejny problem dotyczył struktury kampanii produktowej.
Cały katalog był analizowany praktycznie jako jedna grupa: Wszystkie produkty.
To rozwiązanie niezwykle ogranicza możliwość podejmowania decyzji.
Jeżeli sklep sprzedaje makarony, kawę, oliwy, słodycze, sosy i dziesiątki innych grup produktowych, chcę wiedzieć:

• które kategorie generują sprzedaż,
• które wykorzystują budżet bez efektu,
• gdzie CTR jest najwyższy,
• gdzie warto zwiększać skalę,
• gdzie kampania wymaga dodatkowej optymalizacji.

Dlatego grupa została rozbita według typu produktu na około 45 osobnych segmentów produktowych.
Jednocześnie uruchomiłem pierwszą kontrolowaną kampanię Search dla kategorii sklepu, z dedykowanymi słowami kluczowymi, reklamami RSA, rozszerzeniami i linkami między innymi do makaronów, oliw, kawy i słodyczy.
Najważniejsza zasada na tym etapie była jednak bardzo prosta:
po zmianie konfiguracji trzeba dać danym czas.
Nie zmieniam kampanii co kilka godzin tylko dlatego, że pojedynczy wykres zrobił się czerwony.
Najpierw poprawne dane.
Potem odpowiednia próbka.
Dopiero później decyzje.

SEO: wtyczka to jeszcze nie konfiguracja

Obecność wtyczki SEO w WordPressie nie oznacza automatycznie, że sklep jest poprawnie skonfigurowany.
W Szalonej Italii AIOSEO było zainstalowane, ale kilka istotnych elementów wymagało ponownej konfiguracji.
Produkty posiadały nieprawidłowe ustawienia schema, mapa witryny zawierała elementy, które nie powinny być indeksowane, SEO obrazów było wyłączone, a konfiguracja mediów społecznościowych wymagała uporządkowania.
Uporządkowałem więc:

• schema produktów,
• sitemapę XML,
• indeksowane typy treści,
• SEO obrazów,
• dane dla social media,
• konfigurację lokalnego SEO.

To szczególnie istotne w przypadku Szalonej Italii, ponieważ firma działa nie tylko online. Posiada również sklep stacjonarny.
Po późniejszych pracach technicznych wynik SEO Lighthouse osiągnął 100/100.

Najpierw aktualizacja fundamentów

Przed poważniejszą optymalizacją trzeba było uporządkować również samo środowisko WordPress.
Część wtyczek oraz motywów pozostawała w starszych wersjach. Dotyczyło to między innymi WooCommerce, Elementora, narzędzi wysyłkowych, bezpieczeństwa, integracji oraz samego motywu.
Aktualizacja w działającym sklepie nigdy nie powinna polegać na kliknięciu opcji "Aktualizuj wszystko".
WooCommerce jest systemem połączonych naczyń.
Płatności, dostawy, motyw, checkout, system faktur, importy, stany magazynowe i integracje zewnętrzne muszą nadal działać razem.
Dlatego aktualizacje były prowadzone etapami, wraz z kontrolą działania sklepu.
Ostatecznie:

• zaktualizowałem komponenty WordPressa,
• zaktualizowałem motyw,
• usunąłem zbędne elementy,
• ograniczyłem nieużywany kod,
• uporządkowałem środowisko przed kolejnymi etapami optymalizacji.

75 ciężkich grafik i porządki w mediach

Optymalizacja e-commerce nie kończy się na instalacji wtyczki cache.
Jednym z obszarów wymagających pracy była sekcja blogowa.
Przeanalizowałem aktywne wpisy i znalazłem 75 problematycznych obrazów, które następnie zostały zoptymalizowane, przekonwertowane do WebP i prawidłowo przepięte zarówno w treści, jak i w Elementorze.
Po zmianach zweryfikowałem również, czy aktywne wpisy nie odwołują się nadal do starych plików, oraz uzupełniłem brakujące ALT-y.
To typ pracy, której użytkownik strony prawdopodobnie nigdy nie zauważy.
I dokładnie o to chodzi.
Powinien zauważyć tylko jedno:
strona działa szybciej.

Hero bez ciężkiego slidera

Jednym z najbardziej obciążających elementów strony głównej był slider.
Zamiast próbować w nieskończoność optymalizować rozwiązanie, którego architektura od początku nie była szczególnie lekka, zrobiłem coś innego.
Powstał DIGIKROM Hero Engine.
Autorski silnik hero zastąpił dotychczasowy slider WoodMarta, zachowując jego wygląd praktycznie 1:1, ale zapewniając znacznie większą kontrolę nad tym, co faktycznie trafia do przeglądarki.
Silnik otrzymał między innymi:

• osobne obrazy desktop i mobile,
• własne CTA,
• sterowanie typografią,
• kolory,
• tagi,
• wymuszone łamanie tytułów,
• nieograniczoną liczbę slajdów,
• dedykowany panel administracyjny,
• wysoki priorytet ładowania pierwszej grafiki,
• poprawną strukturę ARIA.

Przy okazji wyszły również rzeczy, które nie miały bezpośredniego związku z wydajnością. Część CTA w poprzednim sliderze nie posiadała przypisanych linków.
Czyli optymalizacja wydajności poprawiła jednocześnie UX.

WooCommerce nie musi ładować wszystkiego wszędzie

Strona główna sklepu WooCommerce bardzo często ładuje znacznie więcej kodu niż faktycznie potrzebuje.
Szalonej Italii również to dotyczyło.
W trakcie optymalizacji:

• ograniczyłem zbędny JavaScript WooCommerce,
• usunąłem z HOME niepotrzebne zależności WooCommerce Blocks i React,
• ograniczyłem skrypty motywu i Elementora tam, gdzie było to bezpieczne,
• zoptymalizowałem ładowanie GTM i GA4,
• usunąłem wielokrotne ładowanie gtag.js,
• poprawiłem cache zasobów statycznych,
• usunąłem ukryte elementy Elementora, które nadal generowały CSS i JavaScript.

W jednym z etapów analizy wykryłem nawet ukryte widgety Countdown, których użytkownik strony nie widział, ale przeglądarka nadal musiała obsługiwać związane z nimi zasoby.
To właśnie dlatego w optymalizacji nie interesuje mnie odpowiedź:
"Przecież ten element jest ukryty".
Interesuje mnie:
"Czy przeglądarka nadal musi go obsłużyć?"

Nie każda optymalizacja jest dobrą optymalizacją

Bardzo ważną częścią pracy nad wydajnością jest również umiejętność odrzucania rozwiązań.
W dalszej analizie mobile przejrzałem między innymi:

• Script Evaluation,
• Style & Layout,
• Recalculate Style,
• koszt Swipera,
• wpływ Elementora,
• Complianz,
• Age Gate.

Potwierdziłem między innymi, że Age Gate był zbędnie ładowany na stronie głównej, dlatego jego JavaScript został dla HOME wyłączony.
Przetestowałem również content-visibility: auto.
W teorii wyglądało obiecująco. Obniżało TBT.
W praktyce jednocześnie znacząco pogarszało LCP i Speed Index.
Rozwiązanie zostało więc odrzucone.
To jest ważna zasada mojego podejścia do optymalizacji:
nie wdrażam techniki dlatego, że dobrze wygląda w jednym wykresie.
Liczy się cały użytkownik, cała strona i rzeczywisty efekt.
Po kolejnych etapach desktop Lighthouse został doprowadzony do 100/100/100/100, a Accessibility do 100.

Autorski cache zamiast czekania na pierwszego użytkownika

Kolejnym elementem infrastruktury został autorski mechanizm podgrzewania cache.
Standardowy problem wielu sklepów wygląda następująco: cache zostaje wyczyszczony, a pierwsza osoba odwiedzająca daną stronę musi poczekać, aż zostanie ona wygenerowana.
Przy dużym katalogu ten problem powtarza się na kolejnych adresach.
Dlatego przygotowałem mechanizm, który cyklicznie sprawdza adresy sklepu i stopniowo buduje cache paczkami, bez gwałtownego obciążania serwera.
Jeżeli cały cache zostanie wyczyszczony po większej zmianie, system zaczyna odbudowywać go automatycznie.
To jest przykład rozwiązania, którego klient końcowy nigdy nie zobaczy.
Ale będzie korzystał z jego efektów przy każdym wejściu na stronę.

Product Engine: bezpieczniejsze zarządzanie katalogiem

W dużym katalogu kolejnym problemem jest sama obsługa produktów.
Dlatego powstał Szalona Italia Product Engine, narzędzie wspierające workflow nowych produktów, kategorii i importów.
Jego zadaniem jest uporządkowanie procesu pracy nad katalogiem i ograniczenie ręcznej ingerencji tam, gdzie można ją bezpiecznie zautomatyzować.
W pierwszym etapie uporządkowany został także workflow kategorii oraz importów produktów.
To ważny element całej transformacji, ponieważ skalowalny e-commerce nie może polegać wyłącznie na tym, że ktoś wchodzi do WordPressa i ręcznie poprawia setki produktów.

Koszyk i checkout: moment, w którym technologia spotyka sprzedaż

Po uporządkowaniu fundamentów można było przejść do części, którą klienci widzą najbardziej bezpośrednio.
Koszyka i finalizacji zamówienia.
Dotychczasowy checkout został zastąpiony dedykowanym rozwiązaniem przygotowanym specjalnie dla Szalonej Italii.
Powstał spójny wizualnie proces:
Koszyk > Dane i dostawa > Płatność
Całość została zaprojektowana w stylistyce marki: ciemna zieleń, biel, czytelne akcenty oraz subtelne nawiązania do włoskiej kolorystyki.
Zmiany nie ograniczały się do CSS.
Uporządkowane zostały:

• podsumowanie koszyka,
• metody dostawy,
• prezentacja InPost,
• podatki,
• formularze checkout,
• płatności,
• hierarchia informacji,
• zachowanie na urządzeniach mobilnych.

Przy okazji wyszedł również jeden z bardziej przewrotnych problemów całego projektu.
Motyw posiada własny system Layouts. Dla koszyka aktywny był dodatkowy layout, który w praktyce ingerował w normalne renderowanie WooCommerce, mimo że sam nie wnosił wartościowej zawartości.
To właśnie ten element powodował zachowanie, które przez dłuższy czas wyglądało jak błąd kodu nowego koszyka.
Po jego odnalezieniu problem zniknął.
To dobry przykład, dlaczego przy złożonym WordPressie nie można zakładać, że to, co widzimy na ekranie, jest generowane dokładnie tam, gdzie sugeruje nazwa strony w panelu.

Rekomendacje, które wiedzą, co znajduje się w koszyku

Standardowa sekcja "Polecane produkty" często jest po prostu przypadkową listą.
W Szalonej Italii powstał osobny DIGIKROM Cart Recommendations.
Mechanizm analizuje aktualną zawartość koszyka i buduje rekomendacje na podstawie:

1. ręcznie przypisanych cross-selli,
2. wspólnych kategorii,
3. wspólnych tagów,
4. popularności jako rozwiązania uzupełniającego.

Produkty już znajdujące się w koszyku są wykluczane.
Niedostępne również.
Algorytm dodatkowo dywersyfikuje wyniki, żeby użytkownik nie otrzymał czterech niemal identycznych produktów.
Przy okazji powstał zupełnie nowy wygląd kart produktowych: prostszy, bardziej czytelny i z wyraźnym przyciskiem Dodaj do koszyka.
Efekt spodobał się na tyle, że ten kierunek wizualny stał się również kandydatem do zastosowania w całym katalogu sklepu.

Udostępnij swój koszyk

Jednym z życzeń właścicieli sklepu była funkcja, która na pierwszy rzut oka wydaje się niewielkim dodatkiem.
Udostępnienie zawartości koszyka drugiej osobie.
Powstał więc DIGIKROM Share Cart.
Użytkownik może wygenerować unikalny link, który odtwarza wybrany koszyk po jego otwarciu.
Link nie zapisuje danych klienta ani ceny na sztywno.
Przechowywane są:

• produkty,
• warianty,
• ilości.

Po otwarciu WooCommerce ponownie sprawdza aktualne ceny oraz dostępność.
Jeżeli odbiorca ma już produkty w swoim koszyku, może zdecydować, czy zastąpić obecny koszyk, czy dodać udostępnione produkty do jego aktualnej zawartości.
To niewielka funkcja technologicznie. Ale bardzo konkretna funkcja biznesowo.
Koszyk można przesłać partnerowi, rodzinie, pracownikowi albo osobie zatwierdzającej zamówienie.

Zapisz koszyk i kup ponownie

Skoro koszyk można było już przesłać komuś innemu, naturalnym kolejnym krokiem było umożliwienie zapisania go dla siebie.
Dlatego jeden pasek narzędzi otrzymał trzy funkcje:

• Udostępnij koszyk,
• Zapisz koszyk,
• Kup ponownie.

Zalogowany klient może zachować swój zestaw produktów i wrócić do niego później.
Jeśli zapis już istnieje, interfejs nie pokazuje ponownie enigmatycznego "Zapisz".
Zmienia się na:

Wczytaj zapisany koszyk

Trzecia funkcja wykorzystuje historię zakupów.

Kup ponownie pobiera ostatnie opłacone zamówienie klienta i pozwala ponownie dodać produkty do koszyka.

Nie kopiuje starej ceny.
WooCommerce zawsze wykorzystuje aktualną cenę i bieżącą dostępność.
Dla sklepu spożywczego ma to szczególne znaczenie.
Kawa się kończy. Oliwa się kończy. Makaron się kończy.
A klient nie musi po raz kolejny szukać wszystkiego od początku.

Brakuje Ci X zł do darmowej dostawy

W minikoszyku informacja o progu darmowej dostawy już istniała.
Podczas budowy nowego koszyka zauważyłem jednak, że zabrakło jej właśnie tam, gdzie może mieć największy wpływ na decyzję zakupową.
Powstał więc dynamiczny pasek pokazujący, ile brakuje do darmowej dostawy, wraz z graficznym wskaźnikiem postępu.
Aktualny próg sklepu to 300 zł.
Po jego osiągnięciu komunikat zmienia się na:
Masz darmową dostawę!
Mechanizm działa zarówno w koszyku, jak i w odpowiednio uproszczonej formie podczas checkoutu.
A tuż pod nim znajdują się rekomendowane produkty.
To już nie jest przypadkowe umieszczenie kolejnych elementów strony.
To świadomie zaprojektowana sekwencja:
widzę wartość koszyka, widzę ile brakuje do progu, dostaję produkty, które mogę dołożyć.

La Famiglia: Strefa Partnera zbudowana specjalnie dla Szalonej Italii

Kolejnym etapem stała się dedykowana strefa klienta i programu lojalnościowego.
Bazowy system DIGIKROM Partner został przekształcony w rozwiązanie przygotowane specjalnie dla marki:
La Famiglia
Nie był to jedynie reskin.
Zmieniło się nazewnictwo, język komunikacji, typografia, hierarchia interfejsu oraz cały charakter wizualny.
Powstały poziomy:

• Amico,
• Buongustaio,
• Conoscitore,
• Ambasciatore,
• Famiglia VIP.

Zamiast generycznej strefy partnera klient wchodzi do świata zgodnego z marką Szalonej Italii.
Może przeglądać swoje postępy, nagrody, historię oraz elementy programu lojalnościowego w interfejsie, który wygląda jak integralna część sklepu, a nie kolejna doinstalowana wtyczka.
To właśnie jest kierunek, w którym rozwijam ten projekt:
technologia ma być niewidoczna jako technologia.
Klient nie powinien myśleć:
"To jest jakiś moduł WordPressa".
Ma myśleć:
"To jest Szalona Italia".

Newsletter, który ma być narzędziem, a nie dekoracją

Podczas audytu wyszło również, że dotychczasowy zapis do newslettera nie był elementem działającego systemu marketing automation.
Dlatego rozpocząłem konfigurację Mautic, osobnego systemu do obsługi marketing automation i wysyłek.
Dopiero kiedy realny zapis zacznie działać, można analizować:

• ilu użytkowników faktycznie zostawia adres,
• jakie formularze konwertują,
• jakie segmenty odbiorców powstają,
• jakie automatyzacje mają sens,
• kiedy wysłać kolejną wiadomość,
• jak powiązać komunikację ze sprzedażą.

Bo przycisk "Zapisz się do newslettera" nie jest jeszcze marketing automation.
To dopiero wejście do całego procesu.

Co właściwie zmieniło się w Szalonej Italii?

Najłatwiej byłoby powiedzieć:
"Zoptymalizowałem stronę".
Ale to kompletnie nie oddaje zakresu projektu.
W pierwszym etapie prac zostały uporządkowane lub przebudowane między innymi:

• WordPress i środowisko wtyczek,
• Motyw,
• Merchant Center,
• feed produktowy,
• Google Ads,
• konwersje,
• GTM i GA4,
• AIOSEO,
• schema,
• sitemap,
• SEO obrazów,
• wydajność,
• cache,
• hero strony głównej,
• grafiki,
• blog,
• workflow produktów,
• UX katalogu,
• koszyk,
• checkout,
• rekomendacje produktów,
• udostępnianie koszyka,
• zapis koszyka,
• ponowne zakupy,
• próg darmowej dostawy,
• program lojalnościowy La Famiglia.

A część kolejnych elementów nadal jest rozwijana.
To bardzo ważne, ponieważ dobry projekt e-commerce nigdy nie powinien dojść do momentu:
"Gotowe, więcej niczego nie zmieniamy".
Sklep działa.
Ludzie kupują.
Zmieniają się produkty.
Zmieniają się kampanie.
Pojawiają się dane.
I dopiero wtedy można podejmować kolejne decyzje.

Od napraw do rozwoju

Najciekawsze w tej współpracy jest dla mnie coś jeszcze.
Na początku znaczną część czasu pochłaniało odpowiadanie na pytanie:
"Dlaczego to nie działa tak, jak powinno?"
Dlaczego Merchant ma tylko część katalogu?
Dlaczego kampania nie widzi zakupów?
Dlaczego feed jest nieaktualny?
Dlaczego strona główna ładuje ten skrypt?
Dlaczego koszyk zachowuje się inaczej niż checkout?
Dlaczego newsletter jest tylko formularzem?
Po uporządkowaniu fundamentów pytania zaczęły się zmieniać.
Teraz coraz częściej brzmią:
"Co jeszcze możemy zrobić?"
Czy możemy rekomendować produkty na podstawie koszyka?
Możemy.
Czy klient może przesłać komuś cały koszyk?
Może.
Czy może go zachować?
Może.
Czy może jednym kliknięciem kupić ponownie poprzednie zamówienie?
Może.
Czy program lojalnościowy może wyglądać jak część Szalonej Italii, a nie zewnętrzne narzędzie?
Może.

I właśnie ten moment uważam za najważniejszy rezultat pierwszego etapu współpracy.

Technologia przestała być listą problemów do rozwiązania i zaczęła być narzędziem do budowania nowych możliwości sprzedażowych.

Nie chodzi o liczbę wtyczek

W wielu projektach WordPressowych odpowiedzią na każdą potrzebę jest kolejna wtyczka.
Potrzebujemy funkcji X?
Szukamy w repozytorium.
Potrzebujemy funkcji Y?
Kupujemy plugin.

A później sklep składa się z kilkudziesięciu niezależnych systemów, z których każdy:

• ładuje własny CSS,
• ładuje własny JavaScript,
• ma własny interfejs,
• ma własną koncepcję UX,
• próbuje przejąć kontrolę nad tą samą częścią WooCommerce.

W Szalonej Italii przyjąłem inne podejście.
Jeżeli potrzebna funkcja jest wystarczająco specyficzna, buduję małe, wyspecjalizowane rozwiązanie.
Tak powstały między innymi:

• DIGIKROM Hero Engine,
• Szalona Italia Product Engine,
• DIGIKROM Cart Recommendations,
• DIGIKROM Share Cart,
• dedykowany checkout,
• La Famiglia.

Każde z tych narzędzi robi konkretną rzecz.
Nie próbuje być kombajnem do wszystkiego.
Dzięki temu mam kontrolę nad kodem, wyglądem, zachowaniem i miejscem, w którym rozwiązanie jest ładowane.

Najważniejszy wynik nie mieści się w Lighthouse

Oczywiście liczby są ważne.
Desktop Lighthouse 100/100/100/100 jest dobrym wynikiem.
SEO 100 jest dobrym wynikiem.
Poprawiony feed jest ważny.
Poprawne konwersje Google Ads są ważne.
Mniejszy JavaScript jest ważny.
Ale żadna z tych liczb sama w sobie nie jest celem projektu.

Celem jest sytuacja, w której:

• sklep jest stabilny,
• dane są wiarygodne,
• marketing pracuje na właściwych sygnałach,
• klient łatwiej składa zamówienie,
• właściciel może rozwijać sprzedaż,
• kolejne pomysły nie rozbijają się o technologiczne ograniczenia istniejącego systemu.

I właśnie do takiego miejsca zmierza Szalona Italia.

E-commerce to system, nie strona

Ten projekt bardzo dobrze pokazuje sposób, w jaki patrzę na współczesny sklep internetowy.
Nie widzę:
WordPressa, WooCommerce i kilku wtyczek.
Widzę system.
Produkt musi powstać.
Stan musi się zgadzać.
Feed musi przekazać właściwe dane.
Google musi zrozumieć produkt.
Reklama musi trafić do odpowiedniej osoby.
Analityka musi poprawnie rozpoznać zakup.
Strona musi się szybko otworzyć.
Koszyk nie może przeszkadzać.
Checkout musi być czytelny.
Klient powinien móc wrócić.
Marketing powinien wiedzieć, kiedy i do kogo mówić.
Jeżeli jeden z tych elementów nie działa, reszta systemu zaczyna nadrabiać jego ograniczenia.
Dlatego przy projektach takich jak Szalona Italia nie interesuje mnie pytanie:

"Jaką wtyczkę zainstalować?"

Znacznie bardziej interesuje mnie:

"Co musi wydarzyć się od momentu, kiedy produkt trafia do sklepu, do momentu, kiedy klient wraca po kolejne zamówienie?"

Bo właśnie pomiędzy tymi dwoma punktami znajduje się prawdziwy e-commerce.

Szalona Italia x DIGIKROM

Pierwszy etap prac nad Szaloną Italią rozpoczął się od napraw.
Bardzo szybko przerodził się jednak w coś znacznie większego:
budowę własnego, dopasowanego do biznesu ekosystemu e-commerce.
I dokładnie takie projekty lubię najbardziej.
Nie takie, w których wszystko sprowadza się do zmiany koloru przycisku.
Tylko takie, w których mogę wejść głębiej, zrozumieć proces, znaleźć ograniczenia i krok po kroku zastępować je rozwiązaniami, które po prostu mają sens.
Bo najlepsza technologia w sklepie internetowym nie jest tą, której jest najwięcej.
Jest tą, która pomaga sprzedawać, nie przeszkadzając przy tym ani klientowi, ani właścicielowi sklepu.