PostHog

Widzisz ruch na stronie, ale nadal nie wiesz, dlaczego użytkownicy przerywają rejestrację albo nie wracają do aplikacji? PostHog pozwala analizować konkretne działania, odtworzyć wybrane sesje i sprawdzić efekty zmian. Łączy analitykę produktu, nagrania sesji, eksperymenty i sterowanie dostępnością funkcji. Wspólny kontekst użytkownika ułatwia przejście od wykresu do sytuacji, która za nim stoi.

Najwięcej sensu ma tam, gdzie regularnie rozwijasz produkt: w aplikacji SaaS, sklepie internetowym, portalu klienta lub serwisie z procesem pozyskiwania zapytań. W Okinet możemy pomóc zaplanować pomiar, połączyć go z aplikacją i przygotować raporty odpowiadające na pytania Twojego zespołu. Punktem wyjścia jest decyzja, którą chcesz podjąć — na przykład wybór etapu rejestracji wymagającego poprawy.

Podstawą analizy są zdarzenia, czyli zarejestrowane działania: utworzenie konta, dodanie produktu do koszyka, opłacenie zamówienia lub uruchomienie konkretnej funkcji. Właściwości zdarzenia opisują kontekst, na przykład wariant planu czy typ urządzenia. Możesz porównywać grupy użytkowników i sprawdzać, jak zmienia się wykorzystanie produktu w czasie.

Autocapture ułatwia zbieranie obsługiwanych interakcji bez ręcznego opisywania każdego kliknięcia. Kluczowe zdarzenia biznesowe warto jednak zdefiniować świadomie. Kliknięcie „Zapłać” i potwierdzone opłacenie zamówienia to dwa różne momenty. Ten drugi najlepiej powiązać z wiarygodnym stanem po stronie systemu płatności lub aplikacji.

Przy wdrożeniu ustalamy nazwy zdarzeń, ich znaczenie oraz sposób identyfikacji użytkownika przed logowaniem i po nim. Sprawdzamy także duplikaty i ruch testowy. Taka organizacja pomiaru sprawia, że raporty pozostają zrozumiałe po kolejnych zmianach w serwisie.

Lejek pokazuje przejście przez ustaloną sekwencję zdarzeń. W sklepie może to być obejrzenie produktu, dodanie do koszyka, rozpoczęcie zamówienia i zakup. W aplikacji: rejestracja, konfiguracja konta i wykonanie pierwszego zadania. PostHog pozwala sprawdzić konwersję między etapami oraz czas potrzebny na ich ukończenie.

Podział wyników według urządzenia, źródła wizyty lub innej zebranej właściwości pomaga zawęzić problem. Jeżeli odpływ pojawia się głównie na telefonach, możesz przyjrzeć się mobilnemu formularzowi i odpowiadającym mu sesjom. Sam wykres pokazuje miejsce straty; przyczynę trzeba potwierdzić.

Ważne są definicje kroków, dopuszczalna kolejność i okno czasowe. Bez nich dwa raporty tego samego procesu mogą przedstawiać różne wyniki. Na poniższej ilustracji słupki odnoszą się do liczby osób z pierwszego etapu lejka.

Pozyskanie konta jest początkiem relacji z produktem. Raport retencji pokazuje, jaka część użytkowników wraca i wykonuje określone działanie w kolejnych okresach. Samodzielnie ustalasz zdarzenie początkowe i zdarzenie powrotu: może to być pierwsze utworzenie projektu i późniejsze korzystanie z niego.

Kohorty pozwalają analizować grupy o wspólnej cesze lub zachowaniu. Możesz porównać osoby, które przeszły onboarding, z tymi, które go przerwały. Taka różnica jest wskazówką do dalszej analizy, a nie automatycznym dowodem, że onboarding spowodował poprawę.

Tabelę czytaj z uwzględnieniem wieku grup. Użytkownicy pozyskani w zeszłym tygodniu nie mają jeszcze historii sześciu tygodni. Niepełnych okresów nie należy porównywać wprost z zakończonymi. Na ilustracji każdy wiersz obejmuje grupę z innego tygodnia, a kolumny pokazują kolejne okresy od rozpoczęcia obserwacji.

Nagrania sesji pomagają zrozumieć sytuacje, których nie wyjaśnia sam wskaźnik konwersji. Możesz zobaczyć kolejne ekrany, kliknięcia i reakcje interfejsu, a następnie zestawić je ze zdarzeniami. To przydatne przy szukaniu problemów z formularzem, nawigacją lub wdrożoną funkcją.

Session Replay odtwarza zarejestrowany stan i zmiany interfejsu; nie jest filmem z całego komputera użytkownika. Zakres danych zależy od konfiguracji. Przy odpowiednim wdrożeniu dostępny jest również kontekst techniczny, taki jak błędy czy informacje z konsoli.

Zamiast oglądać przypadkowe sesje, warto zacząć od konkretnego segmentu: osób, które utknęły na określonym kroku, lub sesji związanych z błędem. Dobór próby i zasad nagrywania ogranicza ilość materiału, który zespół musi przejrzeć.

Feature flag to przełącznik, który aplikacja sprawdza przed udostępnieniem określonej funkcji lub wariantu. Po przygotowaniu tej obsługi w kodzie możesz zmieniać dostępność funkcji z poziomu PostHog. Pozwala to oddzielić wdrożenie kodu od momentu pokazania zmiany użytkownikom.

Nowy proces zamówienia możesz najpierw udostępnić zespołowi, następnie wybranej grupie i dopiero później szerszemu gronu. Warunki mogą uwzględniać właściwości użytkownika oraz procent grupy. W przykładzie producenta reguła łączy okres próbny, kraj i udział użytkowników objętych zmianą.

Przełącznik wymaga zaplanowania zachowania domyślnego, także wtedy, gdy aplikacja nie może pobrać jego wartości. Nie zastępuje kontroli uprawnień po stronie serwera. Po zakończeniu wdrożenia warto usunąć niepotrzebne flagi i związane z nimi rozgałęzienia kodu.

PostHog Experiments pozwala porównywać warianty produktu na podstawie zdefiniowanych metryk. Możesz sprawdzić, czy krótszy formularz wpływa na ukończenie rejestracji albo czy nowy onboarding pomaga uruchomić pierwszą funkcję. Feature flags służą do udostępniania wariantów, a pomiar zdarzeń dostarcza danych do oceny.

Przed startem ustalasz hipotezę, grupę odbiorców, główną metrykę i wskaźniki, których nie chcesz pogorszyć. Więcej wysłanych formularzy nie musi oznaczać większej liczby wartościowych zapytań. Warto więc uwzględnić także dalszy etap procesu.

Wiarygodna interpretacja wymaga odpowiedniej liczby obserwacji i czasu. Przy niewielkim ruchu wynik może długo pozostawać niejednoznaczny. Eksperyment dostarcza podstaw do decyzji, ale nie gwarantuje znalezienia lepszego wariantu.

Ankiety w produkcie pozwalają zebrać odpowiedzi w kontekście korzystania z aplikacji. Po ukończeniu procesu możesz zapytać o trudność zadania, a po użyciu nowej funkcji — o jej przydatność. Krótkie pytanie związane z konkretnym momentem zwykle daje zespołowi bardziej użyteczny materiał niż ogólna prośba o opinię.

Web Analytics uzupełnia ten obraz o ruch w serwisie: odwiedzane strony, źródła wizyt i kontekst kampanii. Dzięki temu możesz zacząć od tego, skąd przychodzą odbiorcy, a następnie analizować ich dalsze działania. Zakres obu modułów dobierasz do potrzeb — nie musisz uruchamiać wszystkich funkcji platformy naraz.

Error Tracking zbiera i grupuje błędy aplikacji, pomagając ograniczyć powtarzające się zgłoszenia do problemów wymagających diagnozy. Powiązanie błędu z użytkownikiem i dostępnym nagraniem sesji daje zespołowi kontekst: co działo się przed awarią i jaki proces został przerwany.

To ułatwia ustalanie priorytetów. Błąd blokujący zakup może wymagać innej reakcji niż problem występujący w rzadko używanym widoku. Wdrożenie powinno obejmować kontrolę przesyłanych danych i weryfikację, czy raport pozwala faktycznie odnaleźć źródło problemu w kodzie.

Analityka zachowania zyskuje dodatkową wartość po zestawieniu z płatnościami, subskrypcjami lub informacjami z innych systemów. Moduł Data Warehouse pozwala podłączać obsługiwane źródła i analizować dane, także za pomocą SQL. Możesz dzięki temu szukać zależności między korzystaniem z funkcji a utrzymaniem płatnej subskrypcji.

Takie połączenie wymaga spójnych identyfikatorów i uzgodnienia znaczenia metryk. Data rejestracji, rozpoczęcie okresu próbnego i pierwsza płatność opisują różne momenty. Najpierw porządkujemy te definicje, a następnie budujemy raport. Sama obecność danych w jednym narzędziu nie rozwiązuje rozbieżności między systemami.

Jeżeli aplikacja korzysta z modeli językowych, PostHog może pomóc obserwować wywołania, czasy odpowiedzi, zużycie tokenów i koszty. Dostępny kontekst wywołań i śladów wykonania ułatwia analizę bardziej złożonych przepływów, na przykład asystenta korzystającego z narzędzi.

Możesz sprawdzić, które zadania generują największy koszt i gdzie użytkownik czeka najdłużej. Taki monitoring nie przesądza jednak o poprawności odpowiedzi modelu. Jakość wymaga osobnej oceny. Przed zbieraniem treści zapytań i odpowiedzi trzeba również określić, które informacje mają być pomijane lub maskowane.

Zakres pomiaru planujemy razem z zakresem produktu. Przy Session Replay szczególnie ważne jest maskowanie pól i treści, które nie powinny opuszczać przeglądarki. Osobno trzeba przejrzeć właściwości zdarzeń, adresy URL oraz inne zbierane dane — maskowanie nagrania nie zastępuje kontroli całej integracji.

PostHog udostępnia chmurę w regionie UE. Wybór regionu jest jednym z elementów organizacji przetwarzania danych; sam w sobie nie rozstrzyga obowiązków dotyczących zgód, informacji dla użytkownika czy zasad przechowywania. Konfigurację narzędzia trzeba dopasować do przyjętych w serwisie zasad.

Możliwe jest również samodzielne uruchomienie PostHog, ale producent opisuje self-hosting jako wariant bez oficjalnego wsparcia. Oznacza to odpowiedzialność za aktualizacje, bezpieczeństwo i utrzymanie infrastruktury. Wybierając tę drogę, trzeba ocenić dostępne funkcje oraz realny koszt opieki nad systemem.

Integracja powinna obejmować zarówno interfejs, jak i te zdarzenia biznesowe, których źródłem jest serwer. W projekcie opartym na Vue.js możemy zaplanować pomiar przejść i interakcji w aplikacji. W systemie korzystającym z PHP i Symfony — przekazywanie potwierdzonych zdarzeń procesu. Dla strony na WordPressie punktem wyjścia mogą być formularze i najważniejsze ścieżki kontaktu.

Zakres wdrożenia warto ułożyć etapami: najpierw pytania biznesowe i plan zdarzeń, następnie integracja, weryfikacja danych oraz kilka raportów. Dopiero po potwierdzeniu jakości pomiaru dokładamy nagrania, eksperymenty lub kolejne źródła. Sprawdzamy też wpływ skryptów na działanie strony.

Jeżeli korzystasz już z GA4, PostHog może działać obok niego. Najpierw ustalamy, które pytania ma obsługiwać każde narzędzie i jak interpretować różnice w wynikach. Różne reguły identyfikacji, filtry czy zakresy pomiaru mogą powodować, że liczby nie będą identyczne.

Oferta PostHog obejmuje bezpłatne limity i rozliczenia zależne od wykorzystania poszczególnych produktów. Koszt trzeba więc odnosić do planowanego wolumenu: zdarzeń, nagrań i pozostałych używanych funkcji. Aktualne stawki oraz warunki najlepiej sprawdzić w cenniku producenta.

Przy szacowaniu budżetu uwzględniamy także integrację, utrzymanie pomiaru i czas potrzebny na analizę. Ograniczenie zbędnych zdarzeń oraz rozsądny dobór nagrywanych sesji pomagają skupić zasoby na danych, z których rzeczywiście korzystasz.

Na początek często wystarczy jeden kluczowy proces, dobrze opisane zdarzenia i raport wskazujący problem do rozwiązania. Porozmawiajmy o pomiarze w Twojej stronie lub aplikacji — ustalimy, gdzie PostHog może pomóc i jaki zakres wdrożenia będzie uzasadniony.