Śledzenie po stronie serwera a po stronie klienta

Jaka jest różnica, w jednym zdaniu?

Śledzenie po stronie klienta widzi kontekst; śledzenie po stronie serwera widzi prawdę. Przeglądarka zna parametry UTM, źródło odesłania, urządzenie i stronę – i gubi zdarzenia przez blokery. Twój backend wie, co naprawdę się wydarzyło – subskrypcja się zaczęła, płatność nie przeszła – i nie wie nic o tym, jak użytkownik tu trafił. Ten poradnik dotyczy tego, gdzie wdrażać śledzenie. Co śledzić – nazewnictwo i startową listę zdarzeń – opisuje plan śledzenia zdarzeń dla startupów; dlaczego dane w ogóle powinny być first-party – dane first-party i śledzenie. Obie połowy należą do jednego planu śledzenia.

Co widzi śledzenie po stronie klienta – a czego nie widzi?

Po stronie klienta żyje kontekst. SDK w przeglądarce zbiera parametry UTM, źródło odesłania, stronę docelową, urządzenie i zachowanie w sesji – wszystko, czego potrzebuje atrybucja i analiza lejka. Gubi natomiast całych użytkowników: według danych GWI zebranych przez Backlinko 29,5% internautów na świecie przynajmniej czasem używało blokera reklam w II kwartale 2025 – to ok. 1,77 mld osób. Wiele blokerów zatrzymuje skrypty analityczne razem z reklamami, więc mierzalna część Twoich zdarzeń po stronie klienta w ogóle nie zostaje wysłana.

Nawet bez blokera Safari sprawia, że śledzenie po stronie klienta gubi dane. Safari, jak podaje dokumentacja ITP od WebKit, ogranicza ważność ciasteczek ustawianych przez JavaScript do siedmiu dni i usuwa wszystkie inne dane zapisywane przez skrypty – localStorage, IndexedDB – po siedmiu dniach korzystania z Safari bez interakcji z Twoją stroną. Gdy to okno siedmiu dni korzystania minie, powracający odwiedzający wygląda na zupełnie nowego, a tożsamość się rozpada. Strata jest mierzalna: gdy zespół Plausible porównał własne liczby z Google Analytics na stronie popularnej na Hacker News i Reddicie w teście pod koniec sierpnia 2021, narzędzie Google Analytics pominęło 58,67% odwiedzających – to skrajny przypadek z technicznie obytą publicznością; Plausible przytacza wcześniejsze badania, według których blokowanie wynosi poniżej 10% na stronach o stylu życia i ponad 25% na stronach technologicznych.

Co widzi śledzenie po stronie serwera – a czego nie widzi?

Śledzenie po stronie serwera to Twój backend, który zgłasza zmiany stanu do API zdarzeń: subscription_started, payment_failed, plan_changed. Te zdarzenia dzieją się na Twoich serwerach, a nie w przeglądarce – zapisywanie ich tam to nie obejście, tylko uczciwe źródło. Na drodze nie stoi żaden bloker, żaden limit przechowywania ich nie usuwa, a liczba zgadza się z Twoją bazą danych, bo z niej pochodzi. Zdarzenie po stronie serwera jest wiarygodne, bo zapisuje to, co zrobił Twój system, a nie to, co przeglądarce udało się zgłosić. Martwym polem jest kontekst: Twój backend nie ma pojęcia, która kampania, źródło odesłania czy urządzenie przyprowadziło użytkownika – ten kontekst istniał tylko po stronie klienta.

Klient czy serwer: które zdarzenia gdzie?

Jak mały zespół powinien to podzielić?

• Wszystko, co dotyczy pieniędzy – okresy próbne, subskrypcje, płatności, zwroty – idzie na serwer. Gdy churn lub MRR muszą się zgadzać, źródłem prawdy jest serwer.
• Wszystko, co dotyczy atrybucji – odsłony, kampanie, źródła odesłań – zostaje po stronie klienta. Tego kontekstu nie da się później odtworzyć.
• Identyfikuj użytkownika na obu drogach tym samym identyfikatorem, żeby lejki się łączyły, a testy A/B przy małym ruchu przypisywały każdego użytkownika do jednego wariantu na wszystkich urządzeniach.
• Zaakceptuj różnicę. Liczby po stronie klienta z założenia są zaniżone; używaj ich do oceny kierunku, a zdarzeń z serwera do wszystkiego, co raportujesz.

Dlaczego te dwie liczby nigdy się nie zgadzają?

Prowadź oba śledzenia, a liczby będą się różnić – na stałe. Liczba po stronie klienta jest zaniżona, bo blokery i ITP zjadają zdarzenia; liczbie po stronie serwera brakuje kontekstu, by powiedzieć, skąd przyszli użytkownicy. To nie błąd do naprawienia, tylko właściwość do nazwania: spodziewaj się stałej różnicy między analityką po stronie klienta a prawdą z serwera, poznaj jej przybliżoną skalę dla swoich odbiorców i przestań ją gonić. Raportuj każdą liczbę z jej uczciwej strony – atrybucję i kierunek lejka z danych klienta; wszystko, co trafia do prezentacji dla inwestorów albo na fakturę – wskaźnik churnu, MRR, aktywne subskrypcje – licz ze zdarzeń z serwera. Platformy customer engagement, takie jak Iterable i Ortto, przyjmują oba źródła z tego samego powodu.

Jak robi to fromHello?

fromHello traktuje ten podział jako domyślny. SDK JS/TS śledzi po stronie klienta i utrzymuje kolejkę offline opartą na localStorage – zdarzenia wysłane podczas utraty połączenia są zachowywane i ponawiane, gdy przeglądarka wróci do sieci – a to samo API zdarzeń przyjmuje wysyłki z serwera, więc subscription_started trafia prosto z Twojego backendu z kluczem API. Obie drogi zapisują do jednego profilu: atrybucja zebrana przez SDK i zdarzenia przychodowe wysłane przez Twój serwer opisują tę samą osobę. Segmenty, ścieżki i analityka czytają ten jeden profil – dzielisz opomiarowanie, a nie tożsamość.