U mnie działa: jak znaleźć błąd, który widzi tylko część użytkowników

Zdanie „u mnie działa” jest zwykle prawdziwe i zwykle bezużyteczne. Strona faktycznie działa na komputerze osoby, która ją zbudowała, w przeglądarce, którą ta osoba aktualizuje co tydzień, na szybkim łączu i przy domyślnym rozmiarze czcionki. Problem polega na tym, że to nie jest typowy warunek wizyty, tylko jeden z wielu — a usterki lubią mieszkać w tych pozostałych.

Ten tekst nie dotyczy awarii, po której nikt nie może wysłać formularza. Takie rzeczy wychodzą w ciągu godziny. Dotyczy usterek, które psują ścieżkę u wąskiej grupy odwiedzających i potrafią żyć miesiącami, bo nikt ich nie zgłasza. Poniżej znajdziesz sposoby ich wykrycia, zanim ktoś zadzwoni z pretensją.

Świadomie nie podajemy udziałów przeglądarek, systemów ani rozdzielczości. Takie liczby różnią się między branżami i rynkami, a decyzja o tym, co warto sprawdzić, powinna wynikać z twoich własnych danych, nie z zestawienia znalezionego w internecie.

Dlaczego takiej usterki nie widać w statystykach

Wyobraź sobie, że przycisk wysyłki formularza przestaje reagować u jednej osoby na trzydzieści. W raporcie zobaczysz spadek konwersji o ułamek punktu procentowego — czyli dokładnie tyle, ile strona waha się w normalnym tygodniu. Nie ma progu, który by się przekroczył, nie ma alertu, nie ma nawet powodu, żeby ktokolwiek zajrzał głębiej. Usterka rozpływa się w średniej.

Druga połowa problemu jest psychologiczna. Osoba, u której coś nie działa, rzadko zakłada, że winna jest strona. Częściej myśli, że kliknęła nie tam, że ma słaby zasięg albo że firma po prostu nie odbiera zapytań. Wyjście jest tańsze niż zgłoszenie — trwa sekundę i nie wymaga tłumaczenia się obcej firmie ze swojego telefonu. Dlatego brak zgłoszeń nie jest dowodem, że wszystko działa.

Z tego wynika przykry paradoks: im węższa grupa jest dotknięta, tym dłużej błąd żyje. Awaria u wszystkich zostaje naprawiona tego samego dnia. Awaria u pięciu procent odwiedzających może przetrwać kolejny redesign. Szczególnie warto o tym pamiętać po wdrożeniach, bo to wtedy powstaje najwięcej takich usterek — temat pilnowania ciągłości pomiaru rozwijamy w tekście o przebudowie strony a pomiarze.

Typowe źródła usterek dotykających mniejszości

Warunki wizyty różnią się od twoich w kilku powtarzalnych wymiarach. Poniższa tabela zestawia to, co jest inne u klienta, z tym, co najczęściej się przy tym psuje, oraz ze sposobem wychwycenia problemu bez zgadywania.

Dwa wiersze celowo traktujemy tu skrótowo, bo mają własne opracowania. Bariery specyficzne dla małych ekranów opisujemy w tekście o konwersji na urządzeniach mobilnych, a obsługę bez myszy i z czytnikiem ekranu — w przewodniku o dostępności ścieżek kontaktu. Tutaj interesuje nas sama metoda wykrywania: co zrobić, gdy nie wiesz jeszcze, czego szukasz.

Ważne zastrzeżenie o narzędziu. Meetlead nie zbiera błędów javascriptu ani logów przeglądarki i nie jest narzędziem do monitoringu technicznego. Pokazuje objaw i to, kogo dotyczy: nagranie sesji z pełnym profilem odwiedzającego, w tym przeglądarką, urządzeniem i adresem, wraz z markerami kliknięć i zmian adresu. Do ustalenia technicznej przyczyny — konkretnego błędu w kodzie, odpowiedzi serwera czy wersji biblioteki — potrzebne jest osobne narzędzie oraz osoba, która zajrzy do kodu.

Sygnały w danych, które zdradzają wąską usterkę

Nie da się przewidzieć, gdzie coś się zepsuje, ale da się nauczyć rozpoznawać ślad, jaki usterka zostawia w danych. Cztery poniższe wzorce w praktyce wystarczają, żeby postawić sensowną hipotezę.

• Segment o zerowej konwersjiJedna przeglądarka, jeden system albo jeden zakres szerokości ekranu ma ruch, ale w całym miesiącu ani jednego zapytania.
• Kliknięcia bez efektuPowtórzone kliknięcia w to samo miejsce, po których nie następuje zmiana adresu ani żadne kolejne zdarzenie.
• Wspólny krok wyjściaSesje z różnych źródeł kończą się dokładnie w tym samym miejscu ścieżki, choć nic tam nie zachęca do rezygnacji.
• Wizyta bez oczekiwanych zdarzeńOdwiedzający przewija podstronę i zostaje na niej długo, ale brakuje zdarzeń, które na tej podstronie występują zawsze.

Pierwszy sygnał wymaga ostrożności: przy małych segmentach zero konwersji bywa zwykłym przypadkiem. Traktuj go poważnie dopiero wtedy, gdy segment ma sensowną liczbę wizyt, a inne porównywalne segmenty konwertują normalnie. Drugi sygnał jest najmocniejszy i najprostszy do sprawdzenia — powtórzone kliknięcie w to samo miejsce to komunikat „naciskam i nic się nie dzieje” zapisany w danych. Zdarzenie kliknięcia w konkretny element pozwala potem sprawdzić, czy dany przycisk faktycznie odnotowuje interakcje we wszystkich segmentach, czy tylko w części z nich.

Mapy kliknięć i przewijania czytaj osobno dla telefonu i komputera, bo zsumowane potrafią zamaskować wzorzec występujący tylko w jednej grupie. Sposób czytania samych map opisujemy w poradniku jak czytać mapy ciepła.

Jak potwierdzić hipotezę nagraniem

Dane ilościowe mówią, że coś jest nie tak, i wskazują grupę. Nagranie pokazuje przebieg, czyli to, co odwiedzający próbował zrobić i w którym momencie się poddał. Ogólne zasady doboru materiału opisujemy w tekście o tym, jak analizować nagrania sesji. Przy polowaniu na usterkę mniejszości obowiązuje jednak inny sposób filtrowania.

1. Filtruj po profilu, nie po dacie.Wybierz sesje z podejrzanej przeglądarki, systemu albo urządzenia, zamiast oglądać najnowsze wizyty z rzędu.
2. Weź wizyty, które dotarły daleko i nic nie dały.Odwiedzający, który przeszedł trzy kroki i zniknął w czwartym, chciał czegoś i napotkał przeszkodę.
3. Zacznij oglądać od momentu decyzji.Przewiń do miejsca, w którym powinno wydarzyć się kliknięcie albo przejście, i patrz na to, co dzieje się tuż przed nim.
4. Szukaj trzech objawów.Powtórzonego kliknięcia w to samo miejsce, nagłego bezruchu przy widocznym wcześniej tempie oraz cofnięcia się o krok.
5. Zrób próbę kontrolną.Obejrzyj kilka sesji z typowej przeglądarki na tej samej podstronie. Jeśli przebieg jest gładki, hipoteza się trzyma.
6. Odtwórz warunek u siebie.Powiększona czcionka, tryb ciemny, wolniejsze łącze albo włączony bloker — dopiero to zamienia hipotezę w usterkę do naprawy.

Ostatni krok jest tym, o którym najłatwiej zapomnieć. Nagranie pokazuje, że przycisk nie zadziałał, ale nie powie, dlaczego. Odtworzenie warunku po swojej stronie zamienia obserwację w zgłoszenie, które programista może przyjąć do pracy — a jeśli nie da się go odtworzyć, przynajmniej wiadomo, komu i na czym trzeba się przyjrzeć dokładniej.

Pytanie klienta jako najtańszy detektor

Zanim jakikolwiek wykres pokaże spadek, ktoś napisze na czacie zdanie, które łatwo zignorować. To najtańszy system wykrywania usterek, jaki masz, i jedyny, który działa od pierwszego dnia. Warunek jest jeden: zespół musi traktować takie zdania jako zgłoszenie techniczne, a nie jako pomyłkę użytkownika.

• „Nie mogę kliknąć” — element wygląda na aktywny, ale nie reaguje albo jest przykryty czymś innym.
• „Nic się nie dzieje” — akcja została wykonana, tylko strona nie dała żadnej informacji zwrotnej.
• „Nie widzę tego przycisku” — element jest poza obszarem widocznym albo zlewa się z tłem.
• „Formularz nie przyjmuje mojego numeru” — walidacja odrzuca poprawny format albo autouzupełnianie wstawiło dane nie tam.
• „Strona mi się rozjeżdża” — układ psuje się przy tej rozdzielczości lub przy powiększonej czcionce.
• „Musiałem to otworzyć na komputerze” — ścieżka na telefonie jest niedokończona, a klient sam obszedł problem.

Odpowiedź „u nas działa” kończy wątek i kasuje jedyny dowód, jaki był dostępny. Zamiast niej warto zadać trzy pytania: z czego klient korzysta, co dokładnie zrobił i co zobaczył. Live chat pomaga tu podwójnie, bo operator widzi bieżącą stronę rozmówcy i nie musi prosić o opis adresu. Jeśli rozmowa trafi później do zgłoszenia z historią, kolejne podobne zdanie od innej osoby przestaje być anegdotą i staje się wzorcem. Sam dobór pól i komunikatów w formularzu opisujemy osobno w tekście o formularzu kontaktowym na stronie.

Rutyna sprawdzania po każdej zmianie

Większość usterek mniejszości powstaje przy wdrożeniu, a nie samoczynnie. Dlatego najtańszym momentem na ich wychwycenie jest kilka dni po zmianie, kiedy wiadomo jeszcze, co dokładnie zostało ruszone. Poniższa lista zajmuje kwadrans i wyłapuje zaskakująco dużo.

• Przejdź całą ścieżkę do kontaktu w innej przeglądarce niż ta, w której pracujesz na co dzień.
• Powtórz przejście przy powiększeniu strony i przy trybie ciemnym włączonym w systemie.
• Sprawdź stronę na starszym telefonie dostępnym w firmie, na realnym łączu komórkowym.
• Otwórz witrynę z włączonym blokerem treści i sprawdź, czy formularz oraz osadzone elementy się pokazują.
• Porównaj konwersję w rozbiciu na przeglądarki i urządzenia z tygodniem sprzed wdrożenia.
• Przejrzyj mapę kliknięć kluczowej podstrony pod kątem powtórzonych kliknięć w to samo miejsce.
• Przeczytaj rozmowy i zgłoszenia z pierwszych dni po zmianie, szukając zdań o tym, że coś nie działa.

Ostatni punkt bywa najbardziej produktywny, bo kosztuje kilka minut i nie wymaga żadnego narzędzia poza historią rozmów. Jeśli chcesz mieć z tego rutynę, a nie jednorazowy zryw, wpisz te siedem punktów do listy kontrolnej wdrożenia — obok testów, które zespół i tak wykonuje. Usterka znaleziona w tygodniu wdrożenia kosztuje poprawkę. Ta sama usterka znaleziona po kwartale kosztuje kwartał zapytań.