Was ist der Unterschied, in einem Satz?
Clientseitiges Tracking sieht Kontext, serverseitiges Tracking sieht Wahrheit. Der Browser kennt die UTM-Parameter, den Referrer, das Gerät und die Seite – und verliert Events an Blocker. Ihr Backend weiß, was tatsächlich passiert ist – ein Abo hat begonnen, eine Zahlung ist fehlgeschlagen – und weiß nichts darüber, wie der Nutzer dorthin gekommen ist. Dieser Leitfaden behandelt, wo Sie instrumentieren. Was Sie tracken sollten – Benennung und die Liste der Start-Events –, steht im Event-Tracking-Plan für Startups; warum die Daten überhaupt First-Party sein sollten, erklärt First-Party-Daten und Tracking. Beide Hälften gehören in einen einzigen Tracking-Plan.
Was sieht clientseitiges Tracking – und was nicht?
Auf der Client-Seite lebt der Kontext. Das SDK im Browser erfasst UTM-Parameter, den Referrer, die Landingpage, das Gerät und das Verhalten in der Sitzung – alles, was Attribution und Funnel-Analyse brauchen. Was ihm entgeht, sind ganze Nutzer: Laut GWI-Daten, zusammengestellt von Backlinko, nutzten im Q2 2025 weltweit 29,5 % der Internetnutzer zumindest manchmal einen Adblocker – rund 1,77 Milliarden Menschen. Viele Blocker stoppen Analyse-Skripte zusammen mit Werbung, sodass ein messbarer Teil Ihrer clientseitigen Events gar nicht erst gesendet wird.
Selbst ohne Blocker macht Safari clientseitiges Tracking lückenhaft. Laut der ITP-Dokumentation von WebKit begrenzt Safari per JavaScript gesetzte Cookies auf eine Laufzeit von sieben Tagen und löscht allen anderen per Skript beschreibbaren Speicher – localStorage, IndexedDB – nach sieben Tagen Safari-Nutzung ohne Interaktion mit Ihrer Website. Sobald dieses Fenster von sieben Nutzungstagen verstrichen ist, sieht ein wiederkehrender Besucher aus wie ein völlig neuer, und die Zuordnung der Identität reißt ab. Der Verlust ist messbar: Als Plausible bei einem Test Ende August 2021 die eigenen Zahlen mit Google Analytics auf einer Website verglich, die auf Hacker News und Reddit gerade viel Aufmerksamkeit bekam, verpasste Google Analytics 58,67 % der Besucher – ein extremer, technikaffiner Fall; Plausible verweist auf frühere Untersuchungen, nach denen die Blockierrate auf Lifestyle-Websites unter 10 % und auf technikorientierten Websites über 25 % liegt.
Was sieht serverseitiges Tracking – und was nicht?
Beim serverseitigen Tracking meldet Ihr Backend Zustandsänderungen an die Events-API: subscription_started, payment_failed, plan_changed. Diese Events passieren auf Ihren Servern, nicht im Browser – sie dort zu erfassen, ist kein Workaround, sondern die ehrliche Quelle. Kein Blocker steht im Weg, keine Speichergrenze lässt sie verfallen, und die Zahl stimmt mit Ihrer Datenbank überein, weil sie aus Ihrer Datenbank kommt. Ein serverseitiges Event ist maßgeblich, weil es festhält, was Ihr System getan hat, nicht was ein Browser zu melden geschafft hat. Der blinde Fleck ist der Kontext: Ihr Backend hat keine Ahnung, welche Kampagne, welcher Referrer oder welches Gerät den Nutzer gebracht hat – dieser Kontext existierte immer nur auf der Client-Seite.
Client vs. Server: Welche Events gehören wohin?
| Event-Klasse | Wo tracken | Warum |
|---|---|---|
| Seitenaufrufe & Kampagnen-Attribution | Client | UTM, Referrer und Landingpage gibt es nur im Browser. |
| Feature-Nutzung im Produkt | Client (bei kritischen auch Server) | Der UI-Kontext zählt; ergänzen Sie eine Server-Kopie, wenn eine Kennzahl davon abhängt. |
| Anmeldung & Login | Beide | Der Punkt, an dem Identitäten zusammenkommen – dieselbe Nutzer-ID auf beiden Wegen. |
| Umsatz & Abo-Status | Server | Geld-Events passieren in Ihrem Backend; die Zahl muss mit Ihrer Datenbank übereinstimmen. |
| E-Mail-, Webhook- & Integrations-Events | Server | Sie kommen als Webhooks von Ihren Anbietern – auf der Client-Seite gibt es nichts zu erfassen. |
Wie sollte ein kleines Team das aufteilen?
- Alles, was mit Geld zu tun hat – Testphasen, Abos, Zahlungen, Erstattungen –, gehört auf den Server. Wenn Churn oder MRR stimmen müssen, ist der Server die maßgebliche Quelle.
- Alles, was mit Attribution zu tun hat – Seitenaufrufe, Kampagnen, Referrer –, bleibt auf dem Client. Dieser Kontext lässt sich später nicht rekonstruieren.
- Identifizieren Sie auf beiden Wegen mit derselben Nutzer-ID, damit Funnels zusammenpassen und A/B-Tests bei wenig Traffic jeden Nutzer geräteübergreifend einer Variante zuordnen.
- Akzeptieren Sie die Lücke. Client-Zahlen liegen systembedingt zu niedrig; nutzen Sie sie für die Richtung und Server-Events für alles, was in Berichte eingeht.
Warum stimmen die beiden Zahlen nie überein?
Wenn Sie beides betreiben, werden die Zahlen voneinander abweichen – dauerhaft. Die Client-Zahl liegt zu niedrig, weil Blocker und ITP Events schlucken; der Server-Zahl fehlt der Kontext, um zu sagen, woher Nutzer kamen. Das ist kein Fehler, den Sie beheben, sondern eine Eigenschaft, die Sie benennen: Rechnen Sie mit einer dauerhaften Lücke zwischen Client-Analyse und Server-Wahrheit, kennen Sie ihre ungefähre Größe für Ihre Zielgruppe und hören Sie auf, ihr hinterherzulaufen. Weisen Sie jede Zahl von ihrer ehrlichen Seite aus – Attribution und Funnel-Richtung aus Client-Daten; alles, was in einem Investoren-Deck oder auf einer Rechnung landet – Churn-Rate, MRR, aktive Abos –, berechnet aus Server-Events. Engagement-Plattformen wie Iterable und Ortto akzeptieren aus demselben Grund beide Quellen.
Wie geht fromHello damit um?
fromHello behandelt die Aufteilung als Standard. Das JS/TS-SDK trackt clientseitig und führt eine Offline-Warteschlange auf Basis von localStorage – Events, die während eines Verbindungsabbruchs ausgelöst werden, bleiben erhalten und werden erneut gesendet, sobald der Browser wieder online ist. Dieselbe Events-API nimmt auch serverseitig gesendete Events an, sodass subscription_started mit einem API-Schlüssel direkt aus Ihrem Backend kommt. Beide Wege schreiben in ein einziges Profil: Die Attribution, die das SDK erfasst hat, und die Umsatz-Events, die Ihr Server gesendet hat, beschreiben dieselbe Person. Segmente, Journeys und Analysen lesen aus diesem einen Profil – Sie teilen die Instrumentierung auf, nicht die Identität.