GA4 for SaaS: The Event Model, User Properties, and Common Mistakes.

GA4 was designed around sessions and page views — a model that maps well to editorial sites and e-commerce storefronts where the interaction pattern is "arrive, browse, leave." SaaS products work differently. A user logs in, navigates through product screens, completes multi-step flows, collaborates with teammates, and the meaningful question is never "did they visit the pricing page" but "did they activate, did they retain, did they expand." Standard GA4 setup, applied without modification to a web app, produces data that looks plausible and is largely useless: page view counts that mean nothing in a single-page app, session durations that reflect idle tabs, and a complete absence of the product funnel.

This guide covers the specific events, user properties, and configuration decisions that make GA4 genuinely useful for a SaaS product. It is written for product marketers and growth engineers who already understand GA4 basics and need to know what is different for a web app context — what events to track, how to name them, how to connect pre-signup and post-signup behaviour, and which standard GA4 metrics to trust versus which to ignore.

The Core SaaS Event Model

SaaS tracking starts with agreeing on four event categories that map to the stages of your product lifecycle. These are not GA4 recommendations — they are the minimum surface area needed to answer the product questions that matter.

Authentication Events

The three authentication events are sign_up, login, and logout. GA4 includes sign_up and login in its recommended event list, which matters because Google Ads and the pre-built reports in GA4's User Acquisition section expect these exact names. Use them.

Both events must include a method parameter with the authentication mechanism: google, email, sso, github, or whatever providers your app supports. This lets you segment activation quality by auth method — in most SaaS products, Google OAuth signups activate at a materially different rate than email/password signups. Without the method parameter, you cannot see this.

More importantly, authentication events are the only events where you can reliably set user_id. The moment a user authenticates, set it in two places. First, in your GA4 config call:

gtag('config', 'G-XXXXXXXXXX', {
  user_id: 'your-internal-user-id'
});

Second, as a persistent user property so the ID survives across sessions:

gtag('set', 'user_properties', {
  crm_id: 'your-internal-user-id'
});

Use an internal user ID from your database, never an email address. Email addresses are PII and sending them to GA4 violates Google's terms of service. The internal ID is opaque to GA4 and lets you join GA4 behavioural data to your own user records in BigQuery after the fact.

Feature Usage Events

Feature usage events are the core of SaaS product analytics. The naming pattern that works best at scale is feature_[verb] — for example: report_created, export_clicked, integration_connected, dashboard_shared, filter_applied. This convention keeps events grouped when you sort alphabetically in the GA4 event report, and the verb tells you whether the action was initiated or completed.

Every feature event should carry three parameters at minimum:

• feature_name — a string identifying the specific feature, distinct from the event name. For example, an event named export_clicked might have feature_name: 'pdf_export' or feature_name: 'csv_export'.
• workspace_id — the account or workspace the action occurred in. Without this, you cannot distinguish a power user hammering one workspace from ten users each using the product once.
• user_tier — the plan tier at the time of the event (free, pro, agency). Sending this as an event parameter as well as a user property means you can analyse feature usage even for users who changed tiers since the event occurred.

gtag('event', 'report_created', {
  feature_name: 'ga4_audit',
  workspace_id: 'ws_abc123',
  user_tier: 'pro'
});

Trial and Conversion Events

The conversion funnel for a SaaS product typically spans four events: trial_started, upgrade_clicked, checkout_started, and subscription_activated. All four should be marked as key events in GA4 — not just the final purchase — because each step has its own drop-off rate and each is worth optimising independently.

The parameters that matter for conversion events:

• plan — the plan name the user is moving to (pro, agency).
• billing_period — monthly or annual. Annual conversions have different LTV implications and different churn curves.
• value — the MRR in decimal format, in your currency unit. For an annual plan priced at $588/year, send value: 49 (the monthly equivalent) rather than the lump sum. This keeps your GA4 revenue reporting coherent for month-to-month comparison.
• currency — the ISO 4217 currency code (USD, EUR, etc.). GA4 will record zero revenue if this is missing.

gtag('event', 'subscription_activated', {
  plan: 'pro',
  billing_period: 'annual',
  value: 49,
  currency: 'USD'
});

Fire subscription_activated from your backend via the Measurement Protocol rather than from the client. The client-side event fires reliably in most cases, but payment confirmation events are exactly where you cannot afford to lose data — a user closing the tab before the success page loads, an ad blocker, a slow network. Firing server-side on the confirmed webhook from your payment provider eliminates this class of loss.

Onboarding Funnel Events

Onboarding is the highest-leverage funnel in most SaaS products. Users who complete onboarding retain at dramatically higher rates than those who do not, and the steps between signup and activation are where the most fixable drop-off occurs. GA4's Funnel Exploration is built for exactly this analysis, but it requires each onboarding step to be a discrete, named event.

Track each step with a consistent event name and step metadata:

gtag('event', 'onboarding_step_completed', {
  step_number: 2,
  step_name: 'connect_google_account',
  completed: true
});

Use a single event name (onboarding_step_completed) with a step_name parameter rather than separate event names per step. This keeps your event report manageable and lets you build a single funnel in GA4 Explorations by filtering on the step names. If you use separate event names per step (e.g. onboarding_account_connected, onboarding_profile_completed), adding or renaming steps later requires rebuilding your funnel report from scratch. Parameterised step names give you more flexibility.

User Properties for SaaS Segmentation

There is a meaningful distinction between event parameters and user properties in GA4 that becomes particularly important for SaaS. Event parameters describe the event. User properties describe the user, and they persist across sessions — GA4 attaches them to every subsequent event that user triggers, not just the event where you set them.

For SaaS, the user properties worth registering are:

• user_tier — the current plan tier (free, pro, agency). The most important SaaS segmentation dimension. With this set as a user property, you can filter any exploration or report by plan tier — not just the events where you explicitly passed the tier as a parameter.
• subscription_status — trialing, active, past_due, canceled. Lets you build segments of users who have churned and see their last-session behaviour in retrospect.
• account_age_days — the number of days since the account was created, updated periodically (on login is a reasonable cadence). Lets you identify whether a behaviour pattern correlates with account maturity.
• company_size — if you collect this during onboarding. Particularly relevant for B2B SaaS where company size determines buying behaviour and feature adoption patterns.

Register each of these as custom user-scoped dimensions in your GA4 property settings under Admin → Custom definitions → Custom dimensions before you start sending them. GA4 only processes custom dimensions that have been registered, and it does not backfill — events that arrive before registration are permanently unprocessable for that dimension.

Update user properties whenever the underlying value changes. When a free user upgrades to Pro, call gtag('set', 'user_properties', {user_tier: 'pro'}) alongside the conversion event. If you wait until their next session to update the property, any events in the current session after the upgrade will carry the old tier value.

Cross-Domain Tracking for SaaS

Most SaaS products span at least two domains: the marketing site at yourdomain.com and the application at app.yourdomain.com. From GA4's default perspective, these are different domains. A user who clicks your pricing CTA, reads the comparison page, and signs up has their session broken at the domain crossing — GA4 sees a referral from yourdomain.com to app.yourdomain.com and starts a new session, resetting attribution. Marketing-influenced conversions are undercounted, direct traffic is overcounted, and the path from acquisition channel to activation is invisible.

Configure cross-domain tracking in your GA4 Data Stream settings under Configure tag settings → Configure your domains. Add every domain that hosts part of your user's journey:

yourdomain.com
app.yourdomain.com
checkout.yourdomain.com  (if you have a separate checkout domain)

GA4 handles the rest automatically — it appends a _gl linker parameter to links crossing these domain boundaries and reads it on the destination to maintain session continuity.

The less obvious configuration is referral exclusions. Many SaaS products use a third-party authentication provider — Auth0, Okta, Clerk, or similar services hosted on a different domain entirely. After a user authenticates, the provider redirects them back to your app. GA4 sees this as a referral from auth0.com or your-tenant.okta.com and starts a new session. The user's original acquisition channel is replaced with the auth provider as the source.

The fix is to add your auth provider domains to GA4's referral exclusion list, not to the cross-domain list. Cross-domain tracking is for domains where you want to preserve the _gl linker. Referral exclusions tell GA4 to ignore the referrer entirely when that domain triggers a new session — the session continues from wherever it was before the auth redirect. Configure this under Admin → Data streams → your stream → Configure tag settings → List unwanted referrals.

The 5 Biggest GA4 SaaS Tracking Mistakes

1. Tracking Only Marketing Pages, Not the App

The most common GA4 SaaS failure is having the tracking snippet on the marketing site but not inside the authenticated application. This is surprisingly easy to end up in: GA4 was initially set up by the marketing team for the website, the engineering team built the app separately, and nobody explicitly connected them.

The consequence is that your entire product funnel — activation, feature adoption, upgrade triggers, churn precursors — is invisible. You can measure traffic to your homepage and signups, but not what users do next. You cannot identify which features correlate with retention, which onboarding steps cause drop-off, or which user behaviour patterns precede cancellation. You are measuring the sales process and ignoring the product.

2. Using Event Names That Don't Match GA4's Recommended Schema

GA4 has a set of recommended event names that power its pre-built reports — the User Acquisition report, the Engagement report, the Monetisation overview. When you use these names, the data flows automatically into the relevant report sections. When you invent your own names for the same actions, you get raw event data that requires manual exploration to analyse.

The most common GA4 recommended events that SaaS products should use: sign_up, login, search (for in-app search), tutorial_begin / tutorial_complete (for onboarding), and any of the standard e-commerce events if you have in-app purchases. Events like user_registered or account_created are not wrong, but they sit outside the pre-built report infrastructure and require more manual work to use.

3. Missing user_id Linkage

GA4 assigns a client_id to each browser via the _ga cookie. This is what it uses to stitch sessions together into user journeys. The problem for SaaS is that a user's pre-signup sessions — reading your documentation, visiting your pricing page, starting a free trial — are associated with one client_id. Their post-signup sessions inside the app are associated with the same client_id only if they are on the same device and browser. If they read the docs on their work laptop and signed up on the same device, you have continuity. If they signed up on a different device or after clearing cookies, the sessions are disconnected.

Setting user_id via gtag('config', ...) tells GA4 to use your internal identifier as a higher-fidelity user identity. GA4 uses it in User ID reporting to stitch together cross-device sessions belonging to the same authenticated user. Without it, your reported user counts are overcounted and cross-device journeys are fractured.

4. Counting Pageviews Instead of Feature Usage in SPAs

Single-page applications use client-side routing — the URL changes when a user navigates between screens, but there is no HTTP request to the server and no full page reload. GA4's enhanced measurement "Page views" setting, which fires on browser history changes, catches some of these transitions. But it catches all of them indiscriminately, including transitions that are not meaningful navigation events: opening and closing modal dialogs, toggling sidebar states, expanding and collapsing filter panels.

The result is inflated pageview counts that do not represent user intent. A user who opens a filter panel and closes it three times has generated three pageview events. A user who opened and closed the same report has the same session-depth as one who navigated to three separate product features. Pageviews in a SaaS app are a proxy metric at best — they correlate loosely with engagement but tell you nothing about what the user was actually trying to accomplish.

The correct approach is to fire explicit feature events for meaningful navigations and actions, and either disable automatic pageview tracking in the SPA or supplement it with your own routing-based tracking that fires only on genuine screen changes.

5. Not Marking MRR-Relevant Events as Key Events

GA4 key events (what were called "conversions" until March 2024) serve two purposes. First, they surface as metrics in the standard GA4 reports. Second, and more important for most SaaS companies, they are what you import into Google Ads as conversion actions — the signal Google's bidding algorithms use to optimise campaign spend.

If subscription_activated is not marked as a key event, Google Ads cannot optimise toward it. Your campaigns will optimise toward whatever key event exists — often just page_view or session_start — which is effectively random optimisation. Marking the right events as key events is not a cosmetic setting. It is the mechanism through which GA4 data influences paid acquisition ROI.

The events to mark as key events for a SaaS product: sign_up, trial_started (if you have a trial), subscription_activated, and any feature event that you have identified as a strong activation signal — the "aha moment" event that predicts long-term retention.

SaaS Metrics in GA4 You Can Actually Trust

Not all GA4 metrics translate meaningfully to a SaaS context. Some are genuinely useful; others produce numbers that look plausible but measure something different from what you think they measure.

Metrics that work well for SaaS:

Engagement rate is a reliable activation proxy. GA4 defines an engaged session as one lasting more than 10 seconds, involving a conversion event, or involving two or more screen views. For a SaaS product, this correlates reasonably well with whether a user actually used something rather than bounced. An engagement rate on your onboarding pages that is significantly below your app's overall engagement rate is a signal worth investigating.

Key event rate by channel tells you which acquisition channels produce users who actually convert, not just users who arrive. A channel with high traffic and low key event rate is a warning sign; one with low traffic and high key event rate is an underinvested channel. This analysis is only possible if you have marked the right events as key events.

User cohort retention via BigQuery. GA4's native cohort reports are limited. The BigQuery export gives you raw session and event data that you can use to build proper DAU/MAU stickiness ratios, cohort retention curves, and feature adoption funnels by signup cohort. This is the most powerful SaaS analysis available from GA4 data, but it requires the BigQuery connection and SQL.

Metrics to treat with caution:

Session duration is unreliable in SaaS web apps. GA4 calculates session duration from the time between the first and last event in a session. A user who opens your app, reads a report for 20 minutes, and closes the tab without further interaction generates a session with a duration roughly equal to the time between page load and whenever the last automatic event (scroll, etc.) fired — which is often the first few seconds. The user's actual engagement time is invisible. Session duration undercounts deep, focused work and overcounts users who leave a tab open in the background.

Bounce rate has been replaced in GA4 by engagement rate, but if you are importing GA4 data into external tools and they surface a bounce rate, interpret it carefully for SPAs. In a single-page app where client-side navigation fires events, most sessions generate enough events to be classified as engaged — so the bounce rate may appear artificially low regardless of actual user engagement quality.

Session count is noisy. Session boundaries in GA4 reset after 30 minutes of inactivity (configurable) and at midnight UTC. A user who works in your app from 11:45 PM to 12:15 AM has generated two sessions. A user who was interrupted for 35 minutes mid-task has generated two sessions. For products used in long, continuous work sessions, session count overcounts activity in ways that do not reflect actual usage patterns.

FAQ

Can GA4 track SaaS user behavior?

Yes, GA4 can track SaaS user behaviour, but it requires deliberate configuration that goes beyond the default setup. The standard GA4 implementation is optimised for websites and e-commerce, not web applications. To track a SaaS product effectively, you need to implement custom events for feature usage, set user_id to link pre-signup and post-signup behaviour, register user properties for segmentation by plan tier, and handle cross-domain tracking between your marketing site and your application. With these in place, GA4 can produce reliable product analytics data. Without them, you get pageview counts that do not map to product value.

How do I track user_id in GA4?

Set user_id in two places: in the gtag('config', ...) call when a user authenticates, and as a persistent user property. Use your internal database user ID — never an email address or any other PII. The config call looks like this: gtag('config', 'G-XXXXXXXXXX', {user_id: 'your-internal-id'}). Also call gtag('set', 'user_properties', {crm_id: 'your-internal-id'}) so the property persists across sessions. You must also enable the User ID reporting identity in your GA4 property settings under Admin → Reporting identity — otherwise GA4 collects the ID but does not use it for user stitching.

What events should a SaaS app track in GA4?

The minimum useful event set for a SaaS product covers four categories: authentication (sign_up, login, logout with a method parameter), feature usage (using a feature_[verb] naming pattern with feature_name, workspace_id, and user_tier parameters), conversion funnel (trial_started, upgrade_clicked, checkout_started, subscription_activated with plan, billing_period, value, and currency), and onboarding steps (onboarding_step_completed with step_number and step_name). The exact events depend on your product, but these four categories cover the lifecycle questions that matter most for growth and retention.

How do I track MRR or revenue in GA4?

GA4 does not have a dedicated MRR metric, but you can approximate it by tracking subscription conversion events with a value parameter set to the monthly recurring revenue in decimal format (not cents). For annual plans, send the monthly equivalent rather than the annual lump sum to keep comparisons coherent. Always include the currency parameter or GA4 will record the event with zero revenue. For the most reliable revenue tracking, fire the conversion event from your backend via the Measurement Protocol on payment confirmation rather than from the client, where tab-close events and ad blockers can cause data loss.

Can GA4 track in-app behavior inside a web app?

Yes. GA4 is just a JavaScript library that sends events to Google's collection endpoint — it does not care whether the page it runs on is a marketing site, a dashboard, or a complex web application. The key differences from a standard website implementation are that you need to handle client-side routing explicitly (rather than relying on automatic page view tracking), you should implement user_id since users are authenticated, and you should fire custom events for meaningful product actions rather than relying on page views as a proxy for engagement.

How do I set up funnel tracking for a SaaS onboarding flow?

Fire a discrete event at each step of your onboarding flow — either a single parameterised event like onboarding_step_completed with a step_name parameter, or separate event names per step. Then build a Funnel Exploration in GA4 under Explore → Funnel exploration. Add each step as a condition matching the relevant event name and parameters. You can set the funnel as open or closed (closed means users must complete steps in order; open allows steps to be completed in any sequence) and segment by user property — for example, comparing onboarding completion rates between free and trial users. GA4 Funnel Explorations are retroactive up to the limits of your data retention window.

Does GA4 work with Single Page Applications (SPAs)?

GA4 has partial support for SPAs through its enhanced measurement setting, which fires a page view event when the browser history changes via the History API. This catches most client-side navigation events in frameworks like React, Next.js, and Vue. However, it also fires on non-navigational history changes (like modal open/close states in some implementations), which can produce inflated page view counts. The more reliable approach for SPAs is to disable automatic history-change page views and implement explicit navigation tracking in your router, firing a page_view event with the correct page_location and page_title parameters only when a genuine screen change occurs.

Should I use GA4 or Mixpanel for SaaS?

The honest answer is that most SaaS products benefit from both, used for different purposes. GA4's strengths are acquisition analysis (connecting paid and organic marketing channels to signups), Google Ads integration (importing key events for bidding optimisation), and free BigQuery export for raw data. Mixpanel's strengths are product analytics depth — it was built for SaaS and handles event-centric analysis, user-level journeys, and cohort retention natively without SQL. If you can only have one, GA4 is the better choice if marketing-to-acquisition analysis is the priority; Mixpanel is better if product-to-retention analysis is the priority. If you implement GA4 with the event model described in this guide, you get a reasonable approximation of Mixpanel-style product analytics alongside the acquisition data that GA4 does uniquely well.