GA4 for Growth Teams: A Practical Setup

Most growth teams I meet have GA4 installed and almost nobody looking at it. The property exists, the tag fires, the reports fill up with numbers, and then everyone quietly goes back to whatever spreadsheet they actually trust. GA4 became the thing you set up because you had to, not the thing you use because it helps. That is a waste, because underneath the intimidating interface there is a genuinely capable analytics tool, and the free BigQuery export attached to it is one of the better deals in the entire measurement stack.

The problem is almost never GA4 itself. It is that GA4 is only as useful as the plan behind it, and most properties have no plan behind them at all. Someone pasted the tag, accepted the defaults, and hoped meaning would emerge. It never does. GA4 does not know what your business cares about, and if you do not tell it, you get a wall of generic reports that describe traffic without ever answering a question you actually asked.

I spend most of my time instrumenting growth measurement and owning the number that comes out the other side. At Chegg I ran a system of more than 200 landing pages with a rigorous experimentation program on top of it, and none of that works without analytics you can trust down to the event. This is the setup I wish more teams started from: what GA4 actually changed, how to configure it for growth rather than for vanity, and where its limits are so you know when to reach for something else.

The shift from Universal Analytics, and why it confuses people

If you learned analytics on Universal Analytics, GA4 feels wrong at first, and the reason is a real change in the underlying model, not just a redesigned interface. Universal Analytics was built around sessions and pageviews. The session was the primary unit, and everything hung off it. GA4 threw that out and rebuilt everything around events. In GA4, a pageview is an event, a click is an event, a purchase is an event, a scroll is an event. Everything is an event, and events carry parameters that describe them.

This is why people get lost. They open GA4 looking for the session-based reports they knew and find a different vocabulary that does not map cleanly onto the old one. Bounce rate is gone, replaced by engagement. The metrics they used to quote in meetings either changed definition or vanished. The instinct is to conclude GA4 is worse. It is not worse, it is different, and the event model is actually a better fit for how growth teams think. You care about what users do, and GA4 is built around exactly that. Once the event model clicks, the old session-centric world starts to feel like the limited one.

Start from a tracking plan, not from GA4’s defaults

Here is the single decision that separates a useful GA4 property from a useless one. Do not start inside GA4. Start from a tracking plan, which is the document that says what you want to measure and why, before you touch any configuration. GA4’s defaults are a starting point built for the average of every website on the internet, which means they are built for no one in particular.

A growth team needs to answer specific questions. Which acquisition sources bring users who actually activate? Where in the flow from first visit to paid do people fall out? Which behaviors predict retention? None of those questions answer themselves from automatically collected pageviews. You have to decide which events matter, name them deliberately, and instrument them on purpose. That work belongs in a tracking plan you design before you instrument anything, because trying to reverse-engineer meaning out of whatever GA4 happened to collect is how you end up with a property nobody trusts. Decide the questions first. Let the questions dictate the events. Then configure GA4 to capture exactly those.

Defining key events that map to real outcomes

In GA4 the events you care most about get marked as key events, which is the current name for what used to be called conversions. This is where discipline pays off, because every key event you define is a claim about what matters to the business, and the temptation is to mark everything.

Resist it. A key event should map to a real business outcome, not to activity that feels good to watch go up. A completed signup, a first meaningful action inside the product, a subscription started, a plan upgraded, these are outcomes. A pageview on the pricing page is not an outcome, it is a step, and if you mark it as a key event you will spend the next year explaining to people why the conversion number is meaningless. The classic trap is measuring what is easy to measure instead of what actually indicates progress. Tie your key events to the moments that mean a user got real value or the business got real revenue. If you have already done the work of naming your activation metric precisely, that definition should translate almost directly into a GA4 key event, which is exactly how it should feel when the plan is coherent.

Event and parameter naming discipline

This sounds like housekeeping and it is actually load-bearing. GA4 gives you enormous freedom in how you name events and what parameters you attach, and freedom without a convention produces chaos fast. I have seen properties with signup, sign_up, SignUp, and user_signup all firing, each from a different developer on a different sprint, none of them aggregating together. The analytics were technically working and completely useless.

Pick a naming convention and write it down in the tracking plan. Lowercase with underscores is the sensible default because it matches GA4’s own automatic events and avoids case-sensitivity surprises. Decide whether a piece of information is its own event or a parameter on a shared event, and be consistent. A single purchase event with a plan_type parameter is far more workable than separate purchase_basic and purchase_pro events, because the parameter version lets you both aggregate all purchases and split by plan when you want to. Parameters are how you avoid an explosion of near-identical events. Use them deliberately, name them consistently, and register the ones you want to report on as custom dimensions so they show up in the interface rather than getting silently dropped.

Audiences and segments that matter

GA4 lets you build audiences from event behavior, and for a growth team this is where the tool starts earning its place. An audience is a group of users defined by what they did, users who activated but never came back, users who hit the pricing page twice without buying, users who completed onboarding in their first session. These are not just report filters, they are groups you can push to Google Ads for remarketing and use to compare behavior across cohorts.

Build the audiences that correspond to real decisions. If you are trying to understand why activated users churn, you need an audience of activated-then-churned users to look at. If you want to retarget high-intent non-buyers, you need that audience defined and flowing to your ad platform. The mistake is building dozens of audiences because you can, then never using any of them. Build the few that map to questions you are actively working, and add more only when a new question demands it. Segments in Explorations work the same way, giving you the power to slice a behavioral question by the group you care about instead of staring at the blended average that hides everything interesting.

Exploring funnels and paths with Explorations

The standard GA4 reports are fine for a quick pulse check and thin for real analysis. The place growth work actually happens is Explorations, the free-form analysis area where you build funnel reports, path analysis, and segment overlaps without being constrained by the prebuilt report layouts.

The funnel exploration is the one I open most. Define the ordered steps from first visit through to your key event, and GA4 shows you the drop-off between each stage. This turns a vague sense that conversion is low into a specific claim: this many people reach step three, this many reach step four, and the gap between them is where the money is leaking. Path exploration answers a different question, showing you the actual routes users take through the product rather than the route you assumed they take, which is regularly a humbling experience. These explorations are where GA4 stops being a reporting tool and becomes a diagnostic one. Spend your time here, not in the default reports.

Connecting GA4 to the wider stack

GA4 is more valuable connected than standalone, and the connections are the point where it stops being an island. Three matter most for growth teams. The Google Ads link sends your key events and audiences into Ads so you can optimize campaigns toward real outcomes and retarget the audiences you built. The Looker Studio connection lets you build dashboards on top of GA4 data that people will actually open, instead of asking everyone to learn the GA4 interface. And the BigQuery export, which deserves its own section, is the one that removes the ceiling entirely.

The Looker Studio piece is worth dwelling on because a dashboard is only useful if it changes what someone does. It is easy to build a beautiful report that nobody acts on, and that is a real failure mode, not a minor one. The discipline of building dashboards that drive action rather than decorate a wall applies directly here. Connect GA4 to Looker Studio, then build the two or three views that answer the questions your team makes decisions with, and stop. Everything past that is noise dressed up as thoroughness.

The BigQuery export is your escape hatch

The GA4 interface has real limits. It samples data on large or complex queries, it applies thresholds that hide small numbers, and it constrains you to the analyses the interface supports. The free BigQuery export is how you get around all of it. Every GA4 property can stream its raw event-level data into BigQuery at no cost for the export itself, and that raw data is the same events you configured, unsampled and unthresholded, sitting in a warehouse you can query with SQL.

This changes what is possible. In BigQuery you can join GA4 data to your product database, your billing system, your CRM. You can run the cohort and retention analyses the GA4 interface cannot express. You can compute your own metrics with definitions you control rather than accepting GA4’s. For any growth team doing serious analysis, I treat the BigQuery export as non-negotiable, and I turn it on the day the property is created, because it only captures data from the moment you enable it and there is no going back to fill in the past. If GA4’s interface is where you check the pulse, BigQuery is where you do the surgery.

Consent, privacy, and the data completeness reality

If you operate in the EU, and I do, you cannot talk about GA4 setup honestly without talking about consent. Under GDPR and the cookie-consent regimes that follow from it, you can only collect analytics data from users who agree to it, and a meaningful share will decline. That is not a bug in your setup, it is the legal and ethical reality, and it means your GA4 data is structurally incomplete in a way US-centric guides tend to gloss over.

Two things follow. First, wire up consent mode properly so GA4 knows the consent state and behaves accordingly, and so Google’s modeling can estimate the behavior of users who declined rather than simply dropping them. Second, calibrate your own expectations and your team’s. The numbers in GA4 undercount actual traffic, sometimes substantially, and the gap is filled with modeled data, which is an estimate and not a measurement. Set your data-retention window deliberately too, because GA4’s default retention is shorter than most people assume and the BigQuery export is part of how you keep history beyond it. None of this makes GA4 unusable in Europe. It makes it a tool you read with informed skepticism rather than false precision.

Common frustrations and how to handle them

A few things will confuse or annoy you, and knowing them in advance saves a lot of frustration.

Sampling and thresholding hide data. When numbers seem to disappear or a report refuses to show a small segment, that is thresholding protecting user privacy, and the fix is usually the BigQuery export where those limits do not apply. Attribution numbers will not match your ad platforms. GA4 uses its own attribution model and lookback windows, and Google Ads, Meta, and your internal reporting will all disagree, because they are counting differently, not because one is broken. The way through that is understanding how attribution models actually differ and why the same conversion gets counted several ways rather than trying to force the numbers to reconcile. And modeled data will appear in your reports labeled as such, which is GA4 filling gaps from consent and cross-device limits with estimates. Treat modeled figures as directional, not exact.

Where GA4 stops and product analytics begins

GA4 is very good at some things and genuinely weak at others, and pretending otherwise leads teams to fight the tool. It is strong on acquisition and marketing analytics, on where traffic comes from, on campaign performance, on top-of-funnel behavior, and on tying all of that into the Google advertising ecosystem. That is what it was built for and it does it well.

It is weaker at deep product analytics. When you want to understand individual user behavior over time, run flexible retention and cohort analysis in an interface built for it, or trace a specific user’s actions across a long lifecycle, GA4 fights you. That is the territory of a dedicated product analytics tool like PostHog or Amplitude, which are designed around exactly the event-level, user-centric questions GA4 makes awkward. The mature setup is not GA4 or product analytics, it is GA4 for marketing and acquisition, a product analytics tool for in-product behavior, and often both feeding the same warehouse. Knowing which tool answers which question is most of the skill.

A practical setup checklist

If you are setting up or fixing a GA4 property for a growth team, this is the order I work in.

• Write the tracking plan first. Decide the questions, then the events and parameters that answer them, before configuring anything.
• Turn on the BigQuery export on day one. It only captures data going forward, so every day you wait is history you lose.
• Define key events that map to real outcomes, signups, activation, revenue, and refuse to mark steps and vanity actions as conversions.
• Enforce a naming convention. Lowercase with underscores, parameters over event proliferation, custom dimensions registered for anything you want to report on.
• Configure consent mode and set your data-retention window deliberately, especially in the EU, and read the resulting numbers as undercounted and partly modeled.
• Build only the audiences and dashboards that map to active decisions, and connect Google Ads and Looker Studio to close the loop.
• Do your real analysis in Explorations and BigQuery, and reach for a product analytics tool the moment the question is about in-product behavior over time.

The short version

• GA4’s problem is almost never GA4. It is the missing plan behind it, so start from a tracking plan and let your questions dictate the events, never the other way around.
• The shift from Universal Analytics is a real change to an event-based model, not just a new interface, and it fits how growth teams think once it clicks.
• Define key events that map to genuine outcomes and enforce strict naming discipline, or your conversions and your reports will quietly become meaningless.
• Do your real work in Explorations for funnels and paths, and turn on the free BigQuery export on day one as the escape hatch from the interface’s sampling and thresholding limits.
• Respect the EU consent reality: your data is structurally incomplete and partly modeled, so read it with informed skepticism rather than false precision.
• Know where GA4 stops. It owns acquisition and marketing analytics; reach for a product analytics tool like PostHog for deep in-product behavior over time.
• Never let it become a wall of reports nobody opens. Build only the audiences and dashboards that map to decisions you are actively making.

---

I am Deepanshu Grover, a Growth Product Manager in Paris. If GA4 feels like a wall of reports you never open, connect on LinkedIn or get in touch.