Czym zajmuje się Growth Engineer?

Zadanie w jednym zdaniu

Growth Engineer to osoba, dzięki której growth da się zmierzyć. Opomiarowuje produkt tak, by każda istotna akcja stawała się zdarzeniem, prowadzi plan śledzenia, który konsekwentnie nazywa te zdarzenia, i naprawia wycieki w lejku, które odsłaniają dane. Wśród ośmiu ról stoi obok roli Growth PM: Growth PM decyduje, co testować, a Growth Engineer sprawia, że test da się zmierzyć. Ten kod służy eksperymentom, a nie roadmapie produktu.

Co Growth Engineer faktycznie dowozi

Większość tej pracy to infrastruktura, której reszta zespołu nigdy nie widzi. Według zespołu PostHog Growth Engineer to ktoś, kto pisze kod, żeby wpływać na metryki biznesowe, a nie żeby budować funkcje – szkielet testów A/B, poprawki w lejku, śledzenie, które mówi, czy cokolwiek zadziałało.

• Rozrysuj lejek – rejestracja, aktywacja, przejście na wyższy plan – i opomiaruj każdy krok, żeby odpływ był widoczny.
• Dodaj brakujące zdarzenie. Klasyczny przykład to subscription_started, którego nikt nie podłączył, więc przychód jest dla lejka niewidoczny.
• Zrób audyt planu śledzenia: usuń zduplikowane zdarzenia, popraw niespójne nazwy, opisz, co oznacza każda właściwość.
• Zbuduj narzędzia wewnętrzne i integracje – webhooki, synchronizacje, panele – dzięki którym inne role mogą działać na danych.

Plan śledzenia to główny rezultat

Wszystko dalej zależy od czystych zdarzeń. Amplitude nazywa taksonomię zdarzeń fundamentem dobrej analityki: spójna konwencja nazewnictwa, uzgodnione właściwości, jedno źródło prawdy. Segment opisuje plan śledzenia jako żywy dokument tego, co śledzisz i dlaczego. Zrób to dobrze, a profile, segmenty i ścieżki będą czytać z tego samego wiarygodnego strumienia. Zrób to źle, a każdy raport będzie po cichu kłamał.

Dlaczego ta rola zwielokrotnia efekty

Growth Engineer rzadko ma własną metrykę. Wynikiem tej pracy jest to, że zespół w ogóle może wpływać na metryki. Gdy Performance Marketer chce zsynchronizować segment o wysokim LTV z platformą reklamową albo Data Analyst potrzebuje raportu kohortowego, który nie opiera się na zgadywaniu, to Growth Engineer sprawia, że te dane istnieją i są wiarygodne. Opomiaruj raz, a każda rola czyta te same zdarzenia. Właśnie przez ten efekt mnożnikowy ta rola to coś więcej niż miły dodatek.

Growth Engineer a Product Engineer

Obie role piszą kod; różni je pytanie, na które odpowiadają. Product Engineer pyta, czy funkcja działa. Growth Engineer pyta, czy funkcja wpływa na liczby – i opomiarowuje produkt tak, żeby dało się to sprawdzić. Wdraża szybciej i mniej elegancko, bo poprawka śledzenia, która trafi na produkcję w przyszłym kwartale, to poprawka, z której niczego się nie dowiesz.

Co Growth Engineer robi z fromHello

Kod śledzący first-party fromHello sam zapisuje page_viewed i session_started, a także element_visible, kliknięcia, wysłania formularzy i głębokość przewijania, gdy ustawisz je jako wyzwalacze – bez kodu – a Twój kod wysyła zdarzenia, które mają znaczenie, takie jak subscription_started, z przeglądarki albo z Twojego backendu z kluczem API. Kod śledzący nie ładuje żadnych pikseli stron trzecich. Każde zdarzenie trafia do profilu danej osoby, segmenty dynamiczne przeliczają się przy każdym zdarzeniu, a ścieżki startują od zdarzeń: to opisana wyżej droga od zbierania do wyzwalacza w konkretnej postaci. Właściwości zdarzeń można mapować na profil, a krok Webhook łączy resztę Twojego stosu technologicznego. Przez serwer MCP fromHello klient AI, którego już używasz, np. Claude Code albo Cursor, może wyświetlić napływające zdarzenia i właściwości, zmapować właściwość na profil albo utworzyć segment; żadne narzędzie AI nie wysyła wiadomości. Żeby porównać to z narzędziem, które znasz, zobacz fromHello vs Customer.io.