GA4 Account, Property, and Data Stream: Understanding the 3-Level Hierarchy.

If you've spent any time in Universal Analytics, GA4's structure will feel slightly off at first. UA had three levels: Account, Property, and View. GA4 kept the first two and replaced the third with something that sounds similar but works completely differently. The result is a hierarchy that confuses everyone who learned analytics on UA — and even some who didn't.

This guide explains what each level of the GA4 hierarchy controls, why the View layer was removed and what replaced it, and how to structure GA4 correctly for organizations with multiple websites, apps, or business units. Get this structure wrong and you'll either contaminate your data across separate properties or lose the cross-platform stitching that makes GA4 worth using.

The Three-Level Hierarchy

Account

An account is the top-level container in GA4. It holds one or more properties, and access granted at the account level flows down to every property inside it. Most organizations have a single GA4 account that holds all their properties — your main site, your staging property, any app properties — under one roof.

Large organizations with multiple independent business units sometimes use one account per unit, which keeps access control hard-separated: a user with account-level access in Business Unit A cannot see anything in Business Unit B's account. This is the right call when the units genuinely operate independently and you don't want any cross-unit data visibility. For most companies, though, one account is the correct answer.

Account-level settings in GA4 are mostly organizational — there are no account-level data filters (those live at the property level), and there is no account-level reporting. The account exists primarily as an access-control boundary and a container.

Property

A property is the core analytical unit in GA4. Each property has a Measurement ID (formatted as G-XXXXXXXXXX), and all data collected under that ID flows into the property's reports. Conversion definitions, audience lists, BigQuery exports, Google Ads links, data filters, and custom dimensions are all configured at the property level. When you "set something up in GA4," you are almost always setting it up at the property level.

The standard rule is one property per logical data entity — usually one website or one app. If you're running a single website, you have one property. If your marketing site and your web app are separate domains but represent one continuous user journey, they may share one property. If they're genuinely separate products with separate analytics needs, they should be separate properties.

Access is also managed at the property level. You can add a user to a specific property without giving them any access to other properties in the same account. This matters a lot for agencies — you should almost always be added at the property level, never at the account level.

Data Stream

A data stream is a source of data flowing into a property. A single GA4 property can have up to 50 data streams: one for your website (a web stream), one for your iOS app, one for your Android app. All three streams feed into the same property — the same reports, the same audiences, the same conversion metrics.

The purpose of multiple streams on one property is cross-platform user journey tracking. If a user reads a blog post on your website and then purchases through your mobile app, GA4 can stitch those sessions together (when the user is signed in on both platforms via Google Account) and show you the complete path. This requires both platforms feeding into one property via separate streams — it cannot work if the website and app are separate properties.

Each stream has its own configuration: Enhanced Measurement settings apply per-stream (web only), stream-specific measurement protocols are defined per-stream, and the stream-level Measurement ID is what goes into your gtag or GTM configuration. A common mistake is treating "Measurement ID" and "property" as synonyms — the Measurement ID belongs to a specific stream within a property.

What GA4 Removed: Views

Universal Analytics Views were filtered subsets of property data. A typical UA setup might have three Views per property: one raw unfiltered View (for data recovery), one main filtered View (internal traffic excluded), and one test View (for experimenting with filters before applying them to the main View). Teams that audited their UA configurations regularly found properties with 10, 15, even 20 Views — "only UK traffic," "only mobile users," "only paid search sessions" — each one representing a different slice of the same data.

GA4 removed Views entirely. The replacement has two parts. Data Filters (under Admin → Data Settings → Data Filters) handle the most common use case: excluding internal traffic and excluding developer traffic. These operate at the property level and apply to all reports. For more flexible segmentation — the kind UA Teams used per-View — GA4 uses Comparisons, which are applied at reporting time rather than at ingestion time. You create a comparison for "mobile only" or "paid search only" inside a report, without filtering the underlying data at all.

For teams that depended heavily on Views, this is a real workflow change. The good news is that Comparisons are non-destructive: the underlying data is always complete, and you apply different lenses at analysis time rather than losing data permanently through a filter. The harder news is that anything requiring permanently stored, pre-filtered datasets — like the raw backup View pattern — needs to move to BigQuery exports and post-processing instead. GA4 is not the right place to store 12 different filtered versions of your data.

How to Structure GA4 for Multiple Websites

Option 1: One property per website (recommended)

This is the standard, correct approach for the vast majority of organizations. Each website gets its own GA4 property, its own Measurement ID, its own conversion definitions, its own audience lists. Data is clean and isolated — changes to one property's configuration cannot affect another. Reporting in each property tells the story of that site with no noise from other data sources.

The only potential downside is that you cannot easily compare properties side by side within GA4's native interface. If you need cross-property comparisons, the right tool is Looker Studio (free, connects to multiple GA4 properties as separate data sources) or BigQuery (where you can query across exported tables from multiple properties).

Option 2: One property for multiple related websites

This approach makes sense when two or more domains represent a single continuous user journey and you want to track users across both without session breaks. The typical scenario is a main marketing site on one domain with a checkout or SaaS app on a different domain — a user who lands on example.com, browses, and then completes a purchase on app.example.com or checkout.otherdomain.com.

To implement this correctly, you need cross-domain tracking configured in GA4 — the additional domains listed under the stream's "Configure your domains" setting — and the same Measurement ID firing on all domains in the journey. GA4 passes a _gl parameter in links between the domains to stitch the sessions together. Without this configuration, each domain transition resets the session and GA4 reports referral traffic from your own checkout domain, which is both inaccurate and a pain to filter out later.

One property for multiple sites only works when the user journey genuinely spans all of them. If the sites are independent products or serve different audiences, combine them into one property only if you can tolerate the reporting complexity of filtering by hostname in every report you run.

Option 3: One property for web and app

This is the scenario multiple data streams were designed for. If your product has both a web presence and a mobile app, and the user journey moves between them — a user who discovers you via the website and converts in the app, or vice versa — then a single GA4 property with a web stream and an app stream is the right architecture.

The cross-platform user stitching works through Google Account sign-in. When the same Google Account is logged in on both the website and the app, GA4 can associate activity across both streams into a unified user journey. This requires the User ID feature to be enabled on both streams and the same user identifier (typically your own internal user ID) to be set via gtag('set', 'user_id', ...) on web and via the Firebase Analytics setUserId call on mobile.

Without signed-in identity linking, cross-platform stitching is probabilistic at best. If your mobile app and website serve entirely different audiences or aren't meaningfully connected, separate properties are cleaner.

Practical Access Control

Account-level vs property-level access

Adding someone at the account level grants them access to every property in that account — present and future. Adding them at the property level restricts them to that one property. This distinction has real consequences for agencies and consultants who manage client analytics.

The correct practice for external parties is property-level access only. Never hand an agency account-level Administrator access unless you've explicitly considered that they will have full access to every property in the account, including any you create later. A well-run agency should ask for property-level Editor access on the specific properties they work on, nothing more.

Audit your account-level user list periodically. Former employees, past agencies, and contractors from completed projects are the most common source of lingering access — and account-level access means they can still see everything. GA4 does not send notifications when account-level users are added or removed; you have to check the Admin panel manually.

GA4 user roles

GA4 has five roles, each granting progressively more capability:

• Viewer — Read-only access to reports and explorations. Cannot create or modify anything.
• Analyst — Can create and manage Explorations and Annotations. Cannot change property configuration.
• Marketer — Can create and manage Audiences, Conversions (Key Events), Attribution models, and modify some reporting settings. Cannot change tag configuration or data streams.
• Editor — Full configuration access: data streams, data filters, custom dimensions, integrations, and all Marketer-level capabilities. Cannot manage users.
• Administrator — Full access including user management. At the account level, this means managing users across all properties.

Roles are additive across levels. A user who is a Viewer at the account level but an Administrator on a specific property can make any configuration change to that property. The effective permission is always the higher of the two. For most team members doing day-to-day analysis, Analyst is the right role. Editors should be the people who own the analytics implementation. Administrators should be a very short list.

Frequently Asked Questions

What is a GA4 account?

A GA4 account is the top-level container that holds one or more GA4 properties. It's primarily an access-control boundary — users added at the account level can access every property within it. Most organizations have one GA4 account. Accounts are created at analytics.google.com and appear in the Admin panel under "Account" settings.

What is a GA4 property?

A GA4 property is the core unit of analytics measurement. Each property has a unique Measurement ID (G-XXXXXXXXXX), and all data collected under that ID flows into the property's reports. Conversions, audiences, data filters, BigQuery exports, and Google Ads links are all configured at the property level. The standard approach is one property per website or app.

What is a GA4 data stream?

A data stream is a source of data feeding into a GA4 property. Each stream has its own Measurement ID and its own collection settings. A property can have up to 50 data streams across web (one), iOS, and Android platforms. Multiple streams on one property enable cross-platform user journey tracking — the same user on your website and your mobile app can be tracked as a single user journey within one property.

What is the difference between a GA4 property and a data stream?

A property is the analytical unit — it holds your reports, conversions, audiences, and all configuration. A data stream is a data source that feeds data into that property. Think of the property as a database and the data stream as a connection from a specific platform (web, iOS, Android) into that database. One property, multiple potential streams. The stream's Measurement ID is what you put in your gtag or GTM configuration.

Can one GA4 property track multiple websites?

Yes, but it requires cross-domain tracking to be configured properly. You list the additional domains in the web stream's "Configure your domains" setting, and GA4 passes a _gl parameter in cross-domain links to stitch sessions together. This is appropriate when the sites represent one continuous user journey (e.g., a marketing site and a checkout on a different domain). If the sites are independent products, separate properties are the cleaner choice.

How many data streams can a GA4 property have?

A GA4 property supports up to 50 data streams. In practice, most properties have one to three: one web stream for the website, one for iOS, one for Android. The limit is rarely a constraint. Note that you can only have one web stream per property (unlike iOS and Android, where you could technically add multiple streams for different apps, though having multiple app streams per platform on a single property is unusual).

What replaced Views in GA4?

Views were replaced by two mechanisms. Data Filters (under Admin → Data Settings → Data Filters) handle permanent exclusions like internal IP traffic. Comparisons handle on-the-fly segmentation within reports — applying a "mobile only" or "paid search only" lens at analysis time without permanently filtering the data. For use cases that required permanently stored, pre-filtered datasets, Google's recommendation is to export raw data to BigQuery and apply filtering there.

Should I have one GA4 property per website or one for all websites?

One property per website is the recommended approach for most organizations. It keeps data clean, prevents cross-contamination of reporting, and makes property-level configuration (conversions, audiences, filters) straightforward. The exception is when two or more sites represent a single continuous user journey — in that case, one property with cross-domain tracking configured is more accurate than separate properties that break the journey at domain transitions. If the sites are independent products with different analytics needs, separate properties are always the cleaner choice.