Real User Monitoring: Jak przestaliśmy zgadywać i wskazaliśmy IT, co dokładnie psuje sprzedaż w e-commerce
Zwalidowane zdarzenia
z prawdziwych sesji zakupowych
30-second summary
Projekt i wdrożenie systemu analityki wydajności opartego na danych od realnych użytkowników (RUM), diagnoza wąskich gardeł oraz przygotowanie gotowych do wdrożenia wytycznych dla działu IT.
Klient i rola TALEM
Klient: Duży sklep internetowy z asortymentem sportowym (rowery, sprzęt turystyczny, sporty zimowe), działający na kilku rynkach europejskich.
Rola TALEM: Projekt i wdrożenie systemu analityki wydajności opartego na danych od realnych użytkowników (RUM), diagnoza wąskich gardeł oraz przygotowanie gotowych do wdrożenia wytycznych dla działu IT.
Czas trwania: 9 tygodni do pierwszego pełnego raportu, następnie monitoring ciągły.
NASZ KLIENT
Duży sklep internetowy z asortymentem sportowym
BRANŻA
E-commerce sportowy, multi-market (rowery, turystyka, sporty zimowe)
CZAS TRWANIA
9 tygodni do pierwszego raportu, następnie monitoring ciągły
ZAKRES
RUM, web-vitals.js, Server-Side GTM, BigQuery, Looker Studio
Punkt wyjścia: Kiedy dane laboratoryjne to za mało
Projekt dotyczył serwisu, którego specyfika wymusza rozbudowaną architekturę. Rower to nie jeden SKU, ale rozmiar ramy, wariant osprzętu i kolor. W efekcie ścieżka klienta jest długa: użytkownik filtruje, porównuje modele, sprawdza tabele geometrii.
Do tego dochodzi kluczowy czynnik – sezonowość. Sklep przeżywa potężne piki ruchu zimą (narty) i latem (rowery). To właśnie w tych wąskich oknach sprzedażowych wydajność serwisu ma krytyczne znaczenie dla przychodów.
Firma korzystała ze standardowych narzędzi i sprawdzała wydajność w PageSpeed Insights. Niestety, narzędzie to miało ograniczenia, które uniemożliwiały skuteczną optymalizację:
- Dane laboratoryjne i mocno zagregowane terenowe: Test Lighthouse to symulacja jednego urządzenia na stabilnym łączu – nie mówi nic o kliencie sprawdzającym dostępność sprzętu na stoku narciarskim przy słabym zasięgu LTE. Dane terenowe z CrUX w PSI są z kolei uśrednione (poziom originu/URL, 28-dniowe okno), dostępne tylko dla adresów o dużym ruchu i bez wskazania, który element odpowiada za problem.
- Brak szerszego obrazu: Skuteczne, ręczne sprawdzanie setek podstron kategorii i produktów jest nierealne.
- Ślepota na szczyty sezonu: Test uruchomiony w maju nie przewidzi zachowania serwisu podczas pierwszego śnieżnego weekendu w roku, przy wielokrotnie większym obciążeniu.
- Brak konkretów dla IT: Informacja o przekroczeniu metryki CLS nie podpowiada programiście, który dokładnie element kodu odpowiada za problem.
Cel projektu
Zbudowanie systemu, który zmierzy wydajność na podstawie prawdziwych sesji użytkowników, wskaże konkretne błędy w kodzie i nie obciąży dodatkowo samego serwisu.
Architektura rozwiązania: Od pomiaru do decyzji biznesowej
Zaprojektowany system składa się z pięciu warstw. Aby zachować najwyższą precyzję i odsiać ruch z botów, zawęziliśmy początkową analizę do kluczowych ścieżek zakupowych i głównych rynków. Zgromadziliśmy reprezentatywną próbę ponad 329 000 zwalidowanych zdarzeń z 566 kluczowych adresów URL.
Zbieranie danych u źródła (web-vitals.js)
Wykorzystaliśmy oficjalną bibliotekę Google web-vitals.js – tę samą, która mierzy Core Web Vitals zgodnie z metodologią Chrome i Chrome UX Report (CrUX). Różnica jest kluczowa: CrUX to zagregowane, publiczne dane zbierane bezpośrednio przez przeglądarkę, podczas gdy web-vitals.js pozwala zbierać własną telemetrię na poziomie pojedynczej odsłony – a tylko taka umożliwia trafną diagnozę i szybką reakcję na regresje. Dzięki temu system nie dostarcza suchych liczb, ale precyzyjnie wskazuje konkretny selektor CSS i element DOM wywołujący problem.
GA4 powiązane ze ścieżką zakupową
Zestawiliśmy metryki wydajnościowe z realnymi zachowaniami użytkowników: od użycia filtrów, przez konfiguratory sprzętu, aż po dodanie produktu do koszyka.
Server-Side GTM: Szybkość bez kompromisów
Przenieśliśmy obsługę tagów analitycznych z przeglądarki użytkownika na własny serwer w usłudze Google Cloud Run. Znacznie odciążyło to witrynę i uodporniło pomiary na blokery reklam.
BigQuery: Standaryzacja analityki
Wdrożyliśmy natywny eksport danych do BigQuery i zbudowaliśmy warstwę modeli SQL. Zagwarantowało to niezmienność definicji metryk i umożliwiło miarodajne porównania wydajności "rok do roku" przed kolejnymi szczytami sprzedaży.
Looker Studio: Trzy poziomy raportowania
Stworzyliśmy dedykowane widoki: techniczny dla działu IT (szczegóły kodu), alertowy pod nadchodzące sprinty programistyczne oraz biznesowy dla zarządu (wpływ wydajności na konwersje).
Co pokazały dane (i dlaczego uśrednianie maskuje problemy)
Gdybyśmy opierali się wyłącznie na uśrednionych wartościach dla całego serwisu (LCP na poziomie 0,8 s, CLS bliski zera), wniosek byłby jednoznaczny: witryna działa bez zarzutu.
W rzeczywistości setki szybkich, ale rzadziej odwiedzanych podstron skutecznie maskowały krytyczne problemy na stronach o największym znaczeniu biznesowym. Szczegółowa analiza RUM ujawniła trzy kluczowe wąskie gardła:
Czas odpowiedzi serwera (TTFB) dusił stronę główną.
Najbardziej eksponowane strony wejściowe notowały TTFB na poziomie 2,5 sekundy (przy progu Google wynoszącym 800 ms). Wąskim gardłem okazało się pobieranie zasobów statycznych z osobnej subdomeny. Dopóki serwer nie zacznie odpowiadać szybciej, optymalizacja warstwy wizualnej (np. banerów) mija się z celem.
Jeden błąd CLS psuł wszystkie listingi kategorii.
Dane udowodniły, że za przeskoki układu na listach produktów odpowiadał ten sam kontener. Diagnoza wskazała konkretną przyczynę: opóźnione ładowanie właściwości CSS order. Dział IT otrzymał precyzyjne zadanie zamiast ogólnej wytycznej.
Wyszukiwarka frustrowała klientów (INP).
Responsywność paska wyszukiwania wynosiła nawet 285 ms. W e-commerce z tak rozbudowanym asortymentem każda sekunda opóźnienia w podpowiedziach wyszukiwarki bezpośrednio uderza w ścieżkę zakupową zdecydowanego klienta.
Biznesowe konsekwencje: Ile kosztuje ignorowanie tych błędów?
Celem projektu było dostarczenie działowi IT klienta precyzyjnych i gotowych do wdrożenia wytycznych – ten cel został zrealizowany, a zadania trafiły do backlogu programistów.
Nawet jeśli proces wdrażania zmian w architekturze sklepu trwa, potencjał biznesowy jest łatwy do oszacowania. Zgodnie z badaniami Google i Deloitte dla branży e-commerce, poprawa mobilnego czasu ładowania o zaledwie 0,1 sekundy może przełożyć się na wzrost współczynnika konwersji o ok. 8%. Dla analizowanego sklepu, skrócenie czasu odpowiedzi serwera (TTFB) z 2,5 sekundy do rekomendowanych 0,8 sekundy stanowi ogromną szansę na redukcję liczby porzuconych koszyków, szczególnie w kluczowych tygodniach sezonu.
przy progu Google 800 ms
frustrujące dla zdecydowanych klientów
za każde 0,1 s poprawy (Google/Deloitte)
Rezultat: Od domysłów do twardych danych
Skutkiem wdrożenia było przejście z analityki opartej na symulacjach na twarde dane z urządzeń użytkowników. IT otrzymało gotową listę zadań, spriorytyzowaną na podstawie realnego obciążenia poszczególnych podstron.
Przed — PageSpeed Insights
Symulacja jednego urządzenia (Lighthouse) + zagregowane dane terenowe CrUX
Po — RUM przez TALEM
Zdarzenia z prawdziwych sesji zakupowych, na poziomie pojedynczej odsłony
Przed — PageSpeed Insights
Ogólna informacja o przekroczeniu wskaźnika
Po — RUM przez TALEM
Konkretny element DOM / selektor CSS
Przed — PageSpeed Insights
Pojedyncze, wyrywkowe testy podstron
Po — RUM przez TALEM
Ciągły monitoring setek kluczowych adresów URL
Przed — PageSpeed Insights
Oparta na subiektywnych ocenach lub audytach ad hoc
Po — RUM przez TALEM
Oparta na faktycznym ruchu na ścieżce konwersji
Przed — PageSpeed Insights
Ręczne, problem zauważany zazwyczaj po fakcie
Po — RUM przez TALEM
Automatyczne alerty o przekroczeniu progów wydajności
Kluczowe lekcje dla Twojego e-commerce:
Średnia to pułapka.
Dobry ogólny wynik witryny może ukrywać krytyczne błędy na stronach generujących największy ruch i przychód.
RUM daje rozwiązania, nie tylko diagnozy.
Analiza wydajności ma sens tylko wtedy, gdy kończy się precyzyjną wytyczną dla programisty.
Wydajność to proces ciągły.
Zmiana materiałów promocyjnych przed Black Friday może nieświadomie obciążyć serwis. Stały monitoring RUM pozwala wykryć ten problem natychmiast, a nie pod koniec sezonu.
Nie trać budżetu w kolejnym szczycie sezonu przez wolną stronę.
Zgadywanie, co dokładnie spowalnia Twój e-commerce, zajmuje czas i kosztuje. Opieraj decyzje optymalizacyjne na twardych danych pochodzących bezpośrednio z urządzeń Twoich klientów.
Zarezerwuj spotkanie techniczne