PostHog, analityka produktu bez pięciu narzędzi

PostHog, czyli kilka narzędzi w jednym miejscu

Typowy zestaw narzędzi wokół produktu to analityka w jednym miejscu, nagrania sesji w drugim, przełączniki funkcji w trzecim i ankiety w czwartym. Cztery rachunki, cztery skrypty na stronie i cztery zbiory danych, których nie da się ze sobą zestawić.

PostHog łączy to w jedną platformę: analitykę zdarzeń, nagrania sesji, przełączniki funkcji, eksperymenty, ankiety, śledzenie błędów i hurtownię danych. Kod jest otwarty, więc można uruchomić go u siebie, choć większość zespołów korzysta z usługi zarządzanej.

Największa korzyść nie leży w liczbie funkcji, tylko w tym, że dane są wspólne. Zdarzenie analityczne, nagranie sesji i przypisanie do wariantu eksperymentu dotyczą tego samego użytkownika, więc od wykresu ze spadkiem konwersji przechodzisz jednym kliknięciem do nagrania osoby, która się poddała.

Darmowy próg i model rozliczeń

Zacznijmy od pieniędzy, bo tu decyzja zapada najczęściej i tu też najczęściej pojawia się niemiła niespodzianka.

Darmowy próg jest tu wyjątkowo szeroki jak na tę kategorię: około miliona zdarzeń analitycznych miesięcznie, kilka tysięcy nagrań sesji, milion zapytań o przełączniki funkcji i pula zdarzeń błędów. Nie ma ograniczenia czasowego ani limitu osób w zespole, więc mały produkt mieści się w nim latami.

Powyżej progu rozliczenie idzie za zużycie, bez stałego abonamentu. Stawka za zdarzenie maleje wraz z wolumenem, więc duże wdrożenie płaci wyraźnie mniej za jednostkę niż małe, a każdy produkt na platformie ma własny próg i własną stawkę.

Warto to policzyć na własnych liczbach przed wdrożeniem, bo różnica między szacunkiem a rachunkiem bierze się z rzeczy, które łatwo przeoczyć. Opisuję je w następnej sekcji, bo zasługują na osobne potraktowanie.

Trzy mnożniki, które psują szacunki

To jest najbardziej praktyczna część tego tekstu i rzecz, o której materiały producenta mówią mniej wyraźnie, niż powinny.

Pierwszy mnożnik to automatyczne zbieranie zdarzeń. Włączone domyślnie, rejestruje kliknięcia, wysyłki formularzy i odsłony bez pisania kodu, co jest świetne na start i kosztowne później. Jedna interakcja użytkownika potrafi wygenerować kilka zdarzeń, a przy śledzeniu przewijania liczba rośnie w sposób, którego nikt nie planował.

Drugi to zdarzenia przypisane do zidentyfikowanego użytkownika. Kosztują wielokrotnie więcej niż zdarzenia anonimowe, bo wymagają dodatkowego przetwarzania. Aplikacja, w której każdy użytkownik jest zalogowany, płaci więc znacznie więcej niż wynikałoby ze stawki podstawowej.

Trzeci to synchronizacja danych z systemów zewnętrznych do hurtowni, rozliczana za wiersz. Podłączenie systemu płatności albo systemu obsługi klienta wygląda niewinnie w konfiguracji, a potrafi dołożyć do rachunku pozycję porównywalną z całą resztą.

Te trzy rzeczy mnożą się przez siebie, a nie sumują, i to jest przyczyna historii o rachunkach kilkukrotnie wyższych od oczekiwanych. Dobra wiadomość jest taka, że wszystkie trzy są sterowalne, a każda z nich ma ustawienie, którym da się ją ograniczyć bez rezygnowania z narzędzia.

Limity wydatków, które warto ustawić od razu

Platforma pozwala ustawić miesięczny limit kwotowy osobno dla każdego produktu: analityki, nagrań sesji, przełączników funkcji i śledzenia błędów. Po przekroczeniu limitu przyjmowanie danych dla tego produktu zatrzymuje się do końca okresu.

To jest pierwsza rzecz do zrobienia po założeniu konta, przed napisaniem pierwszej linii kodu. Limit ustawiony na wartość, którą jesteś gotów zapłacić, zamienia ryzyko nieprzewidzianego rachunku w ryzyko utraty części danych, a to znacznie łagodniejszy problem.

Drugie zabezpieczenie to ograniczenie automatycznego zbierania zdarzeń. Da się wyłączyć je całkowicie i wysyłać wyłącznie zdarzenia zdefiniowane przez Ciebie, albo zawęzić do wybranych elementów strony.

import posthog from 'posthog-js'

posthog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY, {
  api_host: 'https://eu.i.posthog.com',
  autocapture: false,
  capture_pageview: false,
  session_recording: { maskAllInputs: true }
})

posthog.capture('zamowienie_zlozone', {
  wartosc: 249.99,
  liczba_pozycji: 3
})

Wyłączenie automatycznego zbierania i wysyłanie kilkunastu nazwanych zdarzeń daje zwykle lepszą analitykę niż tysiąc zdarzeń zebranych samoczynnie. Nazwane zdarzenie odpowiada krokowi w procesie, który Cię interesuje, a kliknięcie w losowy przycisk nie odpowiada niczemu.

Trzecie to próbkowanie nagrań sesji. Nagrywanie każdej sesji rzadko ma sens, bo i tak obejrzysz kilkanaście. Nagrywanie części ruchu albo wyłącznie sesji spełniających warunek, na przykład zakończonych błędem, daje ten sam wgląd za ułamek ceny.

Czwarte, przydatne przy większej skali, to przeniesienie części sygnałów do narzędzi, które robią to taniej. Śledzenie awarii aplikacji dobrze wypada w Sentry, a podstawowe statystyki ruchu obsłuży dowolne lekkie narzędzie analityczne. Zostawienie tu wyłącznie tego, co korzysta ze wspólnych danych, czyli zdarzeń produktowych, nagrań i eksperymentów, bywa tańsze niż wysyłanie wszystkiego w jedno miejsce.

Przełączniki funkcji i eksperymenty

To część, w której platforma zastępuje osobne, zwykle drogie narzędzie, i robi to dobrze.

if (posthog.isFeatureEnabled('nowy-koszyk')) {
  return <NowyKoszyk />
}
return <StaryKoszyk />

Przełącznik pozwala wdrożyć kod na produkcję z funkcją wyłączoną, a potem włączyć ją dla części użytkowników. To oddziela wdrożenie od udostępnienia, co jest jedną z tych zmian w procesie, które po roku wydają się oczywiste.

Eksperyment to przełącznik z przypisaniem do wariantu i pomiarem wyniku. Definiujesz metrykę, platforma dzieli ruch i liczy istotność statystyczną, więc nie musisz robić tego w arkuszu.

Dwie rzeczy warto wiedzieć przed pierwszym eksperymentem. Pierwsza to konieczność ustalenia metryki przed startem, a nie po obejrzeniu wyników, bo szukanie metryki, która wyszła korzystnie, jest sposobem na potwierdzenie dowolnej tezy. Druga to czas trwania: eksperyment przerwany po dwóch dniach, bo wariant wygrywał, zwykle mierzy nowość, a nie wartość.

Zapytania o przełączniki też są rozliczane, więc odpytywanie ich w pętli renderowania to koszt, który da się usunąć jednym wywołaniem na sesję. Po stronie serwera przełączniki odczytujesz przez wywołanie asynchroniczne z jawnym identyfikatorem użytkownika.

import { PostHog } from 'posthog-node'

const posthog = new PostHog(process.env.POSTHOG_KEY!, {
  host: 'https://eu.i.posthog.com',
  flushAt: 20,
  flushInterval: 10_000
})

const wlaczony = await posthog.isFeatureEnabled('nowy-koszyk', uzytkownik.id)

Dwa ustawienia w konstruktorze decydują o rachunku i o wydajności. Pierwsze mówi, po ilu zdarzeniach wysłać paczkę, drugie po jakim czasie wysłać ją mimo niepełnej paczki. Wartości domyślne są bezpieczne, ale w procesie krótkotrwałym, na przykład w funkcji bezserwerowej, trzeba pamiętać o jawnym opróżnieniu bufora przed zakończeniem, inaczej zdarzenia przepadną.

await posthog.shutdown()

Warto również zaplanować, co się dzieje, gdy odpowiedź o stan przełącznika nie dotrze. Blokada reklam, wolna sieć albo awaria usługi sprawiają, że wartość jest nieznana, a kod zakładający domyślne włączenie pokaże wtedy część użytkowników funkcję, której nie miała zobaczyć. Domyślna wartość wyłączona i renderowanie starego wariantu do czasu odpowiedzi jest tu bezpieczniejszym ustawieniem.

const stan = posthog.isFeatureEnabled('nowy-koszyk')

if (stan === undefined) return <StaryKoszyk />
return stan ? <NowyKoszyk /> : <StaryKoszyk />

Rozróżnienie między wartością nieznaną a wyłączoną jest tu istotne, bo funkcja sprawdzająca zwraca w tych przypadkach dwie różne rzeczy, a zapis skrótowy traktuje obie tak samo.

Osobną dobrą praktyką jest sprzątanie przełączników po zakończonym wdrożeniu. Warunek, który po pół roku zawsze zwraca tę samą wartość, zostaje w kodzie jako martwa gałąź, a przy dwudziestu takich warunkach nikt już nie wie, które ścieżki są jeszcze osiągalne. Usunięcie przełącznika razem z nieużywaną gałęzią należy do zadania wdrożeniowego, a nie do listy rzeczy do zrobienia kiedyś.

PostHog kontra alternatywy

Rozstrzygnięcie zależy od tego, ile z tych funkcji naprawdę wykorzystasz. Zespół używający wyłącznie odsłon i podstawowych zdarzeń przepłaca za możliwości, których nie rusza. Zespół prowadzący eksperymenty, oglądający nagrania i wypuszczający funkcje na części ruchu oszczędza tu na trzech osobnych rachunkach naraz.

Drugi wiersz tabeli oznacza w praktyce narzędzie pokroju Plausible: skrypt bez ciasteczek, więc strona obchodzi się bez baneru zgody, jeden pulpit zamiast kilkudziesięciu raportów i kod na licencji open source do postawienia u siebie. Nagrań sesji, przełączników funkcji ani eksperymentów tam nie ma, więc jest to wybór dla strony, która chce znać liczbę odwiedzin, a nie badać zachowanie zalogowanych użytkowników.

Ostatni wiersz zasługuje na uczciwe potraktowanie. Wdrożenie u siebie usuwa opłaty za zdarzenia i wprowadza koszt utrzymania klastra przetwarzającego duże wolumeny danych, co przy poważnym ruchu bywa droższe niż usługa zarządzana. To wybór podyktowany zwykle wymogami prawnymi, a nie oszczędnością.

Wdrożenie i model danych

Instalacja to skrypt na stronie albo pakiet w projekcie, a przy aplikacji na Next.js warto zwrócić uwagę na dwie rzeczy.

Pierwsza to inicjalizacja wyłącznie po stronie klienta, bo biblioteka sięga po obiekty przeglądarki. Wywołanie jej podczas renderowania na serwerze kończy się błędem, a rozwiązaniem jest umieszczenie jej w komponencie klienckim uruchamianym po zamontowaniu.

Druga to śledzenie zmiany trasy. Aplikacja jednostronicowa nie przeładowuje strony przy przejściu, więc automatyczne zliczanie odsłon widzi tylko pierwsze wejście. Trzeba wysłać zdarzenie ręcznie przy zmianie ścieżki, i to jest najczęstsza przyczyna zaniżonych statystyk w takich aplikacjach.

Warto też rozważyć wysyłanie zdarzeń z serwera zamiast z przeglądarki. Zdarzenia dotyczące płatności, zmiany planu czy zakończenia procesu są wtedy odporne na blokady reklam i na zamknięcie karty w połowie, a to zwykle właśnie te zdarzenia mają największe znaczenie biznesowe.

Model danych opiera się na zdarzeniach z właściwościami i na osobach, do których te zdarzenia są przypisane. Właściwości warto planować od początku, bo dodanie ich później nie zmienia zdarzeń już zapisanych. Zdarzenie zamówienia bez wartości koszyka wygląda niewinnie w pierwszym tygodniu i uniemożliwia policzenie przychodu przez cały kwartał wstecz.

Nazewnictwo zdarzeń również warto ustalić raz. Konwencja z czasownikiem w formie dokonanej, zapisana małymi literami z podkreśleniami, jest dowolna i skuteczna, natomiast mieszanie trzech konwencji w jednym projekcie daje listę zdarzeń, w której nikt niczego nie znajdzie po pół roku.

Prywatność i zgodność

Platforma daje wybór regionu przechowywania danych, w tym europejski, co przy wymogach dotyczących danych osobowych bywa warunkiem wejścia.

Nagrania sesji wymagają osobnej uwagi, bo rejestrują to, co widzi użytkownik. Maskowanie pól formularzy jest ustawieniem, które warto włączyć od początku, a przy polach z danymi wrażliwymi dołożyć jawne wykluczenia. Numer karty widoczny w nagraniu jest problemem, którego nie da się cofnąć po fakcie.

Warto też pamiętać o zgodzie użytkownika. Skrypt zbierający zdarzenia i nagrania podlega tym samym zasadom co inne narzędzia analityczne, więc uruchamianie go przed uzyskaniem zgody jest ryzykiem, którego łatwo uniknąć, inicjując bibliotekę dopiero po decyzji użytkownika.

Typowe błędy

Pierwszy to brak limitu wydatków. Ustawienie go zajmuje minutę i zamienia ryzyko nieprzewidzianego rachunku w ryzyko braku części danych, czyli w problem znacznie łatwiejszy do przełknięcia.

Drugi to pozostawienie automatycznego zbierania zdarzeń bez przeglądu. To główna przyczyna rachunków wielokrotnie wyższych od szacunku.

Trzeci to identyfikowanie każdego użytkownika bez potrzeby. Zdarzenia przypisane kosztują wielokrotnie więcej niż anonimowe.

Czwarty to nagrywanie wszystkich sesji. Obejrzysz kilkanaście, a płacisz za wszystkie, podczas gdy próbkowanie daje ten sam wgląd taniej.

Piąty to ustalanie metryki eksperymentu po obejrzeniu wyników. To sposób na potwierdzenie dowolnej tezy, a nie na dowiedzenie się czegokolwiek.

Szósty to nagrania bez maskowania pól formularzy. Dane wrażliwe zapisane w nagraniu to problem, którego nie da się naprawić wstecz, bo nagranie trzeba wtedy usunąć w całości razem z jego wartością diagnostyczną.

FAQ

Czy PostHog jest darmowy?

Do pewnego poziomu tak, i ten poziom jest szeroki: około miliona zdarzeń analitycznych miesięcznie, kilka tysięcy nagrań sesji i milion zapytań o przełączniki funkcji, bez limitu czasu i bez limitu osób w zespole. Powyżej progu płacisz za zużycie, bez stałego abonamentu.

Dlaczego rachunek bywa wyższy od szacunku?

Zwykle przez trzy rzeczy mnożące się przez siebie: automatyczne zbieranie zdarzeń generujące kilka zdarzeń na jedną interakcję, zdarzenia przypisane do zidentyfikowanego użytkownika kosztujące wielokrotnie więcej niż anonimowe oraz synchronizację danych z systemów zewnętrznych rozliczaną za wiersz.

Czy zastąpi osobne narzędzie do przełączników funkcji?

Tak, i to jeden z mocniejszych argumentów za tą platformą, bo osobne narzędzia tej klasy bywają drogie. Przełączniki działają razem z eksperymentami i analityką na wspólnych danych, więc wynik testu widzisz w tym samym miejscu co resztę.

Czy mogę uruchomić go u siebie?

Tak, kod jest otwarty. Warto natomiast policzyć koszt utrzymania klastra przetwarzającego duże wolumeny danych, bo przy poważnym ruchu bywa on wyższy niż rachunek za usługę zarządzaną. To zwykle wybór podyktowany wymogami dotyczącymi miejsca przechowywania danych.

Czy nagrania sesji są bezpieczne dla danych osobowych?

Tylko przy właściwej konfiguracji. Maskowanie pól formularzy warto włączyć od początku, a pola z danymi wrażliwymi wykluczyć jawnie. Sama biblioteka powinna startować dopiero po uzyskaniu zgody użytkownika, tak jak inne narzędzia analityczne.

Dokumentacja stoi na stronie projektu, a kod w repozytorium na GitHubie.