Analiza ścieżek użytkowników na stronie pokazuje, jak ludzie naprawdę przechodzą przez serwis od wejścia aż do konwersji, porzucenia albo powrotu. To nie jest konkurs na odsłony. Liczy się kolejność kroków, momenty zawahania i te miejsca, w których użytkownik nagle traci orientację. Dzięki temu widać jak na dłoni, które ekrany pchają go dalej, a które wyhamowują cały proces. Sprawdza się to w sklepach, na stronach usługowych, landing page’ach, formularzach i w panelach klienta. Największą wartość daje wtedy, gdy kończy się konkretem: co zmienić w UX, co doprecyzować w treści, jakie zdarzenia domierzyć i które etapy procesu po prostu uprościć. Ale uwaga, żeby wnioski były wiarygodne, najpierw trzeba sprawdzić, czy pomiar faktycznie łapie zachowania użytkownika, a nie potknięcia wdrożenia.
Czym jest analiza ścieżek użytkowników na stronie?
Analiza ścieżek użytkowników na stronie to obserwacja realnych tras: od źródła wejścia, przez kolejne ekrany i interakcje, aż do konwersji, wyjścia albo przerwania procesu. Brzmi prosto. W praktyce nie sprowadza się to do jednego raportu w narzędziu analitycznym, bo sam wykres bez kontekstu potrafi bardziej zaciemniać niż wyjaśniać. Kluczowe jest też sprawdzenie, czy dane zbierają się poprawnie i czy to, co widzisz w raportach, ma sens biznesowy, a nie tylko „ładnie wygląda”.
W praktyce bierze się na warsztat i ścieżki główne, i drobne mikrointerakcje. To mogą być przejścia z reklamy na landing page, wejścia do formularza, kliknięcia CTA, użycie wyszukiwarki, filtrowanie produktów, błędy walidacji, powroty do poprzednich kroków czy porzucenie koszyka. Pytanie brzmi: gdzie użytkownik utknął i co go do tego skłoniło. Najważniejsze jest nie to, gdzie użytkownik był, ale dlaczego nie przeszedł do następnego logicznego kroku.
Taka usługa pozwala wyłapać miejsca tarcia, czyli punkty, w których użytkownik gubi kontekst, nie widzi dalszej drogi, trafia na martwy koniec albo powtarza tę samą akcję kilka razy. To bolesne, ale potrzebne. Problem w tym, że często nie zawodzi sama oferta, lecz układ strony, zbyt słabe CTA, niejasna treść, wolne ładowanie albo element interfejsu, który działa „czasami”. Właśnie dlatego analiza ścieżek zwykle łączy dane ilościowe z jakościowymi, na przykład z nagraniami sesji, heatmapami czy logami błędów.
W nowoczesnej analityce ścieżki opierają się głównie na zdarzeniach, a nie tylko na odsłonach stron. I to nie jest frazes. Jakość nazewnictwa eventów, parametrów, zmian widoku w SPA i cross-domain trackingu bezpośrednio przekłada się na jakość wniosków, bo jeden źle opisany event potrafi „przestawić” całą narrację. Jeśli pomiar jest błędny, analiza ścieżek może pokazywać pozorne porzucenia, których w rzeczywistości nie było.
Największy sens ma analiza prowadzona osobno dla segmentów użytkowników. Inaczej zachowuje się osoba nowa, inaczej powracająca; inaczej ruch płatny, inaczej organiczny; inaczej mobile, inaczej desktop. Zamiast wrzucać wszystko do jednego worka, lepiej zobaczyć, kto i gdzie konkretnie się wykłada. Mieszanie wszystkich użytkowników w jednym raporcie zwykle zaciera prawdziwy obraz problemu.
Jakie są kluczowe etapy analizy ścieżek użytkowników?
Analiza ścieżek użytkowników ma swoje twarde etapy. I nie chodzi o jednorazowe spojrzenie w raport, lecz o proces: ustalenie celu, audyt pomiaru, odtworzenie tras, segmentację zachowań, diagnozę przyczyn oraz przygotowanie zmian do wdrożenia. Pytanie brzmi prosto: co dokładnie chcemy poprawić. Każdy krok ma wagę, bo potknięcie na starcie zwykle ciągnie w dół jakość końcowych rekomendacji.
- Ustalenie celu analizy — na początek trzeba nazwać proces, który bierzemy pod lupę: zakup, lead, rejestracja, kontakt, pobranie materiału albo inna konwersja. Bez tej decyzji łatwo utonąć w danych, które są głośne, ale niczego nie tłumaczą.
- Audyt danych i wdrożenia analityki — weryfikuje się tagi, eventy, parametry, cele, identyfikację kampanii, cross-domain tracking, błędy formularzy i spójność danych między narzędziami. To właśnie tu najczęściej wypływają na wierzch kłopoty typowe dla SPA, blokad przeglądarek, zgód marketingowych oraz braków w danych.
- Inwentaryzacja punktów styku — rozpisuje się strony wejścia, kluczowe ekrany, menu, CTA, formularze, wyszukiwarkę, filtry, koszyk, logowanie i każdy krok procesu. Krótko mówiąc: całą mapę terenu. Dzięki temu widać, które miejsca faktycznie pchają użytkownika dalej, a które są tylko scenografią.
- Odtworzenie ścieżek i lejków — buduje się raporty przejść, sekwencje zdarzeń i lejki, żeby zobaczyć najczęstsze wejścia, cofnięcia, pętle nawigacyjne, odgałęzienia oraz punkty wyjścia. Tu wszystko staje się czytelne: czy użytkownik idzie prosto do celu, czy zamiast tego krąży, błądzi i wraca.
- Segmentacja zachowań — porównuje się ścieżki według urządzenia, źródła ruchu, typu użytkownika, strony lądowania, lokalizacji, wersji językowej lub etapu decyzji. Dane mówią jasno: bardzo często problem dotyka tylko fragmentu ruchu, nie całego serwisu. I to zmienia sposób myślenia o naprawie.
- Analiza jakościowa — do liczb dokłada się nagrania sesji, mapy cieplne, kliknięcia martwych elementów, rage clicki, problemy ze scrollowaniem i logi błędów. Sama ścieżka pokaże, gdzie użytkownik odpada. Ale uwaga: dopiero materiał jakościowy odpowiada, dlaczego to się dzieje.
- Diagnoza przyczyn i priorytetyzacja — trzeba rozdzielić, czy źródłem problemu jest treść, architektura informacji, nawigacja, bariery techniczne, wydajność, niejasne CTA czy po prostu błędny pomiar. Potem rekomendacje układa się nie według tego, co brzmi efektownie, lecz według wpływu na konwersję, trudności wdrożenia i ryzyka biznesowego.
- Wdrożenie i walidacja zmian — po poprawkach sprawdza się, czy ścieżki są krótsze, mniej chaotyczne i mniej podatne na porzucenie. Równolegle trzeba potwierdzić, że nowy lub poprawiony pomiar faktycznie rejestruje efekt, a nie tylko daje poczucie, że „coś się mierzy”.
W praktyce dobra analiza kończy się paczką konkretnych materiałów roboczych. Bez tego zostaje tylko narracja. Zwykle wchodzą w to mapa ścieżek, lista punktów tarcia, raport segmentów, specyfikacja brakujących eventów oraz backlog zmian UX i CRO, gotowy do wzięcia na sprinty. Jeśli efektem są tylko ogólne obserwacje bez priorytetów i wymagań wdrożeniowych, analiza jest za mało użyteczna.
Zakres pracy rośnie razem ze złożonością serwisu. I to czuć od razu. Prosty landing z jednym formularzem analizuje się inaczej niż sklep z filtrami, logowaniem, checkoutem i przejściami między domenami, gdzie każdy dodatkowy krok dokłada ryzyko porzucenia. Im bardziej rozbudowany proces, tym kluczowe jest połączenie danych analitycznych z CRM, systemem sprzedażowym, płatnościami lub danymi z formularzy, bo dopiero wtedy widać pełny obraz.
Jakie dane są niezbędne do przeprowadzenia analizy?
Do analizy potrzebujesz przede wszystkim poprawnie zebranych danych o wejściu użytkownika, kolejnych interakcjach, punktach przejścia i wyniku końcowym procesu. Same odsłony to za mało. Nie pokazują, co wydarzyło się między wejściem a konwersją albo porzuceniem, czyli tam, gdzie zwykle giną pieniądze. W praktyce podstawą są modele oparte na zdarzeniach, więc liczy się nie tylko to, czy event w ogóle istnieje, ale też jak został nazwany i jakie niesie parametry. Jeśli nazewnictwo zdarzeń jest niespójne, analiza ścieżek szybko staje się myląca.
Najczęściej potrzebny jest zestaw danych, który pozwala odtworzyć pełną trasę użytkownika, krok po kroku:
- źródło wejścia, kampania, medium i strona lądowania,
- odsłony lub zmiany widoku oraz przejścia między kluczowymi ekranami,
- mikrointerakcje, takie jak kliknięcia CTA, użycie wyszukiwarki, filtrów, scroll, logowanie, dodanie do koszyka czy otwarcie formularza,
- błędy i przerwania procesu, na przykład błędy formularza, rage clicki, martwe kliknięcia lub cofanie się do poprzednich kroków,
- konwersje główne i pośrednie, wraz z ich wartością biznesową,
- dane segmentacyjne, takie jak urządzenie, typ użytkownika, wersja językowa, lokalizacja czy status zalogowania.
Do pełnej diagnozy często trzeba spiąć analitykę strony z danymi spoza samego serwisu. Bez tego zostaje półprawda. Dotyczy to zwłaszcza formularzy, CRM, systemu sprzedażowego, płatności albo call trackingu, bo tam finalnie rozstrzyga się wartość leada czy transakcji. Dopiero połączenie zachowania na stronie z realnym wynikiem biznesowym pokazuje, które ścieżki są naprawdę wartościowe.
Duże znaczenie ma też techniczna jakość pomiaru. W serwisach SPA trzeba poprawnie rejestrować zmiany widoku, bo inaczej długość ścieżki i moment porzucenia będą zwyczajnie przekłamane. Tam, gdzie użytkownik przechodzi między domeną główną, koszykiem, subdomeną lub zewnętrznym systemem, konieczny jest sprawny cross-domain tracking, a nie prowizorka. Przerwane śledzenie między domenami bardzo często wygląda w raportach jak porzucenie, choć użytkownik faktycznie kontynuuje proces.
Są też twarde ograniczenia danych. Zgody analityczne, adblocki i blokady przeglądarek sprawiają, że nie każda sesja w ogóle trafi do raportów. To nie przekreśla analizy, ale wymusza chłodną głowę: więcej sensu ma porównywanie trendów niż traktowanie liczb jak pełnego obrazu całego ruchu.
W praktyce lepiej zacząć od jednego procesu krytycznego, a nie od mapowania całego serwisu naraz. Dla jednej firmy będzie to ścieżka landing page – formularz, dla innej listing – karta produktu – koszyk – checkout. Lepiej analizować wąski proces z dobrym pomiarem niż cały serwis na danych, którym nie można ufać. To podejście nie jest efektowne, ale jest uczciwe wobec danych.
Jakie są najczęstsze błędy w analizie ścieżek użytkowników?
Najczęstsze błędy w analizie ścieżek użytkowników są zaskakująco powtarzalne. Chodzi o wnioski wyciągane z wadliwego pomiaru, mieszanie segmentów w jednym raporcie i mylenie objawu z prawdziwą przyczyną problemu. Efekt bywa brutalny: ten sam raport potrafi prowadzić do złych decyzji UX, jeśli wcześniej nikt nie sprawdził jakości danych. Problem w tym, że kłopoty rzadko zaczynają się na etapie interpretacji. Zaczynają się wcześniej, przy implementacji śledzenia.
Pierwszy błąd jest prozaiczny. To analiza raportów bez audytu pomiaru. Jeśli event formularza odpala się za wcześnie, page_view w SPA nie działa poprawnie albo cross-domain ucina sesję, raport „zobaczy” fałszywe porzucenia i sztucznie skrócone ścieżki. Najpierw trzeba potwierdzić, że dane opisują rzeczywiste zachowanie, a dopiero potem szukać problemów w UX. Inaczej grzebiemy w interfejsie, a winny siedzi w tagach.
Drugi częsty błąd to wrzucanie wszystkich użytkowników do jednego worka. Ścieżki nowych i powracających osób, ruchu płatnego i organicznego, mobile i desktopu albo użytkowników zalogowanych i anonimowych zwykle mocno się rozjeżdżają. I co z tego, że „średnia” wygląda stabilnie, skoro jeden segment właśnie się wykłada. Jeśli analizuje się wszystko łącznie, łatwo przeoczyć problem występujący tylko w jednej grupie albo odwrotnie, uznać za problem coś, co wynika po prostu z innej intencji wejścia.
Kolejny błąd ma cichy charakter. To patrzenie wyłącznie na dane ilościowe. Ścieżka pokaże, że użytkownicy odpadają na konkretnym kroku, ale sama nie odpowie, czy przyczyną jest niejasna treść, słaba hierarchia informacji, błąd techniczny czy brak zaufania. Pytanie brzmi: co dokładnie ich zatrzymało. Dlatego przy bardziej złożonych sprawach warto dołączyć nagrania sesji, heatmapy, logi błędów albo testy użyteczności.
Często spotykanym błędem jest też rozdmuchany zakres analizy. Kiedy ktoś próbuje na raz opisać cały serwis, kończy z długą listą obserwacji bez priorytetów i bez decyzji wdrożeniowych. Zamiast A — czyli atlasu wszystkiego — lepiej wybrać B: jeden proces krytyczny, rozebrać go na czynniki pierwsze i dopiero potem rozszerzać analizę na kolejne obszary.
Osobny problem to ignorowanie kontekstu technicznego strony. Wolne ładowanie, niestabilny interfejs, błędy JavaScript, źle działające filtry lub formularze potrafią całkowicie przestawić przebieg ścieżki, nawet jeśli treść jest sensowna. Jeśli użytkownik nie przechodzi dalej, przyczyną nie zawsze jest zła treść lub zły CTA; czasem po prostu interfejs działa zawodnie. I wtedy „poprawianie komunikatu” jest pudrowaniem problemu, nie jego rozwiązaniem.
Na finiszu często wchodzi klasyczny błąd wdrożeniowy. Zespół robi raport, po czym nie przekłada go na realne zmiany i dalszy pomiar. Dobra analiza nie kończy się wnioskiem „jest problem”, tylko listą priorytetów, wymaganiami do wdrożenia i planem sprawdzenia efektu po zmianach. Bez walidacji po wdrożeniu nie wiadomo, czy ścieżka faktycznie się poprawiła, czy zmienił się wyłącznie sposób jej raportowania.
Jakie narzędzia wspierają analizę ścieżek użytkowników?
Analizę ścieżek napędzają narzędzia do analityki zdarzeń, zarządzania tagami, obserwacji zachowań, monitoringu błędów oraz łączenia danych z wynikiem biznesowym. Kluczowe są systemy oparte na eventach, bo pokazują nie tylko wejście i wyjście, lecz także kolejne kroki, cofnięcia, porzucenia i mikrointerakcje. W praktyce sprowadza się to do raportów eksploracji ścieżek, lejków, sekwencji zdarzeń oraz analiz segmentów. Jeśli eventy są źle nazwane albo brakuje ich w kluczowych momentach procesu, nawet najlepsze narzędzie pokaże obraz atrakcyjny, ale mylący.
Druga warstwa to narzędzia wdrożeniowe i kontrolne. W grze są przede wszystkim menedżer tagów, debugery i podgląd zdarzeń. To one pozwalają sprawdzić, czy poprawnie rejestrują się kliknięcia CTA, błędy formularzy, przejścia między krokami, logowanie czy dodanie produktu do koszyka. W serwisach typu SPA robi się to krytyczne, bo brak poprawnie mierzonych zmian widoku potrafi skrzywić całą ścieżkę, od pierwszego wejścia po finalny krok. W wielu projektach większym problemem nie jest brak danych, lecz brak zaufania do tego, co te dane naprawdę oznaczają.
Same dane ilościowe rzadko domykają temat. Dlatego analiza ścieżek zwykle dostaje „drugie oko” w postaci nagrań sesji, heatmap, scroll map i monitoringu błędów JavaScript. Wtedy widać czarno na białym, czy użytkownik trafia w martwy element, próbuje kilka razy kliknąć ten sam przycisk, gubi się w formularzu albo porzuca proces po technicznym potknięciu. Takie narzędzia nie zastępują analityki, ale świetnie tłumaczą, dlaczego ścieżka wygląda właśnie tak, a nie inaczej.
W bardziej złożonych serwisach dochodzą jeszcze źródła spoza samej strony, na przykład CRM, system sprzedażowy, dane z call center, formularzy lub płatności. Dopiero wtedy da się spiąć trasę użytkownika z realnym efektem, czy to leadem, sprzedażą, odrzuconym wnioskiem, czy niedokończoną płatnością. To szczególnie istotne, gdy część procesu przenosi się na inną domenę, subdomenę albo do zewnętrznego systemu. Bez poprawnego cross-domain trackingu ścieżka może wyglądać na przerwaną, mimo że użytkownik faktycznie kontynuował proces.
Przy bardziej zaawansowanej analizie wchodzą do gry także hurtownie danych i narzędzia BI. Dają one coś, czego brakuje w gotowcach: możliwość zbudowania własnych definicji etapów, segmentów i kohort. To robi różnicę tam, gdzie standardowe raporty gubią pełny kontekst, choćby przy wielu wersjach językowych, logowaniu, filtrach produktów albo rozbudowanym checkoutcie. I tu jest sedno: nie wygrywa zestaw z największą liczbą narzędzi, lecz taki, który utrzymuje spójny pomiar od wejścia aż do wyniku końcowego.
Jakie zmiany w UX mogą wynikać z analizy ścieżek użytkowników?
Z analizy ścieżek użytkowników najczęściej wypływają korekty w nawigacji, kolejności kroków, treściach, formularzach i widoczności następnej akcji. Kiedy ludzie regularnie zatrzymują się w jednym miejscu, cofają do poprzedniego ekranu albo krążą między tymi samymi podstronami, zwykle nie chodzi o „ciekawość”, tylko o brak jasnego kierunku. Co wtedy robić. Porządkuje się architekturę informacji, dopina linkowanie wewnętrzne i poprawia układ tak, by kolejny krok był czytelny bez zgadywania. Dobra zmiana UX skraca drogę do celu albo zmniejsza ryzyko, że użytkownik zgubi kontekst po drodze.
Często do poprawy jest samo prowadzenie użytkownika przez proces. W praktyce to mniej tarcia w lejku: wycięcie zbędnych kroków, przestawienie kolejności pól, lepsze wyjaśnienie korzyści przy CTA albo dopisanie informacji, które zdejmują niepewność. Jeżeli analiza pokazuje, że użytkownicy przechodzą na stronę kontaktu, a potem wracają do oferty, to sygnał jest prosty: wcześniej nie dostali odpowiedzi na kluczowe pytania. Zamiast więc „dokręcać” perswazję, dopracowuje się treść, sekcje FAQ, elementy zaufania albo porównania wariantów.
Duża część rekomendacji uderza w formularze, bo to tam najłatwiej o realne tarcie. Jeśli użytkownicy zaczynają wpisywanie danych, a potem porzucają proces, winowajcą bywa zbyt długa forma, niejasne etykiety, agresywna walidacja albo brak sensownej podpowiedzi przy błędzie. Wtedy wchodzą zmiany bardziej przyziemne, ale skuteczne: skrócenie formularza, podział na logiczne etapy, czytelniejsze komunikaty i lepsze działanie na urządzeniach mobilnych. Jeżeli ścieżka urywa się po interakcji z formularzem, trzeba sprawdzić zarówno UX, jak i samą techniczną poprawność formularza.
Analiza ścieżek często kończy się też ingerencją w wyszukiwarkę, filtry oraz karty produktów lub usług. Gdy użytkownicy masowo wracają z listingu do wyników wyszukiwania albo w kółko zmieniają filtry, dane mówią jasno: problem leży w dopasowaniu, opisie albo sposobie prezentacji oferty. W odpowiedzi porządkuje się nazwy kategorii, układa kolejność filtrów, poprawia widoczność cen, dopina parametry porównawcze i dodaje elementy, które pomagają podjąć decyzję bez zbędnego błądzenia. Pytanie brzmi: czy oferta jest nieczytelna, czy tylko źle pokazana.
Nie wszystkie zmiany rozgrywają się w treści i układzie. Część kłopotów bierze się z czystej wydajności: przesunięć interfejsu, opóźnionego ładowania modułów albo błędów na urządzeniach mobilnych. Gdy ścieżki pokazują nagłe wyjścia zaraz po wejściu na kluczowy ekran, sprawa jest prosta. Trzeba równolegle sprawdzić Core Web Vitals, stabilność widoku i błędy front-endowe, bo to one potrafią „wypychać” ludzi z procesu. Użytkownik często porzuca proces nie dlatego, że nie chce iść dalej, lecz dlatego, że strona utrudnia mu wykonanie prostego kroku.
Kluczowe jest, by rekomendacje UX nie były ogólnikami, tylko trafiały w konkretne miejsce i konkretny segment. Inaczej zachowują się nowi użytkownicy z kampanii płatnych, inaczej osoby powracające, a jeszcze inaczej ci, którzy są zalogowani i mają już swoje nawyki. I to nie jest akademicka różnica. Dobre wnioski z analizy mają więc formę decyzji operacyjnych: co przebudować, dla kogo, na którym etapie oraz jak sprawdzić efekt po wdrożeniu, zamiast liczyć na „poprawę odczuwalną” bez pomiaru.
Jakie są korzyści z segmentacji ścieżek użytkowników?
Segmentacja ścieżek użytkowników pozwala zobaczyć, które grupy poruszają się po serwisie inaczej i skąd biorą się różnice w wynikach. Jeden zbiorczy raport bywa wygodny, ale to wygoda pozorna. Problem w tym, że uśrednia zachowania ludzi z inną intencją, na innym urządzeniu i z innym poziomem znajomości marki, a potem udaje, że opisuje „typowego użytkownika”, który często nie istnieje. To właśnie segmentacja pokazuje, czy problem dotyczy całego procesu, czy tylko konkretnej grupy użytkowników. Dzięki temu decyzje są trafniejsze i rzadziej kończą się zmianami, które pomagają jednym, a innym podcinają skrzydła.
Największa korzyść to ostrzejsza diagnoza punktów tarcia. Użytkownicy mobile mogą odpadać na formularzu przez niewygodny układ, podczas gdy na desktopie ten sam etap przechodzi gładko. Ruch płatny potrafi porzucać stronę szybciej już po wejściu, bo obietnica reklamy nie zgadza się z landing page’em, a ruch organiczny wykłada się dopiero w dalszej części procesu, gdy rośnie „koszt” kolejnych kroków. To nie są drobne niuanse, tylko różne historie o tym samym produkcie. Bez podziału na segmenty łatwo wyciągnąć błędny wniosek, że „strona działa słabo”, choć w praktyce słabo działa tylko jeden wariant ścieżki.
Segmentacja pomaga też rozsądniej ustalać priorytety wdrożeń. Jeśli nowi użytkownicy nie rozumieją kolejnego kroku, zwykle nie potrzeba rewolucji w funkcjach, tylko korekty komunikacji, struktury informacji albo CTA, które prowadzi jak po sznurku. Jeśli problem dotyczy głównie osób powracających lub zalogowanych, trop jest gdzie indziej: logika konta, koszyka, zapisanych danych albo synchronizacja między widokami, która potrafi rozsypać nawet dobrą ścieżkę. Spójrzmy na to inaczej: nie chodzi o „więcej zmian”, tylko o celne zmiany. Dobrze wykonana segmentacja skraca drogę od obserwacji do konkretnej decyzji: co poprawić, gdzie i dla kogo.
To się po prostu opłaca. Segmenty pozwalają spiąć zachowanie na stronie z jakością ruchu i wynikiem na końcu lejka, a nie tylko z ładnym wykresem w raporcie. Inaczej wygląda ścieżka użytkownika z kampanii brandowej, a inaczej osoby z kampanii performance, porównywarki cenowej czy artykułu blogowego. I wtedy pytanie brzmi: gdzie naprawdę pęka proces. To ułatwia ocenę, czy problem leży po stronie reklamy, strony lądowania, nawigacji, formularza czy dalszego etapu, na przykład checkoutu lub przekazania do zewnętrznego systemu. W efekcie budżet i prace UX kieruje się tam, gdzie strata jest realna, a nie tylko najlepiej widoczna w ogólnym raporcie.
Segmentuj jednak z głową. Zbyt szerokie grupy zacierają różnice, a zbyt wąskie karmią Cię niestabilnymi wnioskami, zwłaszcza przy ograniczeniach pomiaru, zgodach analitycznych i brakach w cross-domain trackingu. Spójrzmy na to inaczej: nie wszystko naraz, tylko to, co najczęściej przestawia bieg ścieżki. W praktyce najlepiej zacząć od segmentów, które najczęściej zmieniają przebieg ścieżki: nowe kontra powracające osoby, mobile kontra desktop, ruch płatny kontra organiczny oraz użytkownicy anonimowi kontra zalogowani. Taki podział zwykle najszybciej pokazuje, gdzie naprawdę trzeba poprawić doświadczenie i pomiar.
