How to Track Multiple Web Apps and Environments in One GA4 Property

Setup GA4 for multiple applications on multiple environments

Hi,

we are currently setting up GA4 to integrate them in our (web) applications. In our company we have a main portal (my.company.com) where multiple applications are deployed into (my.company.com/app1, my.company.com/app2, … and so on).

Besides our production system all these applications are running on development and testing environments, using different URLs (my-dev.company.com/app1, my-test.company.com/app1,…).

We wonder what the best way is to setup our GA4 properties and have the following questions:

1. Is it best practise to have a single GA4 property for all the applications? If so: can we split data per application (eg: all the data of /app1)

2. Is it best practise to have a different property per environment (dev, test, prod)?

3. Is there a certain way to split traffic from the different environments?

Other tips & tricks are welcome!

Thanks,

The short answer is:

The long answer is:

For question 1, you absolutely can and should use a single GA4 property for your main portal and all its sub-applications (my.company.com, my.company.com/app1, my.company.com/app2, etc.).

Since they all run under the same root domain and are likely part of a single, continuous user journey, a single property provides the most comprehensive and holistic view of your user behavior, which is the core goal of GA4.

GA4 automatically tracks subdomains, and since your applications are deployed into sub-directories (paths), you can easily split the data using built-in dimensions like Page path and screen class or Page location.

A better approach is to set a custom dimension in Google Tag Manager to capture the application name, say App Name, based on the URL path.

For example, if the page URL contains /app1, set the app_name event parameter to App 1.

You would then register this parameter as a Custom Dimension in GA4, allowing you to filter all your reports and explorations by application.

You’ll want to ensure that all internal links between the main portal and the sub-applications do not start new sessions by checking your cross-domain/subdomain linking setup, although for sub-directories this is usually handled automatically.

For question 2, yes, it is best practice to have a different GA4 property for each environment, meaning one for production, one for testing, and one for development.

The primary reason is to prevent bad or non-production data from polluting your live analytics reports.

If you use a single property, you’d have to rely on Data Filters to exclude traffic, but these are limited and only work moving forward, and they can be easily misconfigured.

Dedicated properties ensure complete data isolation.

You should set up your tags in Google Tag Manager so that it detects the environment (e.g., based on the Page Hostname variable containing dev or test) and dynamically uses the correct GA4 Measurement ID for that environment.

For question 3, once you’ve set up separate properties for dev and test, traffic separation is inherently achieved by sending data to the correct Measurement ID.

For your production property, you should implement a Data Filter to exclude any known Internal Traffic, which can be defined by the IP addresses of your company and team.

It’s also critical to ensure that traffic from your staging or development sites is blocked from your production property.

You can achieve this separation at the Google Tag Manager level by setting up a Lookup Table variable that maps the environment hostname to the corresponding GA4 Measurement ID, ensuring your live tag only fires on the production domain.

A highly effective and relatively cheap way to build a robust and future-proof analytics pipeline that addresses all these concerns is by combining server-side tagging with the Google Analytics Measurement Protocol, Google Tag Manager, and cloud infrastructure.

You would use server-side Google Tag Manager, possibly hosted on a service like Stape or your own Google Cloud Platform instance, to act as an intermediary data collection point.

Your web application would send all its event data to this server container instead of directly to GA4.

This provides immense control.

In the server container, you can use the Google Analytics Measurement Protocol to format and forward the data to your separate GA4 properties.

Here’s why this is great:

The server-side container can inspect the incoming request, read the hostname (my-dev.company.com vs.my.company.com), and use this logic to dynamically route the data to the correct production or testing GA4 property.

It allows for strict separation without needing complex client-side rules that can be bypassed.

Secondly, it can inject the custom app_name event parameter based on the URL path right there on the server before sending the page_view or any other Standard Event like click or generate_lead to GA4.

This ensures clean, consistent data across all events.

Server-side tagging also enhances data quality, improves page speed by offloading processing from the user’s browser, and provides better resilience against client-side tracking blockers.

Finally, for reporting, the Google Analytics Data API allows you to pull clean, filtered data into powerful visualization tools like Looker Studio, where you can then build custom dashboards to compare application performance or segment by your custom App Name dimension across all production data.

This provides maximum flexibility, control, and data integrity.

About The Author