And why many startups are flying blind without realizing it.
GA4 is everywhere. It's installed, it's collecting data, the dashboards look busy — so founders conclude we have analytics, we're data-driven. But GA4 mostly answers marketing questions, not product questions, and using it as a product decision engine produces a specific and expensive failure mode: false confidence, slow learning, and decisions made on the wrong signal. The problem isn't that GA4 is bad. It's that it's quietly being asked to do a job it was never built for, and the gap doesn't show up as an error message — it shows up as months of optimizing the wrong thing.
The core problem: GA4 was never designed for product thinking
GA4 is optimized for traffic acquisition, attribution, campaigns, channels, and conversions at the edge of the funnel — the marketing questions of how did users arrive and what did it cost. Product decisions need something categorically different: understanding behavior rather than visits, tracking users over time rather than sessions, measuring flows rather than pages, and analyzing decisions rather than clicks. GA4 isn't broken; it's solving a different problem competently. The mistake is treating a marketing-acquisition tool as a product-behavior brain — and the tool will happily produce dashboards either way, which is exactly what makes the mistake so easy to miss.
What founders think GA4 tells them (but doesn't)
Teams routinely believe GA4 answers questions like: which features drive retention? where do users get stuck? what behavior predicts churn? what actually causes conversion? GA4 generally can't answer these reliably — and crucially, not because you configured it wrong. It's because of how it models data. No amount of careful setup turns an acquisition tool into a behavioral one; the limitation is structural, which means the fix isn't "configure GA4 better," it's "use the right instrument for the question."
The structural limitations of GA4 (not configuration issues)
1. Event soup without product context
GA4 is event-based, which sounds promising, but the events are flat, the context is shallow, and the relationships between them are weak. You can track clicks, page views, and scrolls easily; what you can't easily reconstruct is the sequence that led to success, which actions matter versus which are noise, or how behavior evolves across weeks. Product decisions depend on state and progression — where a user is in their lifecycle and how they got there — and GA4 fundamentally sees isolated moments, not journeys.
2. Sessions went away, but the mental models didn't improve
When GA4 replaced Universal Analytics (sunset in 2023), it moved from a session-centric model to an event-centric one — but it didn't replace sessions with real user journeys, lifecycle states, or funnels that reflect product logic. So teams kept reasoning in pages, events, and sessions out of habit, even though products don't work that way. Users move through onboarding, activation, usage, value moments, and drop-off — a stateful lifecycle — and GA4 doesn't model that natively. Removing the old abstraction didn't hand anyone a better one.
3. Retention analysis is superficial
GA4's retention reporting is limited, coarse, hard to customize, and disconnected from product meaning. You can see that users returned; you can't easily see why they returned, what they used, or what changed in their behavior. And retention without causality isn't actionable — "12% came back" tells you nothing you can build on, because it doesn't connect returning to any product cause you could amplify.
4. Thresholding, sampling, and privacy blur the picture
GA4 increasingly applies data thresholds (especially when Google Signals is on, it withholds data that could identify individuals in small segments), collapses high-cardinality dimensions into an "(other)" bucket, and samples explorations above certain limits. This is understandable and often legally sensible for privacy — but for product discovery it's dangerous, because it makes small cohorts invisible, hides edge cases, and erases exactly the weak early signals you most need when you're trying to learn what's working. The tool's privacy posture is appropriate; it just collides directly with the granularity product discovery requires.
The most expensive mistake: mixing marketing and product analytics
This is where teams fail silently. They use GA4 for traffic, then also for onboarding, feature usage, and retention — everything in one place. The result is misleading correlations, false attribution, and decisions driven by acquisition noise leaking into product conclusions. The two disciplines answer different questions: marketing analytics answers how did users arrive?, product analytics answers what do users do once they're here? — and blending them means your product insights inherit your marketing tool's assumptions. (This is the same separation-of-concerns logic from the data-architecture side: in ClickHouse vs BigQuery the winning pattern is BigQuery for marketing/BI, a real-time engine for product behavior, and a warehouse as the shared source of truth — the same split, one layer down.)
What product decisions actually require
A clear event model
Not button_clicked but account_created, onboarding_completed, feature_X_used, value_moment_reached. Events should represent business meaning, not UI actions — a taxonomy of what users accomplished, not what they tapped. This is the single highest-leverage thing a team can get right, because every downstream analysis is only as meaningful as the events underneath it. Garbage events in, confident-looking nonsense out.
User-centric, longitudinal data
You need to follow the same user over time — behavior changes, learning curves, drop-off patterns — which is precisely the depth GA4 isn't built for. Cohorts and lifecycles, not session snapshots.
Funnel logic that matches reality
Product funnels are non-linear, multi-session, multi-device, and stateful; marketing funnels are not. A user who explores, leaves, returns on another device a week later, and converts is a normal product journey and a broken marketing-funnel assumption. Using marketing-funnel logic on product behavior produces confident, wrong conclusions.
Ownership of the data
GA4's data lives inside Google with modeling constraints — though this is the one place the common critique needs updating: GA4 offers a free raw-event export to BigQuery (a genuine improvement over Universal Analytics, where it was a paid-360 feature). So the raw data is reachable. The catch is that an export is not an analysis: once it's in the warehouse you still have to build the user model, the sessionization-that-makes-sense, and the funnels yourself. The constraint shifted from "you can't get the data" to "the data is raw and the modeling is on you" — which is exactly the work serious product teams take ownership of.
What high-performing teams do instead
They don't replace GA4 — they put it in its place. The mature setup is a clean separation: GA4 for acquisition and marketing, a dedicated product-analytics layer for behavior and decisions (tools like Amplitude, Mixpanel, or the open-source, self-hostable PostHog — the last of which is notably friendlier for GDPR and EU data-residency needs), and a data warehouse as the source of truth underneath both. This separation reduces confusion, raises signal quality, and accelerates learning, because each tool answers only the questions it's actually good at. GA4 stays in the stack; it just stops pretending to be the brain.
Why this matters more after product-market fit, not before
Early on, a small team can feel the product — they talk to every user, they hold the whole thing in their heads, and intuition is genuinely a good instrument. Post-PMF, that intuition breaks down: small changes have large, non-obvious impact, wrong decisions compound across a bigger user base, and the team scales faster than any one person's understanding of it. Relying on GA4 alone at that stage is like flying a plane with only an altimeter — one real reading, and none of the instruments you need to actually navigate. The moment you can no longer feel the product is exactly the moment you need real product instrumentation, and it's also the moment most teams discover their event model was never built for it.
The H-Studio perspective: analytics as product infrastructure
We treat analytics as part of the product architecture — not a reporting layer bolted on at the end, and not a marketing add-on. That means designing an event model aligned with business logic, implementing privacy-first (often server-side) tracking that respects GDPR by design rather than as an afterthought, keeping product and marketing analytics cleanly separate, and building dashboards founders can actually act on rather than just admire. GA4 keeps its seat; it simply stops being asked to make product decisions it was never built to inform. (On why privacy-by-design beats bolt-on tracking in the German market specifically, see how to build software that survives German compliance.)
Final thought
GA4 is useful — genuinely, for what it's for. But it's often not enough. If your product decisions rest solely on GA4, you're optimizing for visibility (who arrived, through which channel) when the thing that keeps companies alive is value (what users do, why they stay, what to build next). Those are different questions, answered by different instruments, and mistaking one for the other is how a team can be busily "data-driven" and still flying blind.
Frequently asked questions
Is GA4 bad for analytics?
No — it's good at what it was built for: acquisition, attribution, channels, and marketing conversions. The problem is using it as a product-behavior tool, which its event model and reporting weren't designed to support. Keep it for marketing; add a product layer for behavior.
Why can't GA4 answer product questions like retention drivers or churn predictors?
Because of how it models data, not how you configured it. Its events are flat and weakly related, it doesn't model the user lifecycle natively, and its retention reporting is disconnected from product meaning. Those are structural limits no setup fixes.
Doesn't GA4's BigQuery export solve the data-ownership problem?
Partly. The free raw-event export to BigQuery genuinely gets your data out of Google's UI constraints — a real improvement over Universal Analytics. But raw events aren't analysis; you still have to build the user model, funnels, and lifecycle logic yourself. It removes the access barrier, not the modeling work.
What should we use alongside GA4 for product analytics?
A dedicated product-analytics layer — Amplitude, Mixpanel, or open-source PostHog (often the easiest to keep GDPR-friendly and EU-hosted) — backed by a data warehouse as the source of truth. Keep GA4 for marketing and let the product layer answer behavior questions.
When does relying on GA4 alone become risky?
Most acutely after product-market fit, when intuition stops scaling, small changes have outsized effects, and wrong decisions compound across a larger base. Before PMF you can often feel the product; after it, you need real instrumentation, and GA4 alone isn't it.
Get an analytics architecture audit
If your product decisions rely on GA4 alone, you're likely missing critical insights about user behavior, retention, and feature adoption. We analyze your event model, tracking gaps, and GDPR risks—and design an analytics setup that actually supports product decisions.
We build data engineering and analytics pipelines that give you ownership over your data and the flexibility to answer product questions. For growth analytics and BI dashboards, we create dashboards founders can actually act on. For privacy-first tracking, we implement server-side analytics designed around GDPR requirements while preserving insight quality.
Edited and fact-checked by Anna Hartung.