Tracker lejka trial→płatne: signupy, aktywacje, kohorty

Co to jest tracker lejka od trial do płatnych (i dlaczego pomaga)

Darmowy trial może wyglądać na aktywny: signupy rosną, wsparcie jest zajęte, a ludzie mówią, że „sprawdzają”. Mimo to przychód stoi w miejscu. To zazwyczaj oznacza, że trial wzbudza zainteresowanie, ale zbyt mało osób osiąga prawdziwy rezultat.

Tracker lejka od trial do płatnych to prosty sposób, żeby zobaczyć postęp w trakcie trialu. Odpowiada na jedno praktyczne pytanie: gdzie ludzie przestają iść dalej?

Większość prób subskrypcyjnych można śledzić przez trzy momenty:

• Signup: ktoś tworzy konto (lub zaczyna trial).
• Aktywacja: osiąga pierwszy znaczący rezultat (moment „aha”).
• Płatna konwersja: zaczyna płatny plan.

„Etap odpływu” to luka między tymi momentami. Jeśli 1000 osób się zapisze, ale tylko 150 się aktywuje, największy odpływ jest między signupem a aktywacją. Jeśli 150 się aktywuje, a tylko 10 płaci, odpływ jest między aktywacją a konwersją.

Chodzi nie o ładniejszy raport, lecz o skupienie. Kiedy wiesz, który etap jest słaby, następne kroki stają się prostsze: zmniejszyć tarcie przy rejestracji, poprawić onboarding lub dopracować sposób i moment proszenia o upgrade.

Częsty wzorzec to świętowanie „500 nowych triali w tym tygodniu”, a potem odkrycie, że tylko 5% kończy konfigurację. To nie problem marketingu — to problem aktywacji. Tracker uwidacznia to wcześnie, gdy naprawa jest jeszcze prosta.

Zdecyduj o etapach lejka i klarownych definicjach zdarzeń

Tracker działa tylko wtedy, gdy wszyscy zgadzają się, co oznacza każdy etap. Jeśli „signup” jest niejasny lub zmienia się co miesiąc, linia trendu będzie się poruszać nawet wtedy, gdy produkt się nie zmienił.

Zacznij od signupu. Dla niektórych produktów signup to po prostu „konto utworzone”. Dla innych to „email zweryfikowany” lub „pierwszy workspace utworzony”. Wybierz moment, który najlepiej oznacza prawdziwego nowego użytkownika trial, i trzymaj się go. Jeśli zmienisz regułę później, zanotuj datę i spodziewaj się przerwy w historycznym trendzie.

Następnie zdefiniuj aktywację. Aktywacja to nie „otworzył aplikację” ani „odwiedził dashboard”. To pierwsze znaczące zdarzenie sukcesu, które udowadnia, że użytkownik otrzymał wartość. Dobre zdarzenie aktywacji jest konkretne, szybko osiągalne i powiązane z obietnicą produktu.

Prosty zestaw definicji etapów na start:

• Signup: utworzono nowe konto trial (lub zweryfikowano, jeśli wymagane)
• Aktywacja: użytkownik wykonał pierwszą akcję przynoszącą wartość (twój moment „aha”)
• Płatna konwersja: użytkownik zaktualizował plan i płatność przeszła pomyślnie (nie tylko kliknięcie „upgrade”)
• Sprawdzenie retencji (opcjonalne): użytkownik wraca i powtarza akcję wartości w określonym oknie

Płatna konwersja wymaga dodatkowej uwagi. Zdecyduj, czy oznacza to „rozpoczęcie subskrypcji”, „pierwsza zapłacona faktura”, czy „trial zakończył się i automatycznie stał się płatny”. Jeśli oferujesz faktury, nieudane płatności i okresy karencji mogą utrudnić definicję „konwersji”, więc wybierz definicję zgodną z tym, jak rzeczywiście rozpoznawany jest przychód.

Wydarzenia opcjonalne mogą pomóc diagnozować odpływy bez zamieniania trackera w chaos. Typowe przykłady: ukończenie onboardingu, zaproszenie współpracownika, podłączenie integracji, utworzenie pierwszego projektu lub dodanie danych rozliczeniowych.

Na przykład w narzędziu takim jak AppMaster aktywacja może być „opublikowano pierwszą działającą aplikację” albo „wdrożono endpoint”, a zdarzenia opcjonalne to „podłączono PostgreSQL” lub „utworzono pierwszy proces biznesowy”. Dokładne sformułowanie ma mniejsze znaczenie niż konsekwencja.

Kiedy definicje pozostają stabilne, trendy stają się wiarygodne. Kiedy nie, ludzie dyskutują o liczbach zamiast naprawiać lejek.

Wybierz dane, których potrzebujesz (trzymaj minimalizm)

Tracker jest użyteczny tylko wtedy, gdy mu ufasz i możesz go aktualizować. Najszybszy sposób, by utracić oba te warunki, to zbierać zbyt wiele za wcześnie. Zacznij od niewielkiego zestawu pól, które odpowiadają na jedno tygodniowe pytanie: gdzie ludzie odpływają między signupem, aktywacją a płatnością?

Praktyczne minimum dla większości produktów subskrypcyjnych:

• account_id (i user_id, jeśli produkt jest wieloużytkownikowy)
• timestamp (kiedy zdarzenie miało miejsce)
• event_name (signup, trial_started, activated, subscribed, canceled)
• plan (plan trialowy i płatny)
• source/channel (skąd pochodził signup)

Dodaj trochę metadanych trialu od początku, bo to zapobiega nieporozumieniom później. Jasne trial_start_date i trial_end_date ułatwiają oddzielenie „wciąż w trialu” od „nie przekonwertował”. Jeśli oferujesz różne długości trialu lub wstrzymane triale, dodaj trial_length_days lub trial_status, ale tylko jeśli naprawdę będziesz tego używać.

Bądź jasny co do śledzenia kont vs użytkowników. Zwykle konto płaci, a użytkownik aktywuje. Jedna osoba może utworzyć konto, trzech współpracowników może się zalogować, a tylko jeden podłączyć kluczową integrację. W takim przypadku konwersję powiąż z account_id, a aktywację z pierwszym użytkownikiem, który wykonał kluczową akcję. Przechowywanie obu ID pozwala odpowiedzieć na pytanie „czy to konto się aktywowało?” i „kto to zrobił?” bez zgadywania.

Segmentacja pomaga tylko wtedy, gdy będziesz jej używać. Wybierz kilka pól, które spodziewasz się sprawdzać tygodniowo, jak wielkość firmy, główny przypadek użycia, region/strefa czasowa czy kampania pozyskania (jeśli prowadzisz kampanie).

Jeśli budujesz w AppMaster, ta sama zasada: zdefiniuj tylko tabele i rekordy zdarzeń, których potrzebujesz teraz, a rozszerzaj gdy cotygodniowy przegląd pokaże realne pytanie, na które nie potrafisz odpowiedzieć.

Zbierz dane w jednym miejscu bez overengineerowania

Tracker działa, gdy ludzie ufają źródłu liczb. Najprostsza zasada: wybierz jedno źródło prawdy dla każdego zdarzenia i nie miksuj źródeł dla tego samego zdarzenia.

Na przykład:

• Traktuj signup jako moment utworzenia rekordu użytkownika w bazie danych aplikacji.
• Traktuj aktywację jako moment, w którym produkt zapisuje pierwsze ukończone kluczowe działanie.
• Traktuj płatną konwersję jako moment, w którym system rozliczeniowy potwierdza udaną pierwszą transakcję (często Stripe).

Duplikaty są normalne, więc ustal reguły rozstrzygające z wyprzedzeniem. Ludzie mogą zapisać się dwukrotnie, ponownie przechodzić onboarding albo wywołać to samo zdarzenie na wielu urządzeniach. Praktyczne podejście: deduplikuj po stabilnym identyfikatorze (user_id jeśli jest, w przeciwnym razie email), zachowaj najwcześniejszy timestamp signupu i pierwszą kwalifikującą aktywację. Dla płatności zachowaj pierwszą udaną płatność na klienta.

Czas może podstępnie zepsuć tracker. Wyrównaj znaczniki czasu do jednej strefy czasowej (zwykle UTC) zanim policzysz „dzień 0”, „dzień 1” i kohorty tygodniowe. Przechowuj timestampy z tą samą precyzją (sekundy wystarczą) i trzymaj zarówno surowy czas zdarzenia, jak i znormalizowaną datę, by tabele były czytelne.

Aby utrzymać niski wysiłek, zacznij od dziennego rytmu. Prosty dzienny eksport lub zaplanowane zadanie wystarczy dla większości zespołów, pod warunkiem że jest konsekwentne.

Minimalne, ale niezawodne ustawienie:

• Jedna tabela (lub arkusz) z kolumnami: user_id, signup_at, activated_at, paid_at, plan, source.
• Dzienna praca, która dopisuje nowych użytkowników i uzupełnia brakujące timestampy (nigdy nie nadpisując wcześniejszych).
• Mała tabela mapująca znane duplikaty (scalone konta, zmienione emaile).
• Jedna reguła strefy czasowej (UTC) stosowana przed zapisaniem.
• Podstawowa kontrola dostępu i redakcja pól wrażliwych.

Podstawy prywatności: nie przechowuj surowych treści wiadomości, danych płatniczych czy payloadów API w trackerze. Trzymaj tylko to, co potrzebne do zliczeń i czasu zdarzeń, i ogranicz dostęp do osób, które naprawdę korzystają z liczb.

Jeśli budujesz produkt w AppMaster, często najprościej pobrać signup i aktywację z bazy aplikacji, a płatność z Stripe, a potem połączyć je raz dziennie w tabeli trackera.

Krok po kroku: zbuduj podstawowe metryki lejka

Zbuduj tracker w takiej samej kolejności, w jakiej użytkownik doświadcza produktu.

Zacznij od prostej tabeli, gdzie każdy wiersz to okres (dzienny lub tygodniowy) oparty na dacie rozpoczęcia trialu. To będzie mianownik dla wszystkiego.

1. Policz starty triali na okres. Użyj jednej jasnej reguły, np. „pierwszy raz użytkownik zaczyna trial”, żeby nie policzyć ponownie re-subskrybentów.

2. Dodaj aktywacje w oknie trialu. Aktywacja to jedno znaczące działanie (nie tylko zalogowanie). Połącz aktywowanych użytkowników z okresem startu trialu, do którego należą. Pytanie brzmi: „Ilu z osób, które zaczęły trial w Tygodniu X, aktywowało się w ciągu 7 dni?”

3. Dodaj płatne konwersje w spójnym oknie. Wiele zespołów używa długości trialu plus mały okres karencji (np. trial 14 dni + 3 dni), żeby złapać opóźnione płatności i ponowne próby rozliczeń. Powiąż konwersję z oryginalnym okresem startu trialu.

Mając te trzy liczby (starty, aktywacje, płatne), oblicz podstawowe wskaźniki:

• Współczynnik od startu trialu do aktywacji
• Współczynnik od aktywacji do płatności
• Współczynnik od startu trialu do płatności (ogólna konwersja)

Dodawaj rozbicia ostrożnie. Wybieraj jedną wymiarowość naraz (kanał lub plan). Jeśli kroisz po zbyt wielu wymiarach naraz, dostaniesz malutkie grupy, które wyglądają jak „wnioski”, ale są głównie szumem.

Praktyczny układ to:

Okres | Starty triali | Aktywowane w oknie | Płatne w oknie | Start->Aktywacja | Aktywacja->Płatne | Start->Płatne

Możesz to zbudować w arkuszu kalkulacyjnym lub w narzędziu no-code/database z pulpitami, jeśli chcesz automatycznych aktualizacji (np. w AppMaster obok zdarzeń aplikacji).

Zbuduj prostą tabelę kohort, żeby zobaczyć etapy odpływu

Suma lejka może wyglądać dobrze, podczas gdy nowi użytkownicy mają problemy. Tabela kohort rozwiązuje to, ustawiając obok siebie grupy triali, które zaczęły w tym samym czasie, żeby zobaczyć, gdzie każda grupa utknęła.

Zacznij od jednego klucza kohorty. „Tydzień startu trialu” zwykle jest najprostszy, bo daje wystarczającą liczbę próbek na wiersz i pasuje do tygodniowych cykli wydań i kampanii.

Mała tabela kohort, która pozostaje czytelna

Trzymaj kolumny nieliczne i spójne. Jeden wiersz na kohortę, potem krótki zestaw liczb i procentów odpowiadających etapom lejka.

Liczby pokazują skalę. Procenty umożliwiają porównanie kohort, nawet jeśli jeden tydzień miał większą kampanię.

Jeśli możesz, dodaj dwie kolumny czasu jako mediany (mediany są stabilne, gdy kilku użytkowników zajmuje dużo więcej czasu):

• Mediana dni do aktywacji
• Mediana dni do płatności

Czas często wyjaśnia, dlaczego konwersje spadają. Kohorta z tym samym % płatnych, ale dużo dłuższym czasem do aktywacji może oznaczać, że onboarding jest mylący, a nie że oferta jest słaba.

Jak rozpoznać, gdzie występuje odpływ

Szukaj wzorców w wierszach:

• Jeśli % Aktywowanych nagle spada, a % Płatnych pozostaje podobne, to prawdopodobnie zmienił się onboarding lub doświadczenie pierwszego uruchomienia.
• Jeśli % Aktywowanych pozostaje stabilne, a % Płatnych spada, problem jest prawdopodobnie przy kroku upgrade (strona z cenami, paywall, dopasowanie planu).

Gdy tabela zaczyna się rozrastać, powstrzymaj się przed dodawaniem kolejnych kolumn. Mniej kolumn jest lepsze niż szeroka siatka, której przestajesz czytać. Głębsze cięcia (typ planu, kanał, persona) zostaw na drugą tabelę, gdy podstawowa historia będzie jasna.

Realistyczny przykład: gdzie trial zawodzi

Wyobraź sobie narzędzie raportujące B2B z 14-dniowym trialem. Pozyskujesz triale z dwóch kanałów: Kanał A (reklamy wyszukiwania) i Kanał B (polecenia partnerów). Sprzedajesz dwa plany: Basic i Pro.

Śledzisz trzy checkpointy: Signup, Aktywacja (pierwszy dashboard utworzony) i Płatne (pierwsza udana transakcja).

Tydzień 1 wygląda świetnie na pierwszy rzut oka: signupy skaczą z 120 do 200 po zwiększeniu wydatków na Kanał A. Ale aktywacja spada z 60% do 35%. To wskazówka. Nie dostałeś "gorszych użytkowników", zmienił się miks i nowi użytkownicy zatrzymują się wcześnie.

Segmentacja po kanałach pokazuje wzorzec:

• Kanał A aktywuje wolniej niż Kanał B (wielu użytkowników nadal nieaktywnych po 3 dniach)
• Kanał B pozostaje stabilny (współczynnik aktywacji prawie nie zmienia się)

Przeglądasz onboarding i znajdujesz nowy krok dodany w zeszłym tygodniu: użytkownicy muszą podłączyć źródło danych, zanim zobaczą przykładowy dashboard. Dla użytkowników z Kanału A (którzy często chcą szybkiego wglądu) ten krok staje się zaporą.

Wykonujesz małą zmianę: pozwalasz na wstępnie załadowany demo dataset, tak żeby użytkownik mógł stworzyć pierwszy dashboard w 2 minuty. Następny tydzień pokazuje wzrost aktywacji z 35% do 52% bez zmiany marketingu.

Przenieśmy to na odwrotną sytuację: aktywacja jest zdrowa (55–60%), ale konwersja płatna słaba (tylko 6% aktywowanych kupuje). Kolejne kroki są inne:

• Sprawdź, czy funkcje Pro są zbyt mocno zablokowane w trialu
• Wyślij jedno jasne przypomnienie o „momencie wartości” w dniu 2–3
• Porównaj konwersję płatną dla Basic vs Pro
• Sprawdź tarcia związane z cenami lub zakupem (faktury, zatwierdzenia)

Rosnące signupy mogą ukrywać zepsute pierwsze doświadczenie. Kohorty i lekkie segmentowanie pomagają zobaczyć, czy naprawa należy w onboarding, dostarczaniu wartości, czy w kroku zakupu.

Typowe błędy, które maskują prawdziwy odpływ

Większość problemów z trackingiem to nie problemy matematyczne, tylko definicyjne. Tracker może wyglądać czysto, a jednocześnie mieszać różne zachowania, przez co odpływ pojawia się w złym miejscu.

Jedna pułapka to uznawanie kogoś za „aktywowanego” po powierzchownym działaniu, jak „zalogował się raz”. Loginy to często ciekawość, nie wartość. Aktywacja powinna oznaczać osiągnięcie prawdziwego rezultatu, jak import danych, zaproszenie współpracownika czy ukończenie głównego workflow.

Inna pułapka to mieszanie poziomów. Aktywacja bywa działaniem użytkownika, ale płatność zwykle na poziomie konta lub workspace. Jeśli jeden współpracownik aktywuje, a inna osoba dokonuje upgrade, możesz przez pomyłkę oznaczyć to samo konto jako aktywowane lub nieaktywowane, w zależności od sposobu łączenia tabel.

Późne upgrade'y są też łatwe do błędnej interpretacji. Ludzie czasem płacą po zakończeniu trialu, bo byli zajęci, potrzebowali zatwierdzeń lub czekali na demo. Licz je, ale oznacz jako „konwersja po trialu”, żeby nie zawyżać współczynnika konwersji z trialu.

Uważaj na te pułapki:

• Traktowanie „pierwszego logowania” jako aktywacji zamiast znaczącego etapu
• Łączenie zdarzeń użytkownika z płatnościami konta bez jasnej reguły
• Liczenie upgrade'ów po oknie trialu bez ich oddzielania
• Zmiana reguł zdarzeń w połowie miesiąca i porównywanie tygodni jakby nic się nie zmieniło
• Używanie jednej średniej konwersji, gdy onboardowanie, ceny lub źródła ruchu się zmieniły

Szybki przykład: zespół zmienia aktywację z „utworzono projekt” na „opublikowano projekt” w połowie miesiąca. Konwersja nagle wygląda gorzej, więc panikują. W rzeczywistości poprzeczka się podniosła. Zamrażaj definicje na okres analizy lub uzupełnij dane według nowej reguły przed porównaniami.

Na koniec, nie polegaj na średnich, gdy zachowania zmieniają się w czasie. Kohorty pokażą, czy nowsze triale odpływają wcześniej, nawet jeśli ogólna średnia wydaje się stabilna.

Szybkie kontrole zanim zaufasz liczbom

Tracker jest użyteczny tylko wtedy, gdy wejścia są czyste. Zanim zaczniesz dyskutować o współczynniku konwersji, przeprowadź kilka kontroli zdrowia danych.

Zacznij od pojednania sum. Wybierz krótki zakres dat (np. zeszły tydzień) i porównaj liczbę „rozpoczętych triali” z tym, co pokazuje billing, CRM lub baza produktu dla tych samych dat. Jeśli różnica to nawet 2–5%, zatrzymaj się i znajdź przyczynę (brakujące zdarzenia, przesunięcia stref czasowych, filtry lub konta testowe).

Potem potwierdź, czy linia czasu ma sens. Aktywacja nie powinna wystąpić przed signupem. Jeśli tak się dzieje, zwykle masz jeden z trzech problemów: zegary w różnych systemach różnią się, zdarzenia przychodzą z opóźnieniem, albo używasz „konto utworzone” w jednym miejscu i „trial rozpoczęty” w innym.

Pięć kontroli, które łapią większość problemów:

• Porównaj liczbę triali z drugim źródłem (billing lub baza produktu) dla tej samej daty i strefy czasowej.
• Zweryfikuj kolejność timestampów: signup -> aktywacja -> płatność. Oznacz wiersze poza kolejnością.
• Obsłuż duplikaty: zdecyduj, czy deduplikujesz po user, account, email czy workspace i stosuj to wszędzie.
• Zablokuj regułę okna konwersji (np. „płatne w ciągu 14 dni od signupu”) i udokumentuj ją, żeby nie zmieniała się cicho.
• Ręcznie prześledź jedną kohortę end-to-end: wybierz 10 signupów z jednego dnia i potwierdź każdy etap w surowych rekordach.

Ten ręczny ślad często jest najszybszym sposobem znalezienia ukrytych braków. Na przykład możesz odkryć, że aktywacja jest logowana tylko na webie, więc użytkownicy mobilni nigdy „nie aktywują się” w danych, nawet jeśli są aktywni. Albo znajdziesz, że upgrade'y po trialu są liczone w billing, ale nie pojawiają się w zdarzeniach produktowych.

Gdy te kontrole przejdą pomyślnie, twoje rachunki lejka staną się nudne w dobry sposób. Wtedy wzorce odpływu są prawdziwe, a naprawy oparte na prawdzie, a nie szumie trackingowym.

Przekształcanie insightów z lejka w proste poprawki i eksperymenty

Tracker ma znaczenie tylko wtedy, gdy zmienia twoje działania. Wybierz jeden etap odpływu, wprowadź jedną zmianę i mierz jedną liczbę.

Gdy od startu trialu do aktywacji jest słabo, zakładaj, że pierwsze uruchomienie jest zbyt obciążające. Ludzie nie chcą funkcji — chcą szybkiego sukcesu. Skróć kroki, usuń wybory i poprowadź ich do pierwszego rezultatu.

Jeśli aktywacja jest wysoka, ale płatność niska, trial generuje aktywność bez osiągania prawdziwego momentu wartości. Przesuń paywall bliżej momentu, gdy użytkownik czuje korzyść, albo spraw, by ten moment nastąpił szybciej. Paywall pokazany przed dostarczeniem wartości wygląda jak podatek.

Gdy płatność się opóźnia, szukaj tarć: przypomnienia, które nie dochodzą, kroki płatności, które powodują odpływ, lub zatwierdzenia, które spowalniają zespoły. Często naprawa to prostszy checkout z mniejszą liczbą pól albo jedno dobrze wyczesane przypomnienie.

Prosty rytuał eksperymentu:

• Wybierz jeden etap do poprawy (współczynnik aktywacji, konwersja trialu lub czas do płatności)
• Opisz jedną zmianę, którą wypuścisz w tym tygodniu
• Wybierz jedną metrykę sukcesu i jedną metrykę „nie szkodzi”
• Zdecyduj okno pomiarowe (np. 7 dni nowych triali)
• Wypuść, zmierz, a potem utrzymaj lub wycofaj

Zapisz spodziewany wpływ przed startem. Przykład: „Checklist onboardingu podniesie aktywację z 25% do 35%, bez zmiany w wolumenie signupów.” To ułatwia interpretację wyników później.

Realistyczny scenariusz: tabela kohort pokazuje, że większość użytkowników odpływa między signupem a utworzeniem pierwszego projektu. Testujesz krótszą konfigurację: automatycznie tworzysz przykładowy projekt i wyróżniasz jeden przycisk akcji. Jeśli budujesz produkt lub narzędzia administracyjne w AppMaster, takie zmiany (i zdarzenia posłużone do ich śledzenia) można szybko dostosować, bo logika aplikacji i model danych żyją w jednym miejscu.

Następne kroki: utrzymuj prostotę, potem zautomatyzuj tracker

Tracker działa, gdy ktoś traktuje go jak narzędzie żywe, a nie jednorazowy raport. Wybierz jednego właściciela (często product ops, growth lub PM) i utrzymaj prosty tygodniowy rytm. Cel przeglądu to nazwać jeden etap, który się zmienił, a potem zdecydować, co przetestujecie dalej.

Lekka organizacja operacyjna zwykle wystarcza:

• Wyznacz właściciela i zastępcę, z 15–30 minutowym cotygodniowym przeglądem.
• Zapewnij definicje zdarzeń w prostym języku (co się liczy, a co nie).
• Prowadź changelog zmian definicji i dat startów eksperymentów.
• Ustal jedną tabelę/arkusz źródłowy, żeby ludzie przestali kopiować liczby.
• Zdecyduj, kto może edytować definicje (mniej osób niż myślisz).

Gdy pytania przychodzą ze wsparcia, sprzedaży lub ops, nie wysyłaj surowych eksportów. Daj ludziom mały wewnętrzny widok odpowiadający na powtarzające się pytania: „Ile triali zaczęło się w tym tygodniu?”, „Ilu aktywowało się w ciągu 24 godzin?”, „Która kohorta konwertuje gorzej niż w zeszłym miesiącu?” Prosty dashboard z kilkoma filtrami (data, plan, kanał) zwykle wystarcza.

Jeśli chcesz automatyzacji bez wielkiego projektu inżynierskiego, możesz zbudować tracker i wewnętrzny panel admina w AppMaster: zaprojektuj bazę w Data Designerze, dodaj reguły w Business Process Editor i stwórz webowe UI dla tabeli kohort i metryk lejka bez pisania kodu.

Zachowaj wersję 1 celowo małą. Zacznij od trzech zdarzeń i jednej tabeli kohort:

• Rozpoczęto trial
• Aktywacja (twoje najlepsze pojedyncze działanie „aha”)
• Płatna konwersja

Gdy te liczby są stabilne i zaufane, dodawaj szczegóły (typ planu, kanał, warianty aktywacji) po jednym elemencie. Dzięki temu tracker jest użyteczny teraz i daje miejsce do rozwoju.