GA4 is free, powerful, and configured wrong by default for SaaS. Out of the box it will happily count your logged-in app traffic as "marketing sessions," lose users at the signup boundary, and thin out your data before you notice. Here's the setup that works, the events worth sending, and the traps that cost teams months of clean data.

First decisions: property structure

One property, marketing site + app, separate data streams — or clearly separated by hostname. Keeping both in one property lets you follow a user from landing page to activation; just make sure every report filters or segments by hostname so app usage never inflates "site engagement."
Set data retention to 14 months immediately (Admin → Data settings). The default is 2 months for user-level explorations, and it is not retroactive. This is the single most common irreversible mistake.
Define internal traffic filters (your office IPs, staging domains) before launch, not after your team's clicks pollute three months of baselines.
Turn off the referral of your own payment provider. Add your checkout/billing domains (e.g. Stripe's) to the unwanted referrals list, or every subscription will be attributed to "stripe.com / referral" instead of the real channel.

The event taxonomy: fewer, better events

GA4 auto-collects page views, scrolls, and clicks. Useful, but the SaaS signal lives in a small set of custom events you send deliberately. A taxonomy that covers most products:

Event	When	Key parameters
sign_up	Account created	method, plan_intent
trial_start	Trial begins	plan
onboarding_step	Each onboarding step done	step_name, step_index
activation	First-value moment reached	days_since_signup
feature_used	Core feature engaged	feature_name
begin_checkout	Pricing → checkout	plan, billing_period
purchase	Subscription paid	value, currency, plan
upgrade / downgrade	Plan change	from_plan, to_plan
cancel_subscription	Cancellation confirmed	reason (if collected)

Rules that keep this clean:

Name in snake_case, verbs first, no spaces. GA4 event names are case-sensitive; "signup", "sign_up" and "SignUp" become three different events.
Parameters over event proliferation. One feature_used event with a feature_name parameter beats forty bespoke events.
Register custom dimensions for every parameter you'll report on (Admin → Custom definitions). Unregistered parameters are collected but invisible in standard reports — a classic "where's my data" mystery.
Mark sign_up, activation, and purchase as key events. These drive conversion reporting and audience building.

Identity: the make-or-break for SaaS

Anonymous visitors become logged-in users; GA4 won't connect them unless you tell it to.

Send user_id on every hit once someone is authenticated. This stitches pre-signup browsing to in-app behavior and dedupes users across devices.
Never put email or names in parameters. Personally identifiable information in GA4 violates its terms; use your internal ID only.
Cross-domain tracking: if marketing lives on yoursite.com and the app on app.yoursite.com, same-property tracking generally survives the subdomain hop, but a separate checkout domain needs explicit cross-domain configuration — otherwise the session breaks exactly at the moment that matters most, and conversions attribute to "direct."

The pitfalls that silently corrupt data

Thresholding. When Google signals are on, GA4 hides rows with few users for privacy. Small SaaS + segmented report = mysteriously missing data. If you see the warning icon, consider device-based reporting identity.
Sampling in explorations. Complex explorations over long ranges get sampled. Fine for direction, dangerous for precise conversion math.
(not set) landing pages and "unassigned" channels usually mean broken UTM discipline. Agree on a UTM convention (lowercase, fixed source/medium vocabulary) and audit monthly.
Consent mode gaps. Under consent banners, a large share of EU traffic may be modeled or missing. Your GA4 signup count will not match your database — expect a persistent gap (often 10–30%, illustratively) and treat the database as the source of truth for absolute counts.
Ad blockers. Some fraction of your (often technical) audience never reaches GA4 at all. Again: GA4 for behavior and channel mix, your backend for truth.
Counting purchase from the client only. Client-side purchase events get blocked and double-fire. Send revenue events server-side (Measurement Protocol) keyed to actual billing webhooks, or at minimum reconcile against Stripe monthly.

Where to actually read the data

GA4 offers three reading surfaces, each with a distinct job:

Standard reports (Reports section): pre-built, unsampled, thresholding-prone. Good for the weekly channel and landing-page check; frustrating for anything custom.
Explorations: funnels, path analysis, segment overlap, cohort views. This is where the real analysis lives — build one funnel exploration (landing → signup → activation → purchase) and one cohort retention exploration, save them, and revisit weekly. Remember explorations only see data from after your retention window and can sample on long ranges.
Looker Studio or an external dashboard for anything a non-analyst needs to read regularly. GA4's interface is an analyst tool; don't force your team to navigate it for six numbers.

One workflow note that saves recurring confusion: GA4 data is not final for 24–48 hours. Yesterday's numbers read this morning will change slightly by tomorrow. Never reconcile or report on a window that hasn't fully settled, and pick a consistent weekly reading day so comparisons stay fair.

What GA4 is for — and not for

Use GA4 for: channel and campaign performance, landing-page conversion, funnel drop-off up to signup, content analytics, and audience building for ads.

Do not use GA4 as: your MRR reporting (that's your billing system), your product analytics source of record (thresholding, sampling and blocking make it approximate), or your single source of user counts.

The honest architecture treats GA4 as the top-of-funnel lens and your database + billing data as ground truth, with the two joined by user_id.

Verifying your events actually fire

Instrumentation rots silently: a refactor renames a component, an event stops firing, and you discover it six weeks later as a mysterious "conversion drop." Defenses that cost little:

DebugView before every tracking release. Trigger each key event yourself and watch it arrive, with its parameters, in real time.
A weekly event-volume glance. Any key event at zero, or down an implausible 80%, gets investigated the same day — it's almost always a bug, not a trend.
Tie tracking checks to deploys. A one-line item in the release checklist ("signup and purchase events verified") prevents the majority of silent breakages.

A launch checklist

Data retention: 14 months
Internal traffic + staging filtered
Payment domains in unwanted referrals
Custom events implemented per the taxonomy, snake_case
Parameters registered as custom dimensions
Key events marked: sign_up, activation, purchase
user_id sent post-login; no personal data in any field
Cross-domain configured for any external checkout
UTM convention documented and shared
Monthly reconciliation: GA4 signups vs. database, GA4 revenue vs. billing

Run through this in an afternoon and you'll be ahead of most SaaS setups we see.

The bottom line

GA4 rewards a small, deliberate configuration and punishes defaults. Set retention and filters on day one, send a lean identity-stitched event taxonomy, and never let GA4 be your source of truth for money.

Growth Pilot connects to your GA4 property and pairs it with Stripe data — so acquisition numbers and revenue truth finally live on the same screen, reconciliation included.