I get asked a lot of times how you should create and organize accounts, properties and views in Google Analytics, but I typically answer that with a lot of questions. The true answer is that there is no ‘one’ answer to the question. It all depends on your website(s)/app(s) structure and your business needs.
In this post, I will share my methodology for structuring accounts, properties and views in Google Analytics.
Accounts are the highest level of hierarchy in Google Analytics and can contain multiple properties and views. It’s also important to know that users and filters can be managed at an account level, making it easy for you to manage user permissions and permissions as a whole for all of your views. This is highly important because if I wanted to apply a filter to more than one view, then I could do it at the account level instead of in each view individually.
Similar to view filters, I can do the same with user permissions. If someone moved around or was terminated from a company, I could handle that at the account level instead of at the view level. Hooray for efficiency!
Let’s imagine a part of your company launches a shiny new landing page for a new product launch and the marketing manager creates a new GA account to track it. Great! The site’s tracked, everything is working well and a year passes. After that year, the marketing manager decides to move on to a new job you’ve lost all contact with him/her. The replacement comes in and doesn’t have the password or access to the account. Whoops! Now you’re forced to go through a process to prove your ownership with that website/app and that’s not fun.
So when should I use an existing account or create a new one? Well the answer is pretty simple. Don’t set up another account unless you’ve hit your limit of 100 properties. Account permissions can always be added and removed and the last thing you want to do is have multiple accounts floating around.
Accounts were pretty easy and are focused more around management, but properties are much different. Properties are assigned a unique ID and are used to track users across a single session.
So when do I create a new property vs using an existing one? Well the answer isn’t that simple. When creating a new property, I like to ask myself the following questions:
- Is the user experience the same/similar to the rest of my primary site?
- Do I want to unify the session between the new site and my primary site?
- Are there any links from my new site to the primary site?
If the answer was no to any of these questions, then you’ll likely want to create a new property.
Let’s take that example where the marketing manager created a new landing page for a new product launch. We can assume the user experience is completely different from my primary site, lives on a separate top-level domain (TLD) and there are no links to the primary site. As an analyst, I can consider this landing page a completely different experience. In this case, I’d create a new property.
Now let’s imagine I create a new landing page for that product launch that shares the same look/feel, header and navigation from the rest of my primary site. In this case, I’d use my existing property because as an analyst, I consider this user in the same experience and I’d like to treat him/her in one unified session.
If you decide that you’d like to track a new site/page that’s on a completely different TLD, then don’t forget about setting up proper cross domain tracking. If the page/site is on a subdomain, then you don’t need to implement cross domain tracking. Instead you just need to make sure the cookiedomain is set to auto and add a referral exclusion to your property settings. There are plenty of resources out there and I recommend Luna Metrics’ blog post about it.
Again, there’s no straight answer to setting this up and it all depends on the user experience and how you’d like to analyze the data.
As opposed to properties that control all of your data at a user and session level, views take that data and break it down to report what matters to you. Views can be set up to report on site sections, website environment, country, language and more. Remember that user permissions can also be set at a view level, so you might set them up based on what property data you want to share with your users.
So when do I create a new view? Well it’s all based on if you want to break down reports at a HIT (did I say HIT) level for your users. This is much different that segments because view filters are applied at the hit level, whereas segments are applied at the user or session level.
For starters, I would always create the following four views:
- A completely unfiltered view for all of your website data
- A filtered production view that contains data for your live site with internal or unwanted site traffic out
- A staging view for your staging website
- A test view to apply new filters before you add them to your production view. It’s important to note that filters are not retroactive, so you want to be sure they’re working properly first.
Let me provide you with some other scenarios…
I have a website with multiple languages where the content and user experience stays the same. I’d like to analyze how each of the languages perform independently and collectively.
Use 1 property and create a view for each language in addition to another view with all of the traffic. You’ll configure the filters based on the URL structure. So if the Spanish version’s URLs are ‘/es’, then you’ll set up a filter to include traffic where the page contains ‘/es’.
I have a website with multiple site sections that translate to our industry verticals. I’d like to provide access to data to individual business units based on the industry vertical they tie to.
Use 1 property and create a separate view for each of these industry verticals based on the page URL.
I have a new landing page for a new ad campaign. The landing page’s look and feel is the same as my primary website and shares the same navigation and footer. This landing page is on a separate TLD from my primary website. I’d like to analyze the way users interact with this page and how it drives conversions on another section of the website.
Use 1 property and don’t create a new view. Since there’s no requirement to isolate the performance of the landing page, we won’t need to do that. Also, since we want to understand how the landing page interactions contribute towards conversions, we’ll use a segment for doing that. In addition, we’ll need to make sure cross-domain tracking is implemented; Otherwise, a new session will start when the user clicks to another page on the website and cause multiple issues.
It’s extremely important that anyone managing a GA implementation understands these concepts. Remember to think business-first when considering how to set up an account.