Przed premierą lista kontrolna analityki MVP powinna obejmować cztery elementy: jeden kluczowy proces, zdarzenie aktywacji, sytuacje zakończone błędem oraz zachowanie świadczące o powrocie do produktu, które uzasadnia kolejny cykl prac. Każde zdarzenie powinno w ciągu pierwszych 30 dni pomóc podjąć decyzję: utrzymać, poprawić czy zrezygnować.
Same odsłony stron nie mierzą, czy produkt spełnia swoją główną obietnicę.
Założyciele mają mało ruchu i jeszcze mniej czasu, dlatego pierwszy plan zdarzeń musi pozostać krótki. Ten poradnik zawiera gotową do skopiowania listę kontrolną, prawdziwe nazwy zdarzeń z działającej witryny webvise oraz 30-dniowy rejestr decyzji. Usługa tworzenia MVP świadczona przez webvise obejmuje analitykę użytkowników od pierwszego dnia, dzięki czemu pierwsza kohorta może wpłynąć na kolejną decyzję dotyczącą produktu.
- Należy mierzyć jeden kluczowy proces. Przed dodaniem pobocznych lejków warto rejestrować jego rozpoczęcie, pomyślne zakończenie, błąd i późniejsze powtórzenie.
- Aktywację należy definiować jako dostarczoną wartość. Utworzenie konta potwierdza dostęp. Do definicji aktywacji należy zdarzenie dowodzące, że produkt wykonał swoje zadanie.
- Sukces należy rejestrować po potwierdzeniu z serwera. Kliknięcia przycisków i optymistyczne stany interfejsu mogą zawyżać liczbę ukończonych działań.
- Regułę decyzyjną należy zapisać przed premierą. Każdy wskaźnik wymaga właściciela, daty przeglądu oraz uzgodnionej decyzji: utrzymać, poprawić czy zrezygnować.
Najpierw decyzja, którą MVP ma pomóc podjąć
MVP zasługuje na kolejny cykl prac, gdy faktyczne użycie produktu odpowiada na pytanie biznesowe. Plan zdarzeń zaczyna się od tego pytania, a następnie prowadzi wstecz do najmniejszego zestawu działań, które pozwolą znaleźć odpowiedź.
Szablon dokumentu wymagań dla MVP uwzględnia już jednego użytkownika, jeden proces i jeden wskaźnik sukcesu. Analityka uzupełnia ten wskaźnik o nazwę zdarzenia, punkt rejestracji, przedział czasu oraz osobę odpowiedzialną za decyzję.
| Pytanie produktowe | Dane do zebrania | Decyzja, którą wspierają |
|---|---|---|
| Czy nowy użytkownik może uzyskać obiecaną wartość? | Rozpoczęcie kluczowego procesu, jego sukces, błąd i czas ukończenia | Utrzymanie procesu lub poprawienie zablokowanego kroku |
| Czy wartość uzasadnia powrót do produktu? | Drugie pomyślne wykonanie procesu w późniejszym dniu | Inwestycja w retencję lub ponowna ocena obietnicy produktu |
| Czy kupujący zapłaci lub podejmie zobowiązanie? | Płatność, podpisany pilotaż, wartościowe zapytanie lub inne zadeklarowane zdarzenie biznesowe | Kontynuacja modelu biznesowego lub zmiana oferty |
| W którym miejscu proces się przerywa? | Nazwany kod błędu, krok, czas trwania i wersja aplikacji | Usunięcie usterki, która ma największy wpływ na użytkowników |
Wskaźnik bez przypisanej decyzji staje się ozdobą pulpitu. Decyzję warto zapisać obok zdarzenia, dopóki powód jego istnienia pozostaje jasny.
Lista kontrolna analityki MVP do skopiowania
Z listy warto korzystać podczas ustalania zakresu produktu, a końcowy katalog zdarzeń przechowywać obok opisu MVP. `core_workflow` należy zastąpić działaniem, które tworzy wartość, na przykład `report_generated`, `booking_confirmed` lub `certificate_issued`.
| Element listy kontrolnej | Przykładowe zdarzenie lub pole | Kryterium akceptacji |
|---|---|---|
| Wejście | `account_created` lub pierwsza zidentyfikowana sesja | Stabilny identyfikator użytkownika lub obszaru roboczego trafia do późniejszych zdarzeń |
| Zamiar | `core_workflow_started` | Zdarzenie jest rejestrowane, gdy użytkownik rozpoczyna istotne zadanie |
| Dostarczona wartość | `core_workflow_completed` | Zdarzenie jest rejestrowane po potwierdzeniu wyniku przez backend |
| Błąd | `core_workflow_failed` z polami `error_code` i `step` | Zdarzenie wskazuje możliwy do usunięcia błąd bez przechowywania poufnych danych wejściowych |
| Aktywacja | Ukończenie procesu w zadanym przedziale czasu | Definicja określa liczbę zdarzeń oraz limit czasu |
| Wartość skłaniająca do powrotu | Kolejne ukończenie procesu w późniejszym dniu | Zapytanie wyklucza ponowne próby i powielone dostarczenia |
| Wynik biznesowy | `payment_completed`, `pilot_signed` lub `qualified_request_sent` | Należy użyć wyłącznie zdarzenia odpowiadającego hipotezie biznesowej |
| Kontekst | `source`, `plan`, `workspace_id`, `duration_ms`, `app_version` | Każda właściwość ma zastosowanie decyzyjne i określony typ danych |
| Prywatność | Zatwierdzona lista właściwości i okres przechowywania | Adresy e-mail, treść wiadomości, tokeny dostępu i prywatne pliki nie trafiają do właściwości zdarzeń |
| Weryfikacja | Test w środowisku stagingowym, test produkcyjny i zapytanie w pulpicie | Przed premierą wyznaczona osoba sprawdza każde kluczowe zdarzenie |
Katalog jest celowo krótki. Założyciel może przejrzeć dziesięć zdarzeń po każdej sesji użytkownika. Katalog obejmujący 80 zdarzeń prowadzi do niespójnego nazewnictwa, zanim pojawi się pierwsza użyteczna kohorta.
Jeden proces wymaga zdarzeń rozpoczęcia, sukcesu i błędu
Formularz kontaktowy webvise początkowo korzystał ze zdarzenia `contact_form_submitted`, wdrożonego 2026-03-13. Zdarzenie zliczało próby. `contact_form_started` dodano 2026-04-30, a `contact_form_success` i `contact_form_error` pojawiły się 2026-05-01.
Cztery zdarzenia rozdzielają teraz trzy problemy: osoby, które zaczynają i rezygnują, zgłoszenia docierające do serwera oraz błędy dostarczenia po wysłaniu formularza. Każdy z nich wymaga innych prac. Tekst formularza wpływa na rozpoczęcie, układ pól na ukończenie, a błędy serwera wymagają pracy programistycznej.
| Zdarzenie produkcyjne | Pytanie, na które odpowiada | Prawdopodobne działanie |
|---|---|---|
| `contact_form_started` | Czy strona wzbudziła dość zainteresowania, aby użytkownik zaczął? | Przegląd oferty, CTA oraz położenia formularza |
| `contact_form_submitted` | Czy odwiedzający wypełnił pola? | Przegląd utrudnień w polach i walidacji |
| `contact_form_success` | Czy backend przyjął zgłoszenie? | Zliczanie dostarczonych zapytań |
| `contact_form_error` | Czy proces zakończył się błędem mimo wyraźnego zamiaru? | Sprawdzenie ścieżki serwerowej i powiadomienie właściciela |
Raport o stanie WordPressa korzysta z tego samego schematu w dłuższym lejku. `analyzer_submitted` wdrożono 2026-03-13, `analyzer_unlocked` 2026-03-30, a osobne zdarzenia sukcesu i błędu 2026-05-01. Zdarzenie sukcesu przechowuje również wyniki dla urządzeń mobilnych i komputerów oraz wyniki prognozowane. Dzięki temu jeden proces odpowiada na pytania produktowe i kwalifikacyjne bez kopiowania przesłanego raportu do analityki.
Te przykłady działają w obecnej aplikacji webvise. Pokazują też, dlaczego tworzenie produkcyjnego MVP obejmuje wdrożenie, monitoring oraz analitykę użytkowników już w pierwszym zakresie prac. Plan zdarzeń musi uwzględniać te same ścieżki błędów co produkt.
Aktywacja jako dostarczona wartość
Aktywacja rejestruje pierwsze wiarygodne dostarczenie wartości produktu. W produkcie dokumentowym może nastąpić po prawidłowym utworzeniu dokumentu. W produkcie rezerwacyjnym może nastąpić, gdy obie strony otrzymają potwierdzenie. Definicja wynika z obietnicy produktu.
PostHog opublikował swoją metodę określania aktywacji 2025-02-06. Zespoły testują grupy obejmujące 3 do 5 zdarzeń, porównują 5 do 10 grup kandydujących i sprawdzają, czy aktywowane konta utrzymują się po trzech miesiącach. Product analytics stosuje 30-dniowy przedział aktywacji, a Experimentation i Feature flags 14-dniowy.
| Produkt PostHog | Opublikowana definicja aktywacji | Przedział czasu |
|---|---|---|
| Experimentation | Uruchomienie 1 eksperymentu | 14 dni |
| Feature flags | Utworzenie 2 flag i zaktualizowanie 2 flag przy użyciu filtrów właściwości | 14 dni |
| Product analytics | Zarejestrowanie pierwszego zdarzenia zespołu, utworzenie 1 pulpitu i zapisanie 3 analiz | 30 dni |
| Session replay | Przeanalizowanie 5 nagrań i zmiana 1 filtra listy nagrań | 14 dni |
Poradnik PostHog dotyczący aktywacji opisuje również przydatny przypadek błędu. Zdarzenie `recording analyzed` uruchamiało się nieprawidłowo, dlatego wskaźnik aktywacji zaniżał liczbę zespołów, które odniosły sukces. PostHog zaleca rejestrowanie kluczowych zdarzeń aktywacji na serwerze, ponieważ blokady w przeglądarkach mogą odrzucać zdarzenia po stronie klienta.
Nowe MVP rzadko ma dość użytkowników, aby już w pierwszym miesiącu wykazać zależność z retencją. Najpierw należy wybrać zdarzenie najbliższe dostarczeniu wartości, przejrzeć rzeczywiste sesje i oznaczyć definicję jako wstępną. Warto ją zastąpić dopiero wtedy, gdy większa kohorta pokaże, które zachowanie pozwala przewidzieć powrót do produktu.
30-dniowy rejestr decyzji
Datę przeglądu należy ustalić przed premierą. Stały termin zapobiega zmianie planu produktu z dnia na dzień pod wpływem jednej głośnej sesji, a rejestr decyzji nie pozwala przeciągnąć słabego użycia na kolejny miesiąc prac nad funkcjami.
| Wskaźnik | Cel ustalony przed premierą | Wynik w 7. dniu | Wynik w 30. dniu | Reguła decyzyjna | Właściciel |
|---|---|---|---|---|---|
| Odsetek rozpoczęcia kluczowego procesu | ___% zaproszonych użytkowników | ___% | ___% | Poprawić wejście lub wdrożenie użytkownika, gdy zaproszone osoby nie zaczynają | ___ |
| Wskaźnik powodzenia procesu | ___% rozpoczęć | ___% | ___% | Poprawić zablokowany krok, gdy zamiar nie prowadzi do uzyskania wartości | ___ |
| Wskaźnik aktywacji | ___% w ciągu ___ dni | ___% | ___% | Utrzymać lub zmienić ścieżkę aktywacji | ___ |
| Ponowne użycie | ___% ponownie kończy proces | ___% | ___% | Ponownie ocenić częstotliwość występowania wartości, gdy użytkownicy po sukcesie nie wracają | ___ |
| Wynik biznesowy | ___ płatności, pilotaży lub wartościowych zapytań | ___ | ___ | Kontynuować, zmienić ofertę lub zrezygnować | ___ |
Cele należy ustalać na podstawie obietnicy sprzedażowej produktu, umowy pilotażowej lub ręcznie wyznaczonego punktu odniesienia. Ogólne wartości referencyjne aktywacji porównują produkty o różnych momentach dostarczenia wartości, źródłach ruchu, cenach i przedziałach czasu.
Mała liczba rozpoczęć wskazuje na zaproszenie lub wdrożenie użytkownika. Rozpoczęcia zakończone błędami wskazują na kwestie techniczne. Jednorazowy sukces, po którym następuje cisza, każe sprawdzić częstotliwość występowania wartości. Wielokrotne użycie bez wyniku biznesowego kieruje przegląd na cenę, kupującego lub ofertę.
Plan zdarzeń należy przekazać wykonawcy
Katalog zdarzeń należy umieścić w opisie prac i traktować kluczowe zdarzenia jako kryteria akceptacji. Zrzut ekranu pulpitu niewiele dowodzi, jeśli nie przetestowano czasu wystąpienia zdarzeń, tożsamości użytkownika oraz ścieżek błędów.
- Należy wskazać punkt rejestracji. Trzeba określić, czy dane zdarzenie rejestruje przeglądarka, trasa API, zadanie w tle czy webhook.
- Sukces należy testować po potwierdzeniu. Zdarzenie ukończenia procesu uruchamia się, gdy istnieje już trwały wynik, a nie po pierwszym kliknięciu przycisku.
- Błędy należy wywołać celowo podczas testów. Przed premierą warto wymusić jeden błąd walidacji, jeden błąd serwera i jeden przypadek przekroczenia czasu w usłudze zewnętrznej.
- Należy zweryfikować tożsamość. Po rejestracji anonimowe zdarzenia wejścia muszą zostać przypisane do tego samego użytkownika lub obszaru roboczego bez tworzenia drugiego profilu.
- Należy ograniczyć właściwości. Warto prowadzić pisemną listę dozwolonych identyfikatorów, kategorii, czasów trwania, wersji i zatwierdzonych danych o źródle pozyskania.
- Należy wyznaczyć osobę odpowiedzialną za przegląd. Trzeba wskazać osobę, która sprawdzi stan zdarzeń w dniu premiery i odczyta rejestr z 30. dnia.
webvise ujmuje kluczowy proces, katalog zdarzeń, konfigurację PostHog, wdrożenie i monitoring w ramach skoncentrowanej realizacji MVP. Jeśli pierwsze wydanie ma listę funkcji, ale nie ma planu pomiaru, warto wysłać opis do webvise, zanim nazwy zdarzeń zostaną utrwalone w kodzie produkcyjnym.