Should one single property be used for all sections of a website, or a number of separate properties the better choice?
This post aims at explaining why I believe that separated properties are sometimes better than a single property. I will, of course, try to provide you with all the necessary information for making an informed decision, and if you think of anything I may have missed, please leave a comment or contact me. Thanks!Before we dive into the details, let’s make sure we are all referring to the same terminology…
- Property – According to Google’s documentation, when using your Google Analytics account you can create a property for each domain, site, source or environment for which you would like to collect data. Each property has its own tracking code with its own unique ID for identifying data from that property.
- Views – Each property can contain one view or more. “A view is a defined perspective of the data from a property, and provides access to the reports for that property” (Google’s documentation). In other words, you can include a specific subset of data in a view by applying filters. For example, you can filter out all traffic that is not to a specific domain (should your property track more than one domain) or you can choose to only include organic traffic (if you want to provide a view for your SEO contractor).
- Google Analytics Account – Each Google Analytics account can include one property or more. Make sure not to confuse this with the term “Google Account”: One Google Account can contain up to 25 Google Analytics accounts (check out this post if you reach this limit but wish to have more than 25 accounts).
Please note that in some places Google uses the term profile instead of view, but as far as I can tell, both terms represent the same entity and I will use the term view throughout this post.
So now let’s begin with the main advantages of using multiple properties.
The first reason why using multiple properties is my prefered choice is that in most cases it enables you to use complete data, not just sampled data.
Sampled data often occurs with relatively large sites when using a single property, and is of course not always optimal. If your query includes more than 500,000 visits, Google Analytics will only return sampled data. For example, if your site generates 1,000,000 visits per month, Google Analytics will use sampled data as the default on your reports.
You can overcome this by changing the date range to less than a couple of weeks, but this might not always be a long enough period for your analysis.
Although sampled data often suffices, it is difficult to work with if you want to dive deeply into specific cases, if you need precise numbers, or if you wish to tackle a certain issue with your tracking. This is especially true when receiving a sample rate of less than 70-80%. For more details check out this article.
You can solve the overall data sampling issue by creating subsets of your data using views – but that only helps with standard reports. Since session sampling is done on the property level, creating multiple views will not avoid data sampling when applying advanced segments or creating customized reports. You can find more information about data sampling here.
Google Analytics’ Limitations
The second reason why using multiple properties is my prefered choice, rather than using a single property of the free Google Analytics, are the limitations that occur when working with a large website:
- Data Collection – Google Analytics has a limit of 10 million hits per month – or at least that’s what Google states. From my past experience, Google does process more than this amount, but I’m not sure if it processes all of the data, or just more than this stated limit.
- Data Freshness – If you have more than 200,000 visits a day, Google processes the data once a day – which could lead to a delay of two days in your data refreshness. I have also noticed that with large numbers of visits, custom variable values in standard reports are not updated for up to 3 days, but I am not 100% sure that this is necessarily due to the large amount of data sent (the data is, however, available in the API, even if the GA reports have not yet been updated in the reports).
Clear Separation between Web Properties
Most websites today have more than one web property, such as the main site, a blog, support center, landing pages, etc.
When installing Google Analytics on a website, the first and most trivial thing to do is try to aggregate all of them under the same property. Why? Because it supposedly sounds right that a user who visits the main site and then moves on to the support site or blog will be only counted once by Google Analytics. The common misconception is that if you implement a different property with a different tracking code for each of the company’s websites (e.g., one for the main site, one for the blog, and one for the support site), then you will not be able to tell how many users in total visited your brand’s properties (as the user who visited the main site and then the blog will be counted twice instead of just once).I believe that aggregating all your sites together, is in most cases the incorrect thing to do, but before expanding on why, I would like to give an example: Let’s say I have a Service-as-a-Software application, which includes two sections: (1) the main website (for potential clients), and (2) the authenticated web site where my clients can manage the services. It definitely makes more sense to divide the 2 into two separate sections.
Let’s take the KISSmetrics site as an example: Many people I know (myself included) read the KISSmetrics blog almost on a daily basis, but most of these people have never visited their main site and will never become their customers. That might be the reason why KISSmetrics divides their site into two separated properties in Google Analytics: one for the blog and one for the main site. Otherwise, think what their overall bounce rate would be, or their conversion rate from visits to registration, if their blog was defined as part of their main site property.
Once I’ve decided to separate the website into a number of properties, I like to start at the end and work backwards, first examining each section and deciding which of them should have a separate property. I always want to achieve as great a separation as possible (unless I have a good reason not to). As each web property is, in most cases, targeted at a different audience type (with different behaviors), it makes sense to separate the main website from the service site, just as it makes sense to separate the blog, the support site, and the landing pages.
My rule of thumb is to divide a site into properties based on the personas who will be using the site. For example:
- Blog readers vs. potential clients vs. registered clients
- Free vs. paying customers
- Traffic from online marketing campaigns vs. organic traffic
The total number of visitors, visits, bounce rates, pageviews, etc. are of no interest whatsoever, and are not actionable. Acting based on such data could lead to significantly incorrect conclusions, and worse.
Each persona uses a site differently. Let’s, for example, look at the differences between KISSmetrics blog readers and paying customers:
- Most Blog Readers arrive at the site through organic searches, blog feeds, and social shares. Most will read a post and then leave the site. This translates into a high bounce rate, tons of unique visitors and visits, no. of pages per visits close to 1, extremely low conversion rate to customers, low visit duration, relatively high percentage of new visits, and so on.
- On the other hand, Paying Customers arrive at the site in order to login. This leads to a low bounce rate, not many unique visitors and visits, a high number of pageviews and a high ratio of pages per visits, zero conversion rate to customers (since they are already customers), high visit durations, low number of new visits, and so forth.
You get the picture. If KISSmetrics only had one property, with many more blog readers than paying customers, their overall analytical metrics would be incorrectly influenced by the blog readers.
There are two alternatives that can be used instead of multiple properties: Google Analytics allows you to segment the data (using advanced segmentation) or you can separate the segments into separated views. That way you can have blog readers in one view and paying customers in a different view – but both under the same property. Be cautious, however, if you choose either of these methods, as I will now explain.
Advanced Segmentation – Not a Great Alternative
The advanced segmentation feature is considered less effective for long term segmentation purposes. It is a great way to run ad hoc queries, but if your SEO manager is interested in one specific segment, she will have to re-choose this segment each time she looks at the data. Moreover, if you want your SEO manager to only see SEO traffic, this feature will not help you achieve that.
And one more thing – when it comes to large sites, Advanced Segmentation always uses sampled data.
Separated Views under one Property – Also not a Great Alternative
At this point you might ask yourself why not just use separated views under one property. Although this method has advantages, it does have disadvantages as well – both of which I will present now:Advantages:
- It is much easier to manage from the developer point of view. You only have to deal with one tracking code for all of your sites, and everything else can be achieved in Google Analytics by the administrator.
- Working with different views gives you the option to enjoy the best of both worlds: You can obtain a holistic view (in the default view without filters) and have separated views for the various personas
Besides the fact that setting up cross domain tracking can be a real pain, the main reason I prefer to keep away from this method is the fact that maintaining separate views under the same property is not an easy task – especially when it comes to large, complex sites, with numerous sections and domains. For example, you cannot undo changes in the filter once they have been made, and the lack of a good debugging tool for your filters can cause data to be inaccurate. (Plus as I mentioned earlier, when using multiple views, you cannot avoid receiving only data sampling on non standard reports.)
To emphasize these disadvantages, following is a true story of one of my clients. Most of their traffic came from display campaigns. All traffic to the main website and landing pages was collected by one property in Google Analytics, with three views: (1) Master (no filters at all), (2) Non-Media traffic (traffic to the site from non media sources) and (3) Media traffic (traffic to the site with campaign information passed in the URL).
At some point, one of the media buyers accidently created a Pop-Under Campaign to one of the landing pages – but forgot to set the campaign tracking parameters.
Of course, all traffic from that campaign went into the Non-Media Traffic View. Needless to say, this profile became useless from that moment on. All metrics went “crazy”, as Pop Under Campaigns have an extremely high bounce rate, low ratio of pages per visit, and a high number of unique visitors and visits. (Completely the opposite of Non-Media Traffic…). Oops.
The only person to blame here, besides the media buyer, was me – the person who created the profile. What I should probably have done was set the filter by the first page that the user viewed (as landing pages can only be accessed by Media Traffic).
Although this could also happen with multiple properties, in my experience, implementing the logic in your code as to which tracker to use (preferably via a tag manager):
- Makes maintenance so much easier.
- Reduces the possibility of mistakes.
If for example you use multiple views, with one view for registered users and another for everyone else, then you will not be able to create the filter without sending this information (registered or not) to Google Analytics (in the user defined value for example)
In the past there were certain disadvantages to using multiple views under one property, but they have been resolved. I will however mention them in brief, just to provide a complete picture:
- In the past, you could not set different permissions for a user across views under the same property. Once you set users as an administrator, they had administration rights to all views. (Today, however, you can set permissions up to the view level so one user can be an administrator of one view and have no access to a different view).
- The Real Time Reports presented raw data in the past, so you could not see filtered data for a specific view. (Today filters are applied on your real time reports).
- Some metrics were calculated based on raw data. (Today all metrics are calculated only based on the filtered data).
What are the disadvantages of working with multiple properties?
I never said the choice was easy. I just said that you have to make an informed decision. So following are two main disadvantages to using multiple properties (with possible work-arounds)
Viewing all data in one place
Google Analytics does not provide a way to aggregate or view data from multiple properties. You cannot, for example, see an overview of all your traffic if your blog readers are being tracked in one property, your potential clients in a second one, and your existing clients in a third. On the other hand, there is no real value in obtaining overall numbers regarding different types of personas.
Having said that, I do understand why some people (usually the highest paid person in the company) may want to have a “dashboard” with these numbers. There are several relatively easy ways to achieve this information:
- The most simple method is to define an additional Roll-Up Property that tracks all sections under one property and is only used to show high level metrics. This excellent article will explain you all about using a roll up property and multiple trackers in Google Analytics.
- A different approach is to create a dashboard and obtain data from Google Analytics using the API. This may sound complicated but there are several ways of achieving this without any coding:
- Using a dashboard service such as geckoboard or ducksboard – these excellent (and beautiful) services will allow you to display widgets from different accounts on the same dashboard. The biggest downside, however, to using these services is the fact you will need a programmer to create an aggregated KPI for all properties together.
- Importing all the data to Excel and creating a summary sheet, using services such as Excellent Analytics that will transfer the data from your account to Excel.
- Using Google Analytics Report Automation Script created by Nick Mihailovski from Google. This is an awesome script that allows you to create an aggregated view of all of your properties and present it using Google Docs, spreadsheets or Google sites.
Total no. of users
If each property counts users separately, a user who visits two different sections of my site will be counted twice, instead of just once.
If you really care about the number of users you have overall, there is a relatively easy way to do so, as follows. This solution will also help you better understand the flow of your users across the different sections of your site. (Unfortunately, the Flow Report in Google Analytics is not good enough when you have numerous visitors, visits, pages and sections).
So what you have to do (and you can take the following solution and create your own variation based on your requirements) is mark each user on their very first visit to any of your sites. Once you have determined this, you can inform your Google Analytics using Custom Variable or Custom Dimension.
For example, let’s say all my properties (blog, support, landing pages, main site, forums, etc.) are under the same domain (as subdomains or subdirectories). Setting a domain level cookie (*.yourdomain.com) on all of your pages will share that cookie across all properties. That way, the first time the user visits any of your pages, this cookie will be empty and you will know that this is the first time the user has ever visited the site (or has cleared his cookies – which is the same for Google Analytics).
All you have to do now is filter the data on your dashboard by this custom variable (the condition will be: custom variable is not empty).
If you store the name of the section the user just visited in that custom variable, you will also be able to break down the number of visitors according to the first section they saw.
You can expand of this method for many other uses – and is useful even if you only work with a single property. If you are wondering how to use the same method on a site with multiple domains (not subdomains) where you cannot share the same cookie (as cookies are per domain), you can sync the cookie using an iframe that will be called from all domains and will return the cookie value as a parameter in the URL.
(By the way, using an iframe to sync cookies is much more accurate and reliable compared to using the cross domain tracking code suggested by Google, but that is completely off topic and I will write a separate post about it in the future. You are welcome to contact me in the meantime if you would like to hear more about this method.
To summarise this long post, here are my rules of thumb that I follow when implementing Google Analytics on a new site:
- Segment your traffic by personas rather than by traffic sources
Apply the user-centered design principle when designing your analytics solution by using the same personas you’ve created during your product planning and design.
Ideally, in my opinion, you should create a separate property for each persona.
Different personas will enter your site in various ways so don’t worry too much about traffic sources. Even if you have roles that are evaluated by a specific traffic source (such as an SEO manager), it will make more sense to have different “reward levels” for different personas (just as it makes more sense to look at the number of visits per persona, not the total amount). If your SEO manager is compensated by the number of visitors that arrive at the site from organic searches, then you probably already have a different price for potential clients and existing ones.
- Choosing between properties vs views
If you have a large volume of traffic (that exceeds the limits of the free Google Analytics version), I suggest you go with multiple properties.
- Using a tag manager
A tag manager will help you, regardless to the method you choose, but it will especially make life easier when choosing multiple properties. If you use Google Tag Manager, the following script will help you to store persistent data in the data layer object.
- Combined multiple and single properties
If you go with multiple properties, consider adding a roll up property that will contain an aggregated view of all of your site activity. After all, Google Analytics is free, so you should take advantage of this 😉