Sklep przed Black Friday: co sprawdzić, żeby nie padł
Sklep rzadko pada na stronie głównej. Pada w koszyku, w płatności albo na synchronizacji stanów, czyli tam, gdzie nic nie da się odłożyć do pamięci podręcznej, a każde kliknięcie coś zapisuje w bazie.
- Autor
- Wojciech Wawrzyniak
- Aktualizacja
- Czytanie
- 8 min
Ile kosztuje godzina przestoju w Black Friday
Zanim zdecydujesz, ile czasu i pieniędzy przeznaczyć na przygotowania, policz stawkę. Black Friday wypada w tym roku 27 listopada, Cyber Monday 30 listopada. Weź z panelu sklepu obrót z zeszłorocznego Black Friday i podziel go przez obrót zwykłego dnia z listopada. Wynik to Twój mnożnik. W tabeli przyjęliśmy mnożnik 4.
| Obrót zwykłego dnia | Obrót w Black Friday | Średnio na godzinę | Godzina szczytu |
|---|---|---|---|
| 10 000 zł | 40 000 zł | 2 500 zł | 5 000 zł |
| 30 000 zł | 120 000 zł | 7 500 zł | 15 000 zł |
| 100 000 zł | 400 000 zł | 25 000 zł | 50 000 zł |
Do utraconego obrotu dolicz reklamę. Kampanie nie wiedzą, że sklep nie działa: Google Ads i Meta dalej kupują kliknięcia, które kończą się błędem. Przy budżecie 3 000 zł na dzień promocji godzina przestoju w szczycie to około 375 zł wydanych na kliknięcia bez szansy na zakup. Do tego część klientów, którzy trafili na błąd, kupi u konkurencji i już nie wróci.
To jest model, nie pomiar. Ruch w Black Friday nie rozkłada się równo: szczyty przypadają zwykle na start promocji, wysyłkę newslettera i wieczór. Własny rozkład godzinowy zobaczysz w GA4 (eksploracja z wymiarem Godzina) albo w eksporcie zamówień z zeszłego roku.
Harmonogram: od 6 tygodni do dnia promocji
Najczęstszy błąd to przygotowania w ostatnim tygodniu. Wtedy nie ma już czasu na poprawki po teście obciążenia, a każda zmiana w kodzie tuż przed szczytem sama jest ryzykiem nowej awarii.
| Kiedy | Termin | Co zrobić |
|---|---|---|
| 6 tygodni przed | do 16 października | test obciążenia i lista wąskich gardeł |
| 4 tygodnie przed | do 30 października | poprawki po teście i drugi test |
| 2 tygodnie przed | do 13 listopada | zamrożenie zmian, przegląd tagów, test odtworzenia kopii |
| Tydzień przed | do 20 listopada | zakup testowy na produkcji, dyżur, plan na awarię |
| Dzień promocji | 27 listopada | monitoring na żywo, żadnych wdrożeń |
Test obciążenia: sprawdzaj koszyk, nie stronę główną
Strona główna i karty produktów zwykle wytrzymują, bo serwuje je pamięć podręczna (cache) albo CDN. Koszyk, logowanie, przeliczanie dostawy i składanie zamówienia za każdym razem trafiają do bazy danych. Tam sklep się zatyka, a test typu „ile wejść na stronę główną wytrzyma serwer” tego nie pokaże.
Test obciążenia robi się narzędziem, które udaje wielu klientów naraz, na przykład k6, Locust albo JMeter. Scenariusz powinien przejść całą ścieżkę zakupu:
- Wejście z reklamy na kartę produktu.
- Przejście do kategorii i filtrowanie.
- Dodanie produktu do koszyka i zmiana ilości.
- Wybór dostawy i przeliczenie kosztu.
- Złożenie zamówienia z płatnością w trybie testowym bramki (sandbox).
Cel testu: ruch 3 razy większy niż zeszłoroczny szczyt. Zapas jest potrzebny, bo newsletter albo start kampanii potrafi skupić ruch w kilku minutach. Mierz czas odpowiedzi koszyka i zamówienia w 95. percentylu (czyli czas, w którym mieści się 95 na 100 żądań) i odsetek błędów. Jeśli koszyk odpowiada dłużej niż 2 sekundy albo pojawiają się błędy serwera, masz wąskie gardło do naprawy.
Test obciążenia rób na kopii sklepu albo w nocy, po uzgodnieniu z hostingiem. Test na produkcji w godzinach sprzedaży może położyć sklep, który miał sprawdzić. Część hostingów traktuje taki ruch jak atak i blokuje adres, z którego przychodzi.
Typowe wąskie gardła
Baza danych i wtyczki
W WooCommerce i PrestaShop problemem bywa wtyczka, która przy każdym wyświetleniu koszyka wykonuje dziesiątki zapytań do bazy: kalkulator dostawy, program lojalnościowy, rabaty. Przy zwykłym ruchu tego nie widać. Przy kilkukrotnie większym zapytania czekają w kolejce. Na hostingu współdzielonym dochodzi limit procesów PHP: kiedy wszystkie są zajęte, kolejni klienci widzą błąd 503.
Integracje z magazynem
Synchronizacja stanów i zamówień z BaseLinkerem albo ERP działa przez API, a każde API ma limit zapytań. Przy dużej liczbie zamówień kolejka synchronizacji rośnie, stany się rozjeżdżają i sklep sprzedaje towar, którego już nie ma. Sprawdź, co robi Twoja integracja z ERP i magazynem po przekroczeniu limitu: ponawia zapytanie później czy gubi dane.
Płatności
Bramka płatności też bywa niedostępna albo wolna. Przygotuj drugą metodę płatności, którą da się włączyć jednym przełącznikiem, i sprawdź, czy sklep poprawnie przyjmuje powiadomienie o płatności, które przyszło z opóźnieniem. Jeśli nie, zamówienie opłacone po kilku minutach zostaje w statusie „oczekuje na płatność”, a klient dostaje przypomnienie o zapłacie za coś, za co już zapłacił. Więcej o tym piszemy przy koszyku i płatnościach.
Tagi marketingowe
Przed promocją do Google Tag Managera trafiają nowe piksele, liczniki czasu i narzędzia do nagrywania sesji. Każdy z nich wydłuża ładowanie strony na telefonie. Przejrzyj kontener GTM, usuń tagi, których nikt nie używa, i nie dodawaj nowych w ostatnich dwóch tygodniach. Część tagów da się przenieść na serwer (pomiar po stronie serwera), wtedy przeglądarka klienta ładuje mniej kodu.
Kody rabatowe
Sprawdź kody przed startem: czy łączą się z innymi promocjami, czy mają limit użyć i czy działają na produkty już przecenione. Błędny kod w Black Friday szybko trafia na grupy z okazjami, a wtedy sprzedajesz ze stratą przez kilka godzin, zanim ktoś to zauważy.
Zamrożenie zmian i kopie zapasowe
Dwa tygodnie przed Black Friday zatrzymaj wdrożenia: bez nowych funkcji, bez aktualizacji wtyczek i motywu, bez zmian w konfiguracji serwera. Wyjątek to poprawki błędów znalezionych w teście, i każda z nich najpierw przechodzi przez środowisko testowe.
Kopia zapasowa jest warta tyle, ile udane odtworzenie. Przed zamrożeniem odtwórz sklep z kopii na osobnym serwerze i zmierz, ile to trwa. Jeśli trwa na przykład 6 godzin, to jest Twój najgorszy scenariusz na Black Friday. Lepiej dowiedzieć się tego w listopadzie niż w trakcie awarii.
Dyżur i plan na awarię
W dniu promocji ktoś musi patrzeć na sklep i mieć uprawnienia, żeby coś zrobić. Ustal to na piśmie przed promocją:
- Kto ma dyżur w piątek, w weekend i w Cyber Monday, z numerem telefonu, a nie tylko adresem e-mail.
- Jak szybko reaguje hosting i firma, która utrzymuje sklep. Jeśli czasu reakcji nie ma w umowie, nie ma go wcale.
- Monitoring, który co kilka minut przechodzi ścieżkę zakupu (test syntetyczny), a nie tylko sprawdza, czy strona główna odpowiada.
- Kto i jak wstrzymuje kampanie, kiedy sklep nie działa. W Google Ads da się to zautomatyzować skryptem, który sprawdza adres sklepu i pauzuje kampanie przy błędzie.
- Strona zastępcza na czas przestoju: krótka informacja i zapis na powiadomienie o powrocie sklepu. Lepsze to niż błąd serwera.
Po weekendzie spisz, co się działo: szczyt ruchu, czasy odpowiedzi, błędy, zamówienia z problemem. To najlepszy materiał do przygotowań przed grudniem, który w wielu branżach jest dłuższym szczytem niż sam Black Friday.
Monitoring, kopie zapasowe z testem odtworzenia i czas reakcji na awarię zapisany w umowie.
Zobacz, jak utrzymujemy sklepy