Ustawienie celu w Astrina to nie to samo co włączenie pełnego monitoringu. Cel jest mniejszy. Oznacza jeden warunek sukcesu dla jednego procesu, na przykład wypełniony formularz, potwierdzony krok płatności albo wewnętrzny punkt kontrolny QA. Jeśli zastanawiasz się, jak skonfigurować cele Astrina, zacznij od traktowania każdego celu jak jednej, mierzalnej linii mety. W praktyce najlepsza będzie po prostu cel Astrina konfiguracja oparta na jednym jasnym rezultacie.
Takie wąskie podejście ma znaczenie, bo jeden cel powinien odpowiadać na jedno pytanie. Czy użytkownik wysłał formularz? Czy strona osiągnęła stan podziękowania? Czy przepływ testowy zakończył ostatni krok? Wybierz jedną odpowiedź, nie trzy. Jasne definicje oszczędzają czas później, zwłaszcza gdy ktoś z zespołu otwiera wynik po wdrożeniu w piątkowe popołudnie.
1. Określ, co „cel” ma oznaczać w Twoim koncie Astrina
Zacznij od znaczenia biznesowego, nie od przycisku. Cel może reprezentować konwersję, kamień milowy, zakończoną akcję albo wewnętrzny punkt kontrolny QA. Te cztery przypadki wyglądają podobnie na papierze, ale w praktyce działają inaczej. Konwersja zwykle ma znaczenie dla przychodu. Kamień milowy może być stanem pośrednim. Punkt kontrolny QA może być istotny tylko dla zespołu produktowego.
Jedno załadowanie strony nie jest celem. Jedna poprawna odpowiedź API też nie zawsze jest celem. Pytanie brzmi, czy dana akcja dowodzi, że proces osiągnął stan, który Cię interesuje. Jeśli zespół wsparcia ma wiedzieć, że krok płatności został ukończony, cel powinien mówić to wprost. Jeśli zespół QA ma wiedzieć, że po logowaniu otworzył się modal, to jest inny cel.
Trzymaj definicję wąsko. Cel typu „użytkownik ukończył onboarding” brzmi porządnie, ale może ukrywać trzy różne stany: utworzenie konta, weryfikację e-maila i uzupełnienie profilu. Rozdziel je, jeśli jedna awaria miałaby znaczenie sama w sobie. Dwa małe cele są łatwiejsze do odczytania niż jeden niejasny.
2. Wybierz jedną konkretną akcję użytkownika, którą zamienisz w cel
Wybierz jedną akcję i trzymaj się jej. Wysłanie formularza to dobry przykład. Podobnie kliknięcie końcowego przycisku „Potwierdź”, dotarcie do adresu URL sukcesu albo zobaczenie widocznego stanu na stronie po finalizacji zakupu. Akcja powinna być czymś, co Astrina potrafi rozpoznać bez zgadywania, co użytkownik miał na myśli.
Nie łącz kilku akcji w jedną. „Użytkownik zarejestrował się i zweryfikował e-mail” brzmi efektywnie, ale miesza dwa zdarzenia i wprowadza zamieszanie, gdy dzieje się tylko jedna z tych rzeczy. Cel powinien kończyć się jednoznacznie powodzeniem albo jednoznacznie niepowodzeniem. Nic pomiędzy. Jeśli proces ma pięć kroków, wybierz ten jeden, który dowodzi sukcesu dla tego celu, a resztę pomiń.
Pomagają tu konkretne przykłady. Cel dla checkoutu może brzmieć: „strona płatności pokazuje potwierdzenie zamówienia”. Cel dla procesu publikacji może brzmieć: „przycisk publikacji zmienia status na aktywny”. Cel dla procesu wsparcia może brzmieć: „formularz zgłoszenia pokazuje wiadomość z podziękowaniem”. Każdy z nich ma jedną akcję, jeden rezultat i jeden powód istnienia.
3. Mapuj cel na dokładny trigger, który Astrina potrafi rozpoznać
Gdy akcja jest już jasna, przypisz ją do sygnału, który Astrina może zmierzyć. Taki sygnał może być warunkiem URL, zmianą w DOM, dopasowaniem tekstu albo innym zdarzeniem obsługiwanym przez produkt. Trigger powinien być na tyle precyzyjny, by wskazywał jeden wynik, a nie całą rodzinę podobnych wyników. Jeśli potrzebujesz punktu odniesienia dla aktualnych nazw kontrolek lub dostępnych pól, sprawdź punkty końcowe, uwierzytelnianie i limity i porównaj je z ekranami działającego produktu, zanim opublikujesz cel.
Użyj dokładnie tego, co zmienia się po ukończeniu celu. Strona z podziękowaniem często ma unikalny adres URL. Stan sukcesu w checkoutcie może zmieniać etykietę przycisku albo wyświetlać numer zamówienia. Punkt kontrolny QA może ujawniać konkretny element DOM. Nie polegaj na szerokim wzorcu, jeśli istnieje węższy, bo szerokie wzorce łapią zły wynik szybciej, niż ludzie się spodziewają.
To właśnie na tym etapie dyscyplina w nazewnictwie się opłaca. Jeśli Astrina prosi o selektor, niech będzie czytelny. Jeśli interfejs prosi o nazwę zdarzenia, nazwij je po rzeczywistej akcji, a nie po wewnętrznym żarcie zespołu z 2022 roku. Jeden jasny trigger jest lepszy niż cztery sprytne.
4. Zdefiniuj granice sukcesu i porażki
Cel powinien rozpoznawać prawdziwe zakończenie i ignorować prawie sukcesy. Brzmi to prosto, dopóki nie pojawią się ponowne próby, przekierowania i częściowe ładowanie. Formularz może wysłać się dwa razy. Checkout może na chwilę pokazać komunikat sukcesu, a potem wyrzucić błąd. Strona może wyświetlić właściwy tekst, zanim dane załadują się w pełni. Twój cel musi ignorować takie fałszywe pozytywy.
Ustaw granicę sukcesu wokół ostatecznego dowodu zakończenia. Jeśli proces kończy się na stronie statusu, wymagaj stanu strony, który pojawia się tylko po zakończeniu. Jeśli kończy się na zmianie DOM, wymagaj tej zmiany, która pojawia się dopiero po ostatnim kroku. Jeśli kończy się na URL, bądź precyzyjny co do warunku. Małe luki tworzą złe wyniki. Złe wyniki marnują czas na przegląd.
Granice porażki są równie ważne. Cel nie powinien uruchamiać się przy częściowym postępie, przyciskach ponawiania ani treści zastępczej. Jeśli w checkoutcie są opcje „Zapisz na później” i „Kup teraz”, liczy się tylko jedna z nich. Jeśli w formularzu są „następny krok” i „wyślij”, liczy się tylko jedna. Im czystsza granica, tym mniej niespodzianek w raporcie.
5. Ustal nazewnictwo, etykiety i odpowiedzialność za cel
Nazwij cel tak, by inna osoba mogła go zrozumieć w pięć sekund. „Strona potwierdzenia checkoutu” jest lepsze niż „Cel 7”. „Formularz wsparcia wysłany - staging” jest lepsze niż „Formularz kontaktowy”. Zespół z sześcioma celami poradzi sobie z niejasnymi nazwami; zespół z sześćdziesięcioma już nie. Zachowaj spójny wzór w całym koncie.
Etykiety pomagają, gdy cele są grupowane według wdrożenia, środowiska lub działu. Jedna etykieta może oznaczać staging. Inna może oznaczać produkcję. Trzecia może oznaczać obszar produktu, na przykład rozliczenia albo onboarding. Chodzi nie o ozdobę. Chodzi o to, by filtrowanie było oczywiste, gdy ktoś potrzebuje zestawu celów do przeglądu wdrożenia albo przekazania pracy.
Odpowiedzialność to ostatni element. Jedna osoba, jeden zespół albo jedna wspólna kolejka powinny odpowiadać za zmiany. Jeśli nikt nie jest właścicielem celu, nikt nie zauważy, że zmiana UI go zepsuła. Jeśli odpowiedzialność nie jest jasna, zapisz ją obok celu albo w zespołowym runbooku. Krótka notatka, mniej sporów.
6. Przetestuj cel na jednym prawdziwym scenariuszu
Najpierw przetestuj cel na jednym znanym, poprawnym przepływie. Użyj prawdziwego scenariusza, który powinien przejść, a nie sztucznego przypadku skrajnego. Potem sprawdź jeden znany zły przepływ, który powinien się nie powieść. Taka para mówi więcej niż tuzin domysłów. Jeśli cel przechodzi oba testy, trigger jest zbyt szeroki. Jeśli nie przechodzi żadnego, trigger jest zbyt wąski albo wskazuje na niewłaściwy sygnał.
Na przykład cel dla checkoutu powinien przejść, gdy zamówienie naprawdę zostaje ukończone, i nie przejść, gdy użytkownik porzuca koszyk w połowie. Cel dla rejestracji powinien przejść, gdy pojawi się krok potwierdzenia, i nie przejść, gdy użytkownik zatrzyma się po wpisaniu e-maila. Trzymaj test mały. Nie musisz powtarzać całej konfiguracji monitoringu tylko po to, by zweryfikować jeden cel.
Jeśli wynik wygląda dziwnie, sprawdź, czy cel jest przypięty do właściwej akcji lub właściwego środowiska. Cel ze stagingu uruchamiany na danych produkcyjnych może dawać bardzo mylące dowody. Ten błąd zdarza się częściej, niż zespoły przyznają. Da się go uniknąć.
7. Przejrzyj wynik celu i zdecyduj, co poprawić
Po teście przeanalizuj zapisany wynik z taką samą uwagą, jaką poświęciłbyś raportowi dla klienta. Czy interesariusz może go odczytać bez prośby o tłumaczenie? Czy wynik pokazuje właściwy stan sukcesu? Czy wymienia dokładny trigger, czy tylko ogólne zaliczone/niezaliczone? Jeśli wynik jest trudny do odczytania, cel nie jest jeszcze gotowy.
Dostosuj trigger, jeśli cel jest zbyt szeroki. Zaostrz granice, jeśli przechodzi przez nie częściowy postęp. Zmień nazwę, jeśli etykieta nie pasuje do procesu, który faktycznie się zakończył. W niektórych przypadkach problem wcale nie leży w triggerze; leży w sformułowaniu. Cel nazwany „signup” może wymagać „konto utworzone”, jeśli to naprawdę jest linia mety.
Pomaga tu jeden praktyczny nawyk: przejrzyj cel z osobą, która go nie budowała. Jeśli potrafi opisać go poprawnie jednym zdaniem, cel jest prawdopodobnie dobry. Jeśli nie potrafi, cel prawdopodobnie ukrywa zbyt wiele szczegółów albo używa sygnału, który rozumie tylko autor.
8. Utrzymuj cel wraz ze zmianami produktu
Cele starzeją się źle, gdy produkt się zmienia, a nikt ich nie sprawdza. Aktualizacja UI może przesunąć przycisk. Zmiana lejka może zmienić nazwę kroku. Nowy proces może sprawić, że stary stanie się nieaktualny. Przeglądaj każdy cel po takich zmianach, a nie dopiero po sześciu miesiącach. Najszybciej psuje się cel przypięty do strony, która już nie istnieje.
Wprowadź prosty nawyk przeglądu przy wdrożeniach. Po redesignie potwierdź, że stan sukcesu nadal istnieje. Po zmianie checkoutu potwierdź, że strona potwierdzenia nadal niesie ten sam sygnał. Po nowym procesie onboardingowym potwierdź, że stary cel nadal ma sens albo został wycofany. Małe przeglądy zapobiegają dużemu chaosowi.
Jeśli potrzebujesz też pomocy w interpretacji alertów związanych z tymi kontrolami, przewodnik o tym, co zrobić, gdy alerty Astrina przestają przychodzić, pomoże odróżnić uszkodzony cel od uszkodzonej ścieżki powiadomień. To rozróżnienie oszczędza czas podczas okna wdrożeniowego.
Zespoły, które dbają o dokumentację, mogą pójść o krok dalej i podłączyć cel do krótkiej notatki wewnętrznej. Dodaj trigger, właściciela i datę ostatniego przeglądu. Trzy pola. To wystarczy. Jeśli cel zmienia właściciela, następna osoba nie powinna potrzebować spotkania, by zrozumieć, po co on istnieje.
Praktyczne przykłady dobrego celu Astrina
Dobry cel ma jedną akcję, jeden sygnał i jednego właściciela. Zespół checkoutu może zdefiniować cel wokół stanu potwierdzenia zamówienia po płatności. Zespół marketingu może zdefiniować cel wokół ukończonego formularza kontaktowego. Zespół QA może zdefiniować cel wokół modala, który pojawia się tylko po włączeniu flagi funkcji. Każdy przykład używa jednego mierzalnego wyniku.
Oto test: jeśli usuniesz jedno zdanie z definicji i cel stanie się niejasny, definicja była prawdopodobnie zbyt krótka. Jeśli dodasz trzy kolejne warunki i cel stanie się trudniejszy do odczytania, definicja była prawdopodobnie zbyt przeładowana. Właściwy cel jest zwykle najprostszym, który nadal wychwytuje właściwy rezultat.
| Rodzaj celu | Przykładowy trigger | Czego unikać |
|---|---|---|
| Konwersja | Adres URL sukcesu po płatności | Strona koszyka, szkic strony podziękowania, ekran ponowienia |
| Kamień milowy | Krok profilu zostaje ukończony | Dowolna strona z przyciskiem „następny” |
| Punkt kontrolny QA | Element pojawia się po logowaniu | Spinner ładowania, częściowe wyrenderowanie |
Jeśli nadal zastanawiasz się, jak cel wpisuje się w szerszy proces, artykuł o astrina dla nietechnicznych właścicieli stron internetowych oferuje użyteczny sposób myślenia o prostej odpowiedzialności i jasnych kontrolach. Ta perspektywa jest przydatna, gdy osoba utrzymująca cel nie jest osobą, która zbudowała stronę.
Typowe błędy, których warto unikać
Pierwszy błąd to robienie z jednego celu dwóch zadań. Cel, który śledzi zarówno rejestrację, jak i płatność, będzie się nie powieść z powodów, które nie mają nic wspólnego z prawdziwym problemem. Drugi błąd to użycie triggera, który pojawia się zbyt wcześnie. Komunikat „sukces” ładujący się przed zakończeniem ostatniej akcji to pułapka. Trzeci błąd to pozostawienie odpowiedzialności pustej i liczenie, że zespół wszystko zapamięta. Zespoły rzadko to robią.
Kolejny błąd to nazywanie celu według niejasnej idei biznesowej zamiast widocznego rezultatu. „Retencja” nie jest celem. „Strona odnowienia potwierdza subskrypcję” jest celem. Ta różnica brzmi drobno, ale decyduje o tym, czy następna osoba zrozumie test, czy otworzy wątek na Slacku, żeby zapytać, co się stało.
Na koniec nie zostawiaj jednego starego celu nietkniętego po dwóch zmianach produktu. Cel, który pasował do UI w marcu, może być błędny w czerwcu. Jeśli proces się zmienił, cel też powinien się zmienić. Bez dramatu.
Utrzymuj definicję celu na tyle krótką, by przetrwała zmiany
Przydatna definicja celu często mieści się w jednym zdaniu i jednej notatce o właścicielu. To ograniczenie wymusza jasność. Sprawia też, że przeglądy są szybsze, gdy ktoś z zespołu sprawdza konto przed wdrożeniem. Cel powinien mówić, jak wygląda sukces, gdzie się pojawia i kto za niego odpowiada. Wszystko więcej może należeć do dokumentacji, a nie do samego celu.
Jeśli musisz wrócić do powierzchni produktu, które zasilają cel, porównaj bieżący proces z aktualnymi szczegółami kontroli i, gdy trzeba, z dokumentacją produktu dotyczącą tego, jak sprawdzić, czy strona internetowa działa zgodnie z oczekiwaniami także na urządzeniach mobilnych. Cel związany wyłącznie ze stanem mobilnym może zawieść, jeśli nikt nie zauważy przesunięcia układu.
To właśnie jest prawdziwa praca przy tym, jak skonfigurować cele Astrina: jedna akcja, jeden sygnał, jeden właściciel, a potem test, który potwierdza, że cel nadal znaczy to, co zespół uważa, że znaczy.
