Und warum viele Startups blind fliegen, ohne es zu merken.
GA4 ist überall. Es ist installiert, es sammelt Daten, die Dashboards sehen beschäftigt aus — also schließen Founder daraus wir haben Analytics, wir sind datengetrieben. Aber GA4 beantwortet vor allem Marketing-Fragen, keine Produkt-Fragen, und es als Produkt-Entscheidungsmaschine zu nutzen erzeugt einen spezifischen, teuren Fehlermodus: falsche Sicherheit, langsames Lernen und Entscheidungen auf dem falschen Signal. Das Problem ist nicht, dass GA4 schlecht ist. Es ist, dass man es leise eine Aufgabe erledigen lässt, für die es nie gebaut wurde — und die Lücke zeigt sich nicht als Fehlermeldung, sondern als Monate, in denen das Falsche optimiert wird.
Das Kernproblem: GA4 wurde nie für Product Thinking gebaut
GA4 ist optimiert für Traffic-Akquise, Attribution, Kampagnen, Channels und Conversions am Funnel-Eingang — die Marketing-Fragen, wie kamen User und was hat es gekostet. Produktentscheidungen brauchen etwas kategorisch anderes: Verhalten statt Visits verstehen, User über die Zeit statt Sessions verfolgen, Flows statt Pages messen, Entscheidungen statt Klicks analysieren. GA4 ist nicht kaputt; es löst kompetent ein anderes Problem. Der Fehler ist, ein Marketing-Akquise-Tool als Produkt-Verhaltens-Gehirn zu behandeln — und das Tool produziert in beiden Fällen bereitwillig Dashboards, was genau das ist, was den Fehler so leicht übersehbar macht.
Was Founder glauben, dass GA4 ihnen sagt (aber nicht tut)
Teams glauben routinemäßig, GA4 beantworte Fragen wie: Welche Features treiben Retention? Wo bleiben User hängen? Welches Verhalten sagt Churn voraus? Was verursacht Conversion wirklich? GA4 kann das in der Regel nicht zuverlässig beantworten — und zwar entscheidend nicht, weil du es falsch konfiguriert hast. Es liegt daran, wie es Daten modelliert. Keine noch so sorgfältige Einrichtung macht aus einem Akquise-Tool ein Verhaltens-Tool; die Grenze ist strukturell, was bedeutet, dass die Lösung nicht „GA4 besser konfigurieren“ heißt, sondern „das richtige Instrument für die Frage nutzen“.
Die strukturellen Limitierungen von GA4 (keine Konfigurationsfragen)
1. Event-Suppe ohne Produktkontext
GA4 ist event-basiert, was vielversprechend klingt, aber die Events sind flach, der Kontext ist dünn und die Beziehungen zwischen ihnen sind schwach. Du kannst Klicks, Pageviews und Scrolls leicht tracken; was du nicht leicht rekonstruieren kannst, ist die Sequenz, die zum Erfolg führte, welche Aktionen Signal versus Noise sind oder wie sich Verhalten über Wochen entwickelt. Produktentscheidungen hängen an Zustand und Progression — wo ein User in seinem Lifecycle steht und wie er dorthin kam — und GA4 sieht grundlegend isolierte Momente, keine Journeys.
2. Sessions sind verschwunden, aber die Denkmodelle wurden nicht besser
Als GA4 Universal Analytics ablöste (abgeschaltet 2023), wechselte es von einem session-zentrierten zu einem event-zentrierten Modell — aber es ersetzte Sessions nicht durch echte User-Journeys, Lifecycle-States oder Funnels, die Produktlogik abbilden. Also dachten Teams aus Gewohnheit weiter in Seiten, Events und Sessions, obwohl Produkte so nicht funktionieren. User bewegen sich durch Onboarding, Activation, Nutzung, Wertmomente und Drop-off — ein stateful Lifecycle — und GA4 modelliert das nicht nativ. Die alte Abstraktion zu entfernen hat niemandem eine bessere in die Hand gegeben.
3. Retention-Analyse bleibt an der Oberfläche
Das Retention-Reporting von GA4 ist limitiert, grob, schwer anpassbar und von der Produktbedeutung entkoppelt. Du siehst, dass User zurückkamen; du siehst nicht leicht, warum sie zurückkamen, was sie nutzten oder was sich in ihrem Verhalten änderte. Und Retention ohne Kausalität ist nicht handlungsfähig — „12 % kamen zurück“ sagt dir nichts, worauf du aufbauen könntest, weil es das Zurückkommen mit keiner Produktursache verbindet, die du verstärken könntest.
4. Thresholding, Sampling und Privacy verwischen das Bild
GA4 wendet zunehmend Datenschwellen an (besonders wenn Google Signals aktiv ist, hält es Daten zurück, die Einzelpersonen in kleinen Segmenten identifizieren könnten), fasst hoch-kardinale Dimensionen in einen „(other)“-Topf zusammen und sampled Explorationen oberhalb bestimmter Grenzen. Das ist nachvollziehbar und oft rechtlich sinnvoll aus Privacy-Sicht — aber für Product Discovery gefährlich, weil es kleine Cohorts unsichtbar macht, Edge Cases verbirgt und genau die schwachen frühen Signale auslöscht, die du am dringendsten brauchst, wenn du lernen willst, was funktioniert. Die Privacy-Haltung des Tools ist angemessen; sie kollidiert nur direkt mit der Granularität, die Product Discovery verlangt.
Der teuerste Fehler: Marketing- und Product-Analytics vermischen
Hier scheitern Teams leise. Sie nutzen GA4 für Traffic, dann auch für Onboarding, Feature-Usage und Retention — alles an einem Ort. Das Ergebnis sind irreführende Korrelationen, falsche Attribution und Entscheidungen, in die Akquise-Noise in Produktschlüsse durchsickert. Die beiden Disziplinen beantworten verschiedene Fragen: Marketing-Analytics beantwortet wie kamen User?, Product-Analytics beantwortet was tun User, sobald sie da sind? — und sie zu vermischen bedeutet, dass deine Produkt-Insights die Annahmen deines Marketing-Tools erben. (Das ist dieselbe Separation-of-Concerns-Logik von der Datenarchitektur-Seite: In ClickHouse vs BigQuery ist das Gewinner-Pattern BigQuery für Marketing/BI, eine Echtzeit-Engine für Produktverhalten und ein Warehouse als gemeinsame Source of Truth — derselbe Split, eine Ebene tiefer.)
Was Produktentscheidungen wirklich brauchen
Ein klares Event-Modell
Nicht button_clicked, sondern account_created, onboarding_completed, feature_X_used, value_moment_reached. Events sollten Business-Bedeutung abbilden, nicht UI-Aktionen — eine Taxonomie dessen, was User erreicht haben, nicht dessen, worauf sie getippt haben. Das ist das Wirkungsvollste, was ein Team richtig machen kann, denn jede nachgelagerte Analyse ist nur so aussagekräftig wie die Events darunter. Garbage Events rein, überzeugend aussehender Unsinn raus.
User-zentrische, longitudinale Daten
Du musst denselben User über die Zeit verfolgen — Verhaltensänderungen, Lernkurven, Drop-off-Muster — und genau diese Tiefe ist nicht das, wofür GA4 gebaut ist. Cohorts und Lifecycles, nicht Session-Snapshots.
Funnel-Logik, die zur Realität passt
Produkt-Funnels sind nicht linear, multi-session, multi-device und stateful; Marketing-Funnels sind es nicht. Ein User, der erkundet, geht, eine Woche später auf einem anderen Gerät zurückkommt und konvertiert, ist eine normale Produkt-Journey und eine kaputte Marketing-Funnel-Annahme. Marketing-Funnel-Logik auf Produktverhalten anzuwenden produziert überzeugte, falsche Schlüsse.
Ownership über die Daten
GA4-Daten leben in Google mit Modellierungs-Constraints — wobei das die eine Stelle ist, an der die übliche Kritik ein Update braucht: GA4 bietet einen kostenlosen Rohdaten-Export nach BigQuery (eine echte Verbesserung gegenüber Universal Analytics, wo es ein kostenpflichtiges 360-Feature war). Die Rohdaten sind also erreichbar. Der Haken: Ein Export ist keine Analyse — sobald sie im Warehouse sind, musst du das User-Modell, die sinnvolle Sessionisierung und die Funnels selbst bauen. Der Constraint hat sich verschoben von „du kommst nicht an die Daten“ zu „die Daten sind roh und die Modellierung liegt bei dir“ — und genau diese Arbeit übernehmen ernsthafte Product-Teams.
Was high-performing Teams stattdessen tun
Sie ersetzen GA4 nicht — sie setzen es an die richtige Stelle. Das reife Setup ist eine saubere Trennung: GA4 für Akquise und Marketing, eine dedizierte Product-Analytics-Schicht für Verhalten und Entscheidungen (Tools wie Amplitude, Mixpanel oder das Open-Source-, selbst-hostbare PostHog — Letzteres ist deutlich freundlicher für GDPR- und EU-Datenresidenz-Bedarf) und ein Data Warehouse als Source of Truth unter beidem. Diese Trennung reduziert Verwirrung, hebt die Signalqualität und beschleunigt das Lernen, weil jedes Tool nur die Fragen beantwortet, in denen es tatsächlich gut ist. GA4 bleibt im Stack; es hört nur auf, sich als das Gehirn auszugeben.
Warum das nach Product-Market-Fit kritischer wird, nicht davor
Früh kann ein kleines Team das Produkt fühlen — es spricht mit jedem User, hält das Ganze im Kopf, und Intuition ist tatsächlich ein gutes Instrument. Nach PMF bricht diese Intuition: Kleine Änderungen haben große, nicht-offensichtliche Effekte, falsche Entscheidungen kompounden über eine größere User-Basis, und das Team wächst schneller als das Verständnis einer einzelnen Person davon. Sich in diesem Stadium allein auf GA4 zu verlassen ist wie ein Flugzeug mit nur einem Höhenmesser zu fliegen — ein echter Messwert und keines der Instrumente, die du zum Navigieren brauchst. Der Moment, in dem du das Produkt nicht mehr fühlen kannst, ist genau der Moment, in dem du echte Produkt-Instrumentierung brauchst — und auch der Moment, in dem die meisten Teams entdecken, dass ihr Event-Modell nie dafür gebaut war.
Die H-Studio-Perspektive: Analytics als Produkt-Infrastruktur
Wir behandeln Analytics als Teil der Produktarchitektur — nicht als am Ende angeschraubte Reporting-Schicht und nicht als Marketing-Addon. Das heißt: ein Event-Modell entlang der Business-Logik designen, privacy-first Tracking (oft server-seitig) implementieren, das GDPR by Design respektiert statt als Nachgedanke, Produkt- und Marketing-Analytics sauber getrennt halten und Dashboards bauen, mit denen Founder tatsächlich handeln können, statt sie nur zu bewundern. GA4 behält seinen Platz; es wird nur nicht mehr gebeten, Produktentscheidungen zu treffen, für die es nie gebaut wurde. (Warum Privacy-by-Design im deutschen Markt speziell besser ist als nachgerüstetes Tracking, steht in Software bauen, die deutsche Compliance überlebt.)
Fazit
GA4 ist nützlich — ehrlich, für das, wofür es da ist. Aber es ist oft nicht genug. Wenn deine Produktentscheidungen allein auf GA4 ruhen, optimierst du Sichtbarkeit (wer kam, über welchen Channel), während das, was Unternehmen am Leben hält, Wert ist (was User tun, warum sie bleiben, was als Nächstes zu bauen ist). Das sind verschiedene Fragen, beantwortet von verschiedenen Instrumenten, und das eine für das andere zu halten ist, wie ein Team eifrig „datengetrieben“ sein und trotzdem blind fliegen kann.
Häufige Fragen
Ist GA4 schlecht für Analytics?
Nein — es ist gut in dem, wofür es gebaut wurde: Akquise, Attribution, Channels und Marketing-Conversions. Das Problem ist, es als Produkt-Verhaltens-Tool zu nutzen, was sein Event-Modell und Reporting nicht unterstützen sollten. Behalte es fürs Marketing; ergänze eine Produkt-Schicht fürs Verhalten.
Warum kann GA4 Produkt-Fragen wie Retention-Treiber oder Churn-Prädiktoren nicht beantworten?
Wegen der Art, wie es Daten modelliert, nicht wegen deiner Konfiguration. Seine Events sind flach und schwach verknüpft, es modelliert den User-Lifecycle nicht nativ, und sein Retention-Reporting ist von der Produktbedeutung entkoppelt. Das sind strukturelle Grenzen, die kein Setup behebt.
Löst der BigQuery-Export von GA4 nicht das Data-Ownership-Problem?
Teilweise. Der kostenlose Rohdaten-Export nach BigQuery holt deine Daten tatsächlich aus den UI-Constraints von Google — eine echte Verbesserung gegenüber Universal Analytics. Aber Rohdaten sind keine Analyse; du musst das User-Modell, die Funnels und die Lifecycle-Logik weiterhin selbst bauen. Er beseitigt die Zugangsbarriere, nicht die Modellierungsarbeit.
Was sollten wir neben GA4 für Product-Analytics nutzen?
Eine dedizierte Product-Analytics-Schicht — Amplitude, Mixpanel oder Open-Source-PostHog (oft am einfachsten GDPR-freundlich und EU-gehostet zu halten) — gestützt auf ein Data Warehouse als Source of Truth. Behalte GA4 fürs Marketing und lass die Produkt-Schicht die Verhaltens-Fragen beantworten.
Wann wird es riskant, sich allein auf GA4 zu verlassen?
Am akutesten nach Product-Market-Fit, wenn Intuition nicht mehr skaliert, kleine Änderungen übergroße Effekte haben und falsche Entscheidungen über eine größere Basis kompounden. Vor PMF kannst du das Produkt oft fühlen; danach brauchst du echte Instrumentierung, und GA4 allein ist das nicht.
Analytics-Architektur-Audit
Wenn deine Produktentscheidungen nur auf GA4 basieren, fehlen dir wahrscheinlich kritische Insights zu User-Verhalten, Retention und Feature-Adoption. Wir analysieren dein Event-Modell, Tracking-Lücken und GDPR-Risiken—und designen ein Analytics-Setup, das Produktentscheidungen wirklich trägt.
Wir bauen Data Engineering & Analytics Pipelines, die dir Ownership über deine Daten geben und die Flexibilität, Produkt-Fragen zu beantworten. Für Growth Analytics & BI Dashboards erstellen wir Dashboards, die Founder wirklich nutzen können. Für Privacy-First Tracking implementieren wir Server-Side Analytics, die GDPR-orientiert aufgesetzt sind und gleichzeitig Insight-Qualität erhalten.
Redigiert und faktengeprüft von Anna Hartung.