Zadanie w jednym zdaniu
Data Analyst w zespole growth odpowiada na pytanie, przy którym reszta zespołu ciągle zgaduje: czy to działa i dlaczego. Odpowiada za metryki, buduje raporty i czyta dane tak, jak nawigator czyta mapę – nie dla samej lektury, ale żeby wskazać zespołowi kierunek. W zespole growth pracuje na końcu łańcucha, za każdą inną rolą: Growth Engineer wdraża śledzenie zdarzeń, a analityk zamienia je w dowody.
Retencja to metryka, na której opiera się wszystko
Pierwszym zadaniem analityka jest zwykle krzywa retencji, bo retencja to podłoga, na której stoi każda inna liczba. Brian Balfour i zespół Reforge przekonują, że słaba retencja po cichu ogranicza pozyskanie i monetyzację, bez względu na to, jak dobrze te wyglądają. Analityk buduje widok kohortowy – jaki odsetek każdej kohorty rejestracji jest wciąż aktywny w 1., 7. i 30. dniu – i obserwuje, czy krzywa się wypłaszcza. Wypłaszczająca się krzywa oznacza, że produkt ma rdzeń użytkowników, których zatrzymuje; krzywa spadająca do zera oznacza, że na razie nie ma biznesu do skalowania.
Od danych do decyzji
Surowe zdarzenia to jeszcze nie wnioski. Analityk precyzyjnie definiuje każdą metrykę – co liczy się jako aktywność, gdzie lejek się zaczyna i kończy, który churn jest dobrowolny – żeby zespół spierał się o decyzję, a nie o definicję. Potem buduje cotygodniowy raport, który Growth PM i Growth Lead czytają, ustalając roadmapę: kohorta, która rośnie najszybciej, krok lejka, który przecieka, churn, który prawdopodobnie przyniesie następny miesiąc. Wynikiem nie jest dashboard. To rekomendacja, za którą stoi liczba.
Sygnał a szum
Większość metryk, które się ruszają, nie ma znaczenia. Dobry analityk poświęca tyle samo czasu na eliminowanie metryk próżności (vanity metrics), co na budowanie prawdziwych – łączna liczba rejestracji dobrze wygląda i niczego nie przewiduje; aktywację i retencję trudniej ruszyć, ale przewidują niemal wszystko. Dyscyplina, której uczą zespoły takie jak Amplitude i Reforge, polega na znalezieniu wskaźnika wyprzedzającego, który faktycznie prognozuje interesujący Cię wynik, i zignorowaniu reszty szumu wypełniającego typowy dashboard.
Jak ta rola zwykle wygląda w praktyce
W małym zespole rzadko jest osobny analityk – ta praca spada na tego, kto najswobodniej czuje się w SQL-u, często na założyciela o 23:00. W większym zespole to growth analyst albo data scientist osadzony w funkcji growth, w odróżnieniu od analityka business intelligence, który raportuje o firmie jako całości. Nazwy stanowisk bywają różne; stałe jest jedno: zdefiniować metryki, zbudować raporty i oddzielić sygnał od szumu, żeby zespół stawiał na dowody.
Gdzie AI przyspiesza analizę
Pobieranie danych i robienie wykresów przyspiesza; definicje i ostateczna decyzja – nie. We fromHello surowy materiał analityka jest w jednym miejscu: zdarzenia first-party, profile, segmenty w czasie rzeczywistym oraz wyniki ścieżek i wiadomości, z wbudowanymi lejkami i analityką. Przez serwer MCP klient AI, którego już używasz, np. Claude albo Cursor, może na żądanie pobrać krzywą retencji w podziale na dni, pokazać, które segmenty rosną, a które się kurczą, i odczytać wyniki ścieżek i szablonów. To narzędzia do odczytu, żadne narzędzie AI nie wysyła wiadomości, a wywołania narzędzi MCP są zapisywane w Twoim dzienniku audytu. Nic we fromHello nie prognozuje churnu ani nie decyduje, która metryka ma znaczenie; ta ocena zostaje po stronie analityka. Żeby zestawić fromHello z pakietem, który znasz, zobacz fromHello vs HubSpot.