[GA4] Compare filters, subproperties, and user roles

Explore the different ways to restrict access to your data and how to generate reports on specific subsets of data within your property

Whether you're a small business with one website or a large business with many brands and products, you likely care about the data that you and others in your property can access.

Subproperties, report filters, data filters, and user roles provide different ways to manage the information you collect from your websites and apps and surface that information in reports.

Difference at a glance

The following table compares features offered in Google Analytics:

  Subproperties User roles Report filters Data filters
Primary use case Governance Restrict access to data via permissions Ad-hoc report customization Data hygiene
Access control Property-level access control Account and property-level access control Report-level access control Property-level access control
Availability Analytics 360 properties only Available to all properties Available to all properties Available to all properties
Retroactive No Yes Yes No
Permanently modify data Yes No No Yes

Differences in depth

The following sections provide a more in-depth comparison of the features outlined above:

1. Governance

The primary use case for subproperties is governance, that is, controlling which users have access to a subset of a source property.

Subproperties are useful when you want to restrict access to sensitive or confidential data, or when you want to control access to different subsets of data; for example, you can restrict access by department, project, or user group.

Governance should be used when certain groups of users should not have any access to a subset of the data in a property. In instances where governance is not needed, features such as reports, explorations, and others (see below) should be used instead.

2. Access restriction

Google Analytics allows you to assign roles with different sets of permissions at the account and property levels. By assigning roles, you can restrict what users with access to a property can do in the property and whether the users can see cost and revenue data. This use case can also be addressed using subproperties, although this option incurs a cost.

3. Ad-hoc report customization

You can customize report collections and apply filters to provide more curated experiences for the people who use your Google Analytics property, such as for increased efficiency and the ability to focus on specific data sets at one time.

For example, one team at your company wants to see ecommerce purchases by mobile users, while another team wants to see ecommerce purchases by web users. You could customize the left navigation to include two reports: the first report could include only web data, and the second report could include only mobile data.

Note that filters are not meant for governance and can be temporarily removed by users. For that reason, data filters are meant for curation and convenience rather than governance.

4. Data hygiene

Data filters allow you to prevent incoming data that you classify as internal or developer traffic from being processed by Google Analytics and surfaced in reports. This ensures that your company employees and unwanted referrals don't skew or misrepresent your data.

Once a data filter is applied, its effects are permanent and cannot be undone. For example, if you apply an exclude filter, the excluded data is never processed and won't be available in Google Analytics.

Sample use cases

For example, consider the following use cases:

  • To see data by region or device, use report filters and customization.
  • To restrict access to certain teams for security purposes, use subproperties.
  • To restrict access to cost and revenue data, assign more restrictive user roles.
  • To prevent internal traffic from being processed, use data filters.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
6475875157376361323
true
Search Help Center
true
true
true
true
true
69256
false
false