# GA4 setup for SaaS and apps: the events and settings that matter

Canonical URL: https://www.martechdevs.com/blog/ga4-setup-saas

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-08-21

Last updated: 2026-09-08

A useful GA4 setup for SaaS connects acquisition to an observable business outcome. It should tell you where qualified visitors came from, whether they completed registration or a lead request, and which measurable outcomes followed. Build that path deliberately: one collection owner, consistent consent and identity, accurate events, selected advertising goals and a verified export. Installing a tag is only the first step.

## Define the decisions GA4 needs to support

Start with three questions your team will actually review:

- Which acquisition sources bring people who complete a meaningful registration or lead request?
- Where does the journey from marketing site to application or checkout lose people?
- Which outcomes should inform Google Ads reporting and bidding?

Write down the decision each answer could change. If nobody will act on a metric, it does not belong in the initial implementation simply because GA4 can collect it.

Keep the unit explicit. A person registering, a workspace starting a trial and a billing account paying an invoice are different entities. An invited teammate might create a new user without creating a new potential customer. Decide whether your acquisition KPI counts all registrations, new self-serve workspaces or sales-qualified accounts.

GA4 can support behavioural analysis. Use another product analytics tool when your team needs a different workflow for account-level adoption, detailed journeys or repeated experimentation, rather than assuming a second tool is mandatory. The [product analytics setup guide](https://www.martechdevs.com/blog/product-analytics-setup) helps define those events without turning this implementation into an inventory of every click.

For billing truth, retain the billing system's records. GA4's collected purchases are an analytical view with collection and attribution boundaries; they are not your accounting ledger.

## Establish ownership, property and stream structure

Create the account under business ownership with more than one appropriate internal administrator. Give implementers the access they need and document who can publish tag changes, approve metric definitions and change advertising goals. Avoid making an agency employee's personal access the only route into the account.

For a single SaaS product, a reasonable starting design is one production property covering the marketing website and product experience. Use a separate test environment so automated tests and test purchases do not pollute the production baseline. More complex businesses should decide boundaries based on ownership, access and reporting needs before adding properties.

During property creation, choose the reporting time zone and currency deliberately. Add the appropriate web, Android or iOS data stream and install the corresponding collection mechanism. Google's [website and app setup instructions](https://support.google.com/analytics/answer/14183469?hl=en) describe that sequence. Record the selected identifiers and settings in the implementation document.

Time zone is a reporting definition, not a cosmetic preference. A midnight boundary affects comparisons with Ads, your warehouse and billing reports. Agree how cross-system reconciliations will align dates before investigating differences.

For a marketing site and web application representing one connected journey, decide whether they use the same web stream. Cross-domain measurement requires the same `G-` ID on the participating pages. A stream for every hostname can accidentally make the intended journey harder to connect.

## Give every event one collection owner

Inventory the code already present before installing anything. Look for a Google tag in the application, a CMS integration, GTM, a consent platform integration, a Firebase web SDK and any server-side forwarding. Two teams can each install a working solution and still create duplicate collection together.

Choose the owner of the initial page view, route-change page views, registration events and purchase events. A server-side tagging layer does not automatically mean the browser has stopped sending directly to GA4; trace both paths.

For GTM, configure the Google tag for the intended web stream and initialize it before dependent event tags, with consent defaults established earlier through the supported consent integration. Use Preview to inspect a complete journey before publishing. For a code-owned implementation, put initialization in one controlled application entry point and expose documented event helpers.

Use the same event definitions in either path. A [tracking plan](https://www.martechdevs.com/blog/tracking-plan) should name the business trigger, emitter, required fields, identity, consent handling and duplicate-prevention rule. GTM is a delivery mechanism; it cannot decide whether an account was actually created successfully.

![SaaS acquisition measurement links campaign entry, registration, value and purchase to reviewed advertising goals and retained event data](https://www.martechdevs.com/assets/blog/ga4-setup-saas.svg)

The diagram shows the measurement design, not a promise that every visitor is observable or that attribution proves a campaign caused a purchase.

## Make consent behaviour part of the release

Integrate the CMP or chosen consent mechanism before using collected data as a baseline. Test first visits, an existing saved choice, a changed choice and the transition into the application. The site's approved consent policy determines the expected behaviour.

Google distinguishes basic consent mode, which blocks Google tags until consent, from advanced implementations that load tags with consent defaults and adjust behaviour accordingly. Do not choose between them solely to increase reported numbers. [Google's consent overview](https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=en) explains the collection differences.

In Tag Assistant, inspect the initial state and subsequent updates for the relevant consent types. Verify that tags behave accordingly on both the marketing site and app. [The consent debugging guide](https://developers.google.com/tag-platform/security/guides/consent-debugging) provides the verification procedure.

A release fails this check if one sender ignores the saved choice, the application resets consent unexpectedly or a redirect interrupts an update. Record what was tested and the expected limitations. You need a trustworthy description of what the implementation measures before you can interpret a conversion rate.

## Preserve the journey across domains and application routes

### Marketing site to application

For separate root domains, configure the participating domains in the web stream's Google tag settings and verify that navigation carries the `_gl` linker parameter. Both sides need the same web-stream tag ID. Check redirects and forms as well as direct links; redirects can remove the parameter before the destination reads it. Google's [cross-domain instructions](https://support.google.com/analytics/answer/10071811?hl=en) cover these conditions.

For subdomains, inspect cookie-domain behaviour rather than assuming the hostname alone creates a break. Test the actual path a prospect takes: marketing page, sign-up form, authentication redirect, application welcome screen and checkout return.

Do not add campaign UTMs to every internal navigation link to “preserve attribution.” Keep acquisition tagging on the external entry links your campaign process owns. For internal navigation, measure the action or destination without inventing another campaign visit.

Do not treat a hosted payment or authentication domain as a domain you can necessarily tag. Establish which systems you control and what their supported return flow exposes. Hiding a referral is not evidence that you preserved the user's measurement context.

### Single-page web applications

Choose automatic history-based page views or an explicit route-change implementation for the relevant navigations. Do not allow both to emit the same view. Google's [GTM SPA tutorial](https://developers.google.com/analytics/devguides/collection/ga4/measure-spa-gtm) describes disabling automatic history-based views when implementing the manual GTM path.

Also distinguish the first load from later navigation. `send_page_view: false` controls the configuration call's initial page view; it does not disable enhanced measurement's history listener. [The page-view reference](https://developers.google.com/analytics/devguides/collection/ga4/views?hl=en) documents both controls.

Test a direct deep link, forward navigation, browser back and a full refresh. Inspect the page location and referrer values for each intended virtual page. Avoid treating every tab, modal or filter change as a page unless that is your documented navigation model.

### Native mobile apps

Use the Google Analytics for Firebase SDK for the relevant platform and verify the app is connected to the intended project and Analytics property. Google's [platform quickstarts](https://firebase.google.com/docs/analytics/get-started) cover Apple, Android and other supported runtimes.

Keep event meanings consistent across web and app where the business action is the same. A web registration and app registration can share the same conceptual contract while using different SDK calls. Verify app screen measurement, background and foreground behaviour, offline delivery and platform-specific consent separately.

Web cross-domain linking is not a substitute for an app attribution and deep-linking design. If paid acquisition crosses from a web ad into a native app, add that path to the implementation scope explicitly.

## Track outcomes with precise triggers

Begin with a small set that explains the acquisition journey. Use Google's [recommended event reference](https://developers.google.com/analytics/devguides/collection/ga4/reference/events) where the documented meaning fits. Create a custom event when the business action needs its own definition.

For a typical self-serve SaaS, evaluate these candidates:

- **`page_view`:** a meaningful web page or virtual page is displayed; use the collection ownership rules above.
- **`sign_up`:** the application successfully creates a user registration. Include an appropriate method value, and distinguish invited users from a new buying journey in your analysis.
- **`generate_lead`:** a relevant lead request is successfully accepted. Do not trigger it merely because a person clicked Submit or viewed a form.
- **`trial_started`:** a custom event for the first successful creation of the trial entitlement you defined, such as a workspace trial. A user's sign-up is not automatically a trial start.
- **`activation_completed`:** a custom milestone only if you can define a reliable, observable value outcome. Make the definition explicit and version it when it changes.
- **`purchase`:** a confirmed transaction with the appropriate value, currency, transaction identifier and items.

Do not mark all of these as advertising objectives by default. Page views help diagnose journeys; they rarely express the same commercial intent as a qualified lead or confirmed purchase.

For each outcome, test a success, a failure, a retry and a repeated visit. If a failed API response still sends `sign_up`, fix the application trigger. If reloading the confirmation page creates a new purchase, fix event ownership and deduplication before optimising a campaign against it.

### Keep revenue values consistent with the transaction

The following is an illustrative browser event for one confirmed USD 99 plan purchase. It assumes the Google tag and consent handling are already configured and that this browser path is the chosen sender. Replace the example values from verified transaction data; do not paste it into production as a test transaction.

```javascript
gtag("event", "purchase", {
  transaction_id: "inv_demo_1042",
  currency: "USD",
  value: 99,
  items: [
    {
      item_id: "pro_monthly",
      item_name: "Pro monthly subscription",
      price: 99,
      quantity: 1
    }
  ]
});
```

Google's [ecommerce documentation](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce) defines purchase and refund payloads, including event-level currency when sending value and item-level price and quantity. The example's item total is 99 × 1 = 99. If you separately send tax, do not silently include it in an item subtotal that your definition says excludes tax.

Define whether a transaction represents the first payment, a renewal or another charge. Reuse the identifier for a retry of that same transaction and issue a different identifier for a genuinely different transaction. Do not use one subscription ID for every renewal payment.

Keep new-customer acquisition reporting separate from repeat billing. A stream of recurring payments can make an acquisition goal look healthy while new customer creation falls. Your billing records should support the distinction independently of the browser's availability.

If the authoritative sender is a server integration, build that path explicitly. Google's [Measurement Protocol guidance](https://developers.google.com/analytics/devguides/collection/protocol/ga4) says it supplements browser or app collection and warns of partial reporting in server-only implementations. Do not add a second sender and assume the two paths deduplicate every event automatically.

## Use person identity and a small number of useful dimensions

Assign a stable application person ID through GA4's User-ID feature when appropriate, rather than an email address, company name or a shared account identifier. Users in the same customer account are still different people. Keep account membership available in your business data for account-level analysis.

For web tagging, Google's [User-ID implementation guide](https://developers.google.com/analytics/devguides/collection/ga4/user-id) distinguishes signed-in users, visitors who have never signed in and users who signed out. Clear the prior ID with the JavaScript value `null` after logout; do not send the literal string `"null"` as a shared identity. Avoid registering User-ID as a custom dimension.

For initial reporting, consider a controlled set of event parameters such as `signup_method`, `signup_context`, `plan_tier` and `trial_type`. Define their meanings and valid values. Register the fields needed in the interface with the correct scope; collecting a parameter and creating a reportable custom definition are separate steps. [Google's custom-dimension guide](https://support.google.com/analytics/answer/14240153) explains that relationship.

An event's plan tier should describe the relevant moment if that is the question being asked. A user's current plan is a different field. Do not overwrite the meaning of an acquisition cohort by silently treating today's account status as its historical status.

Review URLs and payloads for personal information and secrets before release. Avoid sending email addresses, authentication tokens, free-text form contents or customer document names as ordinary analytics fields. Prefer controlled categories where they answer the question.

## Review key events and Google Ads goals separately

A GA4 key event marks an action important to the business. A Google Ads conversion is used for advertising measurement and, depending on the goal configuration, optimisation. Google supports creating conversions from Analytics key events. [Its terminology guide](https://support.google.com/analytics/answer/13965727?hl=en) describes that relationship.

Start with the outcome you can measure reliably. A sales-led product might prioritise a qualified lead accepted in the CRM. A self-serve product might use a validated trial or first purchase. Choose based on business meaning, coverage, delay and the available learning signal, then check downstream customer quality.

Audit the actual key-event list, including events marked through product defaults or linked advertising features. Google's [key-event instructions](https://support.google.com/analytics/answer/13128484?hl=en) describe current automatic markings. Do not assume the list contains only choices your team made manually.

In Google Ads, inspect which goals each campaign uses. Primary actions participate in bidding when their standard goal is used; secondary actions are generally observational. A secondary action included in a custom goal can still be used for bidding. [Google's primary and secondary documentation](https://support.google.com/google-ads/answer/11461796?hl=en) covers that exception.

If both an imported GA4 action and a separate Ads tag measure the same purchase, reconcile the implementations before including both as equivalent optimisation signals. The [key events and conversions guide](https://www.martechdevs.com/blog/ga4-key-events) covers the choice in more detail. Never assume that every valuable event deserves the same bidding weight or that every report will count it identically.

## Set retention, export and traffic controls before relying on history

Choose event retention based on the analysis you need and the organisation's data policies. Standard properties offer 2 or 14 months for relevant event history. Increasing the setting cannot recover deleted data. [Google's retention documentation](https://support.google.com/analytics/answer/7667196?hl=en) explains the scope and exceptions.

If future joins or granular history are part of the plan, configure BigQuery export early. Select the intended Cloud project, data location, streams and export type, then confirm that tables actually arrive. Keep an owner for billing, permissions and export monitoring. [Google's export setup](https://support.google.com/analytics/answer/9823238?hl=en) describes those controls and export-failure conditions.

Budget for the ongoing dataset. Standard daily export has a 1-million-event daily limit, and streaming is best-effort. Do not treat a configured link as proof of complete retained history or expect the raw export to reproduce every interface metric. [Google's export reference](https://support.google.com/analytics/answer/9358801?hl=en) defines those boundaries. The [GA4 BigQuery guide](https://www.martechdevs.com/blog/ga4-bigquery-export) explains the next modelling steps.

For internal web traffic, test the filter before activating it. Google states that active exclusion is permanent and excluded events are unavailable in both Analytics and BigQuery. Its [internal-traffic guide](https://support.google.com/analytics/answer/10104470?hl=en) describes the Testing state. A broad office or VPN rule should not quietly remove real customer traffic.

## Accept the implementation through one complete journey

Use a labelled test case with a known entry link and expected outcome. In a test environment, follow the same navigation, consent and authentication path a customer uses. Include a failed attempt and a retry so the test checks meaning as well as delivery.

## Checklist

- [ ] The initial visit arrives in the intended property and stream.
- [ ] Consent defaults and updates behave as specified across the journey.
- [ ] Initial and virtual page views occur once at the intended navigation points.
- [ ] Registration or lead completion requires confirmed success.
- [ ] User-ID is set and cleared at the correct authentication boundaries.
- [ ] Each business transaction has the intended identifier, amount, currency and items.
- [ ] Required custom parameters appear on the events where they belong.
- [ ] Key events and campaign conversion goals match the agreed business outcomes.
- [ ] Processed reports and export records are checked after their respective delays.
- [ ] The business owner can explain remaining gaps and approve the metric definitions.

Reconcile a small, known set of registrations or payments against the application's records. Classify differences by cause: test exclusions, consent or delivery limitations, duplicate triggers, mismatched dates or different business definitions. Do not force the systems to agree by deleting the inconvenient rows.

For ongoing monitoring, track required-field coverage, duplicate business identifiers, unexpected event names and sudden changes by stream or application release. Investigate discrepancies where they affect decisions, rather than chasing a universal perfect match across platforms.

If you need help connecting the marketing site, app, consent layer and advertising goals, an [analytics and tracking implementation](https://www.martechdevs.com/analytics-tracking) should end with this evidence, a maintained tracking plan and named owners. The team should be able to verify its next release without starting the investigation again.

## Frequently asked questions

### Should the marketing website and SaaS app use one GA4 property?

For one product and a connected acquisition journey, that is a reasonable starting design. Confirm access, privacy and reporting requirements first. The stream and cross-domain design must support the journey; using one property alone does not establish continuity.

### Do I need GTM to use GA4?

No. Choose a supported collection path that your team can own and test. A code implementation can suit an engineering-owned application; GTM can help teams manage tags. The priority is consistent event meaning and clear ownership of each trigger.

### Can GA4 measure product activation?

Yes, if you define and collect an appropriate milestone. Decide whether the unit is a person, workspace or account, and whether the event represents the first qualifying achievement. Use a product analytics or warehouse workflow when the required analysis goes beyond the reporting model you can maintain in GA4.

### Should every sign-up be a primary Ads conversion?

Only if that action is the intended optimisation outcome and is measured reliably. Invited teammates, low-quality registrations and repeated actions can weaken the signal. Compare the proposed goal with downstream qualification or payment before relying on it for acquisition decisions.

### When is the setup finished?

The first release is ready when the agreed journey passes collection, consent, identity, outcome and reporting checks, with limitations documented. It still needs maintenance as the application, consent platform and campaign goals change. Assign that ownership as part of the setup.

## Sources

1. [Google: Set up Analytics for a website or app](https://support.google.com/analytics/answer/14183469?hl=en)

2. [Google: Consent mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=en)

3. [Google: Troubleshoot consent mode](https://developers.google.com/tag-platform/security/guides/consent-debugging)

4. [Google: Set up cross-domain measurement](https://support.google.com/analytics/answer/10071811?hl=en)

5. [Google: Measure SPAs with GTM](https://developers.google.com/analytics/devguides/collection/ga4/measure-spa-gtm)

6. [Google: Measure pageviews](https://developers.google.com/analytics/devguides/collection/ga4/views?hl=en)

7. [Firebase: Analytics platform quickstarts](https://firebase.google.com/docs/analytics/get-started)

8. [Google: Recommended event reference](https://developers.google.com/analytics/devguides/collection/ga4/reference/events)

9. [Google: Measure ecommerce](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce)

10. [Google: Measurement Protocol overview](https://developers.google.com/analytics/devguides/collection/protocol/ga4)

11. [Google: Send user IDs](https://developers.google.com/analytics/devguides/collection/ga4/user-id)

12. [Google: About custom dimensions and metrics](https://support.google.com/analytics/answer/14240153)

13. [Google: Conversions versus key events](https://support.google.com/analytics/answer/13965727?hl=en)

14. [Google: Mark events as key events](https://support.google.com/analytics/answer/13128484?hl=en)

15. [Google Ads: Primary and secondary actions](https://support.google.com/google-ads/answer/11461796?hl=en)

16. [Google: Data retention](https://support.google.com/analytics/answer/7667196?hl=en)

17. [Google: Set up BigQuery Export](https://support.google.com/analytics/answer/9823238?hl=en)

18. [Google: BigQuery Export](https://support.google.com/analytics/answer/9358801?hl=en)

19. [Google: Filter out internal traffic](https://support.google.com/analytics/answer/10104470?hl=en)