Sklep ma działać przez 99,99% czasu. Tylko czy to wystarczy, żeby dobrze sprzedawał?

Weźmy dwa hipotetyczne sklepy internetowe. Pierwszy osiąga 99,9% uptime'u, ale działa bardzo szybko. Drugi może pochwalić się dostępnością na poziomie 99,99%, tyle że otwieranie kolejnych podstron, przeglądanie produktów i przechodzenie przez koszyk zajmuje w nim wyraźnie więcej czasu.

Z perspektywy SLA drugi sklep wygląda lepiej, bo ma dziesięciokrotnie mniejszy budżet niedostępności. Pytanie tylko, czy przekłada się to na lepszy wynik biznesowy.

W branży IT przywiązujemy sporą wagę do dostępności usług. Mamy SLA, monitoring, systemy wysokiej dostępności, procedury reagowania na incydenty i całą masę narzędzi, które mają pomóc nam utrzymać infrastrukturę w ruchu. Zresztą słusznie, bo trudno wyobrazić sobie prowadzenie sklepu internetowego, który regularnie przestaje działać. Zastanawia mnie jednak, czy nie poświęcamy czasem zbyt dużo uwagi samej dostępności, a zbyt mało temu, jak sklep działa wtedy, gdy jest dostępny.

Zacząłem szukać badań, które pozwoliłyby porównać wpływ awarii i niskiej wydajności na konwersję. Okazuje się, że o wpływie szybkości działania na zachowania klientów wiemy całkiem sporo. Gorzej z bezpośrednim porównaniem kosztu krótkotrwałych awarii i permanentnie wolnego działania sklepu.

Nie znalazłem wiarygodnego badania, które jednoznacznie rozstrzygałoby, że niższy uptime połączony z lepszą wydajnością daje wyższą sprzedaż. Są jednak badania, które pozwalają przyjrzeć się temu problemowi z nieco innej strony.

Dostępny nie zawsze oznacza użyteczny

Typowy monitoring dostępności sprawdza, czy usługa odpowiada na żądania. Możemy go oczywiście rozbudować o testy syntetyczne, monitorowanie konkretnych endpointów czy całych procesów zakupowych, ale podstawowy pomiar uptime'u niewiele mówi o rzeczywistym doświadczeniu użytkownika.

Jeżeli strona produktu ładuje się osiem sekund, a przejście do koszyka zajmuje kolejne pięć, to z technicznego punktu widzenia sklep może działać zupełnie poprawnie. Serwer zwraca odpowiedzi, baza danych jest dostępna, wszystkie komponenty infrastruktury są oznaczone na zielono. Klient tymczasem czeka i zastanawia się, czy nie kupić produktu gdzie indziej.

Nie chodzi przy tym wyłącznie o czas początkowego ładowania strony. W nowoczesnych aplikacjach e-commerce równie istotna jest responsywność interfejsu. Produkt może wyświetlić się szybko, ale filtrowanie kategorii, wybór wariantu czy aktualizacja zawartości koszyka potrafią skutecznie zepsuć całe doświadczenie zakupowe.

Dlatego sam Time to First Byte nie wystarcza do oceny wydajności sklepu. Szybka odpowiedź serwera nie gwarantuje, że użytkownik szybko zobaczy interesującą go treść, a tym bardziej, że będzie mógł sprawnie wejść z nią w interakcję.

W praktyce możemy więc mieć usługę o doskonałej dostępności infrastrukturalnej, która niemal przez cały czas oferuje klientom słabe doświadczenie. Taki problem nie musi powodować żadnych alarmów, jeżeli monitoring nie został przygotowany z myślą o rzeczywistych ścieżkach użytkowników.

Jak duże znaczenie ma szybkość strony? Sprawdzono to w badaniach

Jedną z ciekawszych prac poświęconych temu zagadnieniu jest Need for Speed: The Impact of In-Process Delays on Customer Behavior in Online Retail, opublikowana w 2023 roku w czasopiśmie Operations Research.

Autorzy, Santiago Gallino, Nil Karacaoglu i Antonio Moreno, przeanalizowali zależność między opóźnieniami występującymi podczas zakupów internetowych a zachowaniem klientów. Oszacowali, że pogorszenie szybkości działania witryny o 10% może prowadzić do spadku sprzedaży o 4,2% oraz współczynnika konwersji o około 2%. Wpływ opóźnień nie był jednakowy na wszystkich etapach zakupów: największą wrażliwość na spowolnienia zaobserwowano podczas finalizacji zamówienia.

Ma to sporo sensu. Użytkownik, który dopiero przegląda produkty, może zaakceptować pewne niedogodności. Kiedy jednak zdecydował się na zakup i chce zapłacić, dodatkowe opóźnienia stają się kolejną przeszkodą na drodze do zakończenia transakcji. Nie trzeba nawet doprowadzić do technicznego błędu, żeby część takich zakupów nie doszła do skutku.

Wyniki jednego badania nie oznaczają, że każde spowolnienie dowolnego sklepu o 10% spowoduje identyczny spadek sprzedaży. Wiele zależy od branży, charakterystyki klientów, urządzeń czy punktu wyjścia. Badanie pokazuje jednak, że wydajność ma mierzalne znaczenie ekonomiczne i trudno traktować ją wyłącznie jako kwestię komfortu użytkownika.

Są też eksperymenty, w których poprawę wydajności testowano wprost.

W 2021 roku Vodafone opublikował wyniki eksperymentu A/B przeprowadzonego na jednej ze swoich stron docelowych, do której kierowano ruch z płatnych kampanii. Przygotowano dwa warianty o takim samym wyglądzie i funkcjonalności, z których jeden został zoptymalizowany pod kątem szybkości działania.

Wersja zoptymalizowana uzyskała o 31% lepszy wynik Largest Contentful Paint (LCP), czyli metryki opisującej czas wyrenderowania największego widocznego elementu treści. W grupie korzystającej z tej wersji odnotowano 8% większą sprzedaż oraz 11% wyższy odsetek odwiedzających, którzy weszli do koszyka.

Podobny eksperyment przeprowadził Rakuten 24, japoński sklep internetowy. W miesięcznym teście A/B zoptymalizowana strona docelowa osiągnęła współczynnik konwersji wyższy o 33,13%, a przychód na odwiedzającego wzrósł o 53,37%.

Te liczby robią wrażenie, ale to wyniki konkretnych eksperymentów, a nie gotowa obietnica dla wszystkich sklepów. Rakuten nie udowodnił przecież, że każda firma może zwiększyć przychody o połowę, poprawiając wydajność aplikacji.

Z raportu Deloitte i Google Milliseconds Make Millions z 2020 roku często przytacza się jedną liczbę. Badanie obejmowało 37 marek i około 30 milionów sesji mobilnych z czterech tygodni. W handlu detalicznym poprawa czterech metryk szybkości o 0,1 sekundy szła w parze ze wzrostem konwersji na urządzeniach mobilnych o 8,4%.

Problem w tym, że statystyka ta bywa przytaczana w oderwaniu od metodologii. Nie był to eksperyment pokazujący, że przyspieszenie dowolnej witryny o 100 milisekund automatycznie zwiększy jej konwersję o 8,4%. Autorzy obserwowali naturalne zmiany szybkości stron i zestawiali je z wynikami biznesowymi, więc mówimy o korelacji, a nie o udowodnionej przyczynie.

Mimo tych ograniczeń poszczególne opracowania prowadzą do zbliżonego wniosku. Szybkość działania sklepu może wpływać na konwersję, a efekt bywa na tyle istotny, że uzasadnia traktowanie optymalizacji wydajności jako inwestycji biznesowej.

A co, jeśli wolna strona kosztuje więcej niż krótka awaria?

Awaria jest zwykle zdarzeniem ograniczonym w czasie. Sklep przestaje działać, monitoring zgłasza problem, ktoś podejmuje działania naprawcze i po przywróceniu usługi ruch może wrócić do normy. Oczywiście konsekwencje awarii mogą utrzymywać się znacznie dłużej, szczególnie jeśli dotyczyła ona zamówień, płatności lub danych klientów.

Z wolno działającym sklepem sytuacja jest inna. Jeżeli problem ma charakter permanentny, wpływa na kolejne sesje przez cały dzień, tydzień czy miesiąc. Użytkownik nie musi trafić na żadną awarię, aby jego doświadczenie zakupowe było na tyle złe, że ostatecznie nie dokona zakupu.

Możemy to zilustrować prostym przykładem.

Załóżmy, że dwa sklepy obsługują po 100 tysięcy potencjalnych wizyt miesięcznie. Pierwszy ma dostępność na poziomie 99%, ale dzięki lepszej wydajności konwertuje 3% obsłużonych wizyt. Drugi pozostaje dostępny przez cały badany okres, lecz jego współczynnik konwersji wynosi 2,8%.

Jeżeli dla uproszczenia przyjmiemy, że niedostępność pierwszego sklepu obejmuje dokładnie 1% potencjalnego ruchu, a utraceni użytkownicy nie wracają później, otrzymamy 2970 zamówień w pierwszym przypadku i 2800 w drugim.

Sklep z niższym uptime'em zrealizowałby więc około 6% więcej zamówień.

Nie jest to wynik żadnego z przytoczonych badań, tylko przykład matematyczny. Celowo wykorzystałem niewielką różnicę we współczynniku konwersji, żeby pokazać, że do zrekompensowania części niedostępności nie potrzeba spektakularnej poprawy wydajności.

Tyle że równie łatwo można skonstruować przykład odwrotny.

Wystarczy, że awaria szybszego sklepu przypadnie na moment rozpoczęcia dużej kampanii promocyjnej. Dostępność czasowa nadal może wynosić 99%, ale jeżeli w czasie niedostępności próbowało wejść 10% miesięcznego ruchu, potencjalne straty będą zupełnie inne. Przy pozostałych założeniach pierwszy sklep zrealizuje 2700 zamówień i tym razem przegra z wolniejszym konkurentem.

Dochodzi jeszcze kwestia zachowania klientów. Część osób po zobaczeniu błędu spróbuje ponownie, niektórzy wrócą za godzinę, a inni zrezygnują całkowicie. Bez uwzględnienia tych powrotów nie sposób rzetelnie policzyć rzeczywistego kosztu awarii.

Dlatego nie da się wyznaczyć jednego, uniwersalnego progu dostępności, poniżej którego bardziej opłaca się inwestować w szybkość niż w niezawodność. Można natomiast obliczyć taki próg dla konkretnego sklepu, mając odpowiednie dane o ruchu, konwersji i historii incydentów.

I właśnie takie porównanie byłoby znacznie bardziej wartościowe niż dyskusja prowadzona wyłącznie na podstawie deklarowanego SLA.

Problem w tym, że możemy nawet nie wiedzieć, ile naprawdę tracimy

Współczynnik konwersji liczony w narzędziu analitycznym nie musi uwzględniać wszystkich użytkowników, którzy rzeczywiście próbowali wejść na stronę. Jeśli sklep nie wczyta się na tyle, aby uruchomić kod analityczny, część takich prób po prostu nie trafi do raportów.

Wyobraźmy sobie 100 tysięcy potencjalnych wizyt i 2000 zamówień, co daje konwersję na poziomie 2%. W kolejnym miesiącu awaria uniemożliwia zarejestrowanie 10 tysięcy prób wejścia, a sklep realizuje 1900 zamówień.

Jeżeli narzędzie analityczne widzi tylko 90 tysięcy wizyt, pokaże współczynnik konwersji wynoszący około 2,11%. Wygląda to na poprawę, chociaż liczba zamówień spadła.

W rzeczywistości ten przykład jest jeszcze bardziej skomplikowany, ponieważ narzędzia analityczne różnie definiują sesje, użytkowników i zdarzenia. Dodatkowo nie każdy błąd ładowania strony oznacza utratę całej sesji, podobnie jak nie każda awaria uniemożliwia uruchomienie analityki.

Nie zmienia to podstawowego problemu: pomiar konwersji oparty wyłącznie na sesjach, które udało się zarejestrować, może nie pokazywać pełnej skali strat.

Podobnie jest w przypadku wydajności. Jeśli użytkownik opuszcza stronę, zanim zostaną zarejestrowane odpowiednie dane, możemy nie widzieć całego problemu również w statystykach wydajnościowych.

Z tego powodu sensowne byłoby zestawianie danych analitycznych z logami CDN i serwerów, niezależnym monitoringiem, danymi z kampanii reklamowych oraz informacjami pochodzącymi bezpośrednio z systemu zamówień. Każde z tych źródeł ma swoje ograniczenia, ale dopiero ich połączenie pozwala zbliżyć się do rzeczywistego obrazu sytuacji.

Trzeba też odróżniać utracone zamówienia od zamówień przesuniętych w czasie. Jeżeli klient wrócił po godzinie i sfinalizował zakup, skutek finansowy awarii będzie inny niż w przypadku osoby, która zdecydowała się na konkurencyjny sklep.

Może więc powinniśmy inaczej rozmawiać o SLA?

Nie uważam, żeby klasyczne SLA straciło sens. Dostępność jest ważna, a awarie potrafią być dla e-commerce katastrofalne, szczególnie w okresach zwiększonego ruchu. Nie ma też dobrego powodu, żeby świadomie tolerować częste przerwy w działaniu tylko dlatego, że sklep jest szybki.

Mam natomiast wrażenie, że rozmowy o jakości usług infrastrukturalnych zbyt łatwo sprowadzają się do procentów dostępności, podczas gdy wpływ codziennej wydajności na działalność klienta pozostaje gdzieś na drugim planie.

Jeśli firma rozważa inwestycję w kolejny mechanizm wysokiej dostępności, warto wiedzieć, jakie ryzyko biznesowe ta inwestycja faktycznie ogranicza. Zwłaszcza gdy alternatywą jest rozwiązanie problemów wydajnościowych, które wpływają na zakupy klientów każdego dnia.

W podejściu Site Reliability Engineering od dawna funkcjonują pojęcia SLI i SLO, które pozwalają definiować jakość usługi z perspektywy użytkownika. Można więc mierzyć nie tylko to, czy aplikacja odpowiada, ale również czy wykonuje określone operacje w akceptowalnym czasie.

W przypadku sklepu internetowego oznacza to między innymi skuteczność i czas realizacji kluczowych etapów zakupów. Czy użytkownik może otworzyć produkt? Czy może dodać go do koszyka? Jak długo czeka na reakcję interfejsu i czy proces płatności rzeczywiście kończy się sukcesem?

Dla warstwy przeglądarkowej warto obserwować Core Web Vitals, w szczególności LCP i INP. Nie zastąpią one jednak monitoringu aplikacji, bazy danych czy usług zewnętrznych. Nawet bardzo dobre wyniki Core Web Vitals nie gwarantują przecież poprawnego działania checkoutu.

Najbardziej użyteczne byłoby połączenie tych informacji z metrykami biznesowymi. Dzięki temu można sprawdzić, czy pogorszenie wydajności konkretnego elementu sklepu wiąże się ze wzrostem liczby porzuconych koszyków i czy wprowadzone optymalizacje rzeczywiście poprawiają wyniki.

Samo współwystępowanie dwóch zmian nie dowodzi jeszcze związku przyczynowego. Na sprzedaż wpływają przecież promocje, ceny, sezonowość, kampanie i wiele innych czynników. Tam, gdzie to możliwe, warto więc korzystać z eksperymentów A/B lub przynajmniej analiz uwzględniających te zmienne.

Ile dostępności gwarantują właściwie dostawcy infrastruktury?

W rozmowach o hostingu często przewijają się wartości 99,9% czy 99,99%, ale rzadko pada pytanie, czego dokładnie dotyczy ta gwarancja.

Operatorzy centrów danych potrafią gwarantować w umowie bardzo wysoką dostępność zasilania. Atman podaje SLA na poziomie 99,999% i twierdzi, że rzeczywista dostępność zasilania w jego centrach danych wynosi 100% od kilkunastu lat. Gwarancje dla chłodzenia bywają niższe: T-Mobile podaje dla jednego ze swoich centrów miesięczną dostępność chłodzenia na poziomie 99,98%. Jedne i drugie dotyczą konkretnych elementów infrastruktury obiektu, a nie działającego w nim serwera, systemu operacyjnego czy aplikacji.

Gdy przejdziemy z poziomu fizycznego centrum danych do pojedynczej maszyny wirtualnej, gwarantowane wartości są znacznie niższe. I wcale nie trzeba szukać przykładów wśród mniejszych dostawców.

AWS dla pojedynczej instancji EC2 deklaruje SLA na poziomie 99,5%. W Microsoft Azure pojedyncza maszyna wirtualna wykorzystująca dyski Premium SSD lub Ultra Disk objęta jest gwarancją 99,9%, a w Google Cloud większość pojedynczych instancji Compute Engine w Premium Network Tier również ma SLA wynoszące 99,9%.

Dla porównania, 99,5% dostępności oznacza matematycznie około 3,6 godziny niedostępności w trzydziestodniowym miesiącu, zanim wynik spadnie poniżej deklarowanego poziomu. Przy 99,9% jest to około 43 minut, a przy 99,99% nieco ponad cztery minuty. Nie oznacza to oczywiście, że dostawca planuje tyle przestojów. To jedynie sposób na zobrazowanie różnicy między poziomami SLA.

Wyższe gwarancje są dostępne, ale często wiążą się z odpowiednią architekturą. AWS oferuje SLA 99,99% dla EC2 przy rozmieszczeniu działających instancji w co najmniej dwóch strefach dostępności. W Azure podobny poziom można uzyskać dla co najmniej dwóch maszyn wirtualnych rozmieszczonych w różnych strefach, a Google Cloud również przewiduje 99,99% dla konfiguracji wielostrefowych w wybranych regionach i wariantach sieciowych. Te gwarancje mają jednak określony zakres i nie oznaczają dostępności aplikacji na takim samym poziomie.

Dopiero tutaj zaczyna być widać, jak duża odpowiedzialność spoczywa na architekturze całego rozwiązania. Możemy umieścić serwery w centrum danych gwarantującym niemal nieprzerwane zasilanie, ale jeśli aplikacja działa na jednym serwerze i korzysta z pojedynczej instancji bazy danych, awaria któregokolwiek z tych elementów nadal może zatrzymać sprzedaż.

Nawet infrastruktura zaprojektowana z myślą o wysokiej dostępności nie eliminuje błędów aplikacyjnych, problemów z wdrożeniami czy awarii zewnętrznych integracji. Centrum danych może działać bez zarzutu, wszystkie maszyny mogą odpowiadać, a klienci i tak nie będą w stanie sfinalizować zamówienia.

SLA nie jest też polisą ubezpieczeniową od utraconych przychodów. Standardowe umowy z dostawcami infrastruktury najczęściej przewidują kredyty serwisowe lub zwrot części opłat za usługę, a nie pokrycie strat biznesowych spowodowanych awarią sklepu.

Dlatego porównując oferty infrastrukturalne, zwracałbym uwagę nie tylko na procent gwarantowanej dostępności, ale również na to, co faktycznie obejmuje SLA i gdzie kończy się odpowiedzialność dostawcy. Ostatecznie za dostępność procesu zakupowego odpowiada cały system, a nie pojedynczy element infrastruktury.

Wydajność czy dostępność? Niekoniecznie trzeba wybierać

Całe to porównanie może sugerować, że wydajność i niezawodność są ze sobą w konflikcie. W rzeczywistości bardzo często poprawa jednego z tych obszarów pomaga również drugiemu.

Dobrym przykładem jest cache. Prawidłowo zaprojektowany mechanizm buforowania może znacząco ograniczyć liczbę operacji wykonywanych przez aplikację i bazę danych, skracając czas odpowiedzi, a przy okazji zmniejszając ryzyko przeciążenia podczas zwiększonego ruchu.

Podobnie optymalizacja ciężkich zapytań, ograniczenie zbędnych operacji wykonywanych w trakcie generowania strony czy lepsze wykorzystanie CDN mogą poprawiać codzienną wydajność, a jednocześnie zwiększać odporność systemu na wzrost liczby użytkowników.

Są jednak inwestycje, które nie przynoszą takiej podwójnej korzyści. Dodatkowy region, zaawansowana replikacja czy bardziej rozbudowany mechanizm failover mogą zwiększyć niezawodność bez istotnej poprawy szybkości działania sklepu. W określonych przypadkach są absolutnie uzasadnione, ale niekoniecznie będą najlepszym sposobem wykorzystania kolejnego budżetu infrastrukturalnego.

Z drugiej strony optymalizacja wydajności niewiele pomoże, jeśli sklep regularnie przestaje przyjmować płatności albo doświadcza awarii prowadzących do utraty danych.

Dlatego zamiast szukać uniwersalnej odpowiedzi na pytanie, czy ważniejszy jest uptime, czy szybkość, lepiej zastanowić się, który problem w danym momencie najbardziej ogranicza działalność sklepu.

Aby to ustalić, trzeba patrzeć szerzej niż na sam stan serwerów.

Ile właściwie kosztuje nas zielony dashboard?

W infrastrukturze łatwo policzyć koszt dodatkowego serwera, nowego mechanizmu redundancji czy utrzymania kolejnego środowiska. Trudniej wycenić zamówienia, które nie doszły do skutku, ponieważ strona działała zbyt wolno.

Nie oznacza to, że powinniśmy zacząć rezygnować z wysokiej dostępności na rzecz wydajności. To raczej argument za tym, żeby obie rzeczy oceniać w odniesieniu do rzeczywistych potrzeb biznesowych.

Z badań, które udało mi się przeanalizować, wynika, że wydajność ma istotny wpływ na zachowanie klientów i może przekładać się na mierzalne różnice w konwersji oraz przychodach. Nie znalazłem natomiast wystarczających dowodów, żeby stwierdzić, że określony poziom niższej dostępności jest z definicji bardziej opłacalny niż wolniejsze działanie sklepu.

To ważne rozróżnienie, bo bez niego łatwo byłoby wyciągnąć niewłaściwy wniosek i uznać, że uptime jest mniej istotny. Nie jest. Po prostu nie opowiada całej historii.

Moim zdaniem, kiedy rozmawiamy o jakości infrastruktury e-commerce, powinniśmy częściej zadawać pytanie, ile rzeczywistych zakupów jesteśmy w stanie skutecznie obsłużyć, a nie tylko przez jaki procent miesiąca serwery odpowiadały na żądania.

Bo ostatecznie klient nie kupuje naszego SLA. Chce znaleźć produkt, wrzucić go do koszyka i bez problemów zapłacić. A czy na końcu miesiąca infrastruktura miała 99,9%, czy 99,99% dostępności, prawdopodobnie nawet nie będzie wiedział.

Źródła

1. Gallino, S., Karacaoglu, N., Moreno, A. (2023). Need for Speed: The Impact of In-Process Delays on Customer Behavior in Online Retail. Operations Research 71(3). DOI.
2. Wharton Magazine (2022). Why Online Retailers Have a 'Need for Speed' - wywiad z jednym z autorów, źródło liczb 4,2% i 2%.
3. Google / Vodafone (2021). A 31% improvement in LCP increased sales by 8%.
4. Google / Rakuten 24. How Rakuten 24's investment in Core Web Vitals increased revenue per visitor.
5. Deloitte / Google (2020). Milliseconds Make Millions.
6. Atman. Bezpieczeństwo energetyczne.
7. T-Mobile Biznes. Nowoczesne Centrum Danych.
8. AWS. Amazon Compute Service Level Agreement.
9. Microsoft. SLA for Virtual Machines.
10. Google Cloud. Compute Engine Service Level Agreement.
11. Google. Site Reliability Engineering - Implementing SLOs.
12. Google. Web Vitals.