Blog

Na łamach grzegorz-zawada.pl regularnie analizuję cyfrowe ślady pozostawiane przez systemy transakcyjne, ale rzadko trafiam na zbiór o tak potężnej skali i entropii. Dzisiaj na warsztat bierziemy „E-commerce App Transactional Dataset” z platformy Kaggle. To potężna baza danych obejmująca **895 203 unikalne sprawy (case IDs)** oraz **12 833 602 rekordy zdarzeń (event logs)**.

Rejestrowane w systemie czynności tworzą pełny obraz cyfrowej podróży użytkownika aplikacji: od punktu wejścia (`HOMEPAGE`), przez eksplorację asortymentu (`CLICK`, `ITEM_DETAIL`, `SCROLL`, `SEARCH`), interakcje z koszykiem i promocjami (`ADD_TO_CART`, `PROMO_PAGE`, `ADD_PROMO`), aż po finalizację transakcji (`BOOKING`). Zrozumienie tego procesu wymaga wejścia głęboko w inżynierię procesów, algorytmy eksploracji procesów (Process Discovery) oraz zaawansowaną analizę wariantowości.

Analiza Wariantowości i Standaryzacji (Variants Mining)

Tradycyjne raporty BI zagregowałyby te dane do prostych wskaźników konwersji, ukrywając fundamentalny problem operacyjny. Zastosowanie algorytmów wariantowości (Variants Mining) obnażyło jednak bezwzględną prawdę o strukturze tego procesu. W przeanalizowanym logu zdarzeń wykryto aż **557 232 unikalne warianty procesu**.

Oznacza to katastrofalny poziom niestandardowości. Spójrzmy na parametry standaryzacji:
* **Happy Path (Wariant #1)**: ` HOMEPAGE ➔ ADD_TO_CART ➔ CLICK ➔ BOOKING` generuje zaledwie 11 090 spraw, co stanowi skromne **1.2% całego wolumenu**.
* **Wariant #2** (`HOMEPAGE ➔ CLICK ➔ ADD_TO_CART ➔ BOOKING`): również 1.2% (10 927 spraw).
* **Wariant #3** (`HOMEPAGE ➔ ADD_TO_CART ➔ ADD_TO_CART ➔ BOOKING`): 1.1% (10 210 spraw).
* **Top 3 warianty** łącznie stanowią zaledwie **3.6%** wszystkich ścieżek realizacji procesu.

Tak gigantyczna liczba wariantów przy blisko 900 tysiącach spraw dowodzi, że użytkownicy poruszają się w aplikacji po omacku. Brak sztywnej, intuicyjnej architektury nawigacyjnej sprawia, że proces zakupu przyjmuje postać błądzenia losowego (random walk), zamiast sterowanego lejka konwersji.

Detekcja Reworku i Marnotrawstwa Operacyjnego

Jednym z najbardziej zatrważających wskaźników wyciągniętych z tego zbioru danych jest **wskaźnik reworku (pętle) na poziomie 85.2%**. Oznacza to, że ponad 8 na 10 procesów zakupowych wymagało wielokrotnego powtarzania tych samych kroków (co widać chociażby w trzecim najpopularniejszym wariancie zawierającym zduplikowany krok `ADD_TO_CART`).

Z punktu widzenia inżynierii procesów, rework jest synonimem marnotrawstwa (muda). W analizowanej aplikacji użytkownicy masowo wracają do wcześniejszych stanów procesu ze względu na:
1. **Błędy w architekturze informacji**: Klienci dodają towary do koszyka, po czym wracają do strony głównej lub wyszukiwarki (`SEARCH`), ponieważ interfejs nie pozwala na efektywne zarządzanie koszykiem z poziomu widoku szczegółowego (`ITEM_DETAIL`).
2. **Nieintuicyjny system promocji**: Obecność kroków takich jak `PROMO_PAGE` i `ADD_PROMO` w zapętlonych sekwencjach sugeruje, że mechanizmy rabatowe są niejasne, co zmusza użytkowników do opuszczania koszyka, szukania kodów, powracania i ponownego przeliczania wartości zamówienia.

Diagnostyka Wąskich Gardeł i Rozkładu Czasowego (DFG & Long-Tail)

Statystyki czasowe tego procesu rysują obraz skrajnej asymetrii. Podczas gdy **średni czas trwania procesu wynosi 11.0 dni**, a **mediana to zaledwie 3.73 dnia**, **percentyl P90 strzela aż do 25.13 dni**. Ta gigantyczna rozpiętość wskazuje na obecność klasycznego zjawiska *long-tail* w opóźnieniach operacyjnych.

Analiza bezpośrednio skierowanego grafu (Directly-Follows Graph – DFG) pozwala precyzyjnie wskazać przejścia generujące największe tarcia czasowe:
* Przejście **`ADD_PROMO` ➔ `BOOKING`**: średnio aż **138.3 godziny** (wolumen: 40 813 zdarzeń). To krytyczny punkt zapalny – procesy promocyjne blokują finalizację transakcji na ponad 5 dni.
* Przejście **`ADD_TO_CART` ➔ `BOOKING`**: średnio **134.8 godziny** (wolumen: 155 885 zdarzeń). Klienci dodają produkty do koszyka i zamrażają proces na blisko 6 dni przed podjęciem decyzji o finalizacji.
* Przejście **`BOOKING` ➔ `HOMEPAGE`**: średnio **109.6 godziny** (wolumen: 41 240 zdarzeń). Zjawisko to wskazuje na powracanie użytkowników do strony głównej już po dokonaniu rezerwacji/zakupu, co może sugerować konieczność dokupienia kolejnych elementów lub poprawiania błędów transakcyjnych.
* Pozostałe znaczące opóźnienia generują przejścia powrotne z `BOOKING` do `PROMO_PAGE` (94.4h), `ITEM_DETAIL` (85.6h) oraz `SEARCH` (81.6h).

Rekomendacje Optymalizacyjne i Process Redesign

Biorąc pod uwagę strukturę wariantowości (557k wariantów) oraz potężny wskaźnik reworku (85.2%), standardowe łatanie błędów interfejsu nie wystarczy. Wymagany jest fundamentalny redesign procesu oparty na inżynierii procesowej:

1. **Automatyzacja bramkowa i re-routing koszyka (`ADD_TO_CART` ➔ `BOOKING`)**: Należy wyeliminować 134-godzinne opóźnienia poprzez wdrożenie mechanizmów automatycznego przypominania (retargeting behawioralny) oraz uproszczenie ścieżki checkoutu do pojedynczego ekranu (One-Step Checkout), co ukróci potrzebę wracania do katalogu.
2. **Przebudowa architektury systemów rabatowych (`ADD_PROMO`)**: Ponieważ przejście z promocji do rezerwacji generuje największe opóźnienie czasowe (138.3h), rekomenduję automatyczne aplikowanie najlepszych dostępnych kodów promocyjnych w koszyku. Usunięcie konieczności ręcznego wklepywania promocji drastycznie obniży liczbę pętli i skróci czas P90.
3. **Wdrożenie ograniczeń swobody nawigacyjnej (Process Guardrails)**: Aby zredukować liczbę 557 tysięcy unikalnych wariantów, aplikacja powinna wymusić bardziej uporządkowaną strukturę nawigacji. Wprowadzenie kontrolowanych kroków przejściowych ograniczy błądzenie użytkowników i sprowadzi rozproszone ścieżki do zdefiniowanego, optymalnego lejka konwersji.

#ProcessMining #PM4Py #ProcessIntelligence #OperationalAnalytics #EventLog