Welcome to another blog article in my GA4 series, where my mission is to help you make the most of Google Analytics 4 (GA4), one blog at a time.

Google has been forcing and warning anyone with a Google account to migrate their GA4 property before the sunset of Universal Analytics on the 1st of July. However, not many businesses go beyond the basic implementation, and by the time you realise it might be too late to restructure your GA4 account.

In this blog post, I will explain the terminology used in GA4 as well as examples of account structure for different types of businesses and some considerations.

GA4 Account Terminology

First things first, let’s cover the terminology in GA4 because some things have changed since Universal Analytics.

Account

The Google Analytics Account has the same meaning as before. In most cases, a business only needs one Google Analytics Account. An account can have multiple properties, including multiple Universal Analytics and GA4 properties which might be set up to collect different sets of data. You can use the same Google Analytics account for multiple websites or apps, and have a further split on property-level.

Property

The Property level is the first option to segment traffic and users in a meaningful way. In GA4, the Property can track both website and mobile app data, which wasn’t possible with Universal Analytics before. When you are viewing data in GA4, keep in mind that you are viewing the data at property-level. We will cover how you should structure your property based on how your business is structured later in the article.

Data Streams

Think of Data Streams as the sources of data for your GA4 property (and I will refer to them as such). They are the level below Property just like Views in Universal Analytics, although they do not function the same way. You need to have at least one Data Stream for your GA4 property to be able to receive data. This data can come from a website, a web app, or a mobile (Android/iOS) app. The data is then combined and deduplicated on property-level, which was not possible before in Universal Analytics.

Subproperties and Roll-up Properties

Note that there are two more structural levels available for users of Google Analytics 360. Subproperties are kind of like Views and they allow you to create a subset of data from the GA4 property. With Roll-up Properties, you can combine data from two different GA4 properties or subproperties. Visit Google’s support article if you need more information about these GA4 360 features.

What is the best structure for my GA4 account?

Now that we have the basics covered, let’s get into the actual implementation. When you (or Google) first create a GA4 property, it asks you to also create a Data Stream from which data will be flowing. Hence, the most basic but also most common structure that most businesses will have is:

Account > GA4 Property > Data Stream (usually a website).

In a lot of cases, this structure is actually enough for a small business that only has one brand and one website without any apps. If that’s the case for you, you can skip to the last chapter: GA4 Account Structure Considerations.

GA4 Property Structure

If your setup is a bit more complex, you will first need to establish if you have multiple brands or domains, and whether their data needs to be kept separate.

When thinking about the structure of GA4 Properties, you need to keep in mind that you cannot see data from multiple properties combined if you are using the free version of GA4. This is the main consideration when thinking about how many GA4 properties your account should have.

If you have multiple separate brands or domains and you don’t really need to see the data combined, then you should create a separate property for each brand. Also, if you have different Google Ads, Google Search Console, or BigQuery accounts for each of these domains or brands, you will need a separate property to connect each account individually. Although if it’s common for your users to cross your domains, I would recommend to set up one property for both so you can better analyse the user behaviour.

If you only have one brand or domain, then it’s best to only set up one GA4 property. If you have a multi-ligual website (but on the same domain or subdomain), I would also recommend to set up only one GA4 property. Since there is no easy or free way to combine the data of two properties in GA4, keep all the data in one property if you need to see how users behave across the different segments of your website visitors (such as different languages).

If you have one domain, but you use different subdomains to split your website (such as ebooks.website.com, or support.website.com), you need to think whether the data from these subdomains would make more sense in isolation or combination. For example, if you have an app., support., and www. subdomains, it might make sense to keep them under the same property to ensure continuous tracking of the user journey.

GA4 Data Stream Structure

When thinking about how to structure the Data Streams, you should consider each Data Stream as a data source from which user behaviour data can flow. You don’t really have many options here but the main distinction is whether you have an app that you want to track traffic for. In GA4 you can connect to a Website, iOS app, or Android app.

If you only have a website, your Data Stream Structure will be very simple and you will just have one Web Data Stream.

If you have a Web App, which is very common for SaaS or B2B businesses that have apps or portals hosted on the same domain as the marketing website, it is still recommended to keep the web app and website on the same Data Stream. Google recommends not separating your website and web app into two Data Streams and advises having a maximum of one Data Stream per GA4 Property. They claim it is because each Data Stream is treated as a separate data source, so it could cause data inflation.

I don’t really understand why this would be the case though because iOS and Android Data Streams are also different data sources, yet the data is deduplicated between these Data Streams in the reports. I will be testing this with my own website very soon and will post a link when the outcomes of that investigation are available.

GA4 Account Structure Considerations

Some additional things you might want to consider when setting up GA4.

1. Creating a separate property for testing

This is optional but recommended, especially if you are used to having a “Test” or “Raw” View in Universal Analytics. You can replicate something similar in GA4 if you have a lot of testing or development traffic, which is currently not possible to exclude with filters like it was in Universal Analytics. You can create a [Raw] property for every domain and this property should receive the same data sources as the main property.

2. Google Search Console can only link to one Data Stream in one Property

This is an important consideration if you have added multiple Data Streams to the same GA4 Property but want to connect them to Google Search Console separately. This is not possible to do, as you can only like one Google Search Console account to one Data Stream within a Property.

3. Different currencies and time zones should be separated

If you have several regional subdomains, you might want to separate these into different GA4 properties so you can ensure the correct timezones and currencies are used for each region. This is important if you rely on Data Imports from other sources or have ecommerce/transactional data that requires accurate time or currency values.

4. Property Access Management

If you have several subdomains, but you have a strict access policy, it is best to separate the subdomains that need more strict access permissions.

Conclusion

In conclusion, for most businesses, the simple structure of Account > Property > Website Data Stream is more than enough. However, there are more complex cases which require further consideration when thinking about your GA4 account structure. For example, businesses that have multiple brands or domains will benefit from separating their domains into different properties. Whereas for businesses that have different parts of their business hosted on different subdomains, it is recommended to consider if you would like to see how users interact between these subdomains or keep the data separate. It is always best to think about the structure early on, to avoid running into issues in the future and realising that data cannot be combined or analysed in ways you had hoped.