W Internecie można znaleźć setki artykułów na temat korzyści płynących z analizy zachowań klientów. Najczęściej dotyczy to sektora handlu detalicznego. Od analizy koszyka żywności, analizy ABC i XYZ po marketing retencji i oferty osobiste. Od dziesięcioleci stosowano różne techniki, algorytmy zostały przemyślane, kod został napisany i zdebugowany - bierz i używaj. W naszym przypadku pojawił się jeden zasadniczy problem – my w ISPsystem zajmujemy się tworzeniem oprogramowania, a nie sprzedażą detaliczną.
Nazywam się Denis i obecnie jestem odpowiedzialny za backend systemów analitycznych w ISPsystem. A oto historia, jak ja i mój kolega — osoby odpowiedzialne za wizualizację danych — próbowały spojrzeć na nasze produkty programowe przez pryzmat tej wiedzy. Zacznijmy jak zwykle od historii.
Na początku było słowo, a ono brzmiało: „Czy spróbujemy?”
W tym momencie pracowałem jako programista w dziale R&D. Wszystko zaczęło się, gdy Danil przeczytał tutaj na Habré — narzędzie do analizy przejść użytkowników w aplikacjach. Byłem nieco sceptyczny co do pomysłu wykorzystania go tutaj. Jako przykłady twórcy bibliotek podali analizę aplikacji, w których jasno zdefiniowano cel działania – złożenie zamówienia lub inną odmianę sposobu zapłaty właścicielowi firmy. Nasze produkty dostarczamy na miejscu. Oznacza to, że użytkownik najpierw kupuje licencję, a dopiero potem rozpoczyna swoją podróż w aplikacji. Tak, mamy wersje demonstracyjne. Można tam wypróbować produkt, żeby nie mieć kota w worku.
Jednak większość naszych produktów jest skierowana na rynek hostingowy. Są to duzi klienci i dział rozwoju biznesu doradza im w zakresie możliwości produktu. Wynika z tego również, że w momencie zakupu nasi klienci wiedzą już, jakie problemy pomoże im rozwiązać nasze oprogramowanie. Ich trasy w aplikacji muszą pokrywać się z CJM osadzonym w produkcie, a rozwiązania UX pomogą im utrzymać się na właściwej drodze. Spoiler: nie zawsze tak się dzieje. Wprowadzenie do biblioteki zostało przełożone... ale nie na długo.
Wszystko zmieniło się wraz z wydaniem naszego startupu - — platformy do tworzenia sklepu internetowego z konta na Instagramie. W aplikacji tej użytkownik otrzymał dwutygodniowy okres na bezpłatne korzystanie ze wszystkich funkcjonalności. Następnie trzeba było zdecydować, czy subskrybować. A to doskonale wpisuje się w koncepcję „akcji na trasie”. Zdecydowano: spróbujmy!
Pierwsze rezultaty, czyli skąd brać pomysły
Zespół programistów i ja podłączyliśmy produkt do systemu zbierania zdarzeń dosłownie w ciągu jednego dnia. Od razu powiem, że ISPsystem korzysta z własnego systemu zbierania zdarzeń o odwiedzinach strony, jednak nic nie stoi na przeszkodzie, aby w tych samych celach wykorzystać Yandex.Metrica, który pozwala na pobieranie surowych danych za darmo. Przeanalizowano przykłady wykorzystania biblioteki i po tygodniu zbierania danych otrzymaliśmy wykres przejścia.
Wykres przejścia. Podstawowa funkcjonalność, inne przejścia usunięte dla przejrzystości
Wyszło tak jak w przykładzie: planarne, przejrzyste, piękne. Na podstawie tego wykresu udało nam się zidentyfikować najczęstsze trasy i skrzyżowania, na których ludzie spędzają najwięcej czasu. Pozwoliło nam to zrozumieć, co następuje:
- Zamiast dużego CJM, który obejmuje kilkanaście podmiotów, aktywnie wykorzystywane są tylko dwa. Konieczne jest dodatkowe kierowanie użytkowników do miejsc, których potrzebujemy, za pomocą rozwiązań UX.
- Niektóre strony, zaprojektowane przez projektantów UX tak, aby były kompleksowe, powodują, że ludzie spędzają na nich nieuzasadnioną ilość czasu. Musisz dowiedzieć się, jakie elementy zatrzymujące znajdują się na konkretnej stronie i dostosować je.
- Po 10 przejściach 20% osób zaczęło się męczyć i rezygnuje z sesji w aplikacji. A to biorąc pod uwagę fakt, że w aplikacji mieliśmy aż 5 stron onboardingowych! Musisz zidentyfikować strony, na których użytkownicy regularnie porzucają sesje i skrócić do nich ścieżkę. Jeszcze lepiej: zidentyfikuj regularne trasy i umożliwij szybkie przejście ze strony źródłowej do strony docelowej. Coś wspólnego z analizą ABC i analizą porzuconych koszyków, nie sądzisz?
I tutaj ponownie przemyśleliśmy nasze podejście do możliwości zastosowania tego narzędzia w przypadku produktów on-premise. Postanowiono przeanalizować aktywnie sprzedawany i używany produkt - . Jest to znacznie bardziej złożone, jest o rząd wielkości więcej bytów. Z niecierpliwością czekaliśmy, aby zobaczyć, jaki będzie wykres przejścia.
O rozczarowaniach i inspiracjach
Rozczarowanie nr 1
Był to koniec dnia roboczego, koniec miesiąca i zarazem koniec roku – 27 grudnia. Dane zostały zgromadzone, zapytania zostały napisane. Do przetworzenia wszystkiego pozostały sekundy i mogliśmy przyjrzeć się wynikom naszej pracy, aby dowiedzieć się, gdzie rozpocznie się kolejny rok pracy. Dział R&D, menedżer produktu, projektanci UX, lider zespołu, programiści zebrali się przed monitorem, aby zobaczyć, jak wyglądają ścieżki użytkownika w ich produkcie, ale… zobaczyliśmy to:
Wykres przejścia zbudowany przez bibliotekę Retentioneering
Inspiracja nr 1
Mocno powiązane, dziesiątki podmiotów, nieoczywiste scenariusze. Było tylko jasne, że nowy rok roboczy rozpocznie się nie od analizy, ale od wynalezienia sposobu na uproszczenie pracy z takim wykresem. Nie mogłem jednak oprzeć się wrażeniu, że wszystko jest znacznie prostsze, niż się wydawało. Po piętnastu minutach studiowania kodu źródłowego Retentioneering udało nam się wyeksportować skonstruowany wykres do formatu kropkowego. Umożliwiło to wgranie wykresu do innego narzędzia - Gephi. A już jest miejsce na analizę wykresów: układy, filtry, statystyki – wystarczy, że skonfigurujesz niezbędne parametry w interfejsie. Z tą myślą wyjechaliśmy na sylwestrowy weekend.
Rozczarowanie nr 2
Po powrocie do pracy okazało się, że gdy wszyscy odpoczywali, nasi klienci studiowali produkt. Tak, tak mocno, że w magazynie pojawiły się zdarzenia, które wcześniej nie istniały. Oznaczało to, że zapytania wymagały aktualizacji.
Trochę tła, żeby zrozumieć smutek tego faktu. Przekazujemy zarówno zaznaczone przez nas zdarzenia (np. kliknięcia w niektóre przyciski), jak i adresy URL stron, które odwiedził użytkownik. W przypadku Cartbee sprawdził się model „jedna akcja – jedna strona”. Ale w przypadku VMmanagera sytuacja była zupełnie inna: na jednej stronie mogło otworzyć się kilka okien modalnych. W nich użytkownik mógł rozwiązać różne problemy. Na przykład adres URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
oznacza, że na stronie „Adresy IP” użytkownik dodał adres IP. I tutaj widoczne są od razu dwa problemy:
- Adres URL zawiera pewien parametr ścieżki - identyfikator maszyny wirtualnej. Trzeba to wykluczyć.
- Adres URL zawiera identyfikator okna modalnego. Trzeba jakoś „rozpakować” takie adresy URL.
Kolejnym problemem było to, że same zaznaczone przez nas zdarzenia miały parametry. Przykładowo istniało pięć różnych sposobów dotarcia do strony z informacjami o maszynie wirtualnej z listy. W związku z tym wysłano jedno zdarzenie, ale z parametrem wskazującym, jaką metodą użytkownik dokonał przejścia. Takich zdarzeń było wiele i wszystkie parametry były inne. Całą logikę wyszukiwania danych mamy w dialekcie SQL dla Clickhouse. Zapytania zawierające 150–200 linii zaczęły wydawać się dość powszechne. Otaczały nas problemy.
Inspiracja nr 2
Pewnego wczesnego ranka Danil, ze smutkiem przewijając żądanie przez drugą minutę, zasugerował mi: „Napiszmy potoki przetwarzania danych?” Pomyśleliśmy o tym i zdecydowaliśmy, że jeśli już to zrobimy, będzie to coś w rodzaju ETL. Aby natychmiast filtrował i pobierał niezbędne dane z innych źródeł. Tak narodził się nasz pierwszy serwis analityczny z pełnoprawnym backendem. Realizuje pięć głównych etapów przetwarzania danych:
- Wyładowanie zdarzeń z magazynu danych surowych i przygotowanie ich do przetwarzania.
- Wyjaśnienie to „rozpakowanie” samych identyfikatorów okien modalnych, parametrów zdarzenia i innych szczegółów, które wyjaśniają zdarzenie.
- Wzbogacanie (od słowa „stać się bogatym”) to dodanie wydarzeń o dane z zewnętrznych źródeł. W tamtym czasie dotyczyło to tylko naszego systemu rozliczeniowego BILLmanager.
- Filtrowanie to proces odfiltrowywania zdarzeń, które zniekształcają wyniki analizy (zdarzenia ze stanowisk wewnętrznych, wartości odstające itp.).
- Przesyłanie odebranych zdarzeń do pamięci, co nazywamy czystymi danymi.
Teraz możliwe było utrzymanie aktualności poprzez dodanie reguł przetwarzania zdarzenia lub nawet grup podobnych wydarzeń. Na przykład od tego czasu nigdy nie aktualizowaliśmy rozpakowywania adresów URL. Chociaż w tym czasie dodano kilka nowych odmian adresów URL. Są zgodne z zasadami określonymi już w serwisie i są przetwarzane prawidłowo.
Rozczarowanie nr 3
Kiedy zaczęliśmy analizować, zdaliśmy sobie sprawę, dlaczego wykres jest tak spójny. Faktem jest, że prawie każdy N-gram zawierał przejścia, których nie można było przeprowadzić przez interfejs.
Rozpoczęło się małe śledztwo. Byłem zdezorientowany, że nie ma niemożliwych przejść w ramach jednego bytu. Oznacza to, że nie jest to błąd w systemie zbierania zdarzeń ani w naszej usłudze ETL. Miało się wrażenie, że użytkownik pracował jednocześnie w kilku podmiotach, nie przechodząc od jednego do drugiego. Jak to osiągnąć? Korzystanie z różnych zakładek w przeglądarce.
Analizując Cartbee, uratowała nas jego specyfika. Z aplikacji korzystano z urządzeń mobilnych, gdzie praca z kilku zakładek jest po prostu niewygodna. Tutaj mamy pulpit i podczas gdy zadanie jest wykonywane w jednym podmiocie, rozsądnie jest chcieć spędzić ten czas na konfigurowaniu lub monitorowaniu stanu w innym. Aby nie stracić postępu, po prostu otwórz kolejną kartę.
Inspiracja nr 3
Koledzy z front-end developmentu nauczyli system zbierania zdarzeń rozróżniania zakładek. Można rozpocząć analizę. I zaczęliśmy. Zgodnie z oczekiwaniami CJM nie pasował do rzeczywistych ścieżek: użytkownicy spędzali dużo czasu na stronach katalogów, porzucanych sesjach i zakładkach w najbardziej nieoczekiwanych miejscach. Korzystając z analizy przejść, udało nam się znaleźć problemy w niektórych kompilacjach Mozilli. W nich, ze względu na funkcje implementacyjne, zniknęły elementy nawigacyjne lub wyświetliły się w połowie puste strony, które powinny być dostępne tylko dla administratora. Strona została otwarta, ale z backendu nie pojawiła się żadna treść. Liczenie przejść pozwoliło ocenić, które funkcje zostały faktycznie wykorzystane. Łańcuchy pozwoliły zrozumieć, w jaki sposób użytkownik otrzymał ten lub inny błąd. Dane zostały poddane testom na podstawie zachowań użytkowników. Udało się, pomysł nie poszedł na marne.
Automatyzacja analityki
W jednej z demonstracji wyników pokazaliśmy, w jaki sposób Gephi jest wykorzystywany do analizy grafów. W tym narzędziu dane konwersji można wyświetlić w tabeli. A szef działu UX powiedział jedną bardzo ważną myśl, która wpłynęła na rozwój całego kierunku analityki behawioralnej w firmie: „Zróbmy to samo, ale w Tableau i z filtrami – będzie wygodniej”.
Wtedy pomyślałem: czemu nie, Retentioneering przechowuje wszystkie dane w strukturze pandas.DataFrame. A to jest w zasadzie stół. Tak pojawiła się kolejna usługa: Data Provider. Nie tylko sporządził tabelę z wykresu, ale także wyliczył, jak popularna jest dana strona i związane z nią funkcjonalności, jak wpływa to na retencję użytkowników, jak długo użytkownicy na niej pozostają oraz które strony opuszczają najczęściej. Natomiast zastosowanie wizualizacji w Tableau zredukowało koszt badania wykresu do tego stopnia, że czas iteracji analizy zachowania w produkcie skrócił się prawie o połowę.
Danil opowie o tym, jak wykorzystuje się tę wizualizację i jakie wnioski pozwala wyciągnąć.
Więcej stołów dla boga stołu!
W uproszczonej formie zadanie zostało sformułowane w następujący sposób: wyświetlić wykres przejścia w Tableau, zapewnić możliwość filtrowania oraz uczynić go jak najbardziej przejrzystym i wygodnym.
Tak naprawdę nie chciałem rysować skierowanego wykresu w Tableau. A nawet jeśli się powiedzie, zysk w porównaniu z Gephim nie wydawał się oczywisty. Potrzebowaliśmy czegoś znacznie prostszego i bardziej dostępnego. Tabela! Przecież graf można łatwo przedstawić w postaci wierszy tabeli, gdzie każdy wiersz jest krawędzią typu „źródło-cel”. Co więcej, taką tabelę przygotowaliśmy już starannie, korzystając z narzędzi Retentioneering i Data Provider. Pozostało tylko wyświetlić tabelę w Tableau i pogrzebać w raporcie.
A propos, jak wszyscy kochają stoły.
Jednak tutaj mamy do czynienia z innym problemem. Co zrobić ze źródłem danych? Nie można było podłączyć pand.DataFrame, Tableau nie ma takiego złącza. Utworzenie osobnej bazy do przechowywania wykresu wydawało się zbyt radykalnym rozwiązaniem z niejasnymi perspektywami. Lokalne opcje rozładunku nie były odpowiednie ze względu na potrzebę ciągłych operacji ręcznych. Przejrzeliśmy listę dostępnych złączy i nasz wzrok padł na przedmiot , który skulił się rozpaczliwie na samym dole.
Tableau posiada bogaty wybór złączy. Znaleźliśmy taki, który rozwiązał nasz problem
Jakie zwierzę? Kilka nowych otwartych kart w przeglądarce - i stało się jasne, że ten łącznik umożliwia odbieranie danych podczas uzyskiwania dostępu do adresu URL. Sam backend do obliczania danych był prawie gotowy, pozostało tylko zaprzyjaźnić się z WDC. Denis przez kilka dni studiował dokumentację i walczył z mechanizmami Tableau, po czym przesłał mi link, który wkleiłem w okno połączenia.
Formularz połączenia z naszym WDC. Denis zrobił front i zadbał o bezpieczeństwo
Po kilku minutach oczekiwania (dane są obliczane dynamicznie na żądanie) pojawiła się tabela:
Tak wygląda surowa tablica danych w interfejsie Tableau
Zgodnie z obietnicą, każdy wiersz takiej tabeli reprezentował krawędź wykresu, czyli ukierunkowane przejście użytkownika. Zawierał także kilka dodatkowych cech. Na przykład liczba unikalnych użytkowników, całkowita liczba przejść i inne.
Można by wyświetlić tę tabelę w raporcie w niezmienionej postaci, hojnie posypać filtrami i wysłać narzędzie w żeglugę. Brzmi logicznie. Co można zrobić ze stołem? Ale to nie jest nasza droga, bo robimy nie tylko stół, ale narzędzie do analizy i podejmowania decyzji produktowych.
Zwykle analizując dane, człowiek chce uzyskać odpowiedzi na pytania. Świetnie. Zacznijmy od nich.
- Jakie są najczęstsze przejścia?
- Dokąd przechodzą z konkretnych stron?
- Ile średnio czasu spędzasz na tej stronie przed opuszczeniem?
- Jak często dokonujesz przejścia z punktu A do B?
- Na jakich stronach kończy się sesja?
Każdy z raportów lub ich kombinacja powinna umożliwiać użytkownikowi samodzielne znalezienie odpowiedzi na te pytania. Kluczową strategią jest tutaj zapewnienie narzędzi, dzięki którym możesz to zrobić samodzielnie. Przydaje się to zarówno w celu odciążenia działu analitycznego, jak i skrócenia czasu podejmowania decyzji – w końcu nie musisz już iść do Youtrack i tworzyć zadania dla analityka, wystarczy, że otworzysz raport.
Co otrzymaliśmy?
Gdzie ludzie najczęściej odchodzą od dashboardu?
Fragment naszego raportu. Po dashboardzie każdy przechodził albo do listy maszyn wirtualnych, albo do listy węzłów
Weźmy ogólną tabelę z przejściami i przefiltrujmy według strony źródłowej. Najczęściej przechodzą z dashboardu do listy maszyn wirtualnych. Co więcej, kolumna Regularność sugeruje, że jest to czynność powtarzalna.
Skąd pochodzą na listę klastrów?
Filtry w raportach działają w obie strony: możesz dowiedzieć się, gdzie wyszedłeś lub dokąd poszedłeś
Z przykładów widać, że już obecność dwóch prostych filtrów i rankingowanie wierszy według wartości pozwala na szybkie uzyskanie informacji.
Zapytajmy o coś trudniejszego.
Gdzie użytkownicy najczęściej rezygnują z sesji?
Użytkownicy VMmanager często pracują w oddzielnych zakładkach
Do tego potrzebny jest nam raport, którego dane są agregowane według źródeł poleceń. Za przypisania przyjęto tzw. punkty przerwania – zdarzenia, które posłużyły jako zakończenie łańcucha przejść.
Należy tutaj pamiętać, że może to być koniec sesji lub otwarcie nowej karty. Przykład pokazuje, że łańcuch najczęściej kończy się na tabeli z listą maszyn wirtualnych. W tym przypadku charakterystycznym zachowaniem jest przejście na inną zakładkę, co jest zgodne z oczekiwanym wzorcem.
Przydatność tych raportów najpierw sprawdziliśmy na sobie, przeprowadzając analizę w podobny sposób , kolejny z naszych produktów. Wraz z pojawieniem się tabel i filtrów hipotezy były testowane szybciej, a oczy mniej się męczyły.
Tworząc raporty nie zapomnieliśmy o oprawie wizualnej. Podczas pracy ze stołami tej wielkości jest to ważny czynnik. Zastosowaliśmy na przykład spokojną gamę kolorów, łatwych do zauważenia dla liczb, kolorystyczne podświetlenie linii zgodnie z wartościami liczbowymi cech. Takie detale poprawiają doświadczenie użytkownika i zwiększają prawdopodobieństwo pomyślnego startu narzędzia w firmie.
Tabela okazała się dość obszerna, ale mamy nadzieję, że nie przestała być czytelna
Osobno warto wspomnieć o szkoleniach naszych klientów wewnętrznych: specjalistów produktowych i projektantów UX. Specjalnie dla nich przygotowano podręczniki z przykładami analiz i wskazówkami dotyczącymi pracy z filtrami. Umieściliśmy linki do podręczników bezpośrednio na stronach raportów.
Podręcznik przygotowaliśmy po prostu jako prezentację w Dokumentach Google. Narzędzia Tableau umożliwiają wyświetlanie stron internetowych bezpośrednio w skoroszycie raportów.
Zamiast posłowia
Co leży w ostatecznym rozrachunku? Stosunkowo szybko i tanio udało nam się zdobyć narzędzie na co dzień. Tak, na pewno nie jest to zamiennik samego wykresu, mapy cieplnej kliknięć czy przeglądarki internetowej. Jednak takie raporty w znaczący sposób uzupełniają wymienione narzędzia i dostarczają materiału do przemyśleń oraz tworzenia nowych hipotez dotyczących produktów i interfejsów.
Ta historia była jedynie początkiem rozwoju analityki w ISPsystem. W ciągu ostatniego półrocza pojawiło się jeszcze siedem nowych usług, m.in. cyfrowe portrety użytkownika w produkcie oraz usługa tworzenia baz danych na potrzeby targetowania Lookalike, ale o nich porozmawiamy w kolejnych odcinkach.
Źródło: www.habr.com