How to share GA4 data with a dashboard, read-only

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

There are two practical ways to share GA4 data read-only with a third-party dashboard: grant OAuth access with the Viewer role at the property level, or create a Google Cloud service account with Analytics API access and add it as a Viewer on the property. Both stop short of giving the tool edit rights, user-management rights, or access to other Google services tied to your account.

Which one you use usually depends on the dashboard, not on you. Most consumer-facing tools use OAuth because it's a one-click "Sign in with Google" flow. Most developer-facing or multi-account tools use service accounts because they're easier to automate and don't expire when someone changes their password.

Option 1: OAuth with the Viewer role

This is the flow you get when a dashboard shows you a "Connect Google Analytics" button. Under the hood:

1. You click connect, Google shows a consent screen listing the exact scopes requested (usually analytics.readonly).
2. You choose which Google account to authenticate with — ideally a dedicated account or one you actually manage the property with.
3. The dashboard receives an OAuth token scoped to read GA4 data. It cannot rename dimensions, edit audiences, or invite new users.
4. You can revoke this at any time from your Google Account's Security > Third-party access page, independent of the dashboard's own settings.

The catch: OAuth access is tied to your GA4 permission level. If you're an Editor or Administrator on the property, the token technically inherits read access to everything you can read — but well-built integrations only request analytics.readonly, which limits what they can do even if they could theoretically see more. Always check the scope list on the consent screen before clicking allow.

Option 2: A scoped service account

Service accounts are the better fit if you're connecting a backend tool, a script, or a dashboard that supports server-to-server auth rather than user login.

1. In Google Cloud Console, create a new project (or reuse one dedicated to integrations — don't bolt this onto your production app's GCP project).
2. Enable the Google Analytics Data API for that project.
3. Create a service account and generate a JSON key.
4. In GA4, go to Admin > Property Access Management, and add the service account's email address as a Viewer, not Editor or Analyst.
5. Give the dashboard the JSON key. It can now pull reports via API but can't modify the property, add users, or touch other Google Cloud resources unless you've granted broader IAM roles — which you shouldn't for this purpose.

The advantage: you can revoke access instantly by removing the service account from Property Access Management, without touching any personal Google account settings. It also doesn't break if someone on your team changes their password or leaves the company.

What "read-only" doesn't cover

Viewer access still lets a tool read your full GA4 event stream, custom dimensions, audiences, and conversion data for that property — read-only means it can't write, not that it can't see everything. If you have multiple properties under one GA4 account and only want to share one app's data, make sure you're granting access at the property level, not the account level. Account-level access cascades to every property underneath it, which is rarely what you want when you're managing several apps' analytics from one Google account.

Also worth checking: GA4's Data API has default and standard quota tiers. If a dashboard is pulling data for several properties on a schedule, high-frequency polling can occasionally hit rate limits, especially on the free tier. This is a dashboard-side implementation detail, not something you control, but it's worth asking about if reports load slowly.

Why this matters more with multiple products

If you're running one app, sharing GA4 access to one dashboard is a five-minute task you do once. If you're running five or ten, you're repeating this per property, and it's easy to lose track of which tools have access to which apps — especially after you've killed off a couple of them and forgotten to revoke access. A periodic audit of Property Access Management across all your GA4 properties is worth doing quarterly, not just when you're setting up a new integration.

This is also where GA4 alone starts to feel thin for portfolio-level questions. GA4 tells you traffic and engagement per property. It doesn't tell you revenue, subscriber churn, or how a given app's traffic trend relates to its MRR trend without manually cross-referencing dashboards. If you're already stitching together Stripe or RevenueCat data by hand, see tracking Stripe and RevenueCat together for a related connector setup, or the metrics dictionary for how traffic and revenue metrics are typically defined and where they diverge.

Disclosure: SoleOS is a portfolio dashboard for solo founders, and this post is written by the company that makes it — so take the recommendation with that in mind. SoleOS connects to GA4 using OAuth or a service account, same as described above, requesting only read access and never write scopes. You can see the exact scopes and how to revoke them on the connectors page, and the underlying security model on the security overview.

You don't need SoleOS or any third-party dashboard if you're running one app and just want to check GA4's built-in reports occasionally — the native GA4 interface already answers most traffic questions well. It becomes more useful once you're checking traffic across several properties and want it next to revenue and subscriber data in one place instead of ten open tabs. If you want to see what that looks like before connecting anything real, the live demo uses sample data and doesn't require sign-up.

Frequently asked questions

Does read-only GA4 access let a dashboard see personally identifiable user data?

GA4 is designed to avoid exposing PII in standard reports — no names, emails, or precise identifiers are surfaced through the Data API in normal use. Viewer access shows aggregated and event-level data as GA4 collects it, which should already exclude PII if your GA4 property is configured correctly. If you've added custom dimensions that capture personal data, those would be visible to anyone with Viewer access, so audit your custom dimensions before granting third-party access.

Can I limit access to specific GA4 reports instead of the whole property?

No. GA4's permission model works at the account or property level, not per-report. Viewer access on a property means the connected tool can query any standard or custom report available in that property via the API. If you need finer-grained control, the only real lever is which custom dimensions and events you send to GA4 in the first place.

What's the difference between OAuth and a service account for this use case?

OAuth ties access to a human Google account and its login session; it's simpler to set up but breaks if that account's access changes. A service account is a non-human identity you add directly to the property, independent of any person's login — better for automated or backend integrations, and easier to audit since it shows up explicitly in Property Access Management.

How do I revoke access later if I stop using a dashboard?

For OAuth connections, go to your Google Account's Security settings and remove the app under third-party access. For service accounts, remove the service account's email from GA4's Property Access Management list, or delete the service account entirely in Google Cloud Console. Neither method requires contacting the dashboard vendor.

Will granting read-only access affect my GA4 data or reporting in any way?

No. Viewer-level access is strictly read: the connected tool cannot create audiences, edit event definitions, add users, or change data retention settings. Your GA4 configuration and historical data remain exactly as they were before you connected anything.