Czego polski e-commerce może nauczyć się z Black Week w Norwegii?

Według danych z raportu Baymard Institute 15% badanych amerykańskich konsumentów, którzy porzucili zakup z powodów innych niż zwykłe przeglądanie oferty, wskazało jako przyczynę błędy lub awarię strony, 8% wskazało odrzucenie karty, a 10% brak odpowiedniej metody płatności jako powód niedokończenia zakupu.

Całkowitą awarię sklepu internetowego trudno przeoczyć -znacznie bardziej podstępne są problemy, które nie wyłączają platformy, ale utrudniają klientom zakupy i w efekcie obniżają sprzedaż. Przykład? Sklep może działać, ale ładować się zbyt wolno. Produkt może być widoczny jako dostępny, mimo że został już wyprzedany, ponieważ dane z systemu magazynowego nie dotarły na czas. Rabat może nie naliczać się dla części zamówień. Płatność może kończyć się błędem, a zamówienie nie trafiać poprawnie do kolejnego systemu. Efekt? Sklep działa, ale nie zyskujesz przychodu, bo klienci uciekają.

W takiej sytuacji raport techniczny może pokazywać bardzo wysoką dostępność platformy, podczas gdy firma realnie traci część transakcji. Dlatego przed Black Week pytanie do zespołu technologicznego nie powinno brzmieć wyłącznie: „Czy sklep wytrzyma większy ruch?”. Z biznesowego punktu widzenia ważniejsze jest inne: czy nasza platforma i systemy, z którymi jest połączona, pozwolą sprawnie obsłużyć sprzedaż, którą planujemy wygenerować?

Jak przygotowuje się jeden z największych e-commerce'ów w Norwegii?

W dużym e-commerce przygotowania technologiczne do Black Week nie zaczynają się kilka tygodni przed promocją.

- W Fabres znamy skalę takich przygotowań z wieloletniej współpracy z Komplett, jednym z największych graczy e-commerce w Norwegii - mówi Wojciech Pindel, Strategic Partnership Manager w Fabres, polsko-norweskim software house. - Pracujemy razem już ponad dekadę, a dane z wcześniejszych kampanii pozwalają nam lepiej przewidywać obciążenie i sprawdzać, jak poszczególne elementy systemu zachowają się przy większej liczbie użytkowników i transakcji - dodaje.

Jednym z najważniejszych źródeł wiedzy są właśnie dane historyczne. Pozwalają określić wcześniejsze szczyty ruchu, a następnie wykorzystać je jako punkt odniesienia w testach.

Samo odtworzenie zeszłorocznego Black Week to jednak za mało. Jedną z praktyk stosowanych przy przygotowaniu platformy jest symulowanie przynajmniej dwukrotności wcześniejszego szczytowego obciążenia. Celem nie jest sprawdzenie wyłącznie scenariusza, którego już doświadczyliśmy, ale znalezienie odpowiedzi na znacznie ważniejsze pytanie: gdzie znajduje się granica systemu, jeśli tegoroczna kampania okaże się większym sukcesem niż poprzednia?

Nie testuj tylko ruchu. Znajdź punkt, w którym system przestaje sobie radzić

„Testy obciążeniowe” często traktuje się jak jedno zadanie do odhaczenia przed dużą kampanią. Tymczasem odpowiadają one na różne pytania.

Load testing pozwala sprawdzić, jak platforma zachowuje się pod długotrwałym, wysokim obciążeniem. Stress testing idzie dalej - zwiększamy ruch do momentu, w którym system osiąga swoje granice. To właśnie drugi scenariusz daje biznesowi szczególnie ważną informację: ile dodatkowego popytu jesteśmy w stanie obsłużyć, zanim zaczną pojawiać się problemy? Nie wystarczy przy tym obserwować samego serwera. Wąskim gardłem może być baza danych, checkout, wyszukiwarka produktów albo integracja z zewnętrznym dostawcą.

Dlatego realistyczny test powinien odtwarzać zachowanie klienta: wyszukanie produktu, wejście na kartę, dodanie go do koszyka, zastosowanie rabatu, wybór dostawy, płatność i przekazanie zamówienia do kolejnych systemów. Dopiero wtedy testujemy sprzedaż, a nie tylko liczbę wejść na stronę.

Marketing wysyła newsletter o 18:00. Co IT powinno wiedzieć wcześniej?

Technologia może przygotować się tylko na scenariusze, o których wie. Jeśli o 18:00 marketing wysyła kampanię do dużej bazy, konkretny produkt trafia na homepage, a dodatkowo uruchamiana jest ograniczona czasowo promocja, dla IT są to trzy bardzo konkretne informacje o spodziewanym obciążeniu. Zespół technologiczny powinien wcześniej znać harmonogram kampanii, planowane promocje, produkty, na które kierowany będzie największy ruch, oraz spodziewane skoki liczby użytkowników. Dzięki temu może sprawdzić właśnie te elementy platformy, które w danym scenariuszu będą najbardziej obciążone.

Działa to również w drugą stronę. Jeśli technologia wie, że konkretny mechanizm promocji, integracja czy element checkoutu może stać się wąskim gardłem, biznes powinien wiedzieć o tym przed uruchomieniem kampanii.

W Black Week kalendarz marketingowy jest więc również informacją techniczną.

99,9% uptime'u nie mówi Ci, ile zamówień właśnie straciłeś

Wysoki uptime mówi, że platforma jest dostępna. Nie mówi, czy klient może na niej skutecznie kupić. Dlatego podczas Black Week warto monitorować nie tylko infrastrukturę, ale również cały proces generowania przychodu: wyszukiwanie produktów, aktualność cen i stanów magazynowych, naliczanie rabatów, dodawanie do koszyka, checkout, poszczególne metody płatności oraz przepływ zamówienia do kolejnych systemów.

W praktyce oznacza to również testowanie różnych scenariuszy: zakupów użytkownika zalogowanego i gościa, różnych metod dostawy i płatności, rabatów czy podatków.

Monitoring techniczny powinien z kolei obejmować między innymi czas odpowiedzi systemu oraz błędy API. Jeżeli jedna z usług zaczyna odpowiadać coraz wolniej albo rośnie liczba błędów, zespół powinien zobaczyć to wcześniej niż klient zgłaszający problem do supportu. Najważniejszą metryką podczas Black Week nie jest więc wyłącznie dostępność sklepu. Jest nią zdolność całej ścieżki zakupowej do zamiany ruchu w poprawnie zrealizowane zamówienie.

Skalowanie nie oznacza utrzymywania maksymalnej mocy przez cały rok

Przed Black Week biznes inwestuje w kampanie reklamowe, promocje, zatowarowanie, logistykę i pozyskanie ruchu. Technologia musi być przygotowana na obsłużenie efektu tych inwestycji. Nie oznacza to jednak utrzymywania przez cały rok infrastruktury potrzebnej podczas kilku najbardziej intensywnych dni. Architektura może pozwalać na zwiększanie dostępnych zasobów wtedy, gdy rośnie zapotrzebowanie, a następnie ich ograniczenie po zakończeniu szczytu sprzedażowego - wyjaśnia Wojciech Pindel.

Kluczowe jest jednak to, co skalujemy. W architekturze mikroserwisowej poszczególne funkcje biznesowe mogą działać jako niezależne komponenty. Jeżeli podczas promocji szczególnie mocno obciążony jest katalog produktów, można zwiększyć zasoby właśnie dla niego, zamiast skalować całą platformę.

Podobną rolę odgrywa przetwarzanie asynchroniczne. Nie każda operacja musi zakończyć się w momencie, gdy klient czeka na odpowiedź strony. Część zadań może trafić do kolejki i zostać wykonana w tle, dzięki czemu najbardziej krytyczne elementy procesu zakupowego nie muszą czekać na zakończenie wszystkich operacji.

To właśnie takie decyzje architektoniczne podjęte miesiące wcześniej decydują później o tym, jak platforma reaguje na gwałtowny wzrost ruchu.

Im bliżej Black Week, tym mniej miejsca na ryzykowne zmiany

Jednym z najgorszych momentów na duże wdrożenie jest okres bezpośrednio przed największym szczytem sprzedaży. Dlatego zamiast dużych zmian, warto wcześniej wdrażać mniejsze aktualizacje i ograniczać ryzyko związane z ich publikacją. Pomagają w tym m.in. feature flags, które pozwalają wdrożyć kod bez natychmiastowego udostępniania funkcji wszystkim użytkownikom. Jeśli pojawia się problem, funkcję można wyłączyć bez wycofywania całego wdrożenia.

Drugim rozwiązaniem jest canary deployment - nowa wersja trafia najpierw do niewielkiej części użytkowników. Dopiero gdy monitoring potwierdzi, że działa prawidłowo, można zwiększać jej dostępność. Dynamiczna konfiguracja pozwala natomiast zmieniać wybrane parametry systemu bez ponownego wdrażania aplikacji. - kontynuuje Wojciech Pindel.

W Black Week szybkość reakcji jest ważna, ale równie ważne jest ograniczenie ryzyka, że naprawiając jeden problem, stworzymy kolejny.

Black Week pokazuje problemy, które powstały dużo wcześniej

Nagły wzrost ruchu rzadko tworzy problem od zera. Częściej ujawnia ograniczenie, które przez resztę roku było niewidoczne. Integracja, która działa wystarczająco szybko przy standardowej liczbie zamówień, może stać się wąskim gardłem przy znacznie większym obciążeniu. Proces wymagający sporadycznej ręcznej interwencji zaczyna blokować operacje, gdy trzeba powtórzyć go setki razy. Baza danych, która radzi sobie ze standardowym ruchem, może zacząć spowalniać pozostałe elementy platformy.

Dlatego po Black Week warto analizować nie tylko przychód, konwersję czy ROAS, ale również techniczne granice platformy:

- przy jakim obciążeniu zaczęły rosnąć czasy odpowiedzi,

- które komponenty były najbliżej swoich limitów,

- gdzie pojawiły się błędy lub kolejki,

- które integracje ograniczały przepustowość,

- gdzie potrzebna była ręczna interwencja,

- jak szybko zespół wykrywał i rozwiązywał problemy.

To są dane, które powinny trafić do planu rozwoju e-commerce'u na kolejny rok.

Doświadczenia Fabres ze współpracy z Komplett pokazują, dlaczego przygotowania do kolejnego Black Week zaczynają się w praktyce długo przed listopadem. Największy szczyt sprzedażowy daje zespołowi technologicznemu coś, czego nie da zwykły tydzień - realne dane o tym, gdzie kończy się komfortowa strefa działania platformy.

A dla biznesu odpowiedź na jeszcze ważniejsze pytanie: ile większą sprzedaż jesteśmy w stanie obsłużyć, zanim technologia zacznie ograniczać nasz wzrost?

To nie jest problem wyłącznie największych graczy

Łatwo pomyśleć, że skoro mowa o jednym z największych e-commerce'ów w Norwegii, to wnioski dotyczą tylko firm tej skali. W praktyce jest odwrotnie. Duży gracz ma zwykle bufor - zespół, który zareaguje w nocy, zapas mocy, procedury awaryjne. Mniejszy sklep tego bufora często nie ma, więc ten sam problem - wolne ładowanie, błąd płatności, rozjazd stanów magazynowych - uderza w niego proporcjonalnie mocniej. Jeśli Black Week odpowiada za znaczącą część rocznego przychodu, awaria w tym tygodniu nie jest niedogodnością, tylko realną stratą, której nie da się odrobić w grudniu. Skala Komplett pokazuje te mechanizmy w powiększeniu - ale te same mechanizmy działają w sklepie, który w szczycie obsługuje kilkaset zamówień dziennie zamiast kilkudziesięciu tysięcy.

Chcesz pracować z doświadczonym dostawcą technologii? Skontaktuj się: [email protected]