Porzucenie onboardingu w SaaS zwykle wygląda w raportach tak samo: rejestracji przybywa, a konta testowe po kilku dniach są puste. Sama liczba aktywacji nie powie, gdzie ludzie się zatrzymali. Potrzebujesz kilku punktów kontrolnych po drodze, jednego zdarzenia, które uznajesz za aktywację, i nagrań z dokładnie tego miejsca, w którym ścieżka się urywa. Wtedy zamiast zgadywać, czy winny jest cennik, termin trialu albo „słaby produkt”, oglądasz konkretny ekran.
Ten poradnik dotyczy diagnozy na danych: od definicji celów do sprawdzenia poprawki. Jak pomagać na czacie osobie, która już napisała, opisujemy w tekście o live chacie w okresie próbnym SaaS. Przykład poniżej dotyczy fikcyjnej aplikacji do układania grafików pracy; nazwy celów i liczby są ilustracją, a nie wynikiem wdrożenia.
Jak znaleźć krok, na którym utykają użytkownicy testowi
Krok, na którym utykają użytkownicy, to zwykle pierwszy cel po ostatnim, który większość jeszcze osiąga. Znajdziesz go, porównując liczby ukończeń kolejnych celów w tym samym okresie, a przyczynę ustalisz dopiero w nagraniach. Całość mieści się w pięciu krokach.
- Wyznacz 3–5 celów i jedno zdarzenie aktywacji.Każdy cel opisuje stan konta, który da się sprawdzić, a aktywacja to moment, w którym użytkownik po raz pierwszy dostaje wynik, po który przyszedł.
- Znajdź ostatni osiągany cel.Porównaj liczby ukończeń w tym samym zakresie dat i wskaż miejsce, gdzie spadek jest największy.
- Obejrzyj dwie grupy nagrań.Osoby, które zatrzymały się na tym kroku, i osoby, które przeszły dalej, z tego samego ekranu i urządzenia.
- Nazwij zachowanie i przyczynę.Oznacz pętle, wahanie i martwe kliknięcia, a potem rozstrzygnij: tekst, brakujący warunek wstępny czy cichy błąd.
- Popraw jedną rzecz i porównaj.Zmierz ten sam stosunek celów w okresie przed i po zmianie, o tej samej długości.
Kilka celów onboardingu i jedno zdarzenie aktywacji
Cel onboardingu powinien potwierdzać zmianę stanu, a nie odwiedzenie ekranu. „Otworzył import pracowników” mówi mniej niż „zapisał co najmniej jednego pracownika”. Aktywacją nie jest też ukończenie przewodnika, tylko pierwszy wynik, dla którego klient założył konto. W fikcyjnej aplikacji do grafików to opublikowanie pierwszego grafiku, bo dopiero wtedy pracownicy coś dostają.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Klucz celu | Co potwierdza | Kiedy go zapisać |
|---|---|---|
| konto_potwierdzone | Użytkownik może się zalogować | Po potwierdzeniu adresu e-mail |
| firma_skonfigurowana | Istnieje lokalizacja i godziny otwarcia | Po udanym zapisie ustawień |
| pracownicy_dodani | Na liście jest co najmniej jedna osoba | Po odpowiedzi serwera, nie po kliknięciu |
| grafik_opublikowany | Aktywacja: pierwszy grafik trafił do zespołu | Po potwierdzeniu publikacji |
W Analityce Meetlead cele definiujesz najpierw w panelu, jako zdarzenie albo odwiedzenie adresu. Aplikacja wywołuje potem meetlead.goal('pracownicy_dodani'), a widget zapisuje tylko klucze, które wcześniej skonfigurowano. Wywołuj cel raz, przy pierwszym zapisie potwierdzonym przez serwer: każde wywołanie to osobne ukończenie, a wywołanie po kliknięciu policzy też próby zakończone błędem. Jeśli twoja aplikacja zmienia ekrany bez przeładowania strony, sprawdź najpierw pomiar stron w aplikacji SPA.
Ostatni osiągnięty cel pokazuje miejsce, nie przyczynę
Ustaw jeden zakres dat i spisz liczbę ukończeń każdego celu. Załóżmy fikcyjnie: 400 potwierdzonych kont, 310 skonfigurowanych firm, 90 kont z pracownikami i 70 opublikowanych grafików. Największa strata leży między konfiguracją a dodaniem pracowników, więc ostatnim osiąganym celem jest „firma_skonfigurowana”. Tam zaczynasz, nawet jeśli zespół od miesięcy podejrzewa edytor grafiku.
Pamiętaj, czym są te liczby. Meetlead liczy ukończenia celów, a nie osoby, a onboarding w SaaS często rozkłada się na kilka dni i wizyt, więc zestawienie nie jest ścisłym lejkiem jednej osoby. Traktuj je jako wskazanie kroku do sprawdzenia. Gdy ktoś pomija etap albo do niego wraca, ustal zasady liczenia według poradnika o kolejności etapów lejka. Jeśli użytkownicy są identyfikowani przez meetlead.identify, ścieżka klienta pokaże kolejne wizyty tej samej osoby i osiągnięte w nich etapy.
Porównaj nagrania osób, które utknęły i które przeszły
Pierwsza grupa to wizyty na ekranie kroku, po których nie pojawia się następny cel. W liście nagrań filtrujesz po adresie tego ekranu, urządzeniu i dacie, a w ścieżce klienta sprawdzasz, czy po wizycie przyszedł zapis pracowników. Druga grupa to osoby, które cel osiągnęły; do ich sesji dojdziesz przez drilldown celu w Analityce. Oglądaj obie na tym samym urządzeniu, bo porażka na telefonie i sukces na komputerze nic nie wyjaśnią.
PostHog w poradniku o onboardingu radzi oglądać także nagrania osób, które krok ukończyły, bo mogły przebrnąć przez to samo tarcie. PostHog: App onboarding drop-off. Podane tam liczby nagrań i użytkowników to wskazówki autorów, a nie próg ważny dla twojego produktu.
Nie oglądaj nagrań losowo. Zapisz pytanie, na przykład „co robią osoby, które otworzyły import i nie zapisały pracownika?”, i trzymaj się go, jak w poradniku o tym, jak analizować nagrania sesji. Sprawdź też plan: Starter nie zapisuje nagrań, Growth przechowuje je 14 dni, a Scale 90 dni. Przy krótszej historii przeglądaj nagrania co tydzień, zanim wygasną.
Oznaczaj zachowania, zanim nazwiesz motyw
„Użytkownik się zniechęcił” to interpretacja, której nagranie nie potwierdza. Zapisuj to, co widać, w komentarzu przy konkretnym momencie nagrania, ze wspólnymi nazwami dla całego zespołu. Po kilkunastu sesjach policzysz, które zachowanie powtarza się w grupie, która utknęła, a w drugiej grupie występuje rzadko.
- Pętla: powrót między dwoma ekranami, na przykład import i ustawienia firmy, bez zapisu
- Wahanie: kursor lub palec krąży nad przyciskiem, który nie zostaje kliknięty
- Martwe kliknięcie: kliknięcie w element, który nie reaguje albo nie jest aktywny
- Cichy błąd: zapis bez komunikatu, po którym lista nadal jest pusta
- Wyjście do pomocy: otwarcie dokumentacji lub czatu dokładnie na tym kroku
Martwe i wściekłe kliknięcia rozpoznajesz w nagraniu ręcznie, sprawdzając, jak strona zareagowała; zasady tej oceny opisuje tekst o rage clicks i dead clicks. Nie wpisuj do komentarzy danych, które użytkownik wprowadził w polach. Do diagnozy wystarczy opis czynności i reakcji ekranu.
Tekst, brakujący warunek czy cichy błąd
Większość zatrzymań w onboardingu da się przypisać do jednej z trzech grup. Każda wymaga innej poprawki, dlatego rozstrzygnij ją przed planowaniem pracy. Jeśli sygnały wskazują dwie grupy naraz, zacznij od tej, która dotyczy większej części nagrań.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Przyczyna | Co widać w nagraniach | Typowa poprawka |
|---|---|---|
| Niejasny tekst | Wahanie nad przyciskiem, czytanie i powrót, wybór złej opcji | Zmiana etykiety, przykładu lub kolejności pól |
| Brakujący warunek wstępny | Pętla do innego ekranu, wyjście po plik lub dane | Wcześniejsza zapowiedź warunku, szablon, dane przykładowe |
| Cichy błąd | Kliknięcie zapisu bez zmiany stanu, ponowne próby | Naprawa błędu i widoczny komunikat |
W fikcyjnym przykładzie nagrania pokazują pętlę: użytkownik otwiera import, widzi wymóg pliku CSV z kolumną stanowisk i wraca do ustawień firmy. To brakujący warunek wstępny, a nie zły tekst przycisku. Jak opisać takie wymagania przed pierwszym krokiem, pokazuje poradnik o warunkach wstępnych instrukcji. Poprawką może być wzór pliku do pobrania albo możliwość ręcznego dodania jednej osoby.
Pomoc tylko na tym kroku i porównanie przed i po
Podpowiedź pokazuj tam, gdzie ludzie utykają, a nie na każdym ekranie. Jeśli widget Meetlead działa w aplikacji, automatyzacja może otworzyć proaktywny czat po wizycie na adresie importu i określonym czasie na stronie. Wiadomość powinna dotyczyć jednego warunku, a nie zapraszać do rozmowy o wszystkim.
Import wymaga pliku CSV z kolumną stanowisk. Nie masz go pod ręką? Dodaj jedną osobę ręcznie i opublikuj próbny grafik, a resztę zespołu zaimportujesz później.
Chameleon zaznacza, że przewodniki i podpowiedzi w aplikacji nie naprawią zepsutego lub mylącego głównego przepływu, więc najpierw poprawia się produkt. Chameleon: onboarding drop-off. Artykuł nie dowodzi, która z tych dróg zadziała w twojej aplikacji.
Obserwację przenieś do zadania: w Projektach powiążesz nagranie z zadaniem, więc osoba wdrażająca poprawkę obejrzy ten sam moment. Po wdrożeniu porównaj stosunek „pracownicy_dodani” do „firma_skonfigurowana” w okresie przed i po zmianie, o tej samej długości i bez równoległej kampanii. Zmieniaj jedną rzecz naraz, bo przy dwóch nie ustalisz, która zadziałała. Na koniec obejrzyj kilka nowych nagrań z tego kroku i sprawdź, czy pętla zniknęła.
Pytania o porzucenie onboardingu
Ile nagrań trzeba obejrzeć, zanim uznam przyczynę? Nie ma jednej liczby. Oglądaj, aż potrafisz opisać zachowanie powtarzające się w grupie, która utknęła, i wskazać sesje, które do wzorca nie pasują. Jeśli każde nagranie wygląda inaczej, zawęź urządzenie, ekran albo okres. Wniosek z jednej sesji traktuj jako hipotezę do sprawdzenia.
Czy wystarczy dodać przewodnik po aplikacji? Tylko wtedy, gdy przyczyną jest niejasny tekst. Przewodnik nie usunie brakującego warunku ani cichego błędu, a dodany na każdym ekranie przeszkadza osobom, które radzą sobie same. Najpierw ustal przyczynę w nagraniach, potem dobierz poprawkę i zmierz ją na tym samym stosunku celów.
