How to Build a Multi-Tenant GA4 Dashboard for SaaS Users

Author's Note

Hi, I'm Paloma, founder of Dashrendr. Early in my career, I was on a team that built a SaaS platform with user-facing analytics. We hit a wall with multi-tenancy — a bug caused one customer to see another's data. It was a nightmare that taught me a crucial lesson: data isolation isn't just a feature, it's the foundation of trust. This guide is the one I wish I had back then, focusing on a common but tricky scenario: delivering per-customer analytics with Google Analytics 4.

Disclosure: This article is published by Dashrendr. Where Dashrendr is relevant, I say so directly — including its limitations.

Introduction: The Multi-Tenant GA4 Challenge

Providing customer-facing analytics is no longer a luxury; it's a core feature for modern SaaS applications. Your users expect to see how they're using your product. While many analytics tools exist, Google Analytics 4 (GA4) is ubiquitous. But using it for per-customer dashboards presents a significant hurdle. This guide provides a developer-focused tutorial on how to build a multi-tenant GA4 dashboard, ensuring each of your customers sees only their data.

The core problem is that GA4 isn't inherently multi-tenant. It's designed to track one website or app for one owner. To make it work for a SaaS platform with hundreds of tenants (customers), you need a deliberate architecture. We'll walk through the most reliable method: using the GA4 Data API combined with Custom Dimensions to achieve true data isolation for each tenant.

What is Multi-Tenant Analytics?

First, let's establish clear definitions.

Definition: Multi-tenancy is an architecture where a single instance of a software application serves multiple customers. Each customer is called a tenant. In a multi-tenant setup, all tenants share the application logic and database, but their data is partitioned and kept isolated from other tenants.

Definition: Embedded Analytics refers to the integration of analytical capabilities and data visualizations within another software application. Our guide on embedded analytics covers this in detail.

Therefore, a multi-tenant GA4 dashboard is an analytics dashboard embedded within your SaaS application that displays GA4 data, where the architecture ensures that each tenant can only view the data relevant to their own organization. As the research firm Gartner noted, "By 2025, data stories will be the most widespread way of consuming analytics." Delivering these stories in a secure, multi-tenant environment is paramount.

The alternative, a single-tenant architecture, would mean deploying a separate GA4 property—and a separate dashboard infrastructure—for every single customer. This is operationally complex and financially unsustainable for any SaaS business expecting to scale.

The most scalable approach for multi-tenant GA4 analytics is to inject a `tenant_id` as a custom dimension at the source, allowing for efficient API-level filtering before data ever reaches your dashboarding tool. This makes your analytics layer inherently secure and performant.

The Unique Challenge of Multi-Tenancy with GA4

Unlike a SQL database where you can add a `tenant_id` column to every table, GA4's data model is more rigid. Out of the box, there is no concept of a "tenant." You can't just tell the GA4 interface, "Show me pageviews for Tenant XYZ." This presents the primary challenge: how do you tag the data itself so you can filter it programmatically?

Many developers first try to solve this by creating separate GA4 properties for each tenant. While this guarantees data isolation, it creates a massive scaling problem:

• Management Hell: Imagine managing API credentials, reports, and settings for 500 different GA4 properties. It's not feasible.
• High Costs: The GA4 Data API has quotas. According to Google's official documentation, there are limits on concurrent requests and daily tokens. Managing this across hundreds of properties is a recipe for getting rate-limited.
• Inconsistent Configuration: Any change to tracking or a custom report needs to be manually replicated across every single property, leading to inevitable drift and errors.

A much cleaner solution is to use a single GA4 property for your entire application and inject your internal `tenant_id` into the data you send to Google. This is achieved using a powerful feature called Custom Dimensions.

Step-by-Step Guide to Building a Multi-Tenant GA4 Dashboard

This tutorial assumes you have a SaaS application and a single GA4 property where you're already collecting user interaction data. We will now architect a multi-tenant solution on top of this.

Step 1: Create a `tenant_id` Custom Dimension in GA4

First, you need to tell GA4 to expect a new piece of information with every event. This is your tenant identifier.

Definition: A Custom Dimension in GA4 is a user-defined parameter that you can send with your event data. Google Analytics can then use this parameter for reporting and analysis. For our purposes, it's the hook we need for data isolation.

1. In your Google Analytics account, go to Admin.
2. In the Property column, click on Custom definitions.
3. Click the Create custom dimensions button.
4. Configure the dimension:
   • Dimension name: `Tenant ID`
   • Scope: `Event` (or `User` if you want to classify all events from a user under one tenant)
   • Description: `The unique identifier for a SaaS customer/tenant.`
   • Event parameter: `tenant_id`
5. Click Save.

That's it. GA4 is now aware of a parameter called `tenant_id` and will associate it with events. A recent study by Statista showed that over 29 million websites use Google Analytics, but only a fraction leverage advanced features like custom dimensions for sophisticated tracking.

Step 2: Send the `tenant_id` from Your SaaS Application

Now, you need to modify your application's tracking code. Whenever a logged-in user performs an action that sends an event to GA4, you must include the `tenant_id` for that user's organization.

For example, if you are using `gtag.js` to track a page view, your code might change from this:

gtag('event', 'page_view', { page_title: 'Dashboard' });

To this, where `current_tenant_id` is a variable populated from your backend when the user logs in:

gtag('event', 'page_view', { page_title: 'Dashboard', 'tenant_id': current_tenant_id });

This step is critical. Every event you want to show in a tenant-specific dashboard must be tagged with the `tenant_id`. This ensures that data from different customers is clearly distinguished within your single GA4 property.

Step 3: Query the GA4 Data API with a Tenant ID Filter

This is where the magic happens. Your backend server, which is responsible for fetching analytics data to display in the embedded dashboard, will now query the GA4 Data API. The key is to add a filter to your API request.

When you construct your API call to `runReport`, you will include a `dimensionFilter`. This filter tells the API to only return data that matches the specified `tenant_id`.

Your filter object would look something like this in JSON format:

"dimensionFilter": { "filter": { "fieldName": "customEvent:tenant_id", "stringFilter": { "value": "the-tenant-id-of-the-logged-in-user" } } }

By applying this filter, you ensure that the API response only contains data for the currently authenticated tenant. This is the core of multi-tenant data isolation. You are not fetching all the data and filtering it in your application; you are requesting only the necessary data from the source. This is more secure, faster, and respects API quotas.

Step 4: Visualize Data in an Embedded Dashboard

Once your backend receives the filtered JSON data from the GA4 API, the final step is to pass it to your front-end and render it in a chart. This is where an embedded analytics platform can save you months of development time.

You can build your own charting components using libraries like ECharts or Chart.js, but you'll also need to build a secure embedding mechanism, a dashboard builder, caching layers, and more. A dedicated platform like Dashrendr is built for this exact use case. You can push the filtered GA4 data from your backend to our REST API or connect directly to a database where you've stored it, and then use our visual dashboard builder to create and embed the analytics your users need.

How Dashrendr Simplifies Multi-Tenant GA4 Data

At Dashrendr, we designed our platform to handle multi-tenant scenarios natively. For GA4 data, you have two primary, equally supported paths:

1. Push via REST API: Follow the steps above to query the GA4 Data API from your backend, filter by `tenant_id`, and then push that pre-filtered, aggregated data to a Dashrendr dataset via our secure REST API. This is a robust and highly secure method that gives you full control.
2. Direct Connector (with a staging database): Use our native Google Analytics connector to pull data into a staging data warehouse like BigQuery. Then, use our BigQuery connector to build your dashboards. You would still apply the `tenant_id` filter within the SQL queries in Dashrendr.

Dashrendr provides the visual dashboard builder, the secure embedding, and theming so you can focus on your core product. You can build charts, apply custom branding, and embed a full analytics suite into your SaaS in days, not months. We offer a 14-day free trial with no credit card required, and our plans start at just $6/month, making powerful analytics accessible to every developer.

An Honest Limitation: One feature currently on our roadmap is cross-connection joins. This means that today, you cannot directly join data from our Google Analytics connector with data from our PostgreSQL connector within a single chart. For use cases that require combining GA4 data and your application database data, we recommend the REST API push method, where you perform the join in your backend before sending the combined dataset to Dashrendr.

Ready to see it in action? Try Dashrendr free and see how quickly you can build a secure, multi-tenant dashboard.

Your Multi-Tenancy Questions Answered

Based on common search queries, here are answers to related questions about multi-tenancy.

What is a multi-tenant data platform?

A multi-tenant data platform is a system where a single instance of the platform serves multiple tenants (customers), keeping their data logically separate while often physically co-located. This architecture, as explained by platforms like Tinybird, is the standard for SaaS as it's cost-effective and scalable. The key is implementing robust data isolation, such as row-level security, to prevent tenants from accessing each other's data.

What are the disadvantages of multi-tenancy?

The primary disadvantages of multi-tenancy are increased complexity and security risk. As detailed in guides on the topic, a single bug in your data isolation logic can lead to a data breach affecting all customers. The "noisy neighbor" problem is another issue, where one tenant's heavy usage could potentially impact the performance for others if the infrastructure isn't properly balanced. However, for most SaaS applications, the scalability and cost benefits far outweigh these manageable risks.

What is the difference between multi-tenant and user?

A 'tenant' is an organization or a group of users who share common access to a specific instance of the software. A 'user' is an individual account that belongs to a tenant. For example, in a project management SaaS, a company like 'Acme Corp' would be the tenant, and its employees (John, Jane, and Jack) would each be users belonging to the 'Acme Corp' tenant. All users within a tenant share the same data context.