Key features and functionalities – co to znaczy w praktyce sklepu internetowego

Key features and functionalities w ofercie wygląda jak lista życzeń: dwadzieścia punktów, każdy z ptaszkiem. W codziennej pracy sklepu to dwa różne pojęcia i warto je rozdzielić. Feature to zdolność systemu — PrestaShop potrafi obsłużyć wiele języków, warianty produktu, faktury PDF. Functionality to sposób, w jaki ta zdolność działa w procesie zamówienia: czy klient z Niemiec dostaje e-mail ze statusem „Wysłano” po niemiecku, czy zmiana rozmiaru przelicza cenę i stan bez przeładowania strony, czy faktura PDF powstaje sama przy zmianie statusu na „Płatność zaakceptowana”.

Przykład pary, którą często rozbieramy z klientami: wielojęzyczność jako feature i automatyczne tłumaczenie statusów zamówień oraz szablonów e-mail jako functionality. Pierwsze mówi „mamy 4 wersje językowe”. Drugie mówi: zamówienie #1043 zmieniło status na „Wysłane”, a klient z Włoch dostał wiadomość po włosku, z poprawną nazwą statusu i numerem przesyłki. Tłumaczenia szablonów ustawiasz w panelu: Międzynarodowe → Tłumaczenia → Tłumaczenia szablonów e-mail.

Zanim funkcja trafi do umowy wdrożeniowej, przepuszczamy ją przez trzy pytania:

• Czy skraca ścieżkę do zakupu? Policz kroki od koszyka do potwierdzenia. Jeśli funkcja dokłada krok (np. wymuszona rejestracja), a nie skraca — nie jest kluczowa.
• Czy eliminuje pracę ręczną? Ręczne wystawianie faktury to 3–5 minut na zamówienie. Przy 200 zamówieniach miesięcznie to kilkanaście godzin pracy.
• Czy da się ją zmierzyć? Zdarzenie w GA4, licznik w panelu albo raport. Funkcja bez pomiaru to opinia, nie fakt.

Pułapka powtarza się w co drugim przetargu: funkcje wymienione w ofercie, ale nigdy nie włączone i nieprzetestowane. W panelu wpisane są cztery języki, działa jeden; jest moduł zwrotów, ale nikt nie wie, gdzie kliknąć. Włącz, złóż zamówienie testowe, sprawdź e-mail i fakturę. Po stronie Google mierzalność wspierają dane strukturalne produktu — cena i dostępność widoczne w wynikach.

Kluczowe funkcje rdzenia PrestaShop 8.x – co dostajesz bez dopłat

Rdzeń PrestaShop 8.x daje więcej, niż większość firm zakłada na starcie. Katalog: produkty, kombinacje generowane z atrybutów (rozmiar, kolor, pojemność), cechy, stany magazynowe, tryb multistore. Uwaga na eksplozję kombinacji: 5 kolorów × 8 rozmiarów = 40 wariantów na produkt, każdy z własnym SKU, ceną i stanem. Przy kilku tysiącach kombinacji na jednej karcie panel zaczyna się dławić — dziel produkt albo upraszczaj atrybuty.

Zamówienia: statusy z automatycznym e-mailem przy zmianie (Zamówienia → Statusy), faktury PDF, zwroty, reguły koszyka i reguły cenowe katalogowe (Katalog → Rabaty). Do tego uprawnienia pracowników w profilach (Parametry zaawansowane → Zespół), dziennik zdarzeń (Parametry zaawansowane → Logi), zadania cron i kolejka maili — bez kolejki przy 100 zamówieniach w godzinę skrzynka wysypuje się błędami SMTP.

Wydajność, którą włączasz ręcznie po instalacji: cache Smarty i CCC (Combine, Compress, Cache) w Parametry zaawansowane → Wydajność, kompresja oraz nagłówki Cache-Control i ETag po stronie serwera. Warstwa bazowa to PHP 8.1+ i MySQL 8 — sprawdź tabelę zgodności dla swojej wersji rdzenia, bo instalator nie ustawi tego za Ciebie. Świeży sklep potrafi ładować kartę produktu o 1,5–2 s dłużej właśnie z powodu wyłączonego cache.

Granica z wersjami płatnymi: PrestaShop Essential i Enterprise to plany komercyjne. Ich zakres zmienia się w czasie — nie przepisuję go z pamięci, sprawdź aktualną tabelę na stronie PrestaShop. Zasada praktyczna: jeśli funkcja jest w rdzeniu, nie płać za nią drugi raz w module.

WooCommerce vs PrestaShop – te same funkcje, inna filozofia

Próg wejścia: WooCommerce startuje szybciej. WordPress, WooCommerce i motyw to kilka godzin pracy, jeśli katalog jest mały. Problem pojawia się później, bo każda dodatkowa funkcja to kolejna wtyczka. Faktury, kurierzy, płatności ratalne, warianty, B2B — po dziesięciu wtyczkach aktualizacja WordPressa przestaje być rutynową czynnością, a staje się projektem z testami.

Koszt utrzymania w horyzoncie 3 lat: w Woo płacisz głównie licencjami — w praktyce od kilku do kilkunastu płatnych wtyczek, rozliczanych rocznie lub miesięcznie. Do tego konflikty po aktualizacjach, czyli czas dewelopera: 2–6 godzin po każdej większej aktualizacji motywu lub samego Woo. W PrestaShop wtyczek jest mniej, bo rdzeń pokrywa zamówienia, faktury, zwroty i warianty, ale płacisz za wdrożenie i za sprawdzanie zgodności modułów z nową wersją rdzenia przed każdą aktualizacją.

Kiedy wygrywa WooCommerce: dużo treści i sklep jako dodatek, blog plus sprzedaż, katalog do kilkuset produktów, prosty model wysyłki i płatności. Kiedy PrestaShop: B2B z cenami per grupa klientów, duży katalog (tysiące SKU), rozbudowane warianty, multistore, kilka walut i języków. Wydajność sprawdź przed decyzją: Woo z kilkudziesięcioma wtyczkami potrafi nie zmieścić się w progach Core Web Vitals na mobile, a to przekłada się na widoczność w Google i na konwersję.

Test decyzyjny — 5 pytań:

• Ponad 500 SKU albo ponad 20% produktów z wariantami? TAK → PrestaShop.
• Sprzedajesz firmom na indywidualnych cennikach i z odroczonym terminem płatności? TAK → PrestaShop.
• Blog i treści mają być głównym źródłem ruchu? TAK → WooCommerce.
• Masz osobę pilnującą aktualizacji WordPressa i wtyczek? NIE → mniej ruchomych części, czyli PrestaShop.
• Planujesz 2+ rynki, waluty lub języki w ciągu 3 lat? TAK → PrestaShop.

Funkcjonalności, które realnie decydują o konwersji

Funkcję uznajemy za działającą dopiero wtedy, gdy da się ją wskazać palcem w ścieżce zakupu i przypisać do zdarzenia w GA4. W praktyce o wyniku decydują trzy obszary: checkout, płatności i dostawa.

• Zakup bez rejestracji. PrestaShop 8.x: Konfiguracja sklepu → Ustawienia klientów → „Zezwól na zamówienia jako gość”. WooCommerce: Ustawienia → Konta i prywatność → „Zezwól klientom na składanie zamówień bez konta”. Wymuszona rejestracja przy pierwszym zakupie to najprostszy sposób na porzucenie koszyka.
• Liczba kroków w checkoucie. Domyślny checkout PrestaShop 8.x prowadzi przez kilka ekranów (dane, adres, dostawa, płatność, potwierdzenie). Zanim wdrożysz one-page checkout, sprawdź w GA4 raport „Eksploracja ścieżki” i ustal, na którym kroku odpada najwięcej sesji — często winna jest walidacja pola, nie liczba ekranów.
• Koszt dostawy przed rejestracją. Włącz szacowanie kosztów w koszyku, żeby cena transportu pojawiła się przed podaniem adresu.
• Walidacja NIP dla B2B. Pole VAT w adresie plus sprawdzenie numeru w VIES przy zapisie. Bez tego faktury poprawiasz ręcznie, a klient zgłasza reklamację po dostawie.

Płatności: BLIK, Przelewy24 lub PayU, karty oraz płatności odroczone. Każda metoda, która wyrzuca użytkownika na zewnętrzny serwis, musi poprawnie wracać do sklepu i domykać zamówienie — inaczej rośnie liczba zamówień ze statusem „oczekiwanie na płatność”.

Dostawa: InPost Paczkomaty, DPD, DHL. Liczy się mapa punktów odbioru (widget z API kuriera), generowanie etykiet bez wychodzenia z panelu i statusy przesyłek wracające do sklepu automatycznie.

Wyszukiwarka i filtry fasetowe to najczęstszy cichy wyciek ruchu wewnętrznego. Monitoruj frazy bez wyników przez zdarzenie view_search_results i poprawiaj słownik synonimów oraz atrybuty filtrów.

Zasada na koniec: każdy dodatkowy krok w checkoucie weryfikujesz danymi z GA4, nie przeczuciem. Osobno pilnuj czasu ładowania koszyka i płatności — Core Web Vitals to najprostszy punkt odniesienia.

GA4 w PrestaShop i WooCommerce – funkcjonalności pomiarowe, które musisz włączyć

Minimum pomiarowe to pięć zdarzeń e-commerce: view_item_list, view_item, add_to_cart, begin_checkout i purchase. Każde musi nieść tablicę items[] z polami item_id, item_name, price i quantity. Bez tego raporty produktowe w GA4 są puste, a kampanie nie mają się do czego przyłożyć.

GTM i kolejność ładowania. Kontener wklejasz w nagłówek szablonu (w PrestaShop: themes/<twoj_szablon>/templates/_partials/head.tpl; w WooCommerce przez wtyczkę albo functions.php). Tag konfiguracyjny GA4 musi odpalać się najwcześniej, przed tagami zdarzeń, najlepiej na wyzwalaczu Initialization. Tagi zdarzeń czytają z dataLayer, więc kolejność wpisów ma znaczenie.

Consent Mode v2. Włączasz cztery sygnały: analytics_storage, ad_storage, ad_user_data, ad_personalization. Przy odrzuconej zgodzie nie tracisz wszystkiego — Google modeluje część konwersji i sesji. Nie odzyskasz natomiast danych na poziomie użytkownika, remarketingu i pełnych ścieżek w eksploracjach. Tego nie da się obejść.

Weryfikacja w 5 minut. Podgląd GTM (Preview) plus GA4 → Administracja → DebugView lub Test Events w Google Ads. Sprawdź trzy rzeczy: czy purchase leci, czy ma poprawną value z currency i czy niesie unikalny transaction_id.

Najczęstsze błędy: brak zdarzenia po płatności z przekierowaniem (zdarzenie musi odpalać się na stronie powrotu albo przez Measurement Protocol z backendu), duplikaty purchase po odświeżeniu strony potwierdzenia oraz brak kosztu dostawy doliczonego do value — raport sprzedaży rozjeżdża się wtedy z fakturą.

GTM server-side rozważ, gdy masz budżet na kontener w chmurze i chcesz wydłużyć żywotność ciasteczek first-party oraz ograniczyć utratę danych przez blokery. Zmienia to jakość danych, ale nie zastąpi poprawnego dataLayer po stronie sklepu.

Integracje: ERP, płatności, kurierzy – co sprawdzić przed podpisaniem umowy

Integrację oceniasz nie po tym, że działa, tylko po tym, jak zachowuje się przy błędzie. Zanim podpiszesz umowę, zadaj wykonawcy pytania techniczne z trzech obszarów.

ERP. Ustal jedno źródło prawdy: najczęściej stany magazynowe i faktury w ERP, ceny i opisy w sklepie. Wymagaj tabeli mapowania statusów — co dokładnie w ERP odpowiada statusowi „oczekiwanie na płatność”, „w realizacji”, „wysłane”. Zapytaj o częstotliwość synchronizacji stanów: raz na 5 minut czy webhook przy każdej zmianie. Pierwsze rozwiązanie sprzedaje towar, którego już nie ma, gdy w kampanii zejdzie 200 sztuk w kwadrans.

API i webhooki. Poproś o limity zapytań dostawcy i informację, co się dzieje przy kodzie odpowiedzi 429. Musisz wiedzieć, czy zamówienia trafiają do kolejki, czy są gubione, oraz jak działają ponowienia. Kluczowa jest idempotencja: ten sam numer zamówienia wysłany dwa razy nie może utworzyć dwóch dokumentów w ERP. Standard HTTP jest tu jednoznaczny — metody i kody odpowiedzi mają określone znaczenie, warto to zweryfikować w RFC 9110.

Kurierzy. Sprawdź generowanie etykiet w formacie wymaganym przez terminal, obsługę punktów odbioru przez API oraz statusy zwrotne. Zapytaj wprost: co się dzieje, gdy API kuriera odrzuci paczkę — błędny kod pocztowy, brak gabarytu, awaria po ich stronie? Kto widzi błąd i kto go naprawia?

Płatności. Źródłem prawdy jest webhook potwierdzający, nie powrót użytkownika na stronę sklepu — klient może zamknąć kartę po zapłacie. Webhook musi być idempotentny i weryfikować podpis.

I najważniejsza pułapka: integracja sprawdzona na 10 zamówieniach testowych wysypuje się przy 500 w kampanii. Test obciążeniowy i monitoring kolejki to nie dodatek, a warunek startu.

Jak testować funkcje i wykrywać ciche błędy

Odbioru wdrożenia nie robi się na słowo. Potrzebujesz stagingu – kopii sklepu na subdomenie (np. staging.twojadomena.pl), z osobną bazą danych, wyłączoną indeksacją (noindex + ochrona hasłem) i wyłączonymi wysyłkami do prawdziwych klientów. Na staging wgrywasz dane testowe: minimum 20 produktów w 3 kategoriach, w tym jeden z wariantami (rozmiar/kolor), jeden z rabatem czasowym i jeden z niskim stanem magazynowym. Klucze API płatności i kurierów ustawiasz w trybie testowym/sandbox (Przelewy24, PayU, Stripe i większość kurierów mają osobne środowisko testowe). Bez tego pierwszy „testowy” zakup to prawdziwa płatność i prawdziwa etykieta.

Test end-to-end wykonaj w jednej sesji: dodanie do koszyka → dane klienta → wybór dostawy i płatności → przejście przez bramkę → powrót do sklepu → mail z potwierdzeniem i etykietą → zdarzenie purchase w GA4. Do sprawdzenia zdarzeń używaj DebugView i real-time w osobnej usłudze GA4 dla stagingu, żeby nie mieszać danych testowych z produkcyjnymi. Sprawdź, czy w purchase zgadza się wartość, koszt dostawy i zawartość items.

Ciche błędy to najczęstsza pułapka: płatność wchodzi, ale hook nie zmienia statusu zamówienia, więc klient nie dostaje maila i nie ma etykiety. Sprawdzasz to w trzech miejscach: logi PHP (var/logs/prod.log w PrestaShop 8.x, w starszych wersjach panel → Zaawansowane → Logi), kolejka zadań i crony, oraz webhooki bramki – czy wracają z kodem 200 i czy nie ma ponownych prób. Dorzuć alert na nieudane płatności (np. gdy odsetek błędów przekroczy ustalony próg), bo bez tego dowiesz się o awarii od klienta.

Wydajność mierz na realnym szablonie, nie na demo. PageSpeed Insights daje dane laboratoryjne, a dane polowe (CrUX) tylko przy odpowiednim ruchu – mały sklep może ich nie mieć i wtedy musisz opierać się na własnym RUM. Cele: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Więcej o tych metrykach pisze web.dev.

Na koniec protokół odbioru na piśmie: lista przetestowanych scenariuszy, zrzuty ekranu z logów i GA4, lista znanych błędów z terminami, przekazane dostępy i dokumentacja.

Ile to kosztuje – widełki wdrożenia i utrzymania

Nie ma jednej ceny sklepu. Jest liczba godzin pomnożona przez stawkę – i to jedyny uczciwy sposób liczenia. Stawki wdrożeniowe w Polsce mieszczą się dziś najczęściej w przedziale 100–200 zł netto za godzinę, w zależności od doświadczenia zespołu. Poniżej typowe rozbicie prac dla sklepu B2C na PrestaShop 8.x.

Prosty sklep bez migracji i z dwiema integracjami to zwykle 80–120 godzin. Sklep z migracją z innej platformy, trzema integracjami i wielosklepowością – 150–250 godzin. Przy 120 zł/h daje to odpowiednio ok. 9,6–14,4 tys. zł i 18–30 tys. zł netto.

Co podnosi koszt: integracja z systemem ERP, który nie ma API (zostaje odczyt z bazy albo pliki CSV), migracja z platformy bez pełnego eksportu danych, wielosklepowość i osobne cenniki, własny moduł pod nietypową regułę dostawy lub rabatu, niestandardowy szablon graficzny.

Rozliczenie godzinowe vs cennik „z sufitu”. Stała cena oznacza, że wykonawca dolicza sobie premię za ryzyko, a każda zmiana zakresu staje się sporem. Godzinowe jest korzystniejsze, jeśli masz: górny limit budżetu, tygodniowy raport z przepracowanych godzin i zasadę, że zmiany zakresu idą przez pisemny change request. Bez limitu i raportu to Ty ponosisz całe ryzyko.

Utrzymanie i SLA. Realne widełki to 300–1500 zł netto miesięcznie. W umowie zapisz cztery rzeczy: czas reakcji na zgłoszenie (np. 4 h robocze dla krytycznych, 1 dzień roboczy dla pozostałych), okno serwisowe na prace wdrożeniowe (np. 22:00–6:00), kopie zapasowe (1× dziennie, retencja 30 dni, kopia poza serwerem) oraz aktualizacje bezpieczeństwa w ciągu 7 dni od wydania krytycznej łatki. Monitoring powinien sprawdzać dostępność co minutę i pilnować webhooków płatności, nie tylko tego, czy strona się otwiera.

Plan wdrożenia w 6 krokach – od audytu funkcji do monitoringu po starcie

1. Audyt funkcji (1–2 tygodnie). Zanim cokolwiek wycenisz, spisz procesy: jak dziś wpływa zamówienie, kto wystawia fakturę, kto generuje etykietę, kto odpowiada na zwroty. Wynikiem jest mapa integracji – jedno zdanie na każde połączenie z zewnętrznym systemem.

2. Lista must-have i nice-to-have. Ustaw maksymalnie 10 pozycji must-have. Reszta trafia do puli nice-to-have z kolejnością – to ona chroni budżet, gdy pojawi się niespodzianka.

3. Wycena godzinowa. Godziny z kroku 1 i 2 razy stawka, plus bufor 15–20% na rzeczy, które wyjdą dopiero w konfiguracji. Bufor nie jest marżą wykonawcy – jest rezerwą na poprawki po testach.

4. Konfiguracja na stagingu. Cała praca dzieje się na kopii. Raz w tygodniu odbierasz przyrost funkcji, żeby nie zostać z gotowym sklepem do przejrzenia w jednym dniu.

5. Testy odbiorowe. Scenariusze z sekcji pierwszej, min. 20 zamówień end-to-end, lista błędów z podziałem na krytyczne i kosmetyczne. Wdrożenie nie kończy się, dopóki krytycznych nie ma zero.

6. Start z monitoringiem przez 30 dni. Po przeniesieniu na produkcję wykonawca patrzy na logi, webhooki płatności, kolejkę zadań i Core Web Vitals. Checkpointy w dniu 7 i dniu 30. W kryteriach wydajności pomaga dokumentacja Google o Core Web Vitals.

Co przygotować przed pierwszym spotkaniem: listę integracji, które muszą działać, eksport produktów z obecnego sklepu, liczbę produktów i kombinacji, informację o językach i walutach, budżet, termin startu oraz nazwisko osoby, która po Twojej stronie podejmuje decyzje.

Kryterium zakończenia: 20 zamówień testowych przechodzi bez błędów, zdarzenie purchase w GA4 ma poprawną wartość, faktura i etykieta generują się automatycznie, przez 7 dni w logach nie pojawia się nowy błąd, kopie zapasowe i monitoring działają, a Ty masz dokumentację i przeszłeś szkolenie z obsługi zamówień.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Inwentaryzacja funkcji z umowy — Zrób to raz, na starcie projektu i powtórz po odbiorze. Każda pozycja: status włączenia, właściciel, data testu.
• Test zamówienia end-to-end — Wykonaj przed każdym większym wdrożeniem i po nim: koszyk, płatność, faktura PDF, e-mail, status przesyłki, zwrot.
• Cache Smarty, kompresja, OPcache — Sprawdź zaraz po instalacji i po każdej zmianie szablonu — domyślnie bywa wyłączone.
• Wersje PHP i MySQL — Weryfikuj przy każdym większym wdrożeniu. Docelowo PHP 8.1+ i MySQL 8, inaczej tracisz wydajność rdzenia.
• Statusy zamówień i automatyzacja — Sprawdź przed wdrożeniem płatności: czy zmiana statusu wysyła e-mail i uruchamia fakturę bez ręcznej pracy.
• Reguły cenowe i promocje katalogowe — Testuj na koncie testowym przed każdą kampanią — nakładające się reguły potrafią dawać darmową dostawę przy zerowym koszyku.
• Uprawnienia pracowników — Ustaw przy zatrudnieniu i przy odejściu osoby. Raz w kwartale sprawdź listę kont aktywnych.
• Zadania cron i kolejka maili — Sprawdź raz w miesiącu, czy zadania wykonują się o czasie; zatrzymana kolejka to klient bez potwierdzenia zamówienia.
• Zdarzenia GA4: view_item_list, view_item, add_to_cart, begin_checkout, purchase — Weryfikuj po każdej zmianie szablonu lub wtyczki, w podglądzie GTM i w DebugView.
• Parametry items[] i wartość zamówienia — Sprawdź na jednym realnym zamówieniu, czy wartość i lista produktów zgadzają się z panelem sklepu.
• Consent Mode v2 — Sprawdź po każdej zmianie polityki cookies i po dodaniu nowego skryptu marketingowego.
• Kroki checkoutu widoczne bez rejestracji — Przejdź proces na telefonie i na komputerze, w trybie prywatnym. Koszt dostawy musi być znany przed rejestracją.
• Wyszukiwarka i filtry fasetowe — Testuj przy każdym powiększeniu katalogu — to najczęstszy punkt utraty ruchu wewnętrznego.
• Koszt utrzymania w horyzoncie 3 lat — Policz raz w roku: licencje, praca dewelopera, koszt serwera. Porównaj z przychodem ze sklepu.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• RFC 9110 – HTTP Semantics
• web.dev – Core Web Vitals