A well-structured Google Analytics account is essential to tracking your web and app data in an organized fashion, allowing your team to effectively analyze and act on the data.
Best practices
The general best practices for approaching Google Analytics account structure are below:
- Create a single Google Analytics account for your entire organization.
- Create a property for each domain. Create a property for each app. Create a roll-up property (360-only feature) for each category or group of relevant sites and apps.
- Create at least three (3) views in each property:
- Raw - a view with little to no configurations
- Test - a view to use for testing, iterating, and verifying configurations before applying them to a main view
- Main - the main, fully-configured view that your team uses to analyze data
Main considerations
While the best practices above may apply to several organizations, certain needs or situations may necessitate a divergence from the above recommendations, particularly around property creation. Key factors in reporting, integrations, and scale should be considered when finalizing your own account structure.
Reporting
If a certain set of sites are closely-related and hence, likely need to be analyzed in aggregate, a single property solution may suffice, even if they are composed of multiple domains.
A common example of this involves a related set of domains used as microsites for marketing purposes. Even if these microsites utilize multiple domains, it may make sense to utilize a single property ID for all of them to simplify setup and reduce unnecessary effort of creating separate properties.
Integrations
Google Analytics integrates with other Google products, like Google Ads, Campaign Manager 360, Display & Video 360, and Optimize. It is beneficial to keep these potential integrations, which typically occur at the property level, in mind as you structure your Google Analytics properties.
The Google Ads integration, which pulls cost and click data into Google Analytics, will bring in all of the cost data into an associated property. This means that if a Google Ads account focuses on paid search initiatives for a certain site, it may make sense to link Google Ads accounts only to closely-related properties in Google Analytics.
For Optimize, you can only link an Optimize container to a single property. For this reason, the sites covered by the property play an integral role in feeding Optimize with the needed Google Analytics data as you run your experiments.
Scale
There may be cases when, due to the sheer number of the sites you manage, you need to consolidate properties into groups pertaining to region, business unit, market, or relative relevance. Part of the reason is that you may run into Google Analytics limits to the number of properties you can create per account.
If, during planning, your desired structure reaches properties in the hundreds, connect with your service partner, or Google account manager to discuss options.
Referral treatment of internal domains
If you own several internal domains, traffic between them could be treated either as referrals, or as "direct" traffic.
If you want to see referral traffic from a.com to b.com (or from b.com to a.com) in your reports, then a structure with separate properties for a.com and b.com should be utilized. In the property for b.com, "b.com" should be set as a referral exclusion, but not "a.com". Conversely, in the property for a.com, "a.com" should be set as a referral exclusion, but not "b.com".
If you don't want to see referral traffic from a.com to b.com (or from b.com to a.com) in your reports, then a single property structure that includes a.com and b.com should be utilized. In this property, both "a.com" and "b.com" should be set as referral exclusions. Make sure that you setup cross-domain tracking between the two domains as well.
Specific use cases
Take this situation as an example for illustrating a few use cases below: a user searches on google.com, then clicks on a Google Ads result that navigates them to a landing page on a.com. Within the same session, the user clicks on a link on a.com that takes them to a landing page on b.com.
Use case 1: Disparate domains
Domains a.com and b.com are generally separate businesses with different stakeholders and KPIs. Nevertheless, you need to build audiences based on data from both these domains. Additionally, you would like to get a holistic view across the entire organization.
Recommendation: Use two separate properties, and a roll-up property
- Use Property 1 for a.com and Property 2 for b.com.
- Use these properties to create remarketing audiences that are specific to each business individually.
- Create a roll-up property (360 feature) using properties 1 and 2 as source properties.
- Setup cross-domain tracking to track user navigation between a.com and b.com.
- Configure referral exclusions for both a.com and b.com on the Roll-up property referral exclusion list so that original referral information is preserved. Note that with this approach, you will not see sessions where a.com led to b.com, or vice versa.
- Use this property to create remarketing audiences with conditions that may involve both domains.
Result
| Property 1 (a.com) | Property 2 (b.com) | Roll-up property | |
|---|---|---|---|
| Source | a.com | ||
| Medium | cpc | referral* | cpc |
| Referral | -- | a.com | -- |
| Client ID | 1234 | 1234 | 1234 |
| Sessions | 1 | 1 | 1 |
Use case 2: Similar domains, and fully-integrated as single site
Domains a.com and b.com are generally similar and you need to build audiences based on data from both these domains. You would like to preserve the original referrer information, rather than see referrals from one domain to another.
Recommendation: Use one common property with referral exclusions
- Create one common property (Property 1) for a.com and b.com.
- Setup cross-domain tracking.
- Use this property to create remarketing audiences with conditions that may involve both domains.
- Configure referral exclusions for both a.com and b.com in order to preserve original referral information. Note that with this approach, you will not see sessions where a.com led to b.com, or vice versa.
Result
| Property 1 | |
|---|---|
| Source | |
| Medium | cpc |
| Referral | -- |
| Client Id | 1234 |
| Sessions | 1 |
Use case 3: Similar domains, but count referrals to each other
Domains a.com and b.com are generally similar, and you would like to build audiences based on data from both these domains. You also need to see referrals from one domain to the other, even if it means breaking up a session as it crosses domains.
Recommendation: Use one common property without referral exclusions
- Create one common property (Property 1) for a.com and b.com.
- Setup cross-domain tracking.
- Do NOT configure a referral exclusion list in the property settings. Instead, modify the tracking code so that it checks for current hit's domain value and compares it with the domain value of the hit's referrer:
- If the values are the same, then update the referrer field to a blank value.
- If the values are different, then do not update the referrer field.
Result
| Session 1 | Session 2 | |
|---|---|---|
| Source | a.com | |
| Medium | cpc | referral |
| Referral | -- | a.com |
| Client Id | 1234 | 1234 |